[Servercert-wg] Questions about spring cleanup ballot and 6.1.1.3
Dimitris Zacharopoulos (HARICA)
dzacharo at harica.gr
Fri May 15 09:15:26 MST 2020
On 2020-05-15 6:33 μ.μ., Ryan Sleevi wrote:
>
>
> On Fri, May 15, 2020 at 5:38 AM Dimitris Zacharopoulos (HARICA)
> <dzacharo at harica.gr <mailto: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
>> <mailto: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.
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.
>> 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
>
I agree that this is what CAs SHOULD be doing, but it's not an explicit
requirement at this time. And to be fair, HARICA would support a ballot
to make these good practices explicitly required in a separate ballot.
This could be included in the ballot that prepares the updated language
in 6.1.1.3. I am just reluctant to adding such a change in a
"cleanup/clarifications" ballot.
> 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.
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)./
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 :-)
I still welcome feedback from other Members.
Dimitris.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20200515/74e01293/attachment-0001.html>
More information about the Servercert-wg
mailing list