Please explain why CAs MUST NOT generate the key pairs

[Michel Le Bihan]

If my understanding is correct, in https://groups.google.com/g/mozilla.dev.security.policy/c/Xio6mrdxp2M/m/m38TJkblAgAJ

it was agreed that it's neither practical nor beneficial to enforce that on resellers or other intermediates. However, it's not really clear to me why there is such a rule in the policy. I think that a CA that would like to generate key pairs for their custommers
could just setup a structure and hide behind a reseller to do that.

[Ryan Sleevi]

It seems you're asking two very different questions, but I'm hoping you could clarify:

• Are you asking why is it not OK for CAs to generate keys?
• Or are you asking why is it OK for resellers and other intermediates to generate keys?

To your latter point, about "evading" the requirement, yes, it's certainly true, a CA could do that. Yet, as the discussion captures, the goal of any policy is to try to capture the expectations, while being mindful of the unintended or second-order consequences.

For example, you could, in theory, fully mitigate, if not outright prevent, crime, by having a police official assigned to each and every person and who follows them 24/7. Yet, in most societies, we recognize that's authoritarian abuse, and would have a number of measurable harms to individuals.

In this specific situation, we're acknowledging that there is frequently a path of intermediates between what might conceptually be seen as "the site" and the CA. I say "conceptually", because it's actually quite complicated with respect to how Applicant/Subscriber function.

On the "close to the site operator" side, you have entities like marketing companies, CDNs, IT (which may be in-sourced or may be out-sourced), hosting providers - all entities that may have access to the keys or may be responsible for generating keys.

On the "close to the CA" side, you obviously have the CA themselves, but then you have entities like resellers.

The problem is those "resellers" may themselves be the CDNs, IT teams, hosting providers, etc - it's not a binary either/or, but can be multiple.

Recognizing this, the policy tries to express both a principle and an outright prohibition. The CA themselves MUST NOT generate the key - primarily because in all cases (except where the CA is self-issuing to themselves), the CA won't be the one actually using or operating the key, which means complexities like key transport and key protection, and the risk of key archival. As we get closer to the site operator, it becomes more of a "site operator problem" to sort out, because we recognize there are legitimate reasons why you may want to have your hosting provider generate the key for you. For example, so they can automatically maintain and renew your certificate for you.

In policy, as in life, we accept the imperfection, because we don't want to let the perfect be the enemy of the good. We also use this to express principles and expectations.

Can CAs do things that stray from the good path? Yes, certainly. But we can deal with and address those situations as we become aware.

[Michel Le Bihan]

> It seems you're asking two very different questions, but I'm hoping you could clarify:

>    Are you asking why is it not OK for CAs to generate keys?

>    Or are you asking why is it OK for resellers and other intermediates to generate keys?

I'm asking why is it not OK for CAs, but OK for others. Intuitively I would think that it should be OK or not OK for everybody. If the difference for whom the keys might be useful to provide service, maybe that should be written in the CP?

[Matthias van de Meent]

On Thu, 13 May 2021, 19:08 Michel Le Bihan, <michel.le...@gmail.com> wrote:

If my understanding is correct, in https://groups.google.com/g/mozilla.dev.security.policy/c/Xio6mrdxp2M/m/m38TJkblAgAJ

it was agreed that it's neither practical nor beneficial to enforce that on resellers or other intermediates. However, it's not really clear to me why there is such a rule in the policy.

CA generated keys implies CA must transfer these keys to the subscriber. This transfer of key material opens the can of worms that is "secure transfer and storage of key material", which is better left closed: 

- How would you authenticate that the recipient of the key material is actually the Subscriber?

- How do you ascertain that there is no adversary in the communications / MitM that can read the key material?

- If the systems of the CA are breached, now all generated keys by that CA must be considered compromised instead of only the CA keys; these subscriber keys have been generated in their sustem, and transferred out through an compromised system.

- ... etc.

The CA is supposed to protect the private key materials with some level of protection (section 6.2 of the BR), and I believe it is not feasable for a CA to protect the key material of their subscriber certificates to the same standards. I believe that CAs (or any other third parties) generating keys for subscribers is a can of worms better not opened.

I think that a CA that would like to generate key pairs for their custommers
could just setup a structure and hide behind a reseller to do that.

If a CA is found to do that, I believe that to be a reason for (immediate?) distrust for going above and beyond to circumvent the rules of the BR; similar to if a CA was found future-dating their certificates to give a subscriber a set of less-than-398-day-validity-period certificates that together is valid after the next 398 days.

Kind regards,

Matthias van de Meent

PS. Note that a CA is actually forbidden from signing server certificates on keys that they have generated (BRs 6.1.1.3). This (currently) includes situations where they are also the subscriber, which implies that CAs must outsource key generation for leaf server certificates in their hierarchy for their own use.

There's an open issue about that in the cabforum bug tracker [1].

[1] https://github.com/cabforum/servercert/issues/255

[Phillip Hallam-Baker]

This came up repeatedly as a customer request when I worked for a CA.

The reason customers want this is that the CA knows how to manage crypto and very often, they don't. Take installing private keys into a smart card during initialization. The banks don't (usually) manufacture or provision their own cards. So any private keys are going to pass through the hands of a third party. The cards were not capable of generating their own keys in sensible time for RSA.

The reason no CA should ever accept this request is liability. If the CA has the private key, the RP can come sue the CA for any real or imagined breach.

This is why I proposed threshold key generation. The CA and the device both generate a key share. The two shares are then combined to produce the final private key. This approach has many beneficial properties. 

Unfortunately, I only developed those ideas in reaction to ACME and too late to grasp the implications. We could have done ACME very differently and in a much better way albeit only for ECC keys. Burt Kaliski says he can make it work for RSA but I am thinking we are beyond RSA these days.

 

--
You received this message because you are subscribed to the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-po...@mozilla.org.
To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CAAs3B9qFEhr6pUedAjnrAh5t4W9vGjvCjvQTTLwiCEP6zQW6Lw%40mail.gmail.com.

[Wojtek Porczyk]

The CAs can do better than that, they can delived a tool for automating the
key generation and cert deployment by the user. This is exaclty what Let's
Encrypt is doing: most ACME clients "generate keys for you", yet it doesn't
count as "CA generates key" because the key never leaves the machine on which
the user installed the tool.

So in the simple case there's not really a reason to do that. As Ryan
explained, the policy gives room for the more complicated cases.


--
pozdrawiam / best regards
Wojtek Porczyk
Graphene / Invisible Things Lab

I do not fear computers,
I fear lack of them.
-- Isaac Asimov

[Phillip Hallam-Baker]

A major difference in the separation of concerns there is that the ACME tool is open source and reviewable so the exposure of the CA is limited, separation of roles is preserved.

--
You received this message because you are subscribed to the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-po...@mozilla.org.

To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/20210513213650.GL2571%40invisiblethingslab.com.