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
