> On Apr 14, 2017, at 1:47 PM, Ryan Sleevi via Public <[email protected]>
> wrote:
>
>
>
> 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. “
Previous versions could be used as they are “Completed confirmations”. There is
nothing that says the completed confirmation has to have been created using a
process described in the current BRs.
I would also point out that 4.2.1 is not the section that requires following
3.2.2.4; under 4.2.1 the CA could simply call the customer to confirm they
requested the data be included. Section 7.1.4.2 is what requires validation:
"By issuing the Certificate, the CA represents that it followed the procedure
set forth in its Certificate Policy
and/or Certification Practice Statement to verify that, as of the Certificate’s
issuance date, all of the Subject
Information was accurate. CAs SHALL NOT include a Domain Name or IP Address in
a Subject attribute
except as specified in Sections 3.2.2.4 or 3.2.2.5.”
> 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)
Could we maybe split validation of namespaces from server auth certificate
issuance? We already have clear definitions of namespaces for subject names
(both the Subject Name itself as well as Subject Alternative Names) defined in
Name Constraints. What if we simply required that each Name in a certificate
(whether Distinguished Name, DNS Name, IP Address, RFC 822 Name, or SRV name)
fall within a validated namespace and that the certificate must expire prior
the the expiration of any namespace validation relied upon for issuance of the
certificate? This would clearly allow a company to use a time consuming but
high assurance validation process (e.g. identity validation + registration
match + legal agreement) and then get multiple short lived certificates using
that validation.
Thanks,
Peter
_______________________________________________
Public mailing list
[email protected]
https://cabforum.org/mailman/listinfo/public
