Re: Problems importing private keys that already exist

2008-05-30 Thread Dave Townsend
Thanks for filing the bug Nelson. I don't suppose anyone has any idea of how I might be able to work around this issue for the time being? My app is based on XULRunner which will be released with NSS_3_12_RC3 so for the time being I have to work with that. I can see from the implementation

Re: Problems importing private keys that already exist

2008-05-29 Thread Dave Townsend
Wan-Teh Chang wrote: Dave, Thanks for the info. So my time estimate is 100% off. Sorry about that. The attribute type 3584088832 is CKA_NETSCAPE_DB (0xD5A0DB00L). In security/nss/lib/softoken/legacydb/lgattr.c, function lg_FindRSAPrivateKeyAttribute, could you try adding case

Re: Problems importing private keys that already exist

2008-05-29 Thread Dave Townsend
Nelson B Bolyard wrote: Dave Townsend wrote, On 2008-05-28 15:08: Wan-Teh Chang wrote: It seems that if the private key already exists, we modify its attributes: Yes. The attribute type is 3584088832. This is with NSS_3_12_RC3 3584088832 is 0xD5A0DB00 which is CKA_NETSCAPE_DB. See http

Re: Problems importing private keys that already exist

2008-05-28 Thread Dave Townsend
Wan-Teh Chang wrote: It seems that if the private key already exists, we modify its attributes: http://lxr.mozilla.org/security/source/security/nss/lib/softoken/sftkdb.c#848 Many PKCS #11 errors of the softoken are mapped to SEC_ERROR_BAD_DATA:

Do I need to give NSS random data?

2007-09-12 Thread Dave Townsend
I'm writing code that generates a cryptographic key pair. I have basically followed the implementation in certutil which gathers some random data from the keyboard and passes it to PK11_RandomUpdate. However a few people are suggesting that NSS uses fairly good sources of random data anyway

Where to add a new scriptable component

2007-08-01 Thread Dave Townsend
I'm attempting to create a scriptable component that is usable from js in mozilla apps to call into NSS, in particular I am exposing the signature verification functionality. I pretty much have the component done but I am trying to figure out where in tree it should sit. I've tried it

Re: Getting public/private keys into/out of NSS

2007-07-10 Thread Dave Townsend
Hi Bob, thanks for all your help by the way, got me much further so far. Robert Relyea wrote: You really only want to store and retrieve the private keys if you you need to transport them (or back them up). Doing the latter needs to be handled carefully, and can be a source of errors in

Getting public/private keys into/out of NSS

2007-07-09 Thread Dave Townsend
I've spent much of the afternoon delving through the NSS APIs trying to figure out how to achieve my goals. I'm basicaly working on signing and verifying data with public and private keys. I've figured that SGN_SignData and VFY_VerifyData are my friends (or should I be using the

Re: Getting public/private keys into/out of NSS

2007-07-09 Thread Dave Townsend
Robert Relyea wrote: Dave Townsend wrote: Anyway basic issue is that I need a SECKEYPublicKey and SECKEYPrivateKey. I can see how to create them in NSS for use, I've also found a technical note which suggests how to bring a public key into NSS, however I don't see anything about

Re: Proposal for improving the security of add-on updates

2007-06-21 Thread Dave Townsend
Nils Maier wrote: Addressing Dave's demand for proposals: Sorry but I didn't actually demand proposals. I gave one and asked for opinions on it. I am of course open to other proposals and a few have been given. If there is no workable solution then don't implement one. As far as I can tell

Re: Proposal for improving the security of add-on updates

2007-06-20 Thread Dave Townsend
Gervase Markham wrote: Benjamin Smedberg wrote: We already support hashes specified by the upate.rdf for the XPI, and AMO uses this to serve the XPIs over http. However, the issue at hand is when the extension has nothing to do with AMO, and serves the update.rdf over HTTP or the XPI over

Re: Proposal for improving the security of add-on updates

2007-06-20 Thread Dave Townsend
Gervase Markham wrote: Dave Townsend wrote: Indeed, the issue is with add-on authors who do not want to host on AMO (for a variety of quite valid reasons). Could you expand on what those reasons are? Some examples that I have heard (or experienced myself): Long review times leading

Re: Proposal for improving the security of add-on updates

2007-06-18 Thread Dave Townsend
Gervase Markham wrote: Dave Townsend wrote: What I want is to be able to be able to establish some trust that the update file retrieved is correct, and has not been tampered with, intercepted and is as it was originally written by the add-on author. Link Fingerprints was designed

Re: Proposal for improving the security of add-on updates

2007-06-17 Thread Dave Townsend
Nelson B wrote: Dave Townsend wrote: Nelson Bolyard wrote: $18/year is too expensive, eh? Heh, this is true. My attempts to find cheap SSL certificates had only yielded $100/per year jobs. Given that they are not that expensive I have started doing a straw poll of authors to see whether

Re: Proposal for improving the security of add-on updates

2007-06-15 Thread Dave Townsend
Nelson Bolyard wrote: $18/year is too expensive, eh? Heh, this is true. My attempts to find cheap SSL certificates had only yielded $100/per year jobs. Given that they are not that expensive I have started doing a straw poll of authors to see whether that would be too much or not. Dave

Proposal for improving the security of add-on updates

2007-06-14 Thread Dave Townsend
Hi all, I am looking for some feedback on a proposal I'm working on to improve the security of add-on updates in Mozilla products. Let me give an overview of the problem I wish to solve and then what I have come up with so far as a potential solution. In the Mozilla applications we have an