<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)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:DengXian;
panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:"Segoe UI Emoji";
panose-1:2 11 5 2 4 2 4 2 2 3;}
@font-face
{font-family:"\@DengXian";
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;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
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;}
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:212815055;
mso-list-template-ids:-559534042;}
@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:640380399;
mso-list-template-ids:1280767766;}
@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:1168014613;
mso-list-template-ids:-1452237050;}
@list l2:level1
{mso-level-tab-stop:.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l2:level2
{mso-level-tab-stop:1.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l2:level3
{mso-level-tab-stop:1.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l2:level4
{mso-level-tab-stop:2.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l2:level5
{mso-level-tab-stop:2.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l2:level6
{mso-level-tab-stop:3.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l2:level7
{mso-level-tab-stop:3.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l2:level8
{mso-level-tab-stop:4.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l2:level9
{mso-level-tab-stop:4.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l3
{mso-list-id:1197045088;
mso-list-template-ids:1650106284;}
@list l3: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 l3: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 l3: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 l3: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 l3: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 l3: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 l3: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 l3: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 l3: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 l4
{mso-list-id:1280988749;
mso-list-template-ids:1105476376;}
@list l5
{mso-list-id:1301501145;
mso-list-template-ids:-970027840;}
@list l5:level1
{mso-level-tab-stop:.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l5:level2
{mso-level-tab-stop:1.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l5:level3
{mso-level-tab-stop:1.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l5:level4
{mso-level-tab-stop:2.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l5:level5
{mso-level-tab-stop:2.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l5:level6
{mso-level-tab-stop:3.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l5:level7
{mso-level-tab-stop:3.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l5:level8
{mso-level-tab-stop:4.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l5:level9
{mso-level-tab-stop:4.5in;
mso-level-number-position:left;
text-indent:-.25in;}
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="blue" vlink="purple" style="word-wrap:break-word">
<div class="WordSection1">
<p class="MsoNormal">Hi Dimitris,<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">I don’t accept that IT audit will not be used. The reason is that the ballot will remove software keys from non-EV code signing certificates. This is a new requirement and will impact the majority of the certificates and the Subscribers.
In addition, there was no requirement to check how Subscriber keys were generated or non-EV code signing certificates, another new requirement.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">I don’t think that a CA or Qualified Auditor can audit a bank of HSMs in production, HA and DR modes for all the keys which a software developer will need for the next undefined period of time. They can only look at the past. I understand
that you can ship a token with more than one key, but the HSM might have thousands or millions of keys required for generation on-demand.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Option 5 Cloud-based protection is NOT Option 7 Signing Service protection. Cloud-based protection will allow a Subscriber to use an HSM from AWS. Signing Service protection has many requirements in the CSBRs, which currently includes an
audit report. I assume that a CA will provide a Signing Service or could be similar to a TSP providing QSCD key generation and signing.
<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Option 5 states, “The Subscriber provides a suitable report from the cloud-based key protection solution subscription and resources configuration protecting the private key in a suitable hardware crypto module meeting the requirements specified
in section 16.3.1.” This is essentially a subscription agreement and not an audit report.<o:p></o:p></p>
<p class="MsoNormal"><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> Dimitris Zacharopoulos (HARICA) <dzacharo@harica.gr>
<br>
<b>Sent:</b> Thursday, November 18, 2021 1:58 AM<br>
<b>To:</b> Bruce Morton <Bruce.Morton@entrust.com>; cscwg-public@cabforum.org; Ian McMillan <ianmcm@microsoft.com><br>
<b>Subject:</b> Re: [Cscwg-public] [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" style="margin-bottom:12.0pt"><o:p> </o:p></p>
<div>
<p class="MsoNormal">On 17/11/2021 8:56 μ.μ., Bruce Morton wrote:<o:p></o:p></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal">Hi Dimitris,<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">Regarding this statement, “I see that you probably missed my comment for removing option 4. (a suitable IT audit, etc). Are there any objections to removing that problematic option?”<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">The concern I have and has been raised on a call is if a customer has purchased a server HSM, which does not support key attestation, what is the CAs alternative to verify that the many keys have been generated on the HSM?<o:p></o:p></p>
</blockquote>
<p class="MsoNormal"><br>
This is covered under option 6.<br>
<br>
<i>" 6. The CA or a Qualified Auditor witnesses the key creation in a suitable hardware crypto module solution including a cloud-based key generation and protection solution. "
</i><br>
<br>
<br>
<o:p></o:p></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">I do understand that this is a problematic option, but I do not see another option for the above use case. We might be better suited to provide more information on the IT audit. Here are some ideas:<o:p></o:p></p>
<ol style="margin-top:0in" start="1" type="1">
<li class="MsoListParagraph" style="margin-left:0in;mso-list:l5 level1 lfo3">Form audit letter included in the CSBRs<o:p></o:p></li><li class="MsoListParagraph" style="margin-left:0in;mso-list:l5 level1 lfo3">Signed by a verified identity, such as a Contract Signer<o:p></o:p></li><li class="MsoListParagraph" style="margin-left:0in;mso-list:l5 level1 lfo3">Audit letter Includes a warranty that all keys for code signing certificates requested will be generated on the HSM<o:p></o:p></li><li class="MsoListParagraph" style="margin-left:0in;mso-list:l5 level1 lfo3">Audit includes crypto device make, model, serial number and picture of serial number<o:p></o:p></li><li class="MsoListParagraph" style="margin-left:0in;mso-list:l5 level1 lfo3">Etc.
<o:p></o:p></li></ol>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">I think we see that the current environment has limited USB tokens which support both 3072/4096-bit RSA and key attestation. We also see that many server HSMs do not support key attestation. It looks like the ecosystem needs to evolve a
little longer before we can make our requirements perfect.<o:p></o:p></p>
</blockquote>
<p class="MsoNormal"><br>
As explained in previous discussions, there is no "IT audit" today that can remotely attest that an operating environment achieves the levels of security described in 16.3.1 (i.e. FIPS 140-2 level 2 or EAL 4+). I believe your use case is perfectly covered with
the new option 6.<br>
<br>
<br>
<o:p></o:p></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">Also, I don’t see that option 4 IT audit is any more problematic than option 5 a cloud provider subscription agreement.<o:p></o:p></p>
</blockquote>
<p class="MsoNormal"><br>
The "cloud-based key protection solution" (or a "signing service key protection solution") will include an audit report that describes that the solution actually uses HSMs certified according to 16.3.1. The CA will review this audit report, ensure that the
solution is compliant with 16.3.1 and then allow the Subscriber to use that service. Actually, 5 is very similar to 7, which is why I am suggesting we merge the "cloud-based solution" and the "signing service".<br>
<br>
Dimitris.<br>
<br>
<br>
<o:p></o:p></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">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>Dimitris Zacharopoulos (HARICA) via Cscwg-public<br>
<b>Sent:</b> Wednesday, November 17, 2021 1:22 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> Re: [Cscwg-public] [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" style="margin-bottom:12.0pt"> <o:p></o:p></p>
<div>
<p class="MsoNormal">On 17/11/2021 7:01 μ.μ., Ian McMillan 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 Dmitris, </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">This is not too painful.
</span><span style="font-family:"Segoe UI Emoji",sans-serif">😊</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">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>
</blockquote>
<p class="MsoNormal"><br>
Thanks for clarifying.<br>
<br>
<br>
<br>
<o:p></o:p></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<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>
</blockquote>
<p class="MsoNormal"><br>
I believe this is too prescriptive. I don't think we can describe these specific options in a public standards document. That's why the term "signing service" and "cloud-based provider" must be described in terms of functional expectations. Who knows what options
will be available in 2-5 years, or whether Microsoft, Amazon, Google and others will change their models and call these options something different than "subscription".<br>
<br>
<br>
<br>
<o:p></o:p></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<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 lfo6">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>
</blockquote>
<p class="MsoNormal"><br>
I don't disagree with that statement, although we do need to discuss and document their differences and even describe their functions in a clear and unambiguous way. The term "cloud" is overloaded and has been used in this industry to mean very different things
depending on the context.<br>
<br>
<br>
<br>
<o:p></o:p></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<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>
</blockquote>
<p class="MsoNormal"><br>
To help with the comparison, let me repeat the text here:<br>
<br>
<i>"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"</i><br>
<br>
The current wording is limiting the key-pairs to just <b>one key-pair</b> (singular) when the CA can ship more than one key-pairs (for future use). I also wanted to avoid the case where CAs generate keys outside of these hardware modules (via software because
it's faster) and then import them into crypto-modules and ship them to Subscribers.<br>
<br>
I see that you probably missed my comment for removing option 4. (a suitable IT audit, etc). Are there any objections to removing that problematic option?<br>
<br>
<br>
<br>
<br>
<o:p></o:p></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<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>
</blockquote>
<p class="MsoNormal"><br>
I believe this was discussed during our last call and the plan was for a roadmap that would ultimately remove this "any other method" option. Until that time, CAs would need to disclose their "any other methods" to the CABF until a certain date (Sep 1, 2022
seems fine with me), so the WG can evaluate the security of that method and either include or reject it. I think we're in total agreement here :)<br>
<br>
<br>
<br>
<o:p></o:p></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<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>
</blockquote>
<p class="MsoNormal"><br>
Let me know how you feel about the other changes. To summarize:<br>
<br>
In section 16.3.2:<o:p></o:p></p>
<ol start="1" type="1">
<li class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0 level1 lfo9">
Update option 1 to allow more keys to be shipped and keys generated <b>in</b> crypto-devices instead of outside and then imported<o:p></o:p></li><li class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0 level1 lfo9">
Removal of option 4<o:p></o:p></li></ol>
<p>We will probably need some more analysis comparing "signing service" vs "cloud provider" to get a better feeling of the functional differences and adjust accordingly.<o:p></o:p></p>
<p> <o:p></o:p></p>
<p>Thanks,<o:p></o:p></p>
<p>Dimitris.<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal"><i>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.</i>
<o:p></o:p></p>
</blockquote>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</body>
</html>