On Monday 29 December 2008 13:50:58 Eddy Nigg wrote:
There is now an interest article at the register:
http://www.theregister.co.uk/2008/12/29/ca_mozzilla_cert_snaf/
snip
Interesting that Comodo founded the CAB forum and Comodo created a
standard for domain control validation. I wonder where
On Tuesday 30 December 2008 22:07:08 Kyle Hamilton wrote:
I would suggest requiring all new roots approved to state that they do
not and will not use MD5 in any newly-minted certificate (except
possibly in a configuration like the TLS pseudo-random function).
FWIW, Comodo have never signed
On Tuesday 30 December 2008 22:22:11 Gervase Markham wrote:
Ian G wrote:
As far as I heard, the CABForum was also formed or inspired from a
similar group of vendors (browsers) that got together at the invite of
the Konqueror guy to talk about phishing one day ...
I'm fairly sure it wasn't
Ahh...I did it from my Vista workstation's firefox profile which I knew had the
roots module added. Nssckbi.dll or libnssckbi.so or whatever it is on a Mac is
a special PKCS#11 module that is read-only and contains the trust anchors. By
default with an NSS database, it's not added. You can
-Original Message-
From: On Behalf Of Nelson B Bolyard
Sent: Tuesday, December 30, 2008 2:25 PM
Attempting to create a 128 byte (1024 bit) aes key on the token:
C:\nss\fipssymkeyutil -K -n aesKey3 -t aes -s 128 -d .
Enter Password or Pin for NSS FIPS 140-2 Certificate DB:
aesKey3
KyleMac:.netscape kyanha$ modutil -add roots -libfile
/Applications/Firefox.app/Contents/MacOS/libnssckbi.dylib -dbdir .
WARNING: Performing this operation while the browser is running could cause
corruption of your security databases. If the browser is currently running,
you should exit browser
Eddy Nigg wrote:
perhaps Mozilla should start to use EV
certs for the update mechanism of Firefox and *enforce* it? There might
be many other sites which potentially could wreak havoc not measurable
in terms of money only.
Perhaps we should. Can you file a bug about this, please? There may be
Kyle Hamilton wrote:
Hmmm... actually, it would be possible, but only with the cooperation
of the CAs.
We currently know the EV policy OIDs for EV-enabled roots. What we
don't know is the policy OIDs assigned for different types of
validation,
...nor do we have, more to the point, a
On 31/12/08 15:38, Gervase Markham wrote:
Eddy Nigg wrote:
perhaps Mozilla should start to use EV
certs for the update mechanism of Firefox and *enforce* it? There might
be many other sites which potentially could wreak havoc not measurable
in terms of money only.
Perhaps we should. Can you
On 12/31/2008 04:36 PM, Gervase Markham:
Kyle Hamilton wrote:
Hmmm... actually, it would be possible, but only with the cooperation
of the CAs.
We currently know the EV policy OIDs for EV-enabled roots. What we
don't know is the policy OIDs assigned for different types of
validation,
...nor
On 31/12/08 01:31, Ben Bucksch wrote:
On 30.12.2008 23:34, Kyle Hamilton wrote:
That difference /can/ be communicated to the end-user, unobtrusively.
Sure, but they can't use that information. I just asked a friend whether
she knows what VeriSign is - she never heard of it. If you have no
Kyle Hamilton wrote, On 2008-12-31 06:36 PST:
KyleMac:.netscape kyanha$ modutil -add roots -libfile
/Applications/Firefox.app/Contents/MacOS/libnssckbi.dylib -dbdir .
WARNING: Performing this operation while the browser is running could cause
corruption of your security databases. If the
Kyle Hamilton wrote:
Ummm... has an enterprise PKI ever been included in Mozilla?
Sorry, I wasn't being clear here. I'm not referring to enterprises that
have their own root CAs. I was referring to schemes where enterprises
work through CAs like VeriSign to issue certificates to their own
Nelson, I wonder if anything from this thread has any bearing here as you
describe some FIPS restrictions:
http://groups.google.com/group/mozilla.dev.tech.crypto/browse_thread/thread/a5d22af274d36c6a?pli=1
I've been trying to help out Alex in the Sun forums and pointed him over here
with this
If I wrap/unwrap with a token object RSA key, I get a different error trying to
encrypt with the unwrapped AES key:
RSA key from NSS DB: SunPKCS11-NSSfips RSA private key, 2048 bits (id
2464323849, token object, sensitive, extractable)
pulled sym key out of keystore? SunPKCS11-NSSfips AES
David Stutzman wrote, On 2008-12-31 11:30:
If I wrap/unwrap with a token object RSA key, I get a different error
trying to encrypt with the unwrapped AES key:
RSA key from NSS DB: SunPKCS11-NSSfips RSA private key, 2048 bits (id
2464323849, token object, sensitive, extractable)
pulled sym
Frank Hecker wrote, On 2008-12-31 10:48 PST:
Nelson B Bolyard wrote:
A representative of Verisign has posted a response to this issue at
https://blogs.verisign.com/ssl-blog/2008/12/on_md5_vulnerabilities_and_mit.php
The VeriSign post is not 100% clear on exactly how VeriSign has removed
Personally, I cannot see that there is an imminent danger. The attack
requires substantial resource, unpublished techniques, dramatic timing
attempts and retrys and no doubt other caveats ... and will be stopped
whenever MD5 is dropped, which is apparantly very soon or already.
See the
Bug 471734. Poking around Apple's developer site, the only thing I
can come up with for error -2804 is cfragNoLibraryErr, with the
description The named library was not found.
I'm also seeing that some functions in the code fragment library were
deprecated in 10.5, but I can't find information
At 6:48 PM + 12/31/08, Frank Hecker wrote:
Nelson B Bolyard wrote:
A representative of Verisign has posted a response to this issue at
https://blogs.verisign.com/ssl-blog/2008/12/on_md5_vulnerabilities_and_mit.php
The VeriSign post is not 100% clear on exactly how VeriSign has removed this
On 12/31/2008 08:57 PM, Frank Hecker:
employees, servers, etc. IIRC in a number of these schemes the CA is
responsible for actually issuing the certificates but the validation is
done by the enterprise. (For example, the CA might provide a web-based
interface by which authorized representatives
On 12/31/2008 12:30 PM, Rob Stradling:
Yes, Reseller and RA are 2 distinct roles. However, in some cases, a single
entity may choose (and be approved) to perform both of these roles.
I fully agree that the Reseller role should not perform any validation
procedures at all.
Robin, could you
Kaspar Brand wrote:
Michael Ströder wrote:
I'd love to have an option to forbid CRMFRequest calls...
Not too difficult to achieve, actually. Just add this line to your
prefs.js:
user_pref(capability.policy.default.Crypto.generateCRMFRequest, noAccess);
That may work now, but capability
23 matches
Mail list logo
