I’m not sure retaining the clause starting with “A CA identifying a high risk application under this section…” provides much clarity or value. Two reasons:
1. All other language concerning high risk checks in section 4.2.1 has been struck. The turn of phrase “under this section” implies there are additional requirements defined in this section, but there are none. This will likely result in confusion. 2. The requirement for the CA to confirm that the Applicant has not been the victim of multiple Takeover Attacks is still present in section 4.2.2. I’m not sure we need a reference to that requirement in another section. I’m partial to removing the clause entirely. However, if the group agrees that it should be retained, then I think at the very least the language needs to be modified to no longer imply that there are (non-existent) requirements in the current section. Thanks, Corey _____ From: Cscwg-public <[email protected]> on behalf of Martijn Katerbarg via Cscwg-public <[email protected]> Sent: Wednesday, November 22, 2023 9:22 AM To: Bruce Morton <[email protected]>; [email protected] <[email protected]>; Tim Hollebeek <[email protected]> Subject: Re: [Cscwg-public] Ballot CSC-??: High Risk Requirements Update Hi Bruce, Going for the full clarification: The PR show that: ”Prior to issuing a Code Signing Certificate, each CA SHOULD check at least one database containing information about known or suspected producers, publishers, or distributors of Suspect Code, as identified or indicated by an Anti-Malware Organization and any database of deceptive names maintained by an Application Software Provider. The CA MUST determine whether the entity is identified as requesting a Code Signing Certificate from a High Risk Region of Concern. The CA MUST also maintain and check an internal database listing Certificates revoked due to Code Signatures on Suspect Code and previous certificate requests rejected by the CA. ” Is being replaced with: ”Prior to issuing a Code Signing Certificate, each CA SHOULD check at least one database containing information about known or suspected producers, publishers, or distributors of Suspect Code, as identified or indicated by an Anti-Malware Organization and any database of deceptive names maintained by an Application Software Provider. The CA MUST also maintain and check an internal database listing Certificates revoked due to Code Signatures on Suspect Code and previous certificate requests rejected by the CA. ” That makes sense. Then the PR goes on to additionally remove: “A CA identifying a high risk application under this section MUST follow the additional procedures defined in [Section 4.2.2](#422-approval-or-rejection-of-certificate-applications) of this document to ensure that the applicant will protect its Private Keys and not sign Suspect Code.” That’s the part I think should remain. So yes, I think we’re on the same page with that one 😊 Regards, Martijn From: Bruce Morton <[email protected]> Date: Wednesday, 22 November 2023 at 14:34 To: Martijn Katerbarg <[email protected]>, [email protected] <[email protected]>, Tim Hollebeek ([email protected]) <[email protected]> Subject: RE: Ballot CSC-??: High Risk Requirements Update Hi Martijn, For clarification, for the following two paragraphs which have been deleted, you would like the first deleted and the second to remain: Prior to issuing a Code Signing Certificate, each CA SHOULD check at least one database containing information about known or suspected producers, publishers, or distributors of Suspect Code, as identified or indicated by an Anti-Malware Organization and any database of deceptive names maintained by an Application Software Provider. The CA MUST determine whether the entity is identified as requesting a Code Signing Certificate from a High Risk Region of Concern. The CA MUST also maintain and check an internal database listing Certificates revoked due to Code Signatures on Suspect Code and previous certificate requests rejected by the CA. A CA identifying a high risk application under this section MUST follow the additional procedures defined in [Section 4.2.2](#422-approval-or-rejection-of-certificate-applications) of this document to ensure that the applicant will protect its Private Keys and not sign Suspect Code. If so, I agree to this change. Please confirm. <mailto:[email protected]> @Tim Hollebeek ([email protected]) does this work for you? Thanks, Bruce. From: Martijn Katerbarg <[email protected]> Sent: Wednesday, November 22, 2023 3:32 AM To: Bruce Morton <[email protected]>; [email protected] Subject: [EXTERNAL] Re: Ballot CSC-??: High Risk Requirements Update Bruce, I’ve added a single comment on the PR, as I think we’ve removed one paragraph too much. Other than that, I’m also happy to endorse. Regards, Martijn From: Cscwg-public <[email protected] <mailto:[email protected]> > on behalf of Bruce Morton via Cscwg-public <[email protected] <mailto:[email protected]> > Date: Tuesday, 21 November 2023 at 20:25 To: [email protected] <mailto:[email protected]> <[email protected] <mailto:[email protected]> > Subject: [Cscwg-public] Ballot CSC-??: High Risk Requirements Update CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. Here is a draft of the High Risk Requirements update ballot. Looking for comments and 2 endorsers. There is no future effectivity date proposed, since the ballot does not add new requirements. Thanks, Bruce. Purpose of the Ballot This ballot updates the “Baseline Requirements for the Issuance and Management of Publicly‐Trusted Code Signing Certificates“ version 3.4 in order to clarify language regarding Signing Service and signing requests. The main goals of this ballot are to: 1. Remove references to High Risk Certificate Request, since the CSBRs do not provide any actions for a high risk application. 2. Remove references to High Risk Region of Concern, since the CSBR appendix has never been populated. 3. Remove rules for a Takeover Attack to require the Subscriber to generate keys in a crypto device, since crypto device key generation is now a baseline requirement for all code signing certificates. 4. Remove option to transfer private key which has been generated in software. 5. Cleanup to remove Subscriber key generation option which expired effective 1 June 2023. 6. Cleanup to remove “any other method” to verify the Subscriber key was generated in a crypto device, since this option expired 1 June 2023. The following motion has been proposed by Bruce Morton of Entrust and endorsed by ?? and ??. MOTION BEGINS This ballot updates the “Baseline Requirements for the Issuance and Management of Publicly‐Trusted Code Signing Certificates” ("Code Signing Baseline Requirements") based on version 3.4. MODIFY the Code Signing Baseline Requirements as specified in the following redline: https://github.com/cabforum/code-signing/pull/31/files <https://url.avanan.click/v2/___https:/github.com/cabforum/code-signing/pull/31/files___.YXAzOmRpZ2ljZXJ0OmE6bzpiNzQxNmRlMjNkMjlmN2JiMWRlMmQwZDlhZGFjN2YzNDo2OjE1MzA6MTgzMDJkZjgwZjQ5NDU3MzljY2EyODY5MGE0NzcwZDExY2ExMDE1ZWE5ZWUyOTNjNmEwMjQxYWYwMGQ5NWE4YTpoOkY> MOTION ENDS The procedure for this ballot is as follows: Discussion (7 days) 1. Start Time: TBD 2. End Time: TBD Vote for approval (7 days) 3. Start Time: TBD 4. End Time: TBD Any email and files/attachments transmitted with it are intended solely for the use of the individual or entity to whom they are addressed. If this message has been sent to you in error, you must not copy, distribute or disclose of the information it contains. Please notify Entrust immediately and delete the message from your system.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Cscwg-public mailing list [email protected] https://lists.cabforum.org/mailman/listinfo/cscwg-public
