[Servercert-wg] Questions about spring cleanup ballot and 6.1.1.3
Christopher Kemmerer
chris at ssl.com
Fri May 29 08:24:34 MST 2020
We appreciate the viewpoints raised in this discussion, and agree with
Tim that the goal should be clarification of the BR language to prevent
issuance of known weak keys. We are proposing the following language for
the Baseline Requirements Section 6.1.1.3 which clarifies this
requirement and addresses ROCA and Debian weak key issues:
REPLACE:
"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)."
WITH:
"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.
In the case of ROCA vulnerability, the CA SHALL reject keys identified
by the tools available at https://github.com/crocs-muni/roca.
In the case of Debian weak keys (https://wiki.debian.org/SSLkeys), the
CA SHALL reject at least keys generated by OpenSSL with the following
parameters:
a. Big-endian 32-bit, little-endian 32-bit, and little-endian 64-bit
architecture;
b. Process ID of 0 to 32767, inclusive;
c. RSA Public Key length up to 4096 bits;
d. rnd, nornd, and noreadrnd OpenSSL random file state; and
e. Using public key exponents 3 and 65537
For Debian weak keys not covered above, the CA SHALL take actions to
minimize the probability of certificate issuance."
We look forward to your thoughts on this proposal.
csk
On 5/15/2020 2:13 PM, Tim Hollebeek via Servercert-wg wrote:
>
> 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.
>
>
> _______________________________________________
> Servercert-wg mailing list
> Servercert-wg at cabforum.org
> http://cabforum.org/mailman/listinfo/servercert-wg
--
Chris Kemmerer
Manager of Operations
SSL.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~ To find the reefs, look~~~~~~~~
~~~~ for the wrecks. ~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20200529/2503d244/attachment-0001.html>
More information about the Servercert-wg
mailing list