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

From: Stephen Nightingale <[email-masked]>
Date: Tue, 14 Jan 2014 10:57:50 -0500

Per the BCP, section 3.3 on Certificate Name Check conventions, the Note 
says that "except with certificate usage 3, where name checks are not 
applicable (see section 4.1) ....."

Section 4.1 is presently empty.  Is there a notion of populating the 
Type Specific DANE Guidelines in section 4?

 From all the above I take it to mean that if the Subject Alt Name in 
the TLS Server served certificate  differs from the domain name in the 
TLSA record (for example it offers an email address instead of a DNS 
label or wildcard), it doesn't matter because we don't check it.

Cheers,

Stephen.

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 14 Jan 2014 16:31:18 +0000

On Tue, Jan 14, 2014 at 10:57:50AM -0500, Stephen Nightingale wrote:

> Per the BCP, section 3.3 on Certificate Name Check conventions, the
> Note says that "except with certificate usage 3, where name checks
> are not applicable (see section 4.1) ....."
> 

Yes, I added the new text last week.  Wes should be reviewing it today,
so your timing is perfect.

You can grab a copy at:

	https://github.com/vdukhovni/ietf.git

> the TLS Server served certificate  differs from the domain name in
> the TLSA record (for example it offers an email address instead of a
> DNS label or wildcard), it doesn't matter because we don't check it.

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
-----BEGIN CERTIFICATE-----
MIHsMIGToAMCAQICAQEwCgYIKoZIzj0EAwIwADAeFw0xNDAxMTQxNjI1MTlaFw0x
NDAxMTMxNjI1MTlaMAAwWTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAASuOChaImgL
QG1RwxQXTZlRUCGIDwHCow3yAigHpJMHIv3pgoj5btpMQz8+JEudqv6OavevSOF7
5SV3Bew32VSKMAoGCCqGSM49BAMCA0gAMEUCIDvPcfUhzmkvgkk37u57TflqNqn2
9JwpQ/hRsLLcY5rIAiEA4i/SYe87VsBKpD7gZxecfDtBsX7wIyJ9VYCqTYWhDwU=
-----END CERTIFICATE-----

-- 
	Viktor.

---

From: [email-masked] (Martin Rex)
Date: Thu, 16 Jan 2014 16:19:59 +0100 (CET)

>         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

---

From: Stephen Kent <[email-masked]>
Date: Thu, 16 Jan 2014 11:45:56 -0500

Martin is correct. This is not well-formed cert as per RFC 5280:

4.1.2.4.Issuer

The issuer field identifies the entity that has signed and issued the

certificate.The issuer field MUST contain a non-empty distinguished

name (DN)

4.1.2.6.Subject

The subject field identifies the entity associated with the public

carried in the subject field and/or the subjectAltName extension.

We issued 5280bis in part to accommodate DANE's use of ss certs. Please 
don't
provide examples that are obviously non-complaint relative to basic PKIX and
X.509 specs.

Steve

---

From: Stephen Nightingale <[email-masked]>
Date: Thu, 16 Jan 2014 12:35:49 -0500

Granted the cert even for Cert Use DANE-EE(3) must be well-formed in 
order to see what's in it.
But I believe Victor's main point is that the only field *value* that 
matters for DANE-EE(3)
is the Public Key.  Issuer, Common Name and SubjectAltName are just 
deckchairs.

Stephen.

On 1/16/2014 11:45 AM, Stephen Kent wrote:
> We issued 5280bis in part to accommodate DANE's use of ss certs. 
> Please don't
> _______________________________________________
> dane mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dane

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 16 Jan 2014 18:08:10 +0000

On Thu, Jan 16, 2014 at 12:35:49PM -0500, Stephen Nightingale wrote:

> But I believe Victor's main point is that the only field *value*
> that matters for DANE-EE(3) is the Public Key.  Issuer, Common Name
> and SubjectAltName are just deckchairs.

Correct, the point is that DANE verification makes no use of these values,
if however underlying libraries are likely to object, certificates like
this should perhaps be avoided.  Note however, that this means that a
certificate with an empty subject DN can never be self-signed.

I'll strive to avoid publishing examples that are likely to fail
interoperability tests.  For what it is worth, OpenSSL does not
mind empty subject and issuer DNs even without a SAN extension, if
the application layer does not object.  The DANE verification code
I wrote on top of OpenSSL likewise does not object with usage
DANE-EE(3).

So my instructions to users will have to suggest something like:

	openssl req ... -subj "/CN=?"

for self signed certificates that are intended solely for DANE-EE(3) use.

