<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<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>
</body>
</html>