UTXOC - Unspent Transaction Output based Certificates

[MiWCryptoCurrencyMA]

Unspent Transaction Output based Certificates UTXOC ‘you-chi-ock’

Proof of concept cryptocurrency (bitcoin-like) private keys used to generate valid signed ECDSA with-SHA256 x509 certificates to be used for medium term authentication within the TLS protocol and other and future applications. These certificates have additional explicit value by merit that they prove ownership of decentralised bitcoin-like value. This construction has been formatively titled Unspent TransaXtion Output Certificate or UTXOC, pronounced ‘you-chi-ock’.

What does this provide in addition to every-day Trusted CA Certified certificates we know and love from such trusted names as Honest Achmed and Diginotar?

By generating an x509 certificate that uses this key, one can explicitly reference the transaction in which some value was transered to this address. By ensuring that the transaction is not claimed (spent) for the lifetime of the certificate, clients have an independently verifiable way of detecting key compromise; as well as increasing the cost for active attacks against TLS. Additionally it provides a bearer bond type construction that can be used with existing x509 infrastructure and devices such as elliptic curve smart cards; and proof of ownership signatures can be made without the official wallet software.

Paper: https://github.com/MiWCryptoCurrency/UTXOC/blob/master/UTXOCv1.pdf?raw=true

The git repository also has scripts:
https://github.com/MiWCryptoCurrency/UTXOC/
 * eckey2coin.py (to easily generate the address + QR code, based on pycoin key utils (ku).
 * utxocsr.py (to generate a certificate signing request from a raw EC key; and embed the transaction hash in the x509v3 Subject Alternative Name.

You will need pycrypto, pyasn1, pycoin, pkiutils, binascii and qrcode for python.

You also need to tweak the utxocsr.py to use the specify your distingushed name; its at the bottom of utxocsr.py.

Yours in cryptography && cryptocurrency,

MiWCryptoCurrency

[DeathAndTaxes]

That is an interesting idea to use the blockchain for revocation.  unspent = valid, spent = revoked.   Even if private key is compromised the attacker can't prevent the original owner from revoking the cert (unless original owner loses access).  The amount of the output can also scale to the security level desired.   If the "bond" amount is larger than the expected return from misusing the cert the attacker is likely to just claim the bond and thus revoke the cert.

One thing I would consider adding is an optional mechanism to allow the bond to expire.  This is pretty common in PKI and allows a way to expire certs for which control of the key has been lost.

[grau]

+1

A cool idea for certificate validity and revocation. Maybe even extensible to trust net by examining sources of the UTXO.

[MiWCryptoCurrencyMA]

Hi DeathAndTaxes,

I like the idea that in the event the bond has expired -- ie: the wall time is past the ValidTo date on the certificate, it could be automatically returned to another address -- however this would need to be done in the claim script when first generating transaction reference in the certificate.

I want to extend this to directly interact with bitcoin-like clients, it could construct the claim script for the transaction so that there is a time dependent claimable output -- not sure how to do this at the moment.

One possibility is something like the difficulty hash function; although the medium term validity life of a certificate makes it hard to predict a future difficulty value.
The other issue with this approach is it is likely more economical to mine the network directly; there is less incentive for a PKI CA to be crunching away for 3 years just so the output can be returned.

Very open to suggestions on this. The network offers a reasonably accurate distributed consensus of wall clock time; is there a realistic possibility that the script alphabet could be extended to include date time functionality? Is this a good idea to do this?

Another  idea could be a revocation key; similar to how GPG works. However the issue there is that practically, if you have lost the private key to your funds, you are likely to have lost access to the revocation key! 

My paper also makes the same argument regarding attacker likely to steal the funds -- it is hoped by making the private keys more valuable (because they dont just represent medium term auth keys; they also represent proof of ownership of funds); people will protect them better. Or likely steal them and the world will be able to know.

[Peter R]

This is a very nice idea and something that I think will happen.  I've heard similar ideas before, but they didn't include the certificate revocation by spending the output (which I think is very useful).  Like you said, the fact that the output's value is not-insignificant also allows it to serve as a "proof of intent" bond.  

To implement an expiry date, could the certificate creator generate (when he first creates the cert) a N_LOCKTIME transaction that spends the output to another address that he controls, and then publish this TX somewhere public?  Even if something happens to the issuer, as long as someone retains this N_LOCKTIME transaction, it will probably end up mined shortly after it becomes valid (thereby expiring the certificate).  

[MiWCryptoCurrencyMA]

N_locktime! Of course, rather than having the datetime in the script;
use the transaction n_locktime flag to prevent the TX spend before the certificate validity is there.

So you have 2 TX's, one the 'loads' the key with some value pre-signing (so it can be included in the cert), and another generated post-signing that allows these funds to be bounced somewhere after the cert is invalidated by time.

This is seems to be equivalent to the revocation certificate; as long as it is signed by the UTXOC key at key generation time, it can be submitted by any anonymous party any time after n_locktime. This is advantageous over the PGP revocation model in that anyone can submit this on your behalf, and has a good reason to do so.
My suggestion would be you provide an incentive that someone other than the key owner could be bothered including the TX -- I'm thinking fees.

If you can construct the "revoke funds" TX with sufficient fee, miners have an incentive to seek out these previously signed TX, published publicly, and include them in the next mined block past the n_locktime unix time. It seems this requires some public place to store these transactions; maybe this is a service that could be offered by exchanges or even CAs?

I like that this doesn't actually prevent the key holder from revoking the certificate at any other time before the validTo date, as the owner is free to construct a TX that invalidates the 'sign time' revocation TX as a double spend.

Also, grau, this is also a good idea. I had not considered tracing the source of the UTXOC as a a way of bootstrapping the trust.
There is a potential here to do away with long-term trusted root distribution.
As long as the CA could prove solvency with an unbroken chain of value transfers, one could use a known trust anchor by inspection of the sources to generate the next valid root.

I guess my next step is write the validation routines; I wanted to publish the paper and code last night, so i didn't get to finish the whole lot before public release.

Thank you DeathAndTaxes, grau and Peter R for your very valuable suggestions

[weex]

Any updates? I'm really interested in the idea of chained credentials in regards to Bitcoin, smart contracts, smart property, etc.

[etotheipi]

By the way, I had a similar idea a while back, but reversed:

https://bitcointalk.org/index.php?topic=525317.0

Rather than spending an output to revoke, you send money to an address to revoke.  If it's your key & address, it costs nothing to revoke it (you send yourself money), but it costs someone else quite a bit.  I mentioned how companies could set the value to the cost of someone maliciously revoking their key.  If needed, the authorized owner can borrow the money momentarily to trigger the revoke condition and then return it. (it always also requires a signature to revoke, but the revocation signature can be less secure knowing that someone has to pay you to exercise it without your permission)

Your idea is much more serious and well-thought-out.  I'm not sure my idea is even feasible, but maybe it's another building block to consider (the asymmetry of using payments to yourself as a trigger for something important).

[MiWCryptoCurrencyMA]

Hi weex
Ive published the verifier script -- it uses blockchain.info and chain.so to check the transaction referenced is unspent.
https://github.com/MiWCryptoCurrency/UTXOC/blob/master/verifyutxoc.py

I also updated the generate script to take attributes, similar to how openssl req -new works.
new code is here https://github.com/MiWCryptoCurrency/UTXOC

I have also generated a 'dogecoin' cert, https://github.com/MiWCryptoCurrency/UTXOC/blob/master/doge.crt which is signed by the UTXOC-CA.crt "Root Cert"
This is an example of a chained cred; you have a 0.01 BTC certifying a 11.02 DOGE certificate :-)

I would like to set up some kind of SCEP service that signs valid CSRs; next step :-)

