[cabfpub] How a Certificate Is Issued - the Baseline Requirements Version
sleevi at google.com
Fri Apr 14 13:47:08 MST 2017
On Fri, Apr 14, 2017 at 4:30 PM, Jeremy Rowley <jeremy.rowley at digicert.com>
> 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 184.108.40.206 as part of the introduction,
but it doesn't allow for "previous" versions to be used.
"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
> 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 220.127.116.11;
> (2) The Applicant’s DBA under Section 18.104.22.168;
> (3) The countryName under Section 22.214.171.124;
> (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.
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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Public