-Original Message-
From: Peter Watkins [mailto:pet...@tux.org]
Sent: Friday, February 06, 2009 8:29 PM
To: McGovern, James F (HTSC, IT)
Cc: specs@openid.net
Subject: Re: OpenID Security
What do you mean, the implementation? There is no the
implementation.
Are you arguing that for the OpenID *protocol* to succeed, every
*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
*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.
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?
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.
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.
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.
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.
-Peter
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.
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs
