Re: [Trans] Putting illegal stuff in an append only ledger

[Ryan Sleevi <[e-mail]>]

On Fri, Mar 23, 2018 at 4:40 PM, Daniel Kahn Gillmor <[e-mail]>
wrote:

> On Wed 2018-03-21 18:22:57 -0400, Tao Effect wrote:
> > This is specific to Bitcoin and Bitcoin-like datastructures which
> > simply do not allocate enough room for arbitrary data.
>
> Thanks for clarifying this!  If i understand correctly, your argument
> appears to depend on all three of the following assertions:
>
>  a) the chunks of arbitrary data that can be injected in the
>     datastructure in question are smaller than some specific size (let's
>     call it X bytes).
>
>  b) there is no standard mechanism used for the datastructure in
>     question that aggregates multiple pieces of arbitrarily-injected
>     data into any larger structure.
>
>  c) there is no toxic data that is X bytes or smaller.
>
> is that right?  I don't know the Bitcoin protocol that well.  What is
> the value of X for the Bitcoin blockchain?
>
> Is (a) some sort of general principle that we should try to include in
> designs of any append-only globally-distributed datastructures?
>
> how do we ensure that (b) remains the case?  how do we verify that (c)
> is true in the jurisdictions that we care about?


Note that for Certificate Transparency, neither (a) or (b) necessarily
holds true if we accept arbitrary certificate profiles. For example, the
use of the LogoType extension could allow for such direct encoding in full.

In this regard, there is an operational concern that merely states that CAs
should not do this, and logs are reliant on sanctions against CAs that do
this. For an ecosystem of publicly trusted CAs, the non-technical
considerations - such as risk of distrust, or the existence of the Baseline
Requirements - serve to curtail most forms of abuse, by restricting through
policy or practice what a CA normatively should encode within a certificate.

However, there are exceptions to this. For example, the existence of a
technically-constrained sub-CA is generally a signal of an operational
hand-off - akin to a DNS zone-split - in which key material is no longer
held by the party whose existence is vested in the root key material, but
instead handed off to some third-party. A hostile technically constrained
sub-CA could thus encode arbitrary data within certificates they issue, and
from that, cause sanction to be visited upon the root. Here, again, we have
non-technical forces of sanction - such as contracts between the two
parties - to discourage the use.

In practice, one would expect that should such content be logged, one
possible remedy is for the log to shut down. From an operational
standpoint, clients are being built with a notion of log agility being a
routine practice, although the target seems to be based on annual
refreshes, it does seem possible to account for exceptional situations.
Based on the above considerations, it seems that at a policy level, we have
a number of options already available, and, in an absolute 'worst-case'
doomsday scenario, logs become gatekeepers for certificate profiles (only
accepting conforming certificates), while serving as transparent
attestations of the validated information - rather than their function
today, serving as attestations both of certificate profiles and validated
information.