Subject: [Lake] SEC-DIR review of AP-ND:

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 3 Feb 2020 13:29:06 +0000

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

---

From: Jim Schaad <[email-masked]>
Date: Mon, 3 Feb 2020 09:50:07 -0800

>From a quick run through the JOSE mailing list to refresh my memory:

1.	There is a view that on only one way should exist to do things.
Thus only either compressed or uncompressed
2.	There are still issues (at the time) about having compressed points
and patents

jim

From: Lake <[email-masked]> On Behalf Of Pascal Thubert (pthubert)
Sent: Monday, February 3, 2020 5:29 AM
To: [email-masked]
Cc: [email-masked]; Shwetha Bhandari (shwethab) <[email-masked]>;
The IESG <[email-masked]>; [email-masked]; [email-masked]; Benjamin Kaduk
<[email-masked]>
Subject: [Lake] SEC-DIR review of AP-ND:

Dear all

 

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