Re: [pki-guidelines] WASP: Web Sign std. - Running on the net

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

Arshad et al,

 

The purpose of the server stuff is only to provide a proof-of-concept that is non-intrusive (=anybody should be able to play with it), not to push server-side signing.  At least not in THIS context :-)

 

http://sid.the-demo-bank.com/wasp

 

Although the proof-of-concept is simple (<100K), it still supports signing of arbitrary web compatible media as well as attachments.

 

But there are other approaches of course.  Your preferred approach seems to be having a potent API that you can script to the point that you can create an infinitely sophisticated "web-crypto-app".

 

Some reasons why I want to pursue the WASP approach to Web Sign is that it combines a number of interesting features that makes it similar to S/MIME (w.r.t. signing), which is universality, simplicity, and thus hopefully also interoperability.  The latter ought to be very hard to achieve using an API-based scheme as this by definition allows you to do "anything".  I don't see a strong need for such flexibility if there is a standardized scheme that supports:

 

- Document format independence

- Strict XML DSig profile(s)

- Minimal footprint

- OS, device, and computer-language independence

 

That it currently does not support:

 

- Explicit message encryption

- Signing of "live" form data

- Signature validation

- Multiple signatures

- A scriptable API

 

may look as a major "omission", but I can attest that all items listed, except for API scripting, already have fully acceptable server-based solutions, that at least I don't think it would be wise to duplicate.

 

Signature validation for example would force a client to deal with certificate paths potentially belonging to unknown PKIs as well as dealing with expired certificates.  A task ideally tailored for the server to handle, as well as displaying such data in a user-interpretable way.  An example:  If a certificate was valid during signature receival but later expired, it would be awfully stupid to indicate (like Outlook) that something may be "wrong".  But nothing is wrong or should be warned about!  Otherwise the signature had been rejected by the server in the first place. On-line makes a huge difference and standards should IMHO be designed accordingly.

 

That is, WASP is a scheme for the masses that don't understand what PKI is, and probably never will (or should).

 

This may or may not be of interest to the PKI-TC, but WASP is actually just a "compilation" of existing schemes that are already in use by millions of people in the EU.

 

thanx

Anders

 

PS Regarding the need for plugins, I don't think that a browser-based app is allowed to call any API just like that.  That is, no matter what we do, we will probably have to provide something new to the browser environment in order to get local signing running.  If that is a trusted plugin or a trusted library should not make much difference from a distribution or development point of view.

 

A fairly complex PPT is available for those who want to look on the nitty gritty.

 

DS

 

 

----- Original Message -----

From: "Arshad Noor" <arshad.noor@strongauth.com>

Cc: "PKI Application Guidelines" <pki-guidelines@lists.oasis-open.org>

Sent: Wednesday, October 12, 2005 01:53

Subject: [pki-guidelines] Re: WASP: Web Sign std. - Running on the net

Thank you, Stephen, for pointing out my error; I should've
responded 
to Anders on the alias in the first place.  Anders,
you are authorized 
to send e-mail to the alias, so you should
use that when communicating to us 
about the web-form signing
work.

While (A) does work, in principle I 
disagree with that approach,
and its not just for non-repudiation 
purposes.  The premise most
companies use in that approach is: it is OK 
for people to log in
to applications using a shared secret-key, but then we 
will sign
the transaction using public-key crypto.  Why bother at 
all?  If
I can usurp your shared secret with any number of methods at 
my
disposal, I can create a signed transaction.  And what will 
that
prove?  That nobody modified the transaction after it was 
signed.
I could do that anyway, at any time on the back-end.

The whole 
point of this exercise of using private-keys in the
possession of the user on 
the client-side, is that it not only
provides data-integrity from the 
client-end, but also serves to
strongly authenticate the client 
itself.

