[cabf_validation] Random Value over DNS or .well-known

Kirk Hall Kirk.Hall at entrust.com
Thu May 19 10:30:35 MST 2016

My recollection was that we didn't want a CA to be able to reuse the same Random Value (posted somewhere) year after year for revetting when revetting was required.  We also didn't want a Random Value sent out by the CA to sit around unused yet still be valid - so we added a requirement that the CA must sent a new Random Value if the old one is not used within 30 days.

I'm not sure why Request Token is not included - I think early in our discussion a Request Token didn't have anything unique in it, such as a date, etc., so the CA couldn't tell if it was fresh or stale (see prior paragraph).  If we have fixed that so the Request Token's age can be determined (so it's used within 30 days, and not reused at the time of required revetting), then it can be added.

From: validation-bounces at cabforum.org [mailto:validation-bounces at cabforum.org] On Behalf Of Jeremy Rowley
Sent: Thursday, May 19, 2016 8:37 AM
To: validation (validation at cabforum.org) <validation at cabforum.org>
Subject: [cabf_validation] Random Value over DNS or .well-known

There was discussion on the call today about the following language:

If a Random Value is used, the CA or Delegated Third Party SHALL provide a Random Value unique to the certificate request and SHALL not use the Random Value after the longer of (i) 30 days or (ii) if the Applicant submitted the certificate request, the timeframe permitted for reuse of validated information relevant to the certificate (such as in Section 3.3.1 of these Guidelines or Section 11.14.3 of the EV Guidelines).

We couldn't recall what this is trying to accomplish or why it does not cover request tokens as well. Any thoughts?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/validation/attachments/20160519/eae5e1d8/attachment.html 

More information about the Validation mailing list