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 >
- [Trans] Further comments on RFC 6962 Phillip Hallam-Baker
- Re: [Trans] Further comments on RFC 6962 Rob Stradling
- Re: [Trans] Further comments on RFC 6962 Phillip Hallam-Baker
- Re: [Trans] Further comments on RFC 6962 Rob Stradling
- Re: [Trans] Further comments on RFC 6962 Ben Laurie
- Re: [Trans] Further comments on RFC 6962 Phillip Hallam-Baker
- Re: [Trans] Further comments on RFC 6962 Ben Laurie
- Re: [Trans] Further comments on RFC 6962 Eran Messeri