I think we dealt with all of the comments. I cannot help you with getting
See below for my one issue.
> -----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; email@example.com
> Subject: Stephen Farrell's Discuss on draft-ietf-cose-msg-20: (with DISCUSS
> 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:
> Thanks for the updates in -20. I think we've only the following points left.
> 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
> on this topic.
> So, COSE chairs - what's your take? (If you say this is ok with the WG, I'll
> (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
> this is ok with the WG, I'll clear.)
> 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
> - 1.5: I'd add a reference to RFC5116.
> - 3.1, crit: The statement that security libraries or application code can
> this is odd - isn't that an API requirement? (I'm not objecting, but it's
> - 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
> 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
> be other ways around the problem too probably.)
> - 4.1: signingTime is often needed with signatures. Isn't that common enough
> 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
> key modulus, then is it clear what to put where in the signature bstr? (Yes,
> 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
> - 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
> MAC values. (And I can't recall the right thing to say off the top of my
> - 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
> 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?
> be good to provide that for such relatively complex operations I think. Is
> what you mean?
> - 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?
> 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-
> - 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