Re: [Trans] Further comments on RFC 6962

Ben Laurie <benl@google.com> Tue, 11 March 2014 15:46 UTC

Return-Path: <benl@google.com>
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CE181A0765 for <trans@ietfa.amsl.com>; Tue, 11 Mar 2014 08:46:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.926
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Md2jhOYnLOD for <trans@ietfa.amsl.com>; Tue, 11 Mar 2014 08:46:35 -0700 (PDT)
Received: from mail-ve0-x22d.google.com (mail-ve0-x22d.google.com [IPv6:2607:f8b0:400c:c01::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 853251A0471 for <trans@ietf.org>; Tue, 11 Mar 2014 08:46:35 -0700 (PDT)
Received: by mail-ve0-f173.google.com with SMTP id oy12so8887723veb.32 for <trans@ietf.org>; Tue, 11 Mar 2014 08:46:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=MF+Juo0s99EHt95xLZ0NUOs5Ltu9SlCBcDUxgTZ3+yY=; b=Kni5jYjXk5ARdfZA4v4+icpBU4VfNA4+dtOQ9RjWHVrVYsAZrVd77rrBoF20AVtWl0 PSUR3DwiKiOz7eiLlXDuOAmaPGuWIRWyIoqoQSPP0p5UFHNZ+JzA+gPVNcjSEAa4vXjT xi1757WL33lpzn+PwL8twaai8q6pSoa3ND1Brav4HuvhHnYfk/xD9JcLPe1K5cgSsB+H kOu+jfi0ysh8Q0eQDnb8uoNy/X3eLfo+0+emExUiQx8sKDOKPaM7RmP7Zmgg7MG47heW uR+Pn3tnyTfCojiBazILIWqILumC2Hrq08CXQDUnIyHAoCQlCMN3XNw0tITG/G2kOuS3 uznA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=MF+Juo0s99EHt95xLZ0NUOs5Ltu9SlCBcDUxgTZ3+yY=; b=KMy/0tGC+ICcKqHMmOjtQ71qf8nf8e22UT/UgEEdtfdZtGZm9xGwdp/vFmVRb6iCDf /XA+PLRQzsvzGltPDZKO6u/Q77VJGG2wbffaxzpx7h8I9b6ib4UPh6vBFRGwhr3n6a8T 9EmCrk02C02130BcGZBY4xBtK2kL+ZODO43UoO+jAEZviYr6B7eNEHngeqoazROtPRxi GEcNrrQzbUag9R9m5muW0Ph34ygZ0JD5VCq0kIIkRA7sA3pSOLCDX+4kY9bPocScgKTp lSJo3vYXS1xp/6udJOF0JgGpqX/ob0Uc72/jHs2I9aAPGRFZNlplM1KCVs2JUaIuKGEU 41uQ==
X-Gm-Message-State: ALoCoQnflAIzINoICUjXLLi2Lb29sqgvxW2Q3IpFhZWiW7OHjgoiUphA9cOWi1SMBUR4OCd7IFz9sIfV5xgu5gXmMltSONtOqjl6gyyN9FE5BcI/u2jPTI7PFjnqK/xjXKFgn/GS+bHeJI3uCxn0plJpyd4C+4LMltEf723pU9UvBwIO5I2ZSFCdWcMQb9uCBoDMg3Z5oHIE
MIME-Version: 1.0
X-Received: by 10.52.63.233 with SMTP id j9mr71235vds.69.1394552789555; Tue, 11 Mar 2014 08:46:29 -0700 (PDT)
Received: by 10.52.230.105 with HTTP; Tue, 11 Mar 2014 08:46:29 -0700 (PDT)
In-Reply-To: <CAMm+LwhpCD9gf_XJUTsKBo3739jOeiHdedqWwi3b0jkeZkSo8w@mail.gmail.com>
References: <CAMm+LwhpCD9gf_XJUTsKBo3739jOeiHdedqWwi3b0jkeZkSo8w@mail.gmail.com>
Date: Tue, 11 Mar 2014 15:46:29 +0000
Message-ID: <CABrd9SQim3ev=2rsCDXSF5fWqv3+cKf9j-88pQ+4NAaBV9w2PA@mail.gmail.com>
From: Ben Laurie <benl@google.com>
To: Phillip Hallam-Baker <hallam@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/qrxLhD_zLqDyTR8rJsg1voT01Io
Cc: "trans@ietf.org" <trans@ietf.org>
Subject: Re: [Trans] Further comments on RFC 6962
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Public Notary Transparency working group discussion list <trans.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/trans>, <mailto:trans-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/trans/>
List-Post: <mailto:trans@ietf.org>
List-Help: <mailto:trans-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/trans>, <mailto:trans-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 11 Mar 2014 15:46:41 -0000

Since a 6962-bis already exists
(https://datatracker.ietf.org/doc/draft-ietf-trans-rfc6962-bis/) it
would be better to comment on that. But I think all these comments
apply anyway.

On 10 March 2014 20:58, Phillip Hallam-Baker <hallam@gmail.com> wrote:
> Following on from my last one that went out early...
>
>
> 2) The transactions add-chain and add-pre-chain only differ in the type of
> the data being exchanged. It would be more general to change the signature
> of the request message so that it had an explicit 'data type'
>
> 3) Shouldn't it be possible for a service to manage multiple logs? I would
> think this particularly important in the case of a retrieve-only log which
> is serving multiple logs. But the same point can be made about the add
> operation.
>
> 4) sha256_root_hash.
>
> Really? This should be an object that has an algorithm/data pair. Encoding
> the algorithm into the tag is going to make algorithm agility hard.

I agree about the name. Not sure I agree about agility. We don't think
a log can change algorithm partway through - at least, we don't think
we want to specify how.

If you want a new algorithm, you start a new log.

> 5) 'in decimal'
>
> This phrase crops up repeatedly and I don't think it means what is intended.
> All JSON integers are encoded in base 10. Using the term 'in decimal' is
> confusing as it is distinct from 'as a decimal'
>
> Integer    42       // An integer value in base ten
> Decimal   3.14    // A decimal fraction

Fair enough, since we refer to JSON, we could just not say anything
about number encodings - presumably we should instead say "integer".

> 6) The tree_size of the first tree, in decimal.
>
> In this context, tree_length would probably be easier to see the context.
>
> 7) https://<log server>/ct/v1/get-sth-consistency does not specify if the
> first and second tree_size identifiers are ordered or not.
>
> It is likely to result in problems if servers assume first > second or first
> < second. Either an order should be specified or there should be an explicit
> statement that it does not matter.

OK.

> 8) 0-based index
>
> Not clear to me from the reference section if this is a byte count or an
> object count. It should not be necessary to hunt through the spec to find
> out which.

I don't see how a byte count could make any sense, but OK.

>
>
>
>
>
>
> --
> Website: http://hallambaker.com/
>
> _______________________________________________
> Trans mailing list
> Trans@ietf.org
> https://www.ietf.org/mailman/listinfo/trans
>