Re: [websec] HPKP & different encodings of the same public key

[Brian Smith <[e-mail]>]

Jesse Wilson <[e-mail]> 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/