Date to disable/remove remaining MD2/MD5 roots from NSS
Kathleen Wilson
with MD2 and MD5 signature algorithm.
There are currently 7 CAs who have root certificates with MD2 or MD5
signatures algorithms in NSS. Three of those CAs are ready for these
roots to be disabled/removed now, and are included in bug #534274. Two
of these CAs have requested a date of December 31, 2010. One of the CAs
has requested a later date.
Proposed date for disabling or removing MD2/MD5 roots from NSS: December
15, 2010.
Caveats to proposed date:
1) Mozilla may disable/remove all MD2 and MD5 root certificates when
there is reason to believe that successful MD5 pre-image attacks are
imminent. If this situation occurs, it may be the case that Mozilla
will need to respond first to the threat by disabling/removing such
roots, and then follow up with communication.
2) As per bug #534274, CAs may request that their MD2/MD5 roots be
disabled or removed from NSS earlier.
Note: The reason I am proposing the date of December 15, 2010, is
because most of us are on holiday on December 31, so I don�t think that
December 31 can be a truly actionable date.
I look forward to your feedback on this proposed date for final
disablement/removal of MD2 and MD5 roots from NSS.
Kathleen
David E. Ross
> There are currently 7 CAs who have root certificates with MD2 or MD5
> signatures algorithms in NSS.
She also wrote:
> Three of those CAs are ready for these
> roots to be disabled/removed now, and are included in bug #534274. Two
> of these CAs have requested a date of December 31, 2010. One of the CAs
> has requested a later date.
But this only adds up to six. What about the seventh?
Will there be a new bug report on this, or will all these be covered by
bug #534274?
--
David E. Ross
<http://www.rossde.com/>
Go to Mozdev at <http://www.mozdev.org/> for quick access to
extensions for Firefox, Thunderbird, SeaMonkey, and other
Mozilla-related applications. You can access Mozdev much
more quickly than you can Mozilla Add-Ons.
Eddy Nigg
> Three of those CAs are ready for these roots to be disabled/removed
> now, and are included in bug #534274. Two of these CAs have requested
> a date of December 31, 2010. One of the CAs has requested a later date.
I think one CA requested end of 2009.
>
> Proposed date for disabling or removing MD2/MD5 roots from NSS:
> December 15, 2010.
> Note: The reason I am proposing the date of December 15, 2010, is
> because most of us are on holiday on December 31, so I don’t think
> that December 31 can be a truly actionable date.
>
We should start to take into account that today it's not only about the
hash, but also key size is going to play role here. With some luck, 1024
bit RSA keys are going to be broken within the next 2-6 years I guess.
At least a demonstration will happen within that time.
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
XMPP: star...@startcom.org
Blog: http://blog.startcom.org/
Twitter: http://twitter.com/eddy_nigg
Nelson Bolyard
> This is a proposal for the date to disable or remove all remaining roots
> with MD2 and MD5 signature algorithm.
Why? Who cares? What problem will it solve?
We don't rely on the signature algorithm (or the signature) in trusted
roots, so it doesn't matter. We could disable MD2 and MD5 signature
algorithms on cert TODAY, with those certs still in place, without any
detrimental effect on those certs.
You can test this for yourself today. There's an environment variable by
which you can turn off all use of MD2 and MD5 in cert signature processing
right now (assuming you have a reasonably recent build) and see how it
affects you.
If it has no detrimental effect on those few remaining root certs with MD2
and MD5 signatures, then why take steps to remove them?
Eddy Nigg
> On 2010-01-15 10:37 PST, Kathleen Wilson wrote:
>
>> This is a proposal for the date to disable or remove all remaining roots
>> with MD2 and MD5 signature algorithm.
>>
> Why? Who cares? What problem will it solve?
>
> We don't rely on the signature algorithm (or the signature) in trusted
> roots, so it doesn't matter. We could disable MD2 and MD5 signature
> algorithms on cert TODAY, with those certs still in place, without any
> detrimental effect on those certs.
>
>
>
I believe there is an interest in removing 1024 bit RSA keys. I agree
that the hashes are not really relevant for the root store in NSS - it
might have for other so. Because of that I think Mozilla should proceed
as planed.
Kathleen Wilson
>> disabled/removed now, and are included in bug #534274.
>> Two of these CAs have requested a date of December 31,
>> 2010. One of the CAs has requested a later date.
>
Yes, you are correct that there is a seventh that I didn’t
address in my posting. Discussions are ongoing with that CA.
However, they did stop issuing certs under their MD2/MD5 roots
in 2009, and they are working towards the end of 2010 date.
> Will there be a new bug report on this, or will all these
> be covered by bug #534274?
There will be new bug reports for the disablement/removal of
the remaining MD2/MD5 roots.
> We should start to take into account that today it's not only about
> the hash, but also key size is going to play role here. With some
> luck, 1024 bit RSA keys are going to be broken within the next 2-6
> years I guess. At least a demonstration will happen within that time.
Correct. This is really about 1024-bit key size. We’re starting with
MD2/MD5 roots, and next we’ll focus on the SHA1 1024-bit roots.
That will be another discussion thread, but hopefully CAs are already
planning not to issue certs under their 1024-bit SHA1 roots after
this year. More to come on that in a separate thread.
>> Why? Who cares? What problem will it solve?
>> We don't rely on the signature algorithm (or the signature) in
>> trusted roots, so it doesn't matter. We could disable MD2 and MD5
>> signature algorithms on cert TODAY, with those certs still in place,
>> without any detrimental effect on those certs.
>
> I believe there is an interest in removing 1024 bit RSA keys.
Correct. The interest is in disabling/removing roots with 1024-bit
key size. We are taking a phased approach, starting with the
MD2/MD5 roots. SHA1 1024-bit roots will be next.
Thank you for your contributions to this discussion. I will leave it
open a while longer before finalizing the date.
Kathleen
Nelson Bolyard
> On 2010-01-15 10:37 PST, Kathleen Wilson wrote:
>> This is a proposal for the date to disable or remove all remaining roots
>> with MD2 and MD5 signature algorithm.
>
> Why? Who cares? What problem will it solve?
Let me ask that question another way.
What problem are you trying to solve with the proposed change?
Is it your objective to disable dependence on MD5 in certificate
signatures?
If so, then do so now!
There is NO NEED to remove or disable or replace any roots first.
We disabled MD2 support in certificate signatures 9 months ago.
We did not disable MD5 support at that time because it was reported that
there were still some intermediate CA certificates in widespread use
whose signatures were made with MD5. Those certs, and the server certs
subordinate to them, would stop working if we disabled MD5 before they
were replaced with certs that don't use MD5.
If you want to try disabling MD5 in cert signatures now, set an environment
variable in your environment and then restart your browser.
setenv NSS_HASH_ALG_SUPPORT=-MD2,-MD5
or
export NSS_HASH_ALG_SUPPORT=-MD2,-MD5
David E. Ross
And how do I do this in Windows XP?
M.Hunstock
>> export NSS_HASH_ALG_SUPPORT=-MD2,-MD5
> And how do I do this in Windows XP?
http://support.microsoft.com/kb/310519
cheers
Kathleen Wilson
> signatures?
>
> If so, then do so now!
>
> There is NO NEED to remove or disable or replace any roots first.
Thank you for clarifying this for me. Now I see that first I need
to find out when we can use the environment variable to turn off MD5
without causing undue hardship to the relevant CAs, but as soon
as possible.
The actual disablement/removal of the roots may happen later as
more of a matter of keeping our root store clean of roots that
are no longer in use or audited. I will still need to track this,
but it can be on a CA-by-CA basis.
I will send email to the CAs with MD5 roots to find out if they
have all already migrated their intermediate certificates off of MD5,
and the date by which all of their end-entity certs will no longer
be dependent on MD5 intermediate certificates.
I will also start a separate discussion about phasing out all
1024-bit roots (regardless of hash algorithm).
Before sending email to the CAs about turning off MD5, I have a couple
of questions...
1) Does anyone know of a website whose SSL cert chains up to an
MD5 intermediate certificate? If yes, please provide the url,
so I can try setting the environment variable and see the affect.
2) Is there any technical documentation about this environment
variable that I can point the CAs to? e.g. documentation about
exactly what will happen when the variable is set to turn off
MD5, from root to intermediate to end-entity certs.
I greatly appreciate your help/guidance on this.
Kathleen
Jean-Marc Desperrier
>> If you want to try disabling MD5 in cert signatures now, set an environment
>> > variable in your environment and then restart your browser.
>> > setenv NSS_HASH_ALG_SUPPORT=-MD2,-MD5
>> > or
>> > export NSS_HASH_ALG_SUPPORT=-MD2,-MD5
> And how do I do this in Windows XP?
I wonder if there would be a way to get such environment variable set
through prefs.js instead of using the OS.
There is an xpcom interface to access environment variables,
https://developer.mozilla.org/en/NsIEnvironment with id
"@mozilla.org/process/environment;1" , it seems you'd have to use the
Dropfox extension to run custom js inside user.js
Gervase Markham
> Thank you for clarifying this for me. Now I see that first I need
> to find out when we can use the environment variable to turn off MD5
> without causing undue hardship to the relevant CAs, but as soon
> as possible.
To clarify (I hope): if we were to do this disablement in Firefox, I
doubt it would actually be done by setting an environment variable on
the user's machine. More likely, we would set a preference which would
tweak the relevant internal knob on NSS.
IOW, you can use the environment variable on your local machine to see
the effect, but this would not be the mechanism we'd use if we rolled
out this change.
Gerv
Kathleen Wilson
> To clarify (I hope): if we were to do this disablement in Firefox, I
> doubt it would actually be done by setting an environment variable on
> the user's machine. More likely, we would set a preference which would
> tweak the relevant internal knob on NSS.
Correct, we would change the default setting of the environment variable
in the code.
However, first I need to figure out how to communicate this clearly
to the relevant CAs, and determine when we can make this change
without causing undue hardship.
Thanks,
Kathleen
Kyle Hamilton
mechanism to "dry run" the proposed disablement of MD5.
It would likely be easier to contact all CAs and find out from each
when their last MD5-signed intermediate certificate expires, or when
the last end-entity certificate issued by one of those intermediates
expires, whichever comes first. The cut-off time should be 00:00:00
-1 second UTC on the latest date that is returned from the CAs. (I
only put it that way to handle the almost-negligibly rare situation of
a leap second on December 31.)
I propose first discovering (via Kathleen) that cut-off date, and then
(via the various release managers of the various Mozilla softwares)
scheduling version upgrades to be pushed starting at the stroke of
midnight of the GMT-defined day following that cut-off date, with MD5
disabled. Is there enough cooperation on security matters to make the
latter happen?
-Kyle H
> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
Eddy Nigg
> i.e., essentially what setting the environment does is provide a
> mechanism to "dry run" the proposed disablement of MD5.
>
> It would likely be easier to contact all CAs and find out from each
> when their last MD5-signed intermediate certificate expires, or when
> the last end-entity certificate issued by one of those intermediates
> expires, whichever comes first.
>
Really? MD5/4/2 on intermediate CA or end-user certificates isn't the
same as with roots (the issue Nelson recently mentioned). And what if
the last certificate would expire in 2025, we should wait for that?
Kathleen Wilson
> Really? MD5/4/2 on intermediate CA or end-user certificates isn't the
> same as with roots (the issue Nelson recently mentioned).
Signatures on trusted root certificates are not checked, so
turning off MD5 does not affect the roots.
The signatures on intermediate certificates are checked.
If we disable MD5, then users who rely on cert chains that
include intermediate certs with MD5 signatures will find those
chains stop working.
> And what if the last certificate would expire in 2025,
> we should wait for that?
No. All but one of the roots with MD5 signatures in NSS are
1024-bit, so if they are not disabled earlier, then they
will be disabled as part of the effort to phase out 1024-bit
roots. For the one root that is 2048-bit and MD5, that CA
is already phasing out that root, targeting the end of this year.
Eddy Nigg
> No. All but one of the roots with MD5 signatures in NSS are
> 1024-bit, so if they are not disabled earlier, then they
> will be disabled as part of the effort to phase out 1024-bit
> roots. For the one root that is 2048-bit and MD5, that CA
> is already phasing out that root, targeting the end of this year.
>
Right. However we don't know which intermediate or end-user certificates
there are with MD5 hashes. Considering that it's been a year since the
pre-image attack on MD5, I think CAs have already took appropriate
measures by now.
Kyle Hamilton
It might affect some software being able to have its signature
validated.
Still, I agree that it's time to get rid of MD5.
-Kyle H
Nelson Bolyard
Yes, that page describes one way. Another way is to use the "set"
command in a windows batch file that starts your browser, e.g.
startfirefox.bat which contains
set NSS_HASH_ALG_SUPPORT=-MD2,-MD5
start firefox
exit /B
Kathleen Wilson
I have created the following draft of a communication that I will send
to the relevant CAs. This will not go to the three CAs who have already
confirmed that their MD5 roots can be disabled or removed now. This
communication will only go to the four CAs who said that their MD5 roots
could be disabled at the end of this year or later.
Would you please review this communication for accuracy and clarity?
I greatly appreciate your assistance on this topic.
Kathleen
--
Dear Certification Authority,
As per our previous email exchange, Mozilla is planning to phase out
root certificates that are using MD5 signature algorithms. As such, I
request some additional information regarding each of your MD5 roots
that are included in NSS.
For the hierarchy under each of your MD5 root certificates that are
included in NSS, please send me the date on which the last end-entity
certificate issued by an MD5-signed intermediate certificate will expire.
Alternatively, please let me know if the hierarchy under each of your
MD5 root certificates that are included in NSS does not include
intermediate CAs with MD5 signatures.
Here is the background information for my request:
It has come to my attention that there is an environment variable in NSS
which can be used to turn off MD5 support, and that this can happen as
soon as I can verify that there are no root certificates included in NSS
that have active intermediate or end-entity certificates with MD5 hashes.
We would like to change the default setting of this NSS environment
variable as soon as possible from
NSS_HASH_ALG_SUPPORT=-MD2,+MD5 (currently only MD2 is turned off)
to
NSS_HASH_ALG_SUPPORT=-MD2,-MD5 (this would turn off MD5)
The affect of setting this NSS environment variable to turn off MD5 will
be as follows.
Root using MD5 signature algorithm: No affect, because signatures on
trusted root certificates are not checked.
Intermediate Certificate using MD5 signature algorithm: The signatures
on intermediate certificates are checked. Turning off MD5 will cause
end-entity certs chaining up to such intermediate certs to not be trusted.
End-Entity Certificate with an MD5 Hash: End-entity certificates that
were signed by an intermediate certificate with an MD5 signature will
not validate in Mozilla products when the NSS environment variable is
set to turn off MD5.
Mozilla and I will greatly appreciate your prompt response,
Kathleen
--
Eddy Nigg
> All,
>
> I have created the following draft of a communication that I will send
> to the relevant CAs. This will not go to the three CAs who have
> already confirmed that their MD5 roots can be disabled or removed
> now. This communication will only go to the four CAs who said that
> their MD5 roots could be disabled at the end of this year or later.
I think this looks good.
Kyle Hamilton
Mozilla's NSS team (the team which approved your request to be added
to the default set of roots included in Firefox and Thunderbird, among
others) is contemplating a change of policy, and we would like to know
how strongly impacted you and your customers will be.
Specifically, we plan to disable the MD5 hash algorithm for
verification in certificate chain, CRL, and OCSP responses. This
follows on the heels of last year's preimage attack against that
algorithm. Note that this does not affect your root certificate that
we have built into the software, as the hashes on each of them are not
checked when they come from the user's and software's trust store.
Here are some questions which you might find useful in identifying the impact:
1) How many intermediate certifiers exist under your root which have
been signed with the MD5 hash algorithm?
2) How many end-entity certificates exist (under your root's
MD5-issued intermediate certifiers) U (EE certificates signed by
non-affected intermediates but are still signed with MD5)?
2a) How many of these end-entity certificates have been issued to
people who or companies which are unwilling to accept a
re-certification under a new intermediate authority?
3) Is your CRL signed with MD5?
4) Are your OCSP responses signed with MD5?
Really, what we are looking for is the date when the last end-entity
certificate which verifies using MD5 at any link of the chain will
expire.
If your infrastructure requires changes, we recommend that you test
against Firefox and Thunderbird (and preferably against other browsers
that your root has been included in) before rolling it out. To help
you test with the proposed NSS setting to disable MD5, there is an
environment variable which you can set before you launch Firefox or
Thunderbird (or anything else which uses NSS):
cshell: setenv NSS_HASH_ALG_SUPPORT=-MD2,-MD5
bash: export NSS_HASH_ALG_SUPPORT=-MD2,-MD5
cmd.exe: set NSS_HASH_ALG_SUPPORT=-MD2,-MD5
(For reference, the default value is NSS_HASH_ALG_SUPPORT=-MD2,+MD5)
OSX users may create a shell script to launch Firefox or Thunderbird
with this configuration, or may set that environment variable in
.login . Windows users may create a batch file, or may set the
system-wide environment variable.
We request a response within 20 business days. This is a matter which
impacts the security of our users, and we cannot afford to take it
lightly; accordingly, if you do not respond, we will have to assume
that your hierarchy will not be affected.
Mozilla and the NSS team thank you very much for your time and prompt response.
Sincerely,
...
Kathleen Wilson
Awesome! Thanks, Kyle for your great wordsmithing and additional
information.
Kathleen
Eddy Nigg
>
> Awesome! Thanks, Kyle for your great wordsmithing and additional
> information.
>
>
He's truly the best ;-) Yeah
Kaspar Brand
> On 1/27/10 11:40 AM, Kyle Hamilton wrote:
>> Dear [Certification Authority],
>>
>> Mozilla's NSS team (the team which approved your request to be added
>> to the default set of roots included in Firefox and Thunderbird, among
>> others)
From my understanding, Frank and Kathleen were never members of the NSS
team, they approved these requests on behalf of MoFo.
>> Specifically, we plan to disable the MD5 hash algorithm for
>> verification in certificate chain, CRL, and OCSP responses. This
>> follows on the heels of last year's preimage attack against that
>> algorithm.
That's rubbish. A preimage attack and a chosen-prefix collision attack
are definitely not the same thing.
>> 1) How many intermediate certifiers exist under your root which have
>> been signed with the MD5 hash algorithm?
I would refrain from inventing new terms like "intermediate certifiers".
>> 2) How many end-entity certificates exist (under your root's
>> MD5-issued intermediate certifiers) U (EE certificates signed by
>> non-affected intermediates but are still signed with MD5)?
Do you expect a typical CA representative to correctly parse this sentence?
>> 2a) How many of these end-entity certificates have been issued to
>> people who or companies which are unwilling to accept a
>> re-certification under a new intermediate authority?
So, what do you do plan to do with the answers to this question? If
enough of them refuse to re-issue the cert, will you postpone the MD5
cut-off to something like 2020?
The most important piece of information from the point of view of a CA
is actually the *date* at which Mozilla currently intends to disable
MD5 (2012? 2015? 2025?). This is nowhere in (the draft of) that message,
right now.
>> Really, what we are looking for is the date when the last end-entity
>> certificate which verifies using MD5 at any link of the chain will
>> expire.
Again, what do you want to do with this finding? Only disable MD5 after
this date? Chances are quite high that Geotrust still issued 5-year
certs signed with md5WithRSAEncryption in January 2009 - so at least in
that case, we're at January 2014. Is this really useful information? (I
don't think so, unless we also know what share these certs will have in
the X.509 universe at what time in the future.)
>> cshell: setenv NSS_HASH_ALG_SUPPORT=-MD2,-MD5
>> bash: export NSS_HASH_ALG_SUPPORT=-MD2,-MD5
>> cmd.exe: set NSS_HASH_ALG_SUPPORT=-MD2,-MD5
NSS_HASH_ALG_SUPPORT=-MD5 is sufficient. People should also be told what
the behavior is when an MD5-based signature is encountered (you get
"Peer's certificate has an invalid signature"), and be provided with a
test site where they can verify that NSS_HASH_ALG_SUPPORT is really
enforced in their browser (i.e., an https page which MD5 somewhere in
the cert chain).
Kaspar
Kyle Hamilton
-Kyle H
On Wed, Jan 27, 2010 at 10:10 PM, Kaspar Brand <dsp...@velox.ch> wrote:
> On 27.01.2010 23:11, Kathleen Wilson wrote:
>> On 1/27/10 11:40 AM, Kyle Hamilton wrote:
>>> Dear [Certification Authority],
>>>
>>> Mozilla's NSS team (the team which approved your request to be added
>>> to the default set of roots included in Firefox and Thunderbird, among
>>> others)
>
> From my understanding, Frank and Kathleen were never members of the NSS
> team, they approved these requests on behalf of MoFo.
>
>>> Specifically, we plan to disable the MD5 hash algorithm for
>>> verification in certificate chain, CRL, and OCSP responses. This
>>> follows on the heels of last year's preimage attack against that
>>> algorithm.
>
> That's rubbish. A preimage attack and a chosen-prefix collision attack
> are definitely not the same thing.
>
>>> 1) How many intermediate certifiers exist under your root which have
>>> been signed with the MD5 hash algorithm?
>
> I would refrain from inventing new terms like "intermediate certifiers".
>
>>> 2) How many end-entity certificates exist (under your root's
>>> MD5-issued intermediate certifiers) U (EE certificates signed by
>>> non-affected intermediates but are still signed with MD5)?
>
> Do you expect a typical CA representative to correctly parse this sentence?
>
>>> 2a) How many of these end-entity certificates have been issued to
>>> people who or companies which are unwilling to accept a
>>> re-certification under a new intermediate authority?
>
> So, what do you do plan to do with the answers to this question? If
> enough of them refuse to re-issue the cert, will you postpone the MD5
> cut-off to something like 2020?
>
> The most important piece of information from the point of view of a CA
> is actually the *date* at which Mozilla currently intends to disable
> MD5 (2012? 2015? 2025?). This is nowhere in (the draft of) that message,
> right now.
>
>>> Really, what we are looking for is the date when the last end-entity
>>> certificate which verifies using MD5 at any link of the chain will
>>> expire.
>
> Again, what do you want to do with this finding? Only disable MD5 after
> this date? Chances are quite high that Geotrust still issued 5-year
> certs signed with md5WithRSAEncryption in January 2009 - so at least in
> that case, we're at January 2014. Is this really useful information? (I
> don't think so, unless we also know what share these certs will have in
> the X.509 universe at what time in the future.)
>
>>> cshell: setenv NSS_HASH_ALG_SUPPORT=-MD2,-MD5
>>> bash: export NSS_HASH_ALG_SUPPORT=-MD2,-MD5
>>> cmd.exe: set NSS_HASH_ALG_SUPPORT=-MD2,-MD5
>
> NSS_HASH_ALG_SUPPORT=-MD5 is sufficient. People should also be told what
> the behavior is when an MD5-based signature is encountered (you get
> "Peer's certificate has an invalid signature"), and be provided with a
> test site where they can verify that NSS_HASH_ALG_SUPPORT is really
> enforced in their browser (i.e., an https page which MD5 somewhere in
> the cert chain).
>
> Kaspar
Kathleen Wilson
> Kaspar, you bring up good points. I'll re-draft it.
No worries. I re-drafted my original using information from your recent
draft. The only concern from Kaspar that I mistakenly included
in my final email was the new term "intermediate certifiers".
I didn't realize it was a new term.
My main concern was in making sure that the information was technically
correct and complete. Your draft was very useful in that respect.
I have sent the email, so no need for further drafts. I have already
received information from two of the affected CAs saying that disabling
MD5 in this manner will not affect them.
Thank you all very much for your help with this. I greatly appreciate it!
Kathleen
Kyle Hamilton
"intermediate certifiers". I think that there is enough knowledge
about X.509 PKI inside companies that operate CAs that they can figure
out what it means.
You're right, though, I should have used the correct term for it.
-Kyle H
Rob Stradling
<snip>
> Again, what do you want to do with this finding? Only disable MD5 after
> this date? Chances are quite high that Geotrust still issued 5-year
> certs signed with md5WithRSAEncryption in January 2009 - so at least in
> that case, we're at January 2014. Is this really useful information? (I
> don't think so, unless we also know what share these certs will have in
> the X.509 universe at what time in the future.)
Hi Kaspar. Just in case anyone does think it's useful information, let me
confirm your speculation...
https://www.aspenexpeditions.com
It's currently using a 6-year cert signed by Geotrust with
md5WithRSAEncryption, issued Sept 2008 and expiring Sept 2014.
<snip>
Rob Stradling
Senior Research & Development Scientist
C·O·M·O·D·O
Eddy Nigg
> It's currently using a 6-year cert signed by Geotrust with
> md5WithRSAEncryption, issued Sept 2008 and expiring Sept 2014.
>
Which in itself is a disgusting practice, sorry to put it that bluntly.
Hopefully we'll have that "fixed" soon too.
Gervase Markham
> Which in itself is a disgusting practice, sorry to put it that bluntly.
If you are actually sorry, then please don't do it. If you aren't sorry,
then don't say you are.
I would remind you, and all participants here, that we would strongly
prefer to keep the language of debate civil and professional.
Gerv
Eddy Nigg
Calling something disgusting doesn't have to be unprofessional. :-)
But since we have also British members at this forum, I apologized
upfront to use such a word ;-)
rand...@verisign.com
VeriSign has strong concerns with the current plan you propose. We
maintain a large number of roots and intermediate certs, and even
though the vast majority of them don't use MD5, we have a few that do.
As of January 2009 we're not issuing any more MD5-based end-entity
certs, but we have a large number of certs in use today that are
signed using MD5. As noted earlier in this thread, some have long
validity periods. The number of MD5-based end-entity certs in use is
large enough that it is simply not possible for us to notify all these
customers and get them to reissue their cert. We'll pull together more
detail to determine when the number of active MD5 certs might fall to
a manageable number that we can deal with.
I know this is arguable, but MD5 isn't yet "broken". A chosen prefix
collision was demonstrated, but that doesn't mean that anyone can take
a signature from an existing MD5 cert and move it to their rogue cert.
Many customers, especially those with large numbers of certs, will
typically decide that unless the algorithm is demonstrably and easily
broken, they will live with their existing certs and phase them out in
the normal renewal cycle.
Another point to consider is that by the end of 2013, we need to get
all customers moved to 2048-bit end-entity certs and chain. We're
working on those 2048-bit chains, but until we have them we don't want
to try to force customers to move to a non-MD5 cert, then a year or so
later force them to move again to a 2048-bit chain.
Given these points, we suggest that Mozilla delays disabling MD5 until
the end of 2013 when you also phase out the use of 1024-bit chains. If
you do so before that, you run the risk of breaking a lot of existing
certs. It's possible that Firefox would be the only browser in which
they would appear broken, which may lead users to stop using it. And
the way it breaks is pretty jarring - the user is blocked from
proceeding without any chance of saying "I understand the risks;
please proceed".
Eddy Nigg
On 03/02/2010 01:05 AM, rand...@verisign.com:
> VeriSign has strong concerns with the current plan you propose. We
> maintain a large number of roots and intermediate certs, and even
> though the vast majority of them don't use MD5, we have a few that do.
> As of January 2009 we're not issuing any more MD5-based end-entity
> certs, but we have a large number of certs in use today that are
> signed using MD5. As noted earlier in this thread, some have long
> validity periods.
This is exactly one of the reasons why end-user certificates shouldn't
be issued for a longer period than they are manageable. Shorter periods
provides more flexibility.
> I know this is arguable, but MD5 isn't yet "broken". A chosen prefix
> collision was demonstrated, but that doesn't mean that anyone can take
> a signature from an existing MD5 cert and move it to their rogue cert.
>
I must agree with this statement however and many have gotten it wrong
what a pre-imaging attack exactly is - including some software vendors.
Still, I believe MD5 shouldn't be used really today.
> Many customers, especially those with large numbers of certs, will
> typically decide that unless the algorithm is demonstrably and easily
> broken, they will live with their existing certs and phase them out in
> the normal renewal cycle.
>
Hey, you are making the calls, not the customers. Since when do
customers decide what's secure? Would you be willing to issue MD2 certs
just because your customers feel that way?
> Another point to consider is that by the end of 2013, we need to get
> all customers moved to 2048-bit end-entity certs and chain. We're
> working on those 2048-bit chains, but until we have them we don't want
> to try to force customers to move to a non-MD5 cert, then a year or so
> later force them to move again to a 2048-bit chain.
>
I believe proper planning and foresight is obviously your
responsibility. As such, Mozilla might not be alone in such a move and
maybe not even the first. Microsoft's root program already hints at
disabling both 1024 bit keys and MD hashes as early as the end of this year.
Eddy Nigg
> I believe proper planning and foresight is obviously your
> responsibility. As such, Mozilla might not be alone in such a move and
> maybe not even the first. Microsoft's root program already hints at
> disabling both 1024 bit keys and MD hashes as early as the end of this
> year.
I was made aware of some possible misinterpretation and here a
correction: Microsoft requires that CAs must stop issuing 1024-bit RSA
intermediates and end-entity certificates by the end of 2010, and they
must stop issuing from 1024-bit RSA roots and intermediates (at that
date). Microsoft will revoke 1024-bit RSA root certificates only upon
public evidence of a vulnerability to 1024-bit RSA that may impact
specific root certificates.
Which means, that such certificate will remain trusted and working also
after that date and until 31st of December 2013 (maybe even beyond?).
Disabling MD5 certificates will also only happen upon a demonstrated
attack that makes specific root certificates vulnerable according to
Microsoft. This hasn't happen so far and pre-image attacks don't make an
exist root vulnerable.
rand...@verisign.com
> > typically decide that unless the algorithm is demonstrably and easily
> > broken, they will live with their existing certs and phase them out in
> > the normal renewal cycle.
>
> Hey, you are making the calls, not the customers. Since when do
> customers decide what's secure? Would you be willing to issue MD2 certs
> just because your customers feel that way?
In most cases, yes, customers look to us to make smart cryptographic
choices on their behalf. But sometimes it happens that a major
customer has a particular need for something that we wouldn't consider
best-practice. We try to work with them, but ultimately it comes down
to business. For example, when we started the process of terminating
our use of MD5, we learned of a major mobile phone middleware provider
whose middleware does not support SHA-1. If we had taken the
principled stand that we would not issue MD5 certs for them, their
platform would have ceased working, disabling millions of mobile
phones. And we could not have just handed them off to another CA,
because their platform is inextricably linked to VeriSign's root
hierarchy.