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

[Ryan Sleevi]

I'm surprised to see the approach of touching 6.1.1.3, rather than 4.9.1.1,
which has the same phrase. Was that intentional?

I'm not supportive of the explicit dependency on crocs-muni/roca, both as a
general explicit dependency on a particular software implementation, but
also because it's got some unfortunate performance characteristics that
other ROCA checks don't have. I do appreciate the attempt to be more
descriptive here, though.

On Fri, May 29, 2020 at 11:24 AM Christopher Kemmerer via Servercert-wg <
servercert-wg at cabforum.org> wrote:

> 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>
> <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>
> <dzacharo at harica.gr>
> *Cc:* CA/B Forum Server Certificate WG Public Discussion List
> <servercert-wg at cabforum.org> <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> 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.
>
> _______________________________________________
> Servercert-wg mailing listServercert-wg at cabforum.orghttp://cabforum.org/mailman/listinfo/servercert-wg
>
> --
> Chris Kemmerer
> Manager of Operations
> SSL.com
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> ~~~~~ To find the reefs, look~~~~~~~~
> ~~~~     for the wrecks.    ~~~~~~~~~
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> _______________________________________________
> Servercert-wg mailing list
> Servercert-wg at cabforum.org
> http://cabforum.org/mailman/listinfo/servercert-wg
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20200529/748759f4/attachment-0001.html>