[Ballot comment]
Mostly just nits left, though the lingering errata report and the IANA
updates seem somewhat significant.  (It would probably be fine to leave
the nits for the RFC Editor.)

It seems that https://www.rfc-editor.org/errata/eid5066 needs to be
incorporated still (and the report verified, presuming it is correct).

Section 1

  providing security services.  The use of COSE, like JOSE and CMS, is
  only for use in store and forward or offline protocols.  The use of

nit: we probably can just start the sentence with "COSE", since the "use in"
has moved to later in the sentence.

  additional data fields as part of the structure.  A one such
  application-specific element would be to include a URI or other

nit: s/A one/One/.

Section 1.5

  The presence a label that is neither a a text string or an integer,

nit: s/a a/a/

Section 2

  layer.  The content layer contains the plaintext is encrypted and
  information about the encrypted message.  The recipient layer contins

nit: s/plaintext is encrypted/encrypted plaintext/ (or similar?)

  the content encryption key (CEK) is encrypted and information about
  how it is encrypted for each recipient.  A single layer version of

nit: s/content encryption key (CEK) is encrypted/encrypted content encryption
key (CEK)/.

Section 4.1

  parameter.  An examples of a header parameter about the signature

nit: s/An examples/An example/

      Note: When a signature with a message recovery algorithm is used
      (Section 8.1), the maximum number of bytes that can be recovered
      is the length of the original payload.  The size of the encoded
      payload is reduced by the number of bytes that will be recovered.
      If all of the bytes of the original payload are consumed, then the
      transmitted payload is encoded as a zero-length byte string rather
      than as being absent.

I guess this is where the difficulty that Jim mentioned comes in -- the
signature recovery scheme gives you the intended recovered content but also
some of the other framing and such that was added as input to the signature
algorithm, and you have to properly figure out where the end of the actual
payload is.  (I'm not sure whether it would be useful to try to have text
about the issue in this location, though.)

Section 8.1

  consume the same bytes of message content.  This means that the
  mixing of the signature with message recovery and signature with
  appendix schemes in a single message is not supported, and if a
  recovery signature scheme is used.

nit: this sentence just trails off ....  I think it would be okay to just end
the sentence after "is not supported", since we covered the "must recover the
same [number of] bytes" previously.

  integrating message recovery signature algorithms.  The first
  algorithm defined is going to need to make decisions about these
  issues and those decisions re likely to be binding on any further
  algorithms defined.

nit: s/ re / are /

  Some of the issue2 that have already been identified are:

nit: s/issue2/issues/

Section 8.5.2, 8.5.3, 8.5.4, 8.5.5

I see that a bunch of things were changed from COSE_Encrypt to COSE_Recipient,
apparently prompted by my earlier review.  I would feel more comfortable if
someone confirmed that each change is correct, as I have lost some of the
context here.

Section 10

      comparable for the desired security functionality.  Additional
      guidence can be found in [BCP201].

nit: s/guidence/guidance/

Section 11

We lost the section about the "CBOR Tags" registry (where we were previously
allocating a codepoint for COSE_Signature).  I think we need to bring back a
stub section with the directive to update the references from 8152 to this
document.

[Noting here for convenience that as of the -12 of -algs, the Header Algorithm
Parameters registry has not been added as a target for reference updates; it
still needs to be listed there.]

Acknowledgments

nit: Göran's name doesn't seem to have made it through some step of the
process (eve in the native HTML output).

# Summary

The document draft-ietf-rfc8152bis-struct is an update to CBOR Object Signing and Encryption (COSE) to addressing outstanding errata, make other clarifications and fixes, and move it to Internet Standard.  This is part of a set — this for the structure and process, the other detailing the algorithms — that together obsolete RFC 8152.

This work is a product of the COSE Working Group.  The document shepherd is Matthew Miller, and the responsible Area Director is Benjamin Kaduk.

# Review and Consensus

This document received wide review from various implementers, including those used in real-world deployments.  There were a number of editorial comments and some substantive commentary, with consensus to publish.

