Re: [COSE] Stephen Farrell's Discuss on draft-ietf-cose-msg-20: (with DISCUSS and COMMENT)

[Kathleen Moriarty <[e-mail]>]

On Wed, Oct 26, 2016 at 11:12 AM, Stephen Farrell <[e-mail]
> 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;-)
>
>
Don't worry, I won't.  COSE closes once this moves forward :-)

Thank you,
Kathleen


> Cheers,
> S.
>
>
> >
> > Thank you,
> >
> > — Justin & Kepeng, as COSE chairs
> >
> >
> >> On Oct 19, 2016, at 8:59 AM, Justin Richer <[e-mail]>
> >> 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
> >>> <[e-mail] <mailto:[e-mail]>>
> >>> 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:[e-mail]
> >>>>> <mailto:[e-mail]>] Sent: Sunday, October 16,
> >>>>> 2016 1:57 PM To: The IESG <[e-mail]
> >>>>> <mailto:[e-mail]>> Cc: [e-mail]
> >>>>> <mailto:[e-mail]>; Goeran Selander
> >>>>> <[e-mail]
> >>>>> <mailto:[e-mail]>>; [e-mail]
> >>>>> <mailto:[e-mail]>; [e-mail]
> >>>>> <mailto:[e-mail]>; [e-mail]
> >>>>> <mailto:[e-mail]> 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>
> >
>
>


-- 

Best regards,
Kathleen