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/
_______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
