CBOR Object Signing and Encryption (COSE)
draft-ietf-cose-msg-24

[Ballot comment]

Thanks all for the discussion and resolution of the mandatory
alg-id issue. I think we've ended up in a better place. (Well, I at
least hope so:-).

While I'm clearing the discuss now, it might be no harm to just
check with the set of folks who commented recently on this topic
before sending this to the RFC editor in case there're any other
non-problematic tweaks that might be beneficial. (I forget if
that was already done or not, sorry;-)

[Ballot comment]
Thank you for addressing my earlier comments. I have one small issue that resulted in a recent change:

This is a well written document, despite its length. Thank you for that.

Some specific comments:

content type:  This parameter is used to indicate the content type of
      the data in the payload or cipher text fields.  Integers are from
      the "CoAP Content-Formats" IANA registry table [COAP.Formats].
      Text values following the syntax of Content-Type defined in
      Section 4.2 of [RFC6838] omitting the prefix string "Content-
      Type:".

This is not quite right, as Section 4.2 of [RFC6838] doesn't define Content-Type header field. It defines:

    type-name = restricted-name
    subtype-name = restricted-name

    restricted-name = restricted-name-first *126restricted-name-chars
    restricted-name-first  = ALPHA / DIGIT
    restricted-name-chars  = ALPHA / DIGIT / "!" / "#" /
                              "$" / "&" / "-" / "^" / "_"
    restricted-name-chars =/ "." ; Characters before first dot always
                                  ; specify a facet name
    restricted-name-chars =/ "+" ; Characters after last plus always
                                  ; specify a structured syntax suffix

So you should say something like this instead:

      Text values following the syntax "/",
      where  and  are defined in
      Section 4.2 of [RFC6838].

[Ballot discuss]

Thanks for the updates in -20. I think we've only the following points
left. Note that all of those are questions to the WG chairs and not to Jim.

  (2) 3.1, alg: so you're disallowing a setup where the kid
  alone identifies the key and algorithm to the recipient?
  That is used in some IETF protocols (OSPF iirc) so rhat's a
  pity, and will in those (maybe less common) cases consume a
  few bytes that could otherwise be saved.  I think, but am not
  sure, that the WG already discussed this, but if not, maybe
  worth a thought? (Or even a 2nd thought:-) And appendix A.1
  is really puzzling - as it provides instructions for how to
  not follow a MUST in the body of the document.

I think we left the mail thread on this with you saying "Best
to ask the chairs if they agree that this is WG consensus," as
you're an admitteddly strong partisan on this topic.

So, COSE chairs - what's your take? (If you say this is ok with
the WG, I'll clear.)

  (6) section 10: why MUST the kty values be present always?
  That seems unnecessary in some contexts and I don't get a
  security reason why it's needed e.g. if there's an alg id
  somewhere - can you explain? I can see folks omitting this
  leading to interop problems for not useful reasons. (Same
  comment applies in other cases where kty is a MUST, e.g.
  12.1.2, 12.2.1.)

I think this is the similar to discuss point (2) above.

