Re: [Trans] IETF 90 scheduling

Jean-Michel Combes <> Wed, 23 April 2014 14:51 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id E83B61A03D6 for <>; Wed, 23 Apr 2014 07:51:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Status: No, score=-1.998 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, 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 KqxQJmjSSiKh for <>; Wed, 23 Apr 2014 07:51:14 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c05::22f]) by (Postfix) with ESMTP id B23A81A0096 for <>; Wed, 23 Apr 2014 07:51:13 -0700 (PDT)
Received: by with SMTP id cc10so5037757wib.8 for <>; Wed, 23 Apr 2014 07:51:07 -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=psvuPfyLvyCkXD+1JZeie5YNbNVPZ9lBO7et4IcXOO4=; b=Kjk8Ex8g9xRccul50RThyXew6vASsRDQlv+mUxVRaIMY0bvRum4xaFZwRvta3rXVZ8 dgNaA1vvYHlvBdZvEyQIx0Or6WfXV1tVSPBu/ACcDi2SD48KbqaEu1aCrqq9HmtmoAV1 le26KFueYTxHXfgNqBH9mA8scFcc5ou0cE/opAPwF+hf80X/IUwIVKfcjm9I6DVZbgfw 5puV7CSpV1KzNjH3a1EvlKPOqrJJdf2ieJEdckUH/JbqFhSt7uqhlSe/VVyCtbOrNdOG M6zj5G2Ws/eyDgTCXLVrLGfvbNpIr4e6vapIYsZgUQOyUObrbYRWwzd0XV39re8wy6S1 dXOg==
MIME-Version: 1.0
X-Received: by with SMTP id gm4mr2113532wib.39.1398264667585; Wed, 23 Apr 2014 07:51:07 -0700 (PDT)
Received: by with HTTP; Wed, 23 Apr 2014 07:51:07 -0700 (PDT)
In-Reply-To: <>
References: <>
Date: Wed, 23 Apr 2014 16:51:07 +0200
Message-ID: <>
From: Jean-Michel Combes <>
To: Melinda Shore <>
Content-Type: multipart/alternative; boundary="f46d044280ead0425604f7b6dc67"
Cc: "" <>
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: Wed, 23 Apr 2014 14:51:17 -0000


I have actually two technical comments with the current specifications of

#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

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.

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

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

I would appreciate any feedback from the WG regarding these comments.

Thanks in advance for your replies.

Best regards,


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