[Servercert-wg] Questions about spring cleanup ballot and 6.1.1.3

[Ryan Sleevi]

On Thu, May 14, 2020 at 1:31 PM Dimitris Zacharopoulos (HARICA) via
Servercert-wg <servercert-wg at cabforum.org> wrote:

>
> I just had a quick review of
> https://github.com/sleevi/cabforum-docs/pull/12/commits/48d12dc25dc458f163b852ea2487473cc084f112
> which moves some requirements from 4.9.1.1 into 6.1.1.3.
>

Given that adjustments are continued to be made throughout, I would
encourage you to also review holistically (e.g.
https://github.com/sleevi/cabforum-docs/pull/12 ) to make sure your
concerns have not already been addressed in subsequent revisions.

I believe this change brings a significant normative change to the BRs.
> According to 4.9.1.1, if an already issued certificate is demonstrated to
> be using a compromised key, it must be revoked. If this moves to 6.1.1.3,
> the CA MUST PREVENT such a certificate from being issued in the first
> place.
>

As I mentioned on the call, while I believe some may see this as a new
normative requirement, I don't believe it actually is.

The existing BRs, Section 6.1.1.3, requires a CA reject if a certificate
has a "known weak Private Key". The area of confusion, which this ballot
attempts to clarify, is whether or not a compromised key is known to be
weak.

>From our point of view, it is. To suggest a key can be "strong, but
compromised" is akin to saying "It provides 2048-bits of security in
theory, and 0 bits of security in practice". It's weak by virtue of its
compromise. Thus, the existing 6.1.1.3 requires CAs reject certificates
that /they/ know to be compromised, such as through the reporting in
4.9.1.1.

That's the logic for why this is *not* a new requirement, but attempts to
clarify the existing requirement in line with what's expected.

There's a real damning harm that comes about to view this as distinct. If
we view compromised certificates as not "known weak", then the revocation
requirements in 4.9.1.1. are worthless to Relying Parties. This is because
a CA can continue to issue certificates to keys it knows to be compromised.
>From issuance, it immediately triggers 4.9.1.1, which requires revocation
in 24 hours. If publishing revocation via CRL, the CA has 7 days before
they need to publish that revocation (4.9.7), or 4 days in the case of OCSP
(4.9.10). From the attacker point of view, however, they can use that
certificate for a total of 10 days, based on the timelines in 4.9.7 and
4.9.10, and either interrupting CRL service or stapling an OCSP response
prior to the revocation.

This cycle can be repeated, without issue, and with the same CA,
effectively defeating the intent of the revocation requirement within
4.9.1.1. This is not acceptable behaviour for publicly trusted CAs.


> The current language of 6.1.1.3 seems to already be quite ambiguous about
> the minimum expectations a CA has to follow, to prevent things like "Debian
> weak keys", as we saw in the parallel thread
> <https://cabforum.org/pipermail/servercert-wg/2020-April/001821.html>.
> Adding more vague requirements without auditable criteria is not a good
> improvement.
>

I'm not sure how to address your concern. This seems to be a complaint with
the existing language, and you seem to be objecting to attempts to clarify
it. That is, it's not an "added" requirement, not to the extent the
language is distinct from our existing language in 4.9.1.1. It seems like
your complaint is with the existing language, not the new language. Is that
correct?

I think we should invest time and effort to improve the language of 6.1.1.3
> separately from this cleanup/clarifications ballot.


I can understand and appreciate hesitation, but the way you've worded this,
it does not provide any ability to better understand or address your
concerns. Implicit to this seems to be "It is more important to fix some
things sooner than it would take to have a productive discussion on this
matter". Yet you don't actually clarify what you believe is important to
get through sooner, nor why it is, so it can be weighed against the
relative risks that I outlined above, and which we've seen cause
significant issues to the CA ecosystem. I'm not outright rejecting your
appeal, but I'm saying it lacks data to help understand your priorities,
and because of that, I don't think the appeal is reasonable.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20200514/386956f4/attachment.html>