Hi Viktor,
using a compression format comes with savings, but in my experience, one
of the other issues, which comes with pain for constraint IoT, is the
amount of "parameters" sent in the ClientHello. For DTLS 1.2, that's
even sent twice, if a HelloVerifyRequest is used.
A macro to enable the set recommended by Thomas and Hannes (RFC 7925,
draft-ietf-uta-tls13-iot-profile-05) helps as well.
best regards
Achim
Am 23.01.23 um 23:47 schrieb Viktor Dukhovni:
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.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
