On Tue, Mar 05, 2013 at 01:20:10AM +0100, Martin Rex wrote:
> > Thus my reading of 6698 is that usage 3 (and 1) obviate any
> > requirement for name validation, which should only apply with
> > certificate usage 2 and 0.
>
> I would actually very dislike such an interpretation, and require the
> name validation for *ALL* variants of X.509 certificates.
This dislike translates into an important lost feature, no support
for direct binding of a service end-point to a public-key sans all
the baggage of the legacy public CA PKI.
The additional name check is, as I pointed out upthread, simply an
opportunity to fail with no security gain. Why should we force the
client to fail when it has all the information required to succeed?
This, I think, makes little sense.
Yes, we can suggest to server operators that their certs SHOULD
carry a name that may be acceptable to legacy public CA PKI clients,
(if they are indeed signed by such legacy public CAs, for example,
today most SMTP certs are self-signed and one only gets protection
from passive eavesdroppers). Telling clients that they MUST reject
certs that don't have a corresponding CA-blessed name, even though
they have an authoritative DANE binding to the EE cert would be a
real shame.
My (not outlandish) view is that the legacy public CA X.509 PKI is
a sinking ship. There is little reason to entrench its semantics
into new protocols except as an optional transition aid.
> For usage DNS usage (1) it would actively subvert the name binding
> that the public CA (from the Web Browser X.509 PKI) placed into the
> certificate.
Hallelujah! I thought that the whole point of DANE was to actively
subvert the public CA model (be it over time). I place as little
faith as possible in the name bindings provided by public CAs and
hope to some day be entirely unencumbered by such faith.
When the service operator publishes a DNSSEC public key binding
(binds the service end-point to an EE certificate), that binding
should suffice.
> What about other cert attributes in DANE usage (1)
> (such as BasicConstraints, KeyUsage, ExtendedKeyUsage, NameConstraints,
> Certificate Policies, PolicyConstraints and Validity)?
If a client application performs PKIX trust path validation for
certificate usage 1, it will check everything relevant for that.
> The end users, some of which sometimes actually look at the attributes
> of X.509 certs, would get totally confused by such weird rules.
With DANE, and EE certificate bindings any UI should simply indicate
that the certificate is bound to the end-entity (service host/port)
via secure DNS. The content of the certificate is irrelevant it is
just an ephemeral public key that could be rotated daily!
Smaller certificates use less bandwidth. This is the sort of lean
and mean certificate (303 bytes of DER) I plan to deploy on MX host
MTAs (bare minimum extensions to support TLS key usage).
$ openssl x509 -in cert.pem -text
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 1 (0x1)
Signature Algorithm: ecdsa-with-SHA256
Issuer:
Validity
Not Before: Mar 5 01:33:43 2013 GMT
Not After : Mar 5 01:33:43 2014 GMT
Subject:
Subject Public Key Info:
Public Key Algorithm: id-ecPublicKey
Public-Key: (256 bit)
pub:
...
ASN1 OID: prime256v1
X509v3 extensions:
X509v3 Basic Constraints:
CA:TRUE
X509v3 Key Usage:
Digital Signature, Key Encipherment
X509v3 Extended Key Usage:
TLS Web Server Authentication, TLS Web Client
Authentication
Signature Algorithm: ecdsa-with-SHA256
...
-----BEGIN CERTIFICATE-----
MIIBKzCB0aADAgECAgEBMAoGCCqGSM49BAMCMAAwHhcNMTMwMzA1MDEzMzQzWhcN
MTQwMzA1MDEzMzQzWjAAMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE7a1YF62n
6XjcPzMGZGjsxSzlJPyq7B5J/q8FNdkS3LG2RrjmlxgjnzIkuzOCHP2AK8z2sKkF
36XRiiVI8X+NeaM8MDowDAYDVR0TBAUwAwEB/zALBgNVHQ8EBAMCBaAwHQYDVR0l
BBYwFAYIKwYBBQUHAwEGCCsGAQUFBwMCMAoGCCqGSM49BAMCA0kAMEYCIQDRTRJU
qwUrkoju65eONV2WcijOh5vxFX6K0AA2cy0oOQIhAK7bv88ee71coa9chdB/YIOD
+9FvyHx3wLebt4clSEzr
-----END CERTIFICATE-----
> For Usage (3) it should be trivial for the server admin to provide
> a correct server cert where the name matching succeeds, without confusing
> any users that may occasionally look at the server cert.
Not when the same key-pair is fielded on a cluster of hosts, and
one wants to avoid minting new certs each time a host joins or
leaves the cluster. Administration is much simpler when all one
needs to do is point another CNAME to the same TLSA record:
$ dig +noall +ans -t tlsa _25._tcp.open.nlnetlabs.nl
_25._tcp.open.nlnetlabs.nl. 10190 IN CNAME 3.1.1._dane.nlnetlabs.nl.
3.1.1._dane.nlnetlabs.nl. 10190 IN TLSA 3 1 1 0D1FCBD71686199607A...
$ dig +noall +ans -t tlsa _587._tcp.open.nlnetlabs.nl
_587._tcp.open.nlnetlabs.nl. 10200 IN CNAME 3.1.1._dane.nlnetlabs.nl.
3.1.1._dane.nlnetlabs.nl. 10182 IN TLSA 3 1 1 0D1FCBD71686199607A...
I have started the implementation of DANE TLSA support for Postfix
2.11, the plan is to map 1/3 to the "fingerprint" security level
(trust a specified EE cert) and 0/2 to the "verify" security level
(trust a specified set of CAs).
With 0/2, naturally the certificate peer name binding asserted by
the CA will be checked against the DNSSEC validated MX hostname.
With 1/3 it will not, there is no reason to fail when success is
an option.
--
Viktor.
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
