I think the random value should be tied to a single communication without reuse. For example, a single email sent to the constructed emails, a single API call, a single phone call, etc. The random value shouldn’t be tied to a method, but should be tied to a specific communication from the CA that is tied to a request. By getting rid of the reuse language, we can simplify the process and eliminate the risk associated with reuse.
From: Rich Smith [mailto:richard.sm...@comodo.com] Sent: Friday, July 28, 2017 6:38 AM To: 'Peter Bowen' <p...@amzn.com>; 'CA/Browser Forum Public Discussion List' <public@cabforum.org>; Jeremy Rowley <jeremy.row...@digicert.com> Subject: RE: [cabfpub] Random value reuse Peter, You make good points. How about something along the lines of: The CA SHALL NOT share the random value generated for methods 2 and/or 4 with the Applicant via any other method, but the CA MAY accept that random value for verification under methods 6, 7 and 10. From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Peter Bowen via Public Sent: Wednesday, July 26, 2017 12:34 AM To: Jeremy Rowley <jeremy.row...@digicert.com <mailto:jeremy.row...@digicert.com> >; CA/Browser Forum Public Discussion List <public@cabforum.org <mailto:public@cabforum.org> > Subject: Re: [cabfpub] Random value reuse Jeremy, This is an interesting question and I the answer is you cannot share a value across all five of the methods you list. Methods 2 and 4 involve sending the value privately to contacts related to the domain (either from registration data or role mailboxes). The certificate applicant does not know the random value unless they are a contact or the contact gives them the random value. The CA doesn’t care how it gets the value back for these methods. On the other hand, 6, 7, and 10 involve giving the applicant the random value and then the CA verifying the applicant could cause it to appear on something related to the domain. The CA then looks for it at the right point. If you use the same value for 2/4 and 6/7/10, then the workflow could look like: - Certificate request - You generate the random value and give it to the applicant (intending to be used for 6/7/10) - Applicant turns around and submits it back to you (as if they had gotten it from a domain contact as per 2/4) Result: No confirmation the applicant is authorized (BAD) Alternatively, you could: - Get certificate request - Send random value to one or more addressed allowed by 2/4 - Then look for the value in a location allowed by 6/7/10 Result: double confirmation (good, but beyond the minimal requirement) Maybe we should clarify this somehow in 3.2.2.4. Thanks, Peter On Jul 25, 2017, at 9:20 PM, Jeremy Rowley via Public <public@cabforum.org <mailto:public@cabforum.org> > wrote: An interesting question came up today in connection with random values used for validation. Methods 2, 4, 6, 7, and 10 permit use of a random values. Methods 2 and 4, require a unique random value per email. Methods 6, 7, and 10 do not require unique random values per request for the random value. Some customers would like to use the same random value across multiple methods (method 2, 6, and 7), having us look for the first instance of the random value, or across multiple domains. Method 6 and 7 require a unique random value per certificate request, not per domain. This means, that the same Random Value can appear in multiple DNS records at once to confirm control. The questions raised by this are: 1. Should the random value be unique per verified domain name instead of per certificate request? With email methods, use of a single email to verify multiple domain names with the same email address makes sense. I’m not sure this makes as much sense for DNS records. 2. Can multiple methods use the same random value? Can you request a random value and then the CA just scour the permitted locations to find it? This seems okay to me as nothing requires the CA to specify the method of validation associated with the Random Value, but thought I’d get other opinions. Jeremy _______________________________________________ Public mailing list <mailto:Public@cabforum.org> Public@cabforum.org <https://cabforum.org/mailman/listinfo/public> https://cabforum.org/mailman/listinfo/public
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Public mailing list Public@cabforum.org https://cabforum.org/mailman/listinfo/public
