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.html >>>>>> <https://www.ietf.org/mail-archive/web/secdir/current/msg06801.html> >> > _______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
