If using PKCS#11 I would personally not go down a path that is not commonly used. The common usage of smart cards and hardware security modules always stores both the private (as a sensitive object) and the public key (either as a public key or as an x.509 certificate). This works and is well tested and is sure to work across a wide range of smart cards and hardware security modules.
Why is this not suitable for OpenDNSSEC. Cheers, Tomas On 03/16/2010 01:40 PM, Rickard Bellgrim wrote: > > On 16 mar 2010, at 09.15, Andreas Jellinghaus wrote: > >> Am Dienstag 16 März 2010 08:28:32 schrieb Rickard Bellgrim: >>> But you still have access to the "public parts" of the private key. >> >> ok, I'm no expert here, so I can't say yes or know. >> >> But I know that some cards hide their private keys, so you need >> to login first, to see if some private key is on the card. > > I read some more in the PKCS#11 specification, and it actually says that only > the CKA_MODULUS and CKA_PRIVATE_EXPONENT is required to be stored by the > token. It is then up to the token if it wants to store the other attributes > of the private key object. > > You need CKA_MODULUS and CKA_PUBLIC_EXPONENT in order to create a public key > from the data in the private key. You can access these attributes if: > - The private key object is public. > - If the object is private, then the user needs to be logged in. > - And the token needs to store the attributes. > > OpenDNSSEC always login into the token, so that is no problem. But the > conclusion is that you cannot guarantee that the CKA_PUBLIC_EXPONENT of the > private key object is available. > > Is there any implementation that does not store the CKA_PUBLIC_EXPONENT? > > If so, then it clearly is a need of the public key object. The key might not > be generated on the same machine as it is used. > > Or another solution is that the application also writes the public key to > disc, when it is still available. And then you make sure that you have your > private key on a smartcard and the public key written on a paper. > > // Rickard > _______________________________________________ > opensc-devel mailing list > opensc-devel@lists.opensc-project.org > http://www.opensc-project.org/mailman/listinfo/opensc-devel _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
