Subject: [COSE] Benjamin Kaduk's Discuss on draft-ietf-cose-rfc8152bis-struct-10: (with DISCUSS and COMMENT)

From: Benjamin Kaduk via Datatracker <[email-masked]>
Date: Wed, 10 Jun 2020 18:44:09 -0700

Benjamin Kaduk has entered the following ballot position for
draft-ietf-cose-rfc8152bis-struct-10: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-cose-rfc8152bis-struct/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

(Arguably a "discuss discuss".)

If we don't have any worked examples of signatures with message
recovery, should we include that possibility in the Internet Standard
version of the protocol?  Some of the description around how the details
of this would work remain unclear to me.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

(I support Roman's Discuss.)

It's a little weird that we're Obsoletes:ing 8152 yet expect the expert
review procedures from it to remain in force.  Perhaps we should copy
the expert review instructions to this document so that IANA is not
relying on an obsolete document?

Do we need to check usage of "counter signature" with and without space?

I'd also like to discuss the question raised by Martin D. (on -algs)
relating to "AE" and "AEAD".  Section 9.3 is quite clear that we
restrict content-encryption algorithms to those that support AAD, i.e.,
AEAD mechanisms, so we only seem to use AE for the Key Wrap operations.
Perhaps we should add a clarifying note in the terminology section about
what AE and AEAD are used for.

Section 1

Shouldn't we refer to RFC 8259 by its STD number (90)?

   structures.  CBOR was designed specifically both to be small in terms
   of messages transported and implementation size and be a schema-free
   decoder.  A need exists to provide message security services for IoT,

nit: I think the second "be" should be "to be" as well.

   *  The description of the structure for the CBOR objects which are
      transmitted over the wire.  Two objects are defined for
      encryption, signing and message authentication.  One object is

That's two objects *each*, right?

   *  A starting set of attributes that apply to the different security
      objects.

nit: the "starting set" wording feels a little out of place given that
the registry already exists and has stuff that we're not covering.

   providing security services.  The use of COSE, like JOSE and CMS, is
   only in store and forward or offline protocols, different solutions
   would be appropriate for online protocols although one can use COSE
   in an online protocol after having done some type of online key
   establishment process.  Any application which uses COSE for security

nit: comma splice (and the sentence after the comma is a bit long, too).

   additional data fields as part of the structure.  A common structure
   is going to include a URI or other pointer to where the data that is
   being hashed is kept, allowing this to be application-specific.

This is "common" in the sense of "a design pattern expected to be
frequently used", not "a common baseline", right?

Section 1.3

   *  Define a single top message structure so that encrypted, signed,

nit: "top-level"?

   *  Signed messages distinguish between the protected and unprotected
      header parameters that relate to the content from those that
      relate to the signature.

nit(?): shouldn't this be "distinguish between [x] and [y]", not
"between [x] from [y]"?

Section 1.6

   Authenticated Encryption (AE) [RFC5116] algorithms are those
   encryption algorithms that provide an authentication check of the
   contents algorithm with the encryption service.

nit: this last "algorithm" seems spurious?

   context can come from several different sources including: Protocol
   interactions, associated key structures and program configuration.

nit: serial comma, please.

   The context to use can be implicit, identified using the 'kid
   context' header parameter defined in [RFC8613], or identified by a

Wouldn't the "kid context" be an *explicit* context, not implicit?

   protocol-specific identifier.  Context should generally be included
   in the cryptographic configuration; for more details see Section 4.3.

nit: "configuration" is not the first word I would have picked here (and
is not used in Section 4.3).  Maybe "construction"?

Section 2

   1.  The protected header parameters encoded and wrapped in a bstr.

nit: I think this flows better with a comma after "parameters".

   3.  The content of the message.  The content is either the plaintext
       or the ciphertext as appropriate.  The content may be detached
       (i.e. transported separately from the COSE structure), but the
       location is still used.  The content is wrapped in a bstr when

This is "location" in the sense of "the third element of the array", or
"the location in the array is still used"?

   layer.  In the content layer, the plaintext is encrypted and
   information about the encrypted message is placed.  In the recipient
   layer, the content encryption key (CEK) is encrypted and information
   about how it is encrypted for each recipient is placed.  A single

nit: ending the sentence with "is placed" feels rather Yoda-esque.

   4.  When a COSE object is carried as a CoAP payload, the CoAP
       Content-Format Option can be used to identify the message
       content.  The CoAP Content-Format values can be found in Table 2.
       The CBOR tag for the message structure is not required as each
       security message is uniquely identified.

Is it an error to include the tag?

   The following CDDL fragment identifies all of the top messages

[hmm, maybe my earlier comment about "top-level message" was misguided]

Section 3

   or evaluation hints for the processing of the layer.  These two
   buckets are available for use in all of the structures except for
   keys.  While these buckets are present, they may not all be usable in
   all instances.  For example, while the protected bucket is defined as

nit: isn't "all buckets" just "both buckets"?

      h'a0').  The zero-length binary encoding is preferred because it
      is both shorter and the version used in the serialization
      structures for cryptographic computation.  After encoding the map,

nit: this doesn't look like a complete sentence.

      structures for cryptographic computation.  After encoding the map,
      the value is wrapped in the binary object.  Recipients MUST accept

This seems a bit redundant with earlier text (and shouldn't it be a
"byte string" anyway?).

      both a zero-length byte string and a zero-length map encoded in
      the binary value.

["binary value" vs. "binary string" vs. "byte string" again]

      decoded byte string.)  This avoids the problem of all parties
      needing to be able to do a common canonical encoding.

perhaps, "common canonical encoding for input to cryptographic
operations"?

   reference to any other layer.  With the exception of the COSE_Sign
   structure, the only data that needs to cross layers is the

(I assume this includes COSE_Sign0 and the tagged versions, too?)

   Parameters" registry (Section 12.2).  Some common header parameters
   are defined in the next section.

