<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
</head>
<body dir="auto">
<div>Mike,</div>
<div><br>
</div>
<div>I don't have an answer to your question, but I can certainly find out from the vendor. I will share that when I get the answer.</div>
<div><br>
</div>
<div>Have a good weekend.</div>
<div><br>
</div>
<div>Al</div>
<div><br>
On Oct 3, 2014, at 12:11, Michael StJohns <<a href="mailto:msj@nthpermutation.com">msj@nthpermutation.com</a>> wrote:<br>
<br>
</div>
<blockquote type="cite">
<div>
<div class="moz-cite-prefix">On 10/2/2014 4:01 PM, Bolivar, Al wrote:<br>
</div>
<blockquote cite="mid:D0532727.17825%25abolivar@verisign.com" type="cite">
<pre wrap="">Mike,
SafeNet is working with IBM to come up with a FIPS 140 level 4 HSM.
I don't know what the current state of development is but do you think
it's worth asking them if they could incorporate a trusted path
authentication that has a bit more flexibility?</pre>
</blockquote>
(Just for clarification are you talking FIP 140-2 level 4 or something in the "maybe soon to be published FIPS 140-4" standard?)<br>
<br>
<br>
The idea of a more flexible authentication system is a good start. But what I'm really thinking needs to happen is a system that supports expressing policy more like:<br>
<br>
<ul>
<li>A CA key that will only sign properly formatted X.509 certificates and ensures that the signed certificate has a unique serial number and has appropriate validity info, and infrastructure extensions (e.g. SKI extension, AKI extension, appropriate policy
bits) - things that are normally enforced outside the HSM boundary these days. </li><li>A wrapping key that can wrap and unwrap AES Key Wrap mode material where the material has its own set of attached policy bits (e.g. a secret key which can only be used for KDFs) and protect that unwrapped key appropriately.
</li><li>A signing key that will only sign a properly formatted DNSKEY RRSet and only if it sees that N other known keys have signed it.
</li><li>A system that ensures the data that the remote signers agreed could be signed is actually the data signed.
</li><li>A more comprehensive set of threshold key systems (e.g. Shamir's plus others) both for partial signatures and for information retrieval/escrow (think of taking Shoup's scheme that I mentioned and publish the public key - data could be encrypted using that
key, but N of K private key holders would need to come together to retrieve that encrypted data -think further about that with respect to backup key generation)
</li></ul>
<br>
I mentioned Javacard Connected as there's a lot of experience with similar things in smart cards. I can't quite figure out why I can't buy an HSM that does what a smart card can be programmed to do.<br>
<br>
Mike<br>
<br>
<blockquote cite="mid:D0532727.17825%25abolivar@verisign.com" type="cite">
<pre wrap="">
The worst thing that could happen is they say no.
Thanks,
Al
On 10/2/14, 2:06 PM, "Michael StJohns" <a class="moz-txt-link-rfc2396E" href="mailto:msj@nthpermutation.com"><msj@nthpermutation.com></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">On 10/2/2014 1:42 PM, Bolivar, Al wrote:
</pre>
<blockquote type="cite">
<pre wrap="">I would like to add that I support the addition of another vendor.
Tomofumi and I spoke to another vendor about introducing a competing
FIPS
140-2 level 4 HSM. In my opinion having other choices will be positive.
Thanks,
Al
</pre>
</blockquote>
<pre wrap="">One of my pet peeves with the HSM vendors is that none of them provide
more than rudimentary policy controls on the use of keys. I keep
waiting for someone to make an HSM that implements either the Javacard
Connected standards or something similar so I can define a programmatic
policy wrapper more comprehensive than "I need a PIN to use it" "I need
two PINs to use it" "I need a smart card to use it" etc. I can do this
on a smart card, why is it so hard to do it on a big iron HSM?
Mike
_______________________________________________
ksk-rollover mailing list
<a class="moz-txt-link-abbreviated" href="mailto:ksk-rollover@icann.org">ksk-rollover@icann.org</a>
<a class="moz-txt-link-freetext" href="https://mm.icann.org/mailman/listinfo/ksk-rollover">https://mm.icann.org/mailman/listinfo/ksk-rollover</a>
</pre>
</blockquote>
<pre wrap="">
</pre>
</blockquote>
<br>
</div>
</blockquote>
</body>
</html>