Re: Digital Signature Usability (was Re: The Argument for Digital Signatures)

On 11/04/11 11:34, Pelle Braendgaard wrote:
> OK I should be more specific here. The only application that 
> successfully uses digital signatures as an authentication device for
>  end users is skype. Every other application from PGP to SMime and 
> client side certs have failed. Of course https works as it is 
> something that server provider does. I just realized that BitCoin of
>  course is another example of a successful end user PKI system.
> 
> Any work with end users and PKI requires the use of external
> clients. This means it is no longer a web standard we are looking
> for. None of the major browsers are going to solve this for us in the
> next couple of years. Less so in the mobile space.
> 
> From what I understand you want individual transactions to be signed
>  by both the merchant and the end user. The merchant is doable as he
>  will be using a web application. The end user is close to impossible
>  to solve.

Ah, I believe this is where the mis-communication is happening.

No, we don't want the end customer to perform a digital signature. We
want the PaySwarm Authority to digitally sign the contract, which I
think you're fine with doing.

We also want the person that is listing the asset for sale to digitally
sign the asset (the thing that is being sold) and the listing (the terms
under which the asset is being sold).

To put it another way, the PaySwarm Authority is acting as a digital
signature Agent on behalf of the end customer.

> Digital signatures are fine anywhere where it is a server signing 
> something, such as a receipt. But in creating a transaction no way.

For PaySwarm 1.0, I agree.

However, we do have working code showing how digital signatures can be
made by end customers using pure browser technology. We put together a
demo of how this technology works a few years ago:

http://digitalbazaar.com/2010/08/07/webid/

The demo can be found here (accept the invalid security certificate,
it's fine for the demo):

https://webid.digitalbazaar.com/manage/

The demo allows you to assign every Web-based device that you have a
temporary (or permanent) public/private keypair. This allows you to
delegate which devices that you own are capable of performing end
customer digital signatures - no external clients required... all of it
works in the browser.

The newest demo uses pure JavaScript, HTML5 Local Storage and WebSockets
(all browser-based technologies).

>> The short of it is that JWT, JWS and JWE is insufficient for our 
>> use cases due to the following reasons:
>> 
>> 1) JWS only secure and sign messages as a part of the HTTP Header
>> - the signature is out-of-band from the data, which means that a 
>> program must be able to extract data from the headers and apply 
>> them to the body of the document. This is more complicated than 
>> just processing the body of the document.
> 
> I don't understand this. There is no mention of the http header in 
> that document. But please take up your concerns with them.

>From the introduction to the specification:

"""
JSON Web Token (JWT) is a compact token format intended for space
constrained environments such as HTTP Authorization headers and URI
query parameters.
"""

>> 2) JWS signatures are not applicable to graphs of information
>> (RDF) - there is no normalization protocol. Even if there was a 
>> normalization protocol for JSON key-value pairs, it wouldn't work 
>> for graphs of information. Since there is no normalization 
>> protocol, you have to have the original data structure to verify 
>> its hash or signature.
> 
> If you have solved this it may be a great extension to JWS

It may... I have a feeling that they're not going to care much about
graph-based data structures. For people that have never needed a
graph-based data structure, it seems like overkill. That is, we've been
through this discussion with die-hard key-value pair storage folks
before and they tend to shun graph-based data structures.

However, those past experiences shouldn't keep us from talking to these
people and trying to convince them that this is a good way forward.

>> 3) JWS is more complicated than it needs to be - supporting every 
>> hashing, signature and encryption mechanism is a non-goal for 
>> PaySwarm because it makes the spec much more complicated than it 
>> needs to be.
> 
> I believe JWS supports a few different mechanisms. The web payment 
> standard could require only a subset of these. Eg. only RSA-SHA256
> or something like that.

>From the spec:

