<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE></TITLE>
<META http-equiv=Content-Type content="text/html; charset=us-ascii">
<META content="MSHTML 6.00.6000.16788" name=GENERATOR></HEAD>
<BODY><!-- Converted from text/plain format --><FONT size=2>
<P><BR><BR>-----Original Message-----<BR>From: Peter Watkins [<A
href="mailto:peterw@tux.org">mailto:peterw@tux.org</A>]<BR>Sent: Friday,
February 06, 2009 8:29 PM<BR>To: McGovern, James F (HTSC, IT)<BR>Cc:
specs@openid.net<BR>Subject: Re: OpenID Security<BR><BR>>> What do you
mean, "the" implementation? There is no "the" implementation.<BR><BR>>>
Are you arguing that for the OpenID *protocol* to succeed, every<BR>>>
*implementation* has to be "secure"? That sounds like a marketing problem to me,
and it's one you solve by having math/crypto experts ensure the<BR>>>
*protocol* is good. Period. When someone finds a bug in Postfix, we don't say
SMTP is broken and run away from email; we say Postfix version
such->>>>and->> such is broken, Wietse fixes it, and we go
on.<BR><BR><FONT size=4>Sometimes, the implementation is busted where a consumer
(albeit a technical one) can tell the library and version. SMTP makes it easy by
responding to HELO. Is there an OpenID equivalent?<BR><BR>Likewise, the protocol
can be defined as weak where someone may apply additive security on top of it.
Kinda like doing SMTP over TLS and/or S/MIME. A relay can have additional logic
to determine how to respond to <<insecure>> interactions. At times,
the SMTP protocol has morphed without breaking backward
compatibility.</FONT><BR><BR>I suppose you could argue for protocol compliance
tools as part of protecting the OpenID image -- at least that might allow OpenID
proponents to disown any insecure library that happened to fail the protocol
tests.<BR>But I wouldn't expect too much from that, either. Automated testing is
good for finding obvious problems, but it's no replacement for good, smart
programming, and not a cure for bad code. I'd feel more comfortable with
software that passed some long-running fuzzing tests, but you really don't want
to be vouching for the "security" of specific implementations. That's just
asking for trouble.</P>
<P><FONT size=4>The way that you achieve protocol compliance can be done through
complex and public interoperability demonstrations (Think Burton Group times
two), basic automated test harnesses (Think Java/J2EE compatibility testkit) and
review by disinterested parties. </FONT></P>
<P><BR>-Peter<BR><BR></P></FONT><pre>************************************************************
This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies.
************************************************************
</pre></BODY></HTML>