Subject: [dane] TA certs at depth 0?

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 20 Mar 2013 21:37:32 +0000

With certificate usage 0/2, if the server certificate from the TLS
handshake is in fact the trust anchor itself, rather than something
else signed (perhaps indirectly) via the trust anchor, is that OK?

Should a DANE client accept the chain?  Should it still apply name
checks? I wasn't able to divine an answer from RFC 5280 (PKIX).

At the moment, I am not treating depth zero specially, so a trust
achor's own certificate is accepted and in that case required to
match the MX domain or validated MX hostname.

-- 
	Viktor.

---

From: Scott Schmit <[email-masked]>
Date: Wed, 20 Mar 2013 23:56:41 -0400

> match the MX domain or validated MX hostname.

Ah yes, this issue spawned a lengthy discussion a little over a year
ago.  The discussion starts here:
https://www.ietf.org/mail-archive/web/dane/current/msg03997.html

The direct answer to your question might be this email here:
https://www.ietf.org/mail-archive/web/dane/current/msg04196.html
but it's hard to say if it does or not.  Exactly how to handle the chain
in a spec-compliant way depends on specifics of the server's
certificate and the TA and your email doesn't really specify those
details.

Take a look at the above links, I think you'll see what I mean.

In the end, client-side inconsistency on this point was one of the
drivers for us defining usage 3 (while some clients would allow it,
others would not, so a case that a TLSA publisher could rely on to work
the way they want was needed).

HTH

-- 
Scott Schmit

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 21 Mar 2013 06:55:04 +0000

On Wed, Mar 20, 2013 at 11:56:41PM -0400, Scott Schmit wrote:

> > anchor's own certificate is accepted and in that case required to
              ^^^
> details.

My question is I guess more specifically about a certusage 2 TA (
which is hypothetically also the server certificate, so the "and"
above is a conjunction of two references to the same thing).

I am more interested in doing the reasonaly sensible thing than
the maximally spec-compiant thing.  Do we expect any appreciable
number of domain owners to publish (perhaps inadvertently) "IN TLSA
2 x y ..." rather than "IN TLSA 3 x y ..." for the same self-signed
key-pair (dressed in X.509v3 finery)?

If yes, should we make them suffer their mistake (if this is a
mistake) by failing, or just reason that we have the public key of
the TA (from the one and only certificate in play) and separately,
though it be a clone, a certificate signed by that TA, and just
proceed as we would for any TA->leaf chain (including expiration
date checks, name checks, ...).

I'm not looking to reopen old wounds, or try to propose or impose
my own views, rather is there a clear consensus on the semantics
of the self-signed certificate below published with a "2 x y" TLSA
record, when I am connecting to "mail.example.com" which presents
this self-signed certificate? What does it mean?
      
      - Must it be rejected? (Perhaps 5280 suggests this is so).

      - If not, do the validity dates apply? (If a trust anchor is
        just a public and certificates just a convenient container,
        arguably not, but we do seem to care about the dates in public
        CA certs.)

      [ I guess I should also ask whether the expiration dates of
	non-degenerate TA certificates that matter with "IN TLSA 2 x y"
	resource records.  At the moment I don't accept expired TA certs.

	Should any of the DANE WG RFCs explicitly cover this ground, rather
	than just defer to the rather dense 5280?  These finer points of
	PKIX are not obvious when one is obtaining TAs from a new source
	that has its own claim to authenticity and an independent validity
	interval via signed DNSSEC RRsets? ]

      - Does the "CN" (or subjectAltName:DNS) matter?  (The server has
        the CA cert in hand, he can sign any name he wants.)

      - Does it matter whether the TLSA record is a "2 0 0" or
        are we in the same boat with any "2 x y" describing the
        same self-signed leaf CA/server.

