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.
You are now arguing at two different levels: the PKCS#11 API, and what is stored on the HSM. I would agree that if it is possible to retrieve the public exponent from the device, then the PKCS#11 should be able to present it as part of a CKO_PUBLIC_KEY or as part of CKO_PRIVATE_KEY. If it is not possible to retrieve it from the device, the PKCS#11 could retrieve it from a file stored externally. An smart card example of this the PIV card defined by NIST 800-73 series of documents. http://csrc.nist.gov/publications/nistpubs/800-73-3/sp800-73-3_PART2_piv-card-applic-card-common-interface.pdf There are only two card commands involving keys: GENERAL AUTHENTICATICATE and GENERATE ASYMMETRIC KEY PAIR. You only get the exponent and modules when the key pair is generated on the card. There are no command to read them from the card or to know what size the key is! The assumption is the size, exponent and modulus will be stored in the certificate. The OpenSC PKCS#11 software will get the size, exponent and modules from the certificate and emulate a CKO_PUBLIC_KEY and CKO_PRIVATE_KEY for the user. (NIST does allow individual card vendors to add additional commands to use during card initialization. Thus signature keys can be created off the card escrowed and written to card. Card vendors would then work with card management software vendors to initialize their cards. But any client code should only use the common commands defined in 800-73.) NIST 800-73-3, released last month, extends the 800-73 series by defining how older signature keys can be stored on the card, along with *SOME* of the older certificates. In the case where storage on the card is tight, older certificates can be stored off the card. The card will have a "Key History Object" with an offCardCertURL to find these certificates. The OpenSC support is currently at 800-73-2. I intend to add support for 800-73-3 and will have to add some way so the OpenSC libs will fetch the offCardCertURL if needed, or require that it be prefetched and stored as a file accessable to the OpenSC libs, so PKCS#11 calls can use any of the older signature keys. > 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. So I would argue OpenSC card drivers and libraries should be as flexible as possible and try and present a full PKCS#11 representation using whatever information is available from the device or other sources, including external files if needed. > > // Rickard > > > ------------------------------------------------------------------------ > > _______________________________________________ > opensc-devel mailing list > opensc-devel@lists.opensc-project.org > http://www.opensc-project.org/mailman/listinfo/opensc-devel -- Douglas E. Engert <deeng...@anl.gov> Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
