Another thread dealing with this issue includes https://www.ietf.org/mail-archive/web/cose/current/msg00981.html - basically the subject is 'make "alg" field optional'
Usual suspects (Göran, Ludwig, Francesca) on one side, me and a couple of others on the other side. Interestingly the antis included Mike who argued for this in the JOSE. Jim > -----Original Message----- > From: Göran Selander [mailto:[email protected]] > Sent: Wednesday, October 26, 2016 9:37 PM > To: Stephen Farrell <[email protected]>; Justin Richer > <[email protected]> > Cc: Jim Schaad <[email protected]>; [email protected]; The IESG > <[email protected]>; [email protected]; [email protected] > Subject: Re: Stephen Farrell's Discuss on draft-ietf-cose-msg-20: (with > DISCUSS > and COMMENT) > > Stephen, Justin, > > About item (2) - mandatory alg header - this was discussed on different > occasions. Several voices were heard in support of a setting where a kid > identifies key and algorithm. One thread starts here: > > https://www.ietf.org/mail-archive/web/cose/current/msg00544.html > > Appendix A was the proposed solution to resolve the conflict of mandatory alg > header, but the case with only kid is discouraged, both in appendix A and in > the > section on COSE_Encrypt0 > https://tools.ietf.org/html/draft-ietf-cose-msg-23#section-5.2 > > draft-ietf-core-object-security, which is the first and currently only adopted > application of COSE, uses the COSE_Encrypt0 structure, does not have the alg > header and has a kid header (“context identifier”, recommended to be 64 bit > pseudo-random). > > > Since you ask: Of course we would prefer to apply an endorsed version of COSE > instead of making an exception from an exception. Appendix A in a sense opens > a door. When what is mandatory in the body isn’t really mandatory, it is a > smaller step to deviate from the recommendations. > > I think the contentious point was the potential non-uniqueness of kid. If I > may > wish: If we maintain mandatory alg header, then maybe some text about when > kid header only could be acceptable, for example sufficiently large random > kids, > if we agree on that? > > Göran > > > On 2016-10-26 17:12, "Stephen Farrell" <[email protected]> wrote: > > > > >Hiya, > > > >On 26/10/16 16:06, Justin Richer wrote: > >> Hi Stephen, > >> > >> Sorry for the delay on answering #2 and #6 below. After researching > >> the list archives and issue tracker, neither Kepeng nor I can find > >> discussion on either issue. If there is such discussion in the > >> archives, we would appreciate the working group members pointing us > >> all to it. > >> > >> But as such, these both seem to be items that were added to the spec > >> by the editor without controversy or contention from the working > >> group. Therefore, it does appear to reflect consensus as there were > >> no objections raised. We both think that the items are OK as is, but > >> we’d like to give the working group a couple days to respond > >> otherwise if that’s not the case for anyone. > > > >Thanks for checking. If the WG don't say they'd like a change within a > >couple of days, I'll clear the discuss. (Please do ping me though, I > >may forget;-) > > > >Cheers, > >S. > > > > > >> > >> Thank you, > >> > >> — Justin & Kepeng, as COSE chairs > >> > >> > >>> On Oct 19, 2016, at 8:59 AM, Justin Richer <[email protected]> > >>> wrote: > >>> > >>> Hi Stephen, > >>> > >>> The consensus of the working group after Yokohama was to make the > >>> CDDL non-normative and still use it as a description/example format. > >>> > >>> https://www.ietf.org/mail-archive/web/cose/current/msg00802.html > >>> <https://www.ietf.org/mail-archive/web/cose/current/msg00802.html> > >>> > >>> I believe the current draft reflects that state. Yes, CDDL syntax is > >>> peppered throughout the document as illustration, but it’s the > >>> English text that’s normative. > >>> > >>> One point that was discussed was that if the draft did not use CDDL, > >>> then another description language would likely need to be made up to > >>> make human-readable examples in the text. The group felt that it was > >>> better to use an existing (even if > >>> unfinished/unofficial) description format but remove the normative > >>> dependency. > >>> > >>> — Justin, as chair. > >>> > >>>> On Oct 16, 2016, at 3:41 PM, Stephen Farrell > >>>> <[email protected] <mailto:[email protected]>> > >>>> wrote: > >>>> > >>>> > >>>> Hiya, > >>>> > >>>> Dear cose-chairs - there is stuff in this discuss for you to deal > >>>> with. (Just putting that there in case you're not delving down into > >>>> the body of the mails:-) > >>>> > >>>> On 16/10/16 22:50, Jim Schaad wrote: > >>>>> I think we dealt with all of the comments. I cannot help you with > >>>>> getting chair response. > >>>>> > >>>>> See below for my one issue. > >>>>> > >>>>> Jim > >>>>> > >>>>> > >>>>>> -----Original Message----- From: Stephen Farrell > >>>>>> [mailto:[email protected] > >>>>>> <mailto:[email protected]>] Sent: Sunday, October 16, > >>>>>> 2016 1:57 PM To: The IESG <[email protected] <mailto:[email protected]>> > >>>>>> Cc: [email protected] > >>>>>> <mailto:[email protected]>; Goeran Selander > >>>>>> <[email protected] > >>>>>> <mailto:[email protected]>>; [email protected] > >>>>>> <mailto:[email protected]>; [email protected] > >>>>>> <mailto:[email protected]>; [email protected] > >>>>>> <mailto:[email protected]> Subject: Stephen Farrell's Discuss on > >>>>>> draft-ietf-cose-msg-20: (with DISCUSS and COMMENT) > >>>>>> > >>>>>> Stephen Farrell has entered the following ballot position for > >>>>>> draft-ietf-cose-msg-20: Discuss > >>>>>> > >>>>>> When responding, please keep the subject line intact and reply to > >>>>>> all email addresses included in the To and CC lines. > >>>>>> (Feel free to cut this introductory paragraph, however.) > >>>>>> > >>>>>> > >>>>>> Please refer to > >>>>>> https://www.ietf.org/iesg/statement/discuss-criteria.html > >>>>>> <https://www.ietf.org/iesg/statement/discuss-criteria.html> > >>>>>> for more information about IESG DISCUSS and COMMENT positions. > >>>>>> > >>>>>> > >>>>>> The document, along with other ballot positions, can be found > >>>>>> here: https://datatracker.ietf.org/doc/draft-ietf-cose-msg/ > >>>>>> <https://datatracker.ietf.org/doc/draft-ietf-cose-msg/> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>>------------------------------------------------------------------ > >>>>>>--- > >>>>>>- > >>>>>> > >>>>>> > >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. > >>>>> > >>>>> In section 1.3 the following text was added: > >>>>> > >>>>> Two syntaxes from CDDL appear in this document as shorthand. > >>>>> These are: > >>>>> > >>>>> FOO / BAR - indicates that either FOO or BAR can appear here [+ > >>>>> FOO] - indicates that the type FOO appears one or more times in an > >>>>> array > >>>>> > >>>>> The value from the table is: > >>>>> > >>>>> COSE_Signature / [+ COSE_Signature ] > >>>>> > >>>>> Section 4.1 contains the text: > >>>>> > >>>>> The CBOR object that carries the signature and information about > >>>>> the signature is called the COSE_Signature structure. > >>>>> > >>>>>> From that I think that all of the needed normative text is > >>>>>> present. > >>>> > >>>> Yeah, I get that. But then I think you've embedded some CDDL > >>>> notation at least as normative. (I mean the constructs you describe > >>>> with FOO/BAR above.) > >>>> > >>>> While I do start to feel pedantry-panic that I'm saying it, if > >>>> really treating CDDL as informative, I think you ought say in text > >>>> that one or more COSE_Signature fields need to be in a counter > >>>> signature. > >>>> > >>>> But I'm gonna clear that anyway as the whole CDDL is not normative > >>>> thing is really pretence IMO and there's no point in me joining in > >>>> with that further. > >>>> > >>>> That means that clearing this discuss is now solely down to the > >>>> chairs saying they're happy that Jim's positions do reflect wG > >>>> consensus. > >>>> > >>>> Cheers, S. > >>>> > >>>> > >>>> > >>>> > >>>>> > >>>>>> > >>>>>> (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.) > >>>>>> > >>>>>> > >>>>>> > >>>>>>------------------------------------------------------------------ > >>>>>>--- > >>>>>>- > >>>>>> > >>>>>> > >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/ > >>>>>> <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 <foo> and <bar>" 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 <foo> and then an appendix that > >>>>>> says how to do <not-foo>? > >>>>>> > >>>>>> - 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.htm > >>>>>> l > >>>>>> <https://www.ietf.org/mail-archive/web/secdir/current/msg06801.ht > >>>>>> ml> > >> > > _______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
