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

[Ryan Sleevi]

On Fri, May 15, 2020 at 12:15 PM Dimitris Zacharopoulos (HARICA) <
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:
>
> *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
> <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/0d49445b/attachment.html>