Assuming that, the XML Signature is the way to go.  While 
browsers
currently support XML, and some even support XForms, they have 
not
yet gotten to the point where they permit XML Signature and 
XML
Encryption originating at the client.  That is what I want 
this
SC to achieve.  I believe we will get there, as I see a 
confluence
of many events that seem to bring us to that:  Sun recently 
put out
an implementation of XML and Web Services Security (based on 
the
OASIS Web Services Security spec) that abstracts the whole 
XML
Signature/XML Encryption to a very high level API.  Although 
this
is available only in Java today, it brings this much closer to
where 
we need this to be for form-signing without any plug-ins and
downloaded 
applets, etc..  A C/C++ implementation is probably being
written 
somewhere as we speak, and once available, web-form signing
should be a hop 
and a step away.

Arshad Noor
StrongAuth, Inc.

http://java.sun.com/webservices/docs/1.6/tutorial/doc/XWS-SecurityIntro.html#wp540763
http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0.pdf
http://www.ws-i.org/


Stephen Wilson wrote:
> 
> Hi Guys. 
> 
> Sorry 
but I have got lost now :-(  Bear in mind I am not an XML expert at 
> all ... but this is how I thought things would be: 
> 
> A. 
For server-side PKI, users will have a private key on a server machine, 
> 
invoked on their behalf after the user authentciates themselves by some 
> 
means.  In many cases, one 'gateway' private key is shared by multiple 
> people.  But I also know of organisations now that are offering to 
keep 
> multiple users' private keys in secure store centrally.  This 
is in 
> principle just like roaming except that the private key is never 
uploaded 
> to the user's local machine.  I actually like it, even if 
non-repudiation 
> purists get nervous. 
> 
> 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 accomodated.  But Arshad wishes to avoid extra plug-
> 
ins etc.  I would agree. 
> 
> But here's where I am confused 
... if the user has a private key in their 
> client system, don't we 
'revert' to something like XML signatures, where a 
> form is served up by 
the server to the client, and a standard crypto API 
> is used to locate 
and invoke a locally available private key to creat a 
> signature 
locally, which is then sent back to the server? 
> 
> With XML 
signatures support (plus CAPI or whatever) there is no need for 
> 
plug-ins at all is there for this scenario B? 
> 
> Sorry if my 
question is a stupid one. 
> 
> Cheers, 
> 
> 
Stephen.
> 
> PS.  Why is this interesting thread confined to 
we three and does not 
> include the whole SC list?  
> 
> 
> Stephen Wilson
> Lockstep Consulting Pty Ltd
> 
www.lockstep.com.au
> ABN 59 593 
754 482
> 
> 11 Minnesota Ave
> Five Dock NSW 2046
> 
Australia
> 
> P +61 (0)414 488 851
> 
> 
--------------------
> 
> About Lockstep 
> Lockstep was 
established in early 2004 by noted authentication expert 
> Stephen 
Wilson, to provide independent advice and analysis on cyber 
> security 
policy, strategy, risk management, and identity management.  
> 
Lockstep is also developing unique new smartcard solutions to address 
> 
privacy and identity theft. 
>  
> 
> 
> 
> 
> 
>>This is exactly what I'm trying to avoid in the OASIS 
effort
>>that the Applications Guidelines SC is addressing, 
Anders.
>>People do not want to install plug-ins anymore - for 
many
>>reasons: security, deployment issues, configuration 
issues,
>>stability issues, etc.
>>
>> From my point 
of view, the only acceptable long-term solution
>>is that the web-form 
signing/encrypting code has to become part
>>of the browser itself, so 
that it can be managed as part of the
>>browser management.  
Comapanies will accept the responsibility
>>if it is part of the 
browser - not as a plug-in to the browser.
>>
>>This is the 
reason why I'm focusing on Firefox, because the
>>code is available and 
can be modified by independent developers
>>if need be.  Once it 
works, it can be contributed back to Mozilla,
>>who will do their own 
QA and make it part of their source tree.
>>Alternatively, they 
themselves will do it if we make the case
>>for its 
needs.
>>
>>Arshad
>>
>>Anders Rundgren 
wrote:
>>
>>>Yes, plugins seems to be the most realistic 
way ahead.
>>>I know that IE can do this and I hope that Mozilla can 
do it as well.
>>>The plugin needs to access three parts of the 
browser
>>>- https channels including session 
cookies
>>>- cryptolib
>>>- rendering 
engine
>>>
>>>The latter is crucial as WASP should not 
need to display on its 
own.
>>>
>>>Anders
>>>----- Original Message 
-----
>>>From: "Arshad Noor" <arshad.noor@strongauth.com>
>>>To: "Anders Rundgren" <anders.rundgren@telia.com>
>>>Cc: "Stephen Wilson" <swilson@lockstep.com.au>
>>>Sent: Tuesday, October 11, 2005 
21:21
>>>Subject: Re: WASP: Web Sign std. - Running on the 
net
>>>
>>>
>>>How would the "real WASP" 
client be implemented?  Are you
>>>envisioning a plug-in, 
contributed code to Mozilla, or some
>>>thing 
else?
>>>
>>>Arshad
>>>
>>>Anders 
Rundgren 
wrote:
>>>
>>>
>>>>Arshad,
>>>>
>>>>Since 
the process of definining a Web Sign standard is so hard, I 
> 
> 
think that
> 
>>>>asking people for downloading a real 
client would disable the dialog 
> 
> with
> 
>>>>a potential "user and development community" before it even 
started.
>>>>
>>>>Therefore the PoC is a only Web 
"emulator" that runs the crypto on the
>>>>serverand uses HTML as 
a GUI.
>>>>
>>>>A real WASP client would typically 
call the API associatd with the
>>>>browser itsellf although this 
part could be configurable as well.
>>>>An MS-implementation 
would only use CAPI I presume.
>>>>
>>>>I plan to 
add a FAQ and spec. soon.
>>>>
>>>>The launch 
alternatives are probably as an OASIS TC or as
>>>>an OpenSource 
project.  What I actually settle on depends on
>>>>how my 
employer sees on this effort as well as how many
>>>>people who 
supports an OASIS track.
>>>>
>>>>Tme will 
tell.
>>>>
>>>>My first real test was with the 
Swedish tax-department and that
>>>>immediately showed that the 
"nomenclature" is a big thing and
>>>>that this may have to be a 
preference parameter that a WASP
>>>>client may or may not 
honor.
>>>>
>>>>Today Microsoft asked for the 
spec!  Maybe the fact that 90%
>>>>of similar systems are 
based on Java applets (usually not using
>>>>CAPI) made them a 
bit 
motivated...
>>>>
>>>>regards
>>>>Anders
>>>>
>>>>----- 
Original Message -----
>>>>From: "Arshad Noor" <arshad.noor@strongauth.com>
>>>>To: "Anders Rundgren" <anders.rundgren@telia.com>
>>>>Cc: "Stephen Wilson" <swilson@lockstep.com.au>
>>>>Sent: Monday, October 10, 2005 
21:03
>>>>Subject: Re: WASP: Web Sign std. - Running on the 
net
>>>>
>>>>
>>>>Anders,
>>>>
>>>>While 
the web application does show that something got signed, how 
> 
> 
will this work if myprivate key is on my desktop instead of
> 
>>>the
>>>
>>>
>>>>server-side 
having it under its control?  How will the web-browser 
> 
> 
gain access to myprivate key to deliver the same capability?
> 
>>>>Arshad
>>>>
>>>>----- Original 
Message -----
>>>>From: Anders Rundgren <anders.rundgren@telia.com>
>>>>Date: Monday, October 10, 2005 12:25 
pm
>>>>Subject: WASP: Web Sign std. - Running on the 
net
>>>>
>>>>
>>>>
>>>>
>>>>>http://sid.the-demo-bank.com/wasp
>>>>>
>>>>>Proof-of-concept 
demo.
>>>>>
>>>>>anders
>>>>
>>>>
> 
> --
> <Put email footer here>