[Cscwg-public] [EXTERNAL] Re: Update to Subscriber Private Key Protection Requirements (CSC-6 to CSC-13)

Tue Mar 22 15:43:50 UTC 2022

Hi Adriano,

Sorry, I have been disconnected from email and work all last week.

This is a good catch, and I've updated the table to include this feedback as well as call out 16.3.1 (7-9) as being required after November 15, 2022. Please see the attached redline with this update.

Thanks,
Ian

________________________________
From: Adriano Santoni
Sent: Monday, March 21, 2022 6:58 AM
To: Ian McMillan; Bruce Morton; cscwg-public at cabforum.org; Inigo Barreira; Dimitris Zacharopoulos (HARICA)
Subject: [EXTERNAL] Re: [Cscwg-public] Update to Subscriber Private Key Protection Requirements (CSC-6 to CSC-13)

All,

I am not clear why the table of Relevant dates does not include this one, which seems to be the most important and demanding one:

Effective November, 15, 2022, for Code Signing Certificates, CAs SHALL ensure that the Subscriber’s Private Key is generated, stored, and used in a suitable Hardware Crypto Module that meets or exceeds the requirements specified in section 16.3.1

This, in fact, requires that all existing code signing certificate application web forms that allow a CSR to be pasted be removed by November 15, if not profoundly modified in order to comply with §16.3.1, if I am not mistaken.

Adriano

Il 10/03/2022 22:46, Ian McMillan ha scritto:

Thank you Bruce!

Attached is the updated redline with the removal of the first addition of “contractual” which you called out as changing the current requirement.

Thanks

Ian

From: Bruce Morton <Bruce.Morton at entrust.com><mailto:Bruce.Morton at entrust.com>
Sent: Thursday, March 10, 2022 4:12 PM
To: Ian McMillan <ianmcm at microsoft.com><mailto:ianmcm at microsoft.com>; cscwg-public at cabforum.org<mailto:cscwg-public at cabforum.org>; Inigo Barreira <Inigo.Barreira at sectigo.com><mailto:Inigo.Barreira at sectigo.com>; Dimitris Zacharopoulos (HARICA) <dzacharo at harica.gr><mailto:dzacharo at harica.gr>; Adriano Santoni <adriano.santoni at staff.aruba.it><mailto:adriano.santoni at staff.aruba.it>
Subject: [EXTERNAL] RE: [Cscwg-public] Update to Subscriber Private Key Protection Requirements (CSC-6 to CSC-13)

Hi Ian,

We added “contractual” representation in 2 places in section 16.3.1. I believe that the first “contractual” should be removed as this is changing an existing requirement which will not be effective as of 15 November 2022. The second “contractual” should remain as this is a new requirement which the CAs must meet effective 15 November 2022.

With that change, I am good to endorse the ballot.

Thanks, Bruce.

From: Cscwg-public <cscwg-public-bounces at cabforum.org<mailto:cscwg-public-bounces at cabforum.org>> On Behalf Of Ian McMillan via Cscwg-public
Sent: Thursday, March 10, 2022 12:43 PM
To: Inigo Barreira <Inigo.Barreira at sectigo.com<mailto:Inigo.Barreira at sectigo.com>>; cscwg-public at cabforum.org<mailto:cscwg-public at cabforum.org>; Dimitris Zacharopoulos (HARICA) <dzacharo at harica.gr<mailto:dzacharo at harica.gr>>; Adriano Santoni <adriano.santoni at staff.aruba.it<mailto:adriano.santoni at staff.aruba.it>>
Subject: [EXTERNAL] Re: [Cscwg-public] Update to Subscriber Private Key Protection Requirements (CSC-6 to CSC-13)

WARNING: This email originated outside of Entrust.
DO NOT CLICK links or attachments unless you trust the sender and know the content is safe.

________________________________

Hi Folks,

Coming out of the meeting today we’ve made some additional changes to address the term “representation” in section 16 by adding changing it to “contractual representation”.

Please review the changes in the attached redline document.

Tim and Bruce would you review and please reply back with your confirmed willingness to endorse this ballot as CSC-13?

Thanks,

Ian

From: Cscwg-public <cscwg-public-bounces at cabforum.org<mailto:cscwg-public-bounces at cabforum.org>> On Behalf Of Inigo Barreira via Cscwg-public
Sent: Wednesday, March 9, 2022 12:15 PM
To: Dimitris Zacharopoulos (HARICA) <dzacharo at harica.gr<mailto:dzacharo at harica.gr>>; cscwg-public at cabforum.org<mailto:cscwg-public at cabforum.org>; Adriano Santoni <adriano.santoni at staff.aruba.it<mailto:adriano.santoni at staff.aruba.it>>
Subject: [EXTERNAL] Re: [Cscwg-public] Update to Subscriber Private Key Protection Requirements (CSC-6 to CSC-13)

Right, it´s not a new thing but I realized now, sorry. It´s just the word “representation” that confuses me and after explanations is more confusing.

De: Dimitris Zacharopoulos (HARICA) <dzacharo at harica.gr<mailto:dzacharo at harica.gr>>
Enviado el: miércoles, 9 de marzo de 2022 18:00
Para: Inigo Barreira <Inigo.Barreira at sectigo.com<mailto:Inigo.Barreira at sectigo.com>>; cscwg-public at cabforum.org<mailto:cscwg-public at cabforum.org>; Adriano Santoni <adriano.santoni at staff.aruba.it<mailto:adriano.santoni at staff.aruba.it>>
Asunto: Re: [Cscwg-public] Update to Subscriber Private Key Protection Requirements (CSC-6 to CSC-13)

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.

It's best if we add the subscriber warranties and expectations in one place but my point was that we already expect things from Certificate Subscribers. It's not a new thing, as you presented it.

Dimitris.

On 9/3/2022 6:03 μ.μ., Inigo Barreira wrote:

Nope. In section 7.2 (which is for certificate warranties) there´s no clear indication on this unless you consider 1) compliance and 6) key protection enough. Section 7.3 says nothing about this. Further, there´s no definition of “representation” in section 4 and hence my question because I was thinking on a different matter.

De: Dimitris Zacharopoulos (HARICA) <dzacharo at harica.gr><mailto:dzacharo at harica.gr>
Enviado el: miércoles, 9 de marzo de 2022 14:08
Para: Inigo Barreira <Inigo.Barreira at sectigo.com><mailto:Inigo.Barreira at sectigo.com>; cscwg-public at cabforum.org<mailto:cscwg-public at cabforum.org>; Adriano Santoni <adriano.santoni at staff.aruba.it><mailto:adriano.santoni at staff.aruba.it>
Asunto: Re: [Cscwg-public] Update to Subscriber Private Key Protection Requirements (CSC-6 to CSC-13)

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.

On 9/3/2022 2:58 μ.μ., Inigo Barreira wrote:

I agree with Adriano. Point 1 does not make customer accountable for anything (I will promise I´m a good guy) and then point 2 is useless because with point 1 you´re allowing the customer to do whatever, independently if they use a hardw device or not. The CSRs can be generated in a crypto device or not and with point 1 you, as the CA, are “sure” that the keys are in a hardware crypto device. That´s a lot to assume.

You are missing the point of Subscriber representations and warranties which is clearly included in the BRs. Subscribers have obligations as well and we must ensure they are aware and bound to those obligations.

Dimitris.

De: Cscwg-public <cscwg-public-bounces at cabforum.org><mailto:cscwg-public-bounces at cabforum.org> En nombre de Dimitris Zacharopoulos (HARICA) via Cscwg-public
Enviado el: miércoles, 9 de marzo de 2022 13:27
Para: Adriano Santoni <adriano.santoni at staff.aruba.it><mailto:adriano.santoni at staff.aruba.it>; cscwg-public at cabforum.org<mailto:cscwg-public at cabforum.org>
Asunto: Re: [Cscwg-public] Update to Subscriber Private Key Protection Requirements (CSC-6 to CSC-13)

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.

