<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<!--[if !mso]><style>v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style><![endif]--><style><!--
/* Font Definitions */
@font-face
{font-family:SimSun;
panose-1:2 1 6 0 3 1 1 1 1 1;}
@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:Consolas;
panose-1:2 11 6 9 2 2 4 3 2 4;}
@font-face
{font-family:"\@SimSun";
panose-1:2 1 6 0 3 1 1 1 1 1;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;
mso-fareast-language:ZH-CN;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:#0563C1;
text-decoration:underline;}
pre
{mso-style-priority:99;
mso-style-link:"HTML Preformatted Char";
margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:SimSun;
mso-fareast-language:ZH-CN;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;
mso-fareast-language:ZH-CN;}
span.HTMLPreformattedChar
{mso-style-name:"HTML Preformatted Char";
mso-style-priority:99;
mso-style-link:"HTML Preformatted";
font-family:Consolas;
mso-fareast-language:ZH-CN;}
span.EmailStyle21
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:1269779814;
mso-list-template-ids:379364156;}
@list l0:level1
{mso-level-tab-stop:.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level2
{mso-level-tab-stop:1.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level3
{mso-level-tab-stop:1.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level4
{mso-level-tab-stop:2.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level5
{mso-level-tab-stop:2.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level6
{mso-level-tab-stop:3.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level7
{mso-level-tab-stop:3.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level8
{mso-level-tab-stop:4.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level9
{mso-level-tab-stop:4.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1
{mso-list-id:1861040463;
mso-list-template-ids:-1272538676;}
@list l1:level1
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l1:level2
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:1.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l1:level3
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:1.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l1:level4
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:2.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l1:level5
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:2.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l1:level6
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:3.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l1:level7
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:3.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l1:level8
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:4.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l1:level9
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:4.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l2
{mso-list-id:2139490667;
mso-list-type:hybrid;
mso-list-template-ids:240398248 67698703 67698713 67698715 67698703 67698713 67698715 67698703 67698713 67698715;}
@list l2:level1
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l2:level2
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l2:level3
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l2:level4
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l2:level5
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l2:level6
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l2:level7
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l2:level8
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l2:level9
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
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]-->
</head>
<body lang="EN-US" link="#0563C1" vlink="purple" style="word-wrap:break-word">
<div class="WordSection1">
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">Hi Dmitris, <o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">This is not too painful.
</span><span style="font-family:"Segoe UI Emoji",sans-serif;mso-fareast-language:EN-US">😊</span><span style="mso-fareast-language:EN-US"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">Effective date set is September 1, 2022 as stated in section 16.3, but 16.2 already has an effective date (June 1, 2021) for signing services to use
</span>at least FIPS 140-2 level 2, or Common Criteria EAL 4+ for ALL Code Signing Certificates per the table in section 1.3. I’ll add the effective date into the table in section 1.3 for the changes in 16.3 on all code signing certs . Please review the text
I used in the 1.3 table, and suggest some better language if possible.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">When I read the,"conforming to <b>at least</b> FIPS 140-2 level 2, or Common Criteria EAL 4+", it does apply to CC EAL 4+ as well.
<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">In 16.2, I’ve corrected the typo (thanks!), but for cloud-based solutions they will have their own terms for resources under a subscription. I think the wording we’ll need to summarize to is for each key generated and stored in the cloud-based
subscription it must be conforming to the requirements. With Azure and AKV, if I have a subscription with a resource group and an AKV resource underneath, for every key I generate, I’ll need to specify the vault protection level (HSM) upon key creation. This
means I could have a subscription with N number of keys with various protection levels. AKV recommends users do not group secrets into one vault, but it doesn’t stop users from making this risk decision on their own (more keys in one vault, the larger impact
if compromised). GCP and AWS all have similar offerings and concepts, but the common level of terminology is subscription. I’ve updated the language to specifically target the subscription configuration at the level that manages the private key.
<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">In 16.3.1, I’ve updated….<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<ol style="margin-top:0in" start="1" type="1">
<li class="MsoListParagraph" style="margin-left:0in;mso-list:l2 level1 lfo4">To be the suggested text you provided, “Subscriber uses a hosted hardware crypto module meeting the specified requirement;” I feel this effectively closes the loophole you pointed
out.<o:p></o:p></li></ol>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">On cloud-based vs signing service solutions (2 & 3), they are distinctly different solutions in the market for subscribers today, so I feel we need to expressly call them out differently.
<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">For section 16.3.2, I am good with the suggested change to #2 with a small ordering tweak being, “The Subscriber counter-signs certificate requests that can be verified by using a manufacturer’s certificate indicating that the key was generated
in a non-exportable way using a suitable hardware module;”<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">With #1, I’d prefer keeping the same way it is today. I’m interested how folks view section 10.2.4 playing a part here as well (and with signing services).
<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">On #8, My goal wasn’t to set a deadline for new methods to be introduced, but to require any innovations to be well documented by the CAs and brought to the Forum’s working group for inclusion. That said, I see the loophole this creates
in that a CA could include a new method in their CP/CPS docs and bring it to the WG in the accordance with this requirement. But the WG could deem the method not acceptable and there is no requirement that states the CA must not use that now rejected method.
The downside is we really do not want to maintain a rejected method list, so I am with you on the suggested change you provided with the date being September 1, 2022. I would like to keep the dates all aligned to reduce confusion.
<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">The attached updated redline draft has all these changes.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Thanks,<o:p></o:p></p>
<p class="MsoNormal">Ian<span style="mso-fareast-language:EN-US"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b>From:</b> Cscwg-public <cscwg-public-bounces@cabforum.org>
<b>On Behalf Of </b>Dimitris Zacharopoulos (HARICA) via Cscwg-public<br>
<b>Sent:</b> Thursday, November 11, 2021 1:42 PM<br>
<b>To:</b> cscwg-public@cabforum.org<br>
<b>Subject:</b> [EXTERNAL] Re: [Cscwg-public] Discussion: Proposed Ballot CSC-6: Update to Subscriber Private Key Protection Requirements<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal" style="margin-bottom:12.0pt">Hello Ian,<br>
<br>
I noticed that you have not set an effective date for all these changes. It would be best if the ballot itself contained updates to the table in section 1.3. With that said, section 16.2 probably needs an effective date because it requires signing services
to use at least FIPS 140-2 level 2, or Common Criteria EAL 4+ for ALL Code Signing Certificates (it used to apply only for EV CS Certificates).<br>
<br>
When you say "conforming to <b>at least</b> FIPS 140-2 level 2, or Common Criteria EAL 4+", does the "at least" apply only for the first part (FIPS 140-2 level 2) or does it also extend to the second part (Common Criteria EAL 4+)? I'm not 100% sure how it is
used in the English language and since it is possible to have non-native English speakers interpreting these requirements (CAs and auditors), I thought it's best to ask for clarifications.<br>
<br>
While still on section 16.2, I believe the introduction of the term "cloud-base<b>d</b>" (please correct the typo), "subscription and usage pattern" needs to be defined and/or clarified. Similarly for the "cloud solution" in 2a. We may need some assistance
from providers offering cloud key management services to reach good language for this. We can certainly try ourselves and see what happens :-)<br>
<br>
In 16.3.1, under the new numbered item 1., <br>
<br>
" 1. Subscriber hosts a hardware crypto module meeting the specified requirement; "<br>
<br>
does not mean that the key will be protected in that hardware crypto module. As written, a subscriber could just present that they own a compliant device and would meet the requirement without the need for them to actually use it.<br>
<br>
Following similar language as 2. and 3., I would recommend changing this to:<br>
<br>
"1. Subscriber uses a hosted hardware crypto module meeting the specified requirements;"<br>
<br>
I have some concerns about 2. which are related to the definition/clarifications described above for "cloud-based" key management solutions. In my opinion these are not any different from "signing services", which are entities that manage keys on behalf of
the Subscribers. Having two similar terms for similar things is a bit confusing.<br>
<br>
Section 16.3 should be more about Private Key <b>generation, use</b> and protection. The "verification" part sounds a bit strange for me. 16.3.2 is more about the subscriber key generation part, and assurances that the key generation is done properly according
to the specified requirements.<br>
<br>
Finally, some small recommendations for 16.3.2.<br>
<br>
"1. The CA ships a suitable hardware crypto module, with a preinstalled key pair" could be changed to:<br>
<br>
"1. The CA ships a suitable hardware crypto module, with one or more pre-generated key pairs that the CA has generated using those crypto modules"<br>
<br>
"2. 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; " to<br>
<br>
"2. The Subscriber counter-signs certificate requests that can be verified by using a manufacturer’s certificate indicating that the key was generated in a suitable hardware module in a non-exportable way;"<br>
<br>
I thought we agreed to remove option 4. (a suitable IT audit indicating a FIPS 140-2 level 2 or equivalent) because we didn't hear auditors or CAs using that option and it is very ambiguous and risky. I would love to see this go and I believe September 2022
is a reasonable timeframe to deprecate this practice.<br>
<br>
For 6., the "cloud-based" again sounds confusing to me because they are effectively "signing services". They generate and protect the subscriber keys on their behalf.<br>
<br>
"8. Any other method the CA uses satisfy this requirement SHALL be specified in the CPS and must be proposed to the CA/Browser Forum for inclusion into these requirements within a 6-month period." to<br>
<br>
"8. Any other method the CA uses to satisfy this requirement. The CA SHALL specify and describe in detail those other methods in its Certificate Policy or Certification Practice Statement, and SHALL propose those methods to the CA/Browser Forum Code Signing
Working Group for inclusion into these requirements until April 1, 2022, using the
<a href="mailto:questions@cabforum.org">questions@cabforum.org</a> mailing list. After that date, the Code Signing Working Group will discuss the removal of this "any other method" and allow only CA/Browser Forum approved methods."<br>
<br>
I hope that was not too painful for you to read :-)<br>
<br>
<br>
Dimitris.<span style="font-size:12.0pt"><o:p></o:p></span></p>
<div>
<p class="MsoNormal">On 11/11/2021 3:36 μ.μ., Ian McMillan via Cscwg-public wrote:<o:p></o:p></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">Hi Folks,</span><o:p></o:p></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">After a brief side conversation with Bruce, I’ve made some further edits to the redline draft to include the CA prescribed CSP and suitable hardware crypto module scenario raised in the last call.</span><o:p></o:p></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">Please review the attached redline now and let me know if you have any feedback and if you are willing to endorse this ballot.</span><o:p></o:p></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">Thanks,</span><o:p></o:p></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">Ian</span><o:p></o:p></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"> </span><o:p></o:p></p>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b>From:</b> Cscwg-public <a href="mailto:cscwg-public-bounces@cabforum.org">
<cscwg-public-bounces@cabforum.org></a> <b>On Behalf Of </b>Ian McMillan via Cscwg-public<br>
<b>Sent:</b> Tuesday, November 9, 2021 8:35 AM<br>
<b>To:</b> Bruce Morton <a href="mailto:Bruce.Morton@entrust.com"><Bruce.Morton@entrust.com></a>;
<a href="mailto:cscwg-public@cabforum.org">cscwg-public@cabforum.org</a><br>
<b>Subject:</b> [EXTERNAL] Re: [Cscwg-public] Discussion: Proposed Ballot CSC-6: Update to Subscriber Private Key Protection Requirements<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">Thanks Bruce!</span><o:p></o:p></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">Really appreciate the help with the new redline draft. I’ve added the effective date of September 1, 2022 for this change to private key protection requirements. That seems reasonable and better
than placing a date closer to major events in the calendar year (e.g. end of year holiday season).
</span><o:p></o:p></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">The other thing that isn’t sitting well with me is the Signing Service requirements section 16.2, so I added the cloud-based key protection to the list of techniques that MAY be used for protecting
the private keys of subscribers in a Signing Service. I know this section will have considerable overhauling in the very near future, so I only would like to add this minor update.</span><o:p></o:p></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">For everyone, please see that new attached redline now. Also please let me know if you are willing to endorse the ballot.</span><o:p></o:p></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">Thanks,</span><o:p></o:p></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">Ian </span><o:p></o:p></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"> </span><o:p></o:p></p>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b>From:</b> Bruce Morton <<a href="mailto:Bruce.Morton@entrust.com">Bruce.Morton@entrust.com</a>>
<br>
<b>Sent:</b> Thursday, November 4, 2021 3:00 PM<br>
<b>To:</b> Bruce Morton <<a href="mailto:Bruce.Morton@entrust.com">Bruce.Morton@entrust.com</a>>;
<a href="mailto:cscwg-public@cabforum.org">cscwg-public@cabforum.org</a>; Ian McMillan <<a href="mailto:ianmcm@microsoft.com">ianmcm@microsoft.com</a>><br>
<b>Subject:</b> [EXTERNAL] RE: Discussion: Proposed Ballot CSC-6: Update to Subscriber Private Key Protection Requirements<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">Hi Ian,<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">Great meeting. Looks like we are making progress now. It will be nice to get this behind us.
<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">Since the change will impact the CAs, we need the ballot to have an effectivity date. As such, we need to keep the current requirements as is with no change. We will also add in the new requirements and have them be effective on a future
date. It is understood that the CAs may implement the requirement before that date.<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">Attached is a draft with the idea. I used the latest version of the CSBRs and captured most of the changes.<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">It would be great, if the CAs could provide some feedback on an effective date.<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">Thanks, Bruce.<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b>From:</b> Cscwg-public <<a href="mailto:cscwg-public-bounces@cabforum.org">cscwg-public-bounces@cabforum.org</a>>
<b>On Behalf Of </b>Bruce Morton via Cscwg-public<br>
<b>Sent:</b> Wednesday, November 3, 2021 1:21 PM<br>
<b>To:</b> Ian McMillan <<a href="mailto:ianmcm@microsoft.com">ianmcm@microsoft.com</a>>;
<a href="mailto:cscwg-public@cabforum.org">cscwg-public@cabforum.org</a><br>
<b>Subject:</b> [EXTERNAL] Re: [Cscwg-public] Discussion: Proposed Ballot CSC-6: Update to Subscriber Private Key Protection Requirements<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:SimSun">WARNING: This email originated outside of Entrust.<br>
DO NOT CLICK links or attachments unless you trust the sender and know the content is safe.</span><o:p></o:p></p>
<div class="MsoNormal" align="center" style="text-align:center"><span style="font-size:12.0pt;font-family:SimSun">
<hr size="1" width="100%" align="center">
</span></div>
<p class="MsoNormal">Hi Ian,<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">Thanks for the proposal. Please find your document with some edits. I wanted to state that the subscriber could use a Signing Service to protect the private key. In addition I tried to reduce the number of “FIPS 140-2 Level 2 or Common
Criteria EAL 4+” call outs as I am sure they will not remain consistent.<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">Looking forward to the discussion tomorrow.<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">Thanks again, Bruce.<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b>From:</b> Cscwg-public <<a href="mailto:cscwg-public-bounces@cabforum.org">cscwg-public-bounces@cabforum.org</a>>
<b>On Behalf Of </b>Ian McMillan via Cscwg-public<br>
<b>Sent:</b> Wednesday, November 3, 2021 10:58 AM<br>
<b>To:</b> <a href="mailto:cscwg-public@cabforum.org">cscwg-public@cabforum.org</a><br>
<b>Subject:</b> [EXTERNAL] [Cscwg-public] Discussion: Proposed Ballot CSC-6: Update to Subscriber Private Key Protection Requirements<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:SimSun">WARNING: This email originated outside of Entrust.<br>
DO NOT CLICK links or attachments unless you trust the sender and know the content is safe.</span><o:p></o:p></p>
<div class="MsoNormal" align="center" style="text-align:center"><span style="font-size:12.0pt;font-family:SimSun">
<hr size="1" width="100%" align="center">
</span></div>
<p class="MsoNormal">Hi Folks,<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">I’ve found the time to write up the subscriber private key protection update under a proposed Ballot CSC-6. Please review the attached redline doc and provide feedback. Also, please let me know if you are willing to endorse this ballot.
<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal"><a href="https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fwiki.cabforum.org%2Fcscwg%2Fcsc_6_-_update_to_subscriber_private_key_protection_requirements__%3B!!FJ-Y8qCqXTj2!JFXFBvuicNpp5JGeK1TvRJ-6eotM5fhSRjTUe2CUTty2HljPYkdltIcLdAbGX374fBk%24&data=04%7C01%7Cianmcm%40microsoft.com%7C3fcb6f7b002144eeacc308d9a542fec9%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637722529511561524%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=BkDEwbd%2Bs7MsAgwFPN2iXZMsuMGnmZibz%2FepayRh%2FyY%3D&reserved=0">cscwg:csc_6_-_update_to_subscriber_private_key_protection_requirements
[CAB Forum Wiki]</a><o:p></o:p></p>
<p class="MsoNormal">Ballot CSC-6: Update to Subscriber Private Key Protection Requirements<o:p></o:p></p>
<p class="MsoNormal">Purpose of this ballot: Update the subscriber private key protection requirements in the Baseline Requirement for the Issuance and Management of Publicly-Trusted Code Signing Certificates v2.5. The following motion has been proposed by
Ian McMillan of Microsoft, and endorsed by <Name + Org> and <Name + Org>.<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">— MOTION BEGINS — This ballot updates the “Baseline Requirements for the Issuance and Management of Publicly‐Trusted Code Signing Certificates“ version 2.5 according to the attached redline which includes:<o:p></o:p></p>
<ol style="margin-top:0in" start="1" type="1">
<li class="MsoNormal" style="mso-list:l0 level1 lfo3">Update section 16.3 “Subscriber Private Key Protection” to “Subscriber Private Key Protection and Verification”<o:p></o:p></li><li class="MsoNormal" style="mso-list:l0 level1 lfo3">Update section 16.3 “Subscriber Private Key Protection” to include sub-sections “16.3.1 Subscriber Private Key Protection” and “16.3.2 Subscriber Private Key Verification”<o:p></o:p></li><li class="MsoNormal" style="mso-list:l0 level1 lfo3">Update section 16.3 under new sub-section 16.3.1 to remove allowance of TPM key generation and software protected private key protection, and remove private key protection requirement differences between
EV and non-EV Code Signing Certificates<o:p></o:p></li><li class="MsoNormal" style="mso-list:l0 level1 lfo3">Update section 16.3 under new sub-section 16.3.1 to include the allowance of key generation and protection using a cloud-based key protection solution providing key generation and protection in a hardware
crypto module that conforms to at least FIPS 140-2 Level 2 or Common Criteria EAL 4+<o:p></o:p></li><li class="MsoNormal" style="mso-list:l0 level1 lfo3">Update section 16.3 under new sub-section 16.3.2 to include verification for Code Signing Certificates' private key generation and storage in a crypto module that meets or exceeds the requirements of FIPS
140-2 level 2 or Common Criteria EAL 4+ by the CAs. Include additional acceptable methods for verification including cloud-based key generation and protection solutions and a stimpulation for CAs to satisfy this verification requirement with additional means
specified in their CPS. Any additional means specified by a CA in their CPS, must be proposed to the CA/Browser Forum for inclusion into the acceptable methods for section 16.3.2 within 6 months of inclusion in their CPS.<o:p></o:p></li></ol>
<p class="MsoNormal">— MOTION ENDS —<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">The procedure for approval of this ballot is as follows:<o:p></o:p></p>
<p class="MsoNormal">Discussion (7 days) Start Time: TBD End Time: TBD<o:p></o:p></p>
<p class="MsoNormal">Vote for approval (7 days) Start Time: TBD End Time: TBD<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">Thanks,<o:p></o:p></p>
<p class="MsoNormal">Ian<o:p></o:p></p>
<p class="MsoNormal"><i><span style="font-size:12.0pt;font-family:SimSun">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.
<u>Please notify Entrust immediately</u> and delete the message from your system.</span></i><span style="font-size:12.0pt;font-family:SimSun">
</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:SimSun"><br>
<br>
<o:p></o:p></span></p>
<pre>_______________________________________________<o:p></o:p></pre>
<pre>Cscwg-public mailing list<o:p></o:p></pre>
<pre><a href="mailto:Cscwg-public@cabforum.org">Cscwg-public@cabforum.org</a><o:p></o:p></pre>
<pre><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%7C3fcb6f7b002144eeacc308d9a542fec9%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637722529511571474%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=DNmJWVKCcMY0ybs4pFnIulBPzQPahXngcddzJ%2FQSy2k%3D&reserved=0">https://lists.cabforum.org/mailman/listinfo/cscwg-public</a><o:p></o:p></pre>
</blockquote>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:SimSun"><o:p> </o:p></span></p>
</div>
</body>
</html>