Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Replace PKI system with Certificate Management System in 5.4.1 #329

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

pjain-fastly
Copy link

No description provided.

@pjain-fastly pjain-fastly requested a review from a team as a code owner December 17, 2021 19:59
@pjain-fastly
Copy link
Author

Hi All,

I am proposing a change to 5.4.1 to update ‘PKI system’ to ‘Certificate Management System’ in point 3.1 Successful and unsuccessful PKI system access attempts.

Currently, PKI system is not a defined term and we have somewhat similar/overlapping defined terms already : Certificate Management System and Certificate System. I do not see a need to introduce another defined term which might create more confusion. Now, coming back to change, 5.4.1-3.1 talks about recording all access attempts to ‘PKI systems’. According to my understanding, we are trying to cover here all remote logins, sudo access attempts and physical access attempts to all systems which includes databases, database servers, storage, hosts running OCSP and CRL services, hosts running certificate issuance and registration service, HSMs etc. My proposal is that we update ‘PKI system’ to ‘Certificate Management System’ to clarify the intent of this requirement.

Open to thoughts and suggestion. This is my first time proposing a change, yay :)

@CBonnell
Copy link
Member

I definitely agree that we should be cleaning up terminology to improve clarity, and replacing "PKI system" with Defined Terms is a good step in that direction.

I'm not sure that replacing "PKI system" with "Certificate Management System" is sufficient, as the definition of "Certificate Management System" appears to be limited to those systems that are not directly involved in signing operations. To ensure that we include those Certificate issuance systems in requirement, I suggest we use the Defined Term "Certificate System" instead or use the NSR convention of explicitly listing out potentially redundant items such as "Certificate Systems, Issuing Systems, Certificate Management Systems, Security Support Systems, and Front-End / Internal-Support Systems".

More generally (not something that needs to be tackled in this ballot), but we should add a note to section 1.6.1 to denote that all definitions in the NSRs are included in the BRs, as they are used throughout the BRs (not just in section 5). For example, the NSR Defined Term "Trusted Role" is used in section 6.

@clintwilson
Copy link
Member

More generally (not something that needs to be tackled in this ballot), but we should add a note to section 1.6.1 to denote that all definitions in the NSRs are included in the BRs, as they are used throughout the BRs (not just in section 5). For example, the NSR Defined Term "Trusted Role" is used in section 6.

fwiw, I have this in my SC51 draft

@pjain-fastly
Copy link
Author

Agreeing to what Corey mentioned in the previous comment, I made the changes to the requirement to explicitly say 'Certificate Systems, Issuing Systems, Certificate Management Systems, Security Support Systems, and Front-End / Internal-Support Systems'. This aligns well with the current NSR conventions.
If anyone has any strong feelings around the need to introduce a new defined term 'PKI Systems', please chime in. Open to discussions. Thanks !!

@pjain-fastly
Copy link
Author

Looking for further feedback on this change 🙂 Once the new Netsec WG adopts the NSRs, I would really appreciate if someone can shepherd this change via a ballot. Thanks !!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants