[cabfpub] BR clarification re: test certificates

[Ryan Sleevi]

On Mon, Apr 17, 2017 at 11:08 AM, Gervase Markham <gerv at mozilla.org> wrote:

> On 17/04/17 15:59, Ryan Sleevi wrote:
> > It may be useful to state why you believe it's difficult.
>
> As you have guessed - my surmise was that, particularly with caching,
> CDNs, etc., it can be difficult to make sure that CRLs and OCSP
> responders are delivering exactly the same information at all times with
> no skew whatsoever.
>
> It may be that in practice, the skew is always or almost always seconds
> or minutes, in which case I doubt we need to cater for it in the wording.
>

That assumes the act of revoking a certificate is a distinct step from
publishing that revocation data. That is, it accepts the model that a CA
flips some bit in the issuance system that says "You are revoked", and then
later, generates a CRL or OCSP response, and then later still, makes that
available within its Repository.

Whether intentional or not, that's not the process the BRs describe. There,
revocation is in lock-step with the operation of the Repository and the
publication - if the repository says it is not revoked, then either the
repository is not current, or it is not revoked. If the repository says it
is revoked, then it is revoked. If a subsequent request to the repository
says it is not revoked, then either the repository is not current, or the
CA has "unrevoked" a certificate.

I realize the pedantry here is no doubt frustrating, but my attempt to
describe the process, in all of its banality, is in the hope that CAs may
chime in with what they believe their operations are, so we can figure out
whether or not the language of the BRs reflects an improper attempt to
obtain a different objective, or, if this interpretation is correct, that
the skew issue is already addressed.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20170417/10a4483b/attachment-0003.html>