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
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
On Mon, Jan 23, 2023 at 09:04:40PM +, 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
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
On Mon, Jan 23, 2023 at 07:01:38AM +, 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
On Mon, Jan 23, 2023 at 09:56:05AM -0500, Viktor Dukhovni wrote:
> On Mon, Jan 23, 2023 at 02:51:45PM +, Salz, Rich wrote:
>
> > > Assuming OpenSSL's d2i_PUBKEY(3) can decode these, they'll be
> > > accepted. I don't recall seeing any code to transmit point
> > > compressed public keys *to*
On Mon, Jan 23, 2023 at 02:51:45PM +, Salz, Rich wrote:
> > Assuming OpenSSL's d2i_PUBKEY(3) can decode these, they'll be
> > accepted. I don't recall seeing any code to transmit point
> > compressed public keys *to* the peer, but may have missed it,
> > wasn't looking at the codec that
> Assuming OpenSSL's d2i_PUBKEY(3) can decode these, they'll be
accepted. I don't recall seeing any code to transmit point
compressed public keys *to* the peer, but may have missed it,
wasn't looking at the codec that closely.
Looking at the file tls`.h, it appears RFC 4492 point formats are
On Mon, Jan 23, 2023 at 07:01:38AM +, John Mattsson wrote:
> Are point compressed secp256r1 RPKs supported?
There is no RPK-specific code that either accepts or rejects point
compression in ECDSA public keys received from the peer:
https://www.rfc-editor.org/rfc/rfc5480#section-2.2
