[cabfpub] Revised document for Ballot 89 - Adopt Requirements for the Processing of EV SSL Certificates v.2

Rick Andrews Rick_Andrews at symantec.com
Sat Oct 13 23:23:55 UTC 2012


Comments inline.

> -----Original Message-----
> From: Ryan Sleevi [mailto:sleevi at google.com]
> Sent: Friday, October 12, 2012 5:50 PM
> To: Rick Andrews
> Cc: Hill, Brad; public at cabforum.org
> Subject: Re: [cabfpub] Revised document for Ballot 89 - Adopt
> Requirements for the Processing of EV SSL Certificates v.2
> 
> On Fri, Oct 12, 2012 at 5:32 PM, Rick Andrews
> <Rick_Andrews at symantec.com> wrote:
> > Brad,
> >
> >
> >
> > I would say a DV cert is superior to DANE w/o PKIX because:
> >
> > -          The DV cert will conform to Baseline Requirements (minimum
> key
> > size, strong signing and hashing algorithm, acceptable validity
> period,
> > proper extensions)
> 
> Under DANE Certificate Usage Type 3, the purpose is to effectively
> deliver a public key. No other asserted information is particularly
> relevant to the connection - it's simply the provisioning of the
> peer's public key via out of bands means. This is further reflected in
> the IETF, where proposed extensions to TLS specifically recognize the
> need to avoid certificates.
> 
> So the use of a certificate is more akin to a "key delivery mechanism"
> than it is about delivering signed assertions. Issues such as validity
> period or extensions are irrelevant - they are handled at the DNSSEC
> layer.

I would say the validity period is relevant. Why do the EV Guidelines restrict EV certs to 2 years max, and the BRs restrict OV and DV to 4 years max? It seems to me that since DANE doesn't restrict how long a key is used, and doesn't even let you determine the age of the key, that's a security hole waiting to be exploited.

> > -          The DV cert would be very likely to have undergone
> automated
> > checks for weak keys, weak exponents, not on Debian weak key list,
> not on
> > internal phish lists, etc.)
> 
> "Very likely", considering that the Baseline Requirements put this as
> a SHALL (eg: MUST). However, because the Baseline Requirements do not
> currently specify any minimal assurance level, from the perspective of
> a relying party (and a browser), there is no minimum level of
> confidence that can be assessed to a CA cert here.
> 
> For example, I believe the discussions regarding Unicode "confusibles"
> highlights that even under the BR or EV certification regimes, there
> is still ample opportunity for abuse.

But with DANE w/o PKIX, it's almost certain that no checking was performed for weak keys. The person who generated the key probably won't, and the DNS operator probably won't either, because they're not required to. I can tell you that Symantec, for all its brands, checks for Debian weak keys and thousands of domains on our internal phish lists. I would guess that most major CAs also do that. 

> > -          The DV cert would contain AIA and/or CDP extensions, so if
> the CA
> > detects that the site is fraudulent, it can revoke the cert.
> 
> And how is this different from the registrar revoking the DNS
> registration (eg: due to a WIPO UDRP typosquatting claim)?
> 
> The DNSSEC approach has the potential at a greater turn-around (due to
> being constrained by the validity of the DNS response), rather than
> the 3-10 day publication period for CRLs and OCSP information.

I'm not very familiar with WIPO UDRP, but if that only covers typosquatting claims, then it doesn't cover taking down the site if it's being used for fraud.

> >
> >
> > I feel strongly that a site (either real or fake) with a self-signed
> > certificate with a 30-year validity, containing a 1024-bit Debian
> weak key,
> > no basicConstraints or CA=true should not be given the same "trusted
> cert"
> > status indicators as a DV cert.
> 
> The 30 year validity is inconsequential - it is the DNSSEC's cache
> time that provides the time validity information. Neither does the
> basicConstraints extension have any effect, since again, the
> certificate is simply a "public key delivery method" (Type 3 is very
> constrained to the *end-entity* certificate)
> 
> The only issue with this specific example is with regards to a
> 1024-bit Debian weak key, but this, along with other such "security
> failures", are checks that are being jointly implemented by both CAs
> (at time of issuance) and Browsers (at time of verification), as a
> form of defense in depth. So even under a DNSSEC/DANE regime, there is
> still defense against this class of errors.

I know of no browser that's building in Debian weak key checks. That's best done at the CA, because then we can tell the customer about it. What will a browser do? Tell the user to tell the web site operator that their key is weak?

Another point I'd like to make is that if you move away from the CA model (even with a DV cert) to a DNSSEC-based DANE w/o PKI, you're shifting your trust to the operators of the various DNS zones and domains (for DNSSEC PKI) and to millions of individual domain owners (for generating and maintaining their keys). None of those entities are subject to audit like the CAs are, and it's reasonable to assume that there are no standards and hence we'll have good ones and bad ones. That makes the end user less safe, in my opinion. Imagine Diginotar in the DNSSEC business...

-Rick



More information about the Public mailing list