On Fri, Mar 23, 2018 at 4:40 PM, Daniel Kahn Gillmor <[email protected]> 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.
_______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
