[cabf_validation] Proposed edit for domain validation method #5

[kirk_hall at trendmicro.com]

Yes, Rick, that’s right (what we are proposing).  What’s a better way to word that?

Any objections to adding that?

From: Rick Andrews [mailto:Rick_Andrews at symantec.com]
Sent: Tuesday, June 09, 2015 1:04 PM
To: Jeremy Rowley; Kirk Hall (RD-US); validation at cabforum.org
Subject: RE: Proposed edit for domain validation method #5

Are we mixing up two roots here? I think Kirk was suggesting allowing the random value to appear at the web server’s document root, not the root domain of the FQDN.

-Rick

From: validation-bounces at cabforum.org [mailto:validation-bounces at cabforum.org] On Behalf Of Jeremy Rowley
Sent: Monday, June 08, 2015 5:10 PM
To: kirk_hall at trendmicro.com; validation at cabforum.org
Subject: Re: [cabf_validation] Proposed edit for domain validation method #5

Sorry – misread your email. I thought it required posting it at the root and the FQDN (not that it was another option).  I think we should permit it at the Authorized Domain level, rather than either the FQDN or base.  I don’t see any reason to limit this to just the two levels while the rest can use any level of the domain name.

Jeremy

From: kirk_hall at trendmicro.com<mailto:kirk_hall at trendmicro.com> [mailto:kirk_hall at trendmicro.com]
Sent: Monday, June 8, 2015 5:29 PM
To: Jeremy Rowley; validation at cabforum.org<mailto:validation at cabforum.org>
Subject: RE: Proposed edit for domain validation method #5

I wasn’t trying to be more restrictive, but just give a CA more options for this method.  Do you think there is more risk in posting to the root level than to the .well-known extension level?  If so, why?

If the root level is compromised, the game is over.

From: Jeremy Rowley [mailto:jeremy.rowley at digicert.com]
Sent: Monday, June 08, 2015 4:27 PM
To: Kirk Hall (RD-US); validation at cabforum.org<mailto:validation at cabforum.org>
Subject: RE: Proposed edit for domain validation method #5

I don’t agree with this one. I think we’re restricting practical control enough with the .well-known extension as-is. I don’t think this is any riskier than the other domain validation methods where you can validate at any level of the string.

From: validation-bounces at cabforum.org<mailto:validation-bounces at cabforum.org> [mailto:validation-bounces at cabforum.org] On Behalf Of kirk_hall at trendmicro.com<mailto:kirk_hall at trendmicro.com>
Sent: Thursday, June 4, 2015 4:20 PM
To: validation at cabforum.org<mailto:validation at cabforum.org>
Subject: [cabf_validation] Proposed edit for domain validation method #5

Chris Bailey and I would like to suggest an edit to domain validation method #5 in the most recent draft.

We think that a CA should also be allowed to ask the Applicant to post the Random Value or Request Token at the home page or “root level” for the FQDN, as a second option to posting at the “well known certificate directory” location included in the current draft.

Here would be the edit (added language):

5.  Having the Applicant demonstrate control over the requested FQDN by adding a file whose name or contents include a Random Value or a Request Token to the root level or the “/.well-known/certificate” directory at an Authorization Domain in accordance with RFC 5785

There may be a better phrase to use than “root level” and we are open to suggestions.

Our thinking is that posting the marker to the root level is at least as secure as posting to the well known certificate directory location.  If the Applicant can’t control the root level, then the Applicant isn’t in control of much and shouldn’t get the cert; on the other hand, if the Applicant does control the root level and can post the marker there, it shows domain control.

Is there support for making this change?  If not, what are the arguments against it?

Kirk R. Hall
Operations Director, Trust Services
Trend Micro
+1.503.753.3088




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.






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.




<table class="TM_EMAIL_NOTICE"><tr><td><pre>
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.
</pre></td></tr></table>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/validation/attachments/20150610/5c2011e2/attachment-0001.html