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

[Ryan Sleevi]

On Mon, Jun 29, 2020 at 9:25 AM Corey Bonnell <CBonnell at securetrust.com>
wrote:

> > 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?
>
>
>
> Actually, I’d think that such an attempt by a CA to comply with the
> requirement by default specifying “cessationOfOperation” unless informed
> otherwise by the Subscriber would be several steps back in terms of the
> stated goals:
>
>    1. cessationOfOperation would become the new “unspecified”, except
>    that cessationOfOperation is actively misleading as it excludes the
>    possibility that revocation was due to keyCompromise. I’d think that having
>    a default of “no reason”/unspecified is less misleading/confusing, as it
>    does not exclude the possibility that the reason for revocation was
>    keyCompromise.
>
> I'm not really sure I understand this objection. Can you elaborate? I fail
to see how it precludes the case of keyCompromise, for example?


>
>    1.
>    2. The reasonCode of “cessationOfOperation” will be encoded in
>    CRL/OCSP responses by default, thus no reduction of the number of bytes on
>    the wire will be realized in the common case.
>
>  If that's a meaningful status - i.e. it provides a way for relying
parties to distingush - that doesn't seem a step back. Even omitting for
clearly specified reasons seems more useful than the status quo.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20200629/3bdfe69a/attachment-0001.html>