After a flaw was found in countersignatures during the IETF last call in June, the working group consensus was to deprecate the coutersignature in 8152 and work on a replacement as a stand-alone document.  Therefore, this document still contains an informational reference to the RFC 8152 to point to the countersignature algorithm, and otherwise removed the text from this document to be replaced with a description and rationale for the deprecation.

The working group consensus was to keep the context string "COSE_Countersign1" for abbreviated countersignatures (used as part of the input when generating the countersignature).  Technically this structure should be "0" as all information about the input is implied (no signatory is explicitly declared), however this is a breaking change that the working group could not find consensus to risk in order to maintain full consistency.

Some concerns were raised about message recovery signature algorithms, but since none are yet defined, the section on signing was updated to discuss concerns a future message-recovery-capable algorithm needs to address.

Additional care during editing and review of this document and draft-ietf-cose-rfc8152bis-algs were taken to ensure as best as possible that various (internal) references made in the original RFC 8152 have proper (external) references.  All errata from RFC 8152 that is relevant to the COSE structure has been addressed therein.

# References

The CryptoForum Research Group (CFRG) published algorithm documents as Informational; the normative reference to 8032 (EdDSA) is expected and exists in the Downref Registry.  The informative references to RFC 2633 (obsoleted by 3855) and RFC 5750 (obsoleted by 8551) are intentional as they illustrate some of the original design considerations for RFC 8152.

This document and draft-ietf-cose-rfc8152bis-algs are to be published in lockstep, and so references here to -algs (and references to this document in -algs) are expected to be updated as part of publication.

# Intellectual Property

The author, to the best of his knowledge, is unaware of any applicable IPR.  There are no substantive changes compared to RFC 8152, which also has no IPR notices submitted.

[Ballot discuss]
Sorry for the late discuss, however rather than deferring the review two weeks we agreed that I would do a later review.