So again, COSE chairs, can you confirm that this design
does reflect WG consensus and isn't just a thorough and
good editor getting his way? (If you say this is ok with
the WG, I'll clear.)

[Ballot discuss]

-21 means I need to put back the DISCUSS point about deterministic
ECDSA. Could be an error though, checking...

Thanks for the updates in -20. I think we've only the following points
left. Note that all of those are questions to the WG chairs and not to Jim.

  (2) 3.1, alg: so you're disallowing a setup where the kid
  alone identifies the key and algorithm to the recipient?
  That is used in some IETF protocols (OSPF iirc) so rhat's a
  pity, and will in those (maybe less common) cases consume a
  few bytes that could otherwise be saved.  I think, but am not
  sure, that the WG already discussed this, but if not, maybe
  worth a thought? (Or even a 2nd thought:-) And appendix A.1
  is really puzzling - as it provides instructions for how to
  not follow a MUST in the body of the document.

I think we left the mail thread on this with you saying "Best
to ask the chairs if they agree that this is WG consensus," as
you're an admitteddly strong partisan on this topic.

So, COSE chairs - what's your take? (If you say this is ok with
the WG, I'll clear.)

  (6) section 10: why MUST the kty values be present always?
  That seems unnecessary in some contexts and I don't get a
  security reason why it's needed e.g. if there's an alg id
  somewhere - can you explain? I can see folks omitting this
  leading to interop problems for not useful reasons. (Same
  comment applies in other cases where kty is a MUST, e.g.
  12.1.2, 12.2.1.)

I think this is the similar to discuss point (2) above.

So again, COSE chairs, can you confirm that this design
does reflect WG consensus and isn't just a thorough and
good editor getting his way? (If you say this is ok with
the WG, I'll clear.)

[Ballot discuss]

Thanks for the updates in -20. I think we've only the following points
left. Note that all of those are questions to the WG chairs and not to Jim.

  (2) 3.1, alg: so you're disallowing a setup where the kid
  alone identifies the key and algorithm to the recipient?
  That is used in some IETF protocols (OSPF iirc) so rhat's a
  pity, and will in those (maybe less common) cases consume a
  few bytes that could otherwise be saved.  I think, but am not
  sure, that the WG already discussed this, but if not, maybe
  worth a thought? (Or even a 2nd thought:-) And appendix A.1
  is really puzzling - as it provides instructions for how to
  not follow a MUST in the body of the document.

I think we left the mail thread on this with you saying "Best
to ask the chairs if they agree that this is WG consensus," as
you're an admitteddly strong partisan on this topic.

So, COSE chairs - what's your take? (If you say this is ok with
the WG, I'll clear.)

  (6) section 10: why MUST the kty values be present always?
  That seems unnecessary in some contexts and I don't get a
  security reason why it's needed e.g. if there's an alg id
  somewhere - can you explain? I can see folks omitting this
  leading to interop problems for not useful reasons. (Same
  comment applies in other cases where kty is a MUST, e.g.
  12.1.2, 12.2.1.)

I think this is the similar to discuss point (2) above.

So again, COSE chairs, can you confirm that this design
does reflect WG consensus and isn't just a thorough and
good editor getting his way? (If you say this is ok with
the WG, I'll clear.)

[Ballot discuss]

Thanks for the updates in -20. I think we've only the following points
left. Note that 2 of those are questions to the WG chairs and not to Jim.

  (1.1) table 2: As-is the value type column seems to me to
  make CDDL normative. I don't see the natural language version
  that you said would be normative. 

Can you help me see that the changes there are such that
CDDL is ok as informative? I'm not sure but as I read it
there is still no natural language statement that a
"counter signature" is one (or more) COSE_Signature
values.

  (2) 3.1, alg: so you're disallowing a setup where the kid
  alone identifies the key and algorithm to the recipient?
  That is used in some IETF protocols (OSPF iirc) so rhat's a
  pity, and will in those (maybe less common) cases consume a
  few bytes that could otherwise be saved.  I think, but am not
  sure, that the WG already discussed this, but if not, maybe
  worth a thought? (Or even a 2nd thought:-) And appendix A.1
  is really puzzling - as it provides instructions for how to
  not follow a MUST in the body of the document.

I think we left the mail thread on this with you saying "Best
to ask the chairs if they agree that this is WG consensus," as
you're an admitteddly strong partisan on this topic.

So, COSE chairs - what's your take? (If you say this is ok with
the WG, I'll clear.)

  (6) section 10: why MUST the kty values be present always?
  That seems unnecessary in some contexts and I don't get a
  security reason why it's needed e.g. if there's an alg id
  somewhere - can you explain? I can see folks omitting this
  leading to interop problems for not useful reasons. (Same
  comment applies in other cases where kty is a MUST, e.g.
  12.1.2, 12.2.1.)

I think this is the similar to discuss point (2) above.

So again, COSE chairs, can you confirm that this design
does reflect WG consensus and isn't just a thorough and
good editor getting his way? (If you say this is ok with
the WG, I'll clear.)

[Ballot comment]

OLD COMMENTS BELOW, I DIDN'T CHECK THEM. Happy to chat
more about 'em if that's useful.

- 1.4: the 2nd last paragraph is unclear to me. Probably just
needs re-phrasing.

- 1.5: I'd add a reference to RFC5116.

- 3.1, crit: The statement that security libraries or
application code can handle this is odd - isn't that an API
requirement? (I'm not objecting, but it's odd.)

- 3.1, "content type" is the space there intended?  If so,
maybe add quotes or a comma or something to disambiguate the
name and descriptive text? Same for other multi-word names
here.

- 3.1, "all the keys may need to be checked" - really?  Or do
you mean all the keys associated with this kid?

- 3.1, IV/Partial IV - I think it's an error to define this
here. What if some algorithm can't use that kind of
(0|partial)^IV but needs something else instead?  Shouldn't
all mechanism for handling IVs be defined by the
algorithm/mode? (This isn't a discuss because I can't think
of a good counter example and there'd be other ways around
the problem too probably.)

- 4.1: signingTime is often needed with signatures. Isn't that
common enough to want to define a way to do it, as an option?

- 4.1: If I sign with a private key corresponding to a 2047
or 2049 bit RSA public key modulus, then is it clear what to
put where in the signature bstr? (Yes, that'd be dumb, but I
wonder is what to do well enough defined, as I don't think
you can rule it out in all cases.) Since you don't include
RSA here I guess it's ok to skip this, but maybe you need to
say that such issues need to be handled in the definition of
signature algs.

- 4.3: "cannot bleed" isn't clear enough maybe, give an
example perhaps where the decoder can fail to disambiguate a
boundary?

4.4, last para: I disagree that one must (even lowercase
must) check the signing identity.  That's application
behaviour and should be stated here in such concrete terms.
At least s/must also/may also want to/

(Note - the above were comments on -18, but also seem to work
based on -19. Subsequent comments are on -19.)

- 7.1: "starting at the same base IV" - are you missing
"and incrementing" or something? Otherwise I think this
seems unclear.

- 8.2.1: is the phrasing of the 1st para right? would it be
better to say that the value of a key for EdDSA MUST NOT be
used for ECDH and vice-versa. (Or maybe points instead of
keys?)

- 8.2.1: you need a reference for batch signing. (Or could it
be omitted?)

- section 9: I think it'd be good to be clearer about the
strength of truncated MAC values. (And I can't recall the
right thing to say off the top of my head:-)

- 11: RFC2898 is about to be obsoleted by [1]. I suspect it'd
be better to refer to the draft as that should be published
soon. (Same for RFC3447 btw.)

  [1] https://datatracker.ietf.org/doc/draft-moriarty-pkcs5-v2dot1/

- 12.4: Why "OKP"? And saying there's no "simple way" to do
point validation seems fairly opaque, a reference there or
explanatory text would be good. (Ah, it's in section 13,
maybe shuffle the text or include a pointer.) Octet key pair
doesn't seem like that good a name to me btw.

- 12.5: The 1st para seems wrong. (Or at least is unclear to
me.) "Encrypted with  and " seems ambiguous anyway,
does it mean double encryption or two parallel ciphertexts?
(I assume the former.) What's the algebraic thing you're
trying to explain?  It'd be good to provide that for such
relatively complex operations I think. Is this what you mean?

KW(KDF(DH-shared),CEK)

- Table 22: The EC2 or OKP value is fixed per curve and the
cryptographic function being performed so seems unnecessary.
Do you really need it so? Why? (I'm not buying that some
future form of ECC might mean this is needed btw - and
codepoints aren't expensive here, right? So other forms of
ECC can burn codepoints when that's needed and in the
meantime we'd save bytes and complexity.)

- Section 15: Do we have any examples of such a profile?  I
think it'd be great if we did and could add an informative
reference here (even if that's to an early I-D).

- section 19: I don't get how ECDSA is normative and the cfrg
curves are not. Same for RFC6979. Maybe these all could do
with checking? (No big deal IMO but maybe worth it.)

- Appendices A.1 (as already noted) and A.2 are a puzzle.
Why say in the body of the document to do  and then an
appendix that says how to do ?

- Appendix C and the implementation status section: Many
thanks - great to see that! (I didn't check 'em though:-)

- Thanks also for speedily handling the extensive secdir
review.

  [2] https://www.ietf.org/mail-archive/web/secdir/current/msg06801.html

[Ballot comment]
IANA comments need to be addressed and a possible revision of the IANA section:

"Also, this is the document where
> registries are composed of multiple tables, and at least two tables don’t
> have the same columns. In one case a registry is made of 12 tables that are
> listed out of order. It would be good if they could just provide the
> consolidated registries in the IANA Considerations section.  I think this
> will require a new IANA Considerations section."

A decision is needed on the CDDL reference as well.

[Ballot comment]
Stephen, I've seen several documents recently that "reference CDDL informatively" and I don't believe that. So the whole situation with CDDL makes me rather unhappy.

Comments on the document:

This is a well written document, despite its length. Thank you for that.

Some specific comments:

I am pretty sure that the CDDL reference is normative.

On page 13: media type syntax reference is outdated, you should reference RFC 6838, Section 4.2 has relevant ABNF.

In Media type registrations:

Applications that use this media type: To be identified

This answer is not useful, please specify types of applications that will be using these media types. Something along the lines of what you specified in the Introduction.

[Ballot comment]
Stephen, I've seen several documents recently that "reference CDDL informatively" and I don't believe that. So the whole situation with CDDL makes me rather unhappy.
Carsten has approached me about forming CBOR extensions/CDDL WG, but this is in very early stages. (He proposed a Charter, I had serious blocking comments on it.)

In Media type registrations:

Applications that use this media type: To be identified

This answer is not useful, please specify types of applications that will be using these media types. Something along the lines of what you specified in the Introduction.

[Ballot comment]
Stephen, I've seen several documents recently that "reference CDDL informatively" and I don't believe that. So the whole situation with CDDL makes me rather unhappy.
Carsten has approached me about forming CBOR extensions/CDDL WG, but this is in very early stages. (He proposed a Charter, I had serious blocking comments on it.)

[Ballot discuss]

I think this is a fine design and well documented, (though
long) and I'm sure we'll clear up the points below quickly
enough. Some of them may need some discussion but others are
mostly checking.

(1) general: I think the inclusion of CDDL is an error here
and we'd be better off having someone (if interested)
generate the CDDL schema stuff later on when/if CDDL is
standardised/stabilised. Including it now creates the
potential for breakage unnecessarily IMO. However, the WG did
explicitly discuss iirc, so this is just a personal comment
that I'm also in the rough on inclusion of CDDL in this spec.
(As an example, for someone not familiar with CDDL, the
inclusion of fragments interspersed in the text is
distracting and potentially puzzling when one gets to the end
of section 3.) However, I do think there are places where the
CDDL is effectively normative despite what is said in the
introduction, the ones I've spotted are below. (Happy to chat
about 'em as I may be mistaken.) I also wondered if one could
really implement this if all the CDDL was removed from the
text, which is what I think would be required if CDDL were
really to be informative. Anyway the places I think some more
text may be needed are:

(1.1) table 2: As-is the value type column seems to me to
make CDDL normative. I don't see the natural language version
that you said would be normative.

(1.2) 4.4, 2nd list point 1: the use of Sig_structure makes
the CDDL normative. (Same with the use in 4.5 and
Enc_structure in 5.3.)

(1.3) 7.1, the key_ops value is only specified in CDDL, in
Table 3. (It is well-defined below the table in text though,
so this one's borderline.)

(1.4) 11.2: it's not clear to me that a reader knows how to
handle decoding of the two optional fields at the end (other
and SuppPrivInfo) without looking at the CDDL. Can you
explain? (That might be just my ignorance of CBOR, but wanted
to check.)

(2) 3.1, alg: so you're disallowing a setup where the kid
alone identifies the key and algorithm to the recipient?
That is used in some IETF protocols (OSPF iirc) so rhat's a
pity, and will in those (maybe less common) cases consume a
few bytes that could otherwise be saved.  I think, but am not
sure, that the WG already discussed this, but if not, maybe
worth a thought? (Or even a 2nd thought:-) And appendix A.1
is really puzzling - as it provides instructions for how to
not follow a MUST in the body of the document.

(3) 7.1: key_op 8, "derive bits" - I don't think this usage
is clear enough, can you say what's meant here?

(4) Why not make deterministic ECDSA a MUST?  8.1.1 says:
"Applications that specify ECDSA should evaluate the ability
to get good random number generation and require
deterministic signatures where poor random number generation
exists."  I don't think that is sufficiently clear, nor
realistic, and I don't recall this being discussed on the
list (sorry if I'm forgetting) and bad random values are a
killer flaw here that has happened in the wild.

(5) Table 6, is this 25519 or 448? Where does it say?  Sorry
if I'm being dumb here, but I don't see where you say which
curve is specified, the definition of 'crv' says defined for
this alg which I assume means listed in Table 6.

(6) section 10: why MUST the kty values be present always?
That seems unnecessary in some contexts and I don't get a
security reason why it's needed e.g. if there's an alg id
somewhere - can you explain? I can see folks omitting this
leading to interop problems for not useful reasons. (Same
comment applies in other cases where kty is a MUST, e.g.
12.1.2, 12.2.1.)

(7) section 11: given that we know people will use human
memorable secrets, why have you not defined codepoints for
PBES2 (or the more commonly supported?) PBDKF2?  I'm fine if
there's a reason, or even if it was discussed by the WG, but
just wanted to check as I'd worry that folks will use the
ones defined here with human memorable secrets no matter what
the spec says so giving 'em something more tailored might be
better. (OTOH, one could argue that making this apparent
might be worse too I guess.)

(8) 12.4: Why is no ephemeral-ephemeral (E-E) variant
supported? Some protocols will allow for that and it seems
wrong to disallow it when it could relatively easily be
supported. For some applications where content is dealt with
in store-and-forward mode, there may be situations (e.g.
provisioning, "introduction") where E-E could be used.
As-is, applications wanting that will have to hack the
recipient DH-public into a home-grown structure (or use one
of the COSE_Key labels from Table 19) and then treat that as
ES-DH. That seems likely to lead to non-interop or security
errors being made. I'd be fine if you even said how to re-use
the structures currently defined for E-E btw and didn't
introduce new structures.

(9) 16.4: I'm not sure expert review is right here.  What if
the expert is asked to add SM2/SM4 while there is still no
widely available non-Chinese text to describe those?  I think
the expert ought enforce a "specification required" rule at
least and maybe more.  (And ought never allow an algorithm
with no specification publicly available.)

(10) 16.4 (and elsewhere maybe) I think this registry is
missing a column - as is being done in the TLS WG, I think
there should be a column saying if the IETF is happy enough
with an algorithm and that getting a "Y" in that ought
require standards action. (Or some similar scheme.) I don't
think the standards-track range of codepoints is enough here,
e.g. at some time we will want to deprecate things, and at
other times we may want to define things for the future on
the standards-track but not (yet) recommend their use.  The
last bullet in 16.11 does help here, but I'd argue that we
need to do more to protect the expert (and implementers) from
the trickle of vanity/national algorithms/curves that are
always being proposed.

[Ballot comment]


- 1.4: the 2nd last paragraph is unclear to me. Probably just
needs re-phrasing.

- 1.5: I'd add a reference to RFC5116.

- 3.1, crit: The statement that security libraries or
application code can handle this is odd - isn't that an API
requirement? (I'm not objecting, but it's odd.)

- 3.1, "content type" is the space there intended?  If so,
maybe add quotes or a comma or something to disambiguate the
name and descriptive text? Same for other multi-word names
here.

- 3.1, "all the keys may need to be checked" - really?  Or do
you mean all the keys associated with this kid?

- 3.1, IV/Partial IV - I think it's an error to define this
here. What if some algorithm can't use that kind of
(0|partial)^IV but needs something else instead?  Shouldn't
all mechanism for handling IVs be defined by the
algorithm/mode? (This isn't a discuss because I can't think
of a good counter example and there'd be other ways around
the problem too probably.)

- 4.1: signingTime is often needed with signatures. Isn't that
common enough to want to define a way to do it, as an option?

- 4.1: If I sign with a private key corresponding to a 2047
or 2049 bit RSA public key modulus, then is it clear what to
put where in the signature bstr? (Yes, that'd be dumb, but I
wonder is what to do well enough defined, as I don't think
you can rule it out in all cases.) Since you don't include
RSA here I guess it's ok to skip this, but maybe you need to
say that such issues need to be handled in the definition of
signature algs.

- 4.3: "cannot bleed" isn't clear enough maybe, give an
example perhaps where the decoder can fail to disambiguate a
boundary?

4.4, last para: I disagree that one must (even lowercase
must) check the signing identity.  That's application
behaviour and should be stated here in such concrete terms.
At least s/must also/may also want to/

(Note - the above were comments on -18, but also seem to work
based on -19. Subsequent comments are on -19.)

- 7.1: "starting at the same base IV" - are you missing
"and incrementing" or something? Otherwise I think this
seems unclear.

- 8.2.1: is the phrasing of the 1st para right? would it be
better to say that the value of a key for EdDSA MUST NOT be
used for ECDH and vice-versa. (Or maybe points instead of
keys?)

- 8.2.1: you need a reference for batch signing. (Or could it
be omitted?)

- section 9: I think it'd be good to be clearer about the
strength of truncated MAC values. (And I can't recall the
right thing to say off the top of my head:-)

- 11: RFC2898 is about to be obsoleted by [1]. I suspect it'd
be better to refer to the draft as that should be published
soon. (Same for RFC3447 btw.)

  [1] https://datatracker.ietf.org/doc/draft-moriarty-pkcs5-v2dot1/

- 12.4: Why "OKP"? And saying there's no "simple way" to do
point validation seems fairly opaque, a reference there or
explanatory text would be good. (Ah, it's in section 13,
maybe shuffle the text or include a pointer.) Octet key pair
doesn't seem like that good a name to me btw.

- 12.5: The 1st para seems wrong. (Or at least is unclear to
me.) "Encrypted with  and " seems ambiguous anyway,
does it mean double encryption or two parallel ciphertexts?
(I assume the former.) What's the algebraic thing you're
trying to explain?  It'd be good to provide that for such
relatively complex operations I think. Is this what you mean?

KW(KDF(DH-shared),CEK)

- Table 22: The EC2 or OKP value is fixed per curve and the
cryptographic function being performed so seems unnecessary.
Do you really need it so? Why? (I'm not buying that some
future form of ECC might mean this is needed btw - and
codepoints aren't expensive here, right? So other forms of
ECC can burn codepoints when that's needed and in the
meantime we'd save bytes and complexity.)

- Section 15: Do we have any examples of such a profile?  I
think it'd be great if we did and could add an informative
reference here (even if that's to an early I-D).

- section 19: I don't get how ECDSA is normative and the cfrg
curves are not. Same for RFC6979. Maybe these all could do
with checking? (No big deal IMO but maybe worth it.)

- Appendices A.1 (as already noted) and A.2 are a puzzle.
Why say in the body of the document to do  and then an
appendix that says how to do ?

- Appendix C and the implementation status section: Many
thanks - great to see that! (I didn't check 'em though:-)

- Thanks also for speedily handling the extensive secdir
review.

  [2] https://www.ietf.org/mail-archive/web/secdir/current/msg06801.html

[Ballot comment]
A few minor comments:

Substantive:

-1.3, definition of "int": Is that really _unsigned_ or negative?  Or is it a signed integer than can be negative or non-negative? (contrasting with uint?)  (Or is int merely a parent of nint and uint?)

-3: What is the scope of uniqueness for map labels? I expected it to be the map, but the text immediately aftewards suggests the scope may be the whole message. Whatever the answer, it would help to be explicit.

- Informative References: [I-D.irtf-cfrg-eddsa]: Other algorithm references are normative. Why not this one?

Editorial:

"Contributing to this Memo" section: Is this intended to stay in the final RFC? If not, it might be worth a note to the RFC editor.

-1, first paragraph, last sentence: Comma splice.

-1, 2nd paragraph: MAC usually expands to Message Authentication _Code_.

-2, 6th paragraph, last sentence: s/method/methods  (assuming the following list is a list of methods, and not steps in a method.

-3, definition of protected:

-4.1,  "COSE_Sign_Tagged = #6.991(COSE_Sign) ; Replace 991 with TBD1": Is the comment intended as a note to the RFC editor? If so, it might be helpful to label it as such.

-4.3, first bullet: "If multiple items are included, care needs to be taken that data
      cannot bleed between the items."
Is this talking about data framing, or something else?

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

IANA has completed its review of draft-ietf-cose-msg-18.txt. If any part of this review is inaccurate, please let us know.

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

IANA understands that, upon approval of this document there are ten actions which must be completed.

First, in the CBOR Tags subregistry of the Concise Binary Object Representation (CBOR) Tags located at:

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

six new tags are to be registered as follows:

Tag: [ TBD-at-Registration ]
Item: COSE_Sign
Semantics: COSE Signed Data Object
Reference: [ RFC-to-be ]

Tag: [ TBD-at-Registration ]
Item: COSE_Sign1
Semantics: COSE Single Signer Data Object
Reference: [ RFC-to-be ]

Tag: [ TBD-at-Registration ]
Item: COSE_Encrypt
Semantics: COSE Encrypted Data Object
Reference: [ RFC-to-be ]

Tag: [ TBD-at-Registration ]
Item: COSE_Encrypt0
Semantics: COSE Single Recipient Encrypted Data Object
Reference: [ RFC-to-be ]

Tag: [ TBD-at-Registration ]
Item: COSE_Mac
Semantics: COSE Mac-ed Data Object
Reference: [ RFC-to-be ]

Tag: [ TBD-at-Registration ]
Item: COSE_Mac0
Semantics: COSE Mac w/o Recipients Object
Reference: [ RFC-to-be ]

IANA notes the authors request that the tags for COSE_Sign1, COSE_Encrypt0, and COSE_Mac0 be assigned in the 1 to 23 value range. It is requested that the tags for COSE_Sign, COSE_Encrypt and COSE_MAC be assigned in the 24 to 255 value range.

As this document requests registrations in an Expert Review or Specification Required (see RFC 5226) registry, we will initiate the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC.

Second, a new registry is to be created called the COSE Header Parameters Registry.

IANA Question --> Should this new registry be a standalone registry, or should it be grouped with, or perhaps a subregistry, of an existing registry?

The new registry will be managed via Expert Review as defined in RFC 5226.

There are initial registrations in the new registry as follows:
+-----------+-------+----------------+-------------+----------------+---------------+
| name | label | value type | value | description | Reference |
| | | | registry | | |
+-----------+-------+----------------+-------------+----------------+---------------+
| reserved | 0 | | | | |
| alg | 1 | int / tstr | COSE | Cryptographic | [ RFC-to-be ] |
| | | | Algorithms | algorithm to | |
| | | | registry | use | |
| | | | | | |
| crit | 2 | [+ label] | COSE Header | Critical | [ RFC-to-be ] |
| | | | Labels | headers to be | |
| | | | registry | understood | |
| | | | | | |
| content | 3 | tstr / uint | CoAP | Content type | [ RFC-to-be ] |
| type | | | Content- | of the payload | |
| | | | Formats or | | |
| | | | Media Types | | |
| | | | registry | | |
| | | | | | |
| kid | 4 | bstr | | Key identifier | [ RFC-to-be ] |
| | | | | | |
| IV | 5 | bstr | | Full | [ RFC-to-be ] |
| | | | | Initialization | |
| | | | | Vector | |
| | | | | | |
| Partial | 6 | bstr | | Partial | [ RFC-to-be ] |
| IV | | | | Initialization | |
| | | | | Vector | |
| | | | | | |
| counter | 7 | COSE_Signature | | CBOR encoded | [ RFC-to-be ] |
| signature | | / [+ | | signature | |
| | | COSE_Signature | | structure | |
| | | ] | | | |
+-----------+-------+----------------+-------------+----------------+---------------+

The authors also suggest that Table 27 be included in the new registry. However, Table 27 does not have the same fields as the remainder of the rest of the registry.

+-------------------+-------+--------+------------------------------+
| name | label | value | description |
| | | type | |
+-------------------+-------+--------+------------------------------+
| CounterSignature0 | 9 | bstr | Counter signature with |
| | | | implied signer and headers |
+-------------------+-------+--------+------------------------------+

IANA Question --> What is the value registry entry for the entry in Table 27.

Third, a new registry is to be created called the COSE Header Algorithm Parameters Registry.

IANA Question --> As before, should this new registry be a standalone registry, or should it be grouped with, or perhaps a subregistry, of an existing registry?

The new registry will be managed via Expert Review as defined in RFC 5226.

The authors suggest that Table 13, 14 and 19 of the document be included in the new registry. However, these tables do not have all the fields required in section 16.3 of the current document.

IANA Question -> Could the authors provide a consolidated listing of all initial registrations for the new registry including all fields required by section 16.3 of the current document in the IANA Considerations section of the document?

Fourth, a new registry is to be created called the COSE Algorithms Registry.

IANA Question --> As before, should this new registry be a standalone registry, or should it be grouped with, or perhaps a subregistry, of an existing registry?

The new registry will be managed via Expert Review as defined in RFC 5226.

The authors suggest that: "The initial contents of the registry can be found in Table 10, Table 9, Table 11, Table 5, Table 7, Table 8, Table 15, Table 16, Table 17, Table 6, Table 20 and Table 18. The specification column for all rows in that table should be this document."

IANA Question -> Could the authors provide a consolidated listing of all initial registrations for the new registry including all fields required by section 16.4 of the current document in the IANA Considerations section of the document?

Fifth, a new registry is to be created called the COSE Key Common Parameters Registry.

IANA Question --> As before, should this new registry be a standalone registry, or should it be grouped with, or perhaps a subregistry, of an existing registry?

The new registry will be managed via Expert Review as defined in RFC 5226.

There are initial registrations in the new registry as follows:

+---------+-------+----------------+------------+-------------------+--------------+
| name | label | CBOR type | registry | description | Reference |
+---------+-------+----------------+------------+-------------------+--------------+
| kty | 1 | tstr / int | COSE Key | Identification of | [ RFC-to-be ]|
| | | | Common | the key type | |
| | | | Parameters | | |
| | | | | | |
| alg | 3 | tstr / int | COSE | Key usage | [ RFC-to-be ]|
| | | | Algorithm | restriction to | |
| | | | Values | this algorithm | |
| | | | | | |
| kid | 2 | bstr | | Key | [ RFC-to-be ]|
| | | | | Identification | |
| | | | | value - match to | |
| | | | | kid in message | |
| | | | | | |
| key_ops | 4 | [+ (tstr/int)] | | Restrict set of | [ RFC-to-be ]|
| | | | | permissible | |
| | | | | operations | |
| | | | | | |
| Base IV | 5 | bstr | | Base IV to be | [ RFC-to-be ]|
| | | | | xor-ed with | |
| | | | | Partial IVs | |
+---------+-------+----------------+------------+-------------------+--------------+

Sixth, a new registry is to be created called the COSE Key Type Parameters Registry.

IANA Question --> As before, should this new registry be a standalone registry, or should it be grouped with, or perhaps a subregistry, of an existing registry?

The new registry will be managed via Expert Review as defined in RFC 5226.

The authors state that: "this registry will be initially populated by the values in Table 23, Table 24, and Table 25."

IANA Question -> Could the authors provide a consolidated listing of all initial registrations for the new registry including all fields required by section 16.6 of the current document in the IANA Considerations section of the document?

Seventh, a new registry is to be created called the COSE Key Type Registry.

IANA Question --> As before, should this new registry be a standalone registry, or should it be grouped with, or perhaps a subregistry, of an existing registry?

The new registry will be managed via Expert Review as defined in RFC 5226.

There are initial registrations in the new registry as follows:

+-----------+-------+--------------------------------------------+---------------+
| name | value | description | Reference |
+-----------+-------+--------------------------------------------+---------------+
| OKP | 1 | Octet Key Pair | [ RFC-to-be ] |
| | | | |
| EC2 | 2 | Elliptic Curve Keys w/ X,Y Coordinate pair | [ RFC-to-be ] |
| | | | |
| Symmetric | 4 | Symmetric Keys | [ RFC-to-be ] |
| | | | |
| Reserved | 0 | This value is reserved | [ RFC-to-be ] |
+-----------+-------+--------------------------------------------+---------------+

Eighth, a new registry is to be created called the COSE Elliptic Curve Parameters Registry.

IANA Question --> As before, should this new registry be a standalone registry, or should it be grouped with, or perhaps a subregistry, of an existing registry?

The new registry will be managed via Expert Review as defined in RFC 5226.

There are initial registrations in the new registry as follows:

+---------+----------+-------+------------------------------------+---------------+
| name | key type | value | description | Reference |
+---------+----------+-------+------------------------------------+---------------|
| P-256 | EC2 | 1 | NIST P-256 also known as secp256r1 | [ RFC-to-be ] |
| | | | | |
| P-384 | EC2 | 2 | NIST P-384 also known as secp384r1 | [ RFC-to-be ] |
| | | | | |
| P-521 | EC2 | 3 | NIST P-521 also known as secp521r1 | [ RFC-to-be ] |
| | | | | |
| X25519 | OKP | 4 | X25519 for use w/ ECDH only | [ RFC-to-be ] |
| | | | | |
| X448 | OKP | 5 | X448 for use w/ ECDH only | [ RFC-to-be ] |
| | | | | |
| Ed25519 | OKP | 6 | Ed25519 for use w/ EdDSA only | [ RFC-to-be ] |
| | | | | |
| Ed448 | OKP | 7 | Ed448 for use w/ EdDSA only | [ RFC-to-be ] |
+---------+----------+-------+------------------------------------+---------------+

Ninth, in the application media types registry located at:

http://www.iana.org/assignments/media-types/

three new application media types are to be registered as follows:

Name: cose
Template: [ TBD-at-registration ]
Reference: [ RFC-to-be ]

Name: cose-key
Template: [ TBD-at-registration ]
Reference: [ RFC-to-be ]

Name: cose-key-set
Template: [ TBD-at-registration ]
Reference: [ RFC-to-be ]

Tenth, in the CoAP Content-Formats subregistry of the Constrained RESTful Environments (CoRE) Parameters registry located at:

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

eight new registrations are to be made as follows:

+---------------------------------+----------+-------+---------------+
| Media Type | Encoding | ID | Reference |
+---------------------------------+----------+-------+---------------+
| application/cose; cose-type | | TBD | [ RFC-to-be ] |
| ="cose-sign" | | | |
| | | | |
| application/cose; cose-type | | TBD | [ RFC-to-be ] |
| ="cose-sign1" | | | |
| | | | |
| application/cose; cose-type | | TBD | [ RFC-to-be ] |
| ="cose-encrypt" | | | |
| | | | |
| application/cose; cose-type | | TBD | [ RFC-to-be ] |
| ="cose-encrypt0" | | | |
| | | | |
| application/cose; cose-type | | TBD | [ RFC-to-be ] |
| ="cose-mac" | | | |
| | | | |
| application/cose; cose-type | | TBD | [ RFC-to-be ] |
| ="cose-mac0" | | | |
| | | | |
| application/cose-key | | TBD | [ RFC-to-be ] |
| | | | |
| | | | |
| application/cose-key-set | | TBD | [ RFC-to-be ] |
| | | | |
+---------------------------------+----------+-------+---------------+

The authors suggest that: "ID assignment in the 24-255 range is requested."

The available assignment ranges for this registry are:
Range Registration Procedures
0-255 Expert Review
256-9999 IETF Review or IESG Approval
10000-64999 First Come First Served
65000-65535 Experimental use (no operational use)

IANA Question -> Which of these ranges do the authors intend these eight new registrations?

IANA understand that these ten actions are the only ones required to be completed upon approval of the document.

IANA will not be able to complete the registry actions for this document until these issues have been resolved.

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 only to confirm what actions will be performed. 


Thank you,

Sabrina Tanamal
IANA Specialist
ICANN

[Ballot comment]
I'm going to be a No Objection for this doc no matter what, so it's safe to answer my question :-)

This is for use with CoAP, right? Would you rely on CoAP for fragmentation, if that's required?

The following Last Call announcement was sent out:

From: The IESG
To: "IETF-Announce"
CC: "Goeran Selander" , cose-chairs@ietf.org, Kathleen.Moriarty.ietf@gmail.com, draft-ietf-cose-msg@ietf.org, goran.selander@ericsson.com, cose@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (CBOR Object Signing and Encryption (COSE)) to Proposed 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)'
  as Proposed 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
ietf@ietf.org mailing lists by 2016-09-28. 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 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)
  specification.  This specification describes how to create and
  process signature, message authentication codes and encryption using
  CBOR for serialization.  This specification additionally specifies
  how to represent cryptographic keys using CBOR.




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

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-cose-msg/ballot/


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


The document contains these normative downward references.
See RFC 3967 for additional information:
    rfc7539: ChaCha20 and Poly1305 for IETF Protocols (Informational - Independent Submission Editor stream)
    rfc3394: Advanced Encryption Standard (AES) Key Wrap Algorithm (Informational - IETF stream)
    rfc3610: Counter with CBC-MAC (CCM) (Informational - Independent Submission Editor stream)
    rfc5869: HMAC-based Extract-and-Expand Key Derivation Function (HKDF) (Informational - IETF stream)
    rfc6090: Fundamental Elliptic Curve Cryptography Algorithms (Informational - IETF stream)
    rfc2104: HMAC: Keyed-Hashing for Message Authentication (Informational - IETF stream)
Note that some of these references may already be listed in the acceptable Downref Registry.

1. Summary

The document shepherd is Göran Selander. The responsible Area Director is Kathleen Moriarty.

This specification describes how to create and process signatures, message authentication codes and encryption using the Concise Binary Object Representation (CBOR, RFC7049) for serialization.  The specification additionally specifies how to represent cryptographic keys using CBOR.

This specification is a Standards Track RFC describing a solution component analogous to the JSON Web suite of security RFCs 7515-7518 (JOSE WG), but using the CBOR encoding format.


2. Review and Consensus

The document was developed by the COSE working group based on requirements from constrained device/IoT community (CORE/ACE WGs) and on the experience of developing the JSON Web security suite of RFCs (JOSE/OAuth WGs). There is a small dedicated team of people interested in this work, and reviews has been performed mainly by these people. One category of issues has been on generic message format vs dedicated formats optimized for certain constrained settings. This was resolved with a small set of dedicated formats complementing the generic formats. Another category of issues has been on the deviations from JOSE or omission of legacy crypto not suitable for constrained devices. There has been some contention by individuals of how individual review comments were addressed. There are no substained objections on any issues relating to this draft. The current open issues are related to additional algorithm and is out of scope for this draft. There has not yet been any dedicated full security review of this version of the draft.

The draft records the status of known implementations of the protocol defined by this specification (based on RFC 7942). Three implementations currently maintained by the author are referenced, in Java, C# and C (https://github.com/cose-wg).
Ongoing work on a JavaScript implementation has been announced. Implementations optimized for constrained platforms are requested by different companies and is in progress.

3. Intellectual Property

The author has confirmed conformance with BCP 78/79. There are no IPR disclosures on the document:

https://www.ietf.org/mail-archive/web/cose/current/msg01106.html

4. Other points

* The IANA considerations section asks for registration into existing registries:

16.1.  CBOR Tag assignment

Request for tags in range 0-23 requires standards action. Requesting tags in this range is is well founded since the objective for these registrations is to produce as compact message format as possible. Request for assignment in range 24-255 requires specification which is provided by this draft. It would be beneficial to request early assignment of the requested CBOR Tags to include in the RFC. The author is has contacted the expert on this.

16.9.  Media Type Registrations

Two new media types needs to be registered for the formats specfied in the draft.

Clarification of what "RFC TBD" is referencing needs to be added (4 occurances).


16.10.  CoAP Content Format Registrations

Assignment in the 24-255 range as requested requires Expert Review.


* The IANA considerations also request for a set of new registries to be created. One of the objectives of this work is to create a compact protected message format and one part of achieving that is to label various message parameters. Expert review is required for all these registrations and instructions are provided. References to tables with initial contents is provided. The new registries requested are:

16.2.  COSE Header Parameters Registry  

16.3.  COSE Header Algorithm Parameters Registry

16.4.  COSE Algorithms Registry

Editorial: The references to tables with initial contents of the registry is unordered.

16.5.  COSE Key Common Parameters Registry

16.6.  COSE Key Type Parameters Registry

16.7.  COSE Key Type Registry

16.8.  COSE Elliptic Curve Parameters Registry


* The Id-nits are essentially remarks on references:

" -- Possible downref: Non-RFC (?) normative reference: ref. 'AES-GCM'

  -- Possible downref: Non-RFC (?) normative reference: ref. 'DSS'

  -- Possible downref: Non-RFC (?) normative reference: ref. 'MAC'

  ** Downref: Normative reference to an Informational RFC: RFC 2104

  ** Downref: Normative reference to an Informational RFC: RFC 3394

  ** Downref: Normative reference to an Informational RFC: RFC 3610

  ** Downref: Normative reference to an Informational RFC: RFC 5869

  ** Downref: Normative reference to an Informational RFC: RFC 6090

  ** Downref: Normative reference to an Informational RFC: RFC 7539

  -- Possible downref: Non-RFC (?) normative reference: ref. 'SEC1'

  -- Obsolete informational reference (is this intentional?): RFC 2633
     (Obsoleted by RFC 3851)"

The downreferences are references to crypto algorithms which are normatively used in the draft so is correct. Referencing RFC 2633 is intentional for addressing older versions of S/MIME; and actually RFC 5751, which is the RFC obsoleting RFC 3851, is referenced in the draft.

* Appendix C contains a substantial number of examples. There is a GitHub project referenced
(https://github.com/cose-wg/Examples) which contains a superset of the examples in the draft including the JSON input used in the examples.