Re: [Trans] [trans] #76 (rfc6962-bis): Normative client behavior specified in Section 3.4

Stephen Kent <> Tue, 10 November 2015 15:56 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id BD3A51B39B8 for <>; Tue, 10 Nov 2015 07:56:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id EH5xtreeHg0l for <>; Tue, 10 Nov 2015 07:56:15 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9920A1B39B4 for <>; Tue, 10 Nov 2015 07:56:14 -0800 (PST)
Received: from ([]:47913 helo=COMSEC.fios-router.home) by with esmtp (Exim 4.77 (FreeBSD)) (envelope-from <>) id 1ZwBHI-0001TB-H5 for; Tue, 10 Nov 2015 10:56:13 -0500
From: Stephen Kent <>
References: <> <>
Message-ID: <>
Date: Tue, 10 Nov 2015 10:56:12 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------040904070900050000040801"
Archived-At: <>
Subject: Re: [Trans] [trans] #76 (rfc6962-bis): Normative client behavior specified in Section 3.4
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, 10 Nov 2015 15:56:19 -0000


> #76: Normative client behavior specified in Section 3.4
> Changes (
>   *  =>
>   * status:  reopened => new
> Comment:
>   Propose this ticket be closed (fixed) as we've added the following text
>   (section 9.2):
>   "However, specifying the TLS clients' behavior once compliance or non-
>   compliance has been determined (for example, whether a certificate should
>   be rejected due to the lack of valid SCTs) is outside the scope of this
>   document."
I think the wording here is still imprecise. For example, the text in 9.2
says "TLS clientsMUST reject SCTs whose timestamp is in the future." But
this, combined with the text above, does not say that a TLS client SHOULD
treat a cert as invalid is it contains (or is associated with) an SCT that
is "rejected." Is this ambiguity intentional?  Also, the term 
"compliance" seems
needlessly vague here.

My colleagues plan to post a proposed client requirements spec (focusing on
browsers and browser vendors) later this week. It tries to be more explicit
about this and other client behaviors (required and optional).
>   I also think that the text on SCT validity is quite clear:
>   "TLS clients SHOULD validate each SCT by computing the signature input
>   from the SCT data as well as the certificate and verifying the signature,
>   using the corresponding log's public key."
>   So not sure what can be added, unless Steve Kent points to the problematic
>   wording in draft 10.
The following problematic comments re client behavior (wrt SCTs) appear 
in -10

    The intent is that eventually clients would refuse to honor

certificates that do not appear in a log, effectively forcing CAs to

add all issued certificates to the logs.

    TLS clients can thus requirethat all

certificates they accept as valid are accompanied by signed


Sincecertificates may not be accepted by TLS clients unless logged ...

    In addition, if TLS clients will not accept unlogged certificates ...

    certificates that have not been publicly logged, and thus

do not have a valid SCT, are not considered compliant (so TLS clients

may decide, for example, to reject them).


These statements do not literally mandate client behavior, but they

expressing intent which could easily be interpreted as client behavior