Example:

  $ cat example.bash
  #! /bin/bash
  openssl req -sha256 -new -noout -text 2>/dev/null \
      -config <(printf "[req]\n%s\n%s\n[dn]\n[exts]\n%s\n[alts]\n%s\n" \
                "distinguished_name = dn" \
                "x509_extensions = exts" \
                "subjectAltName=@alts" \
                "DNS=$1") \
      -newkey param:<(openssl ecparam -name prime256v1) \
        -keyout /dev/null -nodes \
      -x509 -set_serial 1 -days 365 -subj "/CN=$1"

  $ bash example.bash
  Certificate:
      Data:
          Version: 3 (0x2)
          Serial Number: 1 (0x1)
      Signature Algorithm: ecdsa-with-SHA256
          Issuer: CN=mail.example.com
          Validity
              Not Before: Mar 21 06:21:45 2013 GMT
              Not After : Mar 21 06:21:45 2014 GMT
          Subject: CN=mail.example.com
          Subject Public Key Info:
              Public Key Algorithm: id-ecPublicKey
                  Public-Key: (256 bit)
                  pub: 
                      04:58:4a:6a:8a:42:d6:6a:d6:33:a5:27:95:3c:8b:
                      a0:54:e1:9d:df:b7:99:70:76:63:7e:48:e8:d0:54:
                      1a:dd:f7:69:e4:13:1e:5e:b1:13:2e:66:c6:08:4c:
                      34:23:e6:84:59:e9:ec:97:fd:9b:6e:ca:e4:76:91:
                      37:38:8d:6e:e9
                  ASN1 OID: secp256k1
          X509v3 extensions:
              X509v3 Subject Alternative Name: 
                  DNS:mail.example.com
      Signature Algorithm: ecdsa-with-SHA256
           30:44:02:20:56:c3:44:e0:10:67:f1:97:24:fc:e5:2a:fb:55:
           70:66:2c:ef:84:b6:57:7e:1d:bc:a7:1c:06:94:51:cf:7e:5c:
           02:20:64:95:f8:fa:74:d8:b3:c1:f5:1e:54:71:45:2a:a4:ab:
           89:23:6e:1a:f6:17:a2:22:f7:50:cd:00:bc:f5:3b:de

-- 
	Viktor.

---

From: Scott Schmit <[email-masked]>
Date: Thu, 21 Mar 2013 10:06:57 -0400

> My question is I guess more specifically about a certusage 2 TA (

(Cutting to the chase, using the cert you provided below, I think you
can defend allowing it be used with cert usage 2, read further for
details.)

> above is a conjunction of two references to the same thing).

Right, but certificate processing/TLS code will treat different cases of
that differently, depending on how they interpreted the PKIX & TLS
specs.  And there *is* more than one case of that:

If the CA flag is set, some (most?) TLS software will reject it because
it's not an EE cert.  If the CA flag is not set, some PKIX software will
reject it because it requires TAs to have the CA flag set.  Some PKIX
software will reject the certificate because the path length is 0.
Others will not because they interpreted PKIX differently.

In practice, it will probably work on most clients, but not all.  So
if you decide to accept it, you'll likely have a lot of company.  That
said, this widespread confusion about what the specs say will likely
drive most people who aren't interested in establishing their own
certificate hierarchy to usage 3 just to be sure it'll work everywhere.

> I'm not looking to reopen old wounds, [...]

As I recall the discussion from last time, it's more that this is a case
that seems quite straightforward, but actually turns out to be a deep
corner case of the various specs (despite being really widely used).

The arguments end up being very technical & nit-picky & it just makes
peoples' heads hurt. :-)

> 	interval via signed DNSSEC RRsets? ]

AIUI, the PKIX WG owns the PKIX RFCs, so only they can issue updates,
clarifications, etc.  If the DANE WG were to try to do what you're
asking, someone would inevitably think that our interpretation is
inconsistent with PKIX (and thus not an interpretation), and it would
get slapped down (if it didn't get slapped down out of general
principal).

IIRC, the reaction when we requested clarification on how self-signed
certificates are handled by PKIX was that the PKIX WG feels the specs
are already perfectly clear on the matter, if you read the definitions
carefully.

