CA Infrastructure Scope update

[clintwilson]

Following discussions in the NSWG, this is an example version of the NCSSRs which removes several of the "Systems" from the scope of CA Infrastructure (and the document in general). The changes are based on the assumed completion of IPR review for NS-004 and NS-006.

As also touched upon in NSWG meeting on Nov 19, 2024, I slightly updated the Trusted Role definition to (hopefully) avoid its interpretation as including companies not involved in the operation of CA Infrastructure.

Additionally, fixed some minor issues arising from NS-004 and NS-006:

• Reversion of Workstation definition
• Orphaned text in 1.2.2
• Markdown formatting in 2.2.1.2

[clintwilson]

to store, access, process, or manage data

[miguelantonios]

Cloud Services Subgroup Concern: Removal of Support Systems from Certificate Systems no longer encompasses those periphery systems in any kind of requirements for controls. How can we incorporate those requirements into this definition?

[clintwilson]

Security Support Systems has been removed as a defined term.

[miguelantonios]

+1

[BenWilson-Mozilla]

Maybe this should say ", except where a formal specification prohibits ..."? It seems that "where documented that" adds an unnecessary record-creating requirement and could be deleted without changing meaning. But I'm open to other suggestions/comments.

[BenWilson-Mozilla]

For this objective, "CAs are able to clearly understand the minimum security requirements found in this document and successfully adapt/implement these Requirements to their own infrastructure and architecture" maybe add something like ", which requires a comprehensive inventory of their Certificate Systems to ensure that their infrastructure is adequately protected."

[miguelantonios]

Should this be "CA Key Escrow" as just "Key Escrow" is rather broad?

[clintwilson]

It's intended to apply also to escrow of Subscriber keys, where allowed (such as with S/MIME Certificates), so I believe it's correct as-is. Where key escrow is not performed by a CA, then this becomes not applicable (therefore neither constraining nor expanding the requirements applied to the CA).

[miguelantonios]

Leaving some comments from Cloud Services Subgroup meeting today.

tl;dr: the concern that support security systems is removed and no longer requires controls on those systems. One possible solution is to hardcode those requirements and systems within their applicable sections (e.g. Access Management systems in section 2) similar to what's already done in 3.1.2.1 "The CA SHOULD ensure retained and/or archived audit logs are kept and managed in a manner sufficiently effective to prevent unapproved alteration or access."

[miguelantonios]

Cloud Services Subgroup Concern: Removal of Support Systems from Certificate Systems no longer encompasses those periphery systems in any kind of requirements for controls. How can we incorporate those requirements into this definition?

[miguelantonios]

+1

[miguelantonios]

CS group feedback: what if we move this up so that it pertains not just to vuln management, which I don't believe was the intention?

[miguelantonios]

CS group thoughts: What if we use something similar to what is in section 3.1.2.1 "The CA SHOULD ensure retained and/or archived audit logs are kept and managed in a manner sufficiently effective to prevent unapproved alteration or access." for all other relevant security support system sections (e.g. change management, vuln management, etc.) The benefit of this is that it would bring back the requirements to protect security support systems without blowing up the trusted roles bit (which was a concern in the past).

Vuln management example: "Vuln management systems would have to be configured/locked down in a way that prevents malicious attacks on Certificate Systems"