[Servercert-wg] Ballot SC31 Browser Alignment - CRL and OCSP profiles

[Ryan Sleevi]

On Thu, Jun 25, 2020 at 4:11 PM Corey Bonnell <CBonnell at securetrust.com>
wrote:

> I don’t think we can get away from trusting what the Subscriber says
> though.
>
<snip>


> > If a `reasonCode` CRL entry extension is present, the `CRLReason` MUST
> indicate the most appropriate reason for revocation of the certificate, as
> defined by the CA within its CP/CPS.
>
>
>
> Having CAs define the semantics of the reasonCodes in their CPS sounds
> reasonable. However, absent stated expectations on the amount of
> investigative work that CAs must do to ascertain the correct reasonCode for
> end-entity certificates (whose meanings are generally not well defined in
> the first place), the safest bet to avoid non-compliance for CAs is to
> never supply any revocation information for end-entity certificates. But I
> agree with you that is a step back.
>

>
> As an intermediate step, for the end-entity certificate reasonCode case,
> could we walk back the “MUST” to a “SHOULD” for specifying the most
> appropriate reason until the requirements for end-entity reasonCodes are
> better fleshed out? This would still give CAs an incentive to populate the
> reasonCode, but not necessarily create a non-compliance event by failing to
> meet unstated expectations.
>

I was actually trying to address both points you raised, although perhaps
there's still opportunity for improvement.

For example, if a CP/CPS said "The Subscriber may request, in writing or
via programmatic means, for the CA to revoke the certificate. In such
cases, the revocationReason SHALL be cessationOfOperation, unless the
Subscriber provides a more specific revocation reason.", that would meet
the above, right?

Am I overlooking something?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20200625/0893d7ce/attachment.html>