Re: How to export private key using pk12util

[Nelson B Bolyard]

I wrote:
> The message to users was (and still is), if you want to export your
> private key, PKCS#11 is the answer.

er. make that #12.  Unlike PKCS#8, which for a long time (and maybe still
today) implied unencrypted storage of private keys, PKCS#12 has been
associated with encrypted storage of private keys from its beginning.
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: How to export private key using pk12util

[Nelson Bolyard]

Arshad Noor wrote, On 2009-04-23 20:11:
> Nelson Bolyard wrote:
>> The NSS team participated in the process of defining PKCS#12 precisely
>> to avoid the security trap of exporting private keys in PKCS#8 format.
>> Avoiding that trap is precisely why PKCS#12, and not PKCS#8, is THE only
>> format for private key transport supported by all of NSS, Microsoft and 
>> OpenSSL.
>
> Nelson,
> 
> I'm afraid PKCS#8 *does* allow for protecting private-keys with
> passwords, but you have to explicitly choose the ASN type when
> creating the file.  Details can be found at:
> 
> ftp://ftp.rsasecurity.com/pub/pkcs/ascii/pkcs-8.asc

Oh, I'm aware of that, and was aware of that while in the NSS team at
Netscape when PKCS#12 was being defined.  (NSS was known by another
name at that time.)

> It's possible that NSS chose to not support the export of the keys
> in PKCS#8 format for other reasons, but I don't believe it would be
> because it poses a security risk - the PKCS12 file is subject to the
> same risks as PKCS8 since it has the same level of protection: PBE
> using a 3DES key.

The story is that, at that time, it was extremely common for OpenSSL users
to store their private keys in PEM-encoded PKCS8 files that were NOT
encrypted.  OpenSSL made that encryption optional, and (I gather) most
OpenSSL users simply didn't bother with it.  So, at that time, OpenSSL users
expected PKCS8 files to be unencrypted.

The NSS team could have chosen to implement only the encrypted form of
PKCS8, and in fact, NSS DOES support the IMPORT of private keys from
PKCS8 files into PKCS#11 modules, but NSS does not create them (export)
and the browser does not expose the PKCS#8 import feature to its users.

As for "other reasons", at that time NSS was not an independent library
but was very much part of the browser.  The browser folks wanted to give
the user just one way to transport keys and their certificates securely
and keep them together.  PKCS#12 was the obvious candidate.  We could
have implemented exporting keys in PKCS#8 (it would be trivial), but we
chose not to do so, to promote secure practices.  The message to users
was (and still is), if you want to export your private key, PKCS#11 is
the answer.
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: How to export private key using pk12util

[Nelson B Bolyard]

Andriy Zakharchuk wrote, On 2009-04-24 02:39:

>>> <0> AAA-update-key
>>> <1> BBB-update-key
>>> <2> CCC-update-key
>> It that literally what you see?  Or do you see output with some long
>> strings of hexadecimal characters, e.g.
>>   <0> 0549d7e3a1b3c5d7f89 [...]

> Yes, I see symbolic names, no any hexadecimal digits (keyIDs, right?).

OK, those are CKA_LABELs, not CKA_IDs.  CKA_LABELs are also known as
"nicknames".  All keys in NSS have CKA_IDs.  Some (few) have labels.
Since yours have labels, you might try to get certutil to generate a CSR
specifying an existing key by nickname rather than by CKA_ID.

> McCoy is an application (actually, a Firefox extension) 

Yes, I'm familiar with it.  I don't support it though.

> We have a legacy system (Firefox extensions which has been developed for 
> a pretty long time) where extensions are signed with McCoy. The problem 
> is that McCoy is GUI application, which requires user interaction, 
> whereas we want to setup build server where and sign extensions without 
> user interaction.

> We would prefer to find (or create) some command line utility which can 
> be called from the build. At this moment we consider using XPISigner - 
> pure Java utility which require private key in PKCS#12 form.

I think you should tell that to McCoy's developer.

> There is a lot copies of our FF extensions are installed and we would 
> prefer to reuse existing keys than change key and force user perform 
> double extension update.
> 
> So probably the right answer here is to export key to use it with 
> another tool.

McCoy creates signatures of its own peculiar ad-hoc format, for which
there is no specification.  Firefox expects addons to be signed with
that format, unless they are downloaded from https sites.  I doubt that
you will find any other tool that can generate signatures in the expected
format.  See


> Yes, basically I understand PKI nature and was also surprised about 
> storing private key without certificate. And I don't say that it is an 
> NSS problem. From the other hand, I believe that McCoy uses NSS API, so 
> there is a possibility to store keys without certificates in the keys 
> database.

Oh, yes.  They can be created and they can be stored in the database without
certificates.  But that's not what you want to do.

