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

[Ryan Sleevi]

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

> > I guess a question here is if a key is compromised, does the CA allow
> the customer to not specify that reason? I'm particularly interested in the
> case where the CA is informed (e.g. via a problem report) of the compromise.
>
>
>
> For Subscriber-initiated revocation requests via web portal or API, it is
> generally possible for Subscribers to select the reason code they feel is
> most appropriate to fulfill their obligations of section 9.6.3 (5). In the
> case of key compromise, the CA is reliant on the Subscriber to provide that
> reason, as there is no way for the CA always prove that is actually the
> case.
>
>
>
> For revocations stemming from the CA obtaining proof of compromised keys
> via a Certificate Problem Report by a Relying Party, CA support personnel
> processing the report should use the keyCompromise reasonCode if one is
> being specified at all, but I have no idea if that is the generally
> accepted handling of such reports across CAs.
>

Thanks! I'm trying to think how to accomodate or handle this.

I think the goal is to make sure we have meaningful reasons, when possible.
If a system encourages folks to use "unspecified" (or, more specifically,
omit reasons), that seems a step-back. If there's a "whatever the
subscriber says goes", then there's a worry that CAs processing
problem-reports would then request the subscriber to request revocation,
and *not* select keyCompromise, particularly if compromised keys require
special handling by the CA (e.g. cleanups & clarifications).

Similarly, consider if a Subscriber requested a cert be revoked for
unspecified, and later the CA was informed it was due to keyCompromise.
There's utility in the CA updating the revocation reason to reflect that.

The intent of the current language, and particularly, the proposed change
to SC31, https://github.com/sleevi/cabforum-docs/pull/30 , is to put the
onus on the CA to document/describe what they do. Do you think the proposed
clarification is sufficient to address these expectations, without creating
significant challenges? Namely:

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.

That's fairly open, and I suspect in a future ballot we could explore what
sort of scenarios would be relevant for a CA to disclose within its CP/CPS
as part of its handling.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20200625/672f1d51/attachment.html>