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

[Corey Bonnell]

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

 

Can you point to the existing Root Program Requirement for this tightening of the end-entity revocation information profile in the BRs? I’m hoping that by reviewing this requirement it will be easier to suggest clarifications in the proposed language of the ballot.

 

Thanks,

Corey

 

 

From: Ryan Sleevi <sleevi at google.com> 
Sent: Thursday, June 25, 2020 5:40 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 4:11 PM Corey Bonnell <CBonnell at securetrust.com <mailto: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/20200629/f9aab8fb/attachment.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/20200629/f9aab8fb/attachment.p7s>