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

CSC-14 - Convert Code Signing Baseline Requirements to RFC 3647 Framework #6

Merged
merged 31 commits into from Jun 29, 2022

Conversation

CBonnell
Copy link
Member

@CBonnell CBonnell commented Aug 31, 2021

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.

@dzacharo dzacharo mentioned this pull request Nov 17, 2021
Copy link
Contributor

@dzacharo dzacharo left a 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 Show resolved Hide resolved
docs/CSBR.md Show resolved Hide resolved
docs/CSBR.md Outdated Show resolved Hide resolved
docs/CSBR.md Outdated Show resolved Hide resolved
docs/CSBR.md Outdated Show resolved Hide resolved
docs/CSBR.md Show resolved Hide resolved
docs/CSBR.md Outdated Show resolved Hide resolved
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
Copy link
Contributor

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.

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?

Copy link
Member Author

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?

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."

Copy link
Member Author

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.

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.

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.

Copy link
Member Author

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?

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.

Copy link
Member Author

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.

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?

Copy link
Contributor

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,

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?

Copy link
Member Author

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.

@CBonnell
Copy link
Member Author

@cabforum/codesigning-chairs I believe this PR is ready to merge. Please review and approve.

@DeanJC
Copy link

DeanJC commented Jun 29, 2022

LGTM

Copy link
Contributor

@dzacharo dzacharo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM as well

@dzacharo dzacharo merged commit e345af0 into cabforum:main Jun 29, 2022
@CBonnell CBonnell deleted the rfc3647-migration branch July 14, 2022 17:32
@vanbroup vanbroup added the ballot label Jan 8, 2024
@vanbroup vanbroup changed the title RFC 3647 migration CSC-14 - Convert Code Signing Baseline Requirements to RFC 3647 Framework Jan 8, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants