CBOR Object Signing and Encryption (COSE)
draft-ietf-cose-msg-24
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2017-06-30
|
24 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2017-04-19
|
24 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2017-04-07
|
24 | (System) | RFC Editor state changed to RFC-EDITOR from AUTH |
2017-03-28
|
24 | (System) | RFC Editor state changed to AUTH from RFC-EDITOR |
2017-03-28
|
24 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2017-03-28
|
24 | (System) | RFC Editor state changed to RFC-EDITOR from IANA |
2017-03-27
|
24 | (System) | IANA Action state changed to Waiting on RFC Editor from Waiting on Authors |
2017-01-23
|
24 | (System) | RFC Editor state changed to IANA from EDIT |
2016-12-12
|
24 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2016-12-02
|
24 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2016-12-02
|
24 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2016-11-28
|
24 | (System) | RFC Editor state changed to EDIT |
2016-11-28
|
24 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2016-11-28
|
24 | (System) | Announcement was received by RFC Editor |
2016-11-28
|
24 | (System) | IANA Action state changed to In Progress |
2016-11-28
|
24 | Cindy Morgan | IESG state changed to Approved-announcement sent from IESG Evaluation::AD Followup |
2016-11-28
|
24 | Cindy Morgan | IESG has approved the document |
2016-11-28
|
24 | Cindy Morgan | Closed "Approve" ballot |
2016-11-28
|
24 | Cindy Morgan | Ballot approval text was generated |
2016-11-28
|
24 | Cindy Morgan | RFC Editor Note was changed |
2016-11-28
|
24 | Cindy Morgan | RFC Editor Note for ballot was generated |
2016-11-28
|
24 | Cindy Morgan | RFC Editor Note for ballot was generated |
2016-11-23
|
24 | Amy Vezza | Ballot writeup was changed |
2016-11-23
|
24 | Amy Vezza | Ballot writeup was changed |
2016-11-23
|
24 | Amy Vezza | Ballot approval text was generated |
2016-11-22
|
24 | Stephen Farrell | [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 … [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;-) |
2016-11-22
|
24 | Stephen Farrell | [Ballot Position Update] Position for Stephen Farrell has been changed to Yes from Discuss |
2016-11-22
|
24 | Jim Schaad | New version available: draft-ietf-cose-msg-24.txt |
2016-11-22
|
24 | (System) | New version approved |
2016-11-22
|
24 | (System) | Request for posting confirmation emailed to previous authors: "Jim Schaad" |
2016-11-22
|
24 | Jim Schaad | Uploaded new revision |
2016-10-18
|
23 | Jim Schaad | New version available: draft-ietf-cose-msg-23.txt |
2016-10-18
|
23 | (System) | New version approved |
2016-10-18
|
23 | (System) | Request for posting confirmation emailed to previous authors: "Jim Schaad" |
2016-10-18
|
23 | Jim Schaad | Uploaded new revision |
2016-10-17
|
22 | Alexey Melnikov | [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 … [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]. |
2016-10-17
|
22 | Alexey Melnikov | Ballot comment text updated for Alexey Melnikov |
2016-10-16
|
22 | Stephen Farrell | [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 … [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.) |
2016-10-16
|
22 | Stephen Farrell | Ballot discuss text updated for Stephen Farrell |
2016-10-16
|
22 | Jim Schaad | New version available: draft-ietf-cose-msg-22.txt |
2016-10-16
|
22 | (System) | New version approved |
2016-10-16
|
22 | (System) | Request for posting confirmation emailed to previous authors: "Jim Schaad" |
2016-10-16
|
22 | Jim Schaad | Uploaded new revision |
2016-10-16
|
21 | Stephen Farrell | [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 … [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.) |
2016-10-16
|
21 | Stephen Farrell | Ballot discuss text updated for Stephen Farrell |
2016-10-16
|
21 | Jim Schaad | New version available: draft-ietf-cose-msg-21.txt |
2016-10-16
|
21 | (System) | New version approved |
2016-10-16
|
21 | (System) | Request for posting confirmation emailed to previous authors: "Jim Schaad" |
2016-10-16
|
21 | Jim Schaad | Uploaded new revision |
2016-10-16
|
20 | Stephen Farrell | [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 … [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.) |
2016-10-16
|
20 | Stephen Farrell | Ballot comment and discuss text updated for Stephen Farrell |
2016-10-16
|
20 | Stephen Farrell | [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 … [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.) |
2016-10-16
|
20 | Stephen Farrell | [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 … [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 |
2016-10-16
|
20 | Stephen Farrell | Ballot comment and discuss text updated for Stephen Farrell |
2016-10-14
|
20 | Meral Shirazipour | Request for Last Call review by GENART Completed: Ready with Nits. Reviewer: Meral Shirazipour. |
2016-10-10
|
20 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2016-10-10
|
20 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA - Not OK |
2016-10-10
|
20 | Jim Schaad | New version available: draft-ietf-cose-msg-20.txt |
2016-10-10
|
20 | (System) | New version approved |
2016-10-10
|
20 | (System) | Request for posting confirmation emailed to previous authors: "Jim Schaad" |
2016-10-10
|
20 | Jim Schaad | Uploaded new revision |
2016-10-05
|
19 | Gunter Van de Velde | Closed request for Last Call review by OPSDIR with state 'No Response' |
2016-09-29
|
19 | Cindy Morgan | IESG state changed to IESG Evaluation::Revised I-D Needed from Waiting for AD Go-Ahead |
2016-09-29
|
19 | Kathleen Moriarty | [Ballot comment] IANA comments need to be addressed and a possible revision of the IANA section: "Also, this is the document where > registries are … [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. |
2016-09-29
|
19 | Kathleen Moriarty | Ballot comment text updated for Kathleen Moriarty |
2016-09-29
|
19 | Jari Arkko | [Ballot Position Update] New position, No Objection, has been recorded for Jari Arkko |
2016-09-28
|
19 | Alvaro Retana | [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana |
2016-09-28
|
19 | (System) | IANA Review state changed to IANA - Not OK from Version Changed - Review Needed |
2016-09-28
|
19 | Terry Manderson | [Ballot Position Update] New position, No Objection, has been recorded for Terry Manderson |
2016-09-28
|
19 | Alexey Melnikov | [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 … [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. |
2016-09-28
|
19 | Alexey Melnikov | [Ballot Position Update] Position for Alexey Melnikov has been changed to No Objection from No Record |
2016-09-28
|
19 | Deborah Brungard | [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard |
2016-09-28
|
19 | Alexey Melnikov | [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 … [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. |
2016-09-28
|
19 | Alexey Melnikov | Ballot comment text updated for Alexey Melnikov |
2016-09-28
|
19 | Alissa Cooper | [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper |
2016-09-28
|
19 | Alexey Melnikov | [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 … [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.) |
2016-09-28
|
19 | Alexey Melnikov | Ballot comment text updated for Alexey Melnikov |
2016-09-28
|
19 | Stephen Farrell | [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. … [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. |
2016-09-28
|
19 | Stephen Farrell | [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. … [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 |
2016-09-28
|
19 | Stephen Farrell | [Ballot Position Update] New position, Discuss, has been recorded for Stephen Farrell |
2016-09-28
|
19 | (System) | IESG state changed to Waiting for AD Go-Ahead from In Last Call |
2016-09-27
|
19 | Jim Schaad | IANA Review state changed to Version Changed - Review Needed from IANA - Not OK |
2016-09-27
|
19 | Jim Schaad | New version approved |
2016-09-27
|
19 | Jim Schaad | New version available: draft-ietf-cose-msg-19.txt |
2016-09-27
|
19 | Jim Schaad | Request for posting confirmation emailed to previous authors: "Jim Schaad" |
2016-09-27
|
19 | (System) | Uploaded new revision |
2016-09-27
|
18 | Ben Campbell | [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 … [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? |
2016-09-27
|
18 | Ben Campbell | [Ballot Position Update] New position, No Objection, has been recorded for Ben Campbell |
2016-09-27
|
18 | (System) | IANA Review state changed to IANA - Not OK from IANA - Review Needed |
2016-09-27
|
18 | Suresh Krishnan | [Ballot Position Update] New position, No Objection, has been recorded for Suresh Krishnan |
2016-09-27
|
18 | Sabrina Tanamal | (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 … (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 |
2016-09-27
|
18 | Spencer Dawkins | [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 … [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? |
2016-09-27
|
18 | Spencer Dawkins | [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins |
2016-09-26
|
18 | Alia Atlas | [Ballot Position Update] New position, No Objection, has been recorded for Alia Atlas |
2016-09-23
|
18 | Mirja Kühlewind | [Ballot Position Update] New position, No Objection, has been recorded for Mirja Kühlewind |
2016-09-23
|
18 | Kathleen Moriarty | Ballot has been issued |
2016-09-23
|
18 | Kathleen Moriarty | Ballot writeup was changed |
2016-09-23
|
18 | Kathleen Moriarty | Ballot has been issued |
2016-09-23
|
18 | Kathleen Moriarty | [Ballot Position Update] New position, Yes, has been recorded for Kathleen Moriarty |
2016-09-23
|
18 | Kathleen Moriarty | Created "Approve" ballot |
2016-09-23
|
18 | Kathleen Moriarty | Ballot writeup was changed |
2016-09-22
|
18 | Tero Kivinen | Request for Last Call review by SECDIR Completed: Has Issues. Reviewer: Stephen Kent. |
2016-09-21
|
18 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Suzanne Woolf |
2016-09-21
|
18 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Suzanne Woolf |
2016-09-21
|
18 | Kathleen Moriarty | Ballot writeup was changed |
2016-09-21
|
18 | Kathleen Moriarty | Ballot writeup was changed |
2016-09-15
|
18 | Jean Mahoney | Request for Last Call review by GENART is assigned to Meral Shirazipour |
2016-09-15
|
18 | Jean Mahoney | Request for Last Call review by GENART is assigned to Meral Shirazipour |
2016-09-15
|
18 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Stephen Kent |
2016-09-15
|
18 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Stephen Kent |
2016-09-14
|
18 | Amy Vezza | IANA Review state changed to IANA - Review Needed |
2016-09-14
|
18 | Amy Vezza | 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, … 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. |
2016-09-14
|
18 | Amy Vezza | IESG state changed to In Last Call from Last Call Requested |
2016-09-14
|
18 | Kathleen Moriarty | Placed on agenda for telechat - 2016-09-29 |
2016-09-14
|
18 | Kathleen Moriarty | Changed consensus to Yes from Unknown |
2016-09-14
|
18 | Kathleen Moriarty | Last call was requested |
2016-09-14
|
18 | Kathleen Moriarty | Ballot approval text was generated |
2016-09-14
|
18 | Kathleen Moriarty | Ballot writeup was generated |
2016-09-14
|
18 | Kathleen Moriarty | IESG state changed to Last Call Requested from AD Evaluation |
2016-09-14
|
18 | Kathleen Moriarty | Last call announcement was generated |
2016-09-10
|
18 | Jim Schaad | New version available: draft-ietf-cose-msg-18.txt |
2016-09-06
|
17 | Kathleen Moriarty | IESG state changed to AD Evaluation from Publication Requested |
2016-08-15
|
17 | Justin Richer | 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 … 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. |
2016-08-15
|
17 | Justin Richer | Responsible AD changed to Kathleen Moriarty |
2016-08-15
|
17 | Justin Richer | IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up |
2016-08-15
|
17 | Justin Richer | IESG state changed to Publication Requested |
2016-08-15
|
17 | Justin Richer | IESG process started in state Publication Requested |
2016-08-15
|
17 | Justin Richer | Tag Doc Shepherd Follow-up Underway cleared. |
2016-08-14
|
17 | Göran Selander | Changed document writeup |
2016-08-14
|
17 | Göran Selander | Changed document writeup |
2016-08-14
|
17 | Jim Schaad | New version available: draft-ietf-cose-msg-17.txt |
2016-08-13
|
16 | Kepeng Li | Notification list changed to "Goeran Selander" <goran.selander@ericsson.com> |
2016-08-13
|
16 | Kepeng Li | Document shepherd changed to Göran Selander |
2016-08-10
|
16 | Jim Schaad | New version available: draft-ietf-cose-msg-16.txt |
2016-07-25
|
15 | Jim Schaad | New version available: draft-ietf-cose-msg-15.txt |
2016-07-20
|
14 | Justin Richer | Tag Doc Shepherd Follow-up Underway set. |
2016-07-20
|
14 | Justin Richer | IETF WG state changed to WG Consensus: Waiting for Write-Up from In WG Last Call |
2016-06-23
|
14 | Jim Schaad | New version available: draft-ietf-cose-msg-14.txt |
2016-06-17
|
13 | Jim Schaad | New version available: draft-ietf-cose-msg-13.txt |
2016-05-27
|
12 | Justin Richer | IETF WG state changed to In WG Last Call from WG Document |
2016-05-12
|
12 | Jim Schaad | New version available: draft-ietf-cose-msg-12.txt |
2016-03-21
|
11 | Jim Schaad | New version available: draft-ietf-cose-msg-11.txt |
2016-02-07
|
10 | Jim Schaad | New version available: draft-ietf-cose-msg-10.txt |
2015-12-16
|
09 | Jim Schaad | New version available: draft-ietf-cose-msg-09.txt |
2015-11-22
|
08 | Jim Schaad | New version available: draft-ietf-cose-msg-08.txt |
2015-11-03
|
07 | Jim Schaad | New version available: draft-ietf-cose-msg-07.txt |
2015-10-17
|
06 | Jim Schaad | New version available: draft-ietf-cose-msg-06.txt |
2015-09-21
|
05 | Jim Schaad | New version available: draft-ietf-cose-msg-05.txt |
2015-08-28
|
04 | Jim Schaad | New version available: draft-ietf-cose-msg-04.txt |
2015-08-09
|
03 | Jim Schaad | New version available: draft-ietf-cose-msg-03.txt |
2015-07-20
|
02 | Jim Schaad | New version available: draft-ietf-cose-msg-02.txt |
2015-07-05
|
01 | Jim Schaad | New version available: draft-ietf-cose-msg-01.txt |
2015-07-05
|
00 | Justin Richer | Intended Status changed to Proposed Standard from None |
2015-07-05
|
00 | Justin Richer | Importing draft-schaad-cose-msg as starting point for WG document. |
2015-07-05
|
00 | Justin Richer | This document now replaces draft-schaad-cose-msg instead of None |
2015-07-05
|
00 | Justin Richer | New version available: draft-ietf-cose-msg-00.txt |