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

[Jim Schaad <[e-mail]>]

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

 

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?

 

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