<br><tt><font size=2>Rickard Bellgrim wrote on 11/24/2009 08:28:10 AM:<br>
<br>
> Hi</font></tt>
<br><tt><font size=2>>  </font></tt>
<br><tt><font size=2>> I remember a discussion we had in Utrecht regarding
the wrapping <br>
> functions in PKCS#11. If a key is marked as extractable, you can <br>
> export the key encrypted and then import it into another HSM. You
<br>
> must first have a shared symmetric key in each HSM.</font></tt>
<br><tt><font size=2>>  </font></tt>
<br><tt><font size=2>> We currently have the extractable attribute set
to false.</font></tt>
<br><tt><font size=2>> </font></tt><a href=http://trac.opendnssec.org/browser/trunk/OpenDNSSEC/libhsm/src/libhsm.c#L1907><tt><font size=2>http://trac.opendnssec.org/browser/trunk/OpenDNSSEC/libhsm/src/libhsm.c#L1907</font></tt></a>
<br><tt><font size=2>>  </font></tt>
<br><tt><font size=2>> We should still have the keys marked as sensitive,
so that the key <br>
> material cannot be revealed in plain text. But my question is <br>
> whether we should have the key extractable or not?</font></tt>
<br>
<br><tt><font size=2>By default, no. Default should be to have it not exportable.
Flipping the 'exportable bit' must also be a one way function. You can
switch from exportable to not exportable, but not from not-exportable to
exportable.</font></tt>
<br>
<br><tt><font size=2>In general, keys only need to be exportable when an
HSM roll is due. By that time, a key can be generated that is exportable.</font></tt>
<br><tt><font size=2> </font></tt>
<br><tt><font size=2>> Just want to discuss this topic, so that we do
not lock the user <br>
> down. Or is it better to protect against a potential threat of leaking
keys?</font></tt>
<br>
<br><tt><font size=2>IMHO it is not a mutual exclusive choice. We need
to protect against a potential threat of leaking keys all the time, but
only enable the user to export the key as an explicit conscious choice.</font></tt>
<br>
<br><tt><font size=2>Roy</font></tt>