I believe this language and double confirmation comes from years ago when tools like remote key attestation were not available.

If we are to allow an Applicant to generate keys remotely (i.e. without the presence of a CA representative and without hardware that supports remote key attestation), which seems to be the case with the CSCWG today, we need to rely on policy to accomplish that. It is reasonable to hold both sides, the Applicant and the CA, accountable to this policy. See below.

On 9/3/2022 11:43 π.μ., Adriano Santoni via Cscwg-public wrote:

As far as I'm concerned, I find confusing and overly complex the double requirement:

1) customer must make a "representation" that they will use a hardware crypto module (or signing service), and ...

This is required because a customer could potentially "fake" the hardware device id and create a virtual driver that emulates the actual hardware device. The Applicant must be held accountable if they try to manipulate the process or make any changes to the process and tools provided by the CA.

2) the CA must ensure that the customer will really use a hardware crypto module (or signing service).

The CA must establish a process and develop the proper tools to provide reasonable assurance that the Applicant remotely generates keys in a hardware crypto module which is usually within a limited set of devices approved by the CA. The CA is not allowed to say "please send me a CSR and pinky swear that it was generated in a crypto device". They must develop tools and middleware and establish a process to make sure the key is generated in approved crypto-devices only.

If the CA will be obliged to meet req #2, then I do not see what use is req #1.

Hope this explanation helps.
Dimitris.

Adriano

-- Actalis

Il 09/03/2022 10:21, Inigo Barreira via Cscwg-public ha scritto:

Yes, please.

It looks like this representation means something like “click here if you are over 18” or “click here if you agree” because these are also facts not opinions.

IMO the message here is that CAs will rely in whatever the subscriber says, e.g.,  “yes, I´m a good guy and promise that I will keep my keys in a hardware device …” rather on making the corresponding tasks to ensure. Is this the right approach? This is what I understand from Dean´s response because CAs are not attesting anything just relying in a form signed by the subscriber in where it may say whatever.

Regards

De: Tim Hollebeek <tim.hollebeek at digicert.com><mailto:tim.hollebeek at digicert.com>
Enviado el: martes, 8 de marzo de 2022 20:35
Para: Dean Coclin <dean.coclin at digicert.com><mailto:dean.coclin at digicert.com>; Inigo Barreira <Inigo.Barreira at sectigo.com><mailto:Inigo.Barreira at sectigo.com>; cscwg-public at cabforum.org<mailto:cscwg-public at cabforum.org>; Bruce Morton <bruce.morton at entrust.com><mailto:bruce.morton at entrust.com>; Doug Beattie <doug.beattie at globalsign.com><mailto:doug.beattie at globalsign.com>; Ian McMillan <ianmcm at microsoft.com><mailto:ianmcm at microsoft.com>
Asunto: RE: Update to Subscriber Private Key Protection Requirements (CSC-6 to CSC-13)

“representation” is being used here in the legal sense: “a statement of fact. A representation should be distinguished from a statement of opinion for many legal purposes, especially in relation to contractual obligations.”

We should perhaps be using plain English instead of legalese.

-Tim

From: Dean Coclin <dean.coclin at digicert.com<mailto:dean.coclin at digicert.com>>
Sent: Tuesday, March 8, 2022 1:00 PM
To: Inigo Barreira <Inigo.Barreira at sectigo.com<mailto:Inigo.Barreira at sectigo.com>>; cscwg-public at cabforum.org<mailto:cscwg-public at cabforum.org>; Bruce Morton <bruce.morton at entrust.com<mailto:bruce.morton at entrust.com>>; Doug Beattie <doug.beattie at globalsign.com<mailto:doug.beattie at globalsign.com>>; Ian McMillan <ianmcm at microsoft.com<mailto:ianmcm at microsoft.com>>; Tim Hollebeek <tim.hollebeek at digicert.com<mailto:tim.hollebeek at digicert.com>>
Subject: RE: Update to Subscriber Private Key Protection Requirements (CSC-6 to CSC-13)

