Re: Finally, the Killer PKI Application

[D. Popkin]

-BEGIN PGP SIGNED MESSAGE-

"R.A. Hettinga" <[EMAIL PROTECTED]> writes:

> 

>  But SSL's greatest weakness is that it is oriented toward synchronous
> transactions, requiring a direct connection between participants.

Yep.  Makes it difficult to thwart traffic analysis.

>  Security in the Message
> The solution to this problem, as put forth in standards by OASIS and
> the W3C, is to absorb security into the message itself.  That is,
> provide a means of authentication, integrity, and confidentiality
> that is integral to the message, and completely decoupled from
> transport channels.

... the way encrypted email has always been.

>  The Trend Away from Channel-Level Security

> ... Furthermore, everyone is building systems predicated to have key
> pairs on both sides of a transaction: at the message producer
> (client), and the message consumer (server).

> ... SSL is sufficient for Web-like, client/server application, but
> large enterprise computing is built on asynchronous messaging;

This is welcome news also for pseudonymous p2p commerce.

> So PKI is back.

Maybe a work-around can be devised.

> Scott Morrison

D. Popkin


-BEGIN PGP SIGNATURE-
Version: 2.6.3ia
Charset: noconv

iQBVAwUBQdDl3PPsjZpmLV0BAQGyVAIAu5Zc+PFv8CuKkzFv3hmnkIlZ/bXVmMNQ
zg2o1rG/4omH5RFn9B4VXJsCxespviw+Ysnpa31XgQ8f9LdxYCIz4w==
=MbdB
-END PGP SIGNATURE-

Re: Finally, the Killer PKI Application

[James A. Donald]

--
> <http://sys-con.com/story/print.cfm?storyid=47592>
>
> (SYS-CON)(Printview)
>
> Finally, the Killer PKI Application Web Services as an 
> application - and a challenge December 22, 2004 Summary 
> Enterprise PKI has a bad name. Complex, costly, difficult to 
> deploy and maintain - all these criticisms have dogged this 
> technology since it first appeared.

Because PKI sucks.

> To the dismay of so many CIOs, few applications have stepped 
> up to make effective use of PKI.

Because PKI sucks.

> A Role for PKI WSS goes to great lengths to remain flexible
> and not to specify a particular encryption/signing
> technology.

Or in other words, due to the fact that PKI sucks, they have 
left the door open for a replacement.

>  now the investment may finally be realized.

I don't think so. 

--digsig
 James A. Donald
 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG
 wBk2DrWHeXk89xcxEqBeSgid7cCLVSNvu1z47YJW
 4VzhTnreELC1p4yrs3eDjP2/svE8kzr6HxxP9ToWm

Finally, the Killer PKI Application

[R.A. Hettinga]

<http://sys-con.com/story/print.cfm?storyid=47592>

(SYS-CON)(Printview)

Finally, the Killer PKI Application
Web Services as an application - and a challenge
December 22, 2004
Summary
Enterprise PKI has a bad name. Complex, costly, difficult to deploy and
maintain - all these criticisms have dogged this technology since it first
appeared. To the dismay of so many CIOs, few applications have stepped up
to make effective use of PKI. But this may soon change: Web services
promotes a security model that demands the flexibility that an enterprise
PKI deployment can offer.
By Scott Morrison 

Enterprise PKI has a bad name. Complex, costly, difficult to deploy and
maintain - all these criticisms have dogged this technology since it first
appeared. To the dismay of so many CIOs, few applications have stepped up
to make effective use of PKI. But this may soon change: Web services
promotes a security model that demands the flexibility that an enterprise
PKI deployment can offer.

 The Trend Away from Channel-Level Security
If you lumped all the existing, production-level Web services applications
together, and categorized their security models, you would probably
discover some interesting trends. First, an awful lot of these don't
address security at all, which probably owes more to the relative
immaturity of Web services technology than to a conscious choice on the
part of developers. The bulk of the remainder will simply delegate security
entirely to SSL - or in some cases, a VPN connection.

 SSL isn't a bad choice. It provides confidentiality and integrity.
Automatic sequence numbering stands guard against replay attacks. Servers
are always authenticated using a certificate that binds the server's DNS
name to the Subject, a strategy to defeat man-in-the-middle and
impersonation attacks. This does rely heavily on the integrity of the DNS
system, but by and large it is viewed as an acceptable risk. SSL even
offers optional client-side certificate authentication, which is powerful,
though in practice rarely implemented.

 Probably the most unheralded quality of SSL is channel continuity. Once a
session is set up - and once the client and server mutually authenticate
(with the client using a certificate under SSL, through HTTP
authentication, or an application-level means such as forms) - a level of
trust is established on the open socket so that it is available for
multiple transactions without repeating this lengthy process each time.
There is great value in a transparently maintained security context, and it
is easy to take for granted.

 Of course, one of the reasons behind SSL's success on the Web was that,
although it utilizes public key cryptography, it doesn't need full-blown
PKI. Most SSL-enabled Web servers use certs issued by the "browser cartel,"
those CAs fortunate enough to have their root certificates automatically
installed within the trust store of the most popular browsers. And with the
exception of a few early consumer banking products - which have largely
been abandoned - almost nobody steps up to the baroque logistics of
client-side certificates on the Web. The ability to delegate PKI to a third
party greatly simplified security on the Web; this was one of the reasons
SSL became good enough for most online transactions, even when challenged
in the early days by technically elegant, though complex, solutions like
SET (Secure Electronic Transaction).

 But SSL's greatest weakness is that it is oriented toward synchronous
transactions, requiring a direct connection between participants. It's like
an encrypted telephone conversation, which is probably something alien to
you and me, but I suppose that James Bond uses it regularly. Both parties
need to be available, multiple passes are necessary to set up a secure
context, and all of the information - the critical points alongside the
mundane ("how's the weather in London?") - is encrypted wholesale, which
can be a costly processor burden.

 This is why SSL is an insufficient security model for Web services.
Despite the name - an unfortunate one that is probably one of the great
misnomers in the history of technology - Web services isn't really about
the Web. In one realization, it does use existing Web infrastructure,
including HTTP transport, Web application servers, etc. However, Web
services is fundamentally a one-way messaging paradigm for computer
communications, composed around a simple XML message structure with an
extensible header model.

 Web service messages may not piggyback on HTTP at all. They might flow
across a message-oriented middleware (MOM) such as IBM's MQSeries, or be
carried asynchronously by that other ubiquitous infrastructure, SMTP. SOAP
messages are designed to flow through a network of intermediates, not
unlike IP packets being passed between routers. Intermediates may be
required to view header information to make processing decisions based on
a