Re: WebID-TLS using X509 fingerprints

Hey guys,

In the Interledger Project [1] we have been solving a different but similar
problem and in the process have developed a system called crypto-conditions.

We had a requirement for a signature data type in the Interledger
Protocol's core data model but needed this to be flexible and also have a
few other features.

For some background on our requirements, the protocol relies on one or more
ledgers that are involved in an end-to-end transfer being able to put funds
on hold pending the fulfillment of a predefined condition. This condition
is, in effect, the definition of a signature and the fulfillment of that
condition is the signature itself.

Example 1: Condition = SHA265Hash(X), Fulfillment = X
Example 2: Condition = RSA Public Key, Fulfillment = Message, Signature of
message generated using RSA Private KEY
Example 3: Condition = RSA Public Key and Prefix, Fulfillment = Message,
Signature of (Prefix + Message) using RSA Private Key

More information is available from Crypto-condition workshops presented at
Interledger[2] and at IETF[3]. In adition, Crypto-Conditions
(draft-thomas-crypto-conditions-00) has been submitted as an Internet Draft
for candidacy as a standards track RFC[4].

An essential requirement of crypto-conditions is that any implementation
*must* be able to evaluate if it will be able to validate the signature
later (fulfillment) just by looking at the signature definition
(condition). This allows a ledger to reject a transfer that is using a
condition the ledger doesn't support before the end-to-end transfer is
fully prepared, avoiding a case where the ledger fails to release the funds
upon receipt of the signature (fulfillment) because they are unable to
validate it. It also meets the core purpose of the provability requirement
for smart signatures, even if it does so by a slightly different manner.

Crypto-conditions define a format for encoding these signature definitions
(conditions) and signatures (fulfillments) that incorporates a
feature-requirement bitmask and a max-fullfilment size to protect
implementations from any overflow attacks.

Crypto-conditions are *deterministic*. Rather than attempting to define a
Turing complete signature language crypto-conditions simply combine
existing primitives that can be deterministically validated on any
platform. As such, the combined result, which uses simple boolean algebra,
is also determinisitic across platforms.

Crypto-conditions are also nicely *compact*. Complex boolean logic trees of
hashed conditions can be compacted down to a single hash using Merkle
Trees, while a fulfillment can also leave any unfulfilled branches (such as
in an m-of-n signature) as hashes.

If you're interested in contributing to the work it's being done as part of
the Interledger project (a W3C community group) and details of the
community resources are on the website: https://interledger.org/
community.html

Adrian

[1] https://interledger.org
[2]
https://www.youtube.com/watch?v=YfBDDWp58po&list=PLIR1FI1vEGeGvladEm-YZIvokXyH4bbIL&index=7
[3] https://youtu.be/uPXXfClTqSY?t=49m8s
[4] https://datatracker.ietf.org/doc/draft-thomas-crypto-conditions/

On 15 September 2016 at 12:53, Henry Story <henry.story@gmail.com> wrote:

>
> > On 13 Sep 2016, at 13:58, Jacopo Scazzosi <me@jacoscaz.com> wrote:
> >
> > Hello.
> >
> > First mail to this list. My name's Jacopo Scazzosi, nice to meet you all.
> >
> > I've been recently researching the world of WebID-TLS. The current specs
> seem to dictate the use of RSA. As one of my requirements is the support of
> different types of keys, I've written a proof-of-concept authentication
> module for nodejs using X509 fingerprint comparison instead
> exponent+modulus comparison. I'm currently using SHA-256 fingerprints but I
> plan on leaving the choice of the hash function up to our subjects. Module
> is here: https://github.com/jacoscaz/node-webidentity
>
> It is clear that one should extend WebID auth way beyond RSA.
>
> but the protocol by being limited to RSA had the advantage of being simple
> and very clean.
>
> One could extend to larger number of keys in a number of ways:
>  1. by extending the ontology to cover all the other cryptographic key
> types.
>  2. by building on older standards binary standards susch as X509 inside
> of PEM and including those in the rdf or pointing to them
>  3. something like what you suggest
>
> They each have their advantages and disadvantages.
>
> Because what counts for this to work is interoperability, one really would
> need to know how many people with how many webId deployments in the making
> would be coming on board if one of these is adopted.
>
> 1. is a lot of work, but may be a lot easier because of the ground work
> done by JOSE.
>   But just thinking about that is going to be a lot of work.
>
> 2. Is what web payments group have done and could be followed
>    https://web-payments.org/vocabs/security
>
> 3. requires an ontology for X509 certificates in particular.
>    What is the use case of what you are looking for over and above 1 and 2.
>
>
>
> > Has support for non-RSA keys been already considered in the past?
>
> yes. The aim of this group was to come to a definition of the webid
> protocol.
> The work on cryptographic ontologies would require us to have a lot more
> knowledgeable cryptographers
> on board than we have had, so it was left to be done for a later time.
>
> Henry
>
> >
> > Cheers.
> >
> >
>
>
>