[Cscwg-public] Ballot CSC-??: High Risk Requirements Update

Wed Nov 29 14:05:24 UTC 2023

Hi Guys,

Would like to get this closed. I am in favor of the original proposal or the option Corey has provided below. 

 <mailto:martijn.katerbarg at sectigo.com> @Martijn Katerbarg please advise your direction.

Thanks, Bruce.

From: Corey Bonnell <Corey.Bonnell at digicert.com> 
Sent: Monday, November 27, 2023 11:11 AM
To: Martijn Katerbarg <martijn.katerbarg at sectigo.com>; Bruce Morton <Bruce.Morton at entrust.com>; cscwg-public at cabforum.org; Tim Hollebeek <tim.hollebeek at digicert.com>
Subject: [EXTERNAL] RE: Ballot CSC-??: High Risk Requirements Update

Hi Martijn,

> Happy thanksgiving!

Thanks!

> In my opinion, it’s not non-existent though.

I thought the sentence you quoted is being deleted: https://github.com/cabforum/code-signing/pull/31/files#diff-904962f0e52198f4a232d6ef6732d57ccb47433d4bba47b3472d681405360e31L620.

If we want to retain that sentence, then I agree that if you consider checking if the Applicant has previously signed Suspect Code as a “high risk” check, then there are still requirements in section 4.2.1. My thinking is that such a check is discrete from “high risk”, as the (now removed) definition only tangentially encompasses the Suspect Code case (“names contained in previously rejected certificate requests or revoked Certificates”). Thus, it is not clear what the term “high risk” is referring to.

If we want to keep the sentence starting with “The CA MUST also maintain…”, then I agree with your suggestion to remove the term “high risk”. As a concrete proposal:

1.	Restore the deleted sentence
2.	Move the sentence on line 622 to the same paragraph as the restored sentence
3.	Tweak the language of the second sentence to:

“The CA MUST use this internal database to 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.”

Thoughts?

Thanks,

Corey

From: Martijn Katerbarg <martijn.katerbarg at sectigo.com <mailto:martijn.katerbarg at sectigo.com> > 
Sent: Thursday, November 23, 2023 7:28 AM
To: Corey Bonnell <Corey.Bonnell at digicert.com <mailto:Corey.Bonnell at digicert.com> >; Bruce Morton <bruce.morton at entrust.com <mailto:bruce.morton at entrust.com> >; cscwg-public at cabforum.org <mailto:cscwg-public at cabforum.org> ; Tim Hollebeek <tim.hollebeek at digicert.com <mailto:tim.hollebeek at digicert.com> >
Subject: Re: Ballot CSC-??: High Risk Requirements Update

Hi Corey,

Happy thanksgiving!

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

In my opinion, it’s not non-existent though. “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 a requirement. By then (re)adding “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.”, it directly references Section 4.2.2, which will then contain “CAs MUST NOT issue new or replacement Code Signing Certificates to an entity that the CA determined intentionally signed Suspect Code.”

Without the paragraph, I feel like Section 4.2.1 and 4.2.2 aren’t directly connected, which would mean a CA would need to check its internal database of revoked certificates, but without any requirements on what to do with the outcome of that check.

Perhaps however we could rephrase the “disputed” paragraph a bit, to make this clearer, and remove “high risk” from it?

Regards,

Martijn

From: Corey Bonnell <Corey.Bonnell at digicert.com <mailto:Corey.Bonnell at digicert.com> >
Date: Wednesday, 22 November 2023 at 19:42
To: Bruce Morton <bruce.morton at entrust.com <mailto:bruce.morton at entrust.com> >, cscwg-public at cabforum.org <mailto:cscwg-public at cabforum.org>  <cscwg-public at cabforum.org <mailto:cscwg-public at cabforum.org> >, Tim Hollebeek <tim.hollebeek at digicert.com <mailto:tim.hollebeek at digicert.com> >, Martijn Katerbarg <martijn.katerbarg at sectigo.com <mailto:martijn.katerbarg at sectigo.com> >
Subject: Re: Ballot CSC-??: High Risk Requirements Update

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 <mailto:cscwg-public-bounces at cabforum.org> > on behalf of Martijn Katerbarg via Cscwg-public <cscwg-public at cabforum.org <mailto:cscwg-public at cabforum.org> >
Sent: Wednesday, November 22, 2023 9:22 AM
To: Bruce Morton <bruce.morton at entrust.com <mailto:bruce.morton at entrust.com> >; cscwg-public at cabforum.org <mailto:cscwg-public at cabforum.org>  <cscwg-public at cabforum.org <mailto:cscwg-public at cabforum.org> >; Tim Hollebeek <tim.hollebeek at digicert.com <mailto: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 <mailto:Bruce.Morton at entrust.com> >
Date: Wednesday, 22 November 2023 at 14:34
To: Martijn Katerbarg <martijn.katerbarg at sectigo.com <mailto:martijn.katerbarg at sectigo.com> >, cscwg-public at cabforum.org <mailto:cscwg-public at cabforum.org>  <cscwg-public at cabforum.org <mailto:cscwg-public at cabforum.org> >, Tim Hollebeek (tim.hollebeek at digicert.com <mailto:tim.hollebeek at digicert.com> ) <tim.hollebeek at digicert.com <mailto: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 <mailto:martijn.katerbarg at sectigo.com> >
Sent: Wednesday, November 22, 2023 3:32 AM
To: Bruce Morton <Bruce.Morton at entrust.com <mailto:Bruce.Morton at entrust.com> >; cscwg-public at cabforum.org <mailto: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/20231129/e92ed375/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4933 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/cscwg-public/attachments/20231129/e92ed375/attachment-0001.p7s>