Subject: Re: [saag] [Cfrg] Further MD5 breaks: Creating a rogue CAcertificate

From: [email-masked] (Peter Gutmann)
Date: Fri, 02 Jan 2009 00:17:49 +1300

Mike <[email-masked]> writes:

>> We are simply not vigilant enough.  This issue has been on our plate
>> since 2004.
>>
>> SHA-1 is next and neither the client side vendors nor the big
>> Enterprises have pushed to move to SHA-256.
>
>There is a simple fix -- a CA can just reorder the extensions prior to
>issuing a certificate.

That's actually a nice fix, but unfortunately not universally applicable: for
some types of signed data (e.g. S/MIME attributes) the DER rules require
sorting the encoded extensions, so there's only one valid order for them (and
some applications actually check for this, so you have to do it or sig checks
will start failing).

Peter.
_______________________________________________
saag mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/saag

---

From: "Santosh Chokhani" <[email-masked]>
Date: Thu, 1 Jan 2009 06:39:50 -0500

Also, for the actual attack, the ordering of extensions will not work as
long as the certificate size does not change.  If you look at the actual
attack, collision block in the real certificate is up to the SPKI.  The
extension values from the real certificate are simply copied in the
tumor of the rogue certificate.

Given the property that if H(M) = H (M') then H(M | X) = H (M' | X), the
attacker simply copies the extensions from actual certificate in the
tumor.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Peter Gutmann
Sent: Thursday, January 01, 2009 6:18 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [saag] [Cfrg] Further MD5 breaks: Creating a rogue
CAcertificate

>There is a simple fix -- a CA can just reorder the extensions prior to

That's actually a nice fix, but unfortunately not universally
applicable: for
some types of signed data (e.g. S/MIME attributes) the DER rules require
sorting the encoded extensions, so there's only one valid order for them
(and
some applications actually check for this, so you have to do it or sig
checks
will start failing).

Peter.

---

From: [email-masked] (Peter Gutmann)
Date: Fri, 02 Jan 2009 00:11:01 +1300

"Santosh Chokhani" <[email-masked]> writes:

>We are simply not vigilant enough.  This issue has been on our plate since
>2004.

It's not just this, the fact that there were CA certs out there with the CA
flag (in basicConstraints) not set was known for at least five years before
widespread bad publicity forced CAs to address it, the RSA exponent=1 debacle
was known for at least that long but no-one cared until there was lots of bad
publicity about it... there's a really serious problem with CAs and vendors
simply not caring about PKI security until bad publicity forces a change, the
curent MD5 issue (and the mozilla.com cert debacle and the Gromozon malware-
signing cert issue and ...) are just the latest examples.  It's like the
Microsoft of ten years ago, security holes just get ignored until bad
publicity forces a fix (and even then it's often more of a sidestep to avoid
further criticism than an actual fix).

It's small wonder that there's such widespread cynicism about PKI when even
the organisations pushing it don't seem to care whether it's done properly or
not.

Peter.

---

From: Ben Laurie <[email-masked]>
Date: Thu, 1 Jan 2009 15:06:17 +0000

> some applications actually check for this, so you have to do it or sig checks

Surely the whole point of DER is that there's only one correct way to
encode any particular certificate?

So, either extensions must be sorted, or changing their order changes
their meaning. Either way, nothing can be reordered.
_______________________________________________
saag mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/saag

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 01 Jan 2009 09:07:05 -0800

At Thu, 01 Jan 2009 07:51:38 -0800,
Mike wrote:
> 
> 
> Is there anything that could be added to RP software to reliably
> detect and thwart the use of a rogue CA certificate?  Or would
> any attempt to do that just cause too many problems?
> 
> Mike (who is writing "I am not a security expert" 100 times on
>        the chalkboard)

You could certainly add a check for this particular certificate
and any others you discovered. To the extent to which CAs no 
longer use MD5, this would likely quickly clean up the damage.
It's less clear that you could safely detect this kind of
cert in a generic way.

-Ekr

---

From: "Santosh Chokhani" <[email-masked]>
Date: Thu, 1 Jan 2009 10:14:49 -0500

Changing the order of extensions does not change their meaning.

Actually, a CA could put the extensions in random order for various
certificates.  The attack will still work if the certificate size does
not change.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Ben Laurie
Sent: Thursday, January 01, 2009 10:06 AM
To: Peter Gutmann
Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]
Subject: Re: [Cfrg] [saag] Further MD5 breaks: Creating a rogue
CAcertificate

applicable: for
checks

Cfrg mailing list
[email-masked]
https://www.irtf.org/mailman/listinfo/cfrg

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 1 Jan 2009 09:20:00 -0800

>encode any particular certificate?

Not so "surely". The SEQUENCE for extensions does not say what order they should be in.

>their meaning. Either way, nothing can be reordered.

Wrong on both counts. Each extension has stand-alone semantics, and they can be in any order.

However, this is irrelevant for the MD5 break discussion, as is clearly shown in the paper.

--Paul Hoffman, Director
--VPN Consortium

---

From: Ben Laurie <[email-masked]>
Date: Thu, 01 Jan 2009 17:44:32 +0000

> Not so "surely". The SEQUENCE for extensions does not say what order they should be in.

That doesn't change the _point_ of DER. If extensions should have been
specified as a SET but are defined as a SEQUENCE, then they are broken
(technically).

> Wrong on both counts. Each extension has stand-alone semantics, and they can be in any order.

My point was about the correct use of DER. It seems extensions use it
incorrectly.

> However, this is irrelevant for the MD5 break discussion, as is clearly shown in the paper.

I am discussing the correct use of DER :-)

-- 
http://www.apache-ssl.org/ben.html           http://www.links.org/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff
_______________________________________________
saag mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/saag

---

From: "Santosh Chokhani" <[email-masked]>
Date: Thu, 1 Jan 2009 14:29:46 -0500

We must fix X.509 since it is not broken.

We must preserve MD5 since it is weak.

We must provide economic and political support to client side vendors
who refuse to implement SHA-256.  We must treat them with kid gloves and
work around them.

The world economy is in the tank.

People want to shoot each other.

I see a patent here that is not very random.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Ben Laurie
Sent: Thursday, January 01, 2009 12:45 PM
To: Paul Hoffman
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked];
[email-masked]
Subject: Re: [saag] [Cfrg] Further MD5 breaks: Creating a rogue
CAcertificate

---

