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

From: Jim Schaad <[email-masked]>
Date: Tue, 1 Nov 2016 12:17:47 -0700

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, 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-masked]]
> Sent: Wednesday, October 26, 2016 9:37 PM
> To: Stephen Farrell <[email-masked]>; Justin Richer <[email-masked]>
> Cc: Jim Schaad <[email-masked]>; [email-masked]; The IESG
> <[email-masked]>; [email-masked]; [email-masked]
> 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-masked]> 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-masked]>
> >>> 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-masked] <mailto:[email-masked]>>
> >>>> 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-masked]
> >>>>>> <mailto:[email-masked]>] Sent: Sunday, October 16,
> >>>>>> 2016 1:57 PM To: The IESG <[email-masked] <mailto:[email-masked]>>
> >>>>>> Cc: [email-masked]
> >>>>>> <mailto:[email-masked]>; Goeran Selander
> >>>>>> <[email-masked]
> >>>>>> <mailto:[email-masked]>>; [email-masked]
> >>>>>> <mailto:[email-masked]>; [email-masked]
> >>>>>> <mailto:[email-masked]>; [email-masked]
> >>>>>> <mailto:[email-masked]> 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>
> >>
> >

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 1 Nov 2016 21:16:10 +0000

Hiya,

On 01/11/16 19:17, Jim Schaad 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, me and a
> couple of others on the other side.  Interestingly the antis included
> Mike who argued for this in the JOSE.

Heh. To be honest, I'm not sure what's best here. Normally if
it were just my design tastes against the WGs, I'd happily
fold. But in this case we have an appendix that says how to
not do what's a MUST in the body of the spec. And I suspect
that this could damage interop depending on whether or not
libraries follow the MUST or not.

Do we think there's a way to square this circle and somehow
get rid of the appendix to get to a result folks can all use?

Cheers,
S.

> 
> Jim
> 
> 
> 
> 
>> -----Original Message----- From: Göran Selander
>> [mailto:[email-masked]] Sent: Wednesday, October 26,
>> 2016 9:37 PM To: Stephen Farrell <[email-masked]>;
>> Justin Richer <[email-masked]> Cc: Jim Schaad
>> <[email-masked]>; [email-masked]; The IESG 
>> 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:
>> 
>> 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 
>> 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
>> 
>> 
>>>> 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,
>>>> 
>>>>> The consensus of the working group after Yokohama was to make
>>>>> the CDDL non-normative and still use it as a
>>>>> description/example format.
>>>>> 
>>>>> 
>>>>> 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.
>>>>> 
>>>>>> <[email-masked]
>>>>>> <mailto:[email-masked]>> 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:-)
>>>>>> 
>>>>>>> I think we dealt with all of the comments.  I cannot help
>>>>>>> you with getting chair response.
>>>>>>> 
>>>>>>>> <mailto:[email-masked]>] Sent: Sunday,
>>>>>>>> October 16, 2016 1:57 PM To: The IESG <[email-masked]
>>>>>>>> <mailto:[email-masked]>> Cc:
>>>>>>>> [email-masked] 
>>>>>>>> <mailto:[email-masked]>>;
>>>>>>>> [email-masked] <mailto:[email-masked]>;
>>>>>>>> [email-masked] 
>>>>>>>> <mailto:[email-masked]> 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 
>>>>>>>> The document, along with other ballot positions, can be
>>>>>>>> found here:
>>>>>>>> https://datatracker.ietf.org/doc/draft-ietf-cose-msg/ 
>>>>>>>> --- -
---
>>>>>>>> -
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>> Thanks for the updates in -20. I think we've only the following
>>> points left. Note
>>>>>>>> (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.
>>>>>>> 
>>>>>>> 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 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.)
>>>>>>>> 
>>>>>>>> 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.)
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
---
---
>>>>>>>> - 1.4: the 2nd last paragraph is unclear to me.
>>>>>>>> Probably just needs re-phrasing.
>>>>>>>> 
>>>>>>>> - 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] 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>> - 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:-)
>>>>>>>> 
l
ml>

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 1 Nov 2016 22:48:30 +0100

On 1 November 2016 at 22:16:33, Stephen Farrell ([email-masked]) wrote:
Do we think there's a way to square this circle and somehow 
get rid of the appendix to get to a result folks can all use? 

The problem is that we need the capability outlined in the appendix.
(Or, in other words, the problem is the MUST in the main body.
This should be a “MUST unless the specific conditions defined in Appendix A apply”.)

Grüße, Carsten

---

From: Göran Selander <[email-masked]>
Date: Tue, 1 Nov 2016 22:02:48 +0000

From: COSE <[email-masked]<mailto:[email-masked]>> on behalf of Carsten Bormann <[email-masked]<mailto:[email-masked]>>
Date: Tuesday 1 November 2016 at 22:48
To: Stephen Farrell <[email-masked]<mailto:[email-masked]>>, Jim Schaad <[email-masked]<mailto:[email-masked]>>, 'Justin Richer' <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, 'The IESG' <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [COSE] Stephen Farrell's Discuss on draft-ietf-cose-msg-20: (with DISCUSS and COMMENT)

