On 2016-11-01 20:17, "COSE on behalf of Jim Schaad" <[email protected] on behalf of [email protected]> wrote:
>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, Just for the record: Hannes, Abhinav and Sandeep was also on this side this time Göran > 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 _______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