From: Ben Laurie <[email-masked]>
Date: Thu, 01 Jan 2009 19:39:54 +0000

> We must fix X.509 since it is not broken.

I am not suggesting that we should fix X.509, I am pointing out, in my
own roundabout way, that X.509 certs are supposed to have a canonical
form. But it seems they do not.

Makes me wonder why we go to all the effort of using a supposedly
canonical encoding that isn't? If we can only rely on the original bits
in the cert when checking the signature, why bother?

---

From: "Santosh Chokhani" <[email-masked]>
Date: Thu, 1 Jan 2009 14:48:40 -0500

I do not think canonical means only one way to represent.

Extensions have always been a SEQUENCE with their OID denoting what
extension is next and their syntax.

Actually, we find SET in the case of RDN problematic.

-----Original Message-----
From: Ben Laurie [mailto:[email-masked]] 
Sent: Thursday, January 01, 2009 2:40 PM
To: Santosh Chokhani
Cc: Paul Hoffman; [email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]
Subject: Re: [saag] [Cfrg] Further MD5 breaks: Creating a rogue
CAcertificate

---

From: Robert Moskowitz <[email-masked]>
Date: Fri, 2 Jan 2009 10:35:34 -0500

Peter Hesse wrote:
> Since MD5 is known bad and potentially dangerous at this point, I would
> suggest that the best client side action would be to fail to verify any
> signatures created using MD5.  This will break some things, especially if
> existing business processes are relying on a certificate signed with MD5.
> However, it is a fail-safe and would prevent a rogue CA certificate created
> in this fashion from being considered trustworthy.
>
> And to Santosh's point (and others), my earlier email about
> removing/replacing trust anchors was not because the self-signed
> certificates are signed using MD5; I agree the trust anchor public keys are
> protected using other mechanisms.  I am recommending that if CAs do nothing
> to prevent this kind of attack (non-random serial numbers, issue
> certificates signed with MD5, issue certificates in an automated,
> predictable fashion) that those CAs should be removed from trust lists
> because they are no longer acting in the interest of the relying party--they
> are an accomplice to the creation of these rogue certificates.
Peter,

This sounds great at an IETF mike, but out in the field how do you get 
all those millions of browsers to pull down a new trust list that will 
no longer include CA foobar?

Can't happen now, and the way things are going, ain't going to happen 
before 2026 either.

So what tool do we have to get compliance to best practices? The good 
old 5th estate, get out their and give bad press to foobar until they 
fix their behaviour or their business model collapses and they go out of 
business and can no longer issue potentially rogue certs.

We can talk and posture all we want in the IETF. We are rather good at 
that, IMNSHO. But this is perfect proof of our impact as such on the 
business model of companies that use our technology; they will do what 
is expedient, not what is Best Practices.

---

From: Yoav Nir <[email-masked]>
Date: Sun, 4 Jan 2009 09:02:00 +0200

On Jan 2, 2009, at 5:35 PM, Robert Moskowitz wrote:

> This sounds great at an IETF mike, but out in the field how do you  
> get all those millions of browsers to pull down a new trust list  
> that will no longer include CA foobar?
>
> Can't happen now, and the way things are going, ain't going to  
> happen before 2026 either.

There's this one company such that if they use Windows update to  
update their browsers, the others will follow. Technically, it's very  
easy to get rid of the bad CAs. However, that company is not going to  
modify their browsers, not now, probably not in the next few years.

> So what tool do we have to get compliance to best practices? The  
> good old 5th estate, get out their and give bad press to foobar  
> until they fix their behaviour or their business model collapses and  
> they go out of business and can no longer issue potentially rogue  
> certs.

I don't think you can get a message like that across. This story  
evokes more of the "Wow! Clever hackers with 200 playstations"  
sentiment, not the "criminal negligence" sentiment. You can't get the  
media angry with a company unless the negligence causes something  
spectacular, like an exploding Ford Pinto. Even Jesse Walker's "unsafe  
at any keylength" article didn't have quite the impact of the  
original. And people still use WEP.

> We can talk and posture all we want in the IETF. We are rather good  
> at that, IMNSHO. But this is perfect proof of our impact as such on  
> the business model of companies that use our technology; they will  
> do what is expedient, not what is Best Practices.

Best we can do is to get the CAs to

(1) not issue MD5 certs anymore and
(2) randomize the serial number and/or
(3) and a random fluff extension that people are talking about

But still, I don't see Microsoft removing a root CA because one of  
their sub-CAs is issuing non-compliant certificates.

And if Microsoft don't, nobody else will. The Firefox/Opera/Safari/ 
Chrome people don't want any sites that "only work with Explorer".

Email secured by Check Point
_______________________________________________
saag mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/saag

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 4 Jan 2009 11:11:09 -0800

>(3) and a random fluff extension that people are talking about

Just to repeat it one more time: #3 does not prevent the published attack.

>But still, I don't see Microsoft removing a root CA because one of their sub-CAs is issuing non-compliant certificates.

It is hard to see Microsoft removing or adding CAs. If anyone knows of a public interface (mailing list, web site, whatever) for when this happens, by all means please the world know.

>And if Microsoft don't, nobody else will. The Firefox/Opera/Safari/Chrome people don't want any sites that "only work with Explorer".

At least with respect to Firefox, I think that statement is false.

--Paul Hoffman, Director
--VPN Consortium

---

From: Yoav Nir <[email-masked]>
Date: Sun, 4 Jan 2009 22:23:58 +0200

> Just to repeat it one more time: #3 does not prevent the published  

It does if the random fluff is inserted by the CA. The attack depends  
on their ability to predict the entire TBS part.

> It is hard to see Microsoft removing or adding CAs. If anyone knows  
> of a public interface (mailing list, web site, whatever) for when  
> this happens, by all means please the world know.

I managed to find a page with their policy on adding new root CAs.  
Nothing there about removing old root CAs.

> At least with respect to Firefox, I think that statement is false.

They've done quite a bit to render broken sites that were made for IE.  
Also, I've updated today and all the "bad" CAs with MD5 signatures are  
still in the TAS.

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 4 Jan 2009 12:40:10 -0800

At 10:23 PM +0200 1/4/09, Yoav Nir wrote:
>It does if the random fluff is inserted by the CA. The attack depends on their ability to predict the entire TBS part.

I may have misunderstood the paper, but I think that changes after the subjectPublicKeyInfo do not affect the attack.