>         same self-signed leaf CA/server.

Somewhat -- if the TLS server omits the TA from its certificate chain
but hashes it (or only provides a SPKI), and the client doesn't already
know the TA certificate, then the client will have no way to match it.

Diagnostics that this is why you aren't using that record might be
useful, but I don't think there's any reason to hardcode "x & y aren't 0
& 0, so reject!" into your code.  If the TA certificate is included in
the TLS certificate chain or it's embedded in the client's TA store, it
can work.

>            89:23:6e:1a:f6:17:a2:22:f7:50:cd:00:bc:f5:3b:de

Based on my understanding of PKIX, this should work (as long as your
software supports ECDSA):

Only the key & name matter on a TA, but other checks are a matter of
local policy.

It's an EE certificate, because there's no basic constraint saying that
this is a CA (and the certificate is X.509v3), so it's legal for a
server named mail.example.com to use as its certifiate in TLS.

It's self-signed, so if I interpret the chain as mail.example.com (as
TA) -> mail.example.com (as EE), then I have a path length of 1, and
it's legal.  (But that might depend on specifics of how path length is
determined.)

Depending on how you interepret the definition of the certificate chain
in the TLS RFC, maybe we're supposed to transmit both certs in the chain
(i.e., the same certificate twice).

But I think if the client has the full certificate via TLSA, then the
TA is "well-known" to that client and can be omitted from the chain.

So I can't see any reason to reject this certificate, even being
spec-pedantic.

Does that help?

-- 
Scott Schmit

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 21 Mar 2013 19:28:42 +0000

On Thu, Mar 21, 2013 at 10:06:57AM -0400, Scott Schmit wrote:

[ Quoting your last paragraph first: ]

> So I can't see any reason to reject this certificate, even being

Yes, thanks, I think I can largely go with what I have, what remains
to verify is the first part of the side question from my original post:

    [ I guess I should also ask whether the expiration dates of
      non-degenerate TA certificates matter with "IN TLSA 2 x y"
      resource records.  At the moment I don't accept expired TA certs. ]

So, with certificate usage 2, should I allow "expired" TA certs at
depth > 0? If the TA is to be viewed as just a public-key in X.509
garb, and in view of the fact that the expiration times are set by
some entity I may not trust (trust starts at the TA), perhaps not?

On the other hand if the TA is actually self-signed, then its own
statement about expiration times could be taken at face value (as
OpenSSL does with self-signed trust anchors in its trust store).

Bottom line, should I allow expired TA certs, and does it matter
whether they are self-signed.

> specs.  And there *is* more than one case of that:

Checking the OpenSSL x509_vfy.c source I find that:

    - The expiration time of a self-signed issuer certificates (at any
      depth including 0) is *not* ignored.  So with a typical trust chain
      starting at a public root CA, the root CA's expiration time is
      honoured.

    - OpenSSL ignores the "CA:true" vs. "CA:false" for depth 0 self-signed
      certificates.  I'll go along with that.

> it's not an EE cert.

    FWIW, OpenSSL (which Postfix uses for TLS+X509 support) does not care
    at the leaf.

> server named mail.example.com to use as its certifiate in TLS.

I'm going to let OpenSSL ignore the CA bit for me.  That way I
don't have to parse the X509 cert myself in the verification
callback.  And name checks will still apply.

-- 
	Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Sun, 24 Mar 2013 02:44:12 +0000

>       resource records.  At the moment I don't accept expired TA certs. ]

In the end, the implementation of "IN TLSA 2 1 0" and "IN TLSA 3 1 0"
leads me to treat TAs per PKIX/ITU as just public keys, and thus I
no longer check expiration dates in TA certs.

I had to put in a snippet of extra code to support zero-length "IN
TLSA 2 1 0" chains, which are somewhat easier to reject than to
accept, but the primary requirement for SMTP security is to not
fail whenever success is an option, so "IN TLSA 2 0 0" will also
be supported at depth 0, provided the server's certificate is
self-signed.

-- 
	Viktor.