Should BRG 6.2.6 forbidden?

[RufusJWB]

Paragraph 6.2.6 of the BRGs allows that Private Keys for CAs are generated by an Issuing CA and then transported to the Subordinate CA:

If the Issuing CA generated the Private Key on behalf of the Subordinate CA, then the Issuing CA SHALL encrypt the Private Key for transport to the Subordinate CA.

In my opinion, this opens the gate for highly risk-prone behavior with little or no additional benefit for the CAs nor the overall PKI ecosystem. Therefore I would like to propose that this should be forbidden in one of the next releases of the Mozilla Root Store Policy.

[sleevi]

Section 8.3 of Mozilla’s policy imposed additional constraints for exactly this scenario. Do you feel they are inadequate?

[RufusJWB]

I don't feel that section 8.3 covers my concerns. In my understanding, 8.3 describes how a CA key pair should be transferred from one physical location to another physical location but it would typically stay within the control of one legal entity. In opposite BRG 6.2.6 regulates the case of how a private key is being transferred from one legal entity to a very different legal entity. I think the closest within the Mozilla Root Store Policy to cover the process allowed in BRG 6.2.6 is chapter 8.2. But it has, as I read it, a different target scenario in mind.

As I can't imagine any scenario in which the generation of a private key on behalf of a subordinate CA would bring any benefit to the ecosystem but it paves the way to plenty of risky behaviors I think it would be worth discussing here if this should be accepted by the Mozilla community.

[sleevi]

I don't feel that section 8.3 covers my concerns. In my understanding, 8.3 describes how a CA key pair should be transferred from one physical location to another physical location but it would typically stay within the control of one legal entity.

I'd like to unpack this more, and what you mean by "typically". The Policy 8.3 language covers both scenarios - whether it is same entity or different entity, and covers any change in physical location. Are you imagining a scenario in which it's kept on the same HSM, in the same cage, but operationally distinct?

In opposite BRG 6.2.6 regulates the case of how a private key is being transferred from one legal entity to a very different legal entity. I think the closest within the Mozilla Root Store Policy to cover the process allowed in BRG 6.2.6 is chapter 8.2. But it has, as I read it, a different target scenario in mind.

Section 8 covers all such scenarios, and has been intentionally clarified several times to make that clearer. So that's why I'm trying to understand a bit more which part you feel is unclear, so concrete improvements can be suggested. Any such transfer inter-organization unquestionably triggers 8.1 and 8.2, and almost always triggers 8.3, but are also unquestionably within the scope of Section 8 (material changes).

So there's no scenario in which BRG 6.2.6 can be exercised without triggering Section 8 and its requirements, hence why I'm trying to understand the concern.

As I can't imagine any scenario in which the generation of a private key on behalf of a subordinate CA would bring any benefit to the ecosystem but it paves the way to plenty of risky behaviors I think it would be worth discussing here if this should be accepted by the Mozilla community.

I mean, this is a regularly practiced thing in the ecosystem. Organization A creates a CA on Organization B's behalf, while Organization B bootstraps to become a CA. Until such a time as there is a positive dispensation on Organization B operating such a CA, it typically acts as an RA for Organization A, in which the CA is effectively a "Managed CA" in which B is the policy authority, while A is the operational authority. Upon completion of review, Organization A transfers that key material and operational control to Organization B, with that intermediate effectively serving as a cross-signed root.

There's nothing intrinsically wrong in what 6.2.6 describes, and I think the disconnect might be reading 6.2.6 as if the events immediately precede eachother, rather than being spread out over time (e.g. for public discussion and review). The BRGs are fairly light touch in this regard, merely trying to ensure that during the transport activity, it's protected. This saw significant discussion on m.d.s.p. - perhaps this thread is helpful for understanding more?

[RufusJWB]

I still believe it is strange, that a CA creates a key pair for a subordinate CA, but since it seems to be not uncommon, I'll close this issue.

[sleevi]

Sorry, just wanted to reopen, to make sure we’re not missing an opportunity to provide greater clarity and guidance, since this was a legitimate question 😅

[RufusJWB]

As I can't imagine any scenario in which the generation of a private key on behalf of a subordinate CA would bring any benefit to the ecosystem but it paves the way to plenty of risky behaviors I think it would be worth discussing here if this should be accepted by the Mozilla community.

I mean, this is a regularly practiced thing in the ecosystem. Organization A creates a CA on Organization B's behalf, while Organization B bootstraps to become a CA. Until such a time as there is a positive dispensation on Organization B operating such a CA, it typically acts as an RA for Organization A, in which the CA is effectively a "Managed CA" in which B is the policy authority, while A is the operational authority. Upon completion of review, Organization A transfers that key material and operational control to Organization B, with that intermediate effectively serving as a cross-signed root.

Just to be sure, that we are on the same page: what do you mean with

Organization A transfers that key material and operational control to Organization B

? I understand this as the following: Organization B has an empty HSM on its premises. Organization A extracts the key material out of their HSMs, deletes the keys in their HSMs and hands the extracted key material (together with all backups) over to Organization B. Organization B imports the key material into their HSMs (and safely stores the backups).

Do you understand this the same?

[sleevi]

Yes. It can be that, but it’s not exclusively that.

For example, we’ve seen physical transfers of HSM ownership: e.g. A acquires a series of HSMs, generates the keys in these “blank” HSMs within their facility, and then physically transfer the HSM to B and their facility. Alternatively, it can be the production of recovery keys (and N-of-M smart card split), deleting from A’s devices, and then B, who has acquired devices from the same HSM vendor, recovering using the N-of-M split.

You can find quite a bit of discussion about these ceremonies on the list.

[RufusJWB]

I must have missed @sleevi last comment on this thread. Since there is already a clear prohibition for CAs to generate subscriber key-pairs in chapter 6.1.1.3 of the TLS BRs I'd like to reiterate, that I believe that the generation of (Sub-)CA key pairs by the Root CA opens the door to a big bunch of risky behavior and should be banned based on a risk-benefit-analysis.