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

Fri May 15 02:38:20 MST 2020

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.

>
>     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. The current rules of 
4.9.1.1 say that if

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

/then the certificate must be revoked. It is quite possible that when a 
CA issued a Certificate, it wasn't aware of some of those developed 
methods, but once they learn about these methods it would make sense to 
revoke such weak certificates.

Perhaps I'm reading this wrong so I would appreciate some feedback from 
others, possibly from CAs that had some challenges with 6.1.1.3 before.

>
>     I think we should invest time and effort to improve the language
>     of 6.1.1.3 separately from this cleanup/clarifications ballot.
>
>
> I can understand and appreciate hesitation, but the way you've worded 
> this, it does not provide any ability to better understand or address 
> your concerns. Implicit to this seems to be "It is more important to 
> fix some things sooner than it would take to have a productive 
> discussion on this matter". Yet you don't actually clarify what you 
> believe is important to get through sooner, nor why it is, so it can 
> be weighed against the relative risks that I outlined above, and which 
> we've seen cause significant issues to the CA ecosystem. I'm not 
> outright rejecting your appeal, but I'm saying it lacks data to help 
> understand your priorities, and because of that, I don't think the 
> appeal is reasonable.

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. The current language seems 
problematic and pretty vague to copy from 4.9.1.1 to 6.1.1.3.

Perhaps we could get some feedback from auditors and how they evaluate 
this specific section, and whether the current language seems good 
enough for them to develop objective auditable criteria.

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.

Dimitris.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20200515/05e34c8e/attachment.html>