[cabfpub] Domain validation

[Doug Beattie]

Hi Kirk,

I had previously supplied this as a recommended method of validation:


·        Having the Applicant demonstrate practical control over the FQDN by the Applicant requesting and then installing a Test Certificate issued by the CA on the FQDN which is accessed and then validated via https by the CA.

We also added a defined term:

Test Certificate: A Certificate which includes data that renders the Certificate unusable for use by an application software vendor or publicly trusted TLS server such as the inclusion of a critical extension that is not recognized by any known application software vendor or a certificate issued under a root certificate not subject to these Requirements.

In this case the “Random Value” is the signature applied by the CA on the test certificate.  This could just as well be a signed challenge provided by the web server and then made available to the CA on the web server.  I believe the ACME protocol has something along these lines as well.

If we think that the current #10 is too generic and we want to break it down, then I suggest we add this back as an approved method of domain validation (it was listed as item 8 back in February)

Doug


From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of kirk_hall at trendmicro.com
Sent: Thursday, May 7, 2015 4:51 PM
To: Tim Hollebeek; Ryan Sleevi
Cc: CABFPub
Subject: Re: [cabfpub] Domain validation

Well said, Tim.  All the other practical demonstration methods (6-9) are effectively “challenge and response” mechanisms involving both the CA and Applicant, and all are pretty clear as to who, what, where, how – How is the Random Value transmitted to the Applicant, where is the Random Value placed on the Applicant’s website, who does it (for the other methods, it is the Applicant – for method 10?), even what is the exact means by which the CA verifies the Random Value was placed in the right place.

For method 10, those specifics are missing.  They need to be added or else we can’t evaluate the security of the method – and ambiguity could allow some CAs to misinterpret and implement an unsecure method.

Here is the current language that needs to be made much more specific (sorry for the haiku format, but it makes it easier to analyze this way):

Having the Applicant demonstrate control over the FQDN
by providing a TLS service on a host found in DNS for the FQDN
and having the CA
(i) initiate a TLS connection with the host and
(ii) verify a Random Value that is a in a format recognized as a valid TLS response.

Doug mentioned a different verification method where the CA sends the customer a cert from a private (untrusted) root and asks the customer to install on the FQDN being verified, then confirms it is there and issues a production cert.  Doug – can you write that up as “new” method 9 (as we have no method 3 in the current draft – we can renumber current 4-9 to be 3-8, and insert your new method as method 9)?

From: public-bounces at cabforum.org<mailto:public-bounces at cabforum.org> [mailto:public-bounces at cabforum.org] On Behalf Of Tim Hollebeek
Sent: Thursday, May 07, 2015 1:09 PM
To: Ryan Sleevi
Cc: CABFPub
Subject: Re: [cabfpub] Domain validation

In the #10 use case Gerv was discussing, the certificates are self-signed, so the TLS-ness doesn’t provide much value, so it doesn’t matter where the TLS terminates.  If we’re going to allow that, I think we should make it explicit what we’re allowing (self-signed or untrusted certificates), and also enforce the .well_known requirement for the same reasons why we did it for #6.

However, on the validation working group call, another use case was discussed, where validation *does* matter, however the validation is against a non-publicly trusted root (basically, the web site installs a test cert to prove they control the certs for the domain).  It’s an interesting use case that I think should be allowed, though I think it should be a separate enumerated method because the security model is different.

I think #10 needs to be tightened up and clarified significantly.  I’m sure this will be discussed extensively on the validation WG call in two weeks.

-Tim

From: Ryan Sleevi [mailto:sleevi at google.com]
Sent: Thursday, May 07, 2015 12:07 PM
To: Tim Hollebeek
Cc: CABFPub; Anoosh Saboori
Subject: RE: [cabfpub] Domain validation


On May 7, 2015 6:47 AM, "Tim Hollebeek" <THollebeek at trustwave.com<mailto:THollebeek at trustwave.com>> wrote:
>
> I’ll note that if you object to #6 on those grounds, you also object to #10, which is basically “do #6 via TLS, with fewer requirements around where the value must be placed.”
>
>
>
> In fact I’m starting to think that #10 should be eliminated and rolled into #6, simply by noting in #6 that for the purposes of #6, TLS with an untrusted server certificate can be used in place of HTTP.
>
>
>
> -Tim
>

No Tim, they aren't equivalent under the threat model / equivalency that Anoosh agreed as (part of) the concern.

In both the Azure and the AppEngine case, the hosting provider terminates TLS, and thus the tenant cannot influence it.

This isn't universal for all hosting scenarios (e.g. Google Compute Engine, AWS), but it does represent a material difference to the threat model that we should not consider them equivalent.

________________________________

This transmission may contain information that is privileged, confidential, and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is strictly prohibited. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format.



TREND MICRO EMAIL NOTICE

The information contained in this email and any attachments is confidential

and may be subject to copyright or other intellectual property protection.

If you are not the intended recipient, you are not authorized to use or

disclose this information, and we request that you notify us by reply mail or

telephone and delete the original message from your mail system.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/public/attachments/20150513/a9dd21a5/attachment-0001.html