[cabfpub] [cabfquest] Question 5 - Domain Validation pre-ballot

Richard Wang richard at wosign.com
Fri Nov 13 21:03:08 UTC 2015


You are right.
But the Random value should be one time use only for each time validation even for the same domain next time.
WoSign is doing this way now.

Regards,

Richard

> On Nov 14, 2015, at 4:15 AM, Doug Beattie <doug.beattie at globalsign.com> wrote:
> 
> Forwarding as requested.
> 
> Jacob: Are you saying that the site operator generates and publishes the random token?  The draft language requires the CA to generate this and that the site operator demonstrates domain control by making that token visible to the CA via one of the approved methods.
> 
>  
> 
>  
> 
> From: questions-bounces at cabforum.org [mailto:questions-bounces at cabforum.org] On Behalf Of Jacob Hoffman-Andrews
> Sent: Friday, November 13, 2015 2:43 PM
> To: Robin Alden <robin at comodo.com>; 'Tim Shirley' <TShirley at trustwave.com>; kirk_hall at trendmicro.com; questions at cabforum.org
> Subject: Re: [cabfquest] [cabfpub] Question 5 - Domain Validation pre-ballot
>  
> 
> (sent to questions; please forward to public)
> 
> On 11/13/2015 06:38 AM, Robin Alden wrote:
> 2) When a CA wishes the applicant to provide a practical demonstration of control of the domain to be certified (methods 6 & 7, lines H & J) the CA passes a value to the applicant which the applicant must then use in their demonstration of control. 
> Re-use of these values is OK, provided that the value used is unique to the applicant.
> This would apply for Random Values used in methods 6, 7
> and for Request Tokens used in method 7.
> CAs may sometimes not be able to accurately identify whether the applicant for one certificate request is the same as the applicant for another and if that is the case then each certificate request (not just each applicant) will need a new value.  This may be the case for CAs who accept certificate requests through resellers or other third parties where the identification of the applicant is handled by the reseller or third party – and so is not done within the scope of an organization audited as complying with the BRs.
> FYI, there is a related thread going on on the ACME mailing list: https://mailarchive.ietf.org/arch/search/?email_list=acme&gbt=1&index=F_YbbK6KDekS3rjAlHfUTc_vdZA.
> 
> In short: For ACME DV challenges, it would be convenient for the site operator to be able to publish at a well-known URI or in DNS a list of "these accounts on CA X are authorized to issue for this domain." Such a list could include a random token, but if that random token had to vary per-authorization, it would reduce the usefulness of that construction.
> _______________________________________________
> Public mailing list
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20151113/5b67cc34/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 7208 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/public/attachments/20151113/5b67cc34/attachment-0001.p7s>


More information about the Public mailing list