Nelson B. Bolyard wrote:
> Robert Relyea wrote: > >>Steven T. Hatton wrote: >> >> >>>There seems to be a descrepency between the versions of certutil in the >>>meaning of the -k option of -R. The documentation indicates that switch >>>preceeds the key "short name". OTOH the -H option on the certutil from >>>the NSS 3.3.1 indicates the -k distinguishes between rsa and dsa key >>>types. Does this mean I can no longer specify the key to use when >>>generating a request? >>> >>Yes. Short-name was an unsupportable hack we removed before we even open >>sourced NSS. Certutil now used the module that all the rest of our apps >>use: generate the key when you make the request. >> > > One of the requests commonly expressed by users in this newsgroup is the > ability to import key pairs into NSS and then generate a cert request > using the existing key pairs. The old "short name" scheme may indeed have > been an "unsupportable hack", but there needs to be some way to do it. There's not problem referencing a private key programmatically if you have the public key. If the problem is to import the keypairs then generate a cert request, that feature can be added to certutil. The difficulty is generating a key from the command line, then later trying to reference that key before a cert for that key is installed. One possibility is to include a public key file which you can reference later, and maybe a command to generate these files all the orphanned keys. The short name scheme would not have solve this problem BTW because there is currently no command line way import a keypair into NSS. bob > > -- > Nelson Bolyard >
