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

Dmitry Belyavsky <> Tue, 13 May 2014 08:42 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 2A2FE1A01C3 for <>; Tue, 13 May 2014 01:42:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id sG9R_E6Ua1qQ for <>; Tue, 13 May 2014 01:42:03 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4002:c01::22a]) by (Postfix) with ESMTP id A61FB1A0429 for <>; Tue, 13 May 2014 01:42:03 -0700 (PDT)
Received: by with SMTP id t59so12435yho.29 for <>; Tue, 13 May 2014 01:41:57 -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=X7SoQBXg+fQtdzy655UV8/mEwGTvInzemDDodggAz+Q=; b=g/aTZO6GVwD1dRMh4VBcTrMSUqcFUDEQ4j8ffF9EdXwvIRmMx+knBO3euzw0viaE9V a+2QnUSMCwLIALAFBOzj22ntQqw4rFd0YhMeitZM8+KU4kmH4GGJ+hGqdX5Mh+CM24By WW30GeaR7BmGwIKRrqFQm55UK0KqdEzuQILZvpT7tfFVmDTntkBogwdWS2t5Lv/VNBbv UUahtKsjBsp/M1NhzlBeyxvdH5fBIDG5p8Rs+im/F5IJzh/1eqhaVhLSSTU+HGuooW4G e1MRi9yW2ojfwaesibHApAW55OIVWXp6Fliz+KXVFWo77U+W9FONw0zc81+Npbijkui/ qDIw==
MIME-Version: 1.0
X-Received: by with SMTP id q5mr48851121yhb.21.1399970517356; Tue, 13 May 2014 01:41:57 -0700 (PDT)
Received: by with HTTP; Tue, 13 May 2014 01:41:57 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <>
Date: Tue, 13 May 2014 12:41:57 +0400
Message-ID: <>
From: Dmitry Belyavsky <>
To: Melinda Shore <>
Content-Type: multipart/alternative; boundary="047d7b5d83916213cc04f94409f8"
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: Tue, 13 May 2014 08:42:05 -0000

Hello Melinda,

On Tue, May 13, 2014 at 9:26 AM, Melinda Shore <>wrote:

> On 5/12/14 9:12 PM, Nico Williams wrote:
> > Incidentally, rfc6962bis could use an operational considerations
> > section covering issues such as what CAs are expected to be logged.
> We've talked about the possibility of breaking out client behavior
> into a separate document, and while that discussion focused on
> the protocol between a client and a log server it seems that
> this sort of thing may belong there, as well.
> Nobody has stepped forward to draft a document but at this point
> it would be very helpful indeed if someone could step forward and
> contribute some text.
Here are my ideas about "strict" behaviour of the TLS client:

TLS clients supporting CT are supposed to have a preconfigured set of logs
their public keys.

In addition to normal validation of the certificate and its chain, they
validate the SCTs received during the TLS connection.

The client fully conforming to the specification SHOULD perform the
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

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

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

SY, Dmitry Belyavsky