[Trans] Question about Draft 19 - Section 4.2

Ryan Sleevi <ryan-ietf@sleevi.com> Sun, 23 October 2016 21:42 UTC

Return-Path: <ryan-ietf@sleevi.com>
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id D3D581294D1 for <trans@ietfa.amsl.com>; Sun, 23 Oct 2016 14:42:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sleevi.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id jMPD76sobdGt for <trans@ietfa.amsl.com>; Sun, 23 Oct 2016 14:41:59 -0700 (PDT)
Received: from homiemail-a31.g.dreamhost.com (sub4.mail.dreamhost.com []) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE04B129411 for <trans@ietf.org>; Sun, 23 Oct 2016 14:41:59 -0700 (PDT)
Received: from homiemail-a31.g.dreamhost.com (localhost []) by homiemail-a31.g.dreamhost.com (Postfix) with ESMTP id EBF331406B0B for <trans@ietf.org>; Sun, 23 Oct 2016 14:41:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sleevi.com; h=mime-version :from:date:message-id:subject:to:cc:content-type; s=sleevi.com; bh=j90l5fK/8VPk6lMYQQKUXj00iaA=; b=JBDpjNyvJ9h1+UEOLB3MZTjX7qYg X1hwpUjZTSPjg76imFwFqeNFw7xWw2SNJmxyRZrZsOzwd6Ydov90bVTiJG6yQWvZ PP0QND+dCkH/94enOcE1tTFp/uZHM9ni27kRW71SYqXmjzJbtnxPmpvlE5alTivL ytqa1A/k8mTavTM=
Received: from mail-yw0-f171.google.com (mail-yw0-f171.google.com []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: ryan@sleevi.com) by homiemail-a31.g.dreamhost.com (Postfix) with ESMTPSA id D24F91406B0A for <trans@ietf.org>; Sun, 23 Oct 2016 14:41:58 -0700 (PDT)
Received: by mail-yw0-f171.google.com with SMTP id w3so148761006ywg.1 for <trans@ietf.org>; Sun, 23 Oct 2016 14:41:58 -0700 (PDT)
X-Gm-Message-State: ABUngvd3lnuztIKkLjViyzx/B7Te6rAvUriNS1jdEa6741ZdSbrWgxn5wsFnCWIfoz3XFeuOAkQXLNMhenqixA==
X-Received: by with SMTP id i4mr11425692ywb.83.1477258917978; Sun, 23 Oct 2016 14:41:57 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Sun, 23 Oct 2016 14:41:57 -0700 (PDT)
From: Ryan Sleevi <ryan-ietf@sleevi.com>
Date: Sun, 23 Oct 2016 14:41:57 -0700
X-Gmail-Original-Message-ID: <CAErg=HE9D+kNofUNdNEG5w86xqUZbchUB9-j_4Z4gDtv5vd8fA@mail.gmail.com>
Message-ID: <CAErg=HE9D+kNofUNdNEG5w86xqUZbchUB9-j_4Z4gDtv5vd8fA@mail.gmail.com>
To: trans@ietf.org
Content-Type: text/plain; charset=UTF-8
Archived-At: <https://mailarchive.ietf.org/arch/msg/trans/z4n6tFE5sq3s1KR79mfm1VIN8zE>
Cc: Rob Stradling <rob.stradling@comodo.com>, eranm@google.com
Subject: [Trans] Question about Draft 19 - Section 4.2
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.17
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: Sun, 23 Oct 2016 21:42:01 -0000

I'm curious to understand the interpretation of Section 4.2, and it's
presumed implications for CT clients.

At present, Section 4.2 (
)  states:

   An intermediate CA certificate or intermediate CA precertificate that
   contains the Name Constraints [RFC5280] extension MAY be logged in
   place of end-entity certificates issued by that intermediate CA, as
   long as all of the following conditions are met

As I read this, this implies that this is not an obligation upon
clients to recognize this extension, or this approach to logging. That
is, a client (such as Google Chrome) may consider rejecting such
certificates as part of its Certificate Transparency policy. At
present, this is where the thinking of Chrome is, but if it's
perceived to obligate clients to recognize such events, then I'd like
to try to see how to tweak the text to make it clearer that this is
optional - for logs and for clients.

>From discussing with some of the authors, and from those in the CA and
log operator space, it doesn't seem that there's a clear agreement
about the implication of the text, and whether or not it belongs in
https://datatracker.ietf.org/doc/draft-strad-trans-redaction/ (as a
technical means for redaction). However, if there's WG consensus that
it is merely descriptive about how such a mechanism would work (via
MAY), rather than prescriptive upon a client implementation, then
perhaps it's worth noting more explicitly as such, without
meaningfully altering the text that has passed WG consensus.