<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#ffffff">
On 01/02/2009 11:08 AM, Martin Paljak:<br>
<blockquote
cite="mid:B79243CA-B805-4B73-B40C-8F0D005924DB@paljak.pri.ee"
type="cite">
<pre wrap="">
A look back at 2008 suggests a following flow:
1. DNS poisoning or being on a rogue wifi network will move all
traffic (either http or https) for example.com to badguy.com
("Kaminsky DNS attack<a class="moz-txt-link-rfc2396E" href="http://it.slashdot.org/article.pl?sid=08/07/08/195225)2.connectingsoftware(browser/openidlibrary)isOKwithwhateverispresentedontheHTTPsite(obviousreasons)3.connectingsoftware">" http://it.slashdot.org/article.pl?sid=08/07/08/195225)
2. connecting software (browser/openid library) is OK with whatever is
presented on the HTTP site (obvious reasons)
3. connecting software "</a>security checks for PKI" are OK with whatever
is presented on the HTTPS site because
3a. Some dedicated badguy.com have forged a valid certificate for
example.com ("MD5 certificate attack<a class="moz-txt-link-rfc2396E" href="http://it.slashdot.org/article.pl?sid=08%2F12%2F30%2F1655234)3b.Some">" http://it.slashdot.org/article.pl?sid=08%2F12%2F30%2F1655234)
3b. Some "</a>trusted" CA has issued a valid certificate for example.com
("mozilla.com certificate from comodo attack<a class="moz-txt-link-rfc2396E" href="http://it.slashdot.org/article.pl?sid=08%2F12%2F23%2F0046258)4.Userissatisfiedastherewerenonaggingpopupswheretopress">" http://it.slashdot.org/article.pl?sid=08%2F12%2F23%2F0046258)
4. User is satisfied as there were no nagging popups where to press
"</a>OK" (!!!) to get into the site.
</pre>
</blockquote>
<br>
Martin, failures and disclosing them serves the purpose to improve and
prevent them. I'm responsible for disclosing one of the listed above,
which however doesn't mean that public certification is a total
failure. It speaks rather for the dedication and also the ability of
the industry to control and improve itself.<br>
<br>
The failure of a CA to perform validation correctly indeed compromises
the ability to trust and rely on digital certification, that's the
reason why it's being dealt with accordingly at different forums. Those
validations are meant to prevent in case #1 happens. <br>
<br>
Also the MD5 issue has been widely known and is hardly news anymore.
For example the EV guidelines explicitly disallowed MD5 already for
some time. The same would happen if OpenID would rely on such
algorithm. This will happen many times over again as computing power
improves and more research is done.<br>
<br>
<blockquote
cite="mid:B79243CA-B805-4B73-B40C-8F0D005924DB@paljak.pri.ee"
type="cite">
<pre wrap="">
In real life most end user software do not check for the status of a
certificate (CRL/OCSP), there is no easy user control over the "trust
list" ("trusted" CA-s in the system) and after all, most software does
not care if if the site which used to present a valid EV certificate
suddenly starts to present a "trusted" and valid certificate from
"Russian Business Network CA, Signed by Comodo"...
</pre>
</blockquote>
<br>
It would be good if more software was capable to detect EV. The EV
guidelines are the first time that CAs have a clear standard to follow
and are audited accordingly. Even though I would have preferred a
different approach than EV, it's not a bad thing as such. But even
without EV, we (the security specialists, browser vendors and CAs) will
do our due diligence to provide adequate and reasonable certification.
Ranting and FUD will not help anything and there is no viable
alternative right now widely adopted either.<br>
<br>
<blockquote
cite="mid:B79243CA-B805-4B73-B40C-8F0D005924DB@paljak.pri.ee"
type="cite">
<pre wrap="">
I second here the questions often raised about CA-s by Peter Williams,
but the community has managed to subtly ignore the topic. "If there is
a problem (which we don't believe there is) then this is for the PKI/
TLS/HTTPS guys to fix", "Just pay to a big company for your certs",
"Apparently we use whatever CA certificates Debian uses" are all signs
of delegating the problem somewhere else.
</pre>
</blockquote>
<br>
Yes, the later is certainly not a professional approach and should be
avoided.<br>
<br>
<blockquote
cite="mid:B79243CA-B805-4B73-B40C-8F0D005924DB@paljak.pri.ee"
type="cite">
<pre wrap="">
In addition to "lets just do what everybody else is doing" OpenID
could provide additional mechanisms. I once suggested having a
separate configuration file and format for RP libraries to be able to
configure white/blacklists and OP certificates/CA-s checksums and
trust settings. This would raise the issue into OpenID space instead
of relying on the host system for RP-s (dotnet using windows
certstores, hosts without CA certificates installed, requirement to
fiddle with curl options to make php library accept different
certificates etc)
</pre>
</blockquote>
<br>
But who will do that? <br>
<br>
<br>
<div class="moz-signature">
<table cellpadding="0" cellspacing="0" border="0">
<tbody>
<tr>
<td colspan="2">Regards </td>
</tr>
<tr>
<td colspan="2"> </td>
</tr>
<tr>
<td>Signer: </td>
<td>Eddy Nigg, <a href="http://www.startcom.org">StartCom Ltd.</a></td>
</tr>
<tr>
<td>Jabber: </td>
<td><a href="xmpp:startcom@startcom.org">startcom@startcom.org</a></td>
</tr>
<tr>
<td>Blog: </td>
<td><a href="http://blog.startcom.org">Join the Revolution!</a></td>
</tr>
<tr>
<td>Phone: </td>
<td>+1.213.341.0390</td>
</tr>
<tr>
<td colspan="2"> </td>
</tr>
</tbody>
</table>
</div>
</body>
</html>