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

[Ryan Sleevi]

On Mon, Jun 29, 2020 at 1:16 PM Corey Bonnell <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:
>
>
>
> *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/20200629/6076222a/attachment.html>