>I managed to find a page with their policy on adding new root CAs. Nothing there about removing old root CAs.

I'm not talking about the policy: I'm talking about the actual trust anchors themselves.

>They've done quite a bit to render broken sites that were made for IE.

That is irrelevant for this thread. There are active discussions in the Firefox community about adding and removing trust anchors that are and are not already in the IE trust anchor pile.

>Also, I've updated today and all the "bad" CAs with MD5 signatures are still in the TAS.

As was pointed out to me earlier: it does not matter if the CA has its cert signed with MD5, only whether that CA *signs* with MD5. RapidSSL, for example, is still signed with MD5 but is now signing with SHA-1.

--Paul Hoffman, Director
--VPN Consortium

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Sun, 04 Jan 2009 17:29:57 -0500

--On Sunday, January 04, 2009 10:23:58 PM +0200 Yoav Nir 
<[email-masked]> wrote:

> It does if the random fluff is inserted by the CA. The attack depends on
> their ability to predict the entire TBS part.

No, it does not.  It depends on their ability to predict that portion of 
the TBS part which occurs prior to the computed collision blocks, which in 
the real certificate occur in the subject public key modulus.  The portion 
of the TBS part which occurs after the collision blocks does not need to be 
predictable; they just need to be able to copy it as-is, which is done by 
copying the collision blocks, the rest of the original subject public key 
modulus, and all of the original certificate's extensions into a netscape 
comment extension in the forged certificate.

> Also, I've updated today and all the "bad" CAs with MD5 signatures are

Again, there is nothing "bad" about CA certifiates with MD5 signatures. 
The signature on a root certificate is not used for anything, and in 
practice is not an accurate predictor of what algorithms that CA uses to 
sign certificates.

-- Jeffrey T. Hutzelman (N3NHS) <[email-masked]>
   Carnegie Mellon University - Pittsburgh, PA

---

From: "Santosh Chokhani" <[email-masked]>
Date: Sun, 4 Jan 2009 17:34:21 -0500

I agree with Paul.

Unless the Length of TBD certificate as part of DER is made
unpredictable, any values on extensions just go in the tumor.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Paul Hoffman
Sent: Sunday, January 04, 2009 3:40 PM
To: Yoav Nir
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Cfrg] [saag] Further MD5 breaks: Creating a rogue
CAcertificate

I may have misunderstood the paper, but I think that changes after the
subjectPublicKeyInfo do not affect the attack.

>>
>>It is hard to see Microsoft removing or adding CAs. If anyone knows of
a public interface (mailing list, web site, whatever) for when this
happens, by all means please the world know.

I'm not talking about the policy: I'm talking about the actual trust
anchors themselves.

>>>And if Microsoft don't, nobody else will. The
Firefox/Opera/Safari/Chrome people don't want any sites that "only work
with Explorer".
>They've done quite a bit to render broken sites that were made for IE.

That is irrelevant for this thread. There are active discussions in the
Firefox community about adding and removing trust anchors that are and
are not already in the IE trust anchor pile.

still in the TAS.

As was pointed out to me earlier: it does not matter if the CA has its
cert signed with MD5, only whether that CA *signs* with MD5. RapidSSL,
for example, is still signed with MD5 but is now signing with SHA-1.

--Paul Hoffman, Director
--VPN Consortium

---

From: "RL 'Bob' Morgan" <[email-masked]>
Date: Tue, 30 Dec 2008 13:17:50 -0800 (PST)

> Regardless of that, the authors of the MD5 paper are correct: trust 
> anchors signed with MD5 are highly questionable as of today (well, 
> actually, since they published their last paper). Hopefully, the 
> maintainers of the popular trust anchor repositories (Microsoft, 
> Mozilla, etc.) will yank out the trust anchors signed with MD5 (and 
> MD2!) as soon as possible.

This is a different claim than "CAs should stop issuing certs with MD5 
signatures", which is what I as an amateur take away from a quick scan of 
the material.  Obviously MD5 is suspect in various ways, but does this new 
work lead to the conclusion that MD5-signed roots are untrustworthy today?
Replacing a root is a much bigger deal then changing signing practices.

  - RL "Bob"

---

From: "Peter Hesse" <[email-masked]>
Date: Tue, 30 Dec 2008 16:39:34 -0500

Ceasing the issuance of certificates with MD5 used in the signature doesn't
solve the problem of the certificates that have already been issued and are
still out there, any number of which may be rogue.

Replacing, or marking as untrusted all root certificates which have any
current valid (i.e. non-expired, non-revoked) certificates with MD5 used in
the signature could have tremendous undesirable impact and be an untenable
solution.

The right tool for the job is a client-side solution to fail validation of
any signature which uses MD5, especially certificate signatures.  I will not
hold my breath for such a solution.

--Peter 

----------------------------------------------------------------
 Peter Hesse                       [email-masked]
 http://securitymusings.com         http://geminisecurity.com

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of RL 'Bob' Morgan
Sent: Tuesday, December 30, 2008 4:18 PM
To: Paul Hoffman
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [saag] Further MD5 breaks: Creating a rogue CA certificate

  - RL "Bob"

---

From: "Blake Ramsdell" <[email-masked]>
Date: Tue, 30 Dec 2008 14:23:42 -0800

On Tue, Dec 30, 2008 at 2:05 PM, Timothy J. Miller <[email-masked]> wrote:
> Randomizing serial numbers has implications for OCSP operations,
> particularly those that use presigned responses in order to optimize
> performance.

