> -----Original Message-----
> From: Rob Wilton (rwilton) <[email protected]>
> Sent: Friday, June 19, 2020 8:08 AM
> To: Jim Schaad <[email protected]>; 'The IESG' <[email protected]>
> Cc: [email protected]; [email protected];
> [email protected]; 'Matthew Miller' <[email protected]>
> Subject: RE: Robert Wilton's No Objection on
> draft-ietf-cose-rfc8152bis-algs-09:
> (with COMMENT)
>
> Hi Jim,
>
> Sorry, but I'm still struggling to fully understand the capability text.
> That may
> be because it is too far out of my domain of expertise, or it may be because
> the
> text is unclear. It is also worth noting that I've not read the entire
> document,
> just the diffs. Also note that these are just comments intended to help the
> readability of the document, they don't block the progression of the document,
> so the authors are at liberty to ignore them if they choose.
While this is frustrating to me at the moment. I think we are still making the
document better so I am still willing to try and do some slogging through
things.
>
> From the latest text on github, the things that I don't fully understand, or
> potentially find the text somewhat confusing are:
>
>
> "This means that if one wishes to enumerate all of the capabilities for a
> device
> which implements ECDH, it requires multiple pairs of capability structures
> (algorithm, key) to deal with the different key types and curves that are
> supported."
>
> 1. Is the use of a pair of capabilities (algorithm capabilities, key
> capabilities)
> normative, or just an example usage? I.e. is this one way that this could be
> achieved, or the only way that this would be achieved.
This is just and example usage. I am going to reword to talk about
combinations rather than pairs. And point to the cross product structure for
the ECDH element in the last example.
>
>
> "Just an algorithm capability: This is useful if you want to require a
> specific
> algorithm such as ECDSA, but you are agnostic about which curve is being used.
> See the first example."
>
> 2. Is the capability actually saying that a specific algorithm is being used,
> or is it
> that a particular key type is being used for the algorithm? [Given that the
> algorithm capabilities don't encode the choice of algorithm.]
]JLS] It is saying the second statement given that the specific algorithm is
not part of the capability. And yes I am beginning to really regret that
decision.
>
>
> "Just a key type capability: This is useful if you want to require a specific
> curve
> such as P-256, but will accept any algorithm using that curve (e.g. both ECDSA
> and ECDH). See the second example."
>
> 3. Presumably this example is also constraining the key type to EC2 as well as
> the curve to P-256?
[JLS] Good point - added the text.
>
>
> "Both an algorithm and a key type capability: This is used if one needs to
> nail
> down all of the options surrounding an algorithm E.g. EdDSA with the curve
> X25519. See the third example which just concatenates the two capabilities
> together."
>
> 4. Am I right to ensure that a separate specification, where the capabilities
> structures are being used, would specify that the capabilities are defined as
> an
> array of algorithm capabilities followed by key value capabilities. [Related
> to
> comment 1 above.]
[JLS] That would be one way that it could be used. If you look at how it is
used in draft-ietf-core-oscore-groupcomm, there is an array of multiple items
of which one set each of algorithm and key type capabilities are but two of
them. These are then used as part of a key derivation process to make sure
that everybody is agreeing on what is being used. However the view you gave
does look like what I did in example 3.
>
>
> Nits:
>
> I would suggest that it would be better to switch the order of "8.2
> Assignments
> for Existing Algorithms" and "8.1 Assignments for Existing Key Types", since
> elsewhere in this section the text always talks about algorithms before key
> types.
>
> In the examples, you may want to remind that the algorithm type is not
> included in the capability data because it should already be known from
> elsewhere.
>
> Finally, in the examples, you might wish to rephase to avoid second person
> language, such as using "you".
[JLS] All of these things are good and done.
Thanks for working with me.
Jim
>
> Regards,
> Rob
>
>
> > -----Original Message-----
> > From: Jim Schaad <[email protected]>
> > Sent: 18 June 2020 18:55
> > To: Rob Wilton (rwilton) <[email protected]>; 'The IESG'
> > <[email protected]>
> > Cc: [email protected]; [email protected];
> > [email protected]; 'Matthew Miller' <[email protected]>
> > Subject: RE: Robert Wilton's No Objection on
> > draft-ietf-cose-rfc8152bis-
> > algs-09: (with COMMENT)
> >
> > Rob,
> >
> > I have spent way too long trying to do edits and re-writes and
> > additions and deletions on this. I don't think that I can even read it
> > anymore.
> > However, https://cose-wg.github.io/cose-rfc8152bis/draft-ietf-cose-
> > rfc8152bis-algs.html#name-cose-capabilities has an updated version of
> > this that I think will address all of your comments. Please review.
> >
> > Thanks, Jim
> >
> >
> >
> > -----Original Message-----
> > From: Rob Wilton (rwilton) <[email protected]>
> > Sent: Wednesday, June 10, 2020 4:03 AM
> > To: Jim Schaad <[email protected]>; 'The IESG' <[email protected]>
> > Cc: [email protected]; [email protected];
> > [email protected]; 'Matthew Miller' <[email protected]>
> > Subject: RE: Robert Wilton's No Objection on
> > draft-ietf-cose-rfc8152bis-
> > algs-09: (with COMMENT)
> >
> > Hi Jim,
> >
> > Please see inline ...
> >
> > > -----Original Message-----
> > > From: Jim Schaad <[email protected]>
> > > Sent: 10 June 2020 00:13
> > > To: Rob Wilton (rwilton) <[email protected]>; 'The IESG'
> > > <[email protected]>
> > > Cc: [email protected]; [email protected];
> > > [email protected]; 'Matthew Miller' <[email protected]>
> > > Subject: RE: Robert Wilton's No Objection on
> > > draft-ietf-cose-rfc8152bis-
> > > algs-09: (with COMMENT)
> > >
> > >
> > >
> > > -----Original Message-----
> > > From: Robert Wilton via Datatracker <[email protected]>
> > > Sent: Tuesday, June 9, 2020 11:16 AM
> > > To: The IESG <[email protected]>
> > > Cc: [email protected]; [email protected];
> > > [email protected]; Matthew Miller <[email protected]>;
> > > [email protected]
> > > Subject: Robert Wilton's No Objection on
> > > draft-ietf-cose-rfc8152bis-algs-
> > > 09: (with COMMENT)
> > >
> > > Robert Wilton has entered the following ballot position for
> > > draft-ietf-cose-rfc8152bis-algs-09: No Objection
> > >
> > > 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-rfc8152bis-algs/
> > >
> > >
> > >
> > > --------------------------------------------------------------------
> > > --
> > > COMMENT:
> > > --------------------------------------------------------------------
> > > --
> > >
> > > Hi,
> > >
> > > I've only reviewed the diff against RFC8152. The vast majority of this
> > > document seemed to have only minimal changes and looked fine from
> > > what I could see.
> > >
> > > A few minor comments that may help improve the document:
> > >
> > >
> > > 8. COSE Capabilities
> > >
> > > Two different types of capabilities are defined: capabilities for
> > > algorithms and capabilities for key structures. Once defined by
> > > registration with IANA, the list of capabilities is immutable. If it
> > > is later found that a new capability is needed for a key type or an
> > > algorithm, it will require that a new code point be assigned to deal
> > > with that. As a general rule, the capabilities are going to map to
> > > algorithm-specific header parameters or key parameters, but they do
> > > not need to do so. An example of this is the HSS-LMS key
> > > capabilities defined below where the hash algorithm used is included.
> > >
> > > Defining the capabilities list as immutable seemed like a misnomer
> > > to me because a new IANA registration would mutate the list.
> > > Perhaps this sentence, and the one following it, could be removed?
> > > [JLS] The whole object is that once registered with IANA, it will
> > > never be changed even by IANA. Thus I believe that the word
> > > immutable seems to be correct. If this is changed then existing
> > > signatures will fail and key derivation functions will generate different
> results.
> > [RW]
> >
> > I'm still slightly confused, and alas the more I read the text the
> > more confused I become ;-)
> >
> > Hence a clarifying question: Does "the list of capabilities is
> > immutable", does it mean that the list of capabilities associated with
> > a given algorithm or key structure is immutable? Or does it mean that
> > the entire list of defined capabilities as a set is immutable?
> > [JLS] The intention is to say that it is fixed for a single algorithm
> > or key type and not the entire list.
> >
> > And in the following paragraph, where is states "The capability
> > structure is an array of values" does it mean the capability structure
> > associated with a particular algorithm or key?
> > [JLS] Yes
> >
> > Another question relates to "The capability structure is an array of
> > values,", does this mean "The capability structure for a given
> > algorithm or key is an ordered array of values, the order ... "
> > [JLS] Yes
> >
> > The paragraph below also mentions multiple pairs of capability structures.
> > Do the capabilities always come as a pair of an algorithm and a key?
> > If there are multiple pairs then how are they encoded, presumably as
> > an array of pairs? If capabilities do not always come as a pair then
> > you do you differentiate between a capability defining an algorithm
> > and one defining a key?
> >
> > >
> > > The capability structure is an array of values, the order being
> > > dependent on the specific algorithm or key. For an algorithm, the
> > > first element should always be a key type value, but the items that
> > > are specific to a key should not be included in the algorithm
> > > capabilities. This means that if one wishes to enumerate all of the
> > > capabilities for a device which implements ECDH, it requires multiple
> > > pairs of capability structures (algorithm, key) to deal with the
> > > different key types and curves that are supported. For a key, the
> > > first element should also be a key type value. While this means that
> > > this value will be duplicated if both an algorithm and key capability
> > > are used, the key type is needed in order to understand the rest of
> > > the values.
> > >
> > > Should you be using RFC 2119 language here? And should " key should
> > > not be included" be "MUST NOT"?
> > > [JLS] Responded to this point in Roman's comments.
> > >
> > > For the ECDH case, does that mean that the "algorithm" entry will be
> > > duplicated with different "key" entries? If so, would it help
> > > clarify to explicitly state this?
> > > [JLS] Would pointing to the second and third examples in section 8.3
> > > along with some explanatory text?
> > [RW]
> >
> > Perhaps, but I think that it would also be useful to have an example
> > of supporting ECDH-ES with both P-256 and X25519 curves, and how that
> > would be encoded (if that makes sense).
> >
> > I also couldn't convince myself that the numerical values that are
> > used in the examples are necessary right, please can you check that they
> > are.
> > E.g., the first two example have the same numeric encoding, and the
> > two ECDH-ES have different encodings of the algorithm. But perhaps
> > that is just my confusion about how this works.
> >
> > Regards,
> > Rob
> >
> >
> > >
> > > Jim
> > >
> > > Thanks,
> > > Rob
> > >
> > >
> >
_______________________________________________
COSE mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cose
