Wan-Teh Strange situation indeed. You export the function to generate public/private keys, but not a way to import the certificate to go with them. Then you allow the NSS utilities to use the required function, but not the rest of the world, since the rest of the world should only use the .dll. Since this function is quite basic, I doubt a need for something like it would never go away. Unless of course one had no need for certificates at all!
The thing I really find strange is several people have asked how to just use public/private keys and the answer was you should generate a "dummy" certificate to allow easy access to those keys. Then we are told there is no way to store the certificate, at least with the nss dll! However, it makes no difference I guess. The end result is to be able to associate a certificate to a key pair and store that cert on the token and in the certificate db. So, as long as the source is available, one could always just have their own "custom" API to do this. OpenSSL includes some very nice utilities to convert a DER certificate to the required format to be placed on the token. Ken "Wan-Teh Chang" <[EMAIL PROTECTED]> wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > Ian McGreer wrote: > > > > > They have be renamed with a prepended "__" to indicate something like, > > "this function is exported now but may not be in the future." > > > It's actually stronger than that. > > These functions are exported by nss3.dll only for the other > two NSS DLLs, ssl3.dll and smime3.dll. They should be > considered NSS internal. > > Wan-Teh >
