[Cscwg-public] Update to Subscriber Private Key Protection Requirements (CSC-6 to CSC-13)
Dimitris Zacharopoulos (HARICA)
dzacharo at harica.gr
Wed Mar 9 17:00:27 UTC 2022
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>
> *Enviado el:* miércoles, 9 de marzo de 2022 14:08
> *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.
>
> 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://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%7Cd546bfa279f44594c2ce08da01cde35f%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637824281051972448%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=DWMHXOAyED1RmBGi1ruL0D7tq1oYE%2BpyGeKGwcKeZ18%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://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.cabforum.org%2Fmailman%2Flistinfo%2Fcscwg-public&data=04%7C01%7CInigo.Barreira%40sectigo.com%7Cd546bfa279f44594c2ce08da01cde35f%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637824281051972448%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=x8BFJ2B9IL%2FVc9B5TidmtN8KCeJ8bqVTz6FoaCwfPZI%3D&reserved=0>
>
>
>
>
> _______________________________________________
>
> Cscwg-public mailing list
>
> Cscwg-public at cabforum.org
>
> https://lists.cabforum.org/mailman/listinfo/cscwg-public <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.cabforum.org%2Fmailman%2Flistinfo%2Fcscwg-public&data=04%7C01%7CInigo.Barreira%40sectigo.com%7Cd546bfa279f44594c2ce08da01cde35f%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637824281051972448%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=x8BFJ2B9IL%2FVc9B5TidmtN8KCeJ8bqVTz6FoaCwfPZI%3D&reserved=0>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/cscwg-public/attachments/20220309/099722a7/attachment-0001.html>
More information about the Cscwg-public
mailing list