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

[Ryan Sleevi]

On Fri, May 15, 2020 at 5:38 AM Dimitris Zacharopoulos (HARICA) <
dzacharo at harica.gr> wrote:

>
>
> On 2020-05-14 10:11 μ.μ., Ryan Sleevi wrote:
>
>
>
> 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 conversations in m.d.s.p. and the introduction of specific language to
> make the minimum expectations more clear for CAs in 6.1.1.3 about what we
> mean by "known weak Private Key", but also the interesting discussion that
> followed between you, Corey and Roland, demonstrate that this is not a
> straightforward rule with clear and auditable requirements. That is why
> adding more unauditable requirements in 6.1.1.3 is going to be confusing.
>

You keep saying "adding more unauditable requirements", but this is an
existing requirement. I'm hoping you can clarify why you believe it's new.
As I explained to you, it's not, it's a logical consequence of the existing
requirement which this is explicitly trying to make clearer, to reduce that
ambiguity that you're concerned about.

With respect to auditability, I don't think setting the goal at "Only
things that are auditable" is at all a reasonable goal. While not wanting
to undercut the very valuable aspects of concrete auditable requirements,
both Root Store Policies and the Baseline Requirements also work to set
forward the policy expectations that a CA is expected to follow. Even if an
audit cannot provide assurance that the CA follows it, that doesn't mean
it's not a worthwhile requirement. This is especially important, because in
the history of the Baseline Requirements, no major Root Program has
required "just" audits; they've always been layering added things on top,
whether a contractual agreement to abide by the requirements or not. So no,
I don't find the auditability argument at all compelling.


> 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?
>
>
> Actually, I think it's different to hold a CA accountable for *issuing *a
> Certificate with a key that is later demonstrated to have been weak,
> compared to holding a CA accountable for *not revoking* a certificate
> that is proved to have been using a weak key.
>

I'm afraid you've now shifted from discussing what's in the ballot to
what's *already in the BRs*.

6.1.1.3 *already contains the language you object to*, namely, "The CA
SHALL reject a certificate request if the requested Public Key does not
meet the requirements set forth in Sections 6.1.5 and 6.1.6 *or if it has a
known weak Private Key* (such as a Debian weak key, see
http://wiki.debian.org/SSLkeys)."

The entirity of the concerns you've expressed, on this thread, regarding
both auditability and now the discussion on "later demonstrated to have
been weak", is a complaint with the *existing *language. That makes it
difficult to engage.

If we want to talk about what the actual Ballot proposes, without the
misinterpretation, then it's attempting to specifically address what "known
weak" means by giving existing examples of cases that have been viewed as
"known weak" - i.e. if a CA accepts a request, in these circumstances, then
they've violated the *existing* requirement.

It makes it concrete that it's scenarios in which the "CA is aware". That
is, it addresses your 'hypothetical' of "but we didn't know" by clarifying
that it only applies in the scenarios where the CA is aware.

Your concern about how this can be audited can be minimally addressed as
follows:

Control 1:
* Examine all certificates the CA revoked under the existing provisions of
4.9.1.1 regarding key compromise or other key-related flaws
* Did the CA issue any certificates, following those revocations, with
those keys? If so, it violated 6.1.1.3

Control 2:
* Examine all controls the CA has with respect to ensuring 4.9.1.1 is met
(e.g. databases or scans of weak keys)
* Do those controls also get applied to new issuance? If not, it violated
6.1.1.3

As we work to improve the language of 4.9.1.1, the above tests naturally
still apply.

I believe updating 6.1.1.3 with clearer rules about setting minimum
> expectations for "known weak keys" is a good way forward, one that could
> also have positive effects on 4.9.1.1.
>

That's literally what this ballot does. The reason it copies the language,
from 4.9.1.1, is precisely because it clarifies that, under the existing
reasons for revocation under 4.9.1.1, that key is subsequently "known
weak". It doesn't address the ambiguity of 4.9.1.1, because yes, that's a
broader issue - but makes it clear that anytime 4.9.1.1 is triggered for
those reasons, then that key is subsequently... "known weak". The *existing*
requirement.

To object to the language changes in 6.1.1.3, by suggesting it's a new
requirement, is to say the following:

"I do not believe that if a CA revokes a certificate, for the key-related
reasons in 4.9.1.1, that such keys are known to be weak to the CA".

Now, if you believe that 6.1.1.3 is not perfectly aligned with 4.9.1.1, we
can certainly discuss that and fix that. But that's precisely why it
borrows the language from 4.9.1.1 - to clarify what a minimum set of "known
weak" entails, which is the set of reasons for revocation from 4.9.1.1.


> Providing clarifications for non-controversial issues and "obvious
> mistakes" is fine with me in the spirit of a clean-up ballot. However, I
> don't feel very comfortable with this particular change because it
> effectively adds a new requirement (admittedly for the same source of
> issues) as explained earlier.
>

It's *not* a new requirement. That's precisely why it's an important
clarification. This is an existing expectation we have of you and all other
CAs.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20200515/5c7742d0/attachment.html>