Re: [pki-guidelines] Transaction PKI -The Browser Plugin "Silver Bullet"

["Anders Rundgren" <anders.rundgren@telia.com>]

Arshad,

Unfortunately it does not [technically] work as you claim.

In case you are rather talking about vendor-upgraded browsers
supporting an agreed-upon standard, that is at least 3 years away
(if somebody actually succeeds taking MSFT and Mozilla to the
same table implementing something they have to date not even
participated in developing).

This path is probably unrealistic without major backing from NIST,
DoD, and a few more.  You don't really need a cryptographer
anymore, you rather need a full-blown politician or lobbyist!

SAML 1.0 took 18 labor-intensive months to develop, is only
1/3 of WASP, and did not include any client security code.
SAML is also principally simple while individual signatures are anything
but trivial (even lawyers have opinions on signatures, and we all
know that few people can screw-up things more that these guys)

TPKI has BTW hardly more than scratched on the surface of this topic.

TPKI is also likely to be 2-5 as complex as WASP if the
encryption requirement stays.

First is uphill, then it gets really hard.   Been there, done that,
nowadays trying another, faster, leaner and most of all, much
more enjoyable path.

Good Luck!

Anders

----- Original Message ----- 
From: "Arshad Noor" <arshad.noor@strongauth.com>
To: "PKI Application Guidelines" <pki-guidelines@lists.oasis-open.org>
Sent: Monday, January 02, 2006 22:54
Subject: Re: [pki-guidelines] Transaction PKI -The Browser Plugin "Silver Bullet"


Anders Rundgren wrote:
> Anders R wrote:
>  > http://www.arcot.com/docs/SAFE_TPOC_FS.pdf shows a carbon copy of what I
>  > have suggested as a suitable scheme for Transaction PKI.
>  > 
>  
> /Arshad responded:/
> /This architecture uses a plug-in.  Our goal is to avoid the use of a 
> plug-in. /
> // 
> /Stephen wrote (in an earlier message):/
> /B.  For client side PKI ... I got the impression from your thread 
> gentlemen that Anders' proposed method has an extension where client 
> side private keys are also accommodated.  But Arshad wishes to avoid 
> extra plug-ins etc.  I would agree./
> // 
> But Arcot, the maybe 50 other vendors of web signature SW, and myself 
> for some reason have concluded (based on the actual offerings), that the 
> only way you can do web signing using existing browsers[1], is by adding 
> some kind of browser extension usually in the form of an ActiveX control 
> or Java applet plugin.
>  
The reason the 50 vendors developed plug-ins is because browser
never provided a mechanism for signing form content through an
API, other than the primitive signText(), as you acknowledged.

With the advent of XML, signText() is more than adequate, as
long as form content is capable of being represented as an XML
object, which is precisely what the IBM technology does through
ECMAscript for XML.  So, the following is now possible:

   Form content + E4X = XML + signText() = XML Signature

which is exactly what we're trying to achieve without the use
of plug-ins.

This is the type of architecture I hope for this SC to discuss
and investigate through the OASIS-funded resource.

> Apparently the Application Guidelines SC have found a "silver bullet" 
> which the rest of the industry in spite of years of hard work have not 
> managed to do.  Could you guys please enlighten us less gifted souls a bit?
>  
We haven't found a silver bullet, Anders; just that technology
has evolved to a point where existing and some new capabilities
are able to deliver what we want.  All that remains now is to
determine how well it works, and what are the barriers to
standardization and industry-wide implementation.

Arshad Noor
StrongAuth, Inc.