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

[Corey Bonnell]

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

 

>From X.509 section 8.5.3.1:

 

cessationOfOperation indicates that the certificate is no longer needed for the purpose for which it

was issued but there is no cause to suspect that the private key has been compromised.

 

It seems misleading for a CA to assert by default that there is no cause for the associated private key to be compromised if the Subscriber actually did not assert that is that case or the CA otherwise gains evidence to make that assertion. This is why having a default of no reason/unspecified is better than cessationOfOperation.

 

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

 

I don’t see how claiming the cessationOfOperation reasonCode by default provides any value to RPs. As stated above, it is misleading as it is affirmation that the associated private key has not been compromised despite no information to indicate that is the case.

 

Thanks,

Corey

 

From: Ryan Sleevi <sleevi at google.com> 
Sent: Monday, June 29, 2020 10:21 AM
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 Mon, Jun 29, 2020 at 9:25 AM Corey Bonnell <CBonnell at securetrust.com <mailto: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/e4c210ea/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/20200629/e4c210ea/attachment-0001.p7s>