[cabfpub] How a Certificate Is Issued - the Baseline Requirements Version
sleevi at google.com
Sun Apr 16 12:07:18 MST 2017
On Sun, Apr 16, 2017 at 1:13 PM, Peter Bowen <pzb at amzn.com> wrote:
> 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.
Nothing says they could use previous versions.
In the absence of such a statement, "completed confirmation" must be read
to be consistent with the in-force version of the Baseline Requirements
(i.e. excluding previous versions), as a certificate issued using a
previous version's confirmation has not been issued in accordance with
188.8.131.52 or 184.108.40.206.
I would also point out that 4.2.1 is not the section that requires
> following 220.127.116.11; under 4.2.1 the CA could simply call the customer to
> confirm they requested the data be included.
Oh for sure, but 4.2.1 governs the maximum age of reuse.
> 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.
So in general, I think this is clearly the intent of some proponents, and
is more directly stated than past attempts, so I appreciate that. My
concern is and remains how we bound the maximum age of that data (so as to
ensure out of date information is not relied upon for a time longer than is
reasonable) and how that data is invalidated (for example, to avoid a
situation where a revocation event occurs and the CA continues to use the
previously validated information, as we've already seen some CAs
Do you have a sense of what you believe the upper-bound for such
information can or should be?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Public