<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<br>
<br>
<div class="moz-cite-prefix">On 17/11/2021 7:01 μ.μ., Ian McMillan
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:BY5PR00MB0692A0E72C393599CADF2498C49A9@BY5PR00MB0692.namprd00.prod.outlook.com">
<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-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;}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;}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="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.
</p>
</div>
</blockquote>
<br>
Thanks for clarifying.<br>
<br>
<blockquote type="cite"
cite="mid:BY5PR00MB0692A0E72C393599CADF2498C49A9@BY5PR00MB0692.namprd00.prod.outlook.com">
<div class="WordSection1">
<p class="MsoNormal"><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.
</p>
</div>
</blockquote>
<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>
<blockquote type="cite"
cite="mid:BY5PR00MB0692A0E72C393599CADF2498C49A9@BY5PR00MB0692.namprd00.prod.outlook.com">
<div class="WordSection1">
<p class="MsoNormal"><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" type="1" start="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.
</p>
</div>
</blockquote>
<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>
<blockquote type="cite"
cite="mid:BY5PR00MB0692A0E72C393599CADF2498C49A9@BY5PR00MB0692.namprd00.prod.outlook.com">
<div class="WordSection1">
<p class="MsoNormal"><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).
</p>
</div>
</blockquote>
<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:</i><i><br>
</i><i> </i><i><br>
</i><i> "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>
<blockquote type="cite"
cite="mid:BY5PR00MB0692A0E72C393599CADF2498C49A9@BY5PR00MB0692.namprd00.prod.outlook.com">
<div class="WordSection1">
<p class="MsoNormal"><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.
</p>
</div>
</blockquote>
<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>
<blockquote type="cite"
cite="mid:BY5PR00MB0692A0E72C393599CADF2498C49A9@BY5PR00MB0692.namprd00.prod.outlook.com">
<div class="WordSection1">
<p class="MsoNormal"><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.</p>
</div>
</blockquote>
<br>
Let me know how you feel about the other changes. To summarize:<br>
<br>
In section 16.3.2:<br>
<ul>
<li>Update option 1 to allow more keys to be shipped and keys
generated <b>in</b> crypto-devices instead of outside and then
imported</li>
<li>Removal of option 4</li>
</ul>
<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.</p>
<p><br>
</p>
<p>Thanks,</p>
<p>Dimitris.<br>
</p>
<br>
</body>
</html>