Baseline Requirements: Should Technically Constrained Sub CAs require a Key Generation report?

[sleevi]

In sleevi#23 (comment) , @pfuentes69 asked:

Any chance to consider removing the need to have an independent audit for technically-constrained subordinate CAs?

and further pointing out:

Typically a technically-constrained CA can be internally audited by the CA and is not in direct scope of independent audits. I think it should be considered an exception in this case for the need to have the qualified auditor's report as a particular activity, as in any case the creation of any subordinate will be already reviewed during the period audits and that should be enough.

As presently worded in Section 6.1.1.1, if the TCSC generates the key themselves, they're subjected to requiring a Key Generation report, while if the Root CA generates the key for them, and then later transfers the key to the TCSC, they are not.

The challenge is in making sure that no one misinterprets the section and allows a key generation for a TCSC (without audit), and then allows that to be used for a Subordinate CA by arguing that the key was previously generated, ergo 6.1.1.1 doesn't apply.

This effort may be a sub-section of the overall improvement to Key Lifecycle and about the necessary audit reports (Key Generation, a "Key Storage Report" as discussed in meeting 45, the annual audit report, and a key destruction report), clarifying the lifecycle expectations for Root CAs and Subordinate CAs (including Cross-Certificates and TCSCs)

[pfuentes69]

(Let's see if I'm using GitHub properly)

In my understanding, the Root CA would only be allowed to rightfully sign the key of the subordinate if the whole process is in compliance with the BR.

So, assuming that the exception for technically-constrained CAs is considered, if the Root signs a non-constrained subordinate without an audited key generation then the Root itself is violating the BR and would fail in the next period audit, which is a huge risk that no CA would take.

Just as a side note, I never liked to dissociate the key generation of the CA certificate signing, and we make it part of the same ceremony and script.

[sleevi]

@pfuentes69 While I agree that's the "intended conclusion", the challenge is plainly expressing this.

We know CAs reuse previously generated keys all the time - e.g. when reissuing new versions of intermediates, or when obtaining a Cross-Certificate for a previously-generated Root Certificate.

The BRs do not require a fresh key per Certificate, and if they did, that would (effectively) prohibit Cross Certificates.

I do think the challenge should be solvable, but I think it would require a bigger rewrite of that section, which is why I wanted to split it out from sleevi#23 . For example, emphasizing that the key generation (whenever it was done) has to comply with the current requirements, prior to issuing a certificate for it. However, the way it's currently structured, it seems to be aligned with "used" - as in a statement of intent - and we know that has caused CAs confusion about requirements.

Restructuring the section would make it clear that it's about "Prior to issuing a Certificate, the Issuing CA SHALL confirm:" sort of approach, by making sure that before each issuance, the Issuer makes sure all the key generation paperwork is in order, was how I was thinking about tackling that.

However, in looking at how to do that restructure, it also became clear that there's the scenario where the Key Generation was 5 years ago, and then the Key itself wasn't included in any audit scopes (this is the Shanghai discussion mentioned above), and that would also be bad and not aligned with intent. That's why I suggest that allowing this, while not introducing loopholes, probably requires more broadly tackling the Key Lifecycle Management problem from Wayne's presentation.

[pfuentes69]

Maybe a possible way to sort out this is to add some content in 4.2.2, stipulating that a CA cannot sign a certificate for a subordinate it the key doesn't meet the conditions of 6.1.1. Then we could safely add the exception for constrained CAs, and it would be clearly a responsibility of the issuer to approve or reject the signing request.

[sleevi]

@pfuentes69 I considered that, but that's not sufficient to address the concerns I was highlighting in #187 (comment)

I think we can accomplish this with only requiring changes to 6.1.1, but I don't think it's a small edit. In the meantime, I see no harm in the existing status quo, as this is only about enabling an optimization for CAs.

[barrini]

@pfuentes69 Pedro, any update on this matter? F2F 60 discussion indicated that this could be closed.

[pfuentes69]

@barrini I don't have an update on my side.
I opened this issue to request a change in the BR, so Technically Constrained CAs don't need a ceremony report with an independent auditor, but can audited by the CA.
At that time, Ryan Sleevi had concerns and the discussion stalled, as no other gave their opinion in one sense or the other.

Therefore, no advance since then, so unless another wants to assert their opinion, we can take this as closed due of lack of interest of the community to discuss this topic.

[BenWilson-Mozilla]

Just to clarify one aspect of this issue - if an Externally-Operated, non-technically constrained CA seeks a subordinate, or cross certificate from a publicly trusted root, then they should provide the operator of that root with a key generation report.

[pfuentes69]

Just to clarify one aspect of this issue - if an Externally-Operated, non-technically constrained CA seeks a subordinate, or cross certificate from a publicly trusted root, then they should provide the operator of that root with a key generation report.

Thanks, @BenWilson-Mozilla for the clarification.

In this case the topic I raised is the need (according to the BR) to provide an independent audit for the ceremony also in the case of technically constrained CAs, because the rules don't differentiate if the externally-operated subCA is constrained or not.

What I was proposing was the possibility to leave this under internal audit, like the case of subordinates operated by the owner of the root, which don't need to involve an external auditor.

[barrini]

Dimitris to make another review with Pedro