[Cscwg-public] [EXTERNAL] Re: Update to Subscriber Private Key Protection Requirements (CSC-6 to CSC-13)
Adriano Santoni
adriano.santoni at staff.aruba.it
Wed Mar 23 14:25:46 UTC 2022
Thanks, Ian.
Adriano
Il 22/03/2022 16:43, Ian McMillan ha scritto:
> 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/20220323/04db1a38/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/20220323/04db1a38/attachment-0001.p7s>
More information about the Cscwg-public
mailing list