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

On Fri, Nov 4, 2011 at 11:34 AM, Pelle Braendgaard
<pelle@stakeventures.com>wrote:

> On Thu, Nov 3, 2011 at 2:05 AM, Manu Sporny <msporny@digitalbazaar.com>wrote:
>
>> Usability
>>>
>>> The very biggest problem of all is that no one has solved the
>>> usability of digital signatures except in closed systems such as
>>> Skype.
>>>
>>
>> I strongly disagree with your statement here. It's provably false, case
>> in point: HTTPS utilizes digital signatures, which every e-commerce site
>> uses to secure traffic. Hundreds of millions of people a day /directly
>> use/ digital signatures... it's just that nobody really knows that this is
>> happening behind the scenes.
>>
>
> 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.
>
>
>
>>
>> To claim that no one has solved the usability of digital signatures
>> problem is hyperbolic, IMHO. We depend on digital signatures for our
>> world-wide Certificate Authority infrastructure and we depend on digital
>> signatures for the vast majority of SSL/TLS connections made over the
>> Internet.
>>
>> More specifically, the Key Exchange Method in TLS has a provision in it
>> for using RSA key exchange, which utilizes digital signatures to protect
>> against Man-in-the-Middle attacks. Use Google Chrome and go to
>>
>> https://github.com/
>>
>> Click on the padlock icon next to the location bar and you will see this
>> message:
>>
>> """
>> GitHub, Inc. (github.com)
>> The identity of GitHub, Inc. at San Francisco, California US has been
>> verified by DigiCert High Assurance EV CA-1. [[[DIGITAL SIGNATURE
>> VERIFICATION]]]
>>
>> Your connection to github.com is encrypted with 256-bit encryption.
>>
>> The connection uses TLS 1.0.
>>
>> The connection is encrypted using AES_256_CBC, with SHA1 for message
>> authentication and RSA as the key exchange mechanism. [[[DIGITAL
>> SIGNATURE VERIFICATION]]]
>> """
>>
>>  Digital signatures are fine anywhere where it is a server signing
>>> something, such as a receipt. But in creating a transaction no way.
>>>
>>
>> What is the reasoning here? You claim that digital signatures are
>> impossible for a transaction, but then don't back up the argument with the
>> reasoning.
>>
>>  This is why I strongly believe in the approach we have taken with
>>> OpenTransact to use OAuth 2 for the transaction creation aspect of
>>> it.
>>>
>>> http://www.opentransact.org/**core.html#transfer-1<http://www.opentransact.org/core.html#transfer-1>
>>>
>>> We have talked about using optional digital signatures for receipts.
>>> In our discussion it is the asset provider (eg. a PaySwarm authority)
>>> that signs the receipt. I suppose a third party service could also
>>> sign the offer and a sophisticated seller could do the same.
>>>
>>
>> In our system an asset provider is not the same thing as a PaySwarm
>> Authority.
>>
>
> In OpenTransact both the PaySwarm Authority and the person selling
> something is an asset provider. An asset is a very generalized term, which
> is why I've balked by its use in PaySwarm earlier.
>
>
>>
>> An asset provider is an entity that is selling something, like a song,
>> blog post or article.
>>
>> A PaySwarm Authority is an entity that is handling the transaction (and
>> transfer of money from source to destination accounts.
>>
>> The asset provider performs digital signatures on assets (things for
>> sale) and listings (the terms under which the sale can occur).
>>
>> You are correct in that the PaySwarm Authority is the one that digitally
>> signs the receipt... but there are more advanced use cases (such as
>> contract negotiation - negotiating for a certain price, for instance) where
>> the contract offer can be submitted directly from the customer to the
>> vendor. That is, each party in a transaction may perform a digital
>> signature to establish trust in the transaction.
>>
>
> This sounds really simple, with the exception of the bit where the
> customer signs a contract. See my statements above about end users
> performing digital signatures.
>
>
>>
>>  The new JOSE (JSON Object Signing And Encryption) group in IETF is
>>> doing good work in this area and should definitely be looked at for
>>> receipts and other signed objects.
>>>
>>> http://self-issued.info/docs/**draft-jones-json-web-**signature.html<http://self-issued.info/docs/draft-jones-json-web-signature.html>
>>>
>>> This comes out of the OpenID connect work and provides a really
>>> interesting approach to creating small signed and/or encrypted
>>> objects to be passed along across the web. Thus fits our purpose
>>> well.
>>>
>>
>> We had a look at the latest specs when they released an update to them a
>> few days ago.
>>
>> 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.
>
>
>> 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
>
>
>> 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.
>
>
>> 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.
>
>
>>
>> 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.
>
> 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.
>
>
> Pelle
> --
> http://picomoney.com - Like money, just smaller
> http://stakeventures.com - My blog about startups and agile banking
>



-- 
http://picomoney.com - Like money, just smaller
http://stakeventures.com - My blog about startups and agile banking