<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:Helvetica;
panose-1:2 11 6 4 2 2 2 2 2 4;}
@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;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman",serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:#1F497D;}
.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;}
--></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">
<div class="WordSection1">
<p class="MsoNormal"><a name="_MailEndCompose"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">Afternoon everyone,<o:p></o:p></span></a></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">Unofficial response from a POC at NIST.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal">One option would be to try to find a FIPS 140 validated module that has been validated for 4096-bit RSA signature generation. As noted, it would have to be an older module. However, according to
<a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__csrc.nist.gov_groups_STM_cavp_documents_dss_rsanewval.html&d=DQMD-g&c=19TEyCb-E0do3cLmFgm9ItTXlbGQ5gmhRAlAtE256go&r=v6QfMBgWaMWhsB_PpBwwzxPtUwSffCWXSAR0gp0RFbY&m=KN8HhW0WEBuvSMiTkEnQZSLpF-Ub76Wqwy5C7PGeRkk&s=6jgA5x5mNPj0RQY3Li5BIWyswn_uOennnasUUOWbzK4&e=">
http://csrc.nist.gov/groups/STM/cavp/documents/dss/rsanewval.html</a>, implementations of FIPS 186-2 key and signature generation are being allowed in algorithm implementation of some modules undergoing revalidation. In the future, this will be less of an issue,
as NIST is planning to allow the use of longer RSA key sizes again at some point in the future. Unfortunately, I don't have a time line for when the change will be made to allow CAVP to start validating 4096-bit RSA key generation and signature generation
again.<span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal">A cryptographic module may implement 4096-bit key generation and signature generation even if its implementation cannot be validated at those key lengths. So, given that the Baseline Requirements do not have to conform to FIPS, using a
FIPS 140 Level 3 module that implements 4096-bit RSA, but has not been validated for that key length may be an option. If the module has an RSA algorithm certificate for shorter key lengths, and uses the same code for key generation and for signature generation
for 4096-bit keys as for the validated key lengths, then there is some confidence in the implementation.<span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p></o:p></span></p>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal">Also, Section 6.2.7 is about key protection, and those requirements are independent of the lengths of the keys used. FIPS 140 Level 3 validated modules are required to have both physical and logical protections for the keys that are stored
within them. While an HSM may not store private keys long-term, it would need to protect the private key while in use. In addition, the HSM may have a long-term symmetric key that it uses to wrap/unwrap the private keys, and this symmetric key would need to
be well protected as anyone obtaining that key along with a copy of the encrypted private key could obtain the plaintext private key.<span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">Ken<o:p></o:p></span></p>
</div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><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><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">From:</span></b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"> philliph@comodo.com [mailto:philliph@comodo.com]
<br>
<b>Sent:</b> Tuesday, October 11, 2016 14:06<br>
<b>To:</b> Robin Alden <robin@comodo.com><br>
<b>Cc:</b> Peter Bowen <pzb@amzn.com>; CABFPub <public@cabforum.org><br>
<b>Subject:</b> Re: [cabfpub] CA key generation, storage, and FIPS<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">This likely dates from the time that NIST had decided to EOL the RSA algorithm and push everyone towards Elliptic Curves. Now that Quantum is looming as a more likely threat than a new factoring technique they are rowing back in the opposite
direction.<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">FIPS can be changed. I suggest that CABForum make an official request for such a change.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">In the longer term, what we really need is to decouple from the FIPS. WebPKI is a much bigger use case than US Government crypto these days and it is likely to be moving in different directions.<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal">On Oct 11, 2016, at 8:12 AM, Robin Alden via Public <<a href="mailto:public@cabforum.org">public@cabforum.org</a>> wrote:<o:p></o:p></p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal"><span style="font-size:13.5pt;font-family:"Helvetica",sans-serif">Hi Peter,<br>
<br style="font-variant-caps: normal;orphans: auto;text-align:start;widows: auto;-webkit-text-stroke-width: 0px;word-spacing:0px">
<br>
</span><o:p></o:p></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal" style="margin-bottom:13.5pt"><span style="font-size:13.5pt;font-family:"Helvetica",sans-serif">-----Original Message-----<br>
Peter Bowen said on 30 September 2016<br>
In reviewing the Baseline Requirements and certain trust store<br>
requirements, I ran into a set of questions I’m hoping someone can answer.<br>
<br>
The BRs have several sections that address CA key protection. The ones I<br>
think are relevant are below:<br>
<br>
"The CA SHALL protect its Private Key in a system or device that has been<br>
validated as meeting at least FIPS 140 level 3 or an appropriate Common<br>
Criteria Protection Profile or Security Target, EAL 4 (or higher), which includes<br>
requirements to protect the Private Key and other assets against known<br>
threats.” (6.2.7)<br>
<br>
"Protection of the CA Private Key outside the validated system or device<br>
specified above MUST consist of physical security, encryption, or a<br>
combination of both, implemented in a manner that prevents disclosure of<br>
the CA Private Key. The CA SHALL encrypt its Private Key with an algorithm<br>
and key-length that, according to the state of the art, are capable of<br>
withstanding cryptanalytic attacks for the residual life of the encrypted key or<br>
key part.” (6.2)<br>
<br>
"The CA Private Key SHALL be backed up, stored, and recovered only by<br>
personnel in trusted roles using, at least, dual control in a physically secured<br>
environment.” (5.2.2)<br>
<br>
The challenge I’ve run into is that the US NIST, which publishes the FIPS<br>
series, has specified that only lengths of 512, 1024, and 1536 bits shall be<br>
used for p and q in RSA private keys. This results in public key sizes of 1024,<br>
2048, and 3072 bits. Due to this, no FIPS 140 validations are being issued<br>
which include RSA with 4096-bit public keys.<br>
<br>
However, 4096-bits is the minimum size required for certain cases by trust<br>
stores and, as far as I know, it accepted by all trust stores.<br>
<br>
How do we rationalize this with 6.2.7, given that no module certified more<br>
recently than Jan 2014 can generate 4096-bit RSA keys or sign using 4096-bit<br>
RSA keys in FIPS mode?<br>
<br>
Is the correct interpretation that you need the cryptographic module to have<br>
been certified as meeting FIPS 140 Level 3 but the CA can operate it in non-<br>
FIPS mode?<o:p></o:p></span></p>
</blockquote>
<p class="MsoNormal"><span style="font-size:13.5pt;font-family:"Helvetica",sans-serif"><br>
That would certainly be a very convenient interpretation, but I don't think it can be correct.<br>
If an HSM has a FIPS mode and a non-FIPS mode, I think we should use the FIPS mode to be compliant.<br>
Presumably if it is operated in non-FIPS mode all bets concerning the security of the HSM are off. <br>
<br>
I can see Jos's point that it should be possible to do "due diligence to ensure that FIPS validation remains current even when not in use directly, and that operating in non-FIPS mode doesn't meaningfully compromise the security of the key material and HSM",
but that sounds a 'Hard Thing', and not something that a common-or-garden WebTrust (or ETSI) auditor would be keen to opine upon, let alone for a humble CA to do so.<br>
<br>
Perhaps we should be talking with HSM vendors about how they achieve recent FIPS 140-2 validation whilst supporting RSA 4096. <br>
Do NIST check for 4096 bit RSA implementations and reject them where they find them, or do they merely not test key sizes > 3072?<br>
<br style="font-variant-caps: normal;orphans: auto;text-align:start;widows: auto;-webkit-text-stroke-width: 0px;word-spacing:0px">
<br>
</span><o:p></o:p></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal"><span style="font-size:13.5pt;font-family:"Helvetica",sans-serif">Can the CA use the cryptographic module to encrypt the private key, using<br>
AES-256 or another FIPS approved algorithm, for storage but unwrap/decrypt<br>
to do the generation and signature creation in a non-validated device (as<br>
implied in 6.2)?<o:p></o:p></span></p>
</blockquote>
<p class="MsoNormal"><span style="font-size:13.5pt;font-family:"Helvetica",sans-serif"><br>
I don't think it should. <br>
If the non-validated device has the key available to it in order for it to create a signature then I think you have to demonstrate to your auditor how the key is protected while in that non-validated device.<br>
The AES-256 encryption while the key is in motion sounds good, but only if the KEK is itself protected in accordance with 6.2 - which I don't think would be the case if it is available to an online non-validated device.<br>
<br>
We had discussions in past years about using CA keys outside validated devices, i.e. other than in HSMs that meet 6.2.7. <br>
It is probably possible to do it securely, but it's not something we can codify in a few paragraphs without reference to reasonably widely accepted standards such as FIPS 140-2.<br>
<br>
I agree with Jos that it would be good to see something from FIPS that extends 180-2 to longer key lengths.<br>
<br style="font-variant-caps: normal;orphans: auto;text-align:start;widows: auto;-webkit-text-stroke-width: 0px;word-spacing:0px">
<br>
</span><o:p></o:p></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal"><span style="font-size:13.5pt;font-family:"Helvetica",sans-serif"><br>
And what does it mean to protect a private key _in_ a validated system or<br>
device, anyway? Some HSMs are not designed to store keys, just<br>
wrap/unwrap and use keys.<o:p></o:p></span></p>
</blockquote>
<p class="MsoNormal"><span style="font-size:13.5pt;font-family:"Helvetica",sans-serif"><br>
There isn't a requirement to store CA keys _in_ an HSM.<br>
My understanding is that the 'validated system' reasonably includes storage of CA keys in a 'Security World' on disk or elsewhere encrypted to comply with 6.2 provided that decryption of that Security World, or the extraction of the CA keys in any form, is
not possible other than through the HSM as designed and using its FIPS-validated capabilities .<br>
I'm aware that the term 'Security World' is used by one HSM maker in particular, but the concept of an encrypted store being logically 'within' the validated system is common across a number of HSMs.<br>
<br>
Regards<br>
Robin Alden<br>
<br>
_______________________________________________<br>
Public mailing list<br>
</span><a href="mailto:Public@cabforum.org"><span style="font-size:13.5pt;font-family:"Helvetica",sans-serif">Public@cabforum.org</span></a><span style="font-size:13.5pt;font-family:"Helvetica",sans-serif"><br>
</span><a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__cabforum.org_mailman_listinfo_public&d=DQMFaQ&c=19TEyCb-E0do3cLmFgm9ItTXlbGQ5gmhRAlAtE256go&r=v6QfMBgWaMWhsB_PpBwwzxPtUwSffCWXSAR0gp0RFbY&m=BhFEYUZYnTg02o9iobHhYKVoWn1YH9yWXW_7zZgqwUY&s=EoPRexeAcWZemCFixY9VR9WtZA2TEOt-KztzyVn9zcQ&e="><span style="font-size:13.5pt;font-family:"Helvetica",sans-serif">https://cabforum.org/mailman/listinfo/public</span></a><o:p></o:p></p>
</div>
</blockquote>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
</div>
NOTICE: Protiviti is a global consulting and internal audit firm composed of experts specializing in risk and advisory services. Protiviti is not licensed or registered as a public accounting firm and does not issue opinions on financial statements or offer
attestation services. This electronic mail message is intended exclusively for the individual or entity to which it is addressed. This message, together with any attachment, may contain confidential and privileged information. Any views, opinions or conclusions
expressed in this message are those of the individual sender and do not necessarily reflect the views of Protiviti Inc. or its affiliates. Any unauthorized review, use, printing, copying, retention, disclosure or distribution is strictly prohibited. If you
have received this message in error, please immediately advise the sender by reply email message to the sender and delete all copies of this message. Thank you.
</body>
</html>