[similar comment as above about "common"; maybe "The basic protocol
header parameters"?]

   malformed.  Applications SHOULD verify that the same label does not
   occur in both the protected and unprotected header parameters.  If
   the message is not rejected as malformed, attributes MUST be obtained
   from the protected bucket before they are obtained from the
   unprotected bucket.

I a little bit worry that "take from protected before unprotected",
combined with "don't check for duplicates", means "last match wins" and
the unprotected one gets used.  Perhaps it's better to talk about taking
precedence if both are present?

Section 3.1

   alg:  This header parameter is used to indicate the algorithm used
      for the security processing.  This header parameter MUST be
      authenticated where the ability to do so exists.  This support is
      provided by AEAD algorithms or construction (COSE_Sign,
      COSE_Sign1, COSE_Mac, and COSE_Mac0).  This authentication can be

Can countersignatures authenticate 'alg'?
Is there an easy listing of the class of message that does *not* allow
for authenticating 'alg'?

      COSE_Sign1, COSE_Mac, and COSE_Mac0).  This authentication can be
      done either by placing the header parameter in the protected
      header parameter bucket or as part of the externally supplied
      data.  The value is taken from the "COSE Algorithms" registry (see

I don't think we've introduced "externally supplied data" yet, so a
forward reference might be in order.

      *  Integer labels in the range of 0 to 7 SHOULD be omitted.

side note: I see that RFC 8152 has this as 0 to 8, and 8 is listed as
"unassigned" in the registry.  Is there a story here?

      *  Integer labels in the range -1 to -128 can be omitted as they
         are algorithm dependent.  If an application can correctly
         process an algorithm, it can be assumed that it will correctly

Where is this sub-partitioning of the -1 to -65536 range specified, that
any given algorithm will only assign "critical" header parameters in the
-1 to -128 range?  If it's just convention I don't think the declarative
language ("can be omitted") is appropriate.

      *  Labels for header parameters required for an application MAY be
         omitted.  Applications should have a statement if the label can
         be omitted.

nit: applications or application protocols?

      The message IV is generated by the following steps:

      1.  Left-pad the Partial IV with zeros to the length of IV.

      2.  XOR the padded Partial IV with the context IV.

nit: this procedure does not indicate how "the length of IV" is known
(i.e., that it's a constant determined by the algorithm).

Section 4.1

   authenticated by the signature, or just present.  An example of
   header a parameter about the content is the content type header

nit: s/header a/a header/

   A COSE Signed Message is defined in two parts.  The CBOR object that
   carries the body and information about the body is called the
   COSE_Sign structure.  The CBOR object that carries the signature and

(COSE_Sign also carries the signature parts?)

      Note: When a signature with a message recovery algorithm is used
      (Section 9.1), the maximum number of bytes that can be recovered
      is the length of the payload.  The size of the payload is reduced
      by the number of bytes that will be recovered.  If all of the

nit(?): it's the "size of the payload" *in the encoded COSE_Sign* object
that is reduced, right?

Section 4.3

   proxy's cache.  But the sender can cause a failure at the server if a
   proxy, or an attacker, changes the set of accept values by including
   the field in the application-supplied data.

nit: "application-supplied data" reads pretty oddly to me, though given
what section this is in I guess it is not limited to just being
"additional authenticated data".
Also, it seems like more a property of the protocol the sender is using
than the sole choice of the sender, to include or not include the set of
accept values in the externally supplied data.

   This document describes the process for using a byte array of
   externally supplied authenticated data; the method of constructing
   the byte array is a function of the application.  Applications that

Why is this a "byte array" and not a "byte string"?

   *  If multiple items are included, applications need to ensure that
      the same byte string cannot be produced if there are different
      inputs.  This would occur by appending the text strings 'AB' and
      'CDE' or by appending the text strings 'ABC' and 'DE'.  This is

(I liked this better as "could occur" of RFC 8152.  Also, is
concatenating" better than "appending", since we are posing the two
strings as peers, not subject and object?)
Also, sometimes this property is referred to as being an "injective
mapping".

Section 4.4

(I also had Roman's comment about the "CounterSignature" attributes in
field (1).)

   3.  The protected attributes from the signer structure encoded in a
       bstr type.  If there are no protected attributes, a zero-length
       byte string is used.  This field is omitted for the COSE_Sign1
       signature structure and CounterSignature0 attributes.

("omitted" means "not present in the array at all", right?)

   4.  The protected attributes from the application encoded in a bstr
       type.  If this field is not supplied, it defaults to a zero-

Are these "protected attributes" the "externally supplied data" of
Section 4.3?  We should probably use the same terminology to talk about
them...

Section 5

   counter signatures use the structure COSE_Countersign.  This is same
   structure as COSE_Signature and thus it can have protected
   attributes, chained counter signatures and information about
   identifying the key.  Abbreviated counter signatures use the

nit: "information about identifying the key" seems redundant.

   specified.  One result of this is that for COSE one can expand the
   concept of counter signatures beyond just the idea of signing a
   signature to being able to sign most of the structures without having
   to create a new signing layer.  When creating a counter signature,

nit: this seems somewhat redundant with the first paragraph of the
section ("this document extends to the concept of a counter signature to
allow [...]").

Section 5.1

   The COSE_Countersignature structure allows for the same set of
   capabilities of a COSE_Signature.  This means that all of the

nit: "same set of capabilities as"

   archiving services.  More information on how this is used can be
   found in the evidence record syntax described in [RFC4998].

nit: I'm binding "this" to "COSE_Countersignature", which causes this
sentence to not make much sense.  Perhaps "how this can be used" or "how
countersignatures signing countersignatures can be used" or "long-term
archiving services"?

   COSE_CounterSignature_Tagged = #6.98(COSE_CounterSignature)

note that 6.98 is incorrect; this is going to be the TBD value.

Section 6.1

I think we need some forward-references to 6.3/6.4, here, since (e.g.)
6.2 is referencing back here to fill in the ciphertext.

   The COSE_recipient structure is a CBOR array.  The fields of the
   array in order are:
   [...]
   ciphertext:  This field contains the encrypted key encoded as a bstr.
      All encoded keys are symmetric keys; the binary value of the key
      is the content.  If there is not an encrypted key, then this field
      is encoded as a nil value.

I guess it's impossible to have protected headers with no encrypted key
(since you need a ciphertext for protected headers)?

   COSE_recipient = [
       Headers,
       ciphertext : bstr / nil,
       ? recipients : [+COSE_recipient]
   ]

side note(?): I'm not sure I really understand when the recursive
COSE_recipient structure would be used at higher depths of recursion.

   passwords:  The CEK is encrypted in a KEK that is derived from a
      password.  As of when this document was published, no password
      algorithms have been defined.

If there aren't any, do we need to include it in the taxonomy?

Section 6.3

It's slightly amusing that the "Enc_structure" is actually the AAD, not
anything encrypted :)

Section 6.4

   1.  Verify that the 'protected' field is empty.

   2.  Verify that there was no external additional authenticated data
       supplied for this operation.

Presumably we fail the operation if either verification fails?

Section 7.3

   3.  The protected attributes from the application encoded as a bstr
       type.  If this field is not supplied, it defaults to a zero-

[as above, using consistent terminology for "externally supplied data"
would be useful.]

Section 8

   A COSE Key structure is built on a CBOR map.  The set of common
   parameters that can appear in a COSE Key can be found in the IANA
   "COSE Key Common Parameters" registry (Section 12.4).  Additional
   parameters defined for specific key types can be found in the IANA
   "COSE Key Type Parameters" registry ([COSE.KeyParameters]).

It's slightly jarring to have a section reference for one registry but
an external reference for the other.

Section 8.1

      cryptographic operation.  Note that the same key can be in a
      different key structure with a different or no algorithm
      specified; however, this is considered to be a poor security
      practice.

Depending on the answer to my question on -algs about capabilities and
their use, this statement might need to be updated.

   kid:  This parameter is used to give an identifier for a key.  The
      identifier is not structured and can be anything from a user-
      provided byte string to a value computed on the public portion of
      the key.  This field is intended for matching against a 'kid'
      parameter in a message in order to filter down the set of keys
      that need to be checked.

I suggest reiterating that it is not in any way a unique identifier.

   Base IV:  This parameter is defined to carry the base portion of an
      IV.  It is designed to be used with the Partial IV header
      parameter defined in Section 3.1.  This field provides the ability
      to associate a Partial IV with a key that is then modified on a

Er, isn't it the Base IV associated with the key and the Partial IV
that's per-message?

      If different keys are derived for each sender, using the same Base
      IV with Partial IVs starting at zero is likely to ensure that the
      IV would not be used twice for a single key.  If different keys
      are derived for each sender, starting at the same Base IV is
      likely to satisfy this condition.  If the same key is used for

The two sentences that start with "if different keys" seem to have some
redundancy that could be eliminated.

Section 9

   to be exhaustive.  New algorithms will be created which will not fit
   into this taxonomy.  If this occurs, then new documents addressing
   this new algorithms are going to be needed.

nit(?): this last sentence is written in a kind of colloquial style.

Section 9.1

   There are two signature algorithm schemes.  The first is signature

nit: mybe "two types of" (and "scheme" singular)?

Section 9.2

   Message Authentication Codes (MACs) provide data authentication and
   integrity protection.  They provide either no or very limited data
   origination.  A MAC, for example, cannot be used to prove the
   identity of the sender to a third party.

Hmm, should the s/can/cannot/ be filed as an erratum against 8152?

Section 9.4

   General KDFs work well with the first type of secret, can do
   reasonably well with the second type of secret, and generally do
   poorly with the last type of secret.  Functions like PBES2 [RFC8018]
   need to be used for non-random secrets.

nit: To be analogous to the previous discussion of KDFs, shouldn't we
refer to a PBKDF construction, not PBES (which provides an abstract API
for password-based encryption that uses PBKDF1 under the covers)?
(Also, my understanding is that PBKDF1 is not exactly considered
state-of-the-art.)

Section 9.5.1

   *  A header parameter identifying the shared secret SHOULD be
      present.

What type of header parameter might do that?

Section 9.5.2

   *  The 'recipients' field is normally absent, but can be used.
      Applications MUST deal with a recipient field being present that
      has an unsupported algorithm, not being able to decrypt that
      recipient is an acceptable way of dealing with it.  Failing to

nit: comma splice

Section 9.5.3

   When using a key transport algorithm, the COSE_Encrypt structure for
   the recipient is organized as follows:

Does key transport use COSE_Encrypt or COSE_Recipient?

Section 9.5.4

   any dynamic key material.  One side effect of this is that perfect
   forward secrecy (see [RFC4949]) is not achievable.  A static key will

Do we want to drop the "perfect"?

   The COSE_Encrypt structure for the recipient is organized as follows:

Is COSE_Encrypt or COSE_Recipient used for direct key agreement?

Section 9.5.5

   The COSE_Encrypt structure for the recipient is organized as follows:

Is COSE_Encrypt or COSE_Recipient used for key agreement with key wrap?

   *  A header parameter identifying the recipient's key SHOULD be
      present.  A header parameter identifying the sender's key SHOULD
      be present.

Is there anything to say about what header parameters those might be?

Section 10

   The document limits the restrictions it imposes on the CBOR Encoder
   needs to work.

nit: missing word or two?  -algs seems to say "restrictions it imposes
on how the CBOR Encoder needs to work".

Section 11

   *  Applications need to determine the set of security algorithms that
      are to be used.  When selecting the algorithms to be used as the
      mandatory-to-implement set, consideration should be given to
      choosing different types of algorithms when two are chosen for a
      specific purpose.  An example of this would be choosing HMAC-

Do we want to mention BCP 201 here?

Section 12

Do we want to update the reference for the registries themselves (to
point to both 8152 and this) in addition to the reference for the
registered entries?

Section 12.3

The COSE Header Algorithm Parameters Registry is
https://www.iana.org/assignments/cose/cose.xhtml#header-algorithm-parameters
, right?  I don't see any of those being talked about in this document
-- they're discussed in the KDF algorithms section in 8152.  So
shouldn't this registry (and its entries) point to the algorithms doc,
not this one?

Section 12.6

   IANA added the following entries to the "CoAP Content-Formats"
   registry while processing [RFC8152].  IANA is requested to update the
   reference value from [RFC8152] to [[This Document]].

[no entries follow]

Section 13

   There are a number of security considerations that need to be taken
   into account by implementers of this specification.  The security
   considerations that are specific to an individual algorithm are
   placed next to the description of the algorithm.  While some

[this stuff is in -algs, not -struct]

   There are a large number of algorithms presented in
   [I-D.ietf-cose-rfc8152bis-algs] that use nonce values.  Nonces
   generally have some type of restriction on their values.  Generally a
   nonce needs to be a unique value either for a key or for some other
   conditions.  In all of these cases, there is no known requirement on
   the nonce being both unique and unpredictable; under these
   circumstances, it's reasonable to use a counter for creation of the
   nonce.  In cases where one wants the pattern of the nonce to be

nit: this looks like a bad edit from the splitting off of the
algorithms: "all of these cases" cannot bind to "specified in this
document" anymore, so we need to describe what we mean differently.

   One area that has been starting to get exposure is doing traffic
   analysis of encrypted messages based on the length of the message.

I think this may have graduated from "starting" to be more of a
mainstream thing :)

Section 14.1

side note: OpenSSL 1.0 (no minor version information given?)?!  That
stuff's EOL!

Section 14.4

side note: what's curve24459?

Section 15.1

[DSS] has only one usage now in -struct, which doesn't seem normative.
I'd expect it to only be normative in -algs.
Likewise for RFC 8032.

It's also interesting to make a normative reference to -algs, which will
be an informational RFC when published (given the current intended
status).  Are we creating it directly onto the downrefs registry?

Appendix A

side note: it seems like any scheme for conveying information about what
algorithm to use other than "implicit by key with each key limited to
one algorithm" has some risk of allowing an attacker's input to cause
the key holder to perform some operation using that key but with the
"wrong" algorithm.  I think that if the externally visible results of
that operation are indistinguishable from "the input was ignored", that
does not give the attacker a channel by which to attack the key, but I'm
not 100% sure.  Even an application-layer "rejected due to bad input"
might be enough of a lever to enable some types of attack.

Appendix B

   All of the currently defined recipient algorithm classes only use two
   layers of the COSE_Encrypt structure.  The first layer is the message

COSE_Recipient?

Acknowledgments

Göran could probably get his proper name, now.

---

From: Jim Schaad <[email-masked]>
Date: Sun, 14 Jun 2020 15:00:23 -0700

-----Original Message-----
From: Benjamin Kaduk via Datatracker <[email-masked]> 
Sent: Wednesday, June 10, 2020 6:44 PM
To: The IESG <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; Matthew Miller <[email-masked]>; [email-masked]
Subject: Benjamin Kaduk's Discuss on draft-ietf-cose-rfc8152bis-struct-10: (with DISCUSS and COMMENT)

When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.)

