>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 protected]> On Behalf Of Pascal Thubert (pthubert) Sent: Monday, February 3, 2020 5:29 AM To: [email protected] Cc: [email protected]; Shwetha Bhandari (shwethab) <[email protected]>; The IESG <[email protected]>; [email protected]; [email protected]; Benjamin Kaduk <[email protected]> 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
_______________________________________________ 6lo mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lo