-- 
	Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 17 Jan 2014 06:26:01 +0000

> I wrote on top of OpenSSL likewise does not object with usage

My updated code for essentially anonymous self-signed certificates
now generates certificates with subject and issuer set to "CN=*",
in the hope that this will encounter less friction from strict
parsers.  The extra 24 useless octets in the DER encoding of the
certificate are not prohibitive:

issuer= /CN=*
notBefore=Jan 17 05:29:38 2014 GMT
notAfter=Jan 16 05:29:38 2014 GMT
subject= /CN=*
-----BEGIN CERTIFICATE-----
MIIBBTCBq6ADAgECAgEBMAoGCCqGSM49BAMCMAwxCjAIBgNVBAMMASowHhcNMTQw
MTE3MDUyOTM4WhcNMTQwMTE2MDUyOTM4WjAMMQowCAYDVQQDDAEqMFkwEwYHKoZI
zj0CAQYIKoZIzj0DAQcDQgAEa3wTPD7Pnc0r5Jq5pwWVtOJMpDOGjfhPe3Ger2hr
r9XTMJt8gKo+qPbvokID/sqEmqf1cwh/VJtdiEaEw8f2uDAKBggqhkjOPQQDAgNJ
ADBGAiEAjTtBubyqCqIoOFArwZ/imA483U4+zSKZEgEFMTqqS9MCIQClkwwlavTu
mjagje1TSlDYuScRRstmZc9wp2bsmA1Ljg==
-----END CERTIFICATE-----

Yes I know that one can't yet field only an EC certificate even
for SMTP.  Many pre-DANE opportunistic TLS clients will have older
TLS implementations that don't support EC, but insist on a compatible
(i.e. RSA with SHA1) certificate which they promptly ignore.  The
requisite RSA-2048 certificate is ~400 octets longer:

issuer= /CN=*
notBefore=Jan 17 06:18:09 2014 GMT
notAfter=Jan 16 06:18:09 2014 GMT
subject= /CN=*
-----BEGIN CERTIFICATE-----
-----END CERTIFICATE-----

With DANE it will finally be practical to field multiple certificates,
one an with an RSA key, for clients that don't support ECDSA, and
another with an ECDSA key for those that do.  The TLSA RRset can
then list both digests.

-- 
	Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 17 Jan 2014 06:59:42 +0000

On Thu, Jan 16, 2014 at 11:45:56AM -0500, Stephen Kent wrote:

> [...]
> Please don't provide examples that are obviously non-complaint relative
> to basic PKIX and X.509 specs.

Are you referring to RFC 6818?  If so, what is the impact of Section
2 of that document?

    2.  Update to RFC 5280, Section 3.2: "Certification Paths and Trust"

       Add the following paragraph to the end of RFC 5280, Section 3.2:

    | Consistent with Section 3.4.61 of X.509 (11/2008) [X.509], we note
    | that use of self-issued certificates and self-signed certificates
    | issued by entities other than CAs are outside the scope of this
    | specification.  Thus, for example, a web server or client might
    | generate a self-signed certificate to identify itself.  These
    | certificates and how a relying party uses them to authenticate
    | asserted identities are both outside the scope of RFC 5280.

If a self-signed EE (i.e. not a CA) certificate is outside the
scope of 5280, it might seem that the issuer constraint of 5280
need not apply.

This does not mean that it is a good idea to push one's luck, but
I am curious as to whether the 5280 constraints in this thread are
or are not in scope for self-signed EE certificates?

It is perhaps the case that the question of whether a certificate
is self-issued or not is not well-formed when both the issuer and
subject fields are empty?

-- 
	Viktor.

---

From: [email-masked] (Martin Rex)
Date: Fri, 17 Jan 2014 23:50:19 +0100 (CET)

> scope of 5280, it might seem that the issuer constraint of 5280

I think you're misinterpreting this.

TLS typically comes with an software module for processing X.509
certificates that is (supposed to) follow either ITU-T X.509 or PKIX or both,
and TLS is going to be used for processing PKIX-conforming certificates
and certification pathes for quite some time to come.

The idea of DANE's use of X.509 was not to come up with a different
and incompatible interpretation of what and what not is a well-formed
X.509 certificate.  The intention (at least for some of those involved)
of DANE was to standardize a use of X.509 certificate and
certificate path validation for authentication of communication peers
as an alternative to what X.509/PKIX specifies.

Historically, how X.509 certificates that are issued by an entity
other than a CA are used by relying parties to authenticate peer
is outside of the scope of PKIX (rfc5280) essentially means, that
the exact behaviour is implementation-defined.

