Re: [Trans] [ct-policy] Re: Certificate Transparency Newsletter - August 2015

Tom Ritter <tom@ritter.vg> Mon, 19 October 2015 16:29 UTC

Return-Path: <tom@ritter.vg>
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EFB81A8996 for <trans@ietfa.amsl.com>; Mon, 19 Oct 2015 09:29:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.379
X-Spam-Level:
X-Spam-Status: No, score=-3.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, GB_I_LETTER=-2, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fo1YKukexsyH for <trans@ietfa.amsl.com>; Mon, 19 Oct 2015 09:29:55 -0700 (PDT)
Received: from mail-qg0-x229.google.com (mail-qg0-x229.google.com [IPv6:2607:f8b0:400d:c04::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 743A41A8853 for <trans@ietf.org>; Mon, 19 Oct 2015 09:29:55 -0700 (PDT)
Received: by qgad10 with SMTP id d10so68872918qga.3 for <trans@ietf.org>; Mon, 19 Oct 2015 09:29:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ritter.vg; s=vg; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=pgRxpUHrRVXFUU2RzXgBfUdvrhP6yByPc5ldWxHsjS4=; b=Yz5ytOn0afBy/65DeFRnashrdc+7f088NBsdefOv8MJwl0v25m2Ihr2MslRTXt8gvl jioF6pd2Y6P/HdCQDJq42k78JLXcu76gjzmKcbki3kxEQ40eJRzvrkrc7ojSNpamqTlw O3/Lox1BiH2AsgNHzKW7jZaYAwgvNkcflYJzI=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=pgRxpUHrRVXFUU2RzXgBfUdvrhP6yByPc5ldWxHsjS4=; b=VTMCRZIs+CWCm8vIV5mAEQff5SLrYasBnfnVZLsc3amGJcWzeXWvrNKtFR2pkJph3Z 5Pg+B8jrR0dr8ahLrTJfWexs/ocKAKoMNVYeIktdbzcMYUz9nZAiBPQPZqd2nc+AeLAD jARAScNJ0wCJ+/3RxsjdnDg6ZGT5AqrJLv4wxtY0cM2jGjerW8m0AOcpGAtPGym/I+aW gqkpqo+cT/vMzqX/dv5C6VuCCr1Yn/5XM4L7K1fIGJ0SGGH1ojCMkkijajbryMOecLfA V4HPDWoav5aW1X6Jwx2OQ4A9jCExqFBu6op3Q2q2LZomOnyLaC09UZbfgIkDCudw89b+ 2vUg==
X-Gm-Message-State: ALoCoQnKFEqafJv2OVzqFM0VI0LAbRSdtp+f2+q8ULsq9EQbKCYgVO2sqy6q+74n1peIXKUwoVma
X-Received: by 10.140.100.240 with SMTP id s103mr35928415qge.25.1445272194592; Mon, 19 Oct 2015 09:29:54 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.140.94.6 with HTTP; Mon, 19 Oct 2015 09:29:35 -0700 (PDT)
In-Reply-To: <5624F8C3.8020301@comodo.com>
References: <CAP9QY5YXp2x5PGwfAQQJy2wRz4N9TFWh4X2M3rRrHzF4B+0S+g@mail.gmail.com> <5624D492.8040400@comodo.com> <CA+cU71k073s2EL2bW72DkmjipKF8wsYH-=RrZa_xmVQcvTPt_g@mail.gmail.com> <5624F8C3.8020301@comodo.com>
From: Tom Ritter <tom@ritter.vg>
Date: Mon, 19 Oct 2015 11:29:35 -0500
Message-ID: <CA+cU71nLayCxRsrfMsnKTaP+tsNtkEwHaUCTD9EaRrW=wo87Fw@mail.gmail.com>
To: certificate-transparency <certificate-transparency@googlegroups.com>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <http://mailarchive.ietf.org/arch/msg/trans/XfjpIxvDRsGvFaQ3l94YmCsB__E>
Cc: "ct-policy@chromium.org" <ct-policy@chromium.org>, "trans@ietf.org" <trans@ietf.org>
Subject: Re: [Trans] [ct-policy] Re: Certificate Transparency Newsletter - August 2015
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Public Notary Transparency working group discussion list <trans.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/trans>, <mailto:trans-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/trans/>
List-Post: <mailto:trans@ietf.org>
List-Help: <mailto:trans-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/trans>, <mailto:trans-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 19 Oct 2015 16:29:57 -0000

On 19 October 2015 at 09:05, Rob Stradling <rob.stradling@comodo.com> wrote:
> Perhaps 6962-bis should prohibit or recommend against using TLS Feature for
> the CT TLS extension then.  Or...
>
> Actually, I can't find any explicit requirement in RFC7633 that says words
> to the effect of "The TLS server MUST send TLS extension X".  The actual
> requirements are expressed more vaguely than that.  e.g.
>   "A server offering an end-entity certificate with a TLS feature
>    extension MUST satisfy a client request for the specified feature"
>   "If these features are requested by the client in its ClientHello
>    message, then the server MUST return a ServerHello message that
>    satisfies this request."
>
> So, perhaps 6962-bis could specify that, if a TLS client sends the CT TLS
> extension and the TLS server's cert contains the TLS Feature cert extension
> with the CT TLS extension identifier, then the TLS server MUST "satisfy the
> request" by sending SCTs via any of the three supported mechanisms (CT TLS
> extension, cert extension, stapled OCSP response extension).

So... you could. But it wouldn't solve the generic problem of letting
a site owner dictate that CT should always be enabled for their
domain.  The reason I'm critical of 7633 is that it only applies to a
single certificate[0].  If I want to 'enforce' CT for a single
certificate, via a x509 extension... I could just put the CT x509
extension in the certificate.

I'm opposed to the idea of a x509 extension seen on one certificate,
once, applying a policy for the entire domain. For one thing it's
weird, and for another thing it has no way to indicate how long the
policy should apply for. (And it couldn't work for wildcard certs.)

[0] Now technically where 7633 really comes into play and is very
useful is when it's included in intermediates or (my pounding heart be
still) - root certs.  In *that* case it would work great for requiring
CT... but not for site owners, for certificate authorities.  A CA is
assured that all the certs it issues will be publicly logged, and it
can use this as a check against misissuance.  I think that's great...
but it still doesn't help site owners. =)

-tom