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

[Ryan Sleevi]

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.

>
> -          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.

>
> -          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 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 should note that I have no strong feelings for or against DANE here,
but I am wanting to better understand the differences with regards to
DV, in terms of practice and effective end-user security. I just felt
that the original language (which I understand has been removed) may
have been deciding one way without sufficient discussion in the Forum.

>
>
>
> -Rick
>
>
>
> From: Hill, Brad [mailto:bhill at paypal-inc.com]
> Sent: Friday, October 12, 2012 3:23 PM
> To: Rick Andrews; Ryan Sleevi
> Cc: public at cabforum.org
> Subject: RE: [cabfpub] Revised document for Ballot 89 - Adopt Requirements
> for the Processing of EV SSL Certificates v.2
>
>
>
> Rick,
>
>
>
> Can you provide any examples of ways in which DANE absent PKIX provides an
> inferior chain of trust to Domain Validated certificates?  Both prove
> administrative control of a name through means ultimately rooted in the
> registrar as a trust root. (validating “what”, not “who” you are talking to)
>
>
>
>   I don’t think the CABF has any grounds to discourage such DANE options
> unless it discourages DV similarly or justifies why DV should be treated any
> differently.
>
>
>
> -Brad Hill
>
>
>
> From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On
> Behalf Of Rick Andrews
> Sent: Friday, October 12, 2012 2:57 PM
> To: Ryan Sleevi
> Cc: public at cabforum.org
> Subject: Re: [cabfpub] Revised document for Ballot 89 - Adopt Requirements
> for the Processing of EV SSL Certificates v.2
>
>
>
> Ryan,
>
>
>
> Thanks for your speedy review. You raise a good point about DANE, one which
> the entire Forum may want to debate. IMO, we (at least the CAs) should be
> united in discouraging the use of DANE options that disable PKIX chain
> validation. If browsers add DANE support for option 3 (no PKIX chain
> validation), then a phisher could set up a fake site with a self-signed
> cert, and users visiting it would receive no warning whatsoever. I believe
> there’s value if having a CA vet the certificate holder, so the user can’t
> be directed to bunkofamerica.com and get fooled into thinking it’s their
> bank.
>
>
>
> Having said that, though, I suspect DANE will involve much debate and I’d
> rather not wait to resolve that. If others agree with you, I’ll roll back
> the language to make it less contentious.
>
>
>
> What are Google’s plans for DANE support in Chrome? I suppose it will be
> dependent on platform support, since Chrome relies on the OS for crypto and
> PKI.
>
>
>
> -Rick
>
>
>
> From: Ryan Sleevi [mailto:sleevi at google.com]
> Sent: Thursday, October 11, 2012 6:23 PM
> To: Rick Andrews
> Cc: public at cabforum.org
> Subject: Re: [cabfpub] Revised document for Ballot 89 - Adopt Requirements
> for the Processing of EV SSL Certificates v.2
>
>
>
> On Thu, Oct 11, 2012 at 5:31 PM, Rick Andrews <Rick_Andrews at symantec.com>
> wrote:
>
> Colleagues,
>
>
>
> I’ve updated the document again to include feedback from Kathleen. I changed
> the title back to Guidelines as opposed to Requirements, and changed a lot
> of musts to shoulds.
>
>
>
> Please look it over again, especially browser members. If we have consensus
> on this version, I’ll advance it towards a ballot. Thanks,
>
>
>
> -Rick
>
>
>
>
> _______________________________________________
> Public mailing list
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public
>
>
>
> Rick,
>
>
>
> Thanks for taking the time to incorporate the feedback raised by the browser
> members. I think this is a very positive step forward in the document.
>
>
>
> I don't have strong feelings on the matter, and certainly haven't
> implemented anything to the effect, but I wonder what the proposed changes
> to Section 9 mean for systems that implement DANE Type 3 validation (that
> is, where DNSSEC is used to obtain the public key, independent of CA trust
> anchors). Under such scenarios, it seems like there would be some middle
> ground in the UI between a full EV indication, and the proposed change which
> is "no secure indicator".
>
>
>
> I certainly agree that if RFC 5280 / EV Treatment hasn't been followed,
> there should be no EV branding, but I'm not sure whether it's necessary to
> fully strip any security indicator - particularly if using any
> application-defined or non-RFC5280 validation logic (again, eg: DANE). I see
> three levels of validation here (with three possible UI brands) - EV, DV,
> DANE - and the current text seems to suggest that only EV/DV should be used.
>
>
>
> The original text (sans proposed addition) handled the above scenario fine,
> but I'm curious for your thoughts as to what you think the expected
> behaviour should be for such situations. I'll note this same concern also
> applies to the proposed "and should not be treated as trusted certificates"
> for section 13.
>
>
>
> For section 13 "but should try the GET method first" - perhaps "should
> prefer the GET method". This is by no means a sticking point, but it just
> seems to conflict with the "may use either" implies they could only use
> POST. "should prefer" provides directions both for implementation and
> prioritization of the attempt.