On 14/1/09 06:47, Paul Hoffman wrote:
At 5:29 PM -0800 1/13/09, Julien R Pierre - Sun Microsystems wrote:
IMO, we don't have complete confidence that every CA and sub CA has closed the
MD5 hole yet,
What level of confidence do we seek?
Bearing in mind that complete confidence is a
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
and/or a
whitelist of
Paul Hoffman wrote:
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,
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 and/or a
whitelist of
On 13/1/09 10:16, Eddy Nigg wrote:
Before Mozilla yanks any root (which isn't something Mozilla does for
fun really), Mozilla will confront the CA with the concern and assumed
risk concerning the practice of the CA.
- Mozilla will give the CA reasonable time to address the concern -
where
On 01/13/2009 12:50 PM, Ian G:
Sorry, where is this documented? It looks unfamiliar and unworkable to me.
In which respect unworkable? Please explain.
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
Jabber: start...@startcom.org
Blog: https://blog.startcom.org
On 01/13/2009 02:09 PM, Ian G:
Let's work from Mozo's documentation. Where is it? Otherwise we are
liable to get distracted...
If this is not a documented situation, Rob already explained it. Or,
have a look at my comments on dropping the root is useless.
This is not documented, this is how
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
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.
Most CAs run businesses where written policies are the norm.
Mozilla is not a CA.
Where did Frank
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
On 01/13/2009 09:56 PM, Paul Hoffman:
We disagree here. I think it would be more problematic for Mozilla to be
accused of having hard-to-find policy changes than to simply change the policy
itself when needed.
I did not suggest that there should be hard-to-find policy changes at
all.
Ben Bucksch wrote:
I propose to announce that we'll stop supporting MD5 in 3 months, and
ask website owners to get new certs.
On the basis of any known risk?
The current attack requires the attacker to be able to get a cert signed
for a key they control. If all CAs stop using MD5 (which they
Gervase,
Gervase Markham wrote:
Ben Bucksch wrote:
I propose to announce that we'll stop supporting MD5 in 3 months, and
ask website owners to get new certs.
On the basis of any known risk?
The current attack requires the attacker to be able to get a cert signed
for a key they control. If
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
Eddy, I apologize if I'm misinterpreting your response to Paul's last comment,
but I think you are suggesting that Mozilla could hold a CA to doing
something that is 'currently in the 'problematic practices' wiki page,
purely because that wiki page is a document that is (you allege) presented
On 01/12/2009 01:08 PM, Rob Stradling:
Eddy, I apologize if I'm misinterpreting your response to Paul's last comment,
but I think you are suggesting that Mozilla could hold a CA to doing
something that is 'currently in the 'problematic practices' wiki page,
purely because that wiki page is a
On 01/12/2009 01:26 PM, Eddy Nigg:
Instead I think the policy should mention that such by-laws may exists -
as matter of fact section 4 deals with it more or less.
Incidentally section 13 could be lumped together with those by-laws
since it's only a recommendation. But we've discussed
Eddy, I agree that the Potentially Problematic Practices wiki page is a useful
resource during the information gathering period that happens *before* a
Root Certificate is ever accepted by Mozilla.
But (reading back a few messages in this thread), the context of this
discussion is Paul's
On 01/12/2009 03:07 PM, Rob Stradling:
Eddy, I agree that the Potentially Problematic Practices wiki page is a useful
resource during the information gathering period that happens *before* a
Root Certificate is ever accepted by Mozilla.
But (reading back a few messages in this thread), the
I believe that this is not only exactly what he is saying, but also
exactly what must be done.
Once a potentially problematic practice is shown to have moved from
potential to actual, it is a problematic practice. Once that
happens, it must be addressed.
CAs fall into a class of security called
On Monday 12 January 2009 13:30:35 Kyle Hamilton wrote:
I believe that this is not only exactly what he is saying, but also
exactly what must be done.
Once a potentially problematic practice is shown to have moved from
potential to actual, it is a problematic practice. Once that
happens, it
On 01/12/2009 03:59 PM, Rob Stradling:
Right now, as I see it, we have...
1). potential - The Potentially Problematic Practices wiki page.
2). actual - The Mozilla CA Certificate Policy.
So when a problem is shown to have moved from 'potential' to 'actual',
surely the way to address it would
On 12/1/09 22:03, Kyle Hamilton wrote:
On Mon, Jan 12, 2009 at 5:59 AM, Rob Stradlingrob.stradl...@comodo.com wrote:
On Monday 12 January 2009 13:30:35 Kyle Hamilton wrote:
I believe that this is not only exactly what he is saying, but also
exactly what must be done.
Once a potentially
If things have deteriorated to the point where the political hands are
tied, and the only way to get things done is to just make a change in
the code...
...how is the political structure helping the coders? Or anyone else?
-Kyle H
On Mon, Jan 12, 2009 at 1:23 PM, Ian G i...@iang.org wrote:
On
On 01/12/2009 11:37 PM, Kyle Hamilton:
If things have deteriorated to the point where the political hands are
tied, and the only way to get things done is to just make a change in
the code...
...how is the political structure helping the coders? Or anyone else?
Errr...how do you govern
On 09.01.2009 18:51, Johnathan Nightingale wrote:
SHA-1 is heading that way as well, and the decisions we make here will
likely shape policy for SHA-1's eventual decommissioning as well.
I think it's important to prepare now that we actually *can*
decommission SHA-1. This means:
* All popular
On 9/1/09 22:25, Johnathan Nightingale wrote:
Still, it's not nothing either, so if we don't mind extrapolating a bit:
it seems to me that end of 2010, while further out than I'd like, is
probably a good upper bound. At that point we'd have about 4000 valid,
md5 certs out there we'd be breaking,
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
At 5:18 PM +0100 1/10/09, Ian G wrote:
That I agree with, although I believe NIST's decisions will be a lot more
important. (Disclaimer: I sometimes consult for NIST.)
Ahhh... no, please! Mozilla needs to do its own analysis. If it can't make
up its own mind about MDs, which are the simplest
On 10/1/09 19:59, Paul Hoffman wrote:
At 5:18 PM +0100 1/10/09, Ian G wrote:
That I agree with, although I believe NIST's decisions will be a lot more
important. (Disclaimer: I sometimes consult for NIST.)
Ahhh... no, please! Mozilla needs to do its own analysis. If it can't make up
its
On 01/10/2009 08:59 PM, Paul Hoffman:
That's absurd. You can't hold a CA to doing something that we don't document.
Just a by-note on this one...It doesn't have to be in the CA Policy, but
may be also in some by-laws or as we have it currently in the
problematic practices. This document is
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
On 9/1/09 18:02, Paul Hoffman wrote:
At 11:41 PM +0100 1/8/09, Jan Schejbal wrote:
With that definition, SHA-1 is also not secure: its collision resistance has be
reduced from 2^80 to 2^60ish by similar attacks as for MD5.
Yes, the writing is on the wall for SHA-1 as well, and has been since
Yes, the writing is on the wall for SHA-1 as well, and has been since
2005 or so.
February 2005, here's my blog posts.
https://financialcryptography.com/mt/archives/000374.html
https://financialcryptography.com/mt/archives/000357.html
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 is not secure for applications that blindly
sign inputs
-Original Message-
On 1/9/09 12:51 PM, Johnathan Nightingale wrote:
- Do the work to arm ourselves so that when we are confident pulling
the trigger, we can actually do so with minimal changes (in case it
happens in a point release, for instance)
- Establish our feelings
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 is not
Ian,
Ian G wrote:
Yes, the writing is on the wall for SHA-1 as well, and has been since
2005 or so.
February 2005, here's my blog posts.
https://financialcryptography.com/mt/archives/000374.html
https://financialcryptography.com/mt/archives/000357.html
On 9-Jan-09, at 1:27 PM, Benjamin Smedberg wrote:
Perhaps it would help if we had some additional information such as:
what is
the maximum certificate expiration time? That is, if all CAs stopped
using
MD5 *today* and switched to SHA-256, how long would it be before
there were
no unexpired
On 1/9/09 4:25 PM, Johnathan Nightingale wrote:
On 9-Jan-09, at 1:27 PM, Benjamin Smedberg wrote:
Perhaps it would help if we had some additional information such as:
what is
the maximum certificate expiration time? That is, if all CAs stopped
using
MD5 *today* and switched to SHA-256, how
On 01/09/2009 11:32 PM, Benjamin Smedberg:
On 1/9/09 4:25 PM, Johnathan Nightingale wrote:
On 9-Jan-09, at 1:27 PM, Benjamin Smedberg wrote:
Perhaps it would help if we had some additional information such as:
what is
the maximum certificate expiration time? That is, if all CAs stopped
using
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
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 a cryptographic hash function to be called
43 matches
Mail list logo