It seems that the disruption caused by modifying serial number
generation for existing CAs is pretty high. Would an easier solution
be to either a) make the validity period vary slightly (in the
documented attack, the notBefore was always a fixed interval from the
submission time, and making this vary in a period of just a few
minutes would have thwarted it, if I'm understanding correctly), or b)
the CA sticks some random junk in the subject DN (not an MPEG of a
cat, but maybe OU=sf9fj3 [some base64 PRNG data]).

Blake
-- 
Blake Ramsdell | http://www.blakeramsdell.com
_______________________________________________
saag mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/saag

---

From: Scott Rea <[email-masked]>
Date: Tue, 30 Dec 2008 17:30:14 -0500

Russ Housley wrote:
>> This is a different claim than "CAs should stop issuing certs with 
>> MD5 signatures", which is what I as an amateur take away from a quick 
>> scan of the material.  Obviously MD5 is suspect in various ways, but 
>> does this new work lead to the conclusion that MD5-signed roots are 
>> untrustworthy today?
>
> We recommended a migration (walk, don't run) away from MD2, MD4, and 
> SHA-1 toward SHA-256 a few years ago.  MD2 and MD4 generate 128 bit 
> hash values; even without the attacks, these are getting to be too 
> small.  SHA-1 has been shown to be weaker than its design goal, and 
> the 160 bit hash value will be getting too short in a couple of 
> years.  We recommended SHA-256 while fully recognizing that NIST was 
> starting a hash competition, and that we might recommend the winner of 
> that competition as the successor to SHA-256.
>
> I still strongly encourage the migration to SHA-256.
>
> The use of the random bits in the serial number are insurance against 
> similar problems being found in other hash functions.  This insurance 
> will hopefully provide time to migrate to another hash function when 
> cryptanalysis begins to show flaws in any future hash function.
>
> Russ

But one of the things that has kept the brakes on migration has been 
support in clients for SHA256 - the largest vendor of client machines 
only just recently added SHA256 to its XP platform (if you upgrade to 
SP3). I keep running into folks using OpenSSL as their crypto base and 
they haven't updated to a distribution that supports SHA256. I think it 
will take a little more time before it becomes the default...

-- 
Scott Rea

---

From: "Timothy J. Miller" <[email-masked]>
Date: Tue, 30 Dec 2008 16:05:56 -0600

Eric Rescorla wrote:
> At Tue, 30 Dec 2008 12:53:06 -0800,
> Paul Hoffman wrote:

>> Your recollection may be off. I believe I was the person who brought
>> up the serial number hack at the mic, and I'm pretty sure I said
>> "some", not "many" (and certainly not "most"!). When I looked at a
>> handful of popular CAs earlier this week, I only found a few who are
>> using randomization in their serial numbers.

> I don't know whether many or most do it. IMO everyone should.

Why presign?  Because for a large network with varying levels of 
support, it may be easier to move around sets of pre-produced responses 
to distributed keyless OCSP responders than to guarantee connectivity to 
a keyed OCSP service.

Why presign batches rather than individual responses?  Because for a 
large PKI the response pre-production time can exceed the CRL update 
frequency.

-- Tim

---

From: "Timothy J. Miller" <[email-masked]>
Date: Wed, 31 Dec 2008 08:42:56 -0600

Russ Housley wrote:
> 
>> I'm not sure I understand the issue here, but
>> they don't actually have to be totally randomized. You could use a
>> PRF so they were predictable to the CA.
> 
> That works.  This works too: the serial number could be composed of 
> two parts, where the most significant bits are a counter and the 
> least significant bits are randomly generated.

How would Corestreet's miniCRL format fare under this?

-- Tim

---

From: "Timothy J. Miller" <[email-masked]>
Date: Wed, 31 Dec 2008 09:18:00 -0600

Santosh Chokhani wrote:
> One would think we want to start using SHA-1 or even SHA256 (assuming
> client vendors implement SHA256 ASAP) and ask the CAs emanating from
> commercial roots to perform responsible I&A before issuing certificates.

Speaking of I&A, I found it interesting to note that the CA/Browser 
forum guidelines for EV certs allows (but recommends against) MD5 until 
2010.

The spot check of EV issuers I did yesterday didn't turn up anyone 
actually using MD5, but I didn't have all of 'em available.

-- Tim

---

From: "Tim Moses" <[email-masked]>
Date: Wed, 31 Dec 2008 10:36:56 -0500

Colleagues - It has been confirmed that no EV issuer is signing certificates with MD5.  Also, EV certificates cannot be issued by an automated process, putting another obstacle in the path of an attacker.  All the best.  Tim.

Tim Moses
+1 613 270 3183

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Timothy J. Miller
Sent: Wednesday, December 31, 2008 10:18 AM
To: Santosh Chokhani
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Cfrg] [saag] Further MD5 breaks: Creating a rogue CAcertificate

> commercial roots to perform responsible I&A before issuing certificates.

Speaking of I&A, I found it interesting to note that the CA/Browser forum guidelines for EV certs allows (but recommends against) MD5 until 2010.

The spot check of EV issuers I did yesterday didn't turn up anyone actually using MD5, but I didn't have all of 'em available.

-- Tim

---

From: Mike <[email-masked]>
Date: Wed, 31 Dec 2008 09:03:37 -0800

> Enterprises have pushed to move to SHA-256.

There is a simple fix -- a CA can just reorder the extensions prior
to issuing a certificate.

Mike

---

From: "Richard Graveman" <[email-masked]>
Date: Wed, 31 Dec 2008 12:41:47 -0500

Ran,

> It would be very helpful if a *set* of mathematicians/cryptographers
> could jointly put together a summary of the known attacks on all
> the widely used hash algorithms (e.g. MD2, MD4, MD5, SHA-0, SHA-1,
> SHA-2, others), *including references to the published literature*.

For an expert, authoritative, and incredibly up-to-date tutorial on
the state of hash functions, go to http://www.inscrypt.cn/, get the
invited talks, and see the one by Preneel. If the intro material is
boring, flip to slide 45 and start reading. No, MD5 and SHA-1 are not
quite in the same boat.

For full papers, see IACR eprints 2008/391 for MD5, 2008/469 for
SHA-1, and 2006/187 for HMAC with these. Follow the references
therein. I avoided sources that cost money to get to, etc.

Unfortunately, the ways cryptologists look at these things and the
ways the IETF uses them are not always the same, so there is more work
to do. Suffice it to say, for a start, there is a big difference
between, say:

1. An HMAC based on a fresh key used by IPsec of TLS for a few minutes.
2. An HMAC based on a key stuck in a router and keft there for months or years.
3. A hash used to sign an email.
4. A hash use to sign a root certificate.

Rich Graveman

---

From: Mike <[email-masked]>
Date: Wed, 31 Dec 2008 09:49:45 -0800

I sent my last message a bit too hastily.  Other ideas that I was
contemplating should have been mentioned including:

   - remove any unrecognized extensions
   - remove tumors

Those could potentially cause problems if for some reason they were
actually needed.  This one, though, shouldn't cause trouble:

   - add a private EKU with a random number (or two) in the OID

That would not mess up the serial number scheme in use or modify the
subject name as has been suggested.

Mike

---

From: Dr Stephen Henson <[email-masked]>
Date: Wed, 31 Dec 2008 18:11:35 +0000

> subject name as has been suggested.

Or add a non-critical extension with some randomness in it...

Steve.
-- 
Dr Stephen N. Henson.
Core developer of the   OpenSSL project: http://www.openssl.org/
Freelance consultant see: http://www.drh-consultancy.co.uk/
Email: [email-masked], PGP key: via homepage.
_______________________________________________
saag mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/saag

---

From: "Timothy J. Miller" <[email-masked]>
Date: Wed, 31 Dec 2008 12:23:50 -0600

How about adding an otherName to the SAN?  You'd need an OID for random 
data though.

Or the CA could insert a method 4 UUID as a URI in the SAN.  That's 
intentionally random.  This might upset anyone wanting to use UUIDs as 
unique names, though (and these people do exist :).

Just thinking out loud.

-- Tim

Santosh Chokhani wrote:
> Private EKU could cause problems if EKU is not otherwise present in the
> certificate.
> 
> The certificate may not be usable for intended purpose.  Not all clients
> may recognize "any key purpose" as intended by 5280.
> 
> From: [email-masked] [mailto:[email-masked]]
> On Behalf Of Mike
> Sent: Wednesday, December 31, 2008 12:50 PM
> To: [email-masked]

---

From: "Timothy J. Miller" <[email-masked]>
Date: Wed, 31 Dec 2008 12:30:13 -0600

> Or add a non-critical extension with some randomness in it...

Do you want to propose id-ce-magicCookie OBJECT IDENTIFIER  ::=  {id-ce 
55} or should I?  :)

