[hashcash] more format musings

From: Adam Back <adam@xxxxxxxxxxxxxxx>
To: hashcash <hashcash@xxxxxxxxxxxxx>
Date: Fri, 30 Apr 2004 21:06:46 -0400
One thing that occurs to me is there are other types of authentication
which have been proposed in relation to hashcash.

For example MAC based white-list implementations; or CAMRAM style
signature based white-list implemetnations.

So the proposed extension mechanism could be used to introduce said
MAC key, eg:

X-Hashcash: 1:20:040430:kyle@xxxxxxxxxxx:mac-key=0123456789abcdef01234
        56789abcdef:35385ea2086e2b12:15003e

which would mean I am doing two things, sending kyle a hashcash stamp,
and sending along a mac-key in-case he would like to add me to his
whitelist of people able to send without requiring hashcash.  (He'll
tell me he's white listed be somehow in his response).  This is a bit
like TMDA reply mangled addresses with tokens in them.

Or, a DSA public key:

X-Hashcash: 1:20:040430:eric@xxxxxxxxxx:camram-pub=gV/MV0ShcFu6gGnMFte
        9pWicVrR9awLqUHMncCtTubZpp67RRB51iPu4h1yD5abhxpeB1wvmCgBgxvzfr
        g9m39v7ZUblTtHr2btANWNL37ygbAt9ApYdq7brJozp7Njwue28xkd7RxLp7na
        YjIlIYNiFsF1zj+rlt6sEX9qenHw=:8123144225448504:1a4b32

where again doing two things, sending stamp and public key if the
recipient wants to white list me.

(That is not a real DSA public key, but it is the right size 1024 bits
to give an indication of size).

(Btw#2 the = in the base64 throws up a minor side-issue are multiple =
signs allowed between ; separated name=val1,val2;name2=val3,val4 name
value lists.  I think it would be nice to be able to use std base64
encoding, so I guess we just say the name comes before the 1st =, the
rest (= included) is part of the , separated value).

But after this how will I the mac-key or signature key be used.
Hashcash at present does not help at all once you've got the key, so
presumably some other header would have to be used.

So the musing is what would we have to do to the hashcash header to
make it support extensible auth types (auth types other than hashcash
like MAC, signature and other things people might add).

so I think this means taking the hashcash specific things and putting
them into an extension field, eg something like:

X-Hashcash: 1:camram-pub=gV/MV0ShcFu6gGnMFte
        9pWicVrR9awLqUHMncCtTubZpp67RRB51iPu4h1yD5abhxpeB1wvmCgBgxvzfr
        g9m39v7ZUblTtHr2btANWNL37ygbAt9ApYdq7brJozp7Njwue28xkd7RxLp7na
        jIlIYNiFsF1zj+rlt6sEX9qenHw=;hc=20,040430,eric@xxxxxxxxxx,
        8123144225448504,1a4b32

and then the signature like:

X-Hashcash: 1:stuff=blah;camram-sig=cCtTubZpp67RRB51iPu4h1yD5abhxpeB
        1wvmCgBgxvzfrHr2btANWNL37ygbAt9ApYdq7brJoz==

where the authenticated stuff comes before the authentication token,
stuff=blah is whatever camram wants to sign with it's sig, and
hashcash hashes stuff before the hc name values list, plus the bits
inside the hc values list up to 3rd field (email address of
recipient).

Or is this violating the do one thing, and do it well model.  (Do
hashcash and hash extension records, vs be a crappy extensible email
challenge-response format).

People may want multiple auth fields (eg hashcash and signature) but
we can not both hash the signature and sign the hash.  We could hash
the signature or sign the hashcash (so auth stuff to left seems
reasonable).  Unless there is some reason to just auth the stuff,
excluding auth tokens.

Anyway comments and further musing sought...

Adam
[hashcash] more format musings

Other related posts:
