Hi John,
> I don't think RFC 8422 applies here.
maybe, if one of that authors are reading the list, we can get an
statement, what the intention of was.
A RFC7250 handshake takes about 1500 bytes "on the wire".
Saving 32 bytes twice is not that great improvement.
If someone want to be "better off" and uses DTLS 1.2,
then considering RFC9146 improves much more, it reduces
the number of handshake.
best regards
Achim
Am 23.01.23 um 22:04 schrieb John Mattsson:
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 TLSand
that this follows from X.509. I don't think RFC 8422 applies here.
Should there be some code to make sure that the uncompressed format is used?
If you do something, it should probably be for all SubjectPublicKeyInfo,
not just in RPKs.
The numbers I posted beforewas wrong, I think the correct sizes are:
- Uncompressed secp256r1 RPKs are 91 bytes.
- Point compressed secp256r1 RPKs are 59 bytes
- Ed25519 RPKs are 44 bytes
Cheers,
John
*From: *TLS <tls-boun...@ietf.org> on behalf of Viktor Dukhovni
<ietf-d...@dukhovni.org>
*Date: *Monday, 23 January 2023 at 16:36
*To: *tls@ietf.org <tls@ietf.org>
*Subject: *Re: [TLS] FYI, RFC7250 (raw public keys) to be supported in
OpenSSL ~3.2
On Mon, Jan 23, 2023 at 07:01:38AM +0000, John Mattsson wrote:
Hi Viktor,
Are point compressed secp256r1 RPKs supported?
- Uncompressed secp256r1 RPKs are 91 bytes.
- Point compressed secp256r1 RPKs are 59 bytes
- Ed25519 RPKs are 58 bytes
It looks to me like EC keys will be sent in their default point format,
which is set when the key pair is loaded.
I don't see any text in RFC7250 that describes how the TLS supported
point formats extension relates to EC raw public keys. On the other
hand:
https://www.rfc-editor.org/rfc/rfc8422.html#section-5.1.2
<https://www.rfc-editor.org/rfc/rfc8422.html#section-5.1.2>
seems to say that only the uncompressed format is to be used in TLS.
If so what is the right question now? Should there be some code to make
sure that the uncompressed format is used? (Rather than rely on the
private key passed through i2d_PUBKEY() to output that form by default).
--
Viktor.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
<https://www.ietf.org/mailman/listinfo/tls>
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