If we don't have any worked examples of signatures with message recovery, should we include that possibility in the Internet Standard version of the protocol?  Some of the description around how the details of this would work remain unclear to me.

[JLS] I tried a couple of times to get Kenny interested in seeing if anybody in CFRG wanted to pursue this and never got anywhere.  This text is here as much to let people know that such an algorithm might be defined in the future and it might cause some problems if it is.

At one point I looked at looked at writing an experimental RFC which would define a version of this with RSA.  The padding algorithm would look like that in PKCS #1.5 with the following change:  PS = byte count || stolen bytes || 0xff  where byte count is the length of stolen bytes and stolen bytes are the last n bytes of the signed message.  Where byte count is the minimum of the message length and (emLen - tLen - 4).  I ended up not doing this because I did not want it to escape into the wild and I did not see any way of having people implement this for testing and still making sure that it was contained.  

One pointer is https://crypto.stackexchange.com/questions/17802/description-of-signatures-with-message-recovery-as-in-iso-iec-9796-2-and-emv-si

It's a little weird that we're Obsoletes:ing 8152 yet expect the expert review procedures from it to remain in force.  Perhaps we should copy the expert review instructions to this document so that IANA is not relying on an obsolete document?
[JLS] There was some discussion about this in the WG that was pretty inconclusive.  Given that did not change I did not see this to be a big issue but if the IESG wants to change this tell me.

Do we need to check usage of "counter signature" with and without space?
[JLS] I have a note in the XML to the RFC Editor about this point.

I'd also like to discuss the question raised by Martin D. (on -algs) relating to "AE" and "AEAD".  Section 9.3 is quite clear that we restrict content-encryption algorithms to those that support AAD, i.e., AEAD mechanisms, so we only seem to use AE for the Key Wrap operations.
Perhaps we should add a clarifying note in the terminology section about what AE and AEAD are used for.
[JLS] See response to Martin (still to be written)

Section 1

[JLS] Makes sense

[JLS] Changed

[JLS] Changed.

nit: the "starting set" wording feels a little out of place given that the registry already exists and has stuff that we're not covering.
[JLS] Removed starting

be done before sending objects back and forth.
[JLS] New text:
        The use of COSE, like JOSE and CMS, is only for use in store and forward or offline protocols.
        The use of COSE in online protocols needing encryption, require that an online key establishment process
nit: comma splice (and the sentence after the comma is a bit long, too).

This is "common" in the sense of "a design pattern expected to be frequently used", not "a common baseline", right?
[JLS] Yes

Section 1.3

nit: "top-level"?
[JLS] "overall"?

nit(?): shouldn't this be "distinguish between [x] and [y]", not "between [x] from [y]"?
[JLS] Changed, we will see what the copy editor says.

Section 1.6

nit: this last "algorithm" seems spurious?
[JLS] See message to Martin (to be written)

nit: serial comma, please.
[JLS] Now Oxford comma style

Wouldn't the "kid context" be an *explicit* context, not implicit?
[JLS] No it is still implicit.  Consider the usage of a "kid context" in OSCORE as a method of identifying what items should be placed into the context structure.  It changes over time and is not the kid itself.  The use of "kid context" as a name is not good, but I did not name it.

nit: "configuration" is not the first word I would have picked here (and is not used in Section 4.3).  Maybe "construction"?
[JLS] Makes sense

Section 2

[JLS] sure

This is "location" in the sense of "the third element of the array", or "the location in the array is still used"?
[JLS] As in the third element of the array.

nit: ending the sentence with "is placed" feels rather Yoda-esque.
[JLS] Your point being?  Text is re-written to eliminate.

[JLS] No

[JLS] see above comment.

Section 3

nit: isn't "all buckets" just "both buckets"?
[JLS]  I probably meant to rite always though.

nit: this doesn't look like a complete sentence.
[JLS] The RFC editor did not object last time.  Noun = encoding, verb = preferred.

