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
<https://wiki.mozilla.org/Talk:Extension_Manager:Addon_Update_Security:Signature>

> 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

Reply via email to