Re: [Trans] Volunteer opportunity! (was Re: DNSSEC also needs CT) Tue, 27 May 2014 14:48 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id DADE71A0470 for <>; Tue, 27 May 2014 07:48:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id xkKb_DROV3Ae for <>; Tue, 27 May 2014 07:48:25 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 701B71A0445 for <>; Tue, 27 May 2014 07:47:30 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="4.98,919,1392159600"; d="png'150?scan'150,208,217,150";a="168148295"
Received: from (HELO ([]) by with ESMTP; 27 May 2014 16:32:20 +0200
Received: from ejlp023.ejgv ([]) by (Sun Java System Messaging Server 6.2-9.09 (built Jan 8 2008)) with ESMTP id <> for; Tue, 27 May 2014 16:47:25 +0200 (CEST)
Received: from (afe02 []) by ejlp023.ejgv (8.13.1/8.13.1) with ESMTP id s4RElPrP017194; Tue, 27 May 2014 16:47:25 +0200
Received: from ([]) by with Microsoft SMTPSVC(6.0.3790.4675); Tue, 27 May 2014 16:47:24 +0200
Date: Tue, 27 May 2014 16:47:23 +0200
In-reply-to: <>
Message-id: <>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft Exchange V6.5
Content-type: multipart/related; boundary="Boundary_(ID_d+wXSMpV/FUOoHz1dApj9Q)"; type="multipart/alternative"
Content-class: urn:content-classes:message
Thread-topic: [Trans] Volunteer opportunity! (was Re: DNSSEC also needs CT)
Thread-index: Ac95uI3cnUZq5SgcQhCKVW8JH8bKcAAAZOvg
X-MS-Has-Attach: yes
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
X-OriginalArrivalTime: 27 May 2014 14:47:24.0713 (UTC) FILETIME=[9294B190:01CF79BA]
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: Tue, 27 May 2014 14:48:30 -0000



I have some other questions

-          What if a CA can´t belong or it´s not accepted in any log server? 

-          What if you need 3 logs for an EV and only get 2 for whatever reasons?

-          Who´s managing that procedure to accept log servers? Google? Are they going to be registered/publicly available for CAs to choose?





Iñigo Barreira
Responsable del Área técnica




ERNE! Baliteke mezu honen zatiren bat edo mezu osoa legez babestuta egotea. Mezua badu bere hartzailea. Okerreko helbidera heldu bada (helbidea gaizki idatzi, transmisioak huts egin) eman abisu igorleari, korreo honi erantzuna. KONTUZ!
ATENCION! Este mensaje contiene informacion privilegiada o confidencial a la que solo tiene derecho a acceder el destinatario. Si usted lo recibe por error le agradeceriamos que no hiciera uso de la informacion y que se pusiese en contacto con el remitente.


De: Trans [] En nombre de Dmitry Belyavsky
Enviado el: martes, 27 de mayo de 2014 16:33
Para: Stephen Kent
Asunto: Re: [Trans] Volunteer opportunity! (was Re: DNSSEC also needs CT)


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.

2.    Any log-server can select the list of acceptable CAs. I think that “important logs” should cover all the CAs supported by major browsers.

3.    Any log server can select the algorithm of hash for Merkle Tree and for its key signing the SCTs.

4.    Each browser should provide an editable way of managing logs. By default it should be a reasonable subset of “important” logs.

5.    Each CA can be accepted by more than one log. 

6.    Browsers should

a.    allow user to accept the cert without CT providing warning about absence of CT

b.    allow user to specify absence of log for this or that domain (non-public suffix)

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

d.    there should be a procedure of report about log misbehaviour in case of invalid log records

7.    I think that warning is acceptable in case of an absence of SCTs, but in case of cryptographic errors the error should be generated.



On Thu, May 22, 2014 at 10:12 PM, Stephen Kent <> wrote:


Thanks for posting the list below.

I have become very concerned that the doc we're working on describes a mechanism,
but we seem to lack a good description of the architectural context in which CT
is supposed to work. The intro text for the I-D is not at all adequate for this.
Maybe the charter for this WG would have included the need to publish a doc of
this sort if we had gone through the usual BoF process :-).

I'd like to see a doc that addresses a number of points that are now beginning to
be raised by several folks:
    - who is expected to operate logs, does every log cover all CAs, is one
log per CA (even if operated by someone else) adequate, how are users supposed to
select logs (what the UI like?), etc.
    - how are browsers expected to deal with missing SCTs, missing or non-matching
log entries, (crypto) invalid log entries, etc. are browser actions supposed to be
effect in real time or is this deferred activity model?
    - hard fail vs. warnings for CT "exceptions?"
    - how are browsers expected to deal with certs from CAs that are not
part of the Web PKI?
    - what are the fallback plans if some number of the Web PKI CAs elect to not
    - same question for major browser vendors?
    - what are the plans for alg aglity, for logs?

CT is a system, not just a handful of mechanisms. It needs to be described that way.

Although not perfect, I suggest the set of RFCs that describe the RPKI is illustrative
of the many aspects of a global system (with PKI aspects) that need to be documented.




Here are my ideas about "strict" behaviour of the TLS client:



TLS clients supporting CT are supposed to have a preconfigured set of logs and

their public keys.


In addition to normal validation of the certificate and its chain, they should

validate the SCTs received during the TLS connection.


The client fully conforming to the specification SHOULD perform the following

steps before establishing the connection for every certificate in the chain:


1. If no SCTs are provided, the client SHOULD reject the connection.


2. The client MUST ignore all the SCTs provided by unknown logs.


3. TLS clients MUST reject SCTs whose timestamp is in the future.


4. If no SCTs has left after steps 2-3, the client SHOULD reject the connection.


5. If any of SCTs left after steps 2-3 has invalid signature, the client SHOULD reject the connection.


Client MAY check whether the certificate is present in the log corresponding to the passed SCT.

If the certificate is not present in the log, the connection MUST be rejected.



Can it be a starting point or you want something else?


SY, Dmitry Belyavsky 


Trans mailing list


Trans mailing list

SY, Dmitry Belyavsky