On Tue, 5 Mar 2013, Viktor Dukhovni wrote:
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.
While I also dislike the name check, which should not be required or
looked at for non-CA use, it is not hard to generate a wildcard
certificate.
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.
While I agree here, it is kinda strange to put in a selfsigned
generated cert in DNS. If you go through the effort of putting in
a TLSA, you can also generate a proper cert for the mailserver?
When the service operator publishes a DNSSEC public key binding
(binds the service end-point to an EE certificate), that binding
should suffice.
local policy :)
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).
Loking forward to bare public key support in gnutls :)
Then there is no name binding, so everyone is happy!
Paul
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
