On Mon, Jan 23, 2023 at 09:04:40PM +0000, John Mattsson wrote:

> RFC 7250 states that "The SubjectPublicKeyInfo structure is defined in
> Section 4.1 of RFC 5280".
> 
> The encoding of secp256r1 public keys in X.509 is defined in RFC 5480
> which says that: "MUST support the uncompressed form and MAY support
> the compressed form".
> 
> My reading is that point compressed X.509 and RPK are allowed in TLS
> and that this follows from X.509. I don't think RFC 8422 applies here.

I find that reading surprising, because at least when the point formats
extension is used:

    https://www.rfc-editor.org/rfc/rfc4492#section-5.3 (bottom of page 16)

   ...                                           If the client has used
   a Supported Point Formats Extension, both the server's public key
   point and (in the case of an explicit curve) the curve's base point
   MUST respect the client's choice of point formats.  (A server that
   cannot satisfy these requirements MUST NOT choose an ECC cipher suite
   in its ServerHello message.)

which rather indicates that in *TLS* supported point formats is supposed
to cover not just the key exchange, but also the certificates.

With point formats other than "uncompressed" (or default for curve in
TLS 1.3) now deprecated, it sure seems like RPK would need to comply.

Any comments from the usual suspects (ekr, et. al.)?

Of course on the receiving side, of some implementation is more liberal
and accepts compressed there's probably little harm (provided TLSA
records or whatever the peer uses to match the expected key when/if
validating also match the compressed SPKI).

On the sending side, my reading is that the sender should probably
ensure that the transmitted form is "uncompressed" (default for
curve).  In practice, the sender's private key is likely already
in the default point format, so the "right thing" happens most
of the time, but perhaps implementations should be prepared to
DTRT in the rare case that the configured key material is in
some non-default point form.

-- 
    Viktor.

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Reply via email to