But when you start feeding X.509 certificates to a PKIX implementation
that are non-compliant with X.509/PKIX at the PDU level, rather than
differing only in the semantics of how to verify authenticity of
the certificate or cerification path), then you are squarely in
territory of undefined behaviour.

> subject fields are empty?

Doing stuff that is in obvious conflict with X.509 and/or PKIX is
almost unconditionally a bad idea, because it may require
modifying existing code to tolerate bogus information, which may
create/open new vulnerabilities and will result in interop problems.

There are a number of things that PKIX/rfc5280 has declared out-of-scope
(i.e. left to implementations, resulting in implementation-defined
behaviour).  One example is the presence and honoring of attributes
beyond the public key and the associated name(s) in so called
"trust anchors", in case trust anchors are distributed as X.509
certificates with attributes in them.  Some PKIX implementations will
honor (enforce) the notbefore/notafter of TrustAnchors, some may
ignore it.  Neither is PKIX-incompliant.

Your example populated the "notbefore" and "notafter" members with
conflicting values (i.e. notafter>notbefore).  This may needlessly
create a problem with implementations that check notbefore/notafter
even for trust anchors.

If you at your example with empty issuer from a programmers/API perspective
there are other potential problems.  X.509 has traditionally guaranteed
that an X.509 certificate can be (uniquely) identified by the pair
(issuer-name/serial number).  So some APIs that manage stores for certs
may be using issuer&serial as a handle to store or retrieve certs,
and the lack of an issuer name may represent an invalid function parameter
to such an API.

My recommendation is to avoid using obviously bogus examples of X.509
certificates when illustrating the use of DANE, because that is going
to cause unnecessary pain and confusion among users and implementors.

-Martin

---

From: [email-masked] (Martin Rex)
Date: Sat, 18 Jan 2014 01:14:25 +0100 (CET)

> notAfter=Jan 16 06:18:09 2014 GMT

When I've been creating self-signed certs in the past,
then with "notBefore" set to "now minus 24hours" and
"notAfter" set to Jan 1, 2038.  The latter to reduce potential
interop problems with older 32-bit PKIX implementations that may
try to convert the date into a 32-bit time_t value on ASN.1 decode.

One of these days I will have to change the code to use
a notafter "Dec 1, 2049" (so that it still encodes as UTCTime rather
than GeneralizedTime), and maybe in 10 years it will be safe to
use a value like "Dec 1, 2999".

-Martin

PS: if anyone is wondering why the "year 3000" avoidance:
    I'm just trying to be conservative in what I send out, and I've
    encountered one platform where the vendor decided that a C89
    program which passes a (64-bit) time_t that represents a date
    after 23:59:59, December 31, 3000 to some of the C89 time-related
    functions such as gmtime() should be crashed (i.e. fatally terminated)
    rather than see the behaviour described in the C89 specification.

---

From: Viktor Dukhovni <[email-masked]>
Date: Sat, 18 Jan 2014 03:21:18 +0000

> Ooops, typo, I meant (notbefore>notafter) is bogus:

My example is not intended to suggest best-practice server certificate
settings, rather it is intended to emphasize DANE client requirements.
Servers should not push their luck, but, with usage DANE-EE(3),
clients should to the extent possible accept any certificate that
matches the TLSA record, regardless of certificate details.

Sometimes extreme settings that are not recommended in practice
can best serve to make a point.  So I don't disagree with you in
fact.  The certificate I posted makes my answer to original question
in this thread as clear as possible.

-- 
	Viktor.

---

From: Stephen Kent <[email-masked]>
Date: Mon, 20 Jan 2014 09:47:17 -0500

Viktor,

> certificate with an empty subject DN can never be self-signed.
yep.
> I wrote on top of OpenSSL likewise does not object with usage
OpenSSL is a collection of libraries which do not represent a
reference implementation of 5280 or X.509 standards.
> for self signed certificates that are intended solely for DANE-EE(3) use.
Using the question mark seems OK, better than an asterisk, which might
be interpreted by some as a widlcard.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Mon, 20 Jan 2014 09:51:07 -0500

Viktor,

> scope of 5280, it might seem that the issuer constraint of 5280
The wording here was a carefully crafted compromise to deal with the
reality of ss certs vs. the X.509 and 5280 rejection of them. You could
interpret the text to say that anything goes, but violating the basic
format requirements of 5280 and its predecessors) and X.509 strikes me
as a bad mashup.
> subject fields are empty?
Self-issued is not the same same self signed, although the fine
distinction is probably not worth the list's attention.

Steve