This relates to the registries created in RFC 8152. These registries do exist, however the registry rules will not be documented in the replacement standards track document that is in force. And if you look at the IANA page for the COSE regsistries (https://www.iana.org/assignments/cose/cose.xhtml#algorithms), they simply reference back to RFC 8152 which after approval of this document will be an obsoleted RFC.

Thus, I am of the opinion that the rules for expert review and other registration rules for an IETF created registry should exist in an current in force RFC that is referenced by the registry. Thus, I would propose that the registration rule texts from Section 16 in RFC 8152 is included in Section 12 of this document and also request the IANA to update the registry references to point to the new document.

[Ballot comment]
In the interests of brevity, my review focused on the diff between this document and RFC 8152.

Major points:

I agree with Benjamin's concern that we seem to be leaving the Designated Experts for the IANA registries described here with advice in RFC 8152, which this document renders obsolete.  I think that prose should be copied to this document so that it lives someplace current.  I was originally tempted to DISCUSS this but I'm hesitating, so I'll just say I hope this is resolved appropriately.

Some nits:

Section 1:
* "... structure for the CBOR objects which are ..." -- s/which/that/
* "... or offline protocols, different solutions ..." -- "different" should start a new sentence
* "Any application which uses COSE for security ..." -- s/which/that/

Section 5:
* The last sentence in the first paragraph:
OLD:
  It needs to be noted that the counter
  signature needs to be treated as a separate operation from the
  initial operation even if it is applied by the same user as is done
  in [I-D.ietf-core-groupcomm-bis].
NEW:
  It needs to be noted that the counter
  signature is to be treated as a separate operation from the
  initial operation, even if it is applied by the same user, as is done
  in [I-D.ietf-core-groupcomm-bis].
* "This is same structure ..." -- s/same/the same/
* "That is the counter signature ..." -- comma after "is"
* "... existence of the encrypted data is attested to." -- maybe "asserted" instead of "attested to"?

Section 9:
* "New algorithms will be created which will not fit ..." -- s/which/that/

Section 9.5.5:
* In the final bullet, why aren't these MUSTs?  Or in the alternative, when would one legitimately deviate from those SHOULDs?

[Ballot comment]
Thank you for the work put into this document. I really appreciate the section 1 with the detailed and clear introduction.

My current workload prevented me to do a deep review, I will then rely mainly on the other Area Directors.

-éric

[Ballot comment]
Due to the size of this document and my current workload, I won't be able to submit my ballot before the 6/11 telechat, but I wanted to mention for the record that Benjamin's comment about the IANA Expert Review procedures being obsoleted seems DISCUSS-worthy to me.

[Ballot comment]
[[ nits ]]

[ section 1.6 ]

* "authentication check of the contents algorithm" ->
  "authentication check of the contents" ?

  How should I read this sentence about AE?  It seems to be copied from 8152,
  but I kinda feel like the 3rd (last) use of the word "algorithm" could be
  removed?

[ section 2 ]

* Table 1, CBOR tag 17: "COSE Mac w/o" -> "COSE MAC w/o"

[ section 5 ]

* "This is same" -> "This is the same"

* "That is the counter signature..." -> "That is, the counter signature..."

[ section 5.1 ]

* Isn't #6.98 for COSE_Sign_Tagged?  I think the CDDL fragment needs to fixed
  temporarily to:

    COSE_CounterSignature_Tagged = #TBD0(COSE_CounterSignature)

[ section 7 ]

* "of other than direct" -> "if other than direct"?

[ section 7.3 ]

* #2: "COSE_MAC" -> "COSE_Mac"?

[ section 9 ]

* "this new algorithms" -> "these new algorithms"

[ section 9.5.2 ]

* "the key from next layer down" -> "the key from the next layer down"

[Ballot 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.

[Ballot 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.

[Ballot comment]
I've only reviewed the diffs, not the historical approved text.  Everything looks okay to me.  A few minor comments/nits:

Comment:

1.4.  CBOR Grammar

  The CDDL grammar is informational; the prose description is normative.

I'm not familiar with the CDDL grammar, and specifically whether there is any tooling that can use the grammar to generate structures/etc.  If there is, then I think that it would be helpful if the CDDL grammar was also normative, in the sense that readers of the spec should be able to assume that the CDDL is correct.  I would still be okay with a statement that says that if there is any ambiguity between the two then the prose description should be taken as being definitive.
 
Nits:

1.5.  CBOR-Related Terminology
 
  The presence in a CBOR map of a label that is not a text string or an integer is an error.

This sentence was changed from the original formulation, but I find it slightly clunky.  Perhaps:

The presence of a label, that is neither a text string nor an integer, in a CBOR map, is an error.

9.  Taxonomy of Algorithms used by COSE

  In this section, a taxonomy of the different algorithm types that can
  be used in COSE is laid out.  This taxonomy should not be considered
  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 -> these

Regards,
Rob

[Ballot discuss]
Are the wrong data structures being referenced or did I misunderstand something?

** Section 5.  Per “Abbreviated counter signatures use the structure COSE_Countersign1”, this doesn’t seem consistent with the more detailed write-up in Section 5.2 which says that “The byte string representing the signature value is placed in the CounterSignature0 attribute”.  The document makes no other reference to COSE_Countersign1. 

The shepherd write-up notes that ‘one item to note is the decision to keep the context string "COSE_Countersign1" for abbreviated countersignatures’.  However, I found no such reference in Step 1 of Section 4.4 (page 22) which enumerated the possible strings.

** What is the intended name of the structure for the Counter Signature -- is it COSE_Countersignature or COSE_Countersign?

-- Table 1, Section 2, Section 4.4 and Section 5.1 (to include the CDDL) reference COSE_Countersignature

but
-- Section 5. Per “Full counter signatures use the structure COSE_Countersign …”

-- Section 5.1.  Per “A tagged COSE_Countersign structure …”

[Ballot comment]
Thanks for making an easy to read and compare bis document.

** Section 4.4.  Per the the following item in the list, ‘"CounterSignature" for signatures used as counter signature attributes.’, can this be more precisely stated as to reference the particular COSE_* data type?  The other items in this list are more precise in naming the corresponding structure/attributes.

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-cose-rfc8152bis-struct-09. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator has a question about one of the actions requested in the IANA Considerations section of this document.

The IANA Functions Operator understands that, upon approval of this document, there are eight actions which we must complete.

First, in the CBOR Tags registry on the Concise Binary Object Representation (CBOR) Tags registry page located at:

https://www.iana.org/assignments/cbor-tags/

the six tags that have references that point to [RFC8152] will have those references changed to [ RFC-to-be ]. These are tags 16, 17, 18, 96, 97, and 98.

Second, also in the CBOR Tags registry on the Concise Binary Object Representation (CBOR) Tags registry page located at:

https://www.iana.org/assignments/cbor-tags/

a single, new registration will be made as follows:

Tag: [ TBD-at-Registration ]
Data Item: COSE_Signature
Semantics: COSE standalone counter signature
Reference: [ RFC-to-be ]

--> IANA Question: which of the available ranges for CBOR tags should this new registration come from?

Third, in the COSE Header Parameters registry on the CBOR Object Signing and Encryption (COSE) registry page located at:

https://www.iana.org/assignments/cose/

the references that point to [RFC8152] will be updated to point to [ RFC-to-be ]. IANA understands that the registration policy for the registry [RFC8126] is not to change. The IANA Matrix entry for this registry will also be updated to point to [ RFC-to-be ].

Fourth, in the COSE Header Algorithm Parameters registry also on the CBOR Object Signing and Encryption (COSE) registry page located at:

https://www.iana.org/assignments/cose/

the references that point to [RFC8152] will be updated to point to [ RFC-to-be ]. IANA understands that the registration policy for the registry [RFC8126] is not to change. The IANA Matrix entry for this registry will also be updated to point to [ RFC-to-be ].

Fifth, in the COSE Key Common Parameters registry also on the CBOR Object Signing and Encryption (COSE) registry page located at:

https://www.iana.org/assignments/cose/

the references that point to [RFC8152] will be updated to point to [ RFC-to-be ]. IANA understands that the registration policy for the registry [RFC8126] is not to change. The IANA Matrix entry for this registry will also be updated to point to [ RFC-to-be ].

Sixth, section 12.5.1 of the current document proposes registration of the following Media Type:

application/cose

IANA Question --> is the text of section 12.5.1 intended to update the existing registration (from [RFC8152])in the application registry of the Media Type registry page?

Seventh, section 12.5.2 of the current document proposes registration of the following Media Types:

application/cose-key
application/cose-key-set

IANA Question --> is the text of section 12.5.12 intended to update the existing registrations (from [RFC8152])in the application registry of the Media Type registry page?

Eighth, in the CoAP Content-Formats on the Constrained RESTful Environments (CoRE) Parameters registry page located at:

https://www.iana.org/assignments/core-parameters/

Registrations in this registry that have a reference of [RFC8152] will be changed to having a reference of [ RFC-to-be ].

The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2020-05-29):

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
CC: Matthew Miller <linuxwolf+ietf@outer-planes.net>, cose@ietf.org, barryleiba@gmail.com, draft-ietf-cose-rfc8152bis-struct@ietf.org, cose-chairs@ietf.org, linuxwolf+ietf@outer-planes.net
Reply-To: last-call@ietf.org
Sender: <iesg-secretary@ietf.org>
Subject: Last Call: <draft-ietf-cose-rfc8152bis-struct-09.txt> (CBOR Object Signing and Encryption (COSE): Structures and Process) to Internet Standard


The IESG has received a request from the CBOR Object Signing and Encryption
WG (cose) to consider the following document: - 'CBOR Object Signing and
Encryption (COSE): Structures and Process'
  <draft-ietf-cose-rfc8152bis-struct-09.txt> as Internet Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2020-05-29. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  Concise Binary Object Representation (CBOR) is a data format designed
  for small code size and small message size.  There is a need for the
  ability to have basic security services defined for this data format.
  This document defines the CBOR Object Signing and Encryption (COSE)
  protocol.  This specification describes how to create and process
  signatures, message authentication codes, and encryption using CBOR
  for serialization.  This specification additionally describes how to
  represent cryptographic keys using CBOR.

  This document along with [I-D.ietf-cose-rfc8152bis-algs] obsoletes
  RFC8152.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-cose-rfc8152bis-struct/



No IPR declarations have been submitted directly on this I-D.


The document contains these normative downward references.
See RFC 3967 for additional information:
    draft-ietf-cose-rfc8152bis-algs: CBOR Object Signing and Encryption (COSE): Initial Algorithms (None - IETF stream)
    rfc7049: Concise Binary Object Representation (CBOR) (Proposed Standard - IETF stream)

# Summary

The document draft-ietf-rfc8152bis-struct is an update to CBOR Object Signing and Encryption (COSE) to addressing outstanding errata, make other clarifications and fixes, and move it to Internet Standard.  This is part of a set — this for the structure and process, the other detailing the algorithms — that together obsolete RFC 8152.

This work is a product of the COSE Working Group.  The document shepherd is Matthew Miller, and the responsible Area Director is Benjamin Kaduk.

# Review and Consensus

This document received wide review from various implementers, including those used in real-world deployments.  There were a number of editorial comments and some substantive commentary, with consensus to publish.

One item to note is the decision to keep the context string "COSE_Countersign1" for abbreviated countersignatures (used as part of the input when generating the countersignature).  Technically this structure should be "0" as all information about the input is implied (no signatory is explicitly declared), however this is a breaking change that the working group could not find consensus to risk in order to maintain full consistency.

Additional care during editing and review of this document and draft-ietf-cose-rfc8152bis-algs were taken to ensure as best as possible that various (internal) references made in the original RFC 8152 have proper (external) references.  All errata from RFC 8152 that is relevant to the COSE structure has been addressed therein.

# References

The CryptoForum Research Group (CFRG) published algorithm documents as Informational; the normative reference to 8032 (EdDSA) is expected and exists in the Downref Registry.  The informative references to RFC 2633 (obsoleted by 3855) and RFC 5750 (obsoleted by 8551) are intentional as they illustrate some of the original design considerations for RFC 8152.

This document and draft-ietf-cose-rfc8152bis-algs are to be published in lockstep, and so references here to -algs (and references to this document in -algs) are expected to be updated as part of publication.

# Intellectual Property

The author, to the best of his knowledge, is unaware of any applicable IPR.  There are no substantive changes compared to RFC 8152, which also has no IPR notices submitted.

# Summary

The document draft-ietf-rfc8152bis-struct is an update to CBOR Object Signing and Encryption (COSE) to addressing outstanding errata, make other clarifications and fixes, and move it to Internet Standard.  This is part of a set — this for the structure and process, the other detailing the algorithms — that together obsolete RFC 8152.

This work is a product of the COSE Working Group.  The document shepherd is Matthew Miller, and the responsible Area Director is Benjamin Kaduk.

# Review and Consensus

This document received wide review from various implementers, including those used in real-world deployments.  There were a number of editorial comments and some substantive commentary, with consensus to publish.

One item to note is the decision to keep the context string "COSE_Countersign1" for abbreviated countersignatures (used as part of the input when generating the countersignature).  Technically this structure should be "0" as all information about the input is implied (no signatory is explicitly declared), however this is a breaking change that the working group could not find consensus to risk in order to maintain full consistency.

Additional care during editing and review of this document and draft-ietf-cose-rfc8152bis-algs were taken to ensure as best as possible that various (internal) references made in the original RFC 8152 have proper (external) references.  All errata from RFC 8152 that is relevant to the COSE structure has been addressed therein.

# References

The CryptoForum Research Group (CFRG) published algorithm documents as Informational; the normative reference to 8032 (EdDSA) is expected and exists in the Downref Registry.  The informative references to RFC 2633 (obsoleted by 3855) and RFC 5750 (obsoleted by 8551) are intentional as they illustrate some of the original design considerations for RFC 8152.

This document and draft-ietf-cose-rfc8152bis-algs are to be published in lockstep, and so references here to -algs (and references to this document in -algs) are expected to be updated as part of publication.

# Intellectual Property

The author, to the best of his knowledge, is unaware of any applicable IPR.  There are no substantive changes compared to RFC 8152, which also has no IPR notices submitted.