Re: [Trans] IETF 90 scheduling

Ben Laurie <> Thu, 24 April 2014 14:52 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 6D4DB1A033E for <>; Thu, 24 Apr 2014 07:52:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.649
X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 6cbpD7wnA91b for <>; Thu, 24 Apr 2014 07:52:05 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400c:c03::22d]) by (Postfix) with ESMTP id 9E10A1A032E for <>; Thu, 24 Apr 2014 07:52:05 -0700 (PDT)
Received: by with SMTP id il7so3125267vcb.32 for <>; Thu, 24 Apr 2014 07:51:59 -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=1Vtu4/rggeziTMbhnXZHB8fZACVVG531Gdcbs4Ea+ao=; b=Rusjyn56h979yMbnID2UkhTdfuHZ/uA+tNZD9MnqDLQl2JTGljN3IB8LQjPb0/rWe/ WMKN8BhivVftN+4wm2RQ8foCv6cZwnRlVjHV3evVuajefb18ng8ws8ZRyoRqrCWqySRl c1fnNW5CP6EchVOZyafgDfZR4JpsE8ommfefNVJWd/x2FZkS4lrXSIa1o0UjlG3yh9O4 rMDRyaUy+FUtCENttYYHOClOcgO5MyfZl2XvQ0HCGYZ8RQ0s7duipv73yWcRDecl0FVg Dj2D8238Lce8MsX7u60PKinyyQ9BHM4cDXy1rj8GjmVqINC274RqjrLFCRUdzqhFgrM7 OgjA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=1Vtu4/rggeziTMbhnXZHB8fZACVVG531Gdcbs4Ea+ao=; b=kv5JWPVORns6Z5wMl8wrf/1SzdEA+9ewiW1C/3VXawhsdjbHfNNPSf5SMImuOoRcc6 HWBbmSGPYs6FxqjotTDvCIk9iXRRaIuXu/H8r5VqaVXEzncwGiT74BaKqWG30pj0YGDl A17CM0zoPxsN9kcsVCM89zk75Hc1dUldXEtw6wy597dzNMWK6v9jqmfhlEgWh2FxbCgS LztVZvLi/GT2ekID9uTUBiU4NMqeN6Ieu2DZKCySj59J4OdSlBikAE4g5h+FQQ22gidg plKIGVzsWwy3eN+dNHgUO8bxWq8vuIVpMi2I1drnPlXok0xRA1u9ot0a9lhtGgVs0DhJ BAIw==
X-Gm-Message-State: ALoCoQnelzaglmxNb9fLBCMIB2P/CxZQnyEGLcHehSEbSeg08StTiksgfgC4R7I2G+/HT3A5EmmvBzXyY4xt1Sa8Zhmp1V37raiizAwnom7tcg5an19b4vECtkc/2GLOzwH4NL267k7a9Ss7FF/hhOHPpi0+8xHy8eig/4+NVxJQIby/eqFhf1PPDmYUrOeKFL9gjXS4Nj2x
MIME-Version: 1.0
X-Received: by with SMTP id ox4mr666133veb.54.1398351119292; Thu, 24 Apr 2014 07:51:59 -0700 (PDT)
Received: by with HTTP; Thu, 24 Apr 2014 07:51:59 -0700 (PDT)
In-Reply-To: <>
References: <> <>
Date: Thu, 24 Apr 2014 15:51:59 +0100
Message-ID: <>
From: Ben Laurie <>
To: Jean-Michel Combes <>
Content-Type: multipart/alternative; boundary="047d7b6da0eabcbc7d04f7cafd3c"
Cc: Melinda Shore <>, "" <>
Subject: Re: [Trans] IETF 90 scheduling
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: Thu, 24 Apr 2014 14:52:07 -0000

On 23 April 2014 15:51, Jean-Michel Combes <>wrote:

> Hi,
> I have actually two technical comments with the current specifications of
> CT:
> #1 Log server identification
> Currently, if I am correct, the identity of the log server providing the
> SCT is based on its public key (in fact, the hash of it), which is also
> stored in the TLS client. As with the public key pinning mechanism (cf.
> draft-ietf-websec-key-pinning), I am afraid about a potential complexity
> (from a technical/business point of view) to add a new public key in the
> TLS client (e.g., web browser), to be able to set up/manage a new log
> server.
> So, I am wondering, instead (or in parallel) of using log server's public
> key as log server's ID, if that would be easier to use URI for new log
> servers deployment.

There's already been a fairly extensive discussion on this, perhaps still
not resolved. But my position continues to be that the TLS client needs to
know various things about the log - public key, URL, MMD. I don't see the
problem in those things being communicated in a data structure (e.g. in

Indeed we will shortly be defining such a structure for Chrome's valid
logs. Whether this should form part of the RFC is up to the WG.

> #2 Interaction between TLSA RR and CT
> At first, from my point of view, using TLSA RR means "prevention" and
> using CT means "repression". Now, if I want only do "prevention", the
> current CT specifications will not allow me to do it. Indeed, as specified
> in Section 3, TLS clients MUST reject certificates that do not have a valid
> SCT for the end-entity certificate, enforcing the use of CT by the TLS
> server.

That is correct.

> Maybe, replacing the MUST by a SHOULD, when TLSA RR is deployed, would
> relax this enforcement.

No, because this gives an attacker a way to evade CT.

I would appreciate any feedback from the WG regarding these comments.
> Thanks in advance for your replies.
> Best regards,
> JMC.
> 2014-04-22 0:35 GMT+02:00 Melinda Shore <>:
> We just received notification that working group session
>> scheduling for the July meeting is now open.  This is a good
>> time to be thinking about what needs to be done between
>> now and then and how session time will be spent.  Right now
>> my sense is that a single two-hour session will be more than
>> enough, but I'll hold off until we get a better sense of
>> what will need to be done during the session.
>> Melinda
>> _______________________________________________
>> Trans mailing list
> _______________________________________________
> Trans mailing list

Certificate Transparency is hiring! Let me know if you're interested.