Maybe your best bet is to start with the open source to McCoy and see if
you can make it into a command line tool to sign extensions.  It would
probably lose most of its XPCOM code in the process.  That would eliminate
the issue of exporting bare private keys.
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: How to export private key using pk12util

[Arshad Noor]

While it may be technically feasible, Jean-Marc, it would create a
lot of confusion for users, developers and system administrators to
see a P12 file on their file-system that would not have a digital
certificate in it.

I suspect this is the primary reason why the PKCS specs have a #8
specification distinct from the #12; otherwise they would have just
recommended using #12 for all stages of the certificate issuance
process.

Arshad Noor
StrongAuth, Inc.

Jean-Marc Desperrier wrote:

It's technically feasible (it does not break the format) to create a 
private key only pkcs#12, 

--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: How to export private key using pk12util

[Jean-Marc Desperrier]

Arshad Noor wrote:

The reason we use the PKCS#8 format is only because, in the multi-step
process of generating a key-pair, creating a CSR and getting a digital
certificate from an internal/external CA, the private-key needs to be
temporarily stored securely until a CA issues the digital certificate.


It's technically feasible (it does not break the format) to create a 
private key only pkcs#12, but I don't know if the NSS API around pkcs#12 
supports it.



--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: How to export private key using pk12util

[Andriy Zakharchuk]

Hello Nelson,

thank you for so detailed answer. Please see my comments/answers below.

I have a keys database file (key3.db) and need to export a private key 
from it, but can not do this.


What version of the NSS utilities are you using?  version 3.??.??

I believe I use version 3.11, however I'm not sure about release number.


<0> AAA-update-key
<1> BBB-update-key
<2> CCC-update-key


It that literally what you see?  Or do you see output with some long
strings of hexadecimal characters, e.g.
  <0> 0549d7e3a1b3c5d7f89 [...]

??

Yes, I see symbolic names, no any hexadecimal digits (keyIDs, right?).

In other words I have a database with private keys but without 
certificates (the database was created by McCoy tool). 


So, there is an application that uses NSS, named McCoy, that leaves
users with DBs in a state where they cannot do what they want.
Seems like this is an issue to raise with the McCoy developers.
The NSS team really cannot support every application that uses NSS.


McCoy is an application (actually, a Firefox extension) that allows 
manage secure updates to add-ons authors, i.e. sign XPI files and sign 
update.rdf. It is (officially) recommended by Mozilla to sign Firefox or 
Thunderbird extensions.


https://developer.mozilla.org/En/McCoy

To export key I tried to use pk12util. 


Why do you want to export it?
Is there some other tool into which you want to import it?
Do you merely wish to make a backup?


We have a legacy system (Firefox extensions which has been developed for 
a pretty long time) where extensions are signed with McCoy. The problem 
is that McCoy is GUI application, which requires user interaction, 
whereas we want to setup build server where and sign extensions without 
user interaction.


We would prefer to find (or create) some command line utility which can 
be called from the build. At this moment we consider using XPISigner - 
pure Java utility which require private key in PKCS#12 form.


There is a lot copies of our FF extensions are installed and we would 
prefer to reuse existing keys than change key and force user perform 
double extension update.


So probably the right answer here is to export key to use it with 
another tool.



Your answers to these questions may lead to suggestions of alternative
solutions.

In the command line I have to specify certificate 
name (-n option), but I don't have any. 