-- Tim

---

From: "Timothy J. Miller" <[email-masked]>
Date: Wed, 31 Dec 2008 12:34:04 -0600

> Do you want to propose id-ce-magicCookie OBJECT IDENTIFIER  ::=  {id-ce 

draft-01 already:  Make that id-ce-magicNumber instead.  :)

-- Tim

---

From: "Timothy J. Miller" <[email-masked]>
Date: Wed, 31 Dec 2008 12:35:09 -0600

Santosh Chokhani wrote:
> I am a bit concerned about random goo when random goo is one of the
> things the attacker uses to cause collision.  This may limit human or
> machine's ability to discern mischief.

I don't see how, if the random goo is added by the CA.  It defeats 
chosen prefix attacks as a class.

-- Tim

---

From: "Timothy J. Miller" <[email-masked]>
Date: Wed, 31 Dec 2008 12:53:59 -0600

Santosh Chokhani wrote:

> So, if you are relying on CAs, why not ask them to switch to SHA-1 as
> opposed to adding more software to the CA.  SHA-1 is purely a
> configuration item for the CA deployments.

Because someday SHA-1 (and SHA-2, or any hash algorithm) may be subject 
to a similar collision generation attack, and the presence of 
unpredictable data in the cert will defeat it as well.

Just trying to be proactive here.

-- Tim

---

From: Philipp Guehring <[email-masked]>
Date: Thu, 01 Jan 2009 05:01:33 +0100

Hi,

> CAs should have stopped issuing certs with MD5 signatures 4 years ago,  
> when the first practical attacks on MD5 were published.

That's what nearly all of the CA's actually did back then.
But due to the all-for-one and one-for-all problem, that wasn't enough,
and it seems that our auditors forgot to care about it.

> Now it would be more correct to say that "relying parties should treat  
> as invalid any certificate chain that contains an MD5 (or MD2, MD4)  
> signature"

Yes, except for the root certificates / trust anchors.

> Since in the HTTPS context the relying parties are the browsers, it  
> falls to the vendors (if Microsoft leads, everyone will follow) to, as  
> Paul said, yank the trust anchors.

The trust anchors are the wrong place to attack the problem.

