3.2.2.4 only covers domain validation. Perhaps that language could be moved to 3.2.2?
>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. 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. Jeremy From: Ryan Sleevi [mailto:[email protected]] Sent: Friday, April 14, 2017 2:47 PM To: Jeremy Rowley <[email protected]> Cc: CA/Browser Forum Public Discussion List <[email protected]> Subject: Re: [cabfpub] How a Certificate Is Issued - the Baseline Requirements Version On Fri, Apr 14, 2017 at 4:30 PM, Jeremy Rowley <[email protected] <mailto:[email protected]> > wrote: Thanks a ton Ryan for putting this together. This is great info. I agree the BRs are missing a re-use of information section, which is odd because the section exists in the EV Guidelines (11.14.1 and 11.14.2). That's nominally covered in Section 3.2.2.4 as part of the introduction, but it doesn't allow for "previous" versions to be used. Specifically, "Completed confirmations of Applicant authority may be valid for the issuance of multiple certificates over time. In all cases, the confirmation must have been initiated within the time period specified in the relevant requirement (such as Section 3.3.1 of this document) prior to certificate issuance. For purposes of domain validation, the term Applicant includes the Applicant's Parent Company, Subsidiary Company, or Affiliate. " I was planning on circulating the following proposal to sync the two requirement docs once the number of pending ballots declined: Add the following to 3.3.1 (taken from 11.14.2 of the EV Guidelines): A CA may rely on a previously submitted certificate request to issue a new certificate if: (1) The expiration date of the replacement certificate is the same as the expiration date of the Certificate being replaced, and (2) The Subject Information of the Certificate is the same as the Subject in the Certificate that is being replaced. Add the following to 4.2.1 (sort of taken from 11.14.1) 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 of: (1) The Applicant's identity under Section 3.2.2.1; (2) The Applicant’s DBA under Section 3.2.2.2; (3) The countryName under Section 3.2.2.3; (4) The Applicant’s individual identity under Section 3.2.3; and (5) The Applicant’s authorization to issue the Certificate under Section 3.2.5, provided that the CA receives or confirms the request for a Certificate using a Reliable Method of Communication. Thoughts? I suppose it comes as no surprise that I'm in favor of more verifications, not less, and always to the current Guidelines :) There are some real issues with that language in the EVGs, and I'd love to see that stricken. For example, given a certificate issued for 39 months, and a request comes in at 38 months, how long can the certificate be valid? I think your intent would be to say "1 month", but I don't think the proposed change would accomplish that. Instead, I fear it would/could allow for 39 months (and then 77 months since the original validation, another 39 month cert be issued)
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Public mailing list [email protected] https://cabforum.org/mailman/listinfo/public
