<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<br>
Hello Ian,<br>
<br>
I think it's great to be working on this language and hopefully
resolve the ambiguities of the existing language. Please see inline.<br>
<br>
<br>
<div class="moz-cite-prefix">On 5/2/2021 1:48 π.μ., Ian McMillan via
Cscwg-public wrote:<br>
</div>
<blockquote type="cite"
cite="mid:010001776f7293c5-fb350787-1eb6-4124-928b-86d62f59b79f-000000@email.amazonses.com">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<meta name="Generator" content="Microsoft Word 15 (filtered
medium)">
<style>@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}@font-face
{font-family:"Segoe UI";
panose-1:2 11 5 2 4 2 4 2 2 3;}@font-face
{font-family:Cambria;
panose-1:2 4 5 3 5 4 6 3 2 4;}p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
{mso-style-priority:99;
mso-style-link:"Plain Text Char";
margin:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}span.PlainTextChar
{mso-style-name:"Plain Text Char";
mso-style-priority:99;
mso-style-link:"Plain Text";
font-family:"Calibri",sans-serif;}.MsoChpDefault
{mso-style-type:export-only;}div.WordSection1
{page:WordSection1;}ol
{margin-bottom:0in;}ul
{margin-bottom:0in;}</style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
<div class="WordSection1">
<p class="MsoPlainText">Hi Folks,<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">I've revised the wording on key
protection as it relates to the hardware crypto module
conformance to standards as we discussed in the last call. I
used the wording,
<i>"crypto module that meets or exceeds the requirements of
FIPS 140-2 level 2, Common Criteria EAL 4+, or CEN PP EN 419
221-5."</i> This covers the 3 standards we discussed and
commonly see in what is available in the market for HSMs,
tokens, and cloud key protection solutions. Love to get
feedback on whether this satisfies everyone's feedback.<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">As far as the techniques to satisfying
the requirements for key protection as a signing service
(16.2[3]), the feedback was the audit verbiage was confusing,
so I've updated to state:
<o:p></o:p></p>
<p class="MsoPlainText"><i><o:p> </o:p></i></p>
<p class="MsoPlainText" style="margin-left:.5in"><i>"Contractual
terms in the subscriber agreement requiring the Subscriber
to protect the private key to a standard equivalent to FIPS
140-2 level 2, Common Criteria EAL 4+, or CEN PP EN 419
221-5, and with compliance being confirmed by means of an
audit on the attestation records received by the CA from the
Subscriber to accepting the terms of the subscriber
agreement."<o:p></o:p></i></p>
<p class="MsoPlainText"><o:p> </o:p></p>
</div>
</blockquote>
<br>
During the last call, I kept asking myself what are we trying to
achieve by adding an "audit" clause. As I mentioned, the only
meaningful value that an external audit can effectively add (I
wouldn't even call it an "audit", it's more of a "witnessing"
process), is a reasonable assurance that the Key Pair to be
associated with a Code Signing Certificate IS ACTUALLY generated in
a special crypto device. This is applicable to crypto-devices that
do not support remote key attestation.<br>
<br>
Compliance to the FIPS 140-2 level2 and Common Criteria EAL 4+ is a
process that only FIPS and a CC certified lab can perform, not a
Qualified Auditor as defined in the Guidelines. So, in practice, if
we have an Applicant that claims to have a certified device that
meets the requirements of 16.3, all the Applicant has to do is state
the brand, model of this device so that the CA can check the
certifications, which must be publicly available.<br>
<br>
With that said, the WG must decide if it wants to re-draft this
section to increase the assurance that keys are in fact generated
and protected in crypto-devices, and not just rely on an Applicant
"stating" that they will generate the key in a crypto-device, when
in fact they can be generated in a software device because it is
more "flexible" for the Subscriber to install in various software
components that need code signing capabilities.<br>
<br>
If Certificate Consumers are satisfied with a "policy" solution,
described in the subscriber agreement instead of a technically
enforceable practice, I don't think CAs will object to that. Once we
establish this position, we can go back to sections 16.2 and 16.3
and draft the appropriate language to reflect this decision. Thomas
already sent some good comments about the certification of these
devices and I also have some ideas regarding remote key attestation.<br>
<br>
<br>
Thank you,<br>
Dimitris.<br>
<br>
<br>
<blockquote type="cite"
cite="mid:010001776f7293c5-fb350787-1eb6-4124-928b-86d62f59b79f-000000@email.amazonses.com">
<div class="WordSection1">
<p class="MsoPlainText">I am definitely not a lawyer by any
means, so I am happy to get feedback on wordsmithing the
intent of what we are after here.
<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">Lastly, here is a snapshot of the
drafted key protection changes I have now, and hope to discuss
in our call next week.
<o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:0in;margin-right:0in;margin-bottom:11.0pt;margin-left:1.5in;text-indent:-1.0in;page-break-after:avoid"><a
name="_Toc400025925" moz-do-not-send="true"></a><a
name="_Toc39753679" moz-do-not-send="true"></a><a
name="_Toc17488556" moz-do-not-send="true"><span
style="mso-bookmark:_Toc39753679"><span
style="mso-bookmark:_Toc400025925"><b><span
style="font-size:12.0pt;font-family:"Cambria",serif"><o:p> </o:p></span></b></span></span></a></p>
<p class="MsoNormal"
style="mso-margin-top-alt:0in;margin-right:0in;margin-bottom:11.0pt;margin-left:1.5in;text-indent:-1.0in;page-break-after:avoid"><span
style="mso-bookmark:_Toc17488556"><span
style="mso-bookmark:_Toc39753679"><span
style="mso-bookmark:_Toc400025925"><b><span
style="font-size:12.0pt;font-family:"Cambria",serif">Signing
Service Requirements</span></b></span></span></span><b><span
style="font-size:12.0pt;font-family:"Cambria",serif"><o:p></o:p></span></b></p>
<p class="MsoNormal"
style="mso-margin-top-alt:0in;margin-right:0in;margin-bottom:11.0pt;margin-left:.5in"><span
style="font-family:"Cambria",serif">The Signing
Service MUST ensure that a Subscriber’s private key is
generated, stored, and used in a secure environment that has
controls to prevent theft or misuse. A Signing Service MUST
enforce multi-factor authentication to authorize Code
Signing and obtain a representation from the Subscriber that
they will securely store the tokens required for
multi-factor access.
</span><span style="font-family:"Cambria",serif"
lang="EN">A system used to host a Signing Service MUST NOT
be used for web browsing. The Signing Service MUST run a
regularly updated antivirus solution to scan the service for
possible virus infection. The Signing Service MUST comply
with the Network Security Guidelines as a “Delegated Third
Party”.</span><span
style="font-family:"Cambria",serif" lang="EN"><o:p></o:p></span></p>
<p class="MsoNormal"
style="mso-margin-top-alt:0in;margin-right:0in;margin-bottom:11.0pt;margin-left:.5in"><span
style="font-family:"Cambria",serif" lang="EN">For
Code Signing Certificates,
</span><span style="font-family:"Cambria",serif">Signing
Services shall protect private keys in a FIPS 140-2 level 2,
Common Criteria EAL 4+, or CEN PP EN 419 221-5 compliant
hardware crypto module. Techniques that may be used to
satisfy this requirement include:<o:p></o:p></span></p>
<p class="MsoNormal"
style="mso-margin-top-alt:0in;margin-right:0in;margin-bottom:11.0pt;margin-left:1.25in;text-indent:-.25in;mso-list:l4
level1 lfo2">
<!--[if !supportLists]--><span
style="font-family:"Cambria",serif"><span
style="mso-list:Ignore">1.<span style="font:7.0pt
"Times New Roman"">
</span></span></span><!--[endif]--><span
style="font-family:"Cambria",serif"> Use of
an HSM, verified by means of a manufacturer’s certificate;<o:p></o:p></span></p>
<p class="MsoNormal"
style="mso-margin-top-alt:0in;margin-right:0in;margin-bottom:11.0pt;margin-left:1.25in;text-indent:-.25in;mso-list:l4
level1 lfo2">
<!--[if !supportLists]--><span
style="font-family:"Cambria",serif"><span
style="mso-list:Ignore">2.<span style="font:7.0pt
"Times New Roman"">
</span></span></span><!--[endif]--><span
style="font-family:"Cambria",serif"> A
hardware crypto module provided by the CA;<o:p></o:p></span></p>
<p class="MsoNormal"
style="mso-margin-top-alt:0in;margin-right:0in;margin-bottom:11.0pt;margin-left:1.25in;text-indent:-.25in;mso-list:l4
level1 lfo2">
<!--[if !supportLists]--><span
style="font-family:"Cambria",serif"><span
style="mso-list:Ignore">3.<span style="font:7.0pt
"Times New Roman"">
</span></span></span><!--[endif]--><span
style="font-family:"Cambria",serif">
Contractual terms in the subscriber agreement requiring the
Subscriber to protect the private key to a standard
equivalent to FIPS 140-2 level 2, Common Criteria EAL 4+, or
CEN PP EN 419 221-5, and with compliance being confirmed by
means of an audit on the attestation records received by the
CA from the Subscriber to accepting the terms of the
subscriber agreement.<o:p></o:p></span></p>
<p class="MsoNormal"
style="mso-margin-top-alt:0in;margin-right:0in;margin-bottom:11.0pt;margin-left:1.25in;text-indent:-.25in;mso-list:l4
level1 lfo2">
<!--[if !supportLists]--><span
style="font-family:"Cambria",serif"><span
style="mso-list:Ignore">4.<span style="font:7.0pt
"Times New Roman"">
</span></span></span><!--[endif]--><span
style="font-family:"Cambria",serif">
Cryptographic algorithms, key sizes and certificate
life-times for both authorities and Subscribers are governed
by the NIST key management guidelines.<o:p></o:p></span></p>
<p class="MsoNormal"
style="mso-margin-top-alt:0in;margin-right:0in;margin-bottom:11.0pt;margin-left:1.25in;text-indent:-.25in;mso-list:l4
level1 lfo2">
<!--[if !supportLists]--><span
style="font-family:"Cambria",serif"><span
style="mso-list:Ignore">5.<span style="font:7.0pt
"Times New Roman"">
</span></span></span><!--[endif]--><span
style="font-family:"Cambria",serif">A Cloud-based
key generation and protection solution with the following
requirements enabled on the subscription, and a usage
pattern as follows:<o:p></o:p></span></p>
<p class="MsoNormal"
style="mso-margin-top-alt:0in;margin-right:0in;margin-bottom:11.0pt;margin-left:1.75in;text-indent:-.25in;line-height:106%;mso-list:l2
level2 lfo3;vertical-align:middle">
<!--[if !supportLists]--><span
style="font-family:"Cambria",serif"><span
style="mso-list:Ignore">1.<span style="font:7.0pt
"Times New Roman"">
</span></span></span><!--[endif]--><span
style="font-family:"Cambria",serif">Key creation,
storage, and usage of private key MUST remain within the
security boundaries of a hardware crypto module that
conforms to at least FIPS 140-2 Level 2<a
name="_Hlk62827746" moz-do-not-send="true">, Common
Criteria EAL 4+, or CEN PP EN 419 221-5</a>;<o:p></o:p></span></p>
<p class="MsoNormal"
style="mso-margin-top-alt:0in;margin-right:0in;margin-bottom:11.0pt;margin-left:1.75in;text-indent:-.25in;line-height:106%;mso-list:l2
level2 lfo3;vertical-align:middle">
<!--[if !supportLists]--><span style="mso-list:Ignore">2.<span
style="font:7.0pt "Times New Roman"">
</span></span><!--[endif]--><span
style="font-family:"Cambria",serif">Subscription
MUST be configured to log key creation, importation,
deletion, archiving and all access events not associated
with the act of code signing by the Signing Service. These
logs must be retained for the life of the certificate bound
to the private key;</span><o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:0in;margin-right:0in;margin-bottom:11.0pt;margin-left:1.75in;text-indent:-.25in;line-height:106%;mso-list:l2
level2 lfo3;vertical-align:middle">
<!--[if !supportLists]--><span style="mso-list:Ignore">3.<span
style="font:7.0pt "Times New Roman"">
</span></span><!--[endif]--><span
style="font-family:"Cambria",serif">The identities
authorized to the Cloud key protection service subscription
protecting the private key must be included in logical
access reviews as required by any audits.</span> <o:p></o:p></p>
<p class="MsoNormal"
style="margin-left:1.75in;line-height:106%;vertical-align:middle">
<o:p> </o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:0in;margin-right:0in;margin-bottom:11.0pt;margin-left:1.5in;text-indent:-1.0in;page-break-after:avoid"><a
name="_Toc400025926" moz-do-not-send="true"></a><a
name="_Toc39753680" moz-do-not-send="true"></a><a
name="_Toc17488557" moz-do-not-send="true"><span
style="mso-bookmark:_Toc39753680"><span
style="mso-bookmark:_Toc400025926"><b><span
style="font-size:12.0pt;font-family:"Cambria",serif">Subscriber
Private Key Protection</span></b></span></span></a><b><span
style="font-size:12.0pt;font-family:"Cambria",serif"><o:p></o:p></span></b></p>
<p class="MsoNormal" style="margin-left:.5in"><span
style="font-family:"Cambria",serif">For Code
Signing Certificates, the CA MUST obtain a representation
from the Subscriber that the Subscriber will use one of the
following options to generate and protect their Code Signing
Certificate private keys:<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:1.25in"><span
style="font-family:"Cambria",serif"> <o:p></o:p></span></p>
<p class="MsoNormal"
style="mso-margin-top-alt:0in;margin-right:0in;margin-bottom:11.0pt;margin-left:1.25in;text-indent:-.25in;mso-list:l5
level1 lfo4;vertical-align:middle">
<!--[if !supportLists]--><span
style="font-family:"Cambria",serif"><span
style="mso-list:Ignore">1.<span style="font:7.0pt
"Times New Roman"">
</span></span></span><!--[endif]--><span
style="font-family:"Cambria",serif">A hardware
crypto module with a unit design form factor certified as
conforming to at least FIPS 140-2 Level 2, Common Criteria
EAL 4+, or CEN PP EN 419 221-5;<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-left:1.5in;vertical-align:middle"><span
style="font-family:"Cambria",serif"><o:p> </o:p></span></p>
<p class="MsoNormal"
style="mso-margin-top-alt:0in;margin-right:0in;margin-bottom:11.0pt;margin-left:1.25in;text-indent:-.25in;mso-list:l5
level1 lfo4;vertical-align:middle">
<!--[if !supportLists]--><span
style="font-family:"Cambria",serif"><span
style="mso-list:Ignore">2.<span style="font:7.0pt
"Times New Roman"">
</span></span></span><!--[endif]--><span
style="font-family:"Cambria",serif">A Cloud-based
key generation and protection solution with the following
requirements enabled on the subscription, and a usage
pattern as follows:<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-left:1.25in;vertical-align:middle"><span
style="font-family:"Cambria",serif"><o:p> </o:p></span></p>
<p class="MsoNormal"
style="mso-margin-top-alt:0in;margin-right:0in;margin-bottom:11.0pt;margin-left:1.5in;text-indent:-.25in;mso-list:l1
level2 lfo5;vertical-align:middle">
<!--[if !supportLists]--><span
style="font-family:"Cambria",serif"><span
style="mso-list:Ignore">1.<span style="font:7.0pt
"Times New Roman"">
</span></span></span><!--[endif]--><span
style="font-family:"Cambria",serif">Key creation,
storage, and usage of private key must remain within the
security boundaries of the cloud solutions hardware crypto
module
</span><span style="font-family:"Cambria",serif">that
conforms to at least FIPS 140-2 Level 2, Common Criteria EAL
4+, or CEN PP EN 419 221-5;<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-left:1.5in;vertical-align:middle"><span
style="font-family:"Cambria",serif"><o:p> </o:p></span></p>
<p class="MsoNormal"
style="mso-margin-top-alt:0in;margin-right:0in;margin-bottom:11.0pt;margin-left:1.5in;text-indent:-.25in;mso-list:l1
level2 lfo5;vertical-align:middle">
<!--[if !supportLists]--><span style="mso-list:Ignore">2.<span
style="font:7.0pt "Times New Roman"">
</span></span><!--[endif]--><span
style="font-family:"Cambria",serif">Subscription
must be configured to log all access, operations, and
configuration changes on the private key itself.</span><o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:0in;margin-right:0in;margin-bottom:11.0pt;margin-left:.5in"><span
style="font-family:"Cambria",serif"><o:p> </o:p></span></p>
<p class="MsoNormal" style="margin-left:.5in"><span
style="font-family:"Cambria",serif">For Code
Signing Certificates, CAs SHALL ensure that the Subscriber’s
private key is generated, stored, and used in a crypto
module that meets or exceeds the requirements of FIPS 140-2
level 2, Common Criteria EAL 4+, or CEN PP EN 419 221-5.
Acceptable methods of satisfying this requirement include
(but are not limited to) the following:
<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:63.0pt"><span
style="font-family:"Cambria",serif"><o:p> </o:p></span></p>
<p class="MsoNormal"
style="margin-left:99.0pt;mso-add-space:auto;text-indent:-.25in;mso-list:l0
level1 lfo6">
<!--[if !supportLists]--><span
style="font-family:"Cambria",serif;mso-fareast-language:AR-SA"><span
style="mso-list:Ignore">1.<span style="font:7.0pt
"Times New Roman"">
</span></span></span><!--[endif]--><span
style="font-family:"Cambria",serif;mso-fareast-language:AR-SA">The
CA ships a suitable hardware crypto module, with
</span><span
style="font-family:"Cambria",serif;mso-fareast-language:AR-SA">a
preinstalled key pair;
</span><span
style="font-family:"Cambria",serif;mso-fareast-language:AR-SA"><o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-left:99.0pt;mso-add-space:auto"><span
style="font-family:"Cambria",serif;mso-fareast-language:AR-SA"><o:p> </o:p></span></p>
<p class="MsoNormal"
style="margin-left:99.0pt;mso-add-space:auto;text-indent:-.25in;mso-list:l0
level1 lfo6">
<!--[if !supportLists]--><span
style="font-family:"Cambria",serif;mso-fareast-language:AR-SA"><span
style="mso-list:Ignore">2.<span style="font:7.0pt
"Times New Roman"">
</span></span></span><!--[endif]--><span
style="font-family:"Cambria",serif;mso-fareast-language:AR-SA">The
Subscriber counter-signs certificate requests that can be
verified by using a manufacturer’s certificate indicating
that the key is managed in a suitable hardware module;<o:p></o:p></span></p>
<p class="MsoNormal"
style="mso-margin-top-alt:6.8pt;margin-right:0in;margin-bottom:0in;margin-left:99.0pt;margin-bottom:.0001pt"><span
style="font-family:"Cambria",serif;mso-fareast-language:AR-SA"><o:p> </o:p></span></p>
<p class="MsoNormal"
style="margin-left:99.0pt;mso-add-space:auto;text-indent:-.25in;mso-list:l0
level1 lfo6">
<!--[if !supportLists]--><span
style="font-family:"Cambria",serif;mso-fareast-language:AR-SA"><span
style="mso-list:Ignore">3.<span style="font:7.0pt
"Times New Roman"">
</span></span></span><!--[endif]--><span
style="font-family:"Cambria",serif;mso-fareast-language:AR-SA">The
Subscriber provides a suitable IT audit indicating that its
operating environment achieves a level of security at least
equivalent to that of FIPS 140-2 level 2, Common Criteria
EAL 4+, or CEN PP EN 419 221-5;<o:p></o:p></span></p>
<p class="MsoNormal"
style="mso-margin-top-alt:6.8pt;margin-right:0in;margin-bottom:0in;margin-left:99.0pt;margin-bottom:.0001pt"><span
style="font-family:"Cambria",serif;mso-fareast-language:AR-SA"><o:p> </o:p></span></p>
<p class="MsoNormal"
style="margin-left:99.0pt;mso-add-space:auto;text-indent:-.25in;mso-list:l0
level1 lfo6">
<!--[if !supportLists]--><span
style="font-family:"Cambria",serif;mso-fareast-language:AR-SA"><span
style="mso-list:Ignore">4.<span style="font:7.0pt
"Times New Roman"">
</span></span></span><!--[endif]--><span
style="font-family:"Cambria",serif;mso-fareast-language:AR-SA">The
Subscriber provides a suitable report of the cloud key
protection solution subscription configuration protecting
the key in hardware crypto module with a unit design form
factor certified as conforming to at least FIPS 140-2 Level
2, Common Criteria EAL 4+, or CEN PP EN 419 221-5.<o:p></o:p></span></p>
<p class="MsoPlainText">Cheers,<o:p></o:p></p>
<p class="MsoPlainText">Ian<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">-----Original Message-----<br>
From: Cscwg-public <a class="moz-txt-link-rfc2396E" href="mailto:cscwg-public-bounces@cabforum.org"><cscwg-public-bounces@cabforum.org></a>
On Behalf Of Tomas Gustavsson via Cscwg-public<br>
Sent: Friday, November 13, 2020 12:09 AM<br>
To: <a class="moz-txt-link-abbreviated" href="mailto:cscwg-public@cabforum.org">cscwg-public@cabforum.org</a><br>
Subject: [EXTERNAL] Re: [Cscwg-public] Update to key
protection (in 16.2 & 16.3)</p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">Hi,<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">I have reached out to a security
architect at a vendor of security hardware chips to get a
better understanding on the certification side of things.<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">The story gets foggier...at least for
me.<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">I have more questions than answers
unfortunately. But it boils down to if the forum want to high
a high level of assurance of private key protection, or
muddier, opening options for weaker private key protection?<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">The security architect I spoke with
don't think we should use "or equivalent" as that is very non
specific. How to judge this? In his opinion it open up doors
to weak private key protection.<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">I got a little better insight into chip
silicon certifications.<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">FIPS 140-2 or EN 419 221-5 are highly
related to HSMs.<o:p></o:p></p>
<p class="MsoPlainText">BTW: from now on HSMs are evaluated
against FIPS 140-3 I believe (since september 2020).<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">Silicon produced for USB tokens and
smart cards are evaluated against:<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">TPM silicon is certified against:<o:p></o:p></p>
<p class="MsoPlainText"><a
href="https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftrustedcomputinggroup.org%2Fresource%2Fpc-client-tpm-certification%2F&data=04%7C01%7Cianmcm%40microsoft.com%7C268dd401618346621b3908d887ab7b0c%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C1%7C637408518632803125%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=zyl9OICcX1pLMryY%2BpKcBEG8kesw%2BJMUeWbUgmVP1ao%3D&reserved=0"
moz-do-not-send="true"><span
style="color:windowtext;text-decoration:none">https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftrustedcomputinggroup.org%2Fresource%2Fpc-client-tpm-certification%2F&data=04%7C01%7Cianmcm%40microsoft.com%7C268dd401618346621b3908d887ab7b0c%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C1%7C637408518632803125%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=zyl9OICcX1pLMryY%2BpKcBEG8kesw%2BJMUeWbUgmVP1ao%3D&reserved=0</span></a><o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">Then system vendors can lay FIPS
certification on top of the silicon certification, adding
their firmware.<o:p></o:p></p>
<p class="MsoPlainText"><a
href="https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftrustedcomputinggroup.org%2Fresource%2Ftcg-fips-140-2-guidance-for-tpm-2-0%2F&data=04%7C01%7Cianmcm%40microsoft.com%7C268dd401618346621b3908d887ab7b0c%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C1%7C637408518632803125%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=CGWExgwKk5iooCrR9%2BUj3q1nRD1PReljYMJ5AThhmd4%3D&reserved=0"
moz-do-not-send="true"><span
style="color:windowtext;text-decoration:none">https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftrustedcomputinggroup.org%2Fresource%2Ftcg-fips-140-2-guidance-for-tpm-2-0%2F&data=04%7C01%7Cianmcm%40microsoft.com%7C268dd401618346621b3908d887ab7b0c%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C1%7C637408518632803125%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=CGWExgwKk5iooCrR9%2BUj3q1nRD1PReljYMJ5AThhmd4%3D&reserved=0</span></a><o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">A relevant requirement for TPMs module
certification would be:<o:p></o:p></p>
<p class="MsoPlainText">"Protection Profile PC Client Specific
TPM version 2.0"<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">For smart cards or USB token chips it
could be:<o:p></o:p></p>
<p class="MsoPlainText">"Security IC Platform Protection Profile
version 1.0"<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">To complicate things some old tokens
like SafeNet was certified against:<o:p></o:p></p>
<p class="MsoPlainText">"Protection Profile —Secure
Signature-Creation Device v1.05"<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">Questions:<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">1. How strongly does the forum want to
assure private key protection for code signing keys?<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">2. Question I guess if for WebTrust, is
it reasonable to judge "or equivalent", or does it open up too
many doors to weak key protection?<o:p></o:p></p>
<p class="MsoPlainText">For example is the CC evaluation of
SafeNet eToken 5110 (a popular USB<o:p></o:p></p>
<p class="MsoPlainText">token) equivalent?<o:p></o:p></p>
<p class="MsoPlainText"><a
href="https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcpl.thalesgroup.com%2Faccess-management%2Fauthenticators%2Fpki-usb-authentication%2Fetoken-5110-usb-token&data=04%7C01%7Cianmcm%40microsoft.com%7C268dd401618346621b3908d887ab7b0c%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C1%7C637408518632803125%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=4ovN%2BVo2DUfiSH4KNHPXh%2BUkhxbbqd7os6sGYTYev%2BA%3D&reserved=0"
moz-do-not-send="true"><span
style="color:windowtext;text-decoration:none">https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcpl.thalesgroup.com%2Faccess-management%2Fauthenticators%2Fpki-usb-authentication%2Fetoken-5110-usb-token&data=04%7C01%7Cianmcm%40microsoft.com%7C268dd401618346621b3908d887ab7b0c%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C1%7C637408518632803125%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=4ovN%2BVo2DUfiSH4KNHPXh%2BUkhxbbqd7os6sGYTYev%2BA%3D&reserved=0</span></a><o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">3. Should we FIPS 140-3 directly?
Evaluations on -3 has begun.<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">4. If the Forum want to specify USB
tokens and TPMs more carefully, should those certification
standards be called out?<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">Regards,<o:p></o:p></p>
<p class="MsoPlainText">Tomas<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">On 2020-11-02 20:43, Ian McMillan via
Cscwg-public wrote:<o:p></o:p></p>
<p class="MsoPlainText">> Thanks Bruce!<o:p></o:p></p>
<p class="MsoPlainText">> <o:p></o:p></p>
<p class="MsoPlainText">> <o:p></o:p></p>
<p class="MsoPlainText">> <o:p></o:p></p>
<p class="MsoPlainText">> For #1, I am interested in better
understanding what advantages level
<o:p></o:p></p>
<p class="MsoPlainText">> 3 operations provides here. I do
feel level 2 will continue to be the
<o:p></o:p></p>
<p class="MsoPlainText">> best course of requirement as a
Signing Service should have the
<o:p></o:p></p>
<p class="MsoPlainText">> ability to execute on resiliency
scenarios that would be negated by
<o:p></o:p></p>
<p class="MsoPlainText">> level 3 operations (e.g. HSM vendor
and SW diversity/resilience). I
<o:p></o:p></p>
<p class="MsoPlainText">> also do not want to exclude Signing
Services from leveraging
<o:p></o:p></p>
<p class="MsoPlainText">> cloud-based key protection services
which offer level 2 as a
<o:p></o:p></p>
<p class="MsoPlainText">> base/premium SKU in all cases (not
all have a level 3 option).<o:p></o:p></p>
<p class="MsoPlainText">> <o:p></o:p></p>
<p class="MsoPlainText">> <o:p></o:p></p>
<p class="MsoPlainText">> <o:p></o:p></p>
<p class="MsoPlainText">> On #2, I feel the timing is at
least one year out from the June 1,
<o:p></o:p></p>
<p class="MsoPlainText">> 2021 date that we attached to key
lengths and hash algorithms. The 1
<o:p></o:p></p>
<p class="MsoPlainText">> year from that date should provide
most the opportunity to obtain a
<o:p></o:p></p>
<p class="MsoPlainText">> code signing certificate within the
new standards for key protection.
<o:p></o:p></p>
<p class="MsoPlainText">> It may be best to state in the
timing that any new certificates issued
<o:p></o:p></p>
<p class="MsoPlainText">> post implementation date (say June
1, 2021) must meet the these key
<o:p></o:p></p>
<p class="MsoPlainText">> protection standards, but private
keys for existing valid certificates
<o:p></o:p></p>
<p class="MsoPlainText">> have until June 1, 2022 to meet
these requirements. Is this viable in
<o:p></o:p></p>
<p class="MsoPlainText">> folks mind?<o:p></o:p></p>
<p class="MsoPlainText">> <o:p></o:p></p>
<p class="MsoPlainText">> <o:p></o:p></p>
<p class="MsoPlainText">> <o:p></o:p></p>
<p class="MsoPlainText">> Thanks,<o:p></o:p></p>
<p class="MsoPlainText">> <o:p></o:p></p>
<p class="MsoPlainText">> Ian<o:p></o:p></p>
<p class="MsoPlainText">> <o:p></o:p></p>
<p class="MsoPlainText">> <o:p></o:p></p>
<p class="MsoPlainText">> <o:p></o:p></p>
<p class="MsoPlainText">> <o:p></o:p></p>
<p class="MsoPlainText">> <o:p></o:p></p>
<p class="MsoPlainText">> *From:* Bruce Morton <<a
href="mailto:Bruce.Morton@entrust.com"
moz-do-not-send="true"><span
style="color:windowtext;text-decoration:none">Bruce.Morton@entrust.com</span></a>><o:p></o:p></p>
<p class="MsoPlainText">> *Sent:* Sunday, November 1, 2020
11:38 AM<o:p></o:p></p>
<p class="MsoPlainText">> *To:* Ian McMillan <<a
href="mailto:ianmcm@microsoft.com" moz-do-not-send="true"><span
style="color:windowtext;text-decoration:none">ianmcm@microsoft.com</span></a>>;
<a href="mailto:cscwg-public@cabforum.org"
moz-do-not-send="true"><span
style="color:windowtext;text-decoration:none">cscwg-public@cabforum.org</span></a><o:p></o:p></p>
<p class="MsoPlainText">> *Subject:* [EXTERNAL] RE: Update to
key protection (in 16.2 & 16.3)<o:p></o:p></p>
<p class="MsoPlainText">> <o:p></o:p></p>
<p class="MsoPlainText">> <o:p></o:p></p>
<p class="MsoPlainText">> <o:p></o:p></p>
<p class="MsoPlainText">> Hi Ian,<o:p></o:p></p>
<p class="MsoPlainText">> <o:p></o:p></p>
<p class="MsoPlainText">> <o:p></o:p></p>
<p class="MsoPlainText">> <o:p></o:p></p>
<p class="MsoPlainText">> I will have our team review.<o:p></o:p></p>
<p class="MsoPlainText">> <o:p></o:p></p>
<p class="MsoPlainText">> <o:p></o:p></p>
<p class="MsoPlainText">> <o:p></o:p></p>
<p class="MsoPlainText">> I have a couple of items:<o:p></o:p></p>
<p class="MsoPlainText">> <o:p></o:p></p>
<p class="MsoPlainText">> 1. Signing Service requires FIPS
140-2 level 2. Should this be updated<o:p></o:p></p>
<p class="MsoPlainText">> to FIPS 140-2 level 3, as this
device will not be operated by the<o:p></o:p></p>
<p class="MsoPlainText">> Subscriber and may have many
multiple Subscriber private keys? Level<o:p></o:p></p>
<p class="MsoPlainText">> 3 might be better for a third
party to protect a multi-tenant HSM.<o:p></o:p></p>
<p class="MsoPlainText">> 2. If this ballot passes, when
would it need to be implemented. I think<o:p></o:p></p>
<p class="MsoPlainText">> that there may be many impacted
to CAs and Subscribers. It would be<o:p></o:p></p>
<p class="MsoPlainText">> good to have many months to a
year to implement.<o:p></o:p></p>
<p class="MsoPlainText">> <o:p></o:p></p>
<p class="MsoPlainText">> <o:p></o:p></p>
<p class="MsoPlainText">> <o:p></o:p></p>
<p class="MsoPlainText">> <o:p></o:p></p>
<p class="MsoPlainText">> <o:p></o:p></p>
<p class="MsoPlainText">> Thanks, Bruce.<o:p></o:p></p>
<p class="MsoPlainText">> <o:p></o:p></p>
<p class="MsoPlainText">> <o:p></o:p></p>
<p class="MsoPlainText">> <o:p></o:p></p>
<p class="MsoPlainText">> *From:* Cscwg-public
<<a class="moz-txt-link-abbreviated" href="mailto:cscwg-public-bounces@cabforum.org">cscwg-public-bounces@cabforum.org</a><o:p></o:p></p>
<p class="MsoPlainText">> <<a
href="mailto:cscwg-public-bounces@cabforum.org"
moz-do-not-send="true"><span
style="color:windowtext;text-decoration:none">mailto:cscwg-public-bounces@cabforum.org</span></a>>>
*On Behalf Of *Ian
<o:p></o:p></p>
<p class="MsoPlainText">> McMillan via Cscwg-public<o:p></o:p></p>
<p class="MsoPlainText">> *Sent:* Friday, October 30, 2020
6:11 PM<o:p></o:p></p>
<p class="MsoPlainText">> *To:* <a
href="mailto:cscwg-public@cabforum.org"
moz-do-not-send="true"><span
style="color:windowtext;text-decoration:none">cscwg-public@cabforum.org</span></a>
<<a href="mailto:cscwg-public@cabforum.org"
moz-do-not-send="true"><span
style="color:windowtext;text-decoration:none">mailto:cscwg-public@cabforum.org</span></a>><o:p></o:p></p>
<p class="MsoPlainText">> *Subject:* [EXTERNAL][Cscwg-public]
Update to key protection (in 16.2
<o:p></o:p></p>
<p class="MsoPlainText">> &<o:p></o:p></p>
<p class="MsoPlainText">> 16.3)<o:p></o:p></p>
<p class="MsoPlainText">> <o:p></o:p></p>
<p class="MsoPlainText">> <o:p></o:p></p>
<p class="MsoPlainText">> <o:p></o:p></p>
<p class="MsoPlainText">> *WARNING:* This email originated
outside of Entrust.<o:p></o:p></p>
<p class="MsoPlainText">> *DO NOT CLICK* links or attachments
unless you trust the sender and
<o:p></o:p></p>
<p class="MsoPlainText">> know the content is safe.<o:p></o:p></p>
<p class="MsoPlainText">> <o:p></o:p></p>
<p class="MsoPlainText">>
----------------------------------------------------------------------<o:p></o:p></p>
<p class="MsoPlainText">> --<o:p></o:p></p>
<p class="MsoPlainText">> <o:p></o:p></p>
<p class="MsoPlainText">> Hi Folks!<o:p></o:p></p>
<p class="MsoPlainText">> <o:p></o:p></p>
<p class="MsoPlainText">> <o:p></o:p></p>
<p class="MsoPlainText">> <o:p></o:p></p>
<p class="MsoPlainText">> I’ve drafted up the redline for the
changes for an upcoming ballot on
<o:p></o:p></p>
<p class="MsoPlainText">> the current version of the Baseline
Requirements for the Issuance and
<o:p></o:p></p>
<p class="MsoPlainText">> Management of Publicly-Trusted Code
Signing Certificates
<o:p></o:p></p>
<p class="MsoPlainText">>
<<a class="moz-txt-link-freetext" href="https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcab">https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcab</a><o:p></o:p></p>
<p class="MsoPlainText">>
forum.org%2Fwp-content%2Fuploads%2Fbaseline_requirements_for_the_issua<o:p></o:p></p>
<p class="MsoPlainText">>
nce_and_management_of_code_signing.v.2.0.pdf&data=04%7C01%7Cianmcm<o:p></o:p></p>
<p class="MsoPlainText">>
%40microsoft.com%7C268dd401618346621b3908d887ab7b0c%7C72f988bf86f141af<o:p></o:p></p>
<p class="MsoPlainText">>
91ab2d7cd011db47%7C0%7C1%7C637408518632803125%7CUnknown%7CTWFpbGZsb3d8<o:p></o:p></p>
<p class="MsoPlainText">>
eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1<o:p></o:p></p>
<p class="MsoPlainText">>
000&sdata=VpQ15CkmBvodqdoLhc9SGinv6KEpsI7t90BUFDEbQ1E%3D&reser<o:p></o:p></p>
<p class="MsoPlainText">> ved=0> on section 16.2 and 16.3
as it pertains to subscriber private
<o:p></o:p></p>
<p class="MsoPlainText">> key protection requirements
(leaf-signing cert private keys). The goal
<o:p></o:p></p>
<p class="MsoPlainText">> is to collapse the requirements on
non-EV and EV, and to include
<o:p></o:p></p>
<p class="MsoPlainText">> support for cloud-based key
protection solution offered by GCP, AWS,
<o:p></o:p></p>
<p class="MsoPlainText">> and Azure.<o:p></o:p></p>
<p class="MsoPlainText">> Please review and provide comments
on the verbiage below and the
<o:p></o:p></p>
<p class="MsoPlainText">> redline changes in the document
attached, and *if you would be willing
<o:p></o:p></p>
<p class="MsoPlainText">> to endorse this change in the
upcoming ballot, please let me know*.<o:p></o:p></p>
<p class="MsoPlainText">> <o:p></o:p></p>
<p class="MsoPlainText">> <o:p></o:p></p>
<p class="MsoPlainText">> <o:p></o:p></p>
<p class="MsoPlainText">> */16.2 Signing Service
Requirements/**//*<o:p></o:p></p>
<p class="MsoPlainText">> <o:p></o:p></p>
<p class="MsoPlainText">> The Signing Service MUST ensure
that a Subscriber’s private key is
<o:p></o:p></p>
<p class="MsoPlainText">> generated, stored, and used in a
secure environment that has controls
<o:p></o:p></p>
<p class="MsoPlainText">> to prevent theft or misuse. A
Signing Service MUST enforce
<o:p></o:p></p>
<p class="MsoPlainText">> multi-factor authentication to
authorize Code Signing and obtain a
<o:p></o:p></p>
<p class="MsoPlainText">> representation from the Subscriber
that they will securely store the
<o:p></o:p></p>
<p class="MsoPlainText">> tokens required for multi-factor
access. A system used to host a
<o:p></o:p></p>
<p class="MsoPlainText">> Signing Service MUST NOT be used
for web browsing. The Signing
<o:p></o:p></p>
<p class="MsoPlainText">> Service MUST run a regularly
updated antivirus solution to scan the
<o:p></o:p></p>
<p class="MsoPlainText">> service for possible virus
infection. The Signing Service MUST comply
<o:p></o:p></p>
<p class="MsoPlainText">> with the Network Security
Guidelines as a “Delegated Third Party”.<o:p></o:p></p>
<p class="MsoPlainText">> <o:p></o:p></p>
<p class="MsoPlainText">> For Code Signing Certificates,
Signing Services shall protect private
<o:p></o:p></p>
<p class="MsoPlainText">> keys in a FIPS 140-2 level 2 (or
equivalent) crypto module.
<o:p></o:p></p>
<p class="MsoPlainText">> Techniques that may be used to
satisfy this requirement include:<o:p></o:p></p>
<p class="MsoPlainText">> <o:p></o:p></p>
<p class="MsoPlainText">> <o:p></o:p></p>
<p class="MsoPlainText">> <o:p></o:p></p>
<p class="MsoPlainText">> 1. Use of an HSM, verified by
means of a manufacturer’s
<o:p></o:p></p>
<p class="MsoPlainText">> certificate;<o:p></o:p></p>
<p class="MsoPlainText">> <o:p></o:p></p>
<p class="MsoPlainText">> 2. A hardware crypto module
provided by the CA;<o:p></o:p></p>
<p class="MsoPlainText">> <o:p></o:p></p>
<p class="MsoPlainText">> 3. Contractual terms in the
subscriber agreement requiring the
<o:p></o:p></p>
<p class="MsoPlainText">> Subscriber to protect the private
key to a standard equivalent to FIPS<o:p></o:p></p>
<p class="MsoPlainText">> 140-2 level 2 and with compliance
being confirmed by means of an audit.<o:p></o:p></p>
<p class="MsoPlainText">> <o:p></o:p></p>
<p class="MsoPlainText">> 4. Cryptographic algorithms,
key sizes and certificate
<o:p></o:p></p>
<p class="MsoPlainText">> life-times for both authorities and
Subscribers are governed by the
<o:p></o:p></p>
<p class="MsoPlainText">> NIST key management guidelines.<o:p></o:p></p>
<p class="MsoPlainText">> <o:p></o:p></p>
<p class="MsoPlainText">> 5. A Cloud-based key
protection solution with the following
<o:p></o:p></p>
<p class="MsoPlainText">> requirements enabled on the
subscription, and a usage pattern as follows:<o:p></o:p></p>
<p class="MsoPlainText">> <o:p></o:p></p>
<p class="MsoPlainText">> /1. //A hardware crypto
module with a unit design form factor
<o:p></o:p></p>
<p class="MsoPlainText">> certified as conforming to at least
FIPS 140-2 Level 2, eIDAS
<o:p></o:p></p>
<p class="MsoPlainText">> Protection<o:p></o:p></p>
<p class="MsoPlainText">> Profile: EN 419 221-5, or
equivalent;/<o:p></o:p></p>
<p class="MsoPlainText">> <o:p></o:p></p>
<p class="MsoPlainText">> /2. //Key creation, storage,
and usage of private key must
<o:p></o:p></p>
<p class="MsoPlainText">> remain within the security
boundaries of the cloud solutions hardware
<o:p></o:p></p>
<p class="MsoPlainText">> crypto module;/<o:p></o:p></p>
<p class="MsoPlainText">> <o:p></o:p></p>
<p class="MsoPlainText">> /3. //Subscription must be
configured to log access, operations,
<o:p></o:p></p>
<p class="MsoPlainText">> and configuration changes on the
key. The configuration change log is
<o:p></o:p></p>
<p class="MsoPlainText">> available for audits./<o:p></o:p></p>
<p class="MsoPlainText">> <o:p></o:p></p>
<p class="MsoPlainText">> <o:p></o:p></p>
<p class="MsoPlainText">> <o:p></o:p></p>
<p class="MsoPlainText">> */16.3 Subscriber Private Key
Protection/**//*<o:p></o:p></p>
<p class="MsoPlainText">> <o:p></o:p></p>
<p class="MsoPlainText">> For Code Signing Certificates, the
CA MUST obtain a representation
<o:p></o:p></p>
<p class="MsoPlainText">> from the Subscriber that the
Subscriber will use one of the following
<o:p></o:p></p>
<p class="MsoPlainText">> options to generate and protect
their Code Signing Certificate private keys:<o:p></o:p></p>
<p class="MsoPlainText">> <o:p></o:p></p>
<p class="MsoPlainText">> <o:p></o:p></p>
<p class="MsoPlainText">> <o:p></o:p></p>
<p class="MsoPlainText">> 1. A hardware crypto module
with a unit design form factor
<o:p></o:p></p>
<p class="MsoPlainText">> certified as conforming to at least
FIPS 140-2 Level 2, eIDAS
<o:p></o:p></p>
<p class="MsoPlainText">> Protection<o:p></o:p></p>
<p class="MsoPlainText">> Profile: EN 419 221-5, or
equivalent;<o:p></o:p></p>
<p class="MsoPlainText">> <o:p></o:p></p>
<p class="MsoPlainText">> <o:p></o:p></p>
<p class="MsoPlainText">> <o:p></o:p></p>
<p class="MsoPlainText">> 2. A Cloud-based key
protection solution with the following
<o:p></o:p></p>
<p class="MsoPlainText">> requirements enabled on the
subscription, and a usage pattern as follows:<o:p></o:p></p>
<p class="MsoPlainText">> <o:p></o:p></p>
<p class="MsoPlainText">> /1. //A hardware crypto
module with a unit design form factor
<o:p></o:p></p>
<p class="MsoPlainText">> certified as conforming to at least
FIPS 140-2 Level 2, eIDAS
<o:p></o:p></p>
<p class="MsoPlainText">> Protection<o:p></o:p></p>
<p class="MsoPlainText">> Profile: EN 419 221-5, or
equivalent;/<o:p></o:p></p>
<p class="MsoPlainText">> <o:p></o:p></p>
<p class="MsoPlainText">> /2. //Key creation, storage,
and usage of private key must
<o:p></o:p></p>
<p class="MsoPlainText">> remain within the security
boundaries of the cloud solutions hardware
<o:p></o:p></p>
<p class="MsoPlainText">> crypto module;/<o:p></o:p></p>
<p class="MsoPlainText">> <o:p></o:p></p>
<p class="MsoPlainText">> /3. //Subscription must be
configured to log all access,
<o:p></o:p></p>
<p class="MsoPlainText">> operations, and configuration
changes on the key. The configuration
<o:p></o:p></p>
<p class="MsoPlainText">> change log is available for
audits./<o:p></o:p></p>
<p class="MsoPlainText">> <o:p></o:p></p>
<p class="MsoPlainText">> / /<o:p></o:p></p>
<p class="MsoPlainText">> <o:p></o:p></p>
<p class="MsoPlainText">> 3. A type of hardware storage
token with a unit design form
<o:p></o:p></p>
<p class="MsoPlainText">> factor of SD Card or USB token
certified as conformant with FIPS 140
<o:p></o:p></p>
<p class="MsoPlainText">> Level 2 or eIDAS Protection
Profile: EN 419 221-5). The Subscriber
<o:p></o:p></p>
<p class="MsoPlainText">> MUST also warrant that it will keep
the token physically separate from
<o:p></o:p></p>
<p class="MsoPlainText">> the device that hosts the code
signing function until a signing session is begun.<o:p></o:p></p>
<p class="MsoPlainText">> <o:p></o:p></p>
<p class="MsoPlainText">> <o:p></o:p></p>
<p class="MsoPlainText">> <o:p></o:p></p>
<p class="MsoPlainText">> For Code Signing Certificates, CAs
SHALL ensure that the Subscriber’s
<o:p></o:p></p>
<p class="MsoPlainText">> private key is generated, stored
and used in a crypto module that
<o:p></o:p></p>
<p class="MsoPlainText">> meets or exceeds the requirements
of FIPS 140-2 level 2, eIDAS
<o:p></o:p></p>
<p class="MsoPlainText">> Protection<o:p></o:p></p>
<p class="MsoPlainText">> Profile: EN 419 221-5, or
equivalent. Acceptable methods of satisfying
<o:p></o:p></p>
<p class="MsoPlainText">> this requirement include (but are
not limited to) the following:<o:p></o:p></p>
<p class="MsoPlainText">> <o:p></o:p></p>
<p class="MsoPlainText">> <o:p></o:p></p>
<p class="MsoPlainText">> <o:p></o:p></p>
<p class="MsoPlainText">> 1. The Subscriber
counter-signs certificate requests that can be
<o:p></o:p></p>
<p class="MsoPlainText">> verified by using a manufacturer’s
certificate indicating that the key
<o:p></o:p></p>
<p class="MsoPlainText">> is managed in a suitable hardware
module;<o:p></o:p></p>
<p class="MsoPlainText">> <o:p></o:p></p>
<p class="MsoPlainText">> <o:p></o:p></p>
<p class="MsoPlainText">> <o:p></o:p></p>
<p class="MsoPlainText">> 2. The Subscriber provides a
suitable IT audit indicating that
<o:p></o:p></p>
<p class="MsoPlainText">> its operating environment achieves
a level of security at least
<o:p></o:p></p>
<p class="MsoPlainText">> equivalent to that of FIPS 140-2
level 2, eIDAS Protection Profile: EN
<o:p></o:p></p>
<p class="MsoPlainText">> 419 221-5, or equivalent;<o:p></o:p></p>
<p class="MsoPlainText">> <o:p></o:p></p>
<p class="MsoPlainText">> <o:p></o:p></p>
<p class="MsoPlainText">> <o:p></o:p></p>
<p class="MsoPlainText">> 3. The Subscriber provides a
suitable report of the cloud key
<o:p></o:p></p>
<p class="MsoPlainText">> protection solution subscription
configuration protecting the key in
<o:p></o:p></p>
<p class="MsoPlainText">> hardware crypto module with a unit
design form factor certified as
<o:p></o:p></p>
<p class="MsoPlainText">> conforming to at least FIPS 140-2
Level 2, eIDAS Protection Profile,
<o:p></o:p></p>
<p class="MsoPlainText">> EN<o:p></o:p></p>
<p class="MsoPlainText">> 419 221-5, or equivalent.<o:p></o:p></p>
<p class="MsoPlainText">> <o:p></o:p></p>
<p class="MsoPlainText">> <o:p></o:p></p>
<p class="MsoPlainText">> <o:p></o:p></p>
<p class="MsoPlainText">> <o:p></o:p></p>
<p class="MsoPlainText">> <o:p></o:p></p>
<p class="MsoPlainText">> Thanks,<o:p></o:p></p>
<p class="MsoPlainText">> <o:p></o:p></p>
<p class="MsoPlainText">> Ian McMillan<o:p></o:p></p>
<p class="MsoPlainText">> <o:p></o:p></p>
<p class="MsoPlainText">> Microsoft<o:p></o:p></p>
<p class="MsoPlainText">> <o:p></o:p></p>
<p class="MsoPlainText">> <o:p></o:p></p>
<p class="MsoPlainText">> <o:p></o:p></p>
<p class="MsoPlainText">> <o:p></o:p></p>
<p class="MsoPlainText">> <o:p></o:p></p>
<p class="MsoPlainText">> <o:p></o:p></p>
<p class="MsoPlainText">>
_______________________________________________<o:p></o:p></p>
<p class="MsoPlainText">> Cscwg-public mailing list<o:p></o:p></p>
<p class="MsoPlainText">> <a
href="mailto:Cscwg-public@cabforum.org"
moz-do-not-send="true"><span
style="color:windowtext;text-decoration:none">Cscwg-public@cabforum.org</span></a><o:p></o:p></p>
<p class="MsoPlainText">> <a
href="https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flist"
moz-do-not-send="true">
<span style="color:windowtext;text-decoration:none">https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flist</span></a><o:p></o:p></p>
<p class="MsoPlainText">>
s.cabforum.org%2Fmailman%2Flistinfo%2Fcscwg-public&data=04%7C01%7C<o:p></o:p></p>
<p class="MsoPlainText">>
ianmcm%40microsoft.com%7C268dd401618346621b3908d887ab7b0c%7C72f988bf86<o:p></o:p></p>
<p class="MsoPlainText">>
f141af91ab2d7cd011db47%7C0%7C1%7C637408518632803125%7CUnknown%7CTWFpbG<o:p></o:p></p>
<p class="MsoPlainText">>
Zsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%<o:p></o:p></p>
<p class="MsoPlainText">>
3D%7C1000&sdata=EI8oFiOeODof9tI47AMHhxynm3%2B02xHZY6k4jjqxAbI%3D&a<o:p></o:p></p>
<p class="MsoPlainText">> mp;reserved=0<o:p></o:p></p>
<p class="MsoPlainText">> <o:p></o:p></p>
<p class="MsoPlainText">_______________________________________________<o:p></o:p></p>
<p class="MsoPlainText">Cscwg-public mailing list<o:p></o:p></p>
<p class="MsoPlainText"><a
href="mailto:Cscwg-public@cabforum.org"
moz-do-not-send="true"><span
style="color:windowtext;text-decoration:none">Cscwg-public@cabforum.org</span></a><o:p></o:p></p>
<p class="MsoPlainText"><a
href="https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.cabforum.org%2Fmailman%2Flistinfo%2Fcscwg-public&data=04%7C01%7Cianmcm%40microsoft.com%7C268dd401618346621b3908d887ab7b0c%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C1%7C637408518632803125%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=EI8oFiOeODof9tI47AMHhxynm3%2B02xHZY6k4jjqxAbI%3D&reserved=0"
moz-do-not-send="true"><span
style="color:windowtext;text-decoration:none">https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.cabforum.org%2Fmailman%2Flistinfo%2Fcscwg-public&data=04%7C01%7Cianmcm%40microsoft.com%7C268dd401618346621b3908d887ab7b0c%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C1%7C637408518632803125%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=EI8oFiOeODof9tI47AMHhxynm3%2B02xHZY6k4jjqxAbI%3D&reserved=0</span></a><o:p></o:p></p>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
Cscwg-public mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Cscwg-public@cabforum.org">Cscwg-public@cabforum.org</a>
<a class="moz-txt-link-freetext" href="https://lists.cabforum.org/mailman/listinfo/cscwg-public">https://lists.cabforum.org/mailman/listinfo/cscwg-public</a>
</pre>
</blockquote>
<br>
</body>
</html>