[cabfpub] How a Certificate Is Issued - the Baseline Requirements Version

[Ryan Sleevi]

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
7.1.4.2 or 3.2.2.4.

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.
>

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
unfortunately do).

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...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20170416/771891e3/attachment-0003.html>