This seems a bit redundant with earlier text (and shouldn't it be a "byte string" anyway?).
[JLS] Yes it is redundant - removed

[JLS] Yep - fixed

perhaps, "common canonical encoding for input to cryptographic operations"?
[JLS] A bit wordy - but ok

(I assume this includes COSE_Sign0 and the tagged versions, too?)
[JLS] No it does not include COSE_Sign0 because it has only one layer, but it does include the tagged version which is defined in terms of COSE_Sign.

[similar comment as above about "common"; maybe "The basic protocol header parameters"?]
[JLS] I don't like that wording, but have no problems eliminating "common".

I a little bit worry that "take from protected before unprotected", combined with "don't check for duplicates", means "last match wins" and the unprotected one gets used.  Perhaps it's better to talk about taking precedence if both are present?
[JLS] **** I don't understand your worry here.  These are separate maps and thus there is no "last match wins" between the two different buckets.

Section 3.1

Can countersignatures authenticate 'alg'?
Is there an easy listing of the class of message that does *not* allow for authenticating 'alg'?
[JLS] Where to start, all of the constructions/algorithms have the ability to do the authentication.  The use of an AE algorithm does not allow this. By construction, the encryption structures (Encrypt, Encrypt0 and Recipient) do not do this,   Changed to " (e.g. COSE_Sign and COSE_Mac0)"

I don't think we've introduced "externally supplied data" yet, so a forward reference might be in order.
[JLS] Done

side note: I see that RFC 8152 has this as 0 to 8, and 8 is listed as "unassigned" in the registry.  Is there a story here?
[JLS] Yes, I had originally assigned countersign0 to 8 and then messed up.

Where is this sub-partitioning of the -1 to -65536 range specified, that any given algorithm will only assign "critical" header parameters in the
-1 to -128 range?  If it's just convention I don't think the declarative language ("can be omitted") is appropriate.
[JLS] There is no requirement that an algorithm is restricted to that range.  The assumption is that purely optional items might be placed farther out in the range and thus need to be placed in the "crit" attribute.  This is just a restriction, similar to the 0-7 range of things that can be omitted.

nit: applications or application protocols?
[JLS] I am pretty sure I meant applications.

nit: this procedure does not indicate how "the length of IV" is known (i.e., that it's a constant determined by the algorithm).

[JLS] I don't think this is really necessary but "IV (determined by the algorithm)"

Section 4.1

[JLS] Yep

(COSE_Sign also carries the signature parts?)
[JLS] No - they are carried in COSE_Signature

nit(?): it's the "size of the payload" *in the encoded COSE_Sign* object that is reduced, right?
[JLS] No it is the "size of the payload" as in the payload you signed.

Section 4.3

nit: "application-supplied data" reads pretty oddly to me, though given what section this is in I guess it is not limited to just being "additional authenticated data".
Also, it seems like more a property of the protocol the sender is using than the sole choice of the sender, to include or not include the set of accept values in the externally supplied data.
[JLS] No, it really is just externally supplied data - so changed to that

Why is this a "byte array" and not a "byte string"?
[JLS] This is dealing with a value passed in from the application and does not refer to a CBOR encoded value.

(I liked this better as "could occur" of RFC 8152.  Also, is concatenating" better than "appending", since we are posing the two strings as peers, not subject and object?) Also, sometimes this property is referred to as being an "injective mapping".
[JLS] somebody asked for the change from could to would.  I debated it with them and then made the change.  Going to concatenation makes sense.  I don't think that giving the property a name would really help

Section 4.4

(I also had Roman's comment about the "CounterSignature" attributes in field (1).)

[JLS] Yes

Are these "protected attributes" the "externally supplied data" of Section 4.3?  We should probably use the same terminology to talk about them...
[JLS] Yes - fixed in all three spots

Section 5

nit: "information about identifying the key" seems redundant.
[JLS] Changed to "        This is same structure as COSE_Signature and thus it can have protected and unprotected attributes, including chained counter signatures."

nit: this seems somewhat redundant with the first paragraph of the section ("this document extends to the concept of a counter signature to allow [...]").
[JLS] Doesn't bother me - it falls out from the previous sentence

Section 5.1

[JLS] Changed

nit: I'm binding "this" to "COSE_Countersignature", which causes this sentence to not make much sense.  Perhaps "how this can be used" or "how countersignatures signing countersignatures can be used" or "long-term archiving services"?
[JLS] This is a really weird reading on your part, but changed.

note that 6.98 is incorrect; this is going to be the TBD value.
[JLS] Cut and paste error - yes this is a TBD.

Section 6.1

I guess it's impossible to have protected headers with no encrypted key (since you need a ciphertext for protected headers)?
[JLS] Yes that is true

   COSE_recipient = [
       Headers,
       ciphertext : bstr / nil,

side note(?): I'm not sure I really understand when the recursive COSE_recipient structure would be used at higher depths of recursion.
[JLS] Did you take a look at Appendix B

[JLS] It is only a matter of time.  Personally I was waiting for Argon2 get someplace before even trying to define one. 

Section 6.3

It's slightly amusing that the "Enc_structure" is actually the AAD, not anything encrypted :)
[JLS] You are easily amused then.

Section 6.4

Presumably we fail the operation if either verification fails?
[JLS] Yes that would be my expectation.

Section 7.3

[JLS] see above

Section 8

It's slightly jarring to have a section reference for one registry but an external reference for the other.
[JLS]  It doesn't really bother me

Section 8.1

Depending on the answer to my question on -algs about capabilities and their use, this statement might need to be updated.
[JLS] Not clear which comment you are referring to

[JLS] sure.

Er, isn't it the Base IV associated with the key and the Partial IV that's per-message?
[JLS] Yup.

The two sentences that start with "if different keys" seem to have some redundancy that could be eliminated.
[JLS] Looks like I tried two different ways to same the same thing and did not delete one of them.

Section 9

nit(?): this last sentence is written in a kind of colloquial style.
[JLS] Doesn't really add anything - delete

Section 9.1

nit: mybe "two types of" (and "scheme" singular)?
[JLS] No, I think this is a correct usage.

Section 9.2

Hmm, should the s/can/cannot/ be filed as an erratum against 8152?
[JLS] Yes if we don't think we are going to have a fast publish.  What is the current RFC Editor queue processing time?

Section 9.4

nit: To be analogous to the previous discussion of KDFs, shouldn't we refer to a PBKDF construction, not PBES (which provides an abstract API for password-based encryption that uses PBKDF1 under the covers)?
(Also, my understanding is that PBKDF1 is not exactly considered
state-of-the-art.)
[JLS] Given what I said above, if you really want to change this we could point to Argon2

Section 9.5.1

What type of header parameter might do that?
[JLS] Will KID would be one that could do this.

Section 9.5.2

nit: comma splice
[JLS] ok

Section 9.5.3

Does key transport use COSE_Encrypt or COSE_Recipient?
[JLS] No, it uses COSE_Recipient.  It used to use COSE_Encrypt until I change the syntax slightly.

Section 9.5.4

[JLS] Yes.

Is COSE_Encrypt or COSE_Recipient used for direct key agreement?
[JLS] see above and others.

Section 9.5.5

Is there anything to say about what header parameters those might be?
[JLS] No, that would be more algorithm specific esp for the latter.

Section 10

nit: missing word or two?  -algs seems to say "restrictions it imposes on how the CBOR Encoder needs to work".
[JLS] 

Section 11

Do we want to mention BCP 201 here?
[JLS] I don't have an issue with this, I forgot such a beast had been created.

Section 12

Do we want to update the reference for the registries themselves (to point to both 8152 and this) in addition to the reference for the registered entries?
[JLS] Unless we move the DE guidance, I don't see any reason to.

Section 12.3

The COSE Header Algorithm Parameters Registry is https://www.iana.org/assignments/cose/cose.xhtml#header-algorithm-parameters
, right?  I don't see any of those being talked about in this document
-- they're discussed in the KDF algorithms section in 8152.  So shouldn't this registry (and its entries) point to the algorithms doc, not this one?
[JLS] Yes they should

Section 12.6

[no entries follow]
[JLS] s/the following//

Section 13

[JLS] Deleted

nit: this looks like a bad edit from the splitting off of the
algorithms: "all of these cases" cannot bind to "specified in this document" anymore, so we need to describe what we mean differently.
[JLS] Might just as well delete the duplicated paragraph. gone

I think this may have graduated from "starting" to be more of a mainstream thing :)
[JLS] Given that I had to explain this initially, it is nice to know it has gone far more main stream.  No longer starting.

Section 14.1

side note: OpenSSL 1.0 (no minor version information given?)?!  That stuff's EOL!
[JLS] I actually just updated the library in the last month to require 1.1 in order to get support for EdDSA, however yes it did not really what the minor version was because it was totally generic to that version.  I changed that to 1.1, but given that this goes away before publishing I don't suppose it matters andy.

Section 14.4

side note: what's curve24459?
[JLS] You mean you don't recognize the really twisted curve of 25519

Section 15.1

[JLS] Done

It's also interesting to make a normative reference to -algs, which will be an informational RFC when published (given the current intended status).  Are we creating it directly onto the downrefs registry?
[JLS] I could move the reference without any problems.  However, putting it directly in to the downref registry is probably a good idea so that protocol documents can make algorithms MUST.

Appendix A

side note: it seems like any scheme for conveying information about what algorithm to use other than "implicit by key with each key limited to one algorithm" has some risk of allowing an attacker's input to cause the key holder to perform some operation using that key but with the "wrong" algorithm.  I think that if the externally visible results of that operation are indistinguishable from "the input was ignored", that does not give the attacker a channel by which to attack the key, but I'm not 100% sure.  Even an application-layer "rejected due to bad input"
might be enough of a lever to enable some types of attack.
[JLS] The current CoRE group communication document is breaking the "one key one algorithm" rule although in an offline way.  At least for OSCORE, there would not be a way to distinguish between any of the "it did not decrypt" cases.  

Appendix B

COSE_Recipient?
[JLS] That’s what I get for renaming things.

Acknowledgments

Göran could probably get his proper name, now.
[JLS] I think he probably would as well.

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 15 Jun 2020 16:04:43 -0700

Hi Jim,

> https://datatracker.ietf.org/doc/draft-ietf-cose-rfc8152bis-struct/

I was thinking specifically of worked examples for COSE usage.  E.g.,
verifying that the "payload" element of SOSE_Sign interoperates, especially
when the signature provides full message recovery and how the "message
sent" and recovered content are reconstituted into the "message content"
during the Verification() process.  We don't give many details of how that
would work or what an algorithm specification would need to provide in
order to give a complete specification.

My preference would be to bring the text into this document, but I'd like
to hear from others.

> [JLS] I have a note in the XML to the RFC Editor about this point.

Ah, excellent.

> nit: comma splice (and the sentence after the comma is a bit long, too).

[something doesn't seem to be showing up well in the text/plain component
here; I'll try to take a look at the updated I-D when it lands]

> This is "common" in the sense of "a design pattern expected to be frequently used", not "a common baseline", right?

"popular" is not quite right, though maybe "oft-used"?

> [JLS] No it is still implicit.  Consider the usage of a "kid context" in OSCORE as a method of identifying what items should be placed into the context structure.  It changes over time and is not t…

Okay.

> Is it an error to include the tag?

Okay.

> [JLS] The RFC editor did not object last time.  Noun = encoding, verb = preferred.

I was thinking more the parallelism in "is both <x> and <y>", or perhaps
that "shorter" invites a comparison with something unnamed ... I couldn't
really pin my finger on it at the time.

> [JLS] **** I don't understand your worry here.  These are separate maps and thus there is no "last match wins" between the two different buckets.

I think this can depend on whether you see the application as doing "I am
going to obtain all the attributes" or "I am going to get a value of
attribute <X>".  In the latter, you presumably stop once you get a value,
here, from the protected bucket.  In the former case, though, if you do
"get all labels from the protected bucket, put into local cache, then get
all labels from the unprotected bucket, put into the same cache", then a
"last store wins" for the cache will do the wrong thing.
If that's not a relevant "worry", sorry for the noise.

> [JLS] Where to start, all of the constructions/algorithms have the ability to do the authentication.  The use of an AE algorithm does not allow this. By construction, the encryption structures (Enc…

We have a MUST-level requirement to do something "where the ability to do
so exists".  If we leave it to the reader to determine when the ability to
do so exists, I don't expect 100% accuracy in practice, so I'm looking for
a way that we can give clear guidance on when this protection needs to be
present.

> [JLS] Yes, I had originally assigned countersign0 to 8 and then messed up.

Ah, okay.

> [JLS] There is no requirement that an algorithm is restricted to that range.  The assumption is that purely optional items might be placed farther out in the range and thus need to be placed in the…

I agree that it's just a restriction, but the way it's written right now it
feels like the core spec is making statements about what you should assume
to be the case for algorithm-dependent values, without actually placing a
requirement on the algorithm specifications to provide that property.  If
we said that algorithm specs can impose a similar requirement on which
values are required to implement and thus safe to omit, and suggested the
range of -1 to -128 for those values, I wouldn't have a problem, since that
makes it clear that it's a property of the algorithm in question.

> [JLS] I am pretty sure I meant applications.

I'm having trouble picturing this, but will trust you that it makes sense.

> [JLS] No - they are carried in COSE_Signature

I thought the COSE_Sign structure contained one or more COSE_Signature
structures.

> [JLS] No it is the "size of the payload" as in the payload you signed.

I'm having trouble parsing that -- it feels circular to me.  "In the act of
signing, the size of the payload you are signing is reduced by the number
of bytes that will be recovered."  So what's the payload, the longer thing
or the shorter thing?

> [JLS] This is dealing with a value passed in from the application and does not refer to a CBOR encoded value.

Okay.

> [JLS] somebody asked for the change from could to would.  I debated it with them and then made the change.  Going to concatenation makes sense.  I don't think that giving the property a name would…

Okay.

> [JLS] Changed to "        This is same structure as COSE_Signature and thus it can have protected and unprotected attributes, including chained counter signatures."

That probably works.  (I was just expecting "information identifying the
key" or "information about the key".)

> [JLS] Did you take a look at Appendix B

Not when I wrote this :)

> [JLS] Not clear which comment you are referring to

Oops, the referred-to question was "Am I reading this right that the idea
is to use capabilities to lock a key down to a single curve?"

> [JLS] Yes if we don't think we are going to have a fast publish.  What is the current RFC Editor queue processing time?

I think it's pushing 12 weeks, what with C238 and the bulge that
accumulated in RFC-EDITOR (https://www.rfc-editor.org/current_queue.php).
I'd happily approve a report if you want to file one.

> [JLS] Given what I said above, if you really want to change this we could point to Argon2

My main complaint here is that there's a "type error" -- PBES2 is not a
KDF (right?).  I could tolerate dropping the last sentence entirely, or a
bland "Specific KDF constructions are needed to be safely used with
non-random secrets" (and no reference), but pointing to Argon2 would also
be fine.

> [JLS] Will KID would be one that could do this.

Do we want to provide guidance in the doc, or is "kid" sufficiently
self-explanatory and obvious?

> [JLS] see above and others.

Got it, thanks.

> [JLS] I don't have an issue with this, I forgot such a beast had been created.

You have a lot of company :)

> -- they're discussed in the KDF algorithms section in 8152.  So shouldn't this registry (and its entries) point to the algorithms doc, not this one?

(I think Alvaro(?) also remarked on this and you replied there too.)

> [JLS] I actually just updated the library in the last month to require 1.1 in order to get support for EdDSA, however yes it did not really what the minor version was because it was totally generic…

Yeah, it was just a side note since it will go away.  Thanks for updating
it!

> [JLS] You mean you don't recognize the really twisted curve of 25519

;)

> [JLS] I could move the reference without any problems.  However, putting it directly in to the downref registry is probably a good idea so that protocol documents can make algorithms MUST.

I think we had someone (Barry?) mention on the telechat that we might not
need to put it in the registry since it was unclear who else would need to
reference it.  So, thanks for stating a position -- I trust that the
responsible AD will do the right thing.

> [JLS] The current CoRE group communication document is breaking the "one key one algorithm" rule although in an offline way.  At least for OSCORE, there would not be a way to distinguish between an…

Sigh.  I wonder if I can convince any cryptographers to look at the group
communication document.

> [JLS] I think he probably would as well.

I think I've seen the RPC proactively do this, but nothing stops us from
helping.

Thanks for all the discussion and updates!

-Ben

---

From: Jim Schaad <[email-masked]>
Date: Mon, 15 Jun 2020 18:44:02 -0700

> From: Benjamin Kaduk <[email-masked]>
> Sent: Monday, June 15, 2020 4:05 PM
> To: Jim Schaad <[email-masked]>
> Cc: 'The IESG' <[email-masked]>; [email-masked]; cose-
> [email-masked]; 'Matthew Miller' <[email-masked]>;
> [email-masked]
> Subject: Re: [COSE] Benjamin Kaduk's Discuss on draft-ietf-cose-rfc8152bis-
> struct-10: (with DISCUSS and COMMENT)
> 
> Hi Jim,
> 
> > Cc: [email-masked]; [email-masked];
> > [email-masked]; Matthew Miller <[email-masked]>;
> > [email-masked]
> > Subject: Benjamin Kaduk's Discuss on
> > draft-ietf-cose-rfc8152bis-struct-10: (with DISCUSS and COMMENT)
> >
> > email addresses included in the To and CC lines. (Feel free to cut
> > this introductory paragraph, however.)
> >
> >
> > Please refer to
> > https://www.ietf.org/iesg/statement/discuss-criteria.html
> > If we don't have any worked examples of signatures with message recovery,
> should we include that possibility in the Internet Standard version of the
> protocol?  Some of the description around how the details of this would work
> remain unclear to me.
> >
> > [JLS] I tried a couple of times to get Kenny interested in seeing if anybody in
> CFRG wanted to pursue this and never got anywhere.  This text is here as much
> to let people know that such an algorithm might be defined in the future and it
> might cause some problems if it is.
> >
> > At one point I looked at looked at writing an experimental RFC which would
> define a version of this with RSA.  The padding algorithm would look like that in
> PKCS #1.5 with the following change:  PS = byte count || stolen bytes || 0xff
> where byte count is the length of stolen bytes and stolen bytes are the last n
> bytes of the signed message.  Where byte count is the minimum of the
> message length and (emLen - tLen - 4).  I ended up not doing this because I did
> not want it to escape into the wild and I did not see any way of having people
> implement this for testing and still making sure that it was contained.
> >
> > One pointer is
> > https://crypto.stackexchange.com/questions/17802/description-of-signat
> > ures-with-message-recovery-as-in-iso-iec-9796-2-and-emv-si
> 
> I was thinking specifically of worked examples for COSE usage.  E.g., verifying
> that the "payload" element of SOSE_Sign interoperates, especially when the
> signature provides full message recovery and how the "message sent" and
> recovered content are reconstituted into the "message content"
> would work or what an algorithm specification would need to provide in order
> to give a complete specification.
[JLS] I don't have any problems with providing such a thing using the evil signature algorithm that I outlined above on the examples website, but I don't know that it has any place in the document.

> >         The use of COSE in online protocols needing encryption,
> > require that an online key establishment process

[JLS] Ok - trying to change it just made me sad.  Rewrote to

        A one such application-specific element would be to include a URI or other pointer to where the data that is being hashed can be obtained.

> > [hmm, maybe my earlier comment about "top-level message" was
> > misguided] [JLS] see above comment.
> >
> > Section 3
> >
> I was thinking more the parallelism in "is both <x> and <y>", or perhaps that
> "shorter" invites a comparison with something unnamed ... I couldn't really pin
> my finger on it at the time.
[JLS] The options were covered in the preceding sentences and I don't know that you can get much shorter than a one byte encoding and still have existence.

> > I a little bit worry that "take from protected before unprotected", combined
> with "don't check for duplicates", means "last match wins" and the unprotected
> one gets used.  Perhaps it's better to talk about taking precedence if both are
> present?
> > [JLS] **** I don't understand your worry here.  These are separate maps and
> thus there is no "last match wins" between the two different buckets.
> 
> I think this can depend on whether you see the application as doing "I am going
> to obtain all the attributes" or "I am going to get a value of attribute <X>".  In
> the latter, you presumably stop once you get a value, here, from the protected
> bucket.  In the former case, though, if you do "get all labels from the protected
> bucket, put into local cache, then get all labels from the unprotected bucket,
> put into the same cache", then a "last store wins" for the cache will do the
> wrong thing.
[JLS] No it is a relevant worry.  There are two buckets and if you combine the buckets you had better combine them in the correct way.  You are going to need to know if the cache is last wins, first wins or go boom on duplicates.  I am not sure what I can say to make things clearer though.

> > [JLS] Where to start, all of the constructions/algorithms have the ability to do
> the authentication.  The use of an AE algorithm does not allow this. By
> construction, the encryption structures (Encrypt, Encrypt0 and Recipient) do not
> do this,   Changed to " (e.g. COSE_Sign and COSE_Mac0)"
> 
> We have a MUST-level requirement to do something "where the ability to do so
> exists".  If we leave it to the reader to determine when the ability to do so
> exists, I don't expect 100% accuracy in practice, so I'm looking for a way that
> we can give clear guidance on when this protection needs to be present.

[JLS] Where the ability does not exist is when you do an AE algorithm.  It can be done everywhere else.  (And don't get me started on all of the arguments that I had with the OSCORE people about how important I thought it was to do this.)  Otherwise between the structure and the algorithm (AEAD) you can always do this either in the protected attributes or in external data.

> > Where is this sub-partitioning of the -1 to -65536 range specified,
> > that any given algorithm will only assign "critical" header parameters
> > in the
> > [JLS] There is no requirement that an algorithm is restricted to that range.
> The assumption is that purely optional items might be placed farther out in the
> range and thus need to be placed in the "crit" attribute.  This is just a
> restriction, similar to the 0-7 range of things that can be omitted.
> 
> I agree that it's just a restriction, but the way it's written right now it feels like
> the core spec is making statements about what you should assume to be the
> case for algorithm-dependent values, without actually placing a requirement
> on the algorithm specifications to provide that property.  If we said that
> algorithm specs can impose a similar requirement on which values are
> required to implement and thus safe to omit, and suggested the range of -1 to -
> 128 for those values, I wouldn't have a problem, since that makes it clear that
> it's a property of the algorithm in question.

[JLS]  Does this read better?

Integer labels in the range -1 to -128 can be omitted.   Algorithms can assign labels in this range where the ability to process the content of the label is considered to be core to implementing the algorithm.  Algorithms can assign labels outside of this range where the ability to process the content of the label is not considered to be core, but needs to be understood to correctly process this instance.  Integer labels in the range -129 to -65536 <bcp14>SHOULD</bcp14> be included as these would be less common header parameters that might not be generally supported.

> > (COSE_Sign also carries the signature parts?) [JLS] No - they are
> > carried in COSE_Signature
> 

Yes it does.  I think of the "signature" as the byte string as being different from the COSE_Signature structure.  This is referring to the first.

> I'm having trouble parsing that -- it feels circular to me.  "In the act of signing,
> the size of the payload you are signing is reduced by the number of bytes that
> will be recovered."  So what's the payload, the longer thing or the shorter
> thing?

[JLS] The payload that is encrypted is the longer thing.  The payload that is carried in the COSE message is the shorter thing.

> > Depending on the answer to my question on -algs about capabilities and their
> use, this statement might need to be updated.
> Oops, the referred-to question was "Am I reading this right that the idea is to
> use capabilities to lock a key down to a single curve?"
[JLS] Capabilities are not used to lock a key down to a single curve.  The curve is a field in the COSE_Key object.

> > [JLS] Yes if we don't think we are going to have a fast publish.  What is the
> current RFC Editor queue processing time?
> 
> I think it's pushing 12 weeks, what with C238 and the bulge that accumulated in
> RFC-EDITOR (https://www.rfc-editor.org/current_queue.php).
[JLS] done
> > nit: To be analogous to the previous discussion of KDFs, shouldn't we refer to
> a PBKDF construction, not PBES (which provides an abstract API for password-
> based encryption that uses PBKDF1 under the covers)?
> My main complaint here is that there's a "type error" -- PBES2 is not a KDF
> (right?).  I could tolerate dropping the last sentence entirely, or a bland
> "Specific KDF constructions are needed to be safely used with non-random
> secrets" (and no reference), but pointing to Argon2 would also be fine.
[JLS] Switched.

> Do we want to provide guidance in the doc, or is "kid" sufficiently self-
> explanatory and obvious?
[JLS] I think that it is obvious.  I also think something like "password hint" would be as well, but is not currently defined.

> > It's also interesting to make a normative reference to -algs, which will be an
> informational RFC when published (given the current intended status).  Are we
> creating it directly onto the downrefs registry?
> > [JLS] I could move the reference without any problems.  However, putting it
> directly in to the downref registry is probably a good idea so that protocol
> documents can make algorithms MUST.
> 
> reference it.  So, thanks for stating a position -- I trust that the responsible AD
> will do the right thing.
> 
> > Appendix A
> >
> algorithm to use other than "implicit by key with each key limited to one
> algorithm" has some risk of allowing an attacker's input to cause the key holder
> to perform some operation using that key but with the "wrong" algorithm.  I
> think that if the externally visible results of that operation are indistinguishable
> from "the input was ignored", that does not give the attacker a channel by
> which to attack the key, but I'm not 100% sure.  Even an application-layer
> "rejected due to bad input"
> > [JLS] The current CoRE group communication document is breaking the "one
> key one algorithm" rule although in an offline way.  At least for OSCORE, there
> would not be a way to distinguish between any of the "it did not decrypt" cases.
> 

[JLS] That is not where I would put the limited resources.  I would have them look at draft-ietf-lwig-curve-representations and ask if there are issues using the same private key for an EdDSA signature and ECDH after doing the mapping.  I think I recently saw something on the CFRG list which had a pointer to a paper saying that reuse for ECDH and ECDSA was ok.

> I think I've seen the RPC proactively do this, but nothing stops us from helping.

Jim

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 16 Jun 2020 20:02:30 -0700

> [JLS] I don't have any problems with providing such a thing using the evil signature algorithm that I outlined above on the examples website, but I don't know that it has any place in the document.

I also expect that such a thing doesn't have any place in the document.

But where does that leave us, though -- do we have enough
knowledge+experience for how to use signature with recovery for COSE
messages to merit granting it full Internet Standard status?  I can't say
the answer for sure, just on my own authority; hence the "discuss discuss".

>         A one such application-specific element would be to include a URI or other pointer to where the data that is being hashed can be obtained.

Thanks, that seems better on a few axes.

> [JLS] The options were covered in the preceding sentences and I don't know that you can get much shorter than a one byte encoding and still have existence.

Okay, let's leave it for the RFC Editor.

> [JLS] No it is a relevant worry.  There are two buckets and if you combine the buckets you had better combine them in the correct way.  You are going to need to know if the cache is last wins, firs…

I think the core of the (potential) issue is "first" -- "first" assumes
something about what procedure is being used in a way that "priority over"
or "has precedence" does not, which is what I was trying to get at.  (Going
into more detail about the procedure to use for which "first" makes sense
feels like it's going in the wrong direction.)

> [JLS] Where the ability does not exist is when you do an AE algorithm.  It can be done everywhere else.  (And don't get me started on all of the arguments that I had with the OSCORE people about ho…

Brainstorming (and feel free to do something completely different, or
decide that it's not worth it), maybe "(The only algorithm and message-type
combinations where this ability does not exist is when an authenticated
encryption only (not AEAD) symmetric cipher mode is used for a
[COSE_Encrypt*, COSE_Recipient*] message.)"?

> Integer labels in the range -1 to -128 can be omitted.   Algorithms can assign labels in this range where the ability to process the content of the label is considered to be core to implementing th…

That helps, yes.  Even better would be normative language, like "algorithms
MUST only assign labels in this range where [...]" :)

> Yes it does.  I think of the "signature" as the byte string as being different from the COSE_Signature structure.  This is referring to the first.

Okay ... but even in this sense the "signature" is *indirectly* contained in
COSE_Sign, and I at least did not get the sense from this text that we
intended the "directly carries" sense of the term.  Maybe we should leave a
note to ask the RFC Editor for help; I'm failing to come up with a good
wording right now.

> [JLS] The payload that is encrypted is the longer thing.  The payload that is carried in the COSE message is the shorter thing.

Using the same word to mean different things makes the reader work.  I'd
support adding some adjectives, but won't insist on it.

> [JLS] Capabilities are not used to lock a key down to a single curve.  The curve is a field in the COSE_Key object.

Okay, thanks for clarifying.

> > I'd happily approve a report if you want to file one.

Thanks, verified!

Okay.

> [JLS] That is not where I would put the limited resources.  I would have them look at draft-ietf-lwig-curve-representations and ask if there are issues using the same private key for an EdDSA signa…

Fair enough.

Thanks, as always,

Ben

---

From: Jim Schaad <[email-masked]>
Date: Tue, 16 Jun 2020 20:41:56 -0700

I think this is everything except for you discuss-discuss.

Jim

> Sent: Tuesday, June 16, 2020 8:03 PM
'Matthew
> Miller' <[email-masked]>; 'The IESG' <[email-masked]>;
> [email-masked]
> > > Cc: 'The IESG' <[email-masked]>;
> > > [email-masked]; cose- [email-masked];
> > > 'Matthew Miller' <[email-masked]>;
> > > [email-masked]
> > > > Cc: [email-masked];
> > > > [email-masked]; [email-masked]; Matthew Miller
> > > > <[email-masked]>;
> > > > When responding, please keep the subject line intact and reply to
> > > > all email addresses included in the To and CC lines. (Feel free to
> > > > cut this introductory paragraph, however.)
> > > >
> > > >
> > > > Please refer to
> > > > recovery,
> > > should we include that possibility in the Internet Standard version
> > > of the protocol?  Some of the description around how the details of
> > > this would work remain unclear to me.
> > > >
> > > CFRG wanted to pursue this and never got anywhere.  This text is
> > > here as much to let people know that such an algorithm might be
> > > defined in the future and it might cause some problems if it is.
> > > >
> > > define a version of this with RSA.  The padding algorithm would look
> > > like that in PKCS #1.5 with the following change:  PS = byte count
> > > || stolen bytes || 0xff where byte count is the length of stolen
> > > bytes and stolen bytes are the last n bytes of the signed message.
> > > Where byte count is the minimum of the message length and (emLen -
> > > tLen - 4).  I ended up not doing this because I did not want it to
> > > escape into the wild and I did not see any way of having people
implement
> this for testing and still making sure that it was contained.
> > > >
> > > > One pointer is
> > > > https://crypto.stackexchange.com/questions/17802/description-of-si
> > > > gnat ures-with-message-recovery-as-in-iso-iec-9796-2-and-emv-si
> > >
> > > I was thinking specifically of worked examples for COSE usage.
> > > E.g., verifying that the "payload" element of SOSE_Sign
> > > interoperates, especially when the signature provides full message
> > > recovery and how the "message sent" and recovered content are
> reconstituted into the "message content"
> > > during the Verification() process.  We don't give many details of
> > > how that would work or what an algorithm specification would need to
> > > provide in order to give a complete specification.
> > [JLS] I don't have any problems with providing such a thing using the
evil
> signature algorithm that I outlined above on the examples website, but I
don't
> know that it has any place in the document.
> 
the
> answer for sure, just on my own authority; hence the "discuss discuss".
> 

Well - I think that I do.  I did play with this at one point which is why
there are a number of - if you do this then ... statements in the draft.  I
don't think that there is anything in the base COSE document that is going
to care about signature with recovery and the details can be left to an
algorithm description when we get one.  YMMV

> > > >         The use of COSE, like JOSE and CMS, is only for use in
> > > > store and forward
> > > or offline protocols.
> > > [something doesn't seem to be showing up well in the text/plain
> > > component here; I'll try to take a look at the updated I-D when it
> > > lands]
> > >
> >         A one such application-specific element would be to include a
URI or
> other pointer to where the data that is being hashed can be obtained.
> 
> > > > [JLS] The RFC editor did not object last time.  Noun = encoding,
> > > > verb =
> > > preferred.
> > >
> > > I was thinking more the parallelism in "is both <x> and <y>", or
> > > perhaps that "shorter" invites a comparison with something unnamed
> > > ... I couldn't really pin my finger on it at the time.
> > [JLS] The options were covered in the preceding sentences and I don't
know
> that you can get much shorter than a one byte encoding and still have
> existence.
> 
> > > with "don't check for duplicates", means "last match wins" and the
> > > unprotected one gets used.  Perhaps it's better to talk about taking
> > > I think this can depend on whether you see the application as doing
> > > "I am going to obtain all the attributes" or "I am going to get a
> > > value of attribute <X>".  In the latter, you presumably stop once
> > > you get a value, here, from the protected bucket.  In the former
> > > case, though, if you do "get all labels from the protected bucket,
> > > put into local cache, then get all labels from the unprotected
> > > bucket, put into the same cache", then a "last store wins" for the
cache will
> do the wrong thing.
> > [JLS] No it is a relevant worry.  There are two buckets and if you
combine the
> buckets you had better combine them in the correct way.  You are going to
> need to know if the cache is last wins, first wins or go boom on
duplicates.  I am
> not sure what I can say to make things clearer though.
> 
something
> about what procedure is being used in a way that "priority over"
> or "has precedence" does not, which is what I was trying to get at.
(Going into
> more detail about the procedure to use for which "first" makes sense feels
like
> it's going in the wrong direction.)

How about /before they are obtained/and only if not present should they be
obtained/

> > > > Is there an easy listing of the class of message that does *not*
> > > > allow for
> > > authenticating 'alg'?
> > > the authentication.  The use of an AE algorithm does not allow this.
> > > By construction, the encryption structures (Encrypt, Encrypt0 and
Recipient)
> do not
> > > We have a MUST-level requirement to do something "where the ability
> > > to do so exists".  If we leave it to the reader to determine when
> > > the ability to do so exists, I don't expect 100% accuracy in
> > > practice, so I'm looking for a way that we can give clear guidance on
when
> this protection needs to be present.
> >
> > [JLS] Where the ability does not exist is when you do an AE algorithm.
It can
> be done everywhere else.  (And don't get me started on all of the
arguments
> that I had with the OSCORE people about how important I thought it was to
do
> this.)  Otherwise between the structure and the algorithm (AEAD) you can
> always do this either in the protected attributes or in external data.
> 
decide
> that it's not worth it), maybe "(The only algorithm and message-type
> > > > Where is this sub-partitioning of the -1 to -65536 range
> > > > specified, that any given algorithm will only assign "critical"
> > > > header parameters in the
> > > > -1 to -128 range?  If it's just convention I don't think the
> > > > declarative language
> > > ("can be omitted") is appropriate.
> > > The assumption is that purely optional items might be placed farther
> > > out in the range and thus need to be placed in the "crit" attribute.
> > > This is just a restriction, similar to the 0-7 range of things that
can be
> omitted.
> > >
> > > I agree that it's just a restriction, but the way it's written right
> > > now it feels like the core spec is making statements about what you
> > > should assume to be the case for algorithm-dependent values, without
> > > actually placing a requirement on the algorithm specifications to
> > > provide that property.  If we said that algorithm specs can impose a
> > > similar requirement on which values are required to implement and
> > > thus safe to omit, and suggested the range of -1 to -
> > > 128 for those values, I wouldn't have a problem, since that makes it
> > > clear that it's a property of the algorithm in question.
> >
> > Integer labels in the range -1 to -128 can be omitted.   Algorithms can
assign
> labels in this range where the ability to process the content of the label
is
> considered to be core to implementing the algorithm.  Algorithms can
assign
> labels outside of this range where the ability to process the content of
the label
> is not considered to be core, but needs to be understood to correctly
process
> this instance.  Integer labels in the range -129 to -65536
> <bcp14>SHOULD</bcp14> be included as these would be less common header
> parameters that might not be generally supported.
> 

My problem with a MUST is that I don't know what it means to be "core to
implementing".  I think that is too vague to make the MUST useful.

> > > I thought the COSE_Sign structure contained one or more
> > > COSE_Signature structures.
> >
> > Yes it does.  I think of the "signature" as the byte string as being
different
> from the COSE_Signature structure.  This is referring to the first.
> 
intended
> the "directly carries" sense of the term.  Maybe we should leave a note to
ask
> the RFC Editor for help; I'm failing to come up with a good wording right
now.
I am sure they will love me for this.

> > > > nit(?): it's the "size of the payload" *in the encoded COSE_Sign*
> > > > object that is
> > > reduced, right?
> > > I'm having trouble parsing that -- it feels circular to me.  "In the
> > > act of signing, the size of the payload you are signing is reduced
> > > by the number of bytes that will be recovered."  So what's the
> > > payload, the longer thing or the shorter thing?
> >
> > [JLS] The payload that is encrypted is the longer thing.  The payload
that is
> carried in the COSE message is the shorter thing.
> 
[JLS] Not a big issue - added "original" and "transmitted" as appropriate.

> > > Oops, the referred-to question was "Am I reading this right that the
> > > idea is to use capabilities to lock a key down to a single curve?"
> > [JLS] Capabilities are not used to lock a key down to a single curve.
The curve
> is a field in the COSE_Key object.
> 
> > > a PBKDF construction, not PBES (which provides an abstract API for
> > > password- based encryption that uses PBKDF1 under the covers)?
> > > My main complaint here is that there's a "type error" -- PBES2 is
> > > not a KDF (right?).  I could tolerate dropping the last sentence
> > > entirely, or a bland "Specific KDF constructions are needed to be
> > > safely used with non-random secrets" (and no reference), but pointing
to
> Argon2 would also be fine.
> > [JLS] Switched.
> >
> > >
> > > > Section 9.5.1
> > > >
> > > self- explanatory and obvious?
> > [JLS] I think that it is obvious.  I also think something like "password
hint"
> would be as well, but is not currently defined.
> 
> Okay.
> 
> > > > Section 15.1
> > > >
> > > informational RFC when published (given the current intended
> > > directly in to the downref registry is probably a good idea so that
> > > protocol documents can make algorithms MUST.
> > >
> > > I think we had someone (Barry?) mention on the telechat that we
> > > might not need to put it in the registry since it was unclear who
> > > else would need to reference it.  So, thanks for stating a position
> > > -- I trust that the responsible AD will do the right thing.
> > >
> > > > Appendix A
> > > >
> > > algorithm to use other than "implicit by key with each key limited
> > > to one algorithm" has some risk of allowing an attacker's input to
> > > cause the key holder to perform some operation using that key but
> > > with the "wrong" algorithm.  I think that if the externally visible
> > > results of that operation are indistinguishable from "the input was
> > > ignored", that does not give the attacker a channel by which to
> > > attack the key, but I'm not 100% sure.  Even an application-layer
"rejected
> due to bad input"
> > > key one algorithm" rule although in an offline way.  At least for
> > > OSCORE, there would not be a way to distinguish between any of the "it
did
> not decrypt" cases.
> > >
> > > Sigh.  I wonder if I can convince any cryptographers to look at the
> > > group communication document.
> >
> > [JLS] That is not where I would put the limited resources.  I would have
them
> look at draft-ietf-lwig-curve-representations and ask if there are issues
using
> the same private key for an EdDSA signature and ECDH after doing the
> mapping.  I think I recently saw something on the CFRG list which had a
pointer
> to a paper saying that reuse for ECDH and ECDSA was ok.
> 
> Fair enough.
> 
> Thanks, as always,
> 
> Ben

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 16 Jun 2020 22:06:26 -0700

> I think this is everything except for you discuss-discuss.

Perhaps we should put it on the next telechat as a returning item to get
some full-IESG time.  (IIUC it needs another person balloting to hit the
2/3 criterion anyway, even after Roman and I clear.)

-Ben

---

From: DESPERRIER Jean-Marc <[email-masked]>
Date: Thu, 18 Jun 2020 17:22:29 +0000

Hi,

Sorry this is a comment coming very late, but I'm afraid I have identified a very serious issue with counter signatures that I wish to rise here as it seems to me to be important.
I would be really happy to be totally wrong about it, but that would require a very deep misunderstanding about them that would in any case require some clarifications in the text.

I have seen this actually some weeks ago, but until now some of the text about countersignatures got me so confused I wasn't sure I didn't wrongly interpret major parts of it.

So here's my reading step by step of the specifications about countersignature, and why I have an issue with it of a contradiction between what it says is intended to and what is really achieved, and also for me deep unclarity about what the payload of a countersignature consists of :

---------
3.1.  Common COSE Header Parameters
      The counter signature header
      parameter can occur as an unprotected attribute in any of the
      following structures: COSE_Sign1, COSE_Signature, COSE_Encrypt,
      COSE_recipient, COSE_Encrypt0, COSE_Mac, and COSE_Mac0. These
      structures all have the same beginning elements, so that a
      consistent calculation of the counter signature can be computed.
      Details on counter signatures are found in Section 5

Nonetheless, they are differences between those formats that at least impact the payload, and the text doesn't clarify explicitly how they impact counter-signatures

---------
5.  Counter Signatures

   A counter signature is normally defined as a second signature that
   confirms a primary signature.  A normal example of a counter
   signature is the signature that a notary public places on a document
   as witnessing that you have signed the document.  Thus applying a
   counter signature to either the COSE_Signature or COSE_Sign1 objects
   match this traditional definition.

This will only be true if the payload of the counter signature incorporates the byte string representing the primary signature value.
If this not the case for COSE counter signature, this text MUST be removed and clarification otherwise MUST be brought to the standard.
The use of the term counter signature will then be misleading, and should be considered to be removed.

   When done on a COSE_Signature, the normal counter signature semantics
   are preserved.  That is the counter signature makes a statement about
   the existence of a signature and, when used as a timestamp, a time
   point at which the signature exists

This will only be true if the payload of the counter signature incorporates the byte string representing the primary signature value.
If this not the case for COSE counter signature, this text MUST be removed and clarification otherwise MUST be brought to the standard.
The use of the term counter signature will then be misleading, and should be considered to be removed.

   When done on a COSE_Mac or a
   COSE_Mac0, one effectively upgrades the MAC operation to a signature
   operation.  

This will be true even when the payload of the counter signature only incorporates the mac 'payload', and not its 'tag'.

   When done on a COSE_Encrypt or COSE_Encrypt0, the
   existence of the encrypted data is attested to.

This will be true even when only 'ciphertext' is included in the countersignature payload.

---------
5.1.  Full Counter Signatures
    The process of creating and validating abbreviated
   counter signatures is defined in Section 4.4.

1) abbreviated here seems be a typo 

2) The process in Section 4.4 doesn't specify explicitly how to populate the payload element of the Sig_structure in the case of a counter signature
Clarification about that is absolutely required either here in section 5.1 or in section 4.4

---------
4.4.  Signing and Verification Process
   5.  The payload to be signed encoded in a bstr type.  The payload is
       placed here independent of how it is transported.

1) For counter signature of a signature, the simplest interpretation of this text is that the payload is the 'payload' element of the initial signature.
They are however major issues if interpreted like that.
If I have read its source correctly, the COSE-JAVA implementation does do counter-signatures of signatures this way.

If this is what's intended, then COSE counter signatures aren't counter signatures in the classical meaning, they are in fact basically fully equivalent to cosignatures, given that what they include is only the primary payload, and doesn't include the primary signature.
So all text suggesting otherwise should be removed from the standard.
New text should be added to make it extremely clear that those signatures can't function as actual counter-signatures. 
I would actually be in favor of removing use of the term counter-signature given how misleading it would be then.

If the intent is for counter signature in this standard to be real counter signatures, then an explicit clarification is required about how 'payload' is populated.
The simplest solution is probably to say that it includes all of the primary signature structure, except that all of the 'unprotected' headers shall be removed first (there would be recursion problems otherwise)
This specifically solves the issue of specifying which of the initial signature is countersigned in case they are multiple signers. 
Solution to include less of the initial structure in the counter signature seem to be more complex, and would need anyway to include all of the initial signers, except if designing a way to specify only one of them
(maybe when the counter signature is inserted inside the 'unprotected' element of his specific signature ?).

2) For counter signature of a mac, the simplest interpretation of this text is that the payload is the 'payload' element of the initial signature and 'tag' isn't included in the countersignature. 
There's not a major issue if interpreted like that, as I didn't see a claim that this would contradict.

3) For encrypted content, the simplest interpretation of this text is that the payload is the 'ciphertext' element .
There's not a major issue if interpreted like that, nonetheless it would be made clearer by specifying it explicitly

---------
5.2.  Abbreviated Counter Signatures
   Instead, the parameters for computing or verifying the
   abbreviated counter signature are inferred from the same context used
   to describe the encryption, signature, or MAC processing

1) This appears to mean that if a signature with a single signer is counter-signed this way, the content + the protected headers + the signer are the same as the initial signature ?
    If so, it doesn't seem to have much value, since it resigns exactly the same thing (except the signer protected header if applicable), so it should be made even more explicit
If they are multiple signers of the initial signature, is it intended that the signer must be the first of the list ?
For mac and encryption, it's unclear how the signer public key will be identified, as we have only the information for the mac/encryption key.

If what is actually intended that the identification of the counter-signer is through an out-of-band mechanism and doesn't need to have a relation with the counter signed element signature, encryption or mac, this should be specified.

2) To function as an actual counter-signature for signatures, the same issue with the payload is present as for full counter signatures

3) There is no sample of an abbreviated counter signature
---------------

---

From: Jim Schaad <[email-masked]>
Date: Sat, 27 Jun 2020 16:21:08 -0700

Jean-Marc,

I think that you have a deep misunderstanding about this and we need to find what the text is that is both confusing and how to get clarifications.

> From: DESPERRIER Jean-Marc <[email-masked]>
> Sent: Thursday, June 18, 2020 10:22 AM
> To: Jim Schaad <[email-masked]>; 'Benjamin Kaduk' <[email-masked]>
> Cc: [email-masked]; [email-masked]; 'Matthew
> Subject: RE: [COSE] Benjamin Kaduk's Discuss on draft-ietf-cose-rfc8152bis-
> Sorry this is a comment coming very late, but I'm afraid I have identified a very
> serious issue with counter signatures that I wish to rise here as it seems to me
> to be important.
> I would be really happy to be totally wrong about it, but that would require a
> very deep misunderstanding about them that would in any case require some
> clarifications in the text.
> 
> I have seen this actually some weeks ago, but until now some of the text about
> countersignatures got me so confused I wasn't sure I didn't wrongly interpret
> major parts of it.
> 
> So here's my reading step by step of the specifications about countersignature,
> and why I have an issue with it of a contradiction between what it says is
> intended to and what is really achieved, and also for me deep unclarity about
> what the payload of a countersignature consists of :
> 
> ---------
> Nonetheless, they are differences between those formats that at least impact
> the payload, and the text doesn't clarify explicitly how they impact counter-
> signatures

So the first three elements are:
* Protected headers
* Unprotected headers
* Payload of the object

In section 5 there is text which says "that the countersignature operation needs to be treated as a separate operation from the initial operation".  The purpose of this text was to state that all of the cryptographic operations on the target of the countersignature need to be completed prior to starting the countersignature operation.  This means that looking at that array of items above there is a binary string, a map, and a binary string.  The countersignature operation is totally agnostic to how that last byte string is created.  It has to be or else a third party would not be able to apply a countersignature.

> This will only be true if the payload of the counter signature incorporates the
> byte string representing the primary signature value.
> If this not the case for COSE counter signature, this text MUST be removed and
> clarification otherwise MUST be brought to the standard.

[JLS] As noted above that is exactly what the payload is

> This will only be true if the payload of the counter signature incorporates the
> byte string representing the primary signature value.
> If this not the case for COSE counter signature, this text MUST be removed and
> clarification otherwise MUST be brought to the standard.

[JLS] As noted above, this is true for applying to a COSE_Signature.

> This will be true even when the payload of the counter signature only
> incorporates the mac 'payload', and not its 'tag'.

[JLS] As noted above, only the first three elements of the COSE_Mac and COSE_Mac0 structures are used when computing the countersignature.  This means that the tag, which is the fourth element is not included.

> This will be true even when only 'ciphertext' is included in the countersignature
[JLS] As noted above, the ciphertext is what is used.

> 1) abbreviated here seems be a typo
[JLS] My dictionary tells me that this is correctly spelt.

> 
> 2) The process in Section 4.4 doesn't specify explicitly how to populate the
> payload element of the Sig_structure in the case of a counter signature

[JLS]  I will add clarification in the text that the COSE_Signature structure is what is referred to when it says that the details of the fields of a countersignature are found in section 4.1.

> 1) For counter signature of a signature, the simplest interpretation of this text
> is that the payload is the 'payload' element of the initial signature.
> If I have read its source correctly, the COSE-JAVA implementation does do
> counter-signatures of signatures this way.
> 
> If this is what's intended, then COSE counter signatures aren't counter
> signatures in the classical meaning, they are in fact basically fully equivalent to
> cosignatures, given that what they include is only the primary payload, and
> doesn't include the primary signature.
> New text should be added to make it extremely clear that those signatures
> can't function as actual counter-signatures.
> If the intent is for counter signature in this standard to be real counter
> signatures, then an explicit clarification is required about how 'payload' is
> populated.
> The simplest solution is probably to say that it includes all of the primary
> signature structure, except that all of the 'unprotected' headers shall be
> removed first (there would be recursion problems otherwise) This specifically
> solves the issue of specifying which of the initial signature is countersigned in
> case they are multiple signers.
> Solution to include less of the initial structure in the counter signature seem to
> be more complex, and would need anyway to include all of the initial signers,
> except if designing a way to specify only one of them (maybe when the counter
> signature is inserted inside the 'unprotected' element of his specific signature
> ?).

