Re: [dane] "Name Checks are not appropriate for CU=3"

[[e-mail] (Martin Rex)]

Viktor Dukhovni wrote:
>
> Yes, and in fact there need not be any subjectAltNames, the subject
> DN may be an empty sequence, and the certificate may be either
> already expired, not yet valid, or both.  With usage 3 the TLSA
> record binds the service end-point directly to a public key, the
> certificate itself is just a public-key container.
> 
> Certificate:
>     Data:
>         Version: 3 (0x2)
>         Serial Number: 1 (0x1)
>         Signature Algorithm: ecdsa-with-SHA256
>         Issuer: 
>         Validity
>             Not Before: Jan 14 16:25:19 2014 GMT
>             Not After : Jan 13 16:25:19 2014 GMT
>         Subject: 
>         Subject Public Key Info:
>             Public Key Algorithm: id-ecPublicKey
>                 Public-Key: (256 bit)
>                 pub: 
>                     04:ae:38:28:5a:22:68:0b:40:6d:51:c3:14:17:4d:
>                     99:51:50:21:88:0f:01:c2:a3:0d:f2:02:28:07:a4:
>                     93:07:22:fd:e9:82:88:f9:6e:da:4c:43:3f:3e:24:
>                     4b:9d:aa:fe:8e:6a:f7:af:48:e1:7b:e5:25:77:05:
>                     ec:37:d9:54:8a
>                 ASN1 OID: prime256v1
>     Signature Algorithm: ecdsa-with-SHA256
>         30:45:02:20:3b:cf:71:f5:21:ce:69:2f:82:49:37:ee:ee:7b:
>         4d:f9:6a:36:a9:f6:f4:9c:29:43:f8:51:b0:b2:dc:63:9a:c8:
>         02:21:00:e2:2f:d2:61:ef:3b:56:c0:4a:a4:3e:e0:67:17:9c:
>         7c:3b:41:b1:7e:f0:23:22:7d:55:80:aa:4d:85:a1:0f:05


Excuse me while I panic.

Don't be surprised if the above will be unconditionally rejected by some
PKIX software (because it is not well formed and should fail
plausibility checks in the certificate parser).

AFAIK, the issuer field of an X.509v3 certficate must never be empty,
and the subject field can only be empty if a non-empty subjectAltName
is present.

-Martin