> It should be noted, though, that yanking the trust anchors is not  
> enough. You really should change the relying party to not recognize  
> this algorithm. Otherwise, it's perfectly valid for a CA whose  
> certificate is signed with SHA1 to sign an intermediate CA certificate  
> with MD5 (although they usually don't do that, I hope)

I also thought so, but then I realized that if we invalidate MD5
completely, then we would also invalidate root certificates that are MD5
self-signed, which isn't a security issue. So that would give lots of
unnecessary false-positives.

I would like to propose the following idea:

We should define a date for expiring MD5 in certificate chains for the
Internet. I would suggest the 1. June 2009, which is 6 months from now.
All software should present or log warnings in case a MD5 signature is
detected in the certificate chain (except for the self-signatures of the
root certificates) before the 1. June 2009.
The warning should state that this certificate is considered insecure
and will stop functioning on 1. June 2009.
After 1. June 2009, SSL- and digital-signature-creation applications
should treat MD5 signatures should as invalid.
After 1. June 2009, Digital signature verification applications should
warn the user that MD5 signatures have been abandoned on 1. June 2009

I think if we can agree on a date to expire MD5, and inform the media
and the users through the warnings about the expiry date

There is already a Firefox extension that warns about the certificates:
http://codefromthe70s.org/sslblacklist.aspx

Best regards,
Philipp Gühring

---

From: Mike <[email-masked]>
Date: Thu, 01 Jan 2009 07:51:38 -0800

---

From: "Peter Hesse" <[email-masked]>
Date: Fri, 2 Jan 2009 09:41:15 -0500

--Peter

---

From: "Weger, B.M.M. de" <[email-masked]>
Date: Sun, 4 Jan 2009 23:02:36 +0100

Hi Paul,

> >It does if the random fluff is inserted by the CA. The 
> attack depends on their ability to predict the entire TBS part.
> 
> I may have misunderstood the paper, but I think that changes 
> after the subjectPublicKeyInfo do not affect the attack.

Almost correct. A random looking "collision block" has to be inserted
somewhere. We chose to insert it in the public key, as that seems
the most convenient. Somebody else may find another place where
it can be hidden (maybe in a "subject key identifier" field or something,
I don't know what would be feasible). Everything after the "collision
block" must be copied bitwise into the twin certificate, and must be
'harmless' there. If 'random fluff' is inserted by the CA after the
"collision block", this 'random fluff' can be copied into the twin 
certificate as well, retaining the collision property, and this
would indeed be irrelevant to our attack.

> As was pointed out to me earlier: it does not matter if the 
> CA has its cert signed with MD5, only whether that CA *signs* 
> with MD5. RapidSSL, for example, is still signed with MD5 but 
> is now signing with SHA-1.

Correct.

Grtz,
Benne de Weger

---

From: Yoav Nir <[email-masked]>
Date: Mon, 5 Jan 2009 09:46:21 +0200

Oh, OK. I got it now. Eek.

On Jan 5, 2009, at 9:37 AM, Yoav Nir wrote:

> OK. Now I'm a lot confused :-)
>
> On Jan 5, 2009, at 12:02 AM, Weger, B.M.M. de wrote:
>
>> Hi Paul,
>>
> If you inserted a random looking collision block in the public key,  
> how did your signature on the PKCS#10 request verify?
>
>>
>>
> Sure, but the other authorities that signed with MD5 (no idea if  
> they've changed their evil ways) are still there.
>

---

From: Yoav Nir <[email-masked]>
Date: Mon, 5 Jan 2009 09:37:11 +0200

---

From: der Mouse <[email-masked]>
Date: Mon, 5 Jan 2009 04:57:19 -0500 (EST)

>> [...]
> scan of the material.

What I, as an amateur, take away from it is approximately "MD5 is
showing more and more cracks and nobody should use it for anything that
needs to withstand a malicious adversary".

These may be the best openly published breaks of MD5 at the moment, but
I don't for a moment believe nobody has anything better - and I'm quite
sure the time to stop using it is now, when it can be done gracefully,
rather than in a frantic scramble a few months or years from now when
someone publishes a much more blatant break.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		[email-masked]
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B
_______________________________________________
saag mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/saag

---

From: RJ Atkinson <[email-masked]>
Date: Mon, 05 Jan 2009 08:26:52 -0500

> needs to withstand a malicious adversary".

Within the CA world, many folks here seem to agree.

However, the usage in CAs is rather different from
some other modes of operation (e.g. Keyed-Hash, HMAC-Hash).

So far, there are no known attacks on those other modes of operation.
[If someone knows of a refereed paper that's been published
on those latter topics, please share a citation here.]

> These may be the best openly published breaks of MD5 at the moment,

Mind, there are published "serious attacks" [using NIST's words
from their web site] against SHA-0 and SHA-1 also.   Timothy
Miller seemed to suggest in recent email that perhaps the PKIX WG
might enhance the CA structure to increase attack resistance in an
algorithm-independent way.

Now, may I suggest that folks please LOOK AT and possibly
REDUCE/EDIT the CC line as they reply to this thread going forward.
Items that are PKIX specific likely belong only on the PKIX
list.  Ditto for SMIME specific issues to the SMIME list.
That would leave only generic comments for the SAAG list.

Cheers,

Ran

---

From: David McGrew <[email-masked]>
Date: Mon, 5 Jan 2009 10:15:26 -0800

Hi Ran,

> on those latter topics, please share a citation here.]

I'm not sure what you mean by keyed-hash, but here are some attacks  
that might be relevant.

[1] B. Preneel and P. van Oorschot, “MD-x MAC and building fast MACs  
from hash
functions,” Advances in Cryptology – Crypto 95 Proceedings, Lecture  
Notes in Computer
Science Vol. 963, D. Coppersmith ed., Springer-Verlag, 1995.

[2] B. Preneel and P. van Oorschot, “On the security of two MAC  
algorithms,” Advances
in Cryptology – Eurocrypt 96 Proceedings, Lecture Notes in Computer  
Science Vol. ??,
U. Maurer ed., Springer-Verlag, 1996.

RFC 2385 uses the method broken in Section 4.2 of [1].

HMAC seems to be secure given some reasonable assumptions about the  
hash functions (namely, that the underlying hash has a compression  
function that is a PRF - no collision resistance is required); see http://eprint.iacr.org/2006/043

> That would leave only generic comments for the SAAG list.

Done.

David

---

From: RJ Atkinson <[email-masked]>
Date: Mon, 05 Jan 2009 14:47:35 -0500

> function that is a PRF - no collision resistance is required); see http://eprint.iacr.org/2006/043

Thank you very much.
Pointers to the literature are very helpful.

One followup question, if I might, as a non-mathematician here.

Does the community agree on whether MD5, SHA-0, SHA-1, and/or SHA-2
meet the assumptions required by the HMAC proofs (e.g. your mention
above that the hash "is a PRF -- no collision resistance is
required") ???

I do continue to think that an Informational RFC that surveys
the use of hash functions -- as used by IETF protocols -- citing
the literature (as above) and comparing hash functions and modes
would be most helpful.  While RFC-4270 was good as far as it went,
it did not fully explain what the results meant relative to the
modes and algorithms that IETF specifications use -- and of course
time moves on and that RFC is now 3 years old.  :-)

Thanks again,

Ran
[email-masked]

---

From: David McGrew <[email-masked]>
Date: Mon, 5 Jan 2009 14:50:07 -0800

Hi Ran,

I think it is a great idea to document the IETF applications/uses of  
hashing, and the attacks against particular uses of hashing.  It would  
make a great CFRG informational RFC, if we can find volunteers to  
contribute to and edit it.  I offer to review it.

David

On Dec 31, 2008, at 7:48 AM, RJ Atkinson wrote:

>
> [Distribution trimmed slightly to reduce cross-posting and improve  
> SNR.]
>
> On  30 Dec 2008, at 20:20, Peter Gutmann wrote:
>> The current MD5 attack is very cool but there's no need to worry  
>> about
>> bad guys doing much with it because it's much, much easier to get
>> legitimate CA-issued certs the normal way, you buy them just like
>> everyone else does (except that you use someone else's credit card
>> and identity, obviously).
>
>
> Two thoughts:
>
> 1) Protocol Issues
>
> The IETF ought to be thinking about a wide range of IETF protools
> in the same way that Peter thinks about CA security issues above.
>
> For some IETF protocols, for example all of the IGP authentication
> extensions (excepting RFC-2154, AFAICT), active non-cryptographic
> attacks are feasible (if not yet seen in the deployed world, AFAICT)
> that are much easier than *any* cryptographic attack.  Again, and
> only by way of example, RFC-4822 discusses some of these that are
> specific to RIPv2 authentication.
>
> For protocols where non-cryptographic attacks are feasible AND
> are lower cost than a cryptographic attack, really it does not make
> much difference what cryptographic algorithm gets deployed by a user
> -- and the IETF's focus should be on improving the underlying  
> authentication mechanism BEFORE worrying about which cryptographic
> algorithms are being deployed.
>
> Attackers are generally both smart and lazy, so they won't waste
> time on an expensive cryptographic attack when a lower effort
> non-cryptographic attack exists.
>
>
> 2) Hash algorithm analysis
>
> Ideally, this analysis would also include discussion of whether those
> attacks apply for those same algorithms when used in the modes  
> employed
> by various IETF protocols today (e.g. Keyed-Hash as used in OSPFv2 MD5
> or RIPv2 MD5, HMAC-Hash, and so forth).
>
> This would be most useful to have as an Informational RFC,
> and SOON, so that IETF WGs could have some "consensus" document
> to refer to -- and to cite explicitly -- if any IETF WGs decide
> to make hash algorithm recommendations or decisions.
>
> I don't understand IRTF process details perfectly, but perhaps
> the CFRG chairs might undertake creating such a document as a
> near-term official CFRG group project.
>
> Yours,
>
> Ran
> [email-masked]
>

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 5 Jan 2009 15:09:58 -0800

