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

Tue Jun 30 14:46:47 MST 2020

I think the strategy outlined is fine for this ballot, but I do find myself rather concerned about CAs blindly putting information from subscribers into the revocation reason.  I have very little confidence this information will be any better than noise, and injecting noise into the signal will only make the signal worse and degrade confidence in what any reason codes mean (since, after all, it may have come from a less than knowledgeable subscriber, and is therefore meaningless).  I mean, what are you going to do when a subscriber specifies CACompromise?

For “revocation requested by subscriber for reasons other than key compromise”, I can see an argument for CessationOfOperation, but even in the absence of a compliance obligation, I think it’s important that even if the revocation is initiated by a subscriber, revocations are performed by CAs, and CAs should not include revocation reasons that they do not know to be accurate.  Simply blindly trusting the subscriber’s assertion seems unhelpful to me.

-Tim

From: Servercert-wg <servercert-wg-bounces at cabforum.org> On Behalf Of Ryan Sleevi via Servercert-wg
Sent: Monday, June 29, 2020 1:28 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 Mon, Jun 29, 2020 at 1:16 PM Corey Bonnell <CBonnell at securetrust.com <mailto:CBonnell at securetrust.com> > wrote:

>> 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 <http://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 for the response. I think we're quickly reaching an impasse, at which point, it probably makes sense to merge the request as-is, with the language you're concerned about still in. While not ideal, in that I want to make sure I'm addressing any concerns that might be there, I'm also not sure the concern you're raising is meaningful or entirely consistent within the broader picture of your objection. If I've overlooked something important, I'd appreciate your timely clarification to see if we can, but absent that, I think it makes sense to go forward as-is.

Recall that your original concern was "We allow Subscribers to define their revocation reasons, is this still allowed?", and I attempted to show that yes, it is still allowed and permitted, provided the CA documents within their CP/CPS how they handle that. I'm not sure if your lack of reply on that means that particular concern was suitably addressed, but I'm hopefully not incorrect in assuming it does.

Similarly, it SHOULD-levels a revocation reason for Subscriber certs, which consistent with RFC 2119, means "that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course." The objective here, rather moderate in scope, is to simply ensure the CA adequately documents that within their CP/CPS. That is something we've seen successfully work a number of times before, and is indeed the very basis for SC30, so as a foundation, it doesn't seem necessary to object to it.

The semantic distinction you appear to be making is "It's better for a CA not to say they have no evidence to them (unspecified) than to positively assert they have no evidence available to them (cessationOfOperation), even for situations where they have no evidence available to them." That is, you're treating it as if there is a semantic difference from "unspecified" vs "cessationOfOperation" regarding key compromise, despite them both being neutral (not positive) about it. I don't think we can ever say any revocation reason is truly negative re: keyCompromise; it's within that realm of "known unknowns". The benefit, however, to the SHOULD level requirement is that it encourages a CA to actually document their (presumably) established process and criteria, which in turn can further develop into (at a future point) an objective set of auditable criteria. It also encourages the CA to use those reasons, as has already been requested by Root Programs in the past, so that they can better balance and optimize the privacy, security, and usability of certificates within their products.

It doesn't seem we have any dispute around the normative (MUST/SHALL) level requirements, which is encouraging. This is why I believe it's better to proceed as-is. If there's something important I'm overlooking that you'd wish to be considered, a reply by the end of today is useful. Otherwise, I'll look to fix the issues that this discussion usefully highlighted, and for which I'm greatly appreciative, while accepting our remaining difference is over a semantic quibble with respect to "no cause" being affirmatively negative versus simply neutral.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20200630/be281d86/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4940 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20200630/be281d86/attachment-0001.p7s>