[Trans] Extensibility and algorithm agility

[Phillip Hallam-Baker <[e-mail]>]

One of the areas that we have to address to go to proposed standard is
algorithm agility. Another area we can skip but probably should not is
strategy for extensibility so as to be able to apply TRANS to other areas.

On algorithm agility we have to consider questions like:

* Using algorithms other than SHA-2-256 for the tree.
* How does a client discover which algorithm is being used.
* What sort of algorithm substitution attacks become possible.

* How does a client make a selection where a choice of signing algorithm is
offered for the SCT heads?

Questions we don't have to answer but should probably consider include:

* How would alternative log topologies be identified, for example skip
lists?
* Do we want to permit the size of the tree to be bounded by periodically
rolling to a new log? If so we probably want to have a mechanism for
incorporating the old log as the stating point of the new.


Extensibility is an area where we can and quite probably should punt. But
we do need to describe a punting strategy.

The TLS data encoding used in TRANS is a placed based encoding that can
only be decoded by reference to the corresponding schema. That makes it
very hard to use it in an application where extensibility is being used.
The extensions end up being encoded in opaque extension blobs. This is one
of the many parts of ASN.1 that don't work either and is one of the reasons
that JSON has become much more interesting. JSON is after all simply RFC822
headers with braces added to allow recursive structures to be represented...


When I started looking at this, I had thought that the TRANS data
structures are fixed because any changes would be reflected deep in the
Merkle tree. However looking at the situation again, it seems to me that
just as a tree head could be signed with a different algorithm, a different
encoding for the SCT data structure could be communicated in the same way.


Another, rather more minor issue is version numbering. At the moment there
is (or appears to be) one version number for the SCT structures and the
protocol. But there is no reason why these should be linked or even that
every data structure should need to be changed if there is a rev. When we
talk about X.509v3 we are actually talking about v2 of the CRL structure.

This matters because the v1 protocol does not have a mechanism for
specifying what the version of the data structure being requested is.

-- 
Website: http://hallambaker.com/