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:stephen.farr...@cs.tcd.ie] > Sent: Sunday, October 16, 2016 1:57 PM > To: The IESG <i...@ietf.org> > Cc: draft-ietf-cose-...@ietf.org; Goeran Selander > <goran.selan...@ericsson.com>; cose-cha...@ietf.org; > goran.selan...@ericsson.com; firstname.lastname@example.org > 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 > 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/ > > > > ---------------------------------------------------------------------- > 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. > > (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 . I suspect it'd be better to > refer to > the draft as that should be published soon. (Same for RFC3447 btw.) > >  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. > >  https://www.ietf.org/mail-archive/web/secdir/current/msg06801.html _______________________________________________ COSE mailing list COSE@ietf.org https://www.ietf.org/mailman/listinfo/cose