[JLS] Yes I can see how this is confusing.  I will add a paragraph on how to determine what the payload is for a countersignature operation.

> 
> 2) For counter signature of a mac, the simplest interpretation of this text is that
> the payload is the 'payload' element of the initial signature and 'tag' isn't
> included in the countersignature.
> 1) This appears to mean that if a signature with a single signer is counter-
> signed this way, the content + the protected headers + the signer are the same
> as the initial signature ?
>     If so, it doesn't seem to have much value, since it resigns exactly the same
> thing (except the signer protected header if applicable), so it should be made
> even more explicit If they are multiple signers of the initial signature, is it
> intended that the signer must be the first of the list ?
> For mac and encryption, it's unclear how the signer public key will be
> identified, as we have only the information for the mac/encryption key.
> 
> If what is actually intended that the identification of the counter-signer is
> through an out-of-band mechanism and doesn't need to have a relation with
> the counter signed element signature, encryption or mac, this should be
> specified.

[JLS] I will start by saying that I have never liked the abbreviated countersignature, but it is useful in some circumstances.  The easiest document to look at where both an encryption key and signature key are associated draft-ietf-core-oscore-groupcomm.  In this case while each person in the group has a unique key, that key is also known by everybody else in the group so that key cannot be used for the purpose of determining who encrypted and sent the message.  This information is added by the addition of an abbreviated countersignature to the end of the encrypted message.  This, combined with a large amount of externally supplied authenticated data to both the encryption and signature process, allows for proper identification of the entity which sent the message.  There is only one set of key identification material however and that is to identify the encryption key which was used.  The same identifiers used for the encryption key can then be used to figure out which signature key(s) would make sense to check.

[JLS]  In the case that you suggested above, that of an abbreviated countersignature on a signature, when you went to retrieve the key information on the signing key, I would expect that you would get back an array of two signing keys.  The first for the signature and the second for the countersignature.  I would really wonder at a case where this is being done however.  Why are you sufficiently worried about size that you are using an abbreviated countersignature in this situation, but you are not just going to replace the original signature with one of your own.

> 
> 2) To function as an actual counter-signature for signatures, the same issue
> with the payload is present as for full counter signatures
> 

[JLS] I have these and can put one or two into the appendixes.

Jim