Greetings. I'm running NSS 3.11.4 and would like write / read ECDSA
certificates. Does the current version support ECDSA? I have no
problem creating, for example, DSA cert requests, but trying to use
-k ecdsa fails with:
certutil -k: ecdsa is not a recognized type.
At 9:41 AM -0800 1/8/07, Nelson B wrote:
Paul Hoffman wrote:
Greetings. I'm running NSS 3.11.4 and would like write / read ECDSA
certificates. Does the current version support ECDSA? I have no
problem creating, for example, DSA cert requests, but trying to use
-k ecdsa fails
At 12:47 PM -0800 1/8/07, Nelson B wrote:
Paul Hoffman wrote:
At 9:41 AM -0800 1/8/07, Nelson B wrote:
Paul Hoffman wrote:
Greetings. I'm running NSS 3.11.4 and would like write / read ECDSA
certificates. Does the current version support ECDSA? I have no
problem creating, for example
At 3:50 PM -0800 1/10/07, Nelson Bolyard wrote:
Paul Hoffman wrote:
Numerous optional features of NSS builds are controlled through make
variables. Make variables may be set on the gmake command line, e.g.
gmake variable=value variable=value target1 target2
or defined in the environment, e.g
:
Unrecognized elliptic curve (null)
certutil: unable to generate key(s)
: error 0
#
Do I need to build with another make variable, or do I need to call
certutil with an additional argument?
--Paul Hoffman
___
dev-tech-crypto mailing list
dev-tech-crypto
At 6:33 AM -0500 1/12/07, David Stutzman wrote:
Paul Hoffman wrote:
: An I/O error occurred during security authorization.
More clues?
I got that error trying to do a keygen myself when the security
database didn't have a master password set.
reference:
http://groups-beta.google.com
At 11:40 AM -0700 3/13/07, Bob Relyea wrote:
In addition, we only parse these kinds of constraints on
intermediate certs (we currently don't have a mechanism to place
name constraints on a trusted root. Even if the trusted root had
constraints itself, they would be ignored once we identify the
At 10:00 AM + 3/14/07, Gervase Markham wrote:
Paul Hoffman wrote:
A related question that I was intending to do some research on: if
a trust anchor (trusted root in this thread) has an expiration
date in the past, doe NSS still treat it as a trust anchor, or does
it ignore it?
I can't
At 1:15 AM -0700 3/27/07, Nelson B wrote:
Here's a suggestion for the participants in this thread.
Instead of all this conjecture, imagining various bad designs for NSS and
then criticizing them, try to figure out how the products *really* work.
Did that and failed. It may be my stupidity, or it
At 4:30 PM +0100 4/12/07, Gervase Markham wrote:
Paul Hoffman wrote:
At 10:00 AM + 3/14/07, Gervase Markham wrote:
Paul Hoffman wrote:
A related question that I was intending to do some research on: if a
trust anchor (trusted root in this thread) has an expiration date
in the past
This is very good to hear. I have no idea if this is true for other
browsers or OS components that have root stores.
Man, this would be a good research project for some adventurous undergrad.
___
dev-tech-crypto mailing list
At 4:13 AM -0700 4/16/07, Kyle Hamilton wrote:
I should mention that on the [EMAIL PROTECTED] list, there's been a fair amount
of discussion on this topic. The concept that is put forth is that
the trust anchor is the key -- and any metadata that the key surrounds
itself with (such as a
At 9:39 PM -0700 4/29/07, Nelson Bolyard wrote:
I propose that we add additional requirements to the policy for root CAs
that apply for inclusion in mozilla products. I propose that we require a
minimum key size for the root CA cert *AND* for any intermediate CA certs
issued by that root CA cert.
At 11:54 AM -0400 5/1/07, Frank Hecker wrote:
Paul Hoffman wrote:
At 2:12 PM -0700 4/30/07, Robert Relyea wrote:
I don't see a way around the legacy 1024 bit certs, but I would
definately want to see wording that will discourage the issuance of
new root certs that are less than 2048
At 9:32 AM -0700 5/2/07, Wan-Teh Chang wrote:
Again, while we are at it, how about mandating SHA-246? We can safely
assume complete deployment of it within five years.
I assume you meant SHA-256.
Give or take 10, yes. :-)
If SHA-256 won't be made available
in Windows XP, this is equivalent
At 10:49 AM -0700 5/10/07, Nelson Bolyard wrote:
j.fabre wrote:
The common name´s length si 51, and there are the hexadecimal print of
the commonName :
[snip]
20 --
41 --A
47 --G
ff ff ff dc --Ü - Here is the problem, but this
character could be coded in UTF-8,
At 6:06 PM +0100 5/24/07, Gervase Markham wrote:
Paul Hoffman wrote:
That makes the assumption that all domains from those countries are in
the countries' TLDs; that is a bad assumption.
You mean that these CAs will not be able to sign certificates for some
sites that they might want to (e.g
At 9:09 PM -0700 5/25/07, Nelson Bolyard wrote:
Paul Hoffman wrote:
My feeling is that we would be better off not making this leap of
limitation. Either someone is allowed to certify in all domain names, or
in none.
Paul, that argument sounds to me like you're saying that constraining
At 12:47 PM -0700 5/26/07, Kyle Hamilton wrote:
On May 26, 2007, at 11:06 AM, Paul Hoffman wrote:
If we adopt that model, they can. But, again, that's not what this
thread was about. It was about Mozilla unilaterally constraining the
names without asking the user based on a feature of the audit
At 10:26 PM +0300 5/27/07, Eddy Nigg (StartCom Ltd.) wrote:
I just want to add a thought or two after following this thread from
the sidelines...
Paul Hoffman wrote:
I don't know if I like the idea of saying that a commercial
organization has more authority to identify for global commerce than
At 10:10 AM +0100 5/28/07, Gervase Markham wrote:
Paul Hoffman wrote:
Exactly. I strongly suspect that KISA would do a better job at checking
identification of a Korean company in .com than the CAs in the lowest
quartile of capabilities whom we fully trust to do so.
But do we fix
At 10:18 AM +0100 5/28/07, Gervase Markham wrote:
Paul Hoffman wrote:
The current thread is about a proposal that says, in essence, we are
willing to accept a secret audit of a trust anchor that we cannot see
from a national government security agency, but if we accept that, the
trust
At 4:53 PM +0100 5/30/07, Gervase Markham wrote:
Gervase Markham wrote:
My proposal is that we accept such CAs, but use this technical
capability to restrict them to signing certificates for domains under
the appropriate TLD.
Having considered the discussion, it looks like this idea is not
See http://www.vpnc.org/ietf-trust-anchor. There has already been a
lot of good discussion about the requirements, but more is certainly
useful. The protocol would certainly be of use to Mozilla for
updating the trust anchor store in Firefox, Thunderbird, and so on.
--Paul Hoffman
At 11:06 AM +0100 6/28/07, Gervase Markham wrote:
Eddy Nigg (StartCom Ltd.) wrote:
Under section 6 of the Mozilla CA policy
(http://www.mozilla.org/projects/security/certs/policy/) it states:
/provide some service relevant to typical users of our software products/
This CA seems to issue
on.
--Paul Hoffman
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
Greetings again. I have a need for a version of Firefox that allows
me to pick the specific ciphersuite offered in a TLS exchange. Having
not seen this in any Firefox plugin or extension, I suspect that this
might not be possible, but I could have missed the extension.
Does anyone know of a
Sorry, I didn't get time to respond to your message yesterday.
Will there be a cutoff for when Mozilla requires audits against the
final guidelines instead of allowing draft guidelines?
--Paul Hoffman
___
dev-tech-crypto mailing list
dev-tech-crypto
At 3:56 AM -0800 2/13/08, Kyle Hamilton wrote:
Why, as a user, am I being asked by ANYONE in this forum if I can
point to any CA that is violating their CPS, or 'not keeping up with
their auditing'? Why does anyone even remotely think that this is
appropriate?
Because you, alone, brought it up.
at Microsoft. I'm
hoping that this quoted sentence and others like it are not what they
mean.
--Paul Hoffman
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
Here is a slightly edited version of what a lead security developer
at Microsoft told me with regard to EKUs and path processing.
To the core issue. Does EKU need to be in the root certificate. The
answer is: no.
Every root certificate is stored with some properties that are not
At 6:21 PM +0100 3/5/08, Jean-Marc Desperrier wrote:
Paul Hoffman wrote:
[...]
For this to work, Microsoft path validation also checks that the end
certificate is consistent with the EKU property of the root. This part
adds to X.509 and rfc 3280bis.
:s/adds to/conflicts with/
Actually, I
At 11:09 PM -0400 3/25/08, Frank Hecker wrote:
As long as
domain names can be re-registered to different owners, there is always
this potential to some degree. It doesn't matter whether the cert
lifetime is 10 years, 1 year, or 1 week.
Exactly right. A CA re-affirms the binding between the public
At 2:59 PM +0300 4/17/08, Eddy Nigg (StartCom Ltd.) wrote:
The only thing I must notice is the fact that they issue from this CA
root, Non-EV certificates directly, whereas EV certificates are issued
through an intermediate CA certificate, according to the guidelines. I
suspect however that this
At 10:48 AM -0400 5/2/08, Frank Hecker wrote:
On Fri, May 2, 2008 at 8:08 AM, Eddy Nigg (StartCom Ltd.)
[EMAIL PROTECTED] wrote:
In comment https://bugzilla.mozilla.org/show_bug.cgi?id=431621#c5 the
representative of DigiNotar (Kick) notes that their CA root has been
cross-signed by
are of concern
is confusing at best.
--Paul Hoffman
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
sizes that we
are telling all users to trust. Either we tell them to trust
everything equally because we have vetted it, or they should trust
nothing.
--Paul Hoffman
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https
from a security perspective.
--Paul Hoffman
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
At 9:45 PM -0700 5/29/08, Justin Dolske wrote:
Paul Hoffman wrote:
Unless Mozilla says we are going to yank that particular Verisign
certificate, and all the ones with similar key lengths, decades before
they expire, there is absolutely no reason for us to, 20 years in
advance, start
*all* ECC certs with Cause for further checking
due to the very low amount of interop testing that has been done with
them. Again, not to say don't do this, just we want to ask a few
questions that might start a dialog.
--Paul Hoffman
___
dev-tech-crypto
At 9:49 PM +0300 5/30/08, Eddy Nigg (StartCom Ltd.) wrote:
Paul Hoffman:
Again, I strongly strongly doubt that Mallory will try to break a
1024-bit key for this attack, at least for 20 years or more.
I'm not sure from where you got this information
RFC 3766, which is considered the best
At 10:14 AM +0100 6/4/08, Gervase Markham wrote:
Paul Hoffman wrote:
Proposal:
a) Starting January 1 2009, all new CA roots must be 2048 bit RSA or 256
bit EC.
Why January 1 2009 particularly?
No big reason. It gives us six months to agree. If we take longer,
just add months to the date
At 12:45 PM +0100 6/4/08, Rob Stradling wrote:
For those 1024-bit RSA Root Certificates that are *already included* in
Mozilla software, I think that a distinction should be drawn between:
A. Those that expire before NIST's 2010 deadline.
B. Those that expire soon after 2010.
C. Those
At 2:20 AM -0700 6/6/08, Kyle Hamilton wrote:
The NIST date and EV date are the dates when they should no longer be
used, not 'no longer admitted for use', unless I'm completely
misreading the table on page 66 of the NIST SP800-57.
You are not misreading the table. That's a do not use after date.
At 12:54 PM -0700 6/6/08, Nelson B Bolyard wrote:
I recall a long discussion on this list in which certain people observed
(or opined) that the cert path validation algorithm defined in RFC 3280
has the characteristics you describe above. That is, the claim was made
that RFC 3280's algorithm does
of the certified party.
--Paul Hoffman
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
At 11:22 AM +0200 6/9/08, Jean-Marc Desperrier wrote:
Paul Hoffman wrote:
[...]
Sure, but that's not the model most CAs have with their customers. I
would bet that if a CA sent out a message saying we're revoking your
cert tomorrow, here's a new one to all of its affected customers, fewer
At 2:56 PM -0700 6/9/08, Nelson B Bolyard wrote:
Paul Hoffman wrote, On 2008-06-09 09:41:
At 11:22 AM +0200 6/9/08, Jean-Marc Desperrier wrote:
Aren't the people who send their credit card number on an https
connexion where the private key of the server is public knowledge
already screwed
At 7:50 PM -0700 6/9/08, Nelson B Bolyard wrote:
Paul Hoffman wrote, On 2008-06-09 18:31 PDT:
At 2:56 PM -0700 6/9/08, Nelson B Bolyard wrote:
a CA that tries to save the customer by revoking the possibly-compromised
domain's keys is overstepping its responsibility.
The keys in question
At 3:01 PM +0200 6/11/08, Jean-Marc Desperrier wrote:
I might have reacted a bit too strongly on this news.
+1
At 2:56 PM +0200 6/11/08, Jean-Marc Desperrier wrote:
Also I'd need to search for more reference, but I've been reading that
the factorisation of the 2^1039-1 Mersenne number
Has anyone validated the ECC paramters they used?
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
At 9:27 AM -0400 7/18/08, Frank Hecker wrote:
Paul Hoffman wrote:
Has anyone validated the ECC paramters they used?
Not that I'm aware.
I think that's unfortunate. It is easy for all of us to test the
parameters for RSA certs, but few of us have software for testing ECC
certs.
There's
http://ask.slashdot.org/article.pl?sid=08/07/18/1721234
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
At 6:18 PM -0400 7/18/08, Frank Hecker wrote:
Paul Hoffman wrote:
At 9:27 AM -0400 7/18/08, Frank Hecker wrote:
Paul Hoffman wrote:
Has anyone validated the ECC paramters they used?
Not that I'm aware.
I think that's unfortunate. It is easy for all of us to test the
parameters
At 5:15 PM -0700 7/18/08, Nelson B Bolyard wrote:
Paul Hoffman wrote, On 2008-07-18 16:16:
http://ask.slashdot.org/article.pl?sid=08/07/18/1721234
It's gratifying to see the numbers of people who do understand PKI and
are refuting the usual ignorant nonsense. It appears to me
At 3:24 PM -0700 7/18/08, Wan-Teh Chang wrote:
On Fri, Jul 18, 2008 at 1:58 PM, Paul Hoffman [EMAIL PROTECTED] wrote:
There's a test site with a Comodo-issued ECC cert at
https://comodoecccertificationauthority-ev.comodoca.com/
...which no browser will let me into. :-)
and the Comodo
At 11:04 AM +0100 7/19/08, Rob Stradling wrote:
I think that the ECDSA signature algorithms will only be supported in OpenSSL
0.9.9 (not yet released) and above.
Try a recent openssl-SNAP-2008mmdd.tar.gz from ftp://ftp.openssl.org/snapshot
instead.
Will do.
Non-mandatory question: what
Paul Hoffman wrote:
At 3:24 PM -0700 7/18/08, Wan-Teh Chang wrote:
On Fri, Jul 18, 2008 at 1:58 PM, Paul Hoffman [EMAIL PROTECTED]
wrote:
There's a test site with a Comodo-issued ECC cert at
https://comodoecccertificationauthority-ev.comodoca.com/
...which no browser will let me
phoffman 21196 Sep 9 13:44 nss.def
-rw-r--r-- 1 phoffman phoffman 33720 Sep 9 13:44 nssinit.o
-rw-r--r-- 1 phoffman phoffman 2876 Sep 9 13:44 nssver.o
Any clues how I can move forwards on this?
--Paul Hoffman
___
dev-tech-crypto mailing list
dev
At 2:56 PM -0700 9/9/08, Nelson B Bolyard wrote:
Paul Hoffman wrote, On 2008-09-09 13:52:
Greetings again. I'm trying to build 3.12 on FreeBSD 7.0. I follow
the directions on
http://www.mozilla.org/projects/security/pki/nss/nss-3.11.4/nss-3.11.4-build.html
and do the CVSing. 'gmake
At 5:28 PM -0700 9/9/08, Wan-Teh Chang wrote:
On Tue, Sep 9, 2008 at 4:52 PM, Paul Hoffman [EMAIL PROTECTED] wrote:
I nuked mozilla/* and used the two cvs commands above. The make
now ends with:
/usr/bin/ld: cannot find -lnssutil3
gmake[3]: ***
[FreeBSD7.0_DBG.OBJ/FreeBSD_SINGLE_SHLIB
I just added build instructions for 3.11.4 and 3.12.1 to the page
http://developer.mozilla.org/En/NSS_reference/Building_and_installing_NSS/Build_instructions
Thank you. That page has a *lot* of variables that the
3.11.4-specific page does not.
I see that you, Paul, were the last previous
Greetings again. Are people aware of any IPsec implementations using
NSS's crypto, even as a non-default build option?
--Paul Hoffman
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
At 2:29 PM -0700 9/22/08, Nelson B Bolyard wrote:
Ian G wrote, On 2008-09-22 09:45:
Hi all,
Hi Ian,
This reply isn't complete. I'm just going to discuss the questions with
easy answers.
* the following extended key usage fields within roots:
+ Server Authentication
+ Client
be easier to read :)
But is not as good of a reference. Understanding SP 800-57 is
probably just as valuable as understanding RFC 5280, if not more so.
--Paul Hoffman
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https
At 4:23 PM -0700 9/23/08, Nelson B Bolyard wrote:
Paul Hoffman wrote:
At 2:29 PM -0700 9/22/08, Nelson B Bolyard wrote:
In CA certs, NSS understands the EKUs to mean this CA can only issue
certs valid for these purposes, rather than meaning that the CA cert
itself can be used for those
At 4:59 PM -0700 9/23/08, Nelson B Bolyard wrote:
In finality, you have to pick a table from someone you believe has done a
really good job of analyzing it.
Right.
Given that NIST's tables are the basis
for the US Government's protection of its own secrets, which it guards
jealously, I'm
At 3:02 PM +0300 10/3/08, Eddy Nigg wrote:
Here I wanted to add something...it's not that we should prevent
intermediate third-party CAs or cross-signing, but we need to apply the
same requirements on all CAs.
But we don't. All the legacy CAs have different requirements put on them. To
me, this
At 11:13 AM -0700 10/17/08, Nelson B Bolyard wrote:
A root that revokes itself invokes the liar's paradox.
NSS wishes to avoid the fate of the android Norman. :)
Sorry, but that's a bit too glib. A suicide note is one valid method of trust
anchor management. It does not invoke the
At 2:45 AM + 10/18/08, Frank Hecker wrote:
Yes, but as I understand it what is being discussed here is a more elaborate
scheme whereby, for example, we (Mozilla) might run an actual CA just for the
purpose of cross certifying the roots that we accept. Like Nelson, I can't
remember who
the expertise here for any of us to be
stating the One True Solution.
--Paul Hoffman
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
At 2:02 PM + 10/21/08, Frank Hecker wrote:
Paul Hoffman wrote:
If you want to to be able to revoke roots, please consider instead
getting active in the current work on TAMP (trust anchor management
protocol) being discussed in the PKIX WG.
Thanks for the suggestion; I presume that
http
At 4:39 PM +0100 10/22/08, Gervase Markham wrote:
Julien R Pierre - Sun Microsystems wrote:
If the root could revoke itself, in the case of root cert key
compromise, ie. the root cert's private key becoming public, anybody
could then sign revocation information for that root CA - whether to
-of-the-pants management task as it is today, but it is also hopefully
less of a mess because it can be done outside of the software update cycle.
--Paul Hoffman
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org
At 9:42 AM -0700 10/24/08, Robert Relyea wrote:
Paul Hoffman wrote:
Robert: you are already in that business by distributing trust anchors that
you have (sometimes) vetted. You are a CA without signing anything, just by
distributing a trust anchor repository.
Yes, but by doing so we aren't
Well, all the arguments have been heard on this already, and positions are
fairly entrenched. It seems futile to have the debate over and over, and I
for one would like to point out that it is uncomfortable to treat it like a
political campaign.
Perhaps a vote?
Not for me, but perhaps a
At 11:52 AM -0800 11/10/08, Nelson Bolyard wrote:
DNSSEC only attempts to ensure that you get the (a) correct IP address.
s/only/only currently/
You can stick any data you want in the DNS. Currently the most popular data is
the A record (IP address) associated with a domain name, but is it
At 8:20 PM +0200 11/15/08, Eddy Nigg wrote:
Lets stay focused!
This thread started off with a purported newbie having a problem with seeing
self-signed certs where she shouldn't have. It then morphed into a discussion
of security UI design. Then it went to what users shold and should not be
At 6:13 AM -0800 12/6/08, [EMAIL PROTECTED] wrote:
Initially I posted this on another support forum, but was kindly
requested to post here instead:
I have created a X.509 v3 client certificate using OpenSSL.
The CN and OU field contain UTF8 characters, in this case Thai
characters for testing
At 11:27 AM -0800 12/23/08, Kyle Hamilton wrote:
I'd rather deal with disruption caused thereby (and, yes, the user
complaints generated thereby -- at least then the end-user would KNOW
that there's a problem that's being dealt with rather than having a
FALSE SENSE OF SECURITY) than let those
At 3:15 PM +0200 12/23/08, Eddy Nigg wrote:
If they don't shut that site, we can perhaps just publish the private key for
the mozilla.com certificate as well so everybody can enjoy it.
It is indeed unbelievable to hear the COO of a CA company making threats like
this. I'm sure that making such
At 2:51 PM -0800 12/23/08, Kyle Hamilton wrote:
I believe that Startcom (and other certification authorites in
Mozilla's root program) would likely have cause to bring an action for
the tort of negligence against Mozilla. I feel that this is something
that Mozilla should likely ask its general
At 1:16 AM +0200 12/24/08, Eddy Nigg wrote:
Select Preferences - Advanced - View Certificates - Authorities. Search for
AddTrust AB - AddTrust External CA Root and click Edit. Remove all Flags.
This would remove the trust from the potentially affected sites and their
certificates. Comodo has
, and the
folks who might remove Comodo from the root pile are following the issue,
probably more closely than they are letting on. Do you really think oh, but if
only Paul Hoffman would be critical, then things will really change?
FWIW, I would be shocked if you could not get the same result (a cert
) cert list
I haven't tried this myself, but it should work. I have been told that
something very similar to it works fine in XP/Vista for IE.
--Paul Hoffman
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org
At 11:35 AM -0800 12/24/08, Kyle Hamilton wrote:
In the terminology of ASN.1 and PKIX, I want a standardized PKIX
extension that allows for a SEQUENCE OF Certificate within the
tbsCertificate structure.
That makes no sense to me, but I would have to see a complete proposal to
understand why you
At 1:46 PM -0800 12/24/08, Nelson B Bolyard wrote:
Paul Hoffman wrote, On 2008-12-24 09:55:
- Remove all trust anchors one-by-one
- Add your single trust anchor
- Sign the certs of any CA you want
- Add those signed certs to the pre-loaded validation path (not root)
cert list
Of course
At 11:13 PM -0800 12/24/08, Daniel Veditz wrote:
Paul Hoffman wrote:
At 1:16 AM +0200 12/24/08, Eddy Nigg wrote:
Select Preferences - Advanced - View Certificates - Authorities.
Search for AddTrust AB - AddTrust External CA Root and click
Edit. Remove all Flags.
Doesn't this seem like
At 7:16 PM +0100 12/25/08, Michael Ströder wrote:
I'd tend to punish a rogue CA by removing their root CA cert from NSS.
Maybe this serves as a good example to other CAs that the Mozilla CA
policy is really enforced. Otherwise nobody will care.
This is Firefox we're talking about, not IE. Do you
as
possible to include no trust anchors that use MD5 in their signature algorithm.
Although the attack described in the paper does not directly affect MD2, it is
very likely that the same math used by the researchers could be applied to MD2
as well.
--Paul Hoffman
mechanism for NSS / Mozilla trust anchor stores would be
great.
I see no problem the schedule the removal of a trust flag. For security
reasons all users have to update browsers from time to time anyway. ;-}
Quite right.
--Paul Hoffman
___
dev-tech
At 1:16 PM -0800 12/30/08, Nelson B Bolyard wrote:
Paul Hoffman wrote, On 2008-12-30 12:43:
At 8:39 AM -0800 12/30/08, Nelson B Bolyard wrote:
The upshot of this is probably going to be that, in a short time, all
the world's browsers (and PKI software in general) stop supporting MD5
for use
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
At 11:05 AM -0800 1/2/09, geoff.tol...@gmail.com wrote:
On Dec 31 2008, 3:10 pm, Paul Hoffman phoff...@proper.com wrote:
I read that blog posting to mean that they were going to keep issuing certs
using MD5 signatures, but would use unpredictable sequence numbers like
other VeriSign CAs do
Why is this relevant to this mailing list?
--Paul Hoffman
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
with policy.
Thoughts?
--Paul Hoffman
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
Ian G wrote, On 2009-01-04 16:01:
On 4/1/09 21:32, Paul Hoffman wrote:
I propose that Mozilla form a new mailing list,
dev-policy-trustanchors. The topics for that list would include:
- All new trust anchors being added to the Mozilla trust anchor pile
- Proposals for changes to the Mozilla
At 6:08 PM +0200 1/5/09, Eddy Nigg wrote:
Therefor we can't lump just all failures together and as you correctly stated,
there is no clear line between one and the other. This is what I was saying.
What you said was As I see it, our case indeed was a bug, the Comodo case was
negligence. That
At 3:09 PM +0100 1/5/09, Ian G wrote:
The recent MD5 collision attack has also demonstrated a brittle side of OCSP
[1]:
http://blogs.technet.com/swi/archive/2008/12/30/information-regarding-md5-collisions-problem.aspx
It seems that, assuming we can create an intermediate or subroot certificate,
At 1:35 PM -0800 1/5/09, Wan-Teh Chang wrote:
On Sun, Jan 4, 2009 at 12:32 PM, Paul Hoffman phoff...@proper.com wrote:
I propose that Mozilla form a new mailing list, dev-policy-trustanchors. The
topics for that list would include:
- All new trust anchors being added to the Mozilla trust
1 - 100 of 141 matches
Mail list logo
