[Cscwg-public] Update to Subscriber Private Key Protection Requirements (CSC-6 to CSC-13)
Adriano Santoni
adriano.santoni at staff.aruba.it
Mon Mar 21 10:58:13 UTC 2022
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>
> *Sent:* Thursday, March 10, 2022 4:12 PM
> *To:* Ian McMillan <ianmcm at microsoft.com>; cscwg-public at cabforum.org;
> Inigo Barreira <Inigo.Barreira at sectigo.com>; Dimitris Zacharopoulos
> (HARICA) <dzacharo at harica.gr>; Adriano Santoni
> <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> *On Behalf Of
> *Ian McMillan via Cscwg-public
> *Sent:* Thursday, March 10, 2022 12:43 PM
> *To:* Inigo Barreira <Inigo.Barreira at sectigo.com>;
> cscwg-public at cabforum.org; Dimitris Zacharopoulos (HARICA)
> <dzacharo at harica.gr>; Adriano Santoni <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> *On Behalf Of
> *Inigo Barreira via Cscwg-public
> *Sent:* Wednesday, March 9, 2022 12:15 PM
> *To:* Dimitris Zacharopoulos (HARICA) <dzacharo at harica.gr>;
> cscwg-public at cabforum.org; Adriano Santoni
> <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>
> *Enviado el:* miércoles, 9 de marzo de 2022 18:00
> *Para:* Inigo Barreira <Inigo.Barreira at sectigo.com>;
> cscwg-public at cabforum.org; Adriano Santoni
> <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;
> 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
> *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; 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>
> *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>;
> Ian McMillan <ianmcm at microsoft.com>; Tim Hollebeek
> <tim.hollebeek at digicert.com>; 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
>
> 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
>
> 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/20220321/87066b0b/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4557 bytes
Desc: Firma crittografica S/MIME
URL: <http://lists.cabforum.org/pipermail/cscwg-public/attachments/20220321/87066b0b/attachment-0001.p7s>
More information about the Cscwg-public
mailing list