Yes, NSS is intended for use in PKI applications, where use of public
and private keys is done in accordance with normal PKI procedures.
Someone has chosen to implement a non-PKI application, using "bare"
keys without certs, and has not made the application sufficiently
complete.  Now, the incomplete nature of that application is becoming
an NSS problem.  :( :( :(


Yes, basically I understand PKI nature and was also surprised about 
storing private key without certificate. And I don't say that it is an 
NSS problem. From the other hand, I believe that McCoy uses NSS API, so 
there is a possibility to store keys without certificates in the keys 
database.


We created a small utility (using NSS API) which can restore the key. 
However, it seems that in the runtime we don't have a key itself, we 
have only a handle to it (SECKEYPrivateKeyStr.pkcs11ID), the key itself 
is hidden in the NSS engine and we don't see a way how to serialize it 
into PKCS#12 keystore.


So probably the next question here is what we can do with this object? 
Generate public key and certificate?


http://www.mozilla.org/projects/security/pki/nss/ref/nssfunctions.html#pkcs12

Is that all available documentation on NSS functions?


find user certs from nickname failed: security library: bad database.


Right.
pk12util is intended to export a cert and its associated private key
together in a secure manner.  You don't have the primary one of those
ingredients.

So the question is: is there any way to export private keys from such 
database (probably smbd had similar problem with McCoy)?


Bare private keys by themselves?
NSS utility programs are intended to NOT do that.
The idea is to NOT make it easy for the user to ruin his own security.

NSS utilities are intended to support PKI.  In non-PKI crypto applications,
it is the application developer's duty to provide the necessary
functionality to be used with his application.

NSS has an outstanding Request For Enhancement (RFE) asking that certutil
have the ability to generate a Certificate Signing Request (CSR) from any
private key, including "orphan" keys (those that are not associated with
any certificates).  This is bug
https://bugzilla.mozilla.org/show_bug.cgi?id=430198


That's probably thing we are trying to do now. However, at this moment 
our function doesn't work as find-key-by-CKA_ID, we just take private 
keys by their index in the database (0, 1, 2). Roughly speaking, from 
the certutil output I'm not sure they have keyIDs at all.


--
Best regards,
Andriy.
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
http

Re: How to export private key using pk12util

[Arshad Noor]

Nelson,

I'm afraid PKCS#8 *does* allow for protecting private-keys with
passwords, but you have to explicitly choose the ASN type when
creating the file.  Details can be found at:

ftp://ftp.rsasecurity.com/pub/pkcs/ascii/pkcs-8.asc

While NSS itself has no use for the PKCS#8 format (since it stores
private-keys in the key3.db file, which is already protected with
a password), our open-source CSRTool uses the EncryptedPrivateKeyInfo
ASN type to protect the RSA/ECDSA keys in the PKCS#8 file.

The reason we use the PKCS#8 format is only because, in the multi-step
process of generating a key-pair, creating a CSR and getting a digital
certificate from an internal/external CA, the private-key needs to be 
temporarily stored securely until a CA issues the digital certificate.

At that time, the cert is combined with the keys to create a PKCS#12
file.  We chose PKCS#8 since it was a simpler Java exercise for us.

It's possible that NSS chose to not support the export of the keys
in PKCS#8 format for other reasons, but I don't believe it would be
because it poses a security risk - the PKCS12 file is subject to the
same risks as PKCS8 since it has the same level of protection: PBE
using a 3DES key.

For the person who's trying to export the key:

It is possible to write a little Java (or C if you prefer it) program
to read the NSS keystore, extract the key-pairs (assuming they are
legible and not corrupt in any way) and export them as PKCS#8 files.
If you go with Java, then much of the sample code can be derived from
a combination of specific modules of our open-source tools - StrongKey
(which has code that uses the NSS keystore) and CSRTool (which has the
P8/P12-related sources).  Both tools are available at strongauth.com
and a forum exists there for support on both tools.  Good luck.

Arshad Noor
StrongAuth, Inc.

Nelson Bolyard wrote:


The NSS team participated in the process of defining PKCS#12 precisely
to avoid the security trap of exporting private keys in PKCS#8 format.
Avoiding that trap is precisely why PKCS#12, and not PKCS#8, is THE only
format for private key transport supported by all of NSS, Microsoft and OpenSSL.

--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: How to export private key using pk12util

[Nelson Bolyard]

Kyle Hamilton wrote, On 2009-04-23 14:02:
> Is there a pk1util that would allow for PKCS#1 management?  I think
> that would be more useful than requiring a self-signed public key
> wrapper for pk12util.

Private key storage is not within the scope of PKCS#1.
It is covered by PKCS#8.  NSS supports PKCS#8 fully, but deliberately
refuses to allow "bare" private keys to be exported in PKCS#8 format.

This is not a new policy decision, and goes back over 10 years.  MUCH
has been written on that.  I encourage you to read through the archives
about it.

The NSS team participated in the process of defining PKCS#12 precisely
to avoid the security trap of exporting private keys in PKCS#8 format.
Avoiding that trap is precisely why PKCS#12, and not PKCS#8, is THE only
format for private key transport supported by all of NSS, Microsoft and OpenSSL.
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: How to export private key using pk12util

[Kyle Hamilton]

Is there a pk1util that would allow for PKCS#1 management?  I think
that would be more useful than requiring a self-signed public key
wrapper for pk12util.

-Kyle H

On Thu, Apr 23, 2009 at 1:45 PM, Nelson B Bolyard  wrote:
> Andriy Zakharchuk wrote, On 2009-04-23 12:07:
>> Hello all,
>>
>> I have a keys database file (key3.db) and need to export a private key
>> from it, but can not do this.
>
> What version of the NSS utilities are you using?  version 3.??.??
>
>> certutil.exe -L -d .
>>
>> gives empty output (empty line) and
>>
>> certutil.exe -K -d .
>>
>> gives following output
>>
>> <0> AAA-update-key
>> <1> BBB-update-key
>> <2> CCC-update-key
>
> It that literally what you see?  Or do you see output with some long
> strings of hexadecimal characters, e.g.
>  <0> 0549d7e3a1b3c5d7f89 [...]
>
> ??
>
>> In other words I have a database with private keys but without
>> certificates (the database was created by McCoy tool).
>
> So, there is an application that uses NSS, named McCoy, that leaves
> users with DBs in a state where they cannot do what they want.
> Seems like this is an issue to raise with the McCoy developers.
> The NSS team really cannot support every application that uses NSS.
>
>> To export key I tried to use pk12util.
>
> Why do you want to export it?
> Is there some other tool into which you want to import it?
> Do you merely wish to make a backup?
>
> Your answers to these questions may lead to suggestions of alternative
> solutions.
>
>> In the command line I have to specify certificate
>> name (-n option), but I don't have any.
>
> Yes, NSS is intended for use in PKI applications, where use of public
> and private keys is done in accordance with normal PKI procedures.
> Someone has chosen to implement a non-PKI application, using "bare"
> keys without certs, and has not made the application sufficiently
> complete.  Now, the incomplete nature of that application is becoming
> an NSS problem.  :( :( :(
>
>> find user certs from nickname failed: security library: bad database.
>
> Right.
> pk12util is intended to export a cert and its associated private key
> together in a secure manner.  You don't have the primary one of those
> ingredients.
>
>> So the question is: is there any way to export private keys from such
>> database (probably smbd had similar problem with McCoy)?
>
> Bare private keys by themselves?
> NSS utility programs are intended to NOT do that.
> The idea is to NOT make it easy for the user to ruin his own security.
>
> NSS utilities are intended to support PKI.  In non-PKI crypto applications,
> it is the application developer's duty to provide the necessary
> functionality to be used with his application.
>
> NSS has an outstanding Request For Enhancement (RFE) asking that certutil
> have the ability to generate a Certificate Signing Request (CSR) from any
> private key, including "orphan" keys (those that are not associated with
> any certificates).  This is bug
> https://bugzilla.mozilla.org/show_bug.cgi?id=430198
>
> If that feature was implemented, you could use it to create a self signed
> cert, and with that, you could then use pk12util to export the cert and key.
>
> Perhaps you would like to implement that RFE.  The only changes required
> are (or, should be) in the utility program source code itself, and not in
> NSS's crypto libraries.
> --
> dev-tech-crypto mailing list
> dev-tech-crypto@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-tech-crypto
>
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: How to export private key using pk12util

[Nelson B Bolyard]

Andriy Zakharchuk wrote, On 2009-04-23 12:07:
> Hello all,
> 
> I have a keys database file (key3.db) and need to export a private key 
> from it, but can not do this.

What version of the NSS utilities are you using?  version 3.??.??

> certutil.exe -L -d .
> 
> gives empty output (empty line) and
> 
> certutil.exe -K -d .
> 
> gives following output
> 
> <0> AAA-update-key
> <1> BBB-update-key
> <2> CCC-update-key

It that literally what you see?  Or do you see output with some long
strings of hexadecimal characters, e.g.
  <0> 0549d7e3a1b3c5d7f89 [...]

??

> In other words I have a database with private keys but without 
> certificates (the database was created by McCoy tool). 

So, there is an application that uses NSS, named McCoy, that leaves
users with DBs in a state where they cannot do what they want.
Seems like this is an issue to raise with the McCoy developers.
The NSS team really cannot support every application that uses NSS.

> To export key I tried to use pk12util. 

Why do you want to export it?
Is there some other tool into which you want to import it?
Do you merely wish to make a backup?

Your answers to these questions may lead to suggestions of alternative
solutions.

> In the command line I have to specify certificate 
> name (-n option), but I don't have any. 

Yes, NSS is intended for use in PKI applications, where use of public
and private keys is done in accordance with normal PKI procedures.
Someone has chosen to implement a non-PKI application, using "bare"
keys without certs, and has not made the application sufficiently
complete.  Now, the incomplete nature of that application is becoming
an NSS problem.  :( :( :(

> find user certs from nickname failed: security library: bad database.

Right.
pk12util is intended to export a cert and its associated private key
together in a secure manner.  You don't have the primary one of those
ingredients.

> So the question is: is there any way to export private keys from such 
> database (probably smbd had similar problem with McCoy)?

Bare private keys by themselves?
NSS utility programs are intended to NOT do that.
The idea is to NOT make it easy for the user to ruin his own security.

NSS utilities are intended to support PKI.  In non-PKI crypto applications,
it is the application developer's duty to provide the necessary
functionality to be used with his application.

NSS has an outstanding Request For Enhancement (RFE) asking that certutil
have the ability to generate a Certificate Signing Request (CSR) from any
private key, including "orphan" keys (those that are not associated with
any certificates).  This is bug
https://bugzilla.mozilla.org/show_bug.cgi?id=430198

If that feature was implemented, you could use it to create a self signed
cert, and with that, you could then use pk12util to export the cert and key.

Perhaps you would like to implement that RFE.  The only changes required
are (or, should be) in the utility program source code itself, and not in
NSS's crypto libraries.
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto