> -----Original Message-----
> From: COSE [mailto:[email protected]] On Behalf Of Stephen Farrell
> Sent: Thursday, October 06, 2016 4:05 AM
> To: Jim Schaad <[email protected]>; 'The IESG' <[email protected]>
> Cc: [email protected]; [email protected]; [email protected];
> [email protected]
> Subject: Re: [COSE] Stephen Farrell's Discuss on draft-ietf-cose-msg-19: (with
> DISCUSS and COMMENT)
>
>
> Hi Jim,
>
> On 06/10/16 04:16, Jim Schaad wrote:
> > Stephen,
> >
> > Couple of items below asking for input. However, I think that I have
> > dealt with most of the issues and will be pulling them into the
> > version on github.
>
> I'll trim to just those input'y bits...
>
>
> COMMENT:
> >>>> -------------------------------------------------------------------
> >>>> ---
> >>>>
> >>
> >>
>
> >>>> - 3.1, "all the keys may need to be checked" - really? Or do you
> >>>> mean all the keys associated with this kid?
> >>>
> >>> I thought that this said keys associated with the kid. Did you not
> >>> read it this way? If not then I will look at re-phrasing.
> >>>
> >
> > Need input
>
> If you said "all the keys associated with this kid may need to be checked"
> then I
> think it'd be clear
That seems fine - I'll get this done.
>
>
> >>>> 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/
> >>>
> >>> What if it is s/one must also/the application must also/
> >
> > Looking for comment
>
> I still think "must" isn't right and "may" is correct
I think you are wrong, but it is not worth arguing about. I'll get this in.
>
>
> >>>> - 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.)
> >>>
> >>> I am lost and don't understand what you are saying here.
> >>>
> >>> * For EC2 key types the curve is fixed, but the cryptographic
> >>> function is not fixed. * For OKP key types, the curve/cryptographic
> >>> function pair is fixed.
> >>>
> >>> This is analogous to what is happing for the PKIX world.
> >>>
> >>> Are you suggesting that something change? If so what? (Just so I
> >>> can evaluate it.)
> >
> > Request for information
>
> I'm suggesting that the key type is not needed once you know what curve you're
> dealing with and hence the "MUST check" is just adding cruft.
Right - so this is what an EC2 key looks like:
{
1:2,
-1:1,
-2:h'65eda5...de439c08551d',
-3:h'1e52ed...cd0084d19c'
}
A shared secret key looks like:
{
1:4,
-1:h'849b57...ea6c427188'
},
And a hypothetical RSA key would look like
{
1:3,
-1:h'83425...25239fa',
-2:3
}
Since label for curve is '-1', one would need to infer that it was a curve by
being an integer and then based on the curve know what the rest of the
parameters are. The key type ('1') lets you know what the negative labels are.
So you cannot infer that the curve field is a curve field based on the text
value as the same label is used multiple ways for different key types.
Jim
>
> Cheers,
> S.
>
_______________________________________________
COSE mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cose
