On Wed, Mar 20, 2013 at 11:56:41PM -0400, Scott Schmit wrote:
> > At the moment, I am not treating depth zero specially, so a trust
> > anchor's own certificate is accepted and in that case required to
> > 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.
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.
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