At 2:50 PM -0800 1/5/09, David McGrew wrote:
>I think it is a great idea to document the IETF applications/uses of hashing, and the attacks against particular uses of hashing.  It would make a great CFRG informational RFC, if we can find volunteers to contribute to and edit it.  I offer to review it.

I will volunteer to update RFC 4270, and I assume that Bruce Schneier would be willing to still be my co-author.

--Paul Hoffman, Director
--VPN Consortium

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 05 Jan 2009 18:19:24 -0500

> unnecessary false-positives.

Except that the validation process doesn't actually need to check the 
signature on a "root certificate", because that signature is not part of 
the chain.

> Internet. I would suggest the 1. June 2009, which is 6 months from now.

Hahahahaha!

If we all agreed, today, that this is the right approach, and the browser 
vendors all agreed with us, and they all managed to have updated versions 
available, by, say, next week...

It would be after June before anyone even had the new software.

If we're going to propose that browser vendors make a software change, it 
should not be to remove MD5 support; it should be to allow configuration of 
which signature algorithms are supported, just as they allow configuration 
of which TLS ciphersuites are supported.

It certainly should _not_ be to generate a warning every time an MD5 
signature is used.  All that will do is train users to click away security 
warnings without reading them, which they are already quite good at.

-- Jeff

---

From: "Vishwas Manral" <[email-masked]>
Date: Mon, 5 Jan 2009 15:24:01 -0800

Hi Paul,

I think its a good step forward.

I guess the document could instead of taking about each IETF
application, talk about uses of hash functions in general and the
recomendation about a use of a particular function (i.e. random number
generation, secure hash etc).

Thanks,
Vishwas

---

From: Stephen Kent <[email-masked]>
Date: Mon, 5 Jan 2009 21:53:15 -0500

At 8:10 AM -0600 1/5/09, Timothy J. Miller wrote:
>Ben Laurie wrote:
>That was last month's major discussion on PKIX.  The upshot: there's 
>no canonical form other than what's in memory.
>
>-- Tim

Tim,

Your response is an oversimplification, in several respects.

Ben's comment was a bit ill-formed. It's not that certs in general do 
or do not have a canonical form, but whether a given cert has a 
canonical representation. If the cert has no extensions, then it 
does. If it has extensions, then since the top level extension syntax 
is a SEQUENCE, there the order of extensions in that sequence (when 
the cert was signed) is definitive. (if that syntax had called for a 
SET, then  DER encoding would impose an order at this level, so use 
of the SEQUENCE construct here make life a bit easier.)

The context in which there is some disagreement is whether an 
extension needs to be DER encoded below the next level, where it is 
defined as an OCTET string. If one stops at the OCTET string level, 
the  life is easy and an RP can always encode to DER upon receipt 
(since the base cert format IS known by all RPs and they are 
technically capable of encoding it in DER).

If one interprets X.509 to require DER for the lower levels of the 
structure of a cert extension, then a problem can arise. It was noted 
that a non-critical extension (which therefore ought not be rejected 
out of hand by an RP) might have a syntax unknown to an RP. Thus the 
RP needs to assume that what it received is DER encoded when 
computing the signature, as it has no way to recompute the DER.

Steve

---

From: Sean Turner <[email-masked]>
Date: Mon, 05 Jan 2009 22:20:41 -0500

Dave,

When the S/MIME WG penned 
http://tools.ietf.org/html/draft-ietf-smime-multisig-05 we added an 
appendix that addresses where hashes are located in CMS's SignedData and 
the attacks against those hashes.  I'd be willing to help craft any 
other wording necessary for S/MIME|CMS.

spt

David McGrew wrote:
>> [Distribution trimmed slightly to reduce cross-posting and improve SNR.]
>>
>>> The current MD5 attack is very cool but there's no need to worry about
>> attacks apply for those same algorithms when used in the modes employed

---

From: Sean Shen <[email-masked]>
Date: Tue, 06 Jan 2009 11:33:31 +0800

Hi,
A draft in CSI work group gives some analysis on hash threats on
CGA(RFC3972) and SeND(RFC3971). Hope it also provides valuable info.
I will be happy to give review or other possible support for this valuable
work.

Best,

Sean

>From: [email-masked] [mailto:[email-masked]] On 
>Behalf Of Sean Turner
>Sent: Tuesday, January 06, 2009 11:21 AM
>To: David McGrew
>Cc: [email-masked]; [email-masked]
>Subject: Re: [saag] RFC analyzing IETF use of hash functions 
>[was: Re: [Cfrg] Further MD5 breaks: Creating a rogue CA certificate]
>
>Dave,
>
>http://tools.ietf.org/html/draft-ietf-smime-multisig-05 we 
>added an appendix that addresses where hashes are located in 
>CMS's SignedData and the attacks against those hashes.  I'd be 
>willing to help craft any other wording necessary for S/MIME|CMS.
>
>spt
>
>David McGrew wrote:
>> Hi Ran,
>>

---

From: [email-masked] (Peter Gutmann)
Date: Tue, 06 Jan 2009 21:43:56 +1300

"Timothy J. Miller" <[email-masked]> writes:

>The only reliable way to nuke a trusted cert from Windows is touch management
>of workstations.

It's worse than that, there is no reliable way to remove trusted certs from
Windows.  See Paul Hoffman's analysis at
http://www.proper.com/root-cert-problem/.

Peter.

---

From: David McGrew <[email-masked]>
Date: Tue, 6 Jan 2009 04:31:32 -0800

Hi Sean,

