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 <[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
