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\exten
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
asso
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
>
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/#En
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 availab
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
> 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
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 mo
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 p
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 certif
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
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
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
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 ?
M
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
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-
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 represent
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
CPSe
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
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 Cert
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
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 tes
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 tes
23 matches
Mail list logo
