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

[Corey Bonnell]

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

 

I don’t think we can get away from trusting what the Subscriber says though. For example, if a Subscriber asserts their key was compromised because their web server was popped and the machine was wiped, there’s no way for the CA to confirm that the key was actually compromised. In the case of affiliationChanged, a Subscriber might revoke their certificate using that reason code and move to another CA to get the replacement certificate. Is the original CA now obligated to verify if any subject organization information in the certificate actually changed to confirm it is the correct reason code?

 

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

 

Thanks,

Corey

 

From: Ryan Sleevi <sleevi at google.com> 
Sent: Thursday, June 25, 2020 3:21 PM
To: Corey Bonnell <CBonnell at securetrust.com>
Cc: CA/B Forum Server Certificate WG Public Discussion List <servercert-wg at cabforum.org>
Subject: Re: [Servercert-wg] Ballot SC31 Browser Alignment - CRL and OCSP profiles

 

 

On Thu, Jun 25, 2020 at 2:53 PM Corey Bonnell <CBonnell at securetrust.com <mailto: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 <https://scanmail.trustwave.com/?c=4062&d=tPn03nL-glFQbrsmYgExdheFq9ycIG5zVywMhTG7aw&s=5&u=https%3a%2f%2fgithub%2ecom%2fsleevi%2fcabforum-docs%2fpull%2f30>  , 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/90e6e3c8/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4947 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20200625/90e6e3c8/attachment-0001.p7s>