Subscriber key pair generation by the CA, and private key control verification

[defacto64]

There seems (to me) to be an inconsistency between §5.2 of Mozilla Root Policy, which very clearly prohibits CAs from generating Subscribers' key pairs for SSL Server certs, and §6.1.2 of the BRs which seemingly allows that. Or am I misinterpreting the latter? I'd like to be clarified in the BRs that subscriber key pair generation by the CA is a "MUST NOT", in line with the precise requirement set forth in Mozilla Root Policy.

Also, it's not clear in the BR if the CA is supposed to verify that the Applicant controls the private key corresponding to the public key to be certified. I have been following the discussion on msdp... In my view, this is a crucial obligation of the CA and should be clarified in the BR.

[sleevi]

These seem two separate issues, both of which would benefit from some discussion on the list.

For the first, are you planning to propose a ballot? And/or a pull request to the Browser Alignment draft ballot? There’s no inherent reason to assume that a a requirement from one Root Store MUST become part of the BRs, but if other Root Stores support that requirement, it may make sense. I’m not aware of discussion to know where Apple or Microsoft stand, but Google would be willing to consider it.

Your second point we have no plans to address, and remain strongly opposed to introducing unnecessary complexity regarding issuance that has zero security value. If you are aware of any attacks that are actually relevant to TLS, for which POP would be useful, we’d be interested in discussing further. However, to the best of our knowledge, there are none. Given that any POP would naturally impose limits on the means and methods of both public key delivery and in the other to-be-attested information, and our deep concerns with CAs ability to properly implement the necessary complexity in a way that achieves the security goals vs introducing new security issues, we remain strongly opposed to any such efforts. This is an area where discussion on the list, and optionally the next call, would help address, if there are real and articulable security benefits.

[defacto64]

On the first point: I have not planned to propose a ballot so far, but I do not exclude it. In the meantime, I accept your suggestion to discuss it on the list. On the second point, I'll think it over.

[barrini]

Adriano @defacto64 , any update on this matter?

[defacto64]

Hello Iñigo,

I almost forgot this matter, but now that you make me recall it... well, I think it is still worth discussing.

Back in 2020, the BRs apparently allowed CAs to generate Subscriber private keys: (from §6.1.2)

If the CA or any of its designated RAs generated the Private Key on behalf of the Subscriber, then the CA
SHALL encrypt the Private Key for transport to the Subscriber.

Nowadays such passage is no longer present in the BRs, which means that the BRs do not prohibit Subscriber key pair generation by CAs. However, the Mozilla Root Store policy still expressly prohibits this (from 5.2) :

CA operators MUST NOT generate the key pairs for end entity certificates that have an EKU extension containing
the KeyPurposeIds id-kp-serverAuth or anyExtendedKeyUsage, unless the certificate is being issued to the CA itself.

IMO it's an ugly thing that a major Certificate Consumer prohibits something that is not forbidden in the BRs. I would like Certificate Consumers to come to a common policy on this particular aspect, and the BRs to be aligned accordingly.

Furthermore, the prohibition contained in the MRSP is not entirely clear as, for example, it is not clear whether key generation done through an html page that incorporates javascript code and which never transmits the private key to the CA is allowed or not by Mozilla, regardless of whether that html page is hosted by a CA or another entity.

[XolphinMartijn]

@defacto64 We had a discussion on this yesterday at the F2F as well. Actually section 6.1.1.3 of the BRs currently forbid CAs from doing key generation.

[defacto64]

You are right @XolphinMartijn , so as far as I'm concerned this issue can be closed

[BenWilson-Mozilla]

In response to Adriano's comment, re: Mozilla policy, we still prohibit key generation by CAs for subscribers, and any change would require discussion on the Mozilla dev-security-policy list.