[saag] SHA-1 to SHA-n transition

[Stephen Kent <[e-mail]>]

I agree wit Phil's suggestion that we begin work on this topic sooner 
rather than later.  Solutions probably will require coordination 
between folks in both PKIX and TLS, plus some browser experts from 
the APP area.

However, Phil's comment (underling added by me)

If we start addressing the problem now we can lay ourselves an 
insurance policy. If we try to insist on the pristine principles of 
the PKIX infrastructure we are going to be in deep trouble in about 
five years time.

is offensive, at best. Moreover, unless Phil and his favorite browser 
vendors already have a solution in mind, and he anticipates that it 
will be objectionable to PKIX, this comment is gratuitous.

Since we're talking about how well browsers implement PKI mechanisms 
in the context of SSL/TLS, it is worth noting a presentation at last 
week's Black Hat conference in D.C. The presentation provided details 
on how several browsers remain vulnerable to attacks because they 
fails to check the Basic Constraints extension. This oversight of one 
of those pristine principles of PKIX ( we can use the acronym P3 
going forward) and allows a web sites to act as a CA, based o the EE 
cert issued to it by any of the trust anchors embedded in the browser.

Another vulnerability, and matching MITM attack, is enabled by the 
issuance of certs that contain wildcard DNS names. This is not, a 
violation of P3, because PKIX caved to pressure from the TLS WG, to 
accommodate web site operators who wanted to purchase one cert from a 
TTP that could be used to verify the EE certs for multiple web sites. 
I argued against this, but lost. The phrase "I told you so" comes to 
mind :-).

So, contrary to Phil's assertion that adherence to P3 will get us 
into deep trouble in five years (with regard to this transition 
issue), I believe that PKI shortcuts (hacks) in browsers have gotten 
us into deep trouble for many years, and are likely to persist.

Steve