[cabfpub] How a Certificate Is Issued - the Baseline Requirements Version

Jeremy Rowley jeremy.rowley at digicert.com
Fri Apr 14 21:29:29 UTC 2017

You're already permitted to reuse the data and documents, in the example I covered. Can you indicate what part of that process you're attempting to mitigate?


{JR} Your example was only only applies to domain validation, not organizational validation. The process I’m attempting to mitigate is reuse of organizational validation information. 


>From your comment and given Google’s stance on organizational validation, do your comments apply to the first section and not the second (as the second half of the proposal is only org validation)?  What is the issue with the language in my proposal? Note that although the proposal is based on the EV Guideline concept, the proposal language is different than the EV Guideline language.

 Given that the expiration date must be the same, your example would only permit a one month cert. 


That's clearly your intent, but I don't believe that's what's accomplished :) That's the issue :)


{JR} I’d agree if the language was the same as in the EV Guidelines. However, the reuse of domain validation information was explicitly deleted from this proposal. 


 How do you get a 77 month cert? I understand where the 77 month cert would come from based on the current wording of the BRs, but part of this modification would limit the replacement to the same expiration date.


I think this is a flaw in the EV guidelines, because I believe you can read this to suggest "evergreen" certs. It's a problem in the EVGs, which would be imported into the BRs. The problem is the disconnect between 3.3.1 and 4.2.1 can either be read as an AND logical (e.g. both clauses must apply, the result being what you desire) or as an OR (which means either/or, thus permacert).



{JR} In that case we could simply drop 3.3.1 (as you pointed out that particular issue is already addressed in

Add the following to 4.2.1 (sort of taken from 11.14.1 of EV) after the third paragraph: 

If an Applicant has a currently valid Certificate issued by the CA, a CA MAY rely on the prior authentication and verification:  

(1) The Applicant's identity as verified under Section; 

(2) The Applicant’s DBA as verified under Section;

(3) The countryName as verified under Section;

(4) The Applicant’s individual identity as verified under Section 3.2.3; and

(5) The Applicant’s authorization to issue the Certificate as verified under Section 3.2.5, provided that the CA receives or confirms the request for a Certificate using a Reliable Method of Communication.




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20170414/ae6a9b79/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4964 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/public/attachments/20170414/ae6a9b79/attachment-0001.p7s>

More information about the Public mailing list