This means exactly what it says, some representation that the subscriber makes to honor the condition. This traditionally has been something in writing that the subscriber signs and submits to the CA. CAs can provide a form to the subscriber which they attest to.

From: Cscwg-public <cscwg-public-bounces at cabforum.org<mailto:cscwg-public-bounces at cabforum.org>> On Behalf Of Inigo Barreira via Cscwg-public
Sent: Tuesday, March 8, 2022 11:03 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>; Doug Beattie <doug.beattie at globalsign.com<mailto:doug.beattie at globalsign.com>>; Ian McMillan <ianmcm at microsoft.com<mailto:ianmcm at microsoft.com>>; Tim Hollebeek <tim.hollebeek at digicert.com<mailto:tim.hollebeek at digicert.com>>
Subject: Re: [Cscwg-public] Update to Subscriber Private Key Protection Requirements (CSC-6 to CSC-13)

Hi all,

Reviewing the section 16.3.1 I have a “wording” question. What does it mean that “The CA MUST obtain a representation from the Subscriber that the Subscriber will use one of the following options …”. So, what is a “representation from the subscriber”?

Regards

De: Cscwg-public <cscwg-public-bounces at cabforum.org<mailto:cscwg-public-bounces at cabforum.org>> En nombre de Bruce Morton via Cscwg-public
Enviado el: jueves, 3 de marzo de 2022 15:08
Para: Doug Beattie <doug.beattie at globalsign.com<mailto:doug.beattie at globalsign.com>>; Ian McMillan <ianmcm at microsoft.com<mailto:ianmcm at microsoft.com>>; Tim Hollebeek <tim.hollebeek at digicert.com<mailto:tim.hollebeek at digicert.com>>; cscwg-public at cabforum.org<mailto:cscwg-public at cabforum.org>
Asunto: Re: [Cscwg-public] Update to Subscriber Private Key Protection Requirements (CSC-6 to CSC-13)

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.

Doug,

Regarding the 16.2 section, this statement was also struck-out, “After 2021-06-01, the same protection requirements SHALL apply to Non EV Code Signing Certificates.” So I believe that the requirement already applied to normal code signing certificates. The edits are just a cleanup.

Bruce.

From: Doug Beattie <doug.beattie at globalsign.com<mailto:doug.beattie at globalsign.com>>
Sent: Thursday, March 3, 2022 6:56 AM
To: Ian McMillan <ianmcm at microsoft.com<mailto:ianmcm at microsoft.com>>; Tim Hollebeek <tim.hollebeek at digicert.com<mailto:tim.hollebeek at digicert.com>>; cscwg-public at cabforum.org<mailto:cscwg-public at cabforum.org>; Bruce Morton <Bruce.Morton at entrust.com<mailto:Bruce.Morton at entrust.com>>
Subject: [EXTERNAL] RE: Update to Subscriber Private Key Protection Requirements (CSC-6 to CSC-13)

WARNING: This email originated outside of Entrust.
DO NOT CLICK links or attachments unless you trust the sender and know the content is safe.

________________________________

Hi Ian,

Good work on section 16.3, that is much more clear now.  I have 2 more comments for your consideration.

Comment #1:

In Section 11.7 we say:

If the CA is aware that the Applicant was the victim of a Takeover Attack, the CA MUST verify that the Applicant is protecting its Code Signing Private Keys under Section 16.3.1(1) or Section 16.3.1(2). The CA MUST verify the Applicant’s compliance with Section 16.3.1(1) or Section 16.3.1(2) (i) through technical means that confirm the Private Keys are protected using the method described in 16.3.1(1) or 16.3.1(2) or (ii) by relying on a report provided by the Applicant that is signed by an auditor who is approved by the CA and who has IT and security training or is a CISA.

But now there are actually 2 lists in sections 16.3.1(1) or Section 16.3.1(2) with those list numbers.  Do we need to be more specific, or renumber the second list a-c?

After 15 November, what is the right remediation for Take Over attack, do we need to reference one or more of the items in the new list (the list we might renumber a-c), or is there no remediation now?

