Re: Problem with loading security module in firefox..

[Akkshayaa Venkatram]

Hi Subrata,
Thanks for responding. I checked the links you sent. I am calling the 
function pkcs11.addmodule(modname, path, 0,0); for loading the module.
The path of the dllfile is the extension folder say for eg:
C:\Users\AKS\AppData\Roaming\Mozilla\Firefox\Profiles\oiy8ehzb.default\extensions\{22e46b7c-3348-11dc-8314-0800200c9a66}\components\acospkcs11.dll

When i install the extension,restart firefox,  the module gets loaded 
and i am able to use it. But if i close the browser and reopen it, i am 
not able to find the module. Do you have any idea why this happens?

If the path is C:\Program Files\Mozilla Firefox\components\acospkcs11.dll
it loads without any problem and is available persistently.

But i want the path to be the former one.
I would appreciate your help, i have been stuck on this for more than 2 
months..

Thanks,
Akkshayaa

Subrata Mazumdar wrote:
> Hi Akkshayaa,
> The Device Manager in Mozilla PSM registers the PKCS#11 module 
> persistently with the browser's Module-DB.
> You might want to compare your code with Mozilla PSM Device Manager code 
> for loading PKCS#11 module  :
>   
> http://lxr.mozilla.org/mozilla/source/security/manager/pki/resources/content/device_manager.js#459
>   
> http://lxr.mozilla.org/mozilla/source/security/manager/ssl/src/nsCrypto.cpp#3017
>  
> 
> BTW, once PKCS#11 module is registered, browser will automatically load 
> the module every time you open the browser.
> Your add-on need not load it.
> --
> Subrata Mazumdar
> 
> Akkshayaa Venkatram wrote:
>> Hi
>> I am a new member to this group.
>> I am developing a firefox addon for which i am using smart card bundle 
>> and the opensc.dll
>> The addon that i am creating has the opensc.dll in the components 
>> folder of the extension and everytime the extension is installed, the 
>> security module gets loaded into the firefox browser. This works fine 
>> during every new installation. But when i close firefox window and try 
>> reopening it, i can only see the place holder for the security module 
>> but the actual module is missing, which doesn't let me use the smart 
>> card.
>>
>> Can i someone help me figure out where the problem is? I was wondering 
>> if any flag has to be set in the dll to make the loaded module 
>> persistent. However, if i try to load the opensc.dll from C:\program 
>> files or any other stable location, it persists and doesn't get 
>> removed. But i don't want the module to exist when the firefox 
>> extension is removed and hence want to load the module from the 
>> extension folder.
>>
>> Hoping to receive a reply..
>> Thanks in advance
>>
> ___
> 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: Entrust EV request

[Eddy Nigg (StartCom Ltd.)]

Frank Hecker:


This language and other language in section 3.1.8 seem pretty standard
to me; I've seen language like it in lots of CPSs. As I read it, RAs get
various identity-related documents from applicants and cross-check that
information against various databases, including checking the
association between domain name and organizational identity, to make
sure there are no inconsistencies (e.g., the domain name isn't
registered to someone else). The CPS requires RAs to take "commercially
reasonable efforts" in doing this.

Compare this to what our policy requires

... for a certificate to be used for SSL-enabled servers, the CA
takes reasonable measures to verify that the entity submitting
the certificate signing request has registered the domain(s)
referenced in the certificate or has been authorized by the domain
registrant to act on the registrant's behalf

The policy doesn't specify exactly how this verification is to be done,
only that the measures be "reasonable". In the US and Canada (where
Entrust is based) the term "commercially reasonable" as used in the
Entrust CPS means something like "what a reasonably prudent business
person would do in similar circumstances"; this level of effort is
consistent with our intent in the policy.

   
Well, there is no problem with "commercially reasonable efforts", rather 
I'd like to know a little bit more about their procedures and 
requirements by the RAs. A practical example will help illustrate what 
I'm missing...


I'm Frank Hecker and I own bid4books.net. Validating Frank shouldn't be 
such a problem perhaps, but do you really own bid4books.net? The third 
party source (WHOIS) shows:


Registrant:
   Domains by Proxy, Inc.
   DomainsByProxy.com
   15111 N. Hayden Rd., Ste 160, PMB 353
   Scottsdale, Arizona 85260
   United States

Now, lets go back to their CPS again (and I haven't found anything 
better than that):


Registration Authorities operating under the Entrust SSL Web Server 
Certification Authorities shall *determine whether* the organizational 
identity, address, and *domain* name provided with an Entrust SSL Web 
Server Certificate Application are *consistent* with *information* 
contained *in third-party databases* and/or governmental sources.


There is no stipulation about what happens in cases this can't be done 
(e.g. it doesn't say it refuses to issue the certificate nor does it say 
what else it does in such cases). In this respect the CPS is very weakly 
defined at best and I'd prefer to receive explicit information from them 
about what RAs are required to do.


Additionally I'm missing something more about how the subscriber is 
verified, consistency with third party sources isn't really enough, 
isn't it? Or can I be really also Frank Hecker if I know all your details?



Regards
Signer: Eddy Nigg, StartCom Ltd. 
Jabber: [EMAIL PROTECTED] 
Blog:   Join the Revolution! 
Phone:  +1.213.341.0390


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

Re: Entrust EV request

[Frank Hecker]

Eddy Nigg (StartCom Ltd.) wrote:
> Therefore I'd like to request clarification and verification about how 
> domains are validated by the RAs, since the CPS isn't clear in that 
> respect.

> Refence is 3.1.8 from the CPS:
> 
> Registration Authorities operating under the Entrust SSL Web Server 
> Certification Authorities
> shall determine whether the organizational identity, address, and domain 
> name provided with an Entrust
> SSL Web Server Certificate Application are consistent with information 
> contained in third-party databases
> and/or governmental sources.

This language and other language in section 3.1.8 seem pretty standard 
to me; I've seen language like it in lots of CPSs. As I read it, RAs get 
various identity-related documents from applicants and cross-check that 
information against various databases, including checking the 
association between domain name and organizational identity, to make 
sure there are no inconsistencies (e.g., the domain name isn't 
registered to someone else). The CPS requires RAs to take "commercially 
reasonable efforts" in doing this.

Compare this to what our policy requires

   ... for a certificate to be used for SSL-enabled servers, the CA
   takes reasonable measures to verify that the entity submitting
   the certificate signing request has registered the domain(s)
   referenced in the certificate or has been authorized by the domain
   registrant to act on the registrant's behalf

The policy doesn't specify exactly how this verification is to be done, 
only that the measures be "reasonable". In the US and Canada (where 
Entrust is based) the term "commercially reasonable" as used in the 
Entrust CPS means something like "what a reasonably prudent business 
person would do in similar circumstances"; this level of effort is 
consistent with our intent in the policy.

Maybe I'm being dense, but I don't see what the issue is here.

Frank

-- 
Frank Hecker
[EMAIL PROTECTED]
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Entrust EV request

[Eddy Nigg (StartCom Ltd.)]

Frank Hecker:

Eddy Nigg (StartCom Ltd.) wrote:
   

That's nice, but how can *I* also know about it? Would it be possible to
confirm it at the bug (that only EV certificates will be issued from
that root ) and remove the OV attribute from
http://www.mozilla.org/projects/security/certs/pending/#Entrust ?
 


My apologies, I didn't exactly get what you were asking. Yes, I'll make
a note about this in the bug and in the pending list, and get confirmation.
   
I peaked already at the bug and continue to respond to the inclusion 
request as it seems to be clear that non-EV certificates may be issued 
from this root and the governing CP/CPS is 
http://www.entrust.net/CPS/pdf/webcps051404.pdf


Therefore I'd like to request clarification and verification about how 
domains are validated by the RAs, since the CPS isn't clear in that 
respect. Please note that Gerv in the original inclusion request perhaps 
missed that point and I must have been asleep as well or just started to 
regularly review inclusions back then.


Refence is 3.1.8 from the CPS:

Registration Authorities operating under the Entrust SSL Web Server 
Certification Authorities
shall determine whether the organizational identity, address, and domain 
name provided with an Entrust
SSL Web Server Certificate Application are consistent with information 
contained in third-party databases