On Jan 5, 2009, at 7:20 PM, Sean Turner wrote:

> Dave,
>
> When the S/MIME WG penned http://tools.ietf.org/html/draft-ietf-smime-multisig-05 
>  we added an appendix that addresses where hashes are located in  

great, thanks for volunteering.

David

>
>
> spt
>
> David McGrew wrote:
>> Hi Ran,
>> I think it is a great idea to document the IETF applications/uses  
>> of hashing, and the attacks against particular uses of hashing.  It  
>> would make a great CFRG informational RFC, if we can find  
>> volunteers to contribute to and edit it.  I offer to review it.
>> David

---

From: David McGrew <[email-masked]>
Date: Tue, 6 Jan 2009 04:32:13 -0800

thanks for volunteering, Sean.

---

From: "Timothy J. Miller" <[email-masked]>
Date: Mon, 5 Jan 2009 08:10:49 -0600

> form. But it seems they do not.

That was last month's major discussion on PKIX.  The upshot: there's no 
canonical form other than what's in memory.

-- Tim

---

From: "Timothy J. Miller" <[email-masked]>
Date: Mon, 5 Jan 2009 08:40:20 -0600

> modify their browsers, not now, probably not in the next few years.

I hate to burst your bubble, but there's no automated way to *remove* 
certs from the MS cert store.  You have to script it, and the script can 
fail any number of different ways.

The only reliable way to nuke a trusted cert from Windows is touch 
management of workstations.

-- Tim

---

From: Christian Rechberger <[email-masked]>
Date: Mon, 05 Jan 2009 21:35:08 +0100

> above that the hash "is a PRF -- no collision resistance is

That seems a very valid question, and indeed cryptographers have been  
working on  PRF properties, and violations of it can be used to  
construct attacks on HMAC.

As opposed to unkeyed modes, none of the attacks which have been  
developed in recent years on HMAC (when instantiated with one of the  
popular hash functions) are practical.

Still, there are attacks on HMAC-MD4 (see e.g. [1]), NMAC-MD5 (see  
e.g. [1,2]). For HMAC-SHA-1, the best result is on reduced variants  
(61/62 out of its 80 steps, see [2]).

To conclude, from a cryptanalyst point of view:
HMAC-MD4: please don't, attacks might become practical anytime
HMAC-MD5: only certificational attacks, nothing real or serious, but  
MD5 just does not look like a good PRF
HMAC-SHA-1: ok, some security margin left
HMAC-SHA-2: no concrete cryptanalytic results, most likely ok.

hth,
  Christian

[1]  Pierre-Alain Fouque, Gaëtan Leurent, Phong Nguyen: Full  
Key-Recovery Attacks on HMAC/NMAC-MD4 and NMAC-MD5, CRYPTO 2007.

[2] Christian Rechberger and Vincent Rijmen: On Authentication with  
HMAC and Non-Random Properties, Financial Cryptography 2007.

-- 
Christian Rechberger <[email-masked]>
Krypto Group - IAIK - TU Graz, Inffeldgasse 16a, A-8010 Graz, Austria
http://www.iaik.tugraz.at/content/research/krypto/
phone: +43 (0)316 873 5534  ---  fax: +43 (0)316 873 5594

---

From: Ran Canetti <[email-masked]>
Date: Tue, 6 Jan 2009 08:05:21 +0200 (IST)

I strongly second. The document might also have some basic 
recommendations (do-s and dont-s).

(the other) Ran

On Mon, 5 Jan 2009, David McGrew wrote:

> Hi Ran,
>
> I think it is a great idea to document the IETF applications/uses of hashing, 
> and the attacks against particular uses of hashing.  It would make a great 
> CFRG informational RFC, if we can find volunteers to contribute to and edit 
> it.  I offer to review it.
>
> David
>

---

From: "Timothy J. Miller" <[email-masked]>
Date: Tue, 6 Jan 2009 08:08:07 -0600

> http://www.proper.com/root-cert-problem/.

I've corresponded with Paul about that in the past.  Root 
auto-installation can be disabled, users can be blocked from installing 
roots in both the machine and user store (requires domain GPO, IIRC), 
and subjectInfoAccess chasing can be disabled (Vista "feature").

Incomplete answer for general users, yes, but it's there nonetheless. 
Presumably if you're touch managing workstations for trust anchor 
removal you can verify that these settings are all in place.  :)

The roots that shouldn't be removed are the ones needed to boot (i.e., 
validate authenticode signatures).  That's more than a few in XP.

-- Tim

---

From: David McGrew <[email-masked]>
Date: Wed, 7 Jan 2009 15:26:24 -0800

Hi Paul,

thanks for volunteering.  For a CFRG doc it would be good to point out  
how existing standards can benefit from newer research results, and  
what open problems could be addressed with future research.

David

On Jan 5, 2009, at 3:09 PM, Paul Hoffman wrote:

> I will volunteer to update RFC 4270, and I assume that Bruce  
> Schneier would be willing to still be my co-author.
>
> --Paul Hoffman, Director
> --VPN Consortium

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Wed, 7 Jan 2009 16:03:06 -0800

I think this is an area where there is much ambiguity.  When a hash
function is used within a protocol it is often unclear what properties
are expected from it.  This causes problems when a flaw is uncovered and
the impact to the protocol is uncertain.  I think it would improve
things if we were a bit more specific about it. I'd be glad to
participate by reviewing, editing, contributing text or whatever else is
needed. 

Cheers,

Joe

> Behalf Of David McGrew (mcgrew)
> Sent: Wednesday, January 07, 2009 3:26 PM
> To: Paul Hoffman
> Cc: RJ Atkinson; [email-masked]; [email-masked]
> Subject: Re: [saag] [Cfrg] RFC analyzing IETF use of hash 
> functions [was:Re: Further MD5 breaks: Creating a rogue CA 
> certificate]
> 
> Hi Paul,
> 
> thanks for volunteering.  For a CFRG doc it would be good to 
> point out how existing standards can benefit from newer 
> research results, and what open problems could be addressed 
> with future research.
> 
> David
> 
> >> hashing, and the attacks against particular uses of hashing.  It 
> volunteers 
> >> to contribute to and edit it.  I offer to review it.
> >
> > I will volunteer to update RFC 4270, and I assume that 
> Bruce Schneier 
> > would be willing to still be my co-author.
> >
> > --Paul Hoffman, Director
> > --VPN Consortium
>