There are multiple references to 16.3.1(1) so we’d want to apply the same logic to all instances.

Comment #2:

Section 16.2 removed the reference to EV in the scope so this applies to normal Code signing certificates.  Since this does not have a date associated with it, do we assume that this requirement change for normal code signing certs is effective immediately?

From: Ian McMillan <ianmcm at microsoft.com<mailto:ianmcm at microsoft.com>>
Sent: Wednesday, March 2, 2022 5:56 PM
To: Tim Hollebeek <tim.hollebeek at digicert.com<mailto:tim.hollebeek at digicert.com>>; cscwg-public at cabforum.org<mailto:cscwg-public at cabforum.org>; Doug Beattie <doug.beattie at globalsign.com<mailto:doug.beattie at globalsign.com>>; Bruce Morton <bruce.morton at entrust.com<mailto:bruce.morton at entrust.com>>
Subject: RE: Update to Subscriber Private Key Protection Requirements (CSC-6 to CSC-13)

Thank you, Tim, I really like the structure suggestions here. I’ve made those updates per your suggestion in the attached copy of the redline document.

I’ll note your endorsement.

Cheers,

Ian

From: Tim Hollebeek <tim.hollebeek at digicert.com<mailto:tim.hollebeek at digicert.com>>
Sent: Wednesday, March 2, 2022 4:57 PM
To: Ian McMillan <ianmcm at microsoft.com<mailto:ianmcm at microsoft.com>>; cscwg-public at cabforum.org<mailto:cscwg-public at cabforum.org>; Doug Beattie <doug.beattie at globalsign.com<mailto:doug.beattie at globalsign.com>>; Bruce Morton <bruce.morton at entrust.com<mailto:bruce.morton at entrust.com>>
Subject: [EXTERNAL] RE: Update to Subscriber Private Key Protection Requirements (CSC-6 to CSC-13)

I would recommend against using parentheticals to express the deprecation dates, as it makes the sentences more complicated than they need to be.  I’d just modify the first sentence of each part so the structure is as follows:

   For Non-EV Code Signing Certificates issued prior to November 15, 2022, …

   For EV Code Signing Certificates issued prior to November 15, 2022, …

   Effective November 15, 2022, …

But otherwise, the updates look good and we are willing to endorse CSC-13.

-Tim

From: Ian McMillan <ianmcm at microsoft.com<mailto:ianmcm at microsoft.com>>
Sent: Wednesday, March 2, 2022 11:31 AM
To: cscwg-public at cabforum.org<mailto:cscwg-public at cabforum.org>; Doug Beattie <doug.beattie at globalsign.com<mailto:doug.beattie at globalsign.com>>; Bruce Morton <bruce.morton at entrust.com<mailto:bruce.morton at entrust.com>>; Tim Hollebeek <tim.hollebeek at digicert.com<mailto:tim.hollebeek at digicert.com>>
Subject: Update to Subscriber Private Key Protection Requirements (CSC-6 to CSC-13)

Hi Folks,

Attached you will find an updated redline doc of v2.7 of the CSBRs with the updates to the subscriber private key protection requirements as outlined previously in CSC-6. This updated version also includes edits to address issues Doug Beattie raised during the voting period of CSC-6, so I am looking for confirmation from Doug on these edits addressing the concerns he raised.

