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

Adriano Santoni adriano.santoni at staff.aruba.it
Wed Mar 9 09:42:57 UTC 2022


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

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

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

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>
> *Enviado el:* martes, 8 de marzo de 2022 20:35
> *Para:* Dean Coclin <dean.coclin at digicert.com>; Inigo Barreira 
> <Inigo.Barreira at sectigo.com>; cscwg-public at cabforum.org; Bruce Morton 
> <bruce.morton at entrust.com>; Doug Beattie 
> <doug.beattie at globalsign.com>; Ian McMillan <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>
> *Sent:* Tuesday, March 8, 2022 1:00 PM
> *To:* Inigo Barreira <Inigo.Barreira at sectigo.com>; 
> cscwg-public at cabforum.org; Bruce Morton <bruce.morton at entrust.com>; 
> Doug Beattie <doug.beattie at globalsign.com>; Ian McMillan 
> <ianmcm at microsoft.com>; Tim Hollebeek <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> *On Behalf Of 
> *Inigo Barreira via Cscwg-public
> *Sent:* Tuesday, March 8, 2022 11:03 AM
> *To:* Bruce Morton <bruce.morton at entrust.com>; 
> cscwg-public at cabforum.org; Doug Beattie <doug.beattie at globalsign.com>; 
> Ian McMillan <ianmcm at microsoft.com>; Tim Hollebeek 
> <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>
> *Sent:* Thursday, March 3, 2022 6:56 AM
> *To:* Ian McMillan <ianmcm at microsoft.com>; Tim Hollebeek 
> <tim.hollebeek at digicert.com>; cscwg-public at cabforum.org; Bruce Morton 
> <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>
> *Sent:* Wednesday, March 2, 2022 5:56 PM
> *To:* Tim Hollebeek <tim.hollebeek at digicert.com>; 
> cscwg-public at cabforum.org; Doug Beattie <doug.beattie at globalsign.com>; 
> Bruce Morton <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>
> *Sent:* Wednesday, March 2, 2022 4:57 PM
> *To:* Ian McMillan <ianmcm at microsoft.com>; cscwg-public at cabforum.org; 
> Doug Beattie <doug.beattie at globalsign.com>; Bruce Morton 
> <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>
> *Sent:* Wednesday, March 2, 2022 11:31 AM
> *To:* cscwg-public at cabforum.org; Doug Beattie 
> <doug.beattie at globalsign.com>; Bruce Morton 
> <bruce.morton at entrust.com>; Tim Hollebeek <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://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwiki.cabforum.org%2Fcscwg%2Fcsc_13_-_update_to_subscriber_private_key_protection_requirements&data=04%7C01%7Cinigo.barreira%40sectigo.com%7C8c395e17677b473299fe08d9fd1f31e3%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637819132704229104%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=vVY6kf6AeMZd%2FrkLBqxgdyGhAQRLqyqUXVG2B5vGejM%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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/cscwg-public/attachments/20220309/e32c33ca/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/20220309/e32c33ca/attachment-0001.p7s>


More information about the Cscwg-public mailing list