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

[Rene Struik <[e-mail]>]

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.  <<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]