Additionally, I’m looking to get endorsements on this ballot under CSC 13 - Update to Subscriber Private Key Protection Requirements<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fnam06.safelinks.protection.outlook.com%2F%3Furl%3Dhttps*3A*2F*2Fwiki.cabforum.org*2Fcscwg*2Fcsc_13_-_update_to_subscriber_private_key_protection_requirements%26data%3D04*7C01*7Cianmcm*40microsoft.com*7Ce6a5592ea98440d1462508da01f05f7d*7C72f988bf86f141af91ab2d7cd011db47*7C0*7C0*7C637824429178363769*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000%26sdata%3D9so2*2BiOyK9XXEQ8Y*2F*2FnOEd0ZymEoU*2Fub9lk8VS6ucbE*3D%26reserved%3D0__%3BJSUlJSUlJSUlJSUlJSUlJSUlJSUlJQ!!FJ-Y8qCqXTj2!JS-t5TK8xNLRrrr-l8arUfUupgt7PadMcuUOBT4reSeB5x7-jWypHWzhZNsG6GTE_x0%24&data=04%7C01%7Cianmcm%40microsoft.com%7C930e1d88bad74c7a3ec408da02dab235%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637825435611904880%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=uCj7cFUrdj%2FvFKrzwe0QUzczK%2FhPyYfwVyDwD2hRFF0%3D&reserved=0>, and hope that Bruce and Tim, as previous endorsers can review the edits and endorse the new ballot. Once we have endorsers I’ll proceed with the formal ballot process.

Cheers,

Ian

_______________________________________________

Cscwg-public mailing list

Cscwg-public at cabforum.org<mailto:Cscwg-public at cabforum.org>

https://lists.cabforum.org/mailman/listinfo/cscwg-public<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fnam06.safelinks.protection.outlook.com%2F%3Furl%3Dhttps*3A*2F*2Flists.cabforum.org*2Fmailman*2Flistinfo*2Fcscwg-public%26data%3D04*7C01*7Cianmcm*40microsoft.com*7Ce6a5592ea98440d1462508da01f05f7d*7C72f988bf86f141af91ab2d7cd011db47*7C0*7C0*7C637824429178363769*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000%26sdata%3DLnP7dwOGGX87Z6tZNa*2BnglvDc7Px*2BrqaClOqrPsfS48*3D%26reserved%3D0__%3BJSUlJSUlJSUlJSUlJSUlJSUlJSUl!!FJ-Y8qCqXTj2!JS-t5TK8xNLRrrr-l8arUfUupgt7PadMcuUOBT4reSeB5x7-jWypHWzhZNsGCdboIbM%24&data=04%7C01%7Cianmcm%40microsoft.com%7C930e1d88bad74c7a3ec408da02dab235%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637825435611954879%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=aPPWwtxmIuwxR9iSMbGSVKmtV%2FjraFwjEVoN4LyCqYc%3D&reserved=0>

_______________________________________________

Cscwg-public mailing list

Cscwg-public at cabforum.org<mailto:Cscwg-public at cabforum.org>

https://lists.cabforum.org/mailman/listinfo/cscwg-public<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fnam06.safelinks.protection.outlook.com%2F%3Furl%3Dhttps*3A*2F*2Flists.cabforum.org*2Fmailman*2Flistinfo*2Fcscwg-public%26data%3D04*7C01*7Cianmcm*40microsoft.com*7Ce6a5592ea98440d1462508da01f05f7d*7C72f988bf86f141af91ab2d7cd011db47*7C0*7C0*7C637824429178363769*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000%26sdata%3DLnP7dwOGGX87Z6tZNa*2BnglvDc7Px*2BrqaClOqrPsfS48*3D%26reserved%3D0__%3BJSUlJSUlJSUlJSUlJSUlJSUlJSUl!!FJ-Y8qCqXTj2!JS-t5TK8xNLRrrr-l8arUfUupgt7PadMcuUOBT4reSeB5x7-jWypHWzhZNsGCdboIbM%24&data=04%7C01%7Cianmcm%40microsoft.com%7C930e1d88bad74c7a3ec408da02dab235%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637825435611954879%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=aPPWwtxmIuwxR9iSMbGSVKmtV%2FjraFwjEVoN4LyCqYc%3D&reserved=0>

Any email and files/attachments transmitted with it are confidential and 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/20220322/aa36b49a/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Baseline Requirements for the Issuance and Management of Code Signing.v2.7+CSC-13_redline_v1.docx
Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document
Size: 159756 bytes
Desc: Baseline Requirements for the Issuance and Management of Code Signing.v2.7+CSC-13_redline_v1.docx
URL: <http://lists.cabforum.org/pipermail/cscwg-public/attachments/20220322/aa36b49a/attachment-0001.docx>