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 <cscwg-public-bounces at cabforum.org> on behalf of Martijn Katerbarg via Cscwg-public <cscwg-public at cabforum.org>
Sent: Wednesday, November 22, 2023 9:22 AM
To: Bruce Morton <bruce.morton at entrust.com>; cscwg-public at cabforum.org <cscwg-public at cabforum.org>; Tim Hollebeek <tim.hollebeek at digicert.com>
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 <Bruce.Morton at entrust.com>
Date: Wednesday, 22 November 2023 at 14:34
To: Martijn Katerbarg <martijn.katerbarg at sectigo.com>, cscwg-public at cabforum.org <cscwg-public at cabforum.org>, Tim Hollebeek (tim.hollebeek at digicert.com) <tim.hollebeek at digicert.com>
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:tim.hollebeek at digicert.com> @Tim Hollebeek (tim.hollebeek at digicert.com) does this work for you?
Thanks, Bruce.
From: Martijn Katerbarg <martijn.katerbarg at sectigo.com>
Sent: Wednesday, November 22, 2023 3:32 AM
To: Bruce Morton <Bruce.Morton at entrust.com>; cscwg-public at cabforum.org
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 <cscwg-public-bounces at cabforum.org <mailto:cscwg-public-bounces at cabforum.org> > on behalf of Bruce Morton via Cscwg-public <cscwg-public at cabforum.org <mailto:cscwg-public at cabforum.org> >
Date: Tuesday, 21 November 2023 at 20:25
To: cscwg-public at cabforum.org <mailto:cscwg-public at cabforum.org> <cscwg-public at cabforum.org <mailto:cscwg-public at cabforum.org> >
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/cscwg-public/attachments/20231122/b5d907c0/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5231 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/cscwg-public/attachments/20231122/b5d907c0/attachment-0001.p7s>