Mi comments inline
Robert Relyea wrote:
> Subrata Mazumdar wrote:
>> Bob,
>> I implemented the importing and exporting of private key from PKCS#8
>> file using NSS API.
>> Here is what I found based on my testing :
>>
>> Using Mozilla NSS API, I can only import/export private key in PKCS#8
>> format with "PKCS12 V2 PBE With SHA1 And 3KEY Triple DES-cbc"
>> encryption algorithm.
>> I would like to support other encryption algorithms supported by
>> OpenSSL.
>>
> Are you using NSS 3.11 or 3.12. We added PKCS 5 v2 (needed for the
> other algorithms in 3.12).
> I'm pretty sure Elio got support for other keys working.
Yes, I was able to import using pkcs #12 and also from PEM files using
DES-EDE3-CBC (-des3 option) encryption as Subrata reports. I didn't try
other algorithms as this one was the only one I needed at the time. As
expected, I can't import from PEM files with unencrypted keys and that
is by NSS's design.
My code is in the crypto-utils package, specifically the keytutil
application, in fedora in the development branch.
Subrata, I help can point you to how to download it and guide you
through it if you so desire.
>> Using NSS-API, I can import private key from OpenSSL generated PEM
>> file (openssl rsa ...) with
>> DES-EDE3-CBC (-des3 option) encryption only.
>> But, I cannot read the private key from Mozilla NSS API generated PEM
>> file using the OpenSSL API
>> because NSS uses 16 byte salt for encryption but the OpenSSL API
>> expects 8 byte salt.
>>
> Hmm, sounds like a bug in openSSL, though I do remember tripping over
> this. I believe there is an NSS interface that lets you set the salt
> length specifically when generating the PBE (at least in NSS 3.12).
>
> bob
>> --
>> Subrata
>>
>>
>> Robert Relyea wrote:
>>
>>> Subrata Mazumdar wrote:
>>>
>>>> Nelson,
>>>> thanks very much for the clear answer - I did not realize that the
>>>> Mozilla NSS does not support PKCS#8.
>>>> I also agree with you that PKCS#12 format is the right way to
>>>> import/export keys.
>>>> The problem is that a large number of OpenSSL based applications
>>>> still use separate files
>>>> for private key and public key cert. Actually, the problem is even
>>>> worse - some of the applications
>>>> use unencrypted private key or OpenSSL specific encrypted PEM file
>>>> (generated using 'openssl rsa' command).
>>>> Any way, thanks once again.
>>>>
>>> I believe Elio has some sample code that can import and export
>>> *wrapped* PKCS #8 keys stored in Pem format. Unwrapped keys are not
>>> considered safe. To support them you would need to manually
>>> encrypt/decrypt the wrapped keys. NSS does not have an interface to
>>> release unencrypted keys and applications are strongly discouraged
>>> from using them. Even openssl prefers encrypted to unencrypted keys.
>>>
>>> bob
>>>
>>>> --
>>>> Subrata
>>>>
>>>> Nelson Bolyard wrote:
>>>>
>>>>
>>>>> Subrata Mazumdar wrote, On 2008-09-26 07:19:
>>>>>
>>>>>> Hi,
>>>>>> I am having problem in reading PKCS#8 file generated by OpenSSL
>>>>>> command line tool ("opnessl pkcs8").
>>>>>>
>>>>> Officially, import and export of pkcs#8 files is not supported in
>>>>> NSS.
>>>>> You may or may not be able to get it to work, but because of the
>>>>> security concerns of PKCS#8 files, NSS does not support them.
>>>>>
>>>>> PKCS#12 is the supported way to import or export private keys and
>>>>> their
>>>>> related certificates. If you have a problem with PKCS#12, you can get
>>>>> support from the NSS team.
>>>>>
>>>>> PKCS#12 is the one universally implemented private key transport
>>>>> method.
>>>>> OpenSSL also supports PKCS#12, and so does Windows.
>>>>>
>>>> _______________________________________________
>>>> dev-tech-crypto mailing list
>>>> [email protected]
>>>> https://lists.mozilla.org/listinfo/dev-tech-crypto
>>>>
>> _______________________________________________
>> dev-tech-crypto mailing list
>> [email protected]
>> https://lists.mozilla.org/listinfo/dev-tech-crypto
>>
>
_______________________________________________
dev-tech-crypto mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-crypto
