Re: [Trans] Extensibility and algorithm agility

Ben Laurie <> Thu, 13 March 2014 18:08 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id E59431A0A53 for <>; Thu, 13 Mar 2014 11:08:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.926
X-Spam-Status: No, score=-1.926 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id snPBNmRYDJzk for <>; Thu, 13 Mar 2014 11:08:29 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400c:c01::22d]) by (Postfix) with ESMTP id 280E61A0969 for <>; Thu, 13 Mar 2014 11:08:29 -0700 (PDT)
Received: by with SMTP id oy12so1530656veb.32 for <>; Thu, 13 Mar 2014 11:08:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=A7x9ZgftCPmRF/K9AZOg8K/PNSepulOpdNs3cqrdxGQ=; b=m+Mwxdr/e5ghYhrCa7Pzx3lu2Sb+WTrUgLhcmh35mhx3WccrnWhQabgkPck0LOc9mn 1PvpxmKkMG1jCcqpXjRYvEn4fndVZ++sHdvzWdaxzfhCoGuoyCcKgLEhO9v8ZYdw3pH3 bSn8F523O85BG/YzVGtC6ZbgVCy24QWTl6ZMEL/Z1ZRmEgDwpBMckbflogK6mHNDyB1I 9p2kam+woTxt8qs2OgeQ4rr5jAijZBd3GDQJOpq/KvoyyZMbmDJun2XM60QU0gp+UdBh WoqgjH2313n1YptmSnfWC/verVp6lHXvztnTSTTlk7wmBzfOzVw1RNNsPiWEiaMWeFVA E7yw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=A7x9ZgftCPmRF/K9AZOg8K/PNSepulOpdNs3cqrdxGQ=; b=jp0f3s/X7Rt7S/cNp/H5ZAViSq7a1udCWfFKreLd7ijvisLvLRgMMUFU3g/esw0+NA mwCKlKxybMSvx2oBjwRA+MfeqAoqoHsAs8z/r2kzuXXoKtQYZkslbvtxstXv7taxusSZ 7bd3bsoRHd982rc8KnP1Z306qCkHhyp9I4IUSZSynZI1RhoJ8W/MEN+0XJPqGTmqGuf6 m74VVEdx7iwN4Jki3ALVvmov3UXn3tmqZ6TuDK2lfqd00zW5fJ3HLbrwba6uAjWA5MNP 3z1ZDpr9ZckPoNPZ/AQfVNT4yQHCMZyZZQ0/aD1Jk2cRZjDpVy/CIH77Q65xmJ0EI28c 338A==
X-Gm-Message-State: ALoCoQng4UQYmyyN2BlhCAjqdPjF/KbmN6iTOCvgz7P6Gh8H8kMfUvtodufBIxEt6PXgNmpYDNz70X3y+nLWox7MRIaWYHEUhJyQ9gNM/32RVH3vOfYUbjxfEkoPzYBr9rBwtSJJgAPCmVsMdtZ7ZkiZiFVg/eIOnVAUC8l48e7Ro6Mn8GrA7Z/g4VJoqwujH9CS1MvdyT6d
MIME-Version: 1.0
X-Received: by with SMTP id rz4mr2606564vcb.8.1394734102465; Thu, 13 Mar 2014 11:08:22 -0700 (PDT)
Received: by with HTTP; Thu, 13 Mar 2014 11:08:22 -0700 (PDT)
In-Reply-To: <>
References: <>
Date: Thu, 13 Mar 2014 18:08:22 +0000
Message-ID: <>
From: Ben Laurie <>
To: Phillip Hallam-Baker <>
Content-Type: text/plain; charset="UTF-8"
Cc: "" <>
Subject: Re: [Trans] Extensibility and algorithm agility
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Public Notary Transparency working group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 13 Mar 2014 18:08:31 -0000

On 12 March 2014 12:57, Phillip Hallam-Baker <> wrote:
> 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?

Because SCTs can be embedded in certificates, there's no hope of being
agile. All certs would have to be re-issued and the re-issued certs
would have to be deployed. Realistically, this is not going to happen.

Thus, you change algorithms by creating new logs with different metadata.

> Questions we don't have to answer but should probably consider include:
> * How would alternative log topologies be identified, for example skip
> lists?

See above.

> * 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.

This one may be worth addressing. But again, it can also be addressed
by simply starting a new log.

> 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.

I agree that different encodings are possible, and somewhat
straightforward, but there are a bunch of other moving parts - for
example, should you have SCTs or just go straight to
proof-of-inclusion. What about including proof-of-STH-linkage. And so

None of these are possible with TLS certs for various reasons, but
clearly are for other scenarios, particularly where there is no

> 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.

Yes it does: its in the URL. But I agree that the STH and the leaves
should have separate versions. I thought there was a ticket for this