Re: DSA key gen in test pkcs11 code

2002-06-04 Thread Patrick

Ok thanks. Now I'd like to dump out the key values: if I use NSS_NoDBInit(),
how do I dump out the private key value? I would need to be able to convert
from a SECKEYPrivateKey to convert a SECKEYLowPrivateKey, but I can't find a
function to do that.  I see certutil has a DumpPublicKey and DumpPrivateKey
but it uses a function called GetPrivKeyFromNickname() which doen't seem to
exist anywhere...Even if it did, how could I get the priv key from a
nickname, if I'm using a NSS with NoDB?

Could you help me find a way to dump out key values?

-- POC

Ian McGreer [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]...
 Patrick wrote:
  Nelson,
 
  Is the code in
  mozilla\security\nss\tests\pkcs11\netscape\suites\security\pkcs11.c
another
  pretty good example of how to gen a DSA key pair?
 
  -- POC
 
 

 That code calls PKCS#11 functions directly.  I don't think you want to
 do that, unless you want to skip NSS and initialize the softoken yourself.

 If you don't want databases, use NSS_NoDBInit().  certutil can generate
 DSA keypairs, seee mozilla/security/nss/cmd/certutil/keystuff.c

 -Ian







PK11_GenerateKeyPair

2002-06-04 Thread Patrick

If I use PK11_GenerateKeyPair with isPerm and isSensitive parameters set to
FALSE, then I understand that the key is extractable (not tied to a token):
how does one then extract the actual private key value from the object
returned, which is of type SECKEYPrivateKey?

-- POC






Re: PK11_GenerateKeyPair

2002-06-04 Thread Jamie Nicolson

I don't think there is any way to do this. I wanted to provide it in JSS 
to implement the JCA KeyFactory class, but Bob Relyea said he didn't 
want to support this functionality because there is no legitimate reason 
for doing it.

Private keys can be extracted if they are first wrapped with a symmetric 
key; this is the usual way of moving a private key from one place to 
another.

Patrick wrote:

If I use PK11_GenerateKeyPair with isPerm and isSensitive parameters set to
FALSE, then I understand that the key is extractable (not tied to a token):
how does one then extract the actual private key value from the object
returned, which is of type SECKEYPrivateKey?

-- POC







Re: PK11_GenerateKeyPair

2002-06-04 Thread Patrick

OK I can wrap the private key. If I then extract it, will this then give me
an object which I can manipulate to extract the private key value (the raw
bytes)? Or can this wrapped key only be extracted to be be then installed
another token (actual values are still inaccessible)?

Also, when you say the functionality is not supported, do you mean in the
official API or not at all in NSS?

-- Patrick

Jamie Nicolson [EMAIL PROTECTED] wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
 I don't think there is any way to do this. I wanted to provide it in JSS
 to implement the JCA KeyFactory class, but Bob Relyea said he didn't
 want to support this functionality because there is no legitimate reason
 for doing it.

 Private keys can be extracted if they are first wrapped with a symmetric
 key; this is the usual way of moving a private key from one place to
 another.

 Patrick wrote:

 If I use PK11_GenerateKeyPair with isPerm and isSensitive parameters set
to
 FALSE, then I understand that the key is extractable (not tied to a
token):
 how does one then extract the actual private key value from the object
 returned, which is of type SECKEYPrivateKey?
 
 -- POC
 
 







Re: Selecting which cert to sign with doesn't work

2002-06-04 Thread Julien Pierre

Chris,

Chris wrote:
 
 Sure, I can take a look when I get a chance.  If you have some pointers
 of where to look first that might be helpful.  I don't know when I'll
 get around to doing this though.
 
 I'm currently using Mozilla RC3 on Debian Linux and Win32.  Debian
 version is the Debian packaged version 1.0rc3-2.  Win32 version is the
 5-23-2002 build.  I'm also testing with RC2 on Sparc Solaris, although I
 would rather not debug there.

The build instructions for NSS 3.3 are at
http://www.mozilla.org/projects/security/pki/nss/buildnss_33.html .

RC3 was using NSS 3.4, and today NSS 3.5 should be going into the
mozilla 1.0 branch.
The NSS 3.5 branch is NSS_3_5_BRANCH , which is what you want to use
when pulling from cvs .

Specifically when building 3.5 I pull as follows :
cvs co mozilla/nsprpub
cvs co -r NSS_3_5_BRANCH mozilla/security/coreconf mozilla/security/nss
cvs co -r DBM_1_61_RTM mozilla/dbm mozilla/security/dbm

Then I build like this :

setenv NSPR_AUTOCONF 1
cd mozilla/security/nss
gmake nss_build_all

As far as your debugging platform, I would recommend you avoid Linux due
to the lack of support of threads of the debugger. Both Win32 and
Solaris have good debuggers. In any case, the code is the same accross
platforms.

-- 
Except for the lack of debugging and the ps thing, [Linux] kernel
threads are generally fine right now. And if you're not too fussed
about the more fiddly details of POSIX threads, and your application
doesn't spend most of its time in thread creation, then LinuxThreads
is great too.

  Linux-Kernel archive




Re: PK11_GenerateKeyPair

2002-06-04 Thread Jamie Nicolson

Patrick wrote:

OK I can wrap the private key. If I then extract it, will this then give me
an object which I can manipulate to extract the private key value (the raw
bytes)? Or can this wrapped key only be extracted to be be then installed
another token (actual values are still inaccessible)?

In theory, you could decrypt the wrapped key (treating it like encrypted 
data) and decode the ASN.1 blob (I believe it's an 
EncryptedPrivateKeyInfo) and pull out the key bytes. You'd have to write 
this code  yourself, as there is no one function to do it for you.

Also, when you say the functionality is not supported, do you mean in the
official API or not at all in NSS?

I don't think it's supported at all. I don't see any function in 
pk11func.h or key.h that does this.

Dare I ask: why do you need this functionality? Keep in mind that NSS is 
not an all-purpose crypto toolkit. It generally only supports those 
operations that the NSS team considers are required to implement 
responsible applications. An application that plays with key material 
outside the boundary of the cryptographic service provider is not 
considered responsible.