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 3.2.2.4. 3.2.2.4 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 3.2.2.4):
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 3.2.2.1;
(2) The Applicant’s DBA as verified under Section 3.2.2.2;
(3) The countryName as verified under Section 3.2.2.3;
(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.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Public mailing list [email protected] https://cabforum.org/mailman/listinfo/public