and/or governmental sources.



Regards
Signer: Eddy Nigg, StartCom Ltd. 
Jabber: [EMAIL PROTECTED] 
Blog:   Join the Revolution! 
Phone:  +1.213.341.0390


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

Re: Cannot encrypt cipher via pkcs11 in nss fips mode

[Arshad Noor]

FWIW, the StrongKey implementation of a Symmetric Key Management
System (SKMS) uses certificates and private keys from JKS keystores,
NSS databases (using the SunPKCS11 bridge) and smartcards (also using
SunPKCS11).  We're working on integrating various HSMs and the TPM.
Full source code is available at www.strongkey.org.

We haven't tried it with the NSS store in FIPS mode, so I can't predict
what might happen.

Arshad Noor
StrongAuth, Inc.

Glen Beasley wrote:
> Yevgeniy Gubenko wrote:
>> The main reason not to work with JSS is the following paragraph written in
>> http://www.mozilla.org/projects/security/pki/jss/provider_notes.html
>>
>> The following classes don't work very well:
>>
>> KeyStore: There are many serious problems mapping the JCA keystore interface 
>> onto NSS's model of PKCS #11 modules. The current implementation is almost 
>> useless. Since these problems lie deep in the NSS design and implementation, 
>> there is no clear timeframe for fixing them. Meanwhile, the 
>> org.mozilla.jss.crypto.CryptoStore class can be used for some of this 
>> functionality.
>>
>> We have a lot of use of keystore in our application.
>> I didn't understand your observation:
>>   
> As long as you're using using NSS to store your certs and keys you 
> should have no problem using JSS.
> The Mozilla-JSS provider's keystore implementation is almost useless, 
> but you can use CryptoStore as the documentation states.
> Using JDK6 SunPKCS11 you may manage to access both the Java keystore and 
> NSS's but I have
> not tried this so I do not know  what your  issues  will be.
> http://java.sun.com/javase/6/docs/technotes/guides/security/p11guide.html#KeyStoreRestrictions
> 
>>> yes NSS supports x509 but does
>>> 
>> What did you mean saying "but does"?
>>   
> it was a typo that I didn't edit correctly when I sent the email,  as I 
> looked at the time, and realized I had to catch my commuter train.
> do disregard the  "but does".
>> So if NSS supports X509, why do I get the below exception without adding 
>> another 2 providers?
>>   
> sometimes error messages are not clear.
>>> As well, I wasn't able to run my class with the only dynamically added 
>>> crypto provider, until I enabled both of the following providers in 
>>> jre/lib/security/java.security configuration:
>>>
>>> 1. security.provider.1=sun.security.pkcs11.SunPKCS11 
>>> ${java.home}/lib/security/sunpkcs11-solaris.cfg
>>> 2. security.provider.2=sun.security.provider.Sun
>>> 
> These are default providers, you may be able to disable #2, but you 
> cannot disable #1 SunPKCS11 if you want
> the JDK to talk with NSS's PKCS11.
> 
> ie. from your own code:
> 
> String configFileName = "/opt/nss/pkcs11.cfg";
> java.security.Provider nss = new 
> sun.security.pkcs11.SunPKCS11(configFileName);
> 
> 
> If you have an actual issue with JSS or an actual bug with NSS's pkcs11 
> implementation you should use this forum.
> If you want to get your program working with the JDK's SunPKCS11 then I 
> would ask further questions in
> http://forum.java.sun.com/index.jspa
> 
> have a good day,
> 
> glen
>>> Otherwise I got an exception:
>>>
>>> Exception in thread "main" java.lang.ExceptionInInitializerError
>>> at javax.crypto.Cipher.getInstance(DashoA13*..)
>>> at decryptPass.main(decryptPass.java:43)
>>> Caused by: java.lang.SecurityException: Cannot set up certs for trusted CAs
>>> at javax.crypto.SunJCE_b.(DashoA13*..)
>>> ... 2 more
>>> Caused by: java.security.PrivilegedActionException: 
>>> java.security.cert.CertificateException: X.509 not found
>>> at java.security.AccessController.doPrivileged(Native Method)
>>> ... 3 more
>>> Caused by: java.security.cert.CertificateException: X.509 not found
>>> at 
>>> java.security.cert.CertificateFactory.getInstance(CertificateFactory.java:153)
>>> at javax.crypto.SunJCE_b$1.run(DashoA13*..)
>>> ... 4 more
>>> Caused by: java.security.NoSuchAlgorithmException: X.509 CertificateFactory 
>>> not available
>>> at sun.security.jca.GetInstance.getInstance(GetInstance.java:142)
>>> at 
>>> java.security.cert.CertificateFactory.getInstance(CertificateFactory.java:148)
>>>
>>> Doesn't NSS3.11.4 crypto API support all X.509 stuff?
>>>
>>> 
>> yes NSS supports x509 but does
>>   
>>> Best Regards,
>>> Yevgeniy
>>>
>>> -Original Message-
>>> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Glen Beasley
>>> Sent: Wednesday, June 04, 2008 18:15
>>> To: mozilla's crypto code discussion list
>>> Subject: Re: Cannot encrypt cipher via pkcs11 in nss fips mode
>>>
>>> hello,
>>>
>>>
>>> Your chosen set of operations to be performed is: "DESede/CBC/NoPadding"
>>>
>>> DESede is a block cipher and operates on 8-byte blocks. Thus, input to
>>> DESede Cipher with CBC mode and "NoPadding"
>>> scheme should be in multiple of 8 bytes for the encryption/decryption to
>>> succeed.
>>>
>>> I was able to get your program working 

Re: Cannot encrypt cipher via pkcs11 in nss fips mode

[Glen Beasley]

Yevgeniy Gubenko wrote:

The main reason not to work with JSS is the following paragraph written in
http://www.mozilla.org/projects/security/pki/jss/provider_notes.html

The following classes don't work very well:

KeyStore: There are many serious problems mapping the JCA keystore interface 
onto NSS's model of PKCS #11 modules. The current implementation is almost 
useless. Since these problems lie deep in the NSS design and implementation, 
there is no clear timeframe for fixing them. Meanwhile, the 
org.mozilla.jss.crypto.CryptoStore class can be used for some of this 
functionality.

We have a lot of use of keystore in our application.
I didn't understand your observation:
  
As long as you're using using NSS to store your certs and keys you 
should have no problem using JSS.
The Mozilla-JSS provider's keystore implementation is almost useless, 
but you can use CryptoStore as the documentation states.
Using JDK6 SunPKCS11 you may manage to access both the Java keystore and 
NSS's but I have

not tried this so I do not know  what your  issues  will be.
http://java.sun.com/javase/6/docs/technotes/guides/security/p11guide.html#KeyStoreRestrictions


yes NSS supports x509 but does


What did you mean saying "but does"?
  
it was a typo that I didn't edit correctly when I sent the email,  as I 
looked at the time, and realized I had to catch my commuter train.

do disregard the  "but does".

So if NSS supports X509, why do I get the below exception without adding 
another 2 providers?
  

sometimes error messages are not clear.

As well, I wasn't able to run my class with the only dynamically added crypto 
provider, until I enabled both of the following providers in 
jre/lib/security/java.security configuration:

1. security.provider.1=sun.security.pkcs11.SunPKCS11 
${java.home}/lib/security/sunpkcs11-solaris.cfg
2. security.provider.2=sun.security.provider.Sun

These are default providers, you may be able to disable #2, but you 
cannot disable #1 SunPKCS11 if you want

the JDK to talk with NSS's PKCS11.

ie. from your own code:

String configFileName = "/opt/nss/pkcs11.cfg";
java.security.Provider nss = new sun.security.pkcs11.SunPKCS11(configFileName);


If you have an actual issue with JSS or an actual bug with NSS's pkcs11 
implementation you should use this forum.
If you want to get your program working with the JDK's SunPKCS11 then I 
would ask further questions in

http://forum.java.sun.com/index.jspa

have a good day,

glen

Otherwise I got an exception:

Exception in thread "main" java.lang.ExceptionInInitializerError
at javax.crypto.Cipher.getInstance(DashoA13*..)
at decryptPass.main(decryptPass.java:43)
Caused by: java.lang.SecurityException: Cannot set up certs for trusted CAs
at javax.crypto.SunJCE_b.(DashoA13*..)
... 2 more
Caused by: java.security.PrivilegedActionException: 
java.security.cert.CertificateException: X.509 not found
at java.security.AccessController.doPrivileged(Native Method)
... 3 more
Caused by: java.security.cert.CertificateException: X.509 not found
at 
java.security.cert.CertificateFactory.getInstance(CertificateFactory.java:153)
at javax.crypto.SunJCE_b$1.run(DashoA13*..)
... 4 more
Caused by: java.security.NoSuchAlgorithmException: X.509 CertificateFactory not 
available
at sun.security.jca.GetInstance.getInstance(GetInstance.java:142)
at 
java.security.cert.CertificateFactory.getInstance(CertificateFactory.java:148)

Doesn't NSS3.11.4 crypto API support all X.509 stuff?



yes NSS supports x509 but does
  

Best Regards,
Yevgeniy

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Glen Beasley
Sent: Wednesday, June 04, 2008 18:15
To: mozilla's crypto code discussion list
Subject: Re: Cannot encrypt cipher via pkcs11 in nss fips mode

hello,


Your chosen set of operations to be performed is: "DESede/CBC/NoPadding"

DESede is a block cipher and operates on 8-byte blocks. Thus, input to
DESede Cipher with CBC mode and "NoPadding"
scheme should be in multiple of 8 bytes for the encryption/decryption to
succeed.

I was able to get your program working by adding two bytes to the
following line.

   String password = "passwordString!!";  //16 bytes

If you need to have variable lengths of input you need to first pad your
data, then encrypt.
After you decrypt you need to remove the pad.

some links for your review:

http://java.sun.com/javase/6/docs/technotes/guides/security/p11guide.html
http://tools.ietf.org/html/rfc2898
http://csrc.nist.gov/publications/nistpubs/800-38a/sp800-38a.pdf
http://mxr.mozilla.org/security/source/security/jss/org/mozilla/jss/tests/JCASymKeyGen.java

have a good day,

glen


Yevgeniy Gubenko wrote:



Hi,

I'm a new incomer trying to handle keying material for NSS fips mode.
This is the case:
I am working with pkcs11 provider on Solaris 10, which is configured
to work with mozilla NSS provider.
This

RE: Debian Weak Key Problem

[Andrews, Rick]

> It seems that CAs are not bothering to contact their customers with
weak
> keys[1], although they are of course revoking the keys of customers
who
> ask, and reissuing certificates.

Gerv,

I just wanted to mention that we've been working feverishly to automate
checking of all valid certs in our databases. It's taking time because
it's a huge task - we have hundreds of thousands of certs to check - but
we intend to notify any customer who is using a weak key.

-Rick Andrews

-- 
Rick Andrews __oPhone: 650-426-3401
VeriSign, Inc. _ \>,_   Fax:   650-426-5195
487 E. Middlefield Rd. ...(_)/ (_)  URL:   www.verisign.com
Mountain View, CA  94043email: [EMAIL PROTECTED]
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

RE: Cannot encrypt cipher via pkcs11 in nss fips mode

[Yevgeniy Gubenko]

The main reason not to work with JSS is the following paragraph written in
http://www.mozilla.org/projects/security/pki/jss/provider_notes.html

The following classes don't work very well:

KeyStore: There are many serious problems mapping the JCA keystore interface 
onto NSS's model of PKCS #11 modules. The current implementation is almost 
useless. Since these problems lie deep in the NSS design and implementation, 
there is no clear timeframe for fixing them. Meanwhile, the 
org.mozilla.jss.crypto.CryptoStore class can be used for some of this 
functionality.

We have a lot of use of keystore in our application.
I didn't understand your observation:
> yes NSS supports x509 but does
What did you mean saying "but does"?
So if NSS supports X509, why do I get the below exception without adding 
another 2 providers?
Thanks
Yevgeniy

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Thursday, June 05, 2008 18:08
To: mozilla's crypto code discussion list; Yevgeniy Gubenko
Subject: Re: Cannot encrypt cipher via pkcs11 in nss fips mode

Yevgeniy Gubenko wrote:
> Hi Glen,
> Thanks a lot for your detailed reply and the reference to relevant material.
> Your solution worked nice, but I realized that after the decryption, first 8 
> characters were variable, so I had to add 8 characters before the encryption 
> (in my case, 16 after padding, and another 8 for removal after decrypt).
>
I don't quite follow the above issue.

Instead of trying to work at the PKCS11 layer. Why don't you try to do
what you want with JSS? The JSS api is higher level and
should be easier to work with then the PKCS11 layer. JSS is FIPS
compliant as  it  requests  NSS  to  do any and all crypto within
the NSS PKCS11 cryptographic boundary.

http://www.mozilla.org/projects/security/pki/jss/
sample code:
http://mxr.mozilla.org/security/source/security/jss/org/mozilla/jss/tests

-glen

> As well, I wasn't able to run my class with the only dynamically added crypto 
> provider, until I enabled both of the following providers in 
> jre/lib/security/java.security configuration:
>
> 1. security.provider.1=sun.security.pkcs11.SunPKCS11 
> ${java.home}/lib/security/sunpkcs11-solaris.cfg
> 2. security.provider.2=sun.security.provider.Sun
>
> Otherwise I got an exception:
>
> Exception in thread "main" java.lang.ExceptionInInitializerError
> at javax.crypto.Cipher.getInstance(DashoA13*..)
> at decryptPass.main(decryptPass.java:43)
> Caused by: java.lang.SecurityException: Cannot set up certs for trusted CAs
> at javax.crypto.SunJCE_b.(DashoA13*..)
> ... 2 more
> Caused by: java.security.PrivilegedActionException: 
> java.security.cert.CertificateException: X.509 not found
> at java.security.AccessController.doPrivileged(Native Method)
> ... 3 more
> Caused by: java.security.cert.CertificateException: X.509 not found
> at 
> java.security.cert.CertificateFactory.getInstance(CertificateFactory.java:153)
> at javax.crypto.SunJCE_b$1.run(DashoA13*..)
> ... 4 more
> Caused by: java.security.NoSuchAlgorithmException: X.509 CertificateFactory 
> not available
> at sun.security.jca.GetInstance.getInstance(GetInstance.java:142)
> at 
> java.security.cert.CertificateFactory.getInstance(CertificateFactory.java:148)
>
> Doesn't NSS3.11.4 crypto API support all X.509 stuff?
>
yes NSS supports x509 but does
> Best Regards,
> Yevgeniy
>
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Glen Beasley
> Sent: Wednesday, June 04, 2008 18:15
> To: mozilla's crypto code discussion list
> Subject: Re: Cannot encrypt cipher via pkcs11 in nss fips mode
>
> hello,
>
>
> Your chosen set of operations to be performed is: "DESede/CBC/NoPadding"
>
> DESede is a block cipher and operates on 8-byte blocks. Thus, input to
> DESede Cipher with CBC mode and "NoPadding"
> scheme should be in multiple of 8 bytes for the encryption/decryption to
> succeed.
>
> I was able to get your program working by adding two bytes to the
> following line.
>
>String password = "passwordString!!";  //16 bytes
>
> If you need to have variable lengths of input you need to first pad your
> data, then encrypt.
> After you decrypt you need to remove the pad.
>
> some links for your review:
>
> http://java.sun.com/javase/6/docs/technotes/guides/security/p11guide.html
> http://tools.ietf.org/html/rfc2898
> http://csrc.nist.gov/publications/nistpubs/800-38a/sp800-38a.pdf
> http://mxr.mozilla.org/security/source/security/jss/org/mozilla/jss/tests/JCASymKeyGen.java
>
> have a good day,
>
> glen
>
>
> Yevgeniy Gubenko wrote:
>
>> Hi,
>>
>> I'm a new incomer trying to handle keying material for NSS fips mode.
>> This is the case:
>> I am working with pkcs11 provider on Solaris 10, which is configured
>> to work with mozilla NSS provider.
>> This is my configuration file for pkcs11 provider :
>> name = NSScrypto
>> nssLibraryDirectory = /opt/

