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
CSC-14 - Convert Code Signing Baseline Requirements to RFC 3647 Framework #6
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Based on our email discussion.
docs/CSBR.md
Outdated
| 2021-11-01 | 3.2.2.1 (5) | The method used to verify the identity of the Certificate Requester SHALL be per section 3.2.3.| | ||
| 2022-03-31 | 7.1.6.3 | Subordinate CA Certificates issued for Subordinate CA that issues Timestamp Certificates and is an Affiliate of the Issuing CA must include the reserved identifier specified in Section 7.1.6.1.| | ||
| 2022-04-30 | 7.1.3.2.1 | CAs SHALL NOT support SHA-1 digest algorithm for Timestamp tokens.| | ||
|
||
## 1.3 PKI participants | ||
|
||
### 1.3.1 Certification authorities | ||
|
||
### 1.3.2 Registration authorities |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The existing section 14.2 refers to "Registration Authorities and Subcontractors". I wonder if it would be a violation to include the "subcontractors" in the title of section 1.3.2. After all, this section also talks about "signing services" which are far from "Registration Authorities".
docs/CSBR.md
Outdated
|
||
## 5.3 Personnel controls | ||
|
||
As specified in EV Guidelines Section 14.1. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As written I interpret this as being required for both Non EV and EV CSC, is that the intent?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, the intent is to encompass both OVCS and EVCS, as that is the current requirement in CSBR 14.1 as of 2021-06-01. Do you think there's value in explicitly stating that this requirement is applicable to both OVCS and EVCS?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There are 2 differences that stand out to me that may be worth calling out in this document. 14.1.3: I think here we are saying that the issuance of any type of CSC requires 2 validation specialists. 14.1.2: "The required internal examination must relate to the EV Certificate validation criteria outlined in these Guidelines." We can add a statement from the BRs to state that the examination must be related to the CSCBR instead of the EVG, "The CA SHALL require all Validation Specialists to pass an examination provided by the CA on the information verification requirements outlined in these Requirements."
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Unless I'm misreading your suggestion regarding section 14.1.3, I think that 4.2.1 will be sufficiently clear that at least 2 Validation Specialists must validate and review the certificate request: "Prior to issuing Code Signing Certificates, the CA SHALL perform "due diligence" verification as specified in EV Guidelines 11.13.". Given this, I'm not sure we need to repeat that requirement here.
The CA SHALL require all Validation Specialists to pass an examination provided by the CA on the information verification requirements outlined in these Requirements.
I like this language; I'll add in the next commit.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My reasoning for the call out is simply clarity. A reader unfamiliar with requirements may confuse references to EVG to be applicable to EV Code Signing only. I don't feel too strongly about this so I'm good either way.
docs/CSBR.md
Outdated
|
||
For EV Code Signing Certificates, use of documents, data, and previous validations performed per [Section 3.2](#32-initial-identity-validation) SHALL be governed by the usage periods as defined in EV Guidelines Section 11.14. | ||
|
||
Prior to issuing Code Signing Certificates, the CA SHALL perform "due diligence" verification as specified in EV Guidelines 11.13. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this particular statement for EV only? The way it is laid out being underneath a paragraph beginning with "For EV..." makes me think it is.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you think switching the order of these sentences would help to clarify?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, if it's meant to apply to all types, I would suggest moving it up to line 383.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The "due diligence" requirement already exists in CSBR section 11.8, and it is universal to all CS certificate types. Thanks for flagging this; I'll switch the sentence order in my next commit.
|
||
### 4.1.1 Who can submit a certificate application | ||
For Non-EV Code Signing Certificates, the CA SHALL implement procedures to identify suspicious certificate requests as defined in BR Section 4.1.1. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
BR v1.8.2, Section 4.1.1 says No Stipulation, is this as intended?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This was removed recently in the BRs via ballot SC50
The current CSBRs refer to BRs version 1.6.9,
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So the intent is to include the stipulation, "The CA SHALL maintain an internal database of all previously revoked Certificates and previously rejected certificate requests due to suspected phishing or other fraudulent usage or concerns. The CA SHALL use this information to identify subsequent suspicious certificate requests." Correct? If so, can we add that language to this policy? Are there any other reasons the 1.6.9 version is used instead of the 1.8.2?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For the initial RFC 3647 reformat, we agreed to continue referencing BR 1.6.9. In a subsequent ballot, we will incorporate all language directly into the CSBRs and also evaluate all areas where we currently reference and use the latest BR language if appropriate. Incorporating all referenced text in this initial ballot was deemed to add complexity, so we decided to not do that now.
@cabforum/codesigning-chairs I believe this PR is ready to merge. Please review and approve. |
LGTM |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM as well
RFC 3647 defines a standard framework for outlining the obligations of participants in a PKI. Following the recommended framework as specified in RFC 3647 allows for easier comparison of “The Baseline Requirements for the Issuance and Management of Publicly‐Trusted Code Signing Certificates” with other policy documents, most notably work products of other CA/Browser Forum working groups and individual Certification Authority Certificate Policies and Certification Practice Statements. This ballot restates all existing obligations and requirements that are contained in The Baseline Requirements for the Issuance and Management of Publicly‐Trusted Code Signing Certificates” in the outline recommended by RFC 3647.