Re: [Trans] Volunteer opportunity! (was Re: DNSSEC also needs CT)

Stephen Kent <> Mon, 16 June 2014 19:08 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id C310D1A0177 for <>; Mon, 16 Jun 2014 12:08:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.851
X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id CJK-NonXdmBG for <>; Mon, 16 Jun 2014 12:07:58 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 98AE11A0199 for <>; Mon, 16 Jun 2014 12:07:58 -0700 (PDT)
Received: from ([]:51266 helo=comsec.home) by with esmtp (Exim 4.77 (FreeBSD)) (envelope-from <>) id 1WwcGG-000DPV-Uu; Mon, 16 Jun 2014 15:08:09 -0400
Message-ID: <>
Date: Mon, 16 Jun 2014 15:07:55 -0400
From: Stephen Kent <>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Dmitry Belyavsky <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------060207010603050706050803"
Cc: "" <>
Subject: Re: [Trans] Volunteer opportunity! (was Re: DNSSEC also needs CT)
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: Mon, 16 Jun 2014 19:08:01 -0000


My replies are inline. sorry that my mail program renumbered each of 
your bullets as I inserted my replies :-(.

> Hello Stephen,
> Here is my understanding of the question you asked.
> Let Ben or Rob fix me if I'm wrong.
> 1.
>     Anybody is allowed to operate log. But there should be a procedure
>     (similar to CA/Browser forum) which is determined to register log
>     as "important" (we need a better word). There should be not many
>     "important" log servers, I suppose --- otherwise we are to get the
>     same problem as we have with many CAs.
As you note, the notion of establishing some logs as "important" would 
borrow from the
CABF, but we're the IETF and this is intended to be an IETF standard. 
So, I think this
doc needs to address this issue in a fashion consistent with IETF 
> 1.
>     Any log-server can select the list of acceptable CAs. I think that
>     "important logs" should cover all the CAs supported by major browsers.
The doc suggests this, but again, this has a CABF feel to it. IETF 
standards do not endorse
implementations and use decisions by vendors to drive standards.
> 1.
>     Any log server can select the algorithm of hash for Merkle Tree
>     and for its key signing the SCTs.
That's not what the doc says; it establishes two MTI algs that all 
clients must support, while log operators are allowed to pick form 
between the two. This seems a bit backwards to me, in that it imposes 
the greater burden on the larger # of implementations.
> 1.
>     Each browser should provide an editable way of managing logs. By
>     default it should be a reasonable subset of "important" logs.
The set of "important" logs might not include a CA that is important for 
a set of clients 9since log operators have complete discretion as to 
which CAs they accept) so it ought to be possible for a client to 
include a pointer to logs outside the default set.
> 1.
>     Each CA can be accepted by more than one log.
"Might be" is the more accurate characterization, based on the current 
doc. There is no requirement that any log operator accept submissions 
from a specific CA. Each log operator indicates what CAs/TAs it supports.
> 1.
>     Browsers should
>     1.
>         allow user to accept the cert without CT providing warning
>         about absence of CT
>     2.
>         allow user to specify absence of log for this or that domain
>         (non-public suffix)
>     3.
>         allow user to a particular log for this or that domain and
>         return an error if there is no SCT for id provided by this log.
>     4.
>         there should be a procedure of report about log misbehaviour
>         in case of invalid log records
These seem like reasonable suggestions, at least to begin, but none of 
them appear in the doc.
I worry that, absent a description of minimum browser management 
interfaces for CT, we have no sense of whether users will be able to 
deal with incremental deployment.
> 1.
>     I think that warning is acceptable in case of an absence of SCTs,
>     but in case of cryptographic errors the error should be generated.
I presume you mean that if there is a crypto error, the cert should be 
rejected, a hard fail, right?