On 1 November 2016 at 22:16:33, Stephen Farrell ([email-masked]<mailto:[email-masked]>) wrote:
Do we think there's a way to square this circle and somehow
get rid of the appendix to get to a result folks can all use?

And, as mentioned, we actually don’t comply with the specific conditions in Appendix A . . .

Göran

---

From: Göran Selander <[email-masked]>
Date: Tue, 1 Nov 2016 22:07:55 +0000

On 2016-11-01 20:17, "COSE on behalf of Jim Schaad" <[email-masked]
on behalf of [email-masked]> wrote:

>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
>
>
>
>
>>mandatory alg
>_______________________________________________
>COSE mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/cose

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 1 Nov 2016 22:17:38 +0000

> Just for the record: Hannes, Abhinav and Sandeep was also on this side

Sure but the count of heads isn't what matters. I'm happy that
the WG chairs evaluated the WG consensus fairly. The issue though
is that it seems that that consensus in the end may lead to
interop issues so could be worth thinking about once more.

A question: do any of the proponents think that new facts on
the ground since previous discussions in the WG have shed new
light on things in a way that might be useful?

S

---

From: Jim Schaad <[email-masked]>
Date: Wed, 2 Nov 2016 10:10:53 -0700

> From: Stephen Farrell [mailto:[email-masked]]
> Sent: Tuesday, November 01, 2016 2:16 PM
> To: Jim Schaad <[email-masked]>; 'Justin Richer' <[email-masked]>
> Cc: [email-masked]; [email-masked]; 'The IESG' <[email-masked]>; draft-ietf-
> [email-masked]

I wish I knew.  The fact that the CORE draft is not even complying with how the appendix is saying to do things almost leads me to think that we should just kill that section of the appendix and re-evaluate things later.

I can't remember where I saw it, but there was another attack that I saw where a cross key attack on an algorithm was detailed.  The reasoning behind the requirement is solid.  

I don't know what libraries are going to do about enforcing this, at present my libraries are not doing so but I cannot promise that it will not change in the future as they become more complete.  (At least require an explicit flag to violate the condition.)

Once upon a time, this is exactly the reason why documents were supposed to go from draft to proposed standard.  We could have strange things, figure out if they worked in the wild and then fix if necessary.

Jim

---

From: Göran Selander <[email-masked]>
Date: Wed, 2 Nov 2016 19:55:27 +0000

> On 2 nov. 2016, at 18:11, Jim Schaad <[email-masked]> wrote:
> 
> 
> 
> I wish I knew.  The fact that the CORE draft is not even complying with how the appendix is saying to do things almost leads me to think that we should just kill that section of the appendix and re-evaluate things. 

I'd like to understand what is the problem with how it is specified in the  CORE draft, if it is a problem. If it isn't, then either stop mandating alg + remove app A, or change Appendix A so that this case isn't discouraged. 

Göran

---

From: Jim Schaad <[email-masked]>
Date: Wed, 2 Nov 2016 21:58:38 -0700

> Sent: Wednesday, November 02, 2016 12:55 PM
> To: Jim Schaad <[email-masked]>
> Cc: Stephen Farrell <[email-masked]>; Justin Richer <[email-masked]>;
> [email-masked]; [email-masked]; The IESG <[email-masked]>;
> [email-masked]
> > I wish I knew.  The fact that the CORE draft is not even complying with how
> the appendix is saying to do things almost leads me to think that we should just
> kill that section of the appendix and re-evaluate things.

I may have misinterpreted what Göran said and this may not be the case.

Jim

> 
> I'd like to understand what is the problem with how it is specified in the  CORE
> draft, if it is a problem. If it isn't, then either stop mandating alg + remove app A,
> or change Appendix A so that this case isn't discouraged.
> 
> Göran

---

From: Göran Selander <[email-masked]>
Date: Tue, 8 Nov 2016 08:34:37 +0000

On 2016-11-03 05:58, "Jim Schaad" <[email-masked]> wrote:

>> Subject: Re: [COSE] Stephen Farrell's Discuss on
>> >> Cc: [email-masked]; [email-masked]; 'The IESG' <[email-masked]>;
>>draft-
>> ietf-
>> >> [email-masked]
>>(with
>> DISCUSS

Sorry for the delay, we have had some offline discussions.

I think the core of the problem is the desire to use COSE for multiple
purposes, in particular: 1) 1-pass stateless message forwarding and 2)
stateful message forwarding in a session; each with its requirements on
message fields. In the former case it is necessary to send the algorithm,
but not in the latter. In the latter it is necessary to send a
session/context identifier but not in the former, and moreover there is no
such field is defined in the current draft. We therefore used  'kid' for
this purpose contradicting   its intended use which led to this
discussion. But for that particular case it is easy to resolve: We can
simply defining a label for a session/context identifier, replace ‘kid’
and there are no contradictions with the current body or appendix. So I
withdraw my previous comment.

This does not solve the general issue with the appendix contradicting the
body, but I don’t think that is possible to solve if we want to support
multiple ‘modes’ of operation: Either we define explicitly different
modes, and what is required/allowed in terms of message fields for these
modes, or we define one mode and acknowledge that there may be other
modes. 

(Compare Groucho Marx: "Those are my principles, and if you don't like
them... well, I have others.” :-)

Göran