[MiWCryptoCurrencyMA]

Hi etotheipi,

the first thing i thought of was reasons for revocation - from RFC 3280 Certificate and Certificate Revocation List (CRL) Profile

    unspecified (0)
   
    keyCompromise (1)
    Whomever has compromised your key is going to steal your revocation funds!
    CACompromise (2)
    catastrophic system fail; would allow any end-entity certs to move the funds to another cert. just the tx fee charge.
    affiliationChanged (3)
    what new/old employees had access to the key material? theft risk.
    superseded (4)
    if the key is old, why spend more funds to it? better to sweep to the new key
    cessationOfOperation (5)
    if life of cert ends early, sweep to spending wallet and use funds to throw closing party for your staff
    certificateHold (6)
    possible use of 'reverse' payments?
    an additional lookup of transactions matching the payout address could 'hold' certificate?
    removeFromCRL (8 )
    remove from blockchain? heh. good luck.
    privilegeWithdrawn (9)
    another possible use of reverse payments - signer sends token to address, 'poisoning' it?
    AACompromise (10)
    attribute authority (?) -- poorly understood measure in CRL. not sure how applies over reason 2.


I do like the idea of payments to a key you control to trigger some condition.
Additionally, where issuer != subject, you implicitly have the public key of the signer; payments from this address could trigger an additional event.

I am also experimenting with altcoin based UTXOC;
you could have a hierarchy of altcoin based certs - one can share the same public key, which encodes as different addresses and transactions on respective chains; or even denotes a particular kind of event.
ie: if the 'CA' transfers dogecoin from its subject public key (coin address) in its root (which itself is actually a bitcoin UTXOC) this could mean any of the 'CA' specified revocation reasons above?

[weex]

Thanks MiW,

My interest in looking for this thread was in having chained certificates based on Bitcoin credentials. It begins with someone issuing a token on Counterparty that an entire industry (like decentralized storage) might run on. In this case, I am not comfortable with the possibility that a key that issued a token and can update the asset's description might be compromised once and forever. In Counterparty, if the issuer's private key is compromised, it could be very bad not just in monetary terms but in economic terms as well. In this case, I think it would be good to have a private key that is kept offline but which has delegated other responsibilities to other keys. It's a lot like SSL CAs in this respect. Depending on where this might be implemented the responsibilities can be ones provided in Counterparty or even the ability to spend funds in Bitcoin.

For example, address A might receive funds in Bitcoin but the private key for that address might be kept entirely offline, airgapped in a vault. The key for A could have previously delegated the right to spend its funds to the keypair for address B.

The problem I've learned of is that the delegation would likely require a signature and that signature reveals the public key, thereby removing the protection provided by the additional RIPEMD-160 hashing of the public key to turn it into a Bitcoin address.

Your thoughts? Did you have anything like this use case in mind as you thought about the above?