[ksk-change] Keeping two KSK keys long term

[Michael StJohns]

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

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