Re: Cannot encrypt cipher via pkcs11 in nss fips mode

[Glen Beasley]

Yevgeniy Gubenko wrote:
> Hi Glen,
> Thanks a lot for your detailed reply and the reference to relevant material.
> Your solution worked nice, but I realized that after the decryption, first 8 
> characters were variable, so I had to add 8 characters before the encryption 
> (in my case, 16 after padding, and another 8 for removal after decrypt).
>   
I don't quite follow the above issue.

Instead of trying to work at the PKCS11 layer. Why don't you try to do 
what you want with JSS? The JSS api is higher level and
should be easier to work with then the PKCS11 layer. JSS is FIPS 
compliant as  it  requests  NSS  to  do any and all crypto within
the NSS PKCS11 cryptographic boundary.

http://www.mozilla.org/projects/security/pki/jss/
sample code:
http://mxr.mozilla.org/security/source/security/jss/org/mozilla/jss/tests

-glen

> As well, I wasn't able to run my class with the only dynamically added crypto 
> provider, until I enabled both of the following providers in 
> jre/lib/security/java.security configuration:
>
> 1. security.provider.1=sun.security.pkcs11.SunPKCS11 
> ${java.home}/lib/security/sunpkcs11-solaris.cfg
> 2. security.provider.2=sun.security.provider.Sun
>
> Otherwise I got an exception:
>
> Exception in thread "main" java.lang.ExceptionInInitializerError
> at javax.crypto.Cipher.getInstance(DashoA13*..)
> at decryptPass.main(decryptPass.java:43)
> Caused by: java.lang.SecurityException: Cannot set up certs for trusted CAs
> at javax.crypto.SunJCE_b.(DashoA13*..)
> ... 2 more
> Caused by: java.security.PrivilegedActionException: 
> java.security.cert.CertificateException: X.509 not found
> at java.security.AccessController.doPrivileged(Native Method)
> ... 3 more
> Caused by: java.security.cert.CertificateException: X.509 not found
> at 
> java.security.cert.CertificateFactory.getInstance(CertificateFactory.java:153)
> at javax.crypto.SunJCE_b$1.run(DashoA13*..)
> ... 4 more
> Caused by: java.security.NoSuchAlgorithmException: X.509 CertificateFactory 
> not available
> at sun.security.jca.GetInstance.getInstance(GetInstance.java:142)
> at 
> java.security.cert.CertificateFactory.getInstance(CertificateFactory.java:148)
>
> Doesn't NSS3.11.4 crypto API support all X.509 stuff?
>   
yes NSS supports x509 but does
> Best Regards,
> Yevgeniy
>
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Glen Beasley
> Sent: Wednesday, June 04, 2008 18:15
> To: mozilla's crypto code discussion list
> Subject: Re: Cannot encrypt cipher via pkcs11 in nss fips mode
>
> hello,
>
>
> Your chosen set of operations to be performed is: "DESede/CBC/NoPadding"
>
> DESede is a block cipher and operates on 8-byte blocks. Thus, input to
> DESede Cipher with CBC mode and "NoPadding"
> scheme should be in multiple of 8 bytes for the encryption/decryption to
> succeed.
>
> I was able to get your program working by adding two bytes to the
> following line.
>
>String password = "passwordString!!";  //16 bytes
>
> If you need to have variable lengths of input you need to first pad your
> data, then encrypt.
> After you decrypt you need to remove the pad.
>
> some links for your review:
>
> http://java.sun.com/javase/6/docs/technotes/guides/security/p11guide.html
> http://tools.ietf.org/html/rfc2898
> http://csrc.nist.gov/publications/nistpubs/800-38a/sp800-38a.pdf
> http://mxr.mozilla.org/security/source/security/jss/org/mozilla/jss/tests/JCASymKeyGen.java
>
> have a good day,
>
> glen
>
>
> Yevgeniy Gubenko wrote:
>   
>> Hi,
>>
>> I'm a new incomer trying to handle keying material for NSS fips mode.
>> This is the case:
>> I am working with pkcs11 provider on Solaris 10, which is configured
>> to work with mozilla NSS provider.
>> This is my configuration file for pkcs11 provider :
>> name = NSScrypto
>> nssLibraryDirectory = /opt/nss/lib
>> nssSecmodDirectory = /opt/nss/fipsdb
>> nssModule = fips
>>
>> I've created NSS Database and modified it to work in fips module:
>> certutil -N -d /opt/nss/fipsdb
>> modutil -fips true -dbdir /opt/nss/fipsdb
>>
>> Then I created a key in the DB:
>> symkeyutil -K -n test1 -t des3  -d /opt/nss/fipsdb
>>
>> Now let's get to my Java code which should retrieve the key from the
>> DB and use it as a SecretKey to encrypt/decrypt passwords.
>> This is a class which encrypts password:
>>
>> import javax.crypto.SecretKeyFactory;
>>
>> import javax.crypto.spec.DESedeKeySpec;
>>
>> import javax.crypto.spec.DESKeySpec;
>>
>> import javax.crypto.SecretKey;
>>
>> import javax.crypto.Cipher;
>>
>> import javax.crypto.spec.IvParameterSpec;
>>
>> import java.security.*;
>>
>>
>>
>> public class encryptPass
>>
>> {
>>
>> public static void main(String[] args)
>>
>> {
>>
>> try
>>
>> {
>>
>>String configFileName = "/opt/nss/pkcs11.cfg";
>>
>>java.security.Provider nss = new
>> sun.security.pkcs11.SunPKCS11(configFi

Re: Modulus length (was Re: Draft CA information checklist)

[Rob Stradling]

On Thursday 05 June 2008 15:46:54 Kyle Hamilton wrote:
> I must also point out something:
>
> NSS (at least up until 2004 -- I don't know if this has been changed,
> but the MoFo position espoused by I believe Nelson and Frank was that
> it wouldn't change) doesn't rely on any of the X.509v3 certificate
> fields of embedded trust anchors when figuring out whether to extend
> trust.  Thus, changing it won't have any practical value anyway.

Are you saying that NSS *never* checks the "notAfter" dates of its built-in 
Root Certificates?

If so, does this mean that products relying on NSS will still trust built-in 
Root Certificates after those Root Certificates have expired?

> (The argument was that X.509 makes a good container format for
> distributing trust anchors -- the public keys -- along with display
> metadata, but that the trust anchor itself could be distributed
> separately from the X.509 container and thus should not be subject to
> any policy statements included in that container.  Which didn't make
> any sense to me at the time, and still doesn't -- since that container
> is signed by that key anyway, and I would expect it to adhere to the
> CPS espoused by that key -- but that's how it was explained.)
>
> -Kyle H
>
> 2008/6/5 Eddy Nigg (StartCom Ltd.) <[EMAIL PROTECTED]>:
> > Rob Stradling:
> >
> > Sorry Rob, yes I missed that one. But why doing that? Why not replace
> > with something better and remove the "offending" root? Perhaps I'm not
> > objective enough because we actually replaced a small key with a bigger
> > one. What's the logic for having a pile of roots which expire in 2010?
> >
> >
> > I didn't say "expire in 2010".
> >
> >
> > You said valid-for-not-too-far-beyond-2010 :-) I shortened that a little
> > bit for clarity...
> >
> > I think the key issue is that we don't want users of Mozilla software to
> > be relying on 1024-bit RSA Root Keys too far beyond 2010.
> >
> >
> > Correct.
> >
> > If we were to remove any 1024-bit RSA Root Certificates from Mozilla
> > today, it
> > would be damaging to the CAs (who rely on the good browser ubiquity
> > provided by these Roots).
> >
> >
> > Also correct.
> >
> > But, if we instead wait until, say, 2013 to remove those Root
> > Certificates from NSS, some users would still be relying on those
> > 1024-bit Root Keys until
> > nearer 2020 ('cos some users are *very* slow to upgrade their browsers).
> >
> >
> > Update rates are apparently not so bad, but supposed CAs would replace
> > their keys with new and bigger ones, having a target date, when the old
> > roots will be removed, they would make sure that subscribers are using
> > certificates issued by a new root.
> >
> > I believe that my proposal solves both problems.  The CAs' browser
> > ubiquity would not be damaged until such time that Mozilla decides the
> > 1024-bit Keys should be no longer be relied on.
> >
> > Well, I think you are introducing an extra step here. Supposed that CAs
> > indeed would agree to re-issue their current 1024 and smaller keys with a
> > expiration date at some time around 2010, those CAs will most likely also
> > want to have a new root with a bigger key size ready from which they'll
> > want to issue certificates. Because the old root wouldn't be valid
> > anymore in 2010, they really would be at a disadvantage because they
> > won't have enough time to transition to a newer one.
> >
> > Now, in practical terms such a process and transition takes about three
> > years from the moment the new root is created, submitted for inclusion,
> > starting to issue from the new root and make the old root obsolete. One
> > must take into account at least a one year transition period for the EE
> > certs which are still valid (there are some rumors that some CAs issue
> > certs with a validity of 10 years, so they would have to get new certs
> > anyway during that time ;-) ) and CRLs still must be issued from that
> > root until the lasts certificate expires or is revoked.
> >
> > With your proposal, CAs would have first to change their 1024 bit keys to
> > an earlier expiration date, then obviously request to add a new root
> > anyway. I wouldn't want to be in the situation to have a root with
> > validity to only 2010 (or valid-for-not-too-far-beyond) without a
> > acceptable replacement and time to transition.
> >
> > And in the future, Mozilla users (even
> > with...at that point in time...fairly out-of-date software) would be
> > prevented from relying on 1024-bit RSA Root Keys as soon as the date
> > decided by Mozilla arrives.
> >
> >
> > Keep in mind that the ones which usually don't update their browser will
> > also miss the changed 1024 bit keys with the shorter validity, hence I
> > think the gain would be rather minimal. Therefore I think the plan
> > suggested from Paul more realistic in every respect and 2012, maybe 2013
> > sounds to me doable and still within the time frame of such keys not
> > being a risk yet.
> >
> >
> > Regards
> >
> > Signer:

Re: Modulus length (was Re: Draft CA information checklist)

[Kyle Hamilton]

I must also point out something:

NSS (at least up until 2004 -- I don't know if this has been changed,
but the MoFo position espoused by I believe Nelson and Frank was that
it wouldn't change) doesn't rely on any of the X.509v3 certificate
fields of embedded trust anchors when figuring out whether to extend
trust.  Thus, changing it won't have any practical value anyway.

(The argument was that X.509 makes a good container format for
distributing trust anchors -- the public keys -- along with display
metadata, but that the trust anchor itself could be distributed
separately from the X.509 container and thus should not be subject to
any policy statements included in that container.  Which didn't make
any sense to me at the time, and still doesn't -- since that container
is signed by that key anyway, and I would expect it to adhere to the
CPS espoused by that key -- but that's how it was explained.)

-Kyle H

2008/6/5 Eddy Nigg (StartCom Ltd.) <[EMAIL PROTECTED]>:
> Rob Stradling:
>
> Sorry Rob, yes I missed that one. But why doing that? Why not replace
> with something better and remove the "offending" root? Perhaps I'm not
> objective enough because we actually replaced a small key with a bigger
> one. What's the logic for having a pile of roots which expire in 2010?
>
>
> I didn't say "expire in 2010".
>
>
> You said valid-for-not-too-far-beyond-2010 :-) I shortened that a little bit
> for clarity...
>
> I think the key issue is that we don't want users of Mozilla software to be
> relying on 1024-bit RSA Root Keys too far beyond 2010.
>
>
> Correct.
>
> If we were to remove any 1024-bit RSA Root Certificates from Mozilla today,
> it
> would be damaging to the CAs (who rely on the good browser ubiquity provided
> by these Roots).
>
>
> Also correct.
>
> But, if we instead wait until, say, 2013 to remove those Root Certificates
> from NSS, some users would still be relying on those 1024-bit Root Keys
> until
> nearer 2020 ('cos some users are *very* slow to upgrade their browsers).
>
>
> Update rates are apparently not so bad, but supposed CAs would replace their
> keys with new and bigger ones, having a target date, when the old roots will
> be removed, they would make sure that subscribers are using certificates
> issued by a new root.
>
> I believe that my proposal solves both problems.  The CAs' browser ubiquity
> would not be damaged until such time that Mozilla decides the 1024-bit Keys
> should be no longer be relied on.
>
> Well, I think you are introducing an extra step here. Supposed that CAs
> indeed would agree to re-issue their current 1024 and smaller keys with a
> expiration date at some time around 2010, those CAs will most likely also
> want to have a new root with a bigger key size ready from which they'll want
> to issue certificates. Because the old root wouldn't be valid anymore in
> 2010, they really would be at a disadvantage because they won't have enough
> time to transition to a newer one.
>
> Now, in practical terms such a process and transition takes about three
> years from the moment the new root is created, submitted for inclusion,
> starting to issue from the new root and make the old root obsolete. One must
> take into account at least a one year transition period for the EE certs
> which are still valid (there are some rumors that some CAs issue certs with
> a validity of 10 years, so they would have to get new certs anyway during
> that time ;-) ) and CRLs still must be issued from that root until the lasts
> certificate expires or is revoked.
>
> With your proposal, CAs would have first to change their 1024 bit keys to an
> earlier expiration date, then obviously request to add a new root anyway. I
> wouldn't want to be in the situation to have a root with validity to only
> 2010 (or valid-for-not-too-far-beyond) without a acceptable replacement and
> time to transition.
>
> And in the future, Mozilla users (even
> with...at that point in time...fairly out-of-date software) would be
> prevented from relying on 1024-bit RSA Root Keys as soon as the date decided
> by Mozilla arrives.
>
>
> Keep in mind that the ones which usually don't update their browser will
> also miss the changed 1024 bit keys with the shorter validity, hence I think
> the gain would be rather minimal. Therefore I think the plan suggested from
> Paul more realistic in every respect and 2012, maybe 2013 sounds to me
> doable and still within the time frame of such keys not being a risk yet.
>
>
> Regards
>
> Signer:  Eddy Nigg, StartCom Ltd.
> Jabber:  [EMAIL PROTECTED]
> Blog:  Join the Revolution!
> Phone:  +1.213.341.0390
>
>
>
> ___
> 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: Modulus length (was Re: Draft CA information checklist)

[Eddy Nigg (StartCom Ltd.)]

Rob Stradling:

Sorry Rob, yes I missed that one. But why doing that? Why not replace
with something better and remove the "offending" root? Perhaps I'm not
objective enough because we actually replaced a small key with a bigger
one. What's the logic for having a pile of roots which expire in 2010?
 


I didn't say "expire in 2010".
   


You said valid-for-not-too-far-beyond-2010 :-) I shortened that a little 
bit for clarity...


I think the key issue is that we don't want users of Mozilla software to be
relying on 1024-bit RSA Root Keys too far beyond 2010.
   


Correct.


If we were to remove any 1024-bit RSA Root Certificates from Mozilla today, it
would be damaging to the CAs (who rely on the good browser ubiquity provided
by these Roots).
   


Also correct.


But, if we instead wait until, say, 2013 to remove those Root Certificates
from NSS, some users would still be relying on those 1024-bit Root Keys until
nearer 2020 ('cos some users are *very* slow to upgrade their browsers).
   


Update rates are apparently not so bad, but supposed CAs would replace 
their keys with new and bigger ones, having a target date, when the old 
roots will be removed, they would make sure that subscribers are using 
certificates issued by a new root.



I believe that my proposal solves both problems.  The CAs' browser ubiquity
would not be damaged until such time that Mozilla decides the 1024-bit Keys
should be no longer be relied on.


Well, I think you are introducing an extra step here. Supposed that CAs 
indeed would agree to re-issue their current 1024 and smaller keys with 
a expiration date at some time around 2010, those CAs will most likely 
also want to have a new root with a bigger key size ready from which 
they'll want to issue certificates. Because the old root wouldn't be 
valid anymore in 2010, they really would be at a disadvantage because 
they won't have enough time to transition to a newer one.


Now, in practical terms such a process and transition takes about three 
years from the moment the new root is created, submitted for inclusion, 
starting to issue from the new root and make the old root obsolete. One 
must take into account at least a one year transition period for the EE 
certs which are still valid (there are some rumors that some CAs issue 
certs with a validity of 10 years, so they would have to get new certs 
anyway during that time ;-) ) and CRLs still must be issued from that 
root until the lasts certificate expires or is revoked.


With your proposal, CAs would have first to change their 1024 bit keys 
to an earlier expiration date, then obviously request to add a new root 
anyway. I wouldn't want to be in the situation to have a root with 
validity to only 2010 (or valid-for-not-too-far-beyond) without a 
acceptable replacement and time to transition.



And in the future, Mozilla users (even
with...at that point in time...fairly out-of-date software) would be
prevented from relying on 1024-bit RSA Root Keys as soon as the date decided
by Mozilla arrives.
   


Keep in mind that the ones which usually don't update their browser will 
also miss the changed 1024 bit keys with the shorter validity, hence I 
think the gain would be rather minimal. Therefore I think the plan 
suggested from Paul more realistic in every respect and 2012, maybe 2013 
sounds to me doable and still within the time frame of such keys not 
being a risk yet.



Regards
Signer: Eddy Nigg, StartCom Ltd. 
Jabber: [EMAIL PROTECTED] 
Blog:   Join the Revolution! 
Phone:  +1.213.341.0390



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

RE: Cannot encrypt cipher via pkcs11 in nss fips mode

[Yevgeniy Gubenko]

Hi Glen,
Thanks a lot for your detailed reply and the reference to relevant material.
Your solution worked nice, but I realized that after the decryption, first 8 
characters were variable, so I had to add 8 characters before the encryption 
(in my case, 16 after padding, and another 8 for removal after decrypt).
As well, I wasn't able to run my class with the only dynamically added crypto 
provider, until I enabled both of the following providers in 
jre/lib/security/java.security configuration:

1. security.provider.1=sun.security.pkcs11.SunPKCS11 
${java.home}/lib/security/sunpkcs11-solaris.cfg
2. security.provider.2=sun.security.provider.Sun

Otherwise I got an exception:

Exception in thread "main" java.lang.ExceptionInInitializerError
at javax.crypto.Cipher.getInstance(DashoA13*..)
at decryptPass.main(decryptPass.java:43)
Caused by: java.lang.SecurityException: Cannot set up certs for trusted CAs
at javax.crypto.SunJCE_b.(DashoA13*..)
... 2 more
Caused by: java.security.PrivilegedActionException: 
java.security.cert.CertificateException: X.509 not found
at java.security.AccessController.doPrivileged(Native Method)
... 3 more
Caused by: java.security.cert.CertificateException: X.509 not found
at 
java.security.cert.CertificateFactory.getInstance(CertificateFactory.java:153)
at javax.crypto.SunJCE_b$1.run(DashoA13*..)
... 4 more
Caused by: java.security.NoSuchAlgorithmException: X.509 CertificateFactory not 
available
at sun.security.jca.GetInstance.getInstance(GetInstance.java:142)
at 
java.security.cert.CertificateFactory.getInstance(CertificateFactory.java:148)

Doesn't NSS3.11.4 crypto API support all X.509 stuff?

Best Regards,
Yevgeniy

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Glen Beasley
Sent: Wednesday, June 04, 2008 18:15
To: mozilla's crypto code discussion list
Subject: Re: Cannot encrypt cipher via pkcs11 in nss fips mode

hello,


Your chosen set of operations to be performed is: "DESede/CBC/NoPadding"

DESede is a block cipher and operates on 8-byte blocks. Thus, input to
DESede Cipher with CBC mode and "NoPadding"
scheme should be in multiple of 8 bytes for the encryption/decryption to
succeed.

I was able to get your program working by adding two bytes to the
following line.

   String password = "passwordString!!";  //16 bytes

If you need to have variable lengths of input you need to first pad your
data, then encrypt.
After you decrypt you need to remove the pad.

some links for your review:

http://java.sun.com/javase/6/docs/technotes/guides/security/p11guide.html
http://tools.ietf.org/html/rfc2898
http://csrc.nist.gov/publications/nistpubs/800-38a/sp800-38a.pdf
http://mxr.mozilla.org/security/source/security/jss/org/mozilla/jss/tests/JCASymKeyGen.java

have a good day,

glen


Yevgeniy Gubenko wrote:
>
> Hi,
>
> I'm a new incomer trying to handle keying material for NSS fips mode.
> This is the case:
> I am working with pkcs11 provider on Solaris 10, which is configured
> to work with mozilla NSS provider.
> This is my configuration file for pkcs11 provider :
> name = NSScrypto
> nssLibraryDirectory = /opt/nss/lib
> nssSecmodDirectory = /opt/nss/fipsdb
> nssModule = fips
>
> I've created NSS Database and modified it to work in fips module:
> certutil -N -d /opt/nss/fipsdb
> modutil -fips true -dbdir /opt/nss/fipsdb
>
> Then I created a key in the DB:
> symkeyutil -K -n test1 -t des3  -d /opt/nss/fipsdb
>
> Now let's get to my Java code which should retrieve the key from the
> DB and use it as a SecretKey to encrypt/decrypt passwords.
> This is a class which encrypts password:
>
> import javax.crypto.SecretKeyFactory;
>
> import javax.crypto.spec.DESedeKeySpec;
>
> import javax.crypto.spec.DESKeySpec;
>
> import javax.crypto.SecretKey;
>
> import javax.crypto.Cipher;
>
> import javax.crypto.spec.IvParameterSpec;
>
> import java.security.*;
>
>
>
> public class encryptPass
>
> {
>
> public static void main(String[] args)
>
> {
>
> try
>
> {
>
>String configFileName = "/opt/nss/pkcs11.cfg";
>
>java.security.Provider nss = new
> sun.security.pkcs11.SunPKCS11(configFileName);
>
>java.security.Security.insertProviderAt(nss,1);
>
>java.security.KeyStore ks =
> java.security.KeyStore.getInstance("PKCS11", nss);
>
>char[] nssDBPassword = {'f','i','p','s','1','4','0','-','2'};
>
>ks.load(null, nssDBPassword);
>
>SecretKey key = (SecretKey) ks.getKey("test1", nssDBPassword);
>
>
>
>
>
>//iv for CBC mode - note, in practice you don't generate a
> random iv for decryption :)
>
>byte[] iv = new byte[8];  //64-bit block size for 3DES
>
>SecureRandom sr = SecureRandom.getInstance("PKCS11", nss);
>
>sr.nextBytes(iv);
>
>IvParameterSpec params = new IvParameterSpec(iv);
>
>
>
>
>
>   

Re: Entrust EV request

[Frank Hecker]

Eddy Nigg (StartCom Ltd.) wrote:
> That's nice, but how can *I* also know about it? Would it be possible to 
> confirm it at the bug (that only EV certificates will be issued from 
> that root ) and remove the OV attribute from 
> http://www.mozilla.org/projects/security/certs/pending/#Entrust ?

My apologies, I didn't exactly get what you were asking. Yes, I'll make 
a note about this in the bug and in the pending list, and get confirmation.

Frank

-- 
Frank Hecker
[EMAIL PROTECTED]
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Modulus length (was Re: Draft CA information checklist)

[Rob Stradling]

On Thursday 05 June 2008 12:59:13 Eddy Nigg (StartCom Ltd.) wrote:
> Rob Stradling:
> >> Additionally, most of the times the old and the new root will be both
> >> present in NSS for some time in order to allow a smooth transition,
> >> until the old root is being removed.
> >
> > Eddy, I think you've missed the main point of my proposal.  I am
> > suggesting that each existing valid-for-too-long 1024-bit RSA Root
> > Certificate should be replaced with a valid-for-not-too-far-beyond-2010
> > 1024-bit RSA Root Certificates *WITH THE SAME KEY*.
>
> Sorry Rob, yes I missed that one. But why doing that? Why not replace
> with something better and remove the "offending" root? Perhaps I'm not
> objective enough because we actually replaced a small key with a bigger
> one. What's the logic for having a pile of roots which expire in 2010?

I didn't say "expire in 2010".

> Sorry for being slow...can you explain to me the logic of your proposal
> (again)?

I think the key issue is that we don't want users of Mozilla software to be 
relying on 1024-bit RSA Root Keys too far beyond 2010.

If we were to remove any 1024-bit RSA Root Certificates from Mozilla today, it 
would be damaging to the CAs (who rely on the good browser ubiquity provided 
by these Roots).
But, if we instead wait until, say, 2013 to remove those Root Certificates 
from NSS, some users would still be relying on those 1024-bit Root Keys until 
nearer 2020 ('cos some users are *very* slow to upgrade their browsers).

I believe that my proposal solves both problems.  The CAs' browser ubiquity 
would not be damaged until such time that Mozilla decides the 1024-bit Keys 
should be no longer be relied on.  And in the future, Mozilla users (even 
with...at that point in time...fairly out-of-date software) would be 
prevented from relying on 1024-bit RSA Root Keys as soon as the date decided 
by Mozilla arrives.

> Regards
> Signer:   Eddy Nigg, StartCom Ltd. 
> Jabber:   [EMAIL PROTECTED] 
> Blog: Join the Revolution! 
> Phone:+1.213.341.0390



-- 
Rob Stradling
Senior Research & Development Scientist
Comodo - Creating Trust Online
Office Tel: +44.(0)1274.730505
Fax Europe: +44.(0)1274.730909
www.comodo.com

Comodo CA Limited, Registered in England No. 04058690
Registered Office:
  3rd Floor, 26 Office Village, Exchange Quay,
  Trafford Road, Salford, Manchester M5 3EQ

This e-mail and any files transmitted with it are confidential and intended
solely for the use of the individual or entity to whom they are addressed.
If you have received this email in error please notify the sender by replying
to the e-mail containing this attachment. Replies to this email may be
monitored by Comodo for operational or business reasons. Whilst every
endeavour is taken to ensure that e-mails are free from viruses, no liability
can be accepted and the recipient is requested to use their own virus checking
software.
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Modulus length (was Re: Draft CA information checklist)

[Eddy Nigg (StartCom Ltd.)]

Rob Stradling:

Additionally, most of the times the old and the new root will be both
present in NSS for some time in order to allow a smooth transition,
until the old root is being removed.


Eddy, I think you've missed the main point of my proposal.  I am suggesting
that each existing valid-for-too-long 1024-bit RSA Root Certificate should be
replaced with a valid-for-not-too-far-beyond-2010 1024-bit RSA Root
Certificates *WITH THE SAME KEY*.
   


Sorry Rob, yes I missed that one. But why doing that? Why not replace 
with something better and remove the "offending" root? Perhaps I'm not 
objective enough because we actually replaced a small key with a bigger 
one. What's the logic for having a pile of roots which expire in 2010? 
Sorry for being slow...can you explain to me the logic of your proposal 
(again)?



Regards
Signer: Eddy Nigg, StartCom Ltd. 
Jabber: [EMAIL PROTECTED] 
Blog:   Join the Revolution! 
Phone:  +1.213.341.0390


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

Re: Modulus length (was Re: Draft CA information checklist)

[Rob Stradling]

On Thursday 05 June 2008 12:05:42 Eddy Nigg (StartCom Ltd.) wrote:
> Rob Stradling:
> >> Rob, in the past, any time that we have suggested that a CA issue a new
> >> root CA cert for any reason, even if only to change something minor,
> >> we've received much feedback saying that doing so represents a huge
> >> challenge and investment for the CAs, necessitating modifications to
> >> CPSes, triggering new audits, etc. etc.  One gets the impression from
> >> those replies that this is something the CAs would rather avoid at
> >> (nearly) all cost.
> >
> > I'm not convinced a new audit would be required, and I don't think CPS
> > changes are quite as expensive as the CAs you cite have suggested.
>
> Yes, I agree with you. I suppose that this is part of the key management
> a CA performs, which in itself is audited. Issuing new keys according to
> the defined procedures and CP/CPS doesn't require re-auditing per se,
> perhaps only if there were substantial other changes to the
> infrastructure which aren't related to the mere issuing of additional keys.
>
> > Also...just a thought...I wonder if any part of the Mozilla CA
> > Certificate Policy could be updated to make 1024-bit Root Certificate
> > replacement less hassle?
>
> I don't agree however with this. CAs usually have to go through the full
> cycle for having roots included and we shouldn't make other exceptions.
> The EV inclusions were exceptionally rushed enough I'd say...Also it's
> an excellent opportunity to review CAs which sometimes never were really
> looked at.

I have no objection to Mozilla reviewing "CAs which sometimes never were 
really looked at" in days gone by.  :-)

> Additionally, most of the times the old and the new root will be both
> present in NSS for some time in order to allow a smooth transition,
> until the old root is being removed.

Not so.  With my proposal, the old and new roots would *not* both be present 
in any NSS versions.  The old one would be removed when the new one gets 
added.

Eddy, I think you've missed the main point of my proposal.  I am suggesting 
that each existing valid-for-too-long 1024-bit RSA Root Certificate should be 
replaced with a valid-for-not-too-far-beyond-2010 1024-bit RSA Root 
Certificates *WITH THE SAME KEY*.

> > On a kind-of-related note...
> > Bug 406794.  GlobalSign want to do something very similar
>
> No, this isn't the same really, it's not a new key per se.

Precisely.  So, as I said, it is the same thing.

> > Could that behaviour of NSS be changed?
> > If future NSS versions were to treat "authorityCertSerialNumber" as
> > merely a hint, then I don't think that any certs would need to be
> > reissued for my proposal to work.
>
> Mhhh, maybe I'm missing something here, but how should replacing a root
> with a different key and key size not have an effect on this? Certs will
> have to be issued from the new root at some point and I'm not sure how a
> certificate signed from a 1024 bit key doesn't require re-issuance from
> a new 2048 key if the old key becomes obsolete and the EE cert is still
> valid.
>
>
> Regards
> Signer:   Eddy Nigg, StartCom Ltd. 
> Jabber:   [EMAIL PROTECTED] 
> Blog: Join the Revolution! 
> Phone:+1.213.341.0390



-- 
Rob Stradling
Senior Research & Development Scientist
Comodo - Creating Trust Online
Office Tel: +44.(0)1274.730505
Fax Europe: +44.(0)1274.730909
www.comodo.com

Comodo CA Limited, Registered in England No. 04058690
Registered Office:
  3rd Floor, 26 Office Village, Exchange Quay,
  Trafford Road, Salford, Manchester M5 3EQ

This e-mail and any files transmitted with it are confidential and intended
solely for the use of the individual or entity to whom they are addressed.
If you have received this email in error please notify the sender by replying
to the e-mail containing this attachment. Replies to this email may be
monitored by Comodo for operational or business reasons. Whilst every
endeavour is taken to ensure that e-mails are free from viruses, no liability
can be accepted and the recipient is requested to use their own virus checking
software.
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Modulus length (was Re: Draft CA information checklist)

[Eddy Nigg (StartCom Ltd.)]

Rob Stradling:

Rob, in the past, any time that we have suggested that a CA issue a new
root CA cert for any reason, even if only to change something minor,
we've received much feedback saying that doing so represents a huge
challenge and investment for the CAs, necessitating modifications to
CPSes, triggering new audits, etc. etc.  One gets the impression from
those replies that this is something the CAs would rather avoid at
(nearly) all cost.
 


I'm not convinced a new audit would be required, and I don't think CPS changes
are quite as expensive as the CAs you cite have suggested.
   


Yes, I agree with you. I suppose that this is part of the key management 
a CA performs, which in itself is audited. Issuing new keys according to 
the defined procedures and CP/CPS doesn't require re-auditing per se, 
perhaps only if there were substantial other changes to the 
infrastructure which aren't related to the mere issuing of additional keys.



Also...just a thought...I wonder if any part of the Mozilla CA Certificate
Policy could be updated to make 1024-bit Root Certificate replacement less
hassle?
   


I don't agree however with this. CAs usually have to go through the full 
cycle for having roots included and we shouldn't make other exceptions. 
The EV inclusions were exceptionally rushed enough I'd say...Also it's 
an excellent opportunity to review CAs which sometimes never were really 
looked at.


Additionally, most of the times the old and the new root will be both 
present in NSS for some time in order to allow a smooth transition, 
until the old root is being removed.



On a kind-of-related note...
Bug 406794.  GlobalSign want to do something very similar
   


No, this isn't the same really, it's not a new key per se.



Could that behaviour of NSS be changed?
If future NSS versions were to treat "authorityCertSerialNumber" as merely a
hint, then I don't think that any certs would need to be reissued for my
proposal to work.
   


Mhhh, maybe I'm missing something here, but how should replacing a root 
with a different key and key size not have an effect on this? Certs will 
have to be issued from the new root at some point and I'm not sure how a 
certificate signed from a 1024 bit key doesn't require re-issuance from 
a new 2048 key if the old key becomes obsolete and the EE cert is still 
valid.



Regards
Signer: Eddy Nigg, StartCom Ltd. 
Jabber: [EMAIL PROTECTED] 
Blog:   Join the Revolution! 
Phone:  +1.213.341.0390


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

Re: Modulus length (was Re: Draft CA information checklist)

[Rob Stradling]

On Wednesday 04 June 2008 21:59:54 Paul Hoffman wrote:
> > ...
> >   - There may be some (solvable, I think) interoperability problems for
> > CAs that choose to include the "authorityCertSerialNumber" field in the
> > Authority Key Identifier extension of certificates issued by their
> > 1024-bit Root Certificates.
>
> Not sure what you mean here.

Please see the follow-up comments from myself and Nelson.  I hope they explain 
this issue enough.

> >Am I trying to make things too complicated?
> >Or does anybody think that this idea is worth considering?
>
> Definitely worth considering.
> ___
> dev-tech-crypto mailing list
> dev-tech-crypto@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-tech-crypto



-- 
Rob Stradling
Senior Research & Development Scientist
Comodo - Creating Trust Online
Office Tel: +44.(0)1274.730505
Fax Europe: +44.(0)1274.730909
www.comodo.com

Comodo CA Limited, Registered in England No. 04058690
Registered Office:
  3rd Floor, 26 Office Village, Exchange Quay,
  Trafford Road, Salford, Manchester M5 3EQ

This e-mail and any files transmitted with it are confidential and intended
solely for the use of the individual or entity to whom they are addressed.
If you have received this email in error please notify the sender by replying
to the e-mail containing this attachment. Replies to this email may be
monitored by Comodo for operational or business reasons. Whilst every
endeavour is taken to ensure that e-mails are free from viruses, no liability
can be accepted and the recipient is requested to use their own virus checking
software.
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Modulus length (was Re: Draft CA information checklist)

[Rob Stradling]

On Wednesday 04 June 2008 21:32:17 Nelson B Bolyard wrote:
> Rob Stradling wrote, On 2008-06-04 04:45:
> >   2. Give each affected CA the opportunity to submit a replacement
> > 1024-bit RSA Root Certificate for inclusion in new versions of Mozilla
> > software.  Each of these replacement Root Certificates would exactly
> > match the to-be-removed Root Certificate (in terms of Subject name,
> > Public Key and Subject Key Identifier), but would have a different Serial
> > Number and a more acceptable Not After date.
>
> That plan appeals to me.

:-)

> > Disadvantages:
> >   - Each affected CA would have to spend some time reissuing their Root
> > Cetificate.
>
> Rob, in the past, any time that we have suggested that a CA issue a new
> root CA cert for any reason, even if only to change something minor,
> we've received much feedback saying that doing so represents a huge
> challenge and investment for the CAs, necessitating modifications to
> CPSes, triggering new audits, etc. etc.  One gets the impression from
> those replies that this is something the CAs would rather avoid at
> (nearly) all cost.

I'm not convinced a new audit would be required, and I don't think CPS changes 
are quite as expensive as the CAs you cite have suggested.

Also...just a thought...I wonder if any part of the Mozilla CA Certificate 
Policy could be updated to make 1024-bit Root Certificate replacement less 
hassle?

On a kind-of-related note...
Bug 406794.  GlobalSign want to do something very similar to what I've 
suggested, albeit with a 2048-bit Root Key and extending (rather than 
reducing) the expiry date.  It's obviously not too much of "a huge challenge 
and investment" for them.

> >   - There may be some (solvable, I think) interoperability problems for
> > CAs that choose to include the "authorityCertSerialNumber" field in the
> > Authority Key Identifier extension of certificates issued by their
> > 1024-bit Root Certificates.
>
> Yes, that's also an issue.  NSS treats AKID extensions as requirements.
> When the issuer says to the relying party, through an AKID extension,
> "you must rely on the issuer cert with this issuer name and serial number"
> NSS does so.  I'm afraid the solution, for CAs that used that field,
> may be for them to reissue certs with the offending AKID extension.

Could that behaviour of NSS be changed?
If future NSS versions were to treat "authorityCertSerialNumber" as merely a 
hint, then I don't think that any certs would need to be reissued for my 
proposal to work.

> We keep telling CAs NOT to include the part of an AKID that names the
> issuer's issuer and the issuer's serial number, but many CAs keep on doing
> it anyway.  The OpenSSL programs that create certs do that by default,
> IINM, requiring extra work (I gather) to avoid including that info in the
> AKID.  I have suspected for some time now that the reason CAs keep
> including that info is because they haven't figured out how to stop the
> OpenSSL program from doing so.  :(
>
> ___
> dev-tech-crypto mailing list
> dev-tech-crypto@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-tech-crypto



-- 
Rob Stradling
Senior Research & Development Scientist
Comodo - Creating Trust Online
Office Tel: +44.(0)1274.730505
Fax Europe: +44.(0)1274.730909
www.comodo.com

Comodo CA Limited, Registered in England No. 04058690
Registered Office:
  3rd Floor, 26 Office Village, Exchange Quay,
  Trafford Road, Salford, Manchester M5 3EQ

This e-mail and any files transmitted with it are confidential and intended
solely for the use of the individual or entity to whom they are addressed.
If you have received this email in error please notify the sender by replying
to the e-mail containing this attachment. Replies to this email may be
monitored by Comodo for operational or business reasons. Whilst every
endeavour is taken to ensure that e-mails are free from viruses, no liability
can be accepted and the recipient is requested to use their own virus checking
software.
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Entrust EV request

[Eddy Nigg (StartCom Ltd.)]

Frank Hecker:

Eddy Nigg (StartCom Ltd.) wrote:
   

Does the document http://www.entrust.net/CPS/pdf/webcps051404.pdf not
apply for this root and if so how do you know about it?
 


Per Entrust, at present this root has only one subordinate CA, the
"Entrust Certification Authority - L1A" used to issue EV certificates.
So in that sense, yes, the governing CPS for the hierarchy is the EV CPS.
   


That's nice, but how can *I* also know about it? Would it be possible to 
confirm it at the bug (that only EV certificates will be issued from 
that root ) and remove the OV attribute from 
http://www.mozilla.org/projects/security/certs/pending/#Entrust ?



Regards
Signer: Eddy Nigg, StartCom Ltd. 
Jabber: [EMAIL PROTECTED] 
Blog:   Join the Revolution! 
Phone:  +1.213.341.0390

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

PKCS#11 compliance test suite for NSS

[Amit Goel]

Hi All,

we have a PKCS#11 library for windows platform. How can we test the
same for NSS PKCS#11 compliance test? Is there any testing tool
available for the compliance test? I have seen some Netscape test
suite code but I am not able to able build it on windows. Is someone
able to compile the test tool?

regards,
Amit Goel
Sr. Developer
Safenet Inc
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

PKCS#11 compliance test suite for NSS

[lovrguru]

Hi All,

we have a PKCS#11 library for windows platform. How can we test the
same for NSS PKCS#11 compliance test? Is there any testing tool
available for the compliance test? I have seen some Netscape test
suite code but I am not able to able build it on windows. Is someone
able to compile the test tool?

regards,
Amit Goel
Sr. Developer
Safenet Inc
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto