Rickard Bellgrim wrote: > Definately my recommendation. I'm also working with all the big HSM > vendors and you don't have to save space on any of them, at a minimum > you can store about one hundred objects in a single slot. So for PKI > purposes there is vast space available. None of the big HSM vendors > license per storage, it's simple one-time purchase price of the HSM > hardware (+ support costs that are a percentage of the price). > > Keep it simple :-) > > The SafeNet Luna HSM has a limitation to 1000 objects according to one of our > project member. We use the Sun SCA6000 and it has a bug in its software the > limits it to around 600 objects. > > DNSSEC is used as an security extension to DNS. In DNSSEC there are two types > of keys. KSK (Key Signing Key) and ZSK (Zone Signing Key). The KSK is a > stronger key and used for creating trust between the parent zone and the > current zone. ZSK is smaller which makes it faster to sign the rest of the > zone. You typically roll the KSK every other year. And the ZSK every quarter. > > We have no problem since we are only signing one DNS zone, which means at a > maximum 10 objects (Rolling the ZSK and rolling one of the overlapping KSKs. > All with both private and public key objects). > > However, the one using the SafeNet is responsible for a national university > network with around 300 zones. And if they decide to not share the keys > between the zones (there is a debate in the DNSSEC community on whether you > should do this or not), then they will have 1200 objects (each zone has a KSK > and ZSK, both with private and public key object). > > So you see, it is worth saving space. > > The same person is also a PKCS#11-expert. And he says that he has never seen > an implementation, which does not store the CKA_PUBLIC_EXPONENT in the > private key object. To save space in the smartcard, vendors usually store the > private and public key material in one space. If you remove the public key > object, then you still have the key material left for the private key object. > Thus making it possible to only have the private key object. Which complies > to the arguments that this list had one year ago, to let the pkcs11-tool only > save the private key object.
This seems like a special requirement. If you have special requirements and really know what you are doing, I'd say go for it, absolutely. As long as you're prepared for that it will work in you specific case, with specific components, and may, or may not, be compatible across different HSM vendors or PKCS#11 implementations. I'd argue that it will limit your choices, but if that's ok with you it's as good a solution as any. As long as you know what you are doing when going outside the regular tracks, and are prepared to spend the extra time on it. Good luck. Cheers, Tomas > > // Rickard > > > > ------------------------------------------------------------------------ > > _______________________________________________ > opensc-devel mailing list > [email protected] > http://www.opensc-project.org/mailman/listinfo/opensc-devel _______________________________________________ opensc-devel mailing list [email protected] http://www.opensc-project.org/mailman/listinfo/opensc-devel
