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

Fri May 15 12:13:18 MST 2020

I’m less interested in what the current BRs say about this topic, than what they should say about this topic.  CAs should not be issuing certificates with keys that are known to be compromised, and we support any clarification that makes that clear.  We’d still support it even if it were a new requirement.

Since, as we clarified on the call yesterday, this is a “cleanup and clarification” ballot, and not a “spring cleanup” ballot (despite a few subject lines and comments to the contrary …), we don’t have a problem with the inclusion of this provision.  It makes the internet better.

-Tim

From: Servercert-wg <servercert-wg-bounces at cabforum.org> On Behalf Of Ryan Sleevi via Servercert-wg
Sent: Friday, May 15, 2020 1:03 PM
To: Dimitris Zacharopoulos (HARICA) <dzacharo at harica.gr>
Cc: CA/B Forum Server Certificate WG Public Discussion List <servercert-wg at cabforum.org>
Subject: Re: [Servercert-wg] Questions about spring cleanup ballot and 6.1.1.3

On Fri, May 15, 2020 at 12:15 PM Dimitris Zacharopoulos (HARICA) <dzacharo at harica.gr <mailto:dzacharo at harica.gr> > wrote:

That's a fair statement, I'm not arguing that all requirements should be objectively auditable, but for this particular requirement we have seen several different interpretations, which -to me- demonstrated that these rules are not so clear and unambiguous. I agree it is an existing requirement in 4.9.1.1 but I'm arguing it becomes a different requirement if added in 6.1.1.3.

Right. And this is, I think, the crux of our disagreement:

If a CA revokes a certificate because it's pointed out as compromised to them, in 4.9.1.1, does that mean that it's known weak, as required by the existing 6.1.1.3.

You seem to be saying "No, as currently written, it's not", and I am saying "Yes, as currently written, it is". This seems like an important thing to clarify.

At present, I don't think you've really provided substance to your "No". You've said you don't believe so, but you haven't really articulated why. The closest it seems we've got is "Well, it's ambiguous", and while I agree the language is ambiguous (and that's why it's important to clarify), I don't believe the expectation is ambiguous.

I agree that this is what CAs SHOULD be doing, but it's not an explicit requirement at this time. 

Again, you keep saying "No it isn't", but you don't provide any substance or reason for how you're reaching a conclusion that it's not an existing requirement. You've shifted the language a little, to say now "explicit" requirement, but I don't think that's substantive. I think it's already an implicit requirement, and while this is clarifying it explicitly, it doesn't actually change or introduce any new requirements.

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.  

You suggest the following in 6.1.1.3 <http://6.1.1.3> :

1. The Key Pair does not meet the requirements set forth in Section 6.1.5 and/or Section 6.1.6;
2. There is clear evidence that the specific method used to generate the Private Key was flawed;
3. The CA is aware of a demonstrated or proven method that exposes the Subscriber's Private Key to compromise;
4. The CA has previously been made aware that the Subscriber's Private Key has suffered a Key Compromise, such as through the provisions of Section 4.9.1.1;
5. The CA is aware of a demonstrated or proven method to easily compute the Subscriber's Private Key based on the Public Key (such as a Debian weak key, see https://wiki.debian.org/SSLkeys).

2 and 3 are already covered by 4 because they are already included in 4.9.1.1. Adding 1 also seems uncontroversial. I still have concerns with adding issuing requirements that are not explicitly stated in 6.1.1.3, especially 2, 3 and 4. If I'm the only one with these concerns, it shouldn't block this ballot from moving forward :-)

Your framing here is again incorrect. The side-by-side diff is useful, but let's just repeat the existing 6.1.1.3 language, in the BRs today.

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

>From there, we can see that the New-6.1.1.3 (1) is just the following from the Old-6.1.1.3 (1)

"if the requested Public Key does not meet the requirements set forth in Sections 6.1.5 and 6.1.6"

Now, you might argue that the change from "Public Key" to "Key Pair" is significant, but if you look at 6.1.5 / 6.1.6, they only describe requirements for Public Keys, so it's not actually a change in normative requirements. My goal was trying to be more consistent about when we mean either/or or truly mean only Public, but I can make that change back, if it's important to you.

The substance of our disconnect seems to hinge on this existing clause from Old-6.1.1.3:

"if it has a known weak Private Key (such as a Debian weak key, see <http://wiki.debian.org/SSLkeys>)."

This language, "known weak", only appears once in the BRs. We know from the phrase "such as" that this is not an exhaustive set; what follows is merely an example. So what are the other examples that constitute "known weak"

Our existing Old-4.9.1.1 has a number of clauses, related to private keys, that talk about in terms of "The CA is 'made aware'". If a CA is "made aware" of something, does that mean it is "known" to them? I argue yes, it does.

So now we get to "known weak" - is the CA made aware that something is weak? What is weak? In New-6.1.1.3, this breaks out the requirements from Old-4.9.1.1 p2 (11), which says the following:

"The CA is made aware of a demonstrated or proven method that exposes the Subscriber's Private Key to compromise, methods have been developed that can easily calculate it based on the Public Key (such as a Debian weak key, see http://wiki.debian.org/SSLkeys), or if there is clear evidence that the specific method used to generate the Private Key was flawed"

We can see that New-6.1.1.3 (2) is just stating the third/last clause from Old-4.9.1.1 p2 (11)

We can see that New-6.1.1.3 (3) is just stating the first clause from Old-4.9.1.1 p2 (11)

We can see that New-6.1.1.3 (5) is just stating the second clause from Old-4.9.1.1 p2 (11)

New 6.1.1.3 (4) does *not* come from Old-4.9.1.1 p2(11), but instead ties to Old-4.9.1.1 p1 (3), which reads

"The CA obtains evidence that the Subscriber's Private Key corresponding to the Public Key in the Certificate suffered a Key Compromise;" 

Again, the extent of this is to address the very concerns you raised, which is that "known weak" is a phase not used or clarified anywhere in the BRs, and is thus seen as ambiguous. It does not propose introducing any new requirement, other than stating the existing expectation: that if a certificate is revoked because the CA is made aware of some detail ("known") that compromises the assurance of the private key ("weak"), and are required to revoke, they also shouldn't issue.

The minimalist view of Old-6.1.1.3 would view that the only weak key defined is Debian weak keys, and every other interpretation of "known weak" is left to the CA. In that view, New-6.1.1.3 is somehow removing the CA's discretion and flexibility by imposing new requirements. I'm suggesting that's not the case, and that because of 4.9.1.1, a number of other scenarios are already identified in the BRs that make something "known weak", and this makes that explicit, rather than implicit.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20200515/d8d08eeb/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://cabforum.org/pipermail/servercert-wg/attachments/20200515/d8d08eeb/attachment-0001.p7s>