[cabfpub] How a Certificate Is Issued - the Baseline Requirements Version
sleevi at google.com
Fri Apr 14 14:03:22 MST 2017
On Fri, Apr 14, 2017 at 4:59 PM, Jeremy Rowley <jeremy.rowley at digicert.com>
> 18.104.22.168 only covers domain validation. Perhaps that language could be
> moved to 3.2.2?
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
> 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 :)
> 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
There's also a host of other problems with the EVG language. For example,
if you revoke a certificate (due to lack of authorization for domain or for
organizational issues), can you issue a new certificate with that problem
(as worded, yes).
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Public