Re: Verifiable Text-based Claims

Hi Christopher

you tls hack paper is a nice read. However I take one issue with it, viz:

"If you have some out-of-band reason to trust these certificates, they
can help secure TLS against man-in-the-middle attacks. However, these
certificates also suffer from the fact that they can not be revoked --
only CAs can offer CRLs or other revocation services. If the issuer
later decides that the keys are compromised, they have no way to notify
their partners that this certificate should no longer be considered valid."

This is not true. If you have some out of band way to get and trust
these certificates, you also have the same route to receive a signed
revocation message or CRL from the issuer. (The issuer is by definition
a CA :-). Even better, you can also use an in band route to receive a
signed revocation message. The only time this will not work is if the
issuer loses the signing key. But in this case a CA could not issue a
CRL. Furthermore I believe your blockchain solution also suffers from
this same problem.

Admittedly the issuer may not know who his self signed certificate has
been propagated to by the original recipients, so he cannot notify all
recipients directly, but then publishing a CRL is not a direct method of
notifying recipients. The issuer needs to notify those who he directly
gave the certificate to and rely on them to propagate the revocation
message to their colleagues. But to say 'they can not be revoked' is not
correct.

Comments?

David

On 18/09/2017 20:57, Christopher Allen wrote:
> My concern with many revocation schemes is they are trivially
> censorable. A client asks if a claim has been revoked, and the attacker
> through any one of a number of man-in-the-middle methods says "no".
> 
> So then you might say "sign the responses" but these too are trivial to
> DOS. These also can leak privacy info as Joe has pointed out. The lesson
> from TLS cert revocation lists is that if they are not highly available
> users and developers will stop requesting.
> 
> I wrote up one very easy, highly available revocation method which
> checks to see if a Bitcoin address has been spent. Between massive p2p
> replication, multiple heterogeneous service and censorship resistant
> approaches like TOR, Bitcoin Fibre, and Blockstream Satellite, it is
> easy to see if a very has been revoked even if your network is being
> censored.
> See https://github.com/ChristopherA/revocable-self-signed-tls-certificates-hack
> 
> You can implement this hack easily today. The problem with this hack is
> that it doesn't scale well long term — it pollutes the UTXO database of
> Bitcoin. I do believe however that there are some other schemes using
> merkle trees with either sidechains or payment channels that may help
> address this. 
> 
> As DIDs also use ledgers, and some special purpose ledgers like Sovrin &
> Veres are specifically written for verifiable claims, I would like DID
> method specs be able to also point to chain specific revocation
> approaches that are available to verifiable claims that use that chain
> for the DID.
> 
> -- Christopher Allen

Received on Wednesday, 20 September 2017 12:43:10 UTC