Jesse Wilson <[email protected]> wrote:
> Older versions of Android (which use BouncyCastle) embed the curve:
>
> SEQUENCE {
> SEQUENCE {
> # ecPublicKey
> OBJECT_IDENTIFIER { 1.2.840.10045.2.1 }
> SEQUENCE {
> INTEGER { 1 }
> SEQUENCE {
> # prime-field
> OBJECT_IDENTIFIER { 1.2.840.10045.1.1 }
> INTEGER { `01ffffffffffffff...` }
> }
> SEQUENCE {
> OCTET_STRING { `01ffffffffffffff...` }
> OCTET_STRING { `0051953eb9618e1c...` }
> }
> OCTET_STRING { `0400c6858e06b704...` }
> INTEGER { `01ffffffffffffff...` }
> INTEGER { 1 }
> }
> }
> BIT_STRING { `0004019519de800d...` }
> }
>
> This is invalid. See https://tools.ietf.org/html/rfc5480#section-2.1.1:
> "implicitCurve
and specifiedCurve MUST NOT be used in PKIX."
> But new versions of Android (which use Conscrypt/OpenSSL) reference the
> curve by name:
>
> SEQUENCE {
> SEQUENCE {
> # ecPublicKey
> OBJECT_IDENTIFIER { 1.2.840.10045.2.1 }
> # secp521r1
> OBJECT_IDENTIFIER { 1.3.132.0.35 }
> }
> BIT_STRING { `0004019519de800d...` }
> }
>
> The original certificate embeds the curve.
>
This is the only correct encoding.
> The original and roundtripped SPKI bytes are not identical.
>
Does anyone else do ASN.1 encoding in order to compute a certificate’s pin?
>
1. I recommend that you don't decode and then re-encode. Instead, I
recommend that you only verify that the curve is specified using the valid
encoding, and then compute the result using the single valid encoding
directly, without using any encoder.
> Or is it a uniquely Java problem?!
>
IIRC, older versions of OpenSSL have this problem too.
> The spec should warn that a single SPKI may have multiple conflicting
> encodings.
>
No. There's only one valid way to encode each SPKI. This makes sense if you
think about the primary goal of the DER encoding of ASN.1: It's supposed to
allow round-trip decode-encode where the output is the same as the input.
> I suggest that only encoding in the certificate should be pinned. TLS
> server administrators should also be careful to not inadvertently re-encode
> their SPKIs when doing maintenance.
>
Instead, certificates with invalid encodings should be rejected by
verifiers and nobody should produce certificates with invalid encodings.
Cheers,
Brian
--
https://briansmith.org/
_______________________________________________
websec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/websec
