At 9:32 PM +0300 9/1/09, Eddy Nigg wrote:
On 09/01/2009 09:23 PM, Georgi Guninski:
On Mon, Aug 31, 2009 at 10:30:03PM +0800, Tobby Lau wrote:
certificates till 2010
2010 is 3 months away.
It is also a completely arbitrary date that NIST pulled out of its mumble;
folks at NIST are quite
At 3:16 PM +0200 7/9/09, Ian G wrote:
Although I haven't read it at all, normally what happens is that the strength
of an algorithm of X bits is X/2.
Say what!?! AES is an encryption function, not a hash function. AES-256 has a
strength of 256 bits.
--
dev-tech-crypto mailing list
At 8:08 PM +0300 7/8/09, Eddy Nigg wrote:
On 07/08/2009 08:03 PM, Peter Djalaliev:
There has been an attack on the full AES-256 algorithm with space and
time complexity of 2^119. Reportedly, the attack works on all keys.
The title of the paper (and the body, of course) says otherwise.
Funny
Peter Gutmann asked on a different mailing list:
Subject says it all, does anyone know of a public, commercial CA (meaning one
baked into a browser or the OS, including any sub-CA's hanging off the roots)
ever having their certificate revoked? An ongoing private poll hasn't turned
up anything,
At 4:27 PM -0700 4/30/09, Robert Relyea wrote:
Content-Type: multipart/signed; protocol=application/x-pkcs7-signature;
micalg=sha1; boundary=ms000907030103030804040502
Nelson B Bolyard wrote:
SHA-1 has taken a significant hit. See
At 6:32 AM -0800 2/27/09, Kyle Hamilton wrote:
The Unicode standard actually cross-references each character and
visually-indistinct glyph.
No, it doesn't.
Foisting this off on other bodies such as the the Unicode Consortium is only a
good idea when they actually are willing to take on the
At 12:49 PM +0100 2/26/09, Jean-Marc Desperrier wrote:
Just one thing : The use of a wildcard certificate was a misleading red
herring in the implementation of the attack.
What's truly broken is that the current i18n attack protection relies on the
checking done by the registrar/IDN, and that
and
revocation, some browser vendors
--Paul Hoffman
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
At 7:09 AM +0100 2/24/09, Kaspar Brand wrote:
Kyle Hamilton wrote:
Removal of support for wildcards can't be done without PKIX action, if
one wants to claim conformance to RFC 3280/5280.
Huh? Both these RFCs completely step out of the way when it comes to
wildcard certificates - just read the
At 1:14 PM +0100 2/23/09, Jean-Marc Desperrier wrote:
Paul Hoffman wrote:
TLD registries ask which language a name is in; some then do some
filtering based on what characters they think are used by particular
languages. This is far from a science and fails miserably for most
European languages
At 2:19 AM +0200 2/23/09, Eddy Nigg wrote:
You don't like that I mention particular CAs, but the one I'm affiliated with
does to some extend. ;-)
I do not like you mentioning particular CAs to advertise (yourself) or attack
(your competitor); asking for a list of CAs that implement policies
On Sat, Feb 21, 2009 at 1:19 PM, Paul Hoffman phoff...@proper.com wrote:
I don't see how the attack could have been done without wildcards. CA
guidelines say that certificates should not be issued with homographic
characters that might cause confusion
They do? Where?
I believe that Unicode
At 1:28 PM -0500 2/20/09, Benjamin Smedberg wrote:
On 2/20/09 12:11 PM, Nelson B Bolyard wrote:
Benjamin Smedberg wrote, On 2009-02-19 07:39:
It sounds to me that we could and should fix this bug simply by disabling
punycode for the wildcard portion.
I'm not sure what you're proposing here,
At 7:58 PM -0800 2/12/09, Nelson B Bolyard wrote:
Recently, a CA that uses partitioned CRLs applied to admission to
the Mozilla/NSS root CA list. Our choices appear to be:
1) Do not admit their root until support for partitioned CRLs is done.
(There is no active plan of record to do that work at
Seems to me that this is another case where we're having problems
because we're using a term (CPS) which is widely understood, but
for which more than one meaning exists. As long as we continue to
use it without defining it, we will have problems of people seeming
to agree, but having different
At 5:09 PM + 2/4/09, Frank Hecker wrote:
1. To what extent do typical CPSs and CPs address this issue? In other words,
if we were to read the average CPS/CP, would it have language that would
unambiguously tell us whether our policy requirement were met or not? Or is
this something that's
At 6:23 PM -0800 2/4/09, Kyle Hamilton wrote:
There are two states in the NIST key state transition diagram that are
appropriate to this entire concept... compromised (state entered
when the private information associated with it -- i.e., the private
key and its passphrase, and has only one
At 12:29 PM +0100 2/1/09, Ian G wrote:
On 31/1/09 17:08, Paul Hoffman wrote:
If a trust anchor has a CRL that is too large for for the implementation to
handle, the implementation MUST remove that trust anchor from its pile.
Wouldn't it be better to mark those certificates in the same way
On 31/1/09 03:56, Kyle Hamilton wrote:
The PKIX standard can deal with problems of this extent.
If an implementation of the standard cannot, then the implementation
is nonconforming, and cannot be expected to interoperate.
Do you mean, an implementation should be able to deal with a CRL of any
It is kind of sad that this discussion has become CAs should not revoke
certificates when the private keys are exposed because Java cannot handle CRLs
reliably. That says more about the failures of Java than it does failures in
PKIX.
--Paul Hoffman
--
dev-tech-crypto mailing list
dev-tech
At 12:53 PM +0100 1/29/09, Ben Bucksch wrote:
On 27.01.2009 05:20, Gervase Markham wrote:
https://bugzilla.mozilla.org/show_bug.cgi?id=475473
filed to create mozilla.dev.security.policy. And please let's not have a
bikeshed discussion about the name.
Sorry to do just that, but I think it's
At 1:21 PM +0100 1/29/09, Jean-Marc Desperrier wrote:
Eddy Nigg wrote:
[...]
Well, this thread started out with the request that Mozilla should
change it's policy to require CAs revoke certificate when the private
key is known to be compromised.
Given the practical problems of revoking a very
Is this useful for people?
Yes. If for some reason you need to stop supporting this wonderful, please let
this list know in advance. I, for one, would be willing to take it over.
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
At 3:45 PM -0800 1/21/09, Nelson B Bolyard wrote:
Perhaps Mozilla should change its policy to require CAs to revoke certs
when the private key is known to be compromised, whether or not an attack
is in evidence, as a condition of having trust bits in Firefox.
Fully agree.
--Paul Hoffman
--
dev
the extension, it wouldn't
really add much value.
--Paul Hoffman
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
At 11:16 AM +0200 1/13/09, Eddy Nigg wrote:
On 01/13/2009 10:15 AM, Rob Stradling:
Eddy, I do think that the Mozilla CA Certificate Policy should cover
*all* actual problematic practices. In this particular case, I think that
a blacklist of unsupported/non-allowed/not-recommended algorithms
At 9:00 PM +0200 1/13/09, Eddy Nigg wrote:
On 01/13/2009 05:23 PM, Paul Hoffman:
Useful yes, up to certain extend. If there is too much information in the
policy, it will start to be problematic.
For whom?
For Mozilla mostly.
We disagree here. I think it would be more problematic for Mozilla
At 5:29 PM -0800 1/13/09, Julien R Pierre - Sun Microsystems wrote:
Just because root CAs have stopped using MD5 doesn't mean every intermediate
CA in the world has stopped yet. It would be a fairly arduous task to
determine that. If a sub CA hasn't stopped using MD5 yet, they may be subject
to
At 1:52 PM +0100 1/12/09, Ian G wrote:
These are word games. What is the definition of these words? If you look in
the RFCs, likely (I have not, please correct me if I am wrong)
A better idea would be for all of us to read them and point out where in the
document it says something.
For
At 10:07 PM +0100 1/12/09, Ian G wrote:
* RFC5280 is an implementation document and doesn't do
semantics much, if at all.
* It does not define the meaning of expiry or revocation.
* By _meaning_, I mean semantics, what outsiders should take
as the message being delivered,
At 1:42 PM -0800 1/12/09, Kyle Hamilton wrote:
Technically, 'expiration' is also an action taken by the CA.
No, it is an action taken by time passing. When the time in the univers is the
same as the time listed as notAfter in the cert, the cert expires. That's it.
It's
basically saying, I
At 2:48 PM -0800 1/12/09, Nelson B Bolyard wrote:
I explain it to people this way: The notAfter date is the date after which
the CA has no further obligation to report that the cert was ever revoked.
Yes, quite right.
(It actually is obliged to report revocation ONE more time after the
notAfter
The main difference is that my solution would force all MD5 certs out of
circulation by the given date, no matter their expiration date,
...for no valid security reason...
while yours would allow MD5 certs with long validity periods to stay in use.
...because there is no security problem with
, so they just advanced the timetable. No discussion
needed.
Please re-read the paper that described the attack. The authors discussed the
attack with all of the named CAs. No discussion needed is just plain naive.
--Paul Hoffman
___
dev-tech-crypto
At 11:41 PM +0100 1/8/09, Jan Schejbal wrote:
MD5 is not secure for applications that blindly sign inputs from non-trusted
parties that can predict the content of the part of the message before the
submitted text. This is an attack on the collision-resistance of the function.
I assume that for
At 12:42 AM +0200 1/9/09, Eddy Nigg wrote:
On 01/09/2009 12:15 AM, Nelson B Bolyard:
It requires that CAs NEVER forget about any certs they previously
issued, not even after they expire. It means that a CA's list of revoked
certs will grow boundlessly. It makes CRLs become impractically big.
At 12:51 PM -0500 1/9/09, Johnathan Nightingale wrote:
On 8-Jan-09, at 3:45 PM, Paul Hoffman wrote:
At 6:51 PM +0100 1/8/09, Jan Schejbal wrote:
As the MD5 algorithm is obviously not secure anymore,
This statement is not based on reality, so the rest of the message does not
follow. MD5
At 6:51 PM +0100 1/8/09, Jan Schejbal wrote:
As the MD5 algorithm is obviously not secure anymore,
This statement is not based on reality, so the rest of the message does not
follow. MD5 is not secure for applications that blindly sign inputs from
non-trusted parties that can predict the
Is there any way I can suck back the last two messages I sent on this thread
and pretend they never happened? sigh I guess not.
Please ignore my assertions about what the AIA extension does: I was completely
wrong. As we were making the AIA extension in the PKIX WG, we discussed
multiple
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
At 4:01 PM -0800 1/5/09, Nelson B Bolyard wrote:
Paul Hoffman wrote, On 2009-01-05 08:54:
At 3:09 PM +0100 1/5/09, Ian G wrote:
[...] Hence, once we rogue-players have created a certificate like this,
the CA cannot revoke it using its own control mechanisms. [...]
I am not convinced
At 6:51 PM -0800 1/5/09, Julien R Pierre - Sun Microsystems wrote:
Paul,
Paul Hoffman wrote:
3) A corollary of (2): Even when parent == grandparent, and hence parent
is also a sibling, it's not generally true that you can use the OCSP URL
from the parent to check the OCSP status of a child.
All
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
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
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
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
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 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
) 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: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
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 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 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
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
-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
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
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
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: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
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 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 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
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
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
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
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
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
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
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 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
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 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
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 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
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
1 - 100 of 141 matches
Mail list logo
