<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content="text/html; charset=gb2312" http-equiv=Content-Type>
<STYLE>
BLOCKQUOTE {
MARGIN-TOP: 0px; MARGIN-BOTTOM: 0px; MARGIN-LEFT: 2em
}
OL {
MARGIN-TOP: 0px; MARGIN-BOTTOM: 0px
}
UL {
MARGIN-TOP: 0px; MARGIN-BOTTOM: 0px
}
P {
MARGIN-TOP: 0px; MARGIN-BOTTOM: 0px
}
BODY {
LINE-HEIGHT: 1.5; FONT-FAMILY: ËÎÌå; COLOR: #000000; FONT-SIZE: 10.5pt
}
</STYLE>
<META name=GENERATOR content="MSHTML 8.00.6001.18702"></HEAD>
<BODY style="MARGIN: 10px">
<DIV>Hi all,</DIV>
<DIV> </DIV>
<DIV>We have been testing DNSSEC with OpenDNSSEC+SoftHSM, it has been working
well.</DIV>
<DIV>But recently we decided to buy a HSM to replace SoftHSM to do signing work
and</DIV>
<DIV>keys storage. After consulting with some of the HSM vendors here, we found
out </DIV>
<DIV>that almost no devices can cooperate with OpenDNSSEC. </DIV>
<DIV> </DIV>
<DIV>Take key generation for example, the vendors' HSM devices allow create keys
with </DIV>
<DIV>software API though they are both using PKCS#11, keys in HSM
devices must be </DIV>
<DIV>created manually with administrator permission and it is the same case
with removing </DIV>
<DIV>keys.</DIV>
<DIV> </DIV>
<DIV>And we also found out that HSM device do not support <TokenLabel>
which is used by</DIV>
<DIV>SoftHSM's slot, only KeyLabel is supported, that means
it designate a specific</DIV>
<DIV>key to do the signing work instead of the keys in a slot. </DIV>
<DIV> </DIV>
<DIV>In short, the HSM devices are designed not as flexible as OpenDNSSEC
supposed they</DIV>
<DIV>should be, there are lots of incompatible places.</DIV>
<DIV> </DIV>
<DIV>What should we do to avoid abandon using OpenDNSSEC? Are there any
possibility that</DIV>
<DIV>people can do their own programming work with your APIs if they
exist in order to</DIV>
<DIV>adapt with HSM devices?</DIV>
<DIV> </DIV>
<DIV>Are there any body ever met the problem as ours?</DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV>Best regards,</DIV>
<DIV>Stuart</DIV></BODY></HTML>