[ksk-change] Keeping two KSK keys long term

[Bolivar, Al]

Mike,

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.

Have a good weekend.

Al

On Oct 3, 2014, at 12:11, Michael StJohns <msj at nthpermutation.com<mailto:msj at nthpermutation.com>> wrote:

On 10/2/2014 4:01 PM, Bolivar, Al wrote:

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?

(Just for clarification are you talking FIP 140-2 level 4 or something in the "maybe soon to be published FIPS 140-4" standard?)


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:


  *   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.
  *   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.
  *   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.
  *   A system that ensures the data that the remote signers agreed could be signed is actually the data signed.
  *   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)

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.

Mike



The worst thing that could happen is they say no.



Thanks,

Al





On 10/2/14, 2:06 PM, "Michael StJohns" <msj at nthpermutation.com><mailto:msj at nthpermutation.com> wrote:



On 10/2/2014 1:42 PM, Bolivar, Al wrote:


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


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
ksk-rollover at icann.org<mailto:ksk-rollover at icann.org>
https://mm.icann.org/mailman/listinfo/ksk-rollover






-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/ksk-rollover/attachments/20141004/01ddeb73/attachment.html>