Re: [6lo] [Lake] SEC-DIR review of AP-ND:

[Rene Struik <[e-mail]>]

The second part of the sentence below (see ....) did not make it to my 
earlier email. My apologies.

RS>> Reuse of the same public-private key pair with different signature 
schemes is not allowed.  See also Security Considerations, Section 7.5. <<RS

On 2/3/2020 3:46 PM, Rene Struik wrote:
> Hi Jim:
>
> Just weighing-in on this: see below.
>
> Best regards, Rene
>
> On 2/3/2020 1:16 PM, Jim Schaad wrote:
>>
>> What is following is personal opinion (although I will admit to being 
>> one of the DEs on these registries):
>>
>>  1. I don’t think that you are going to be able to start doing
>>     compressed points easily in JOSE.   It is a design philosophy
>>     that people really wanted at the time.  There was extensive
>>     discussions about getting compressed points as well as how to
>>     expressed the point format.
>>
> RS>> I would be curious what this design philosophy was: if there is a 
> record of this, that would be great. It would be particularly 
> interesting to understand the reasoning as to why for Montgomery 
> curves and twisted Edwards curves compression is a must, while for 
> short Weierstrass curves this is forbidden... This is not just so with 
> JOSE, it is also in RFC 8152 (OKP vs. EC2 distinction). It seems to be 
> pretty random. <<RS
>>
>>  1. In my opinion, table 2 should not be referencing the Curve25519
>>     in the last column.  From my point of view when curves are
>>     expressed as using different coordinate systems then you need to
>>     be expressing these as different curves.  An algorithm
>>     negotiation currently only needs to include the curve and not
>>     additionally include the point format.  This needs to be
>>     maintained.  I therefore believe that a new curve code point
>>     should be registered here.  That is the only registration that I
>>     believe needs to be done in the JOSE registries.
>>
> RS>> Please note that the different crypto types in Table 2 refer to 
> complete specifications of signature schemes, including point 
> representation, bit/byte ordering, etc. Please note that curves 
> expressed in different coordinate systems are not really different: 
> only their representations are (unfortunately, this confusion is 
> caused by heavy marketing by some people in the past). The different 
> representations, not just of curve points, but also LSB/MSB and 
> lsb/msb ordering conventions, are already captured in Table 2.  Since 
> different bit/byte ordering, even with the same curve, makes a 
> difference, representation conventions are the guiding metric, not 
> just different curve models. <<RS
>
>> 1.
>>
>>
>> Note, I find section 7.5 to be missing a small piece of guidance that 
>> might be needed.  If you use the “same” private key for both the 
>> Edwards and Weierstrass curve representations, is that a problem 
>> according to this guidance?
>>
> RS>> Reuse of the same public-private key pair with different 
> signature schemes is not allowed.  See also Security Considerations, 
> Section 7.5. <<RS
>
>> Jim
>>
>> *From:* Lake <[e-mail]> *On Behalf Of *Pascal Thubert 
>> (pthubert)
>> *Sent:* Monday, February 3, 2020 5:29 AM
>> *To:* [e-mail]
>> *Cc:* [e-mail]; Shwetha Bhandari (shwethab) 
>> <[e-mail]>; The IESG <[e-mail]>; [e-mail]; 
>> [e-mail]; Benjamin Kaduk <[e-mail]>
>> *Subject:* [Lake] SEC-DIR review of AP-ND:
>>
>> Dear all
>>
>> During SEC-DIR review, Benjamin pointed out:
>>
>> > Why do we need to allow ambiguity/flexibility as to the point 
>> representation
>>
>> > within a given Crypto-Type value (as opposed to fixing the 
>> representation as a
>>
>> > parameter of the Crypto-Type)? Alternately, what does "(un)compressed"
>>
>> > mean, as it's not really clarified directly?  Furthermore, Table 2 
>> lists an
>>
>> > "(un)compressed" representation for type 0 (over P-256), but RFC 
>> 7518 notes
>>
>> > that the compressed representation is not supported for P-256 (Section
>>
>> > 6.2.1.1).  I also am not finding the needed codepoints registered 
>> in the JOSE
>>
>> > registries to use ECDSA25519 (crypto-type 2) -- do we need to register
>>
>> > anything there?
>>
>> Any idea how we can address this?
>>
>> In particular does anyone know why RFC 7518 does not support the 
>> compressed representation for P-256? Cc’ing LAKE on the impact of this
>>
>> Pascal
>>
>
> -- 
> email:[e-mail]  | Skype: rstruik
> cell: [phone] | US: [phone]


-- 
email: [e-mail] | Skype: rstruik
cell: [phone] | US: [phone]