"""
Of the JWS signing algorithms, only HMAC SHA-256 MUST be implemented by
conforming JWT implementations. It is RECOMMENDED that implementations
also support the RSA SHA-256 and ECDSA P-256 SHA-256 algorithms. Support
for other algorithms and key sizes is OPTIONAL.

If an implementation provides encryption capabilities, of the JWE
encryption algorithms, only RSA-PKCS1-1.5 with 2048 bit keys,
AES-128-CBC, and AES-256-CBC MUST be implemented by conforming
implementations. It is RECOMMENDED that implementations also support
ECDH-ES with 256 bit keys, AES-128-GCM, and AES-256-GCM. Support for
other algorithms and key sizes is OPTIONAL.
"""

The only subset that PaySwarm needs is RSA SHA-256 and AES-128-CBC,
IIRC. You're correct, we could specify the subset that is required...
but unfortunately, the other issues still don't make JWS a good solution
for PaySwarm.

>> 4) JWS objects are not fully-contained documents. JWE objects are 
>> not fully-contained documents and thus, one must specify how to 
>> store the data in the JSON objects themselves. This is important 
>> because we expect that many implementations are just going to want
>>  to grab the JSON blob and store it directly into a database like 
>> MongoDB, CouchDB, or similar.
> 
> Again I'm not quite sure I understand this. A JWS object is just a 
> JSON document. There is maybe something I've misunderstood.

The question is, where do you store the signature once you have created
it in JWS? It's left as an exercise to the reader - that's my point. We
could specify how to do this in PaySwarm, but that's not really where
the JSON digital signatures stuff should go.

To put it another way - JWS says that you can put the digital signature
and JWT header anywhere that you want to... but that means that you
could store it in an HTTP Header, store it in a metadata database
separate from the JSON document, etc. All of these solutions are sub-par
and not standardized.

So, at the very least, we'd have to spec how to store all of this
information in one JSON document if we want the JSON documents to be
fully encapsulated. By fully encapsulated, I mean the data and the
signature are stored in the same JSON document (as they are with the
JSON-LD documents that are digitally signed).

Storing digital signature information separately from the document is an
issue for digital receipts. You want the digital receipt to be
self-contained - data and signature residing in the same document. JWS
just does not clearly specify how to do this... that's my point.

I'm not saying that we couldn't extend it to do it... but you really
don't need something as complicated as JWS to do a digital signature on
JSON data.

>> Signatures on JSON-LD objects address all of the shortcomings 
>> above... I'm sure we'll get into that discussion over the next 
>> couple of weeks/months. That is not to say that JWT/JWS/JWE are not
>> useful, we have just found them insufficient for our use cases.
> 
> I suggest you join the JOSE list to deal with these short comings. 
> This will be the standard way of doing digital signatures in JSON. 
> Creating extensions and subsets of the spec is preferred to creating
>  a new one.

I'm not convinced that the JOSE list is after the same things that we
are after here. They want to digitally sign key-value pairs... we want
to digitally sign graphs. Those are two fundamentally different
approaches to data modeling and the two communities have failed to truly
find common ground in the past.

The pure JSON key-value folks feel that JSON-LD is too complicated.

The JSON-LD folks feel that the JSON key-value approach is insufficient
for the problems that they're attempting to solve.

Again, I don't mean to suggest that we shouldn't try to find some common
ground. Just re-iterating what has happened in the past when we tried to
do this.

> We are working on payments not digital signatures and I suspect 
> reinventing the wheel is not a good place for us to spend our time.

Yes, reinventing the wheel is bad.

However, the particular wheel that we need, doesn't exist. :)

This group won't be dealing with this particular problem.The JSON-LD
Community Group is tasked with expressing graph-based data structures in
JSON, normalizing graph-based data structures and digitally signing that
normalized data. So, we won't be wasting our time with that sort of
stuff in this group... unfortunately, some of us in this group, that are
also in the JSON-LD group, have to do work in the JSON-LD group to solve
the problem. :)

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny)
President/CEO - Digital Bazaar, Inc.
Standardizing Payment Links
http://manu.sporny.org/2011/payment-links/

Received on Monday, 7 November 2011 21:09:13 UTC