Phillip Hallam-Baker wrote:
> 
> But the standard is set by the consensus and the running code which
> recognize self-signed certs..
> 
> 
> I see the following courses of action as being open:
> 
> D1) DANE says nothing at all about this issue in the DANE spec (I see no
> reason it need be mentioned at all).
> 
> D2) DANE says that the EE cert can be a self signed EE cert in accordance
> with customary Internet usage
> 
> P1) PKIX writes draft on how to specify self signed EE certs so that this is
> properly understood. I.E. relying applications MUST NOT rely on any claims
> other than the POP of the key and any restrictions on validity/usage.
> 
> P2) PKIX ignores the issue.
> 
> Note that D1/2 and P1/2 are orthogonal.
> 
> 
> These certs exist and I can't see there being a consensus likely to emerge
> to require a chain with a CA cert at the head.


I have very little experience with / exposure to the discussions
in the PKIX WG, so I don't know how much I like (P1).

>From the data collected by EFF, there appear to be

  ~ 830000 self-signed X.509v3 Web Server Certs installed on the internet
           with the BasicConstraint cA=TRUE
  ~ 494000 self-signed X.509v1 Web Server Certs installed on the internet

  ~  56000 self-signed X.509v3 Web Server certs installed on the internet
           without the BasicConstraint cA=TRUE

There may be a much higher number of use case for self-signed certs
on home networks (HomeNAS, DSL-Router, Set-Top Boxes), but they're
probably irrelevant for DANE because most are on private IP-Addresses and
don't use officially registered DNS domains on their internal networks.


>
> Nor can I see a requirement
> to introduce a downref to X.509v1 to try to circumvent this.

I do not see the particular gripe that you have with X.509v1.

X.509v1 is a proper subset of X.509v3 -- nothing weird or awkard.


The beauty of X.509v1 certs is that they're *MUCH* easier to create
and hard to get wrong in an interop-impairing fashion.

And, the biggest advantage: enforcing a rule "do not accept as signers
of other certs" is trivial and fool-proof to implement, so that you
don't create immediate and serious problems when you add such
certs to the list of trusted keys for your PKI software along
with Trust Anchors from commercial CAs.

When you mix up self-signed CA certs from some web-servers into the
list of trusted keys next to rootCAs from commercial CAs, then
you may put yourself at risk today.

But what are you real options today, with programmatic clients?
Either disable the peer certificate check entirely, or add some
peers self-signed certs to the same file as the self-signed certs
of the commercial rootCAs.


-Martin