Re: [Trans] Relaxing section 5.1

Ryan Sleevi <> Wed, 02 November 2016 19:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9AA1A129872 for <>; Wed, 2 Nov 2016 12:51:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.501
X-Spam-Status: No, score=-1.501 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, RCVD_IN_SORBS_SPAM=0.5] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id D_J3uZEHZjF3 for <>; Wed, 2 Nov 2016 12:51:19 -0700 (PDT)
Received: from ( []) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E43E512986F for <>; Wed, 2 Nov 2016 12:51:19 -0700 (PDT)
Received: from (localhost []) by (Postfix) with ESMTP id 602383C000747 for <>; Wed, 2 Nov 2016 12:51:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed;; h=mime-version :in-reply-to:references:from:date:message-id:subject:to:cc :content-type;; bh=w88u6lICdOX7uB/03YkQ/hEVQdk=; b= MulExzVyV5V/C6m2oLLvuh52QcIbtdOwYRj0EDKfR91RgtqWgaSebfBLfy8pEziu s8kS5CfRU8i/LUIhQLhNyYc2ft1p9mP7A3zPH5xde2PSF0e5V7QbHWrDycHpT0WY 0gMUYVy8spIwSIKGTL00ztB3Foejsbk7UCFJeDwimmA=
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: by (Postfix) with ESMTPSA id 5359D3C000746 for <>; Wed, 2 Nov 2016 12:51:19 -0700 (PDT)
Received: by with SMTP id 128so34579744oih.0 for <>; Wed, 02 Nov 2016 12:51:19 -0700 (PDT)
X-Gm-Message-State: ABUngvfGRXASpfcs0S9Kko+0MNuTEXw+Z6cDhFGE1JLSguwDhig/vqzxy4FtEaNrDoxPW17bJXzG1GDG7cCICg==
X-Received: by with SMTP id 8mr6752631iot.33.1478116278633; Wed, 02 Nov 2016 12:51:18 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Wed, 2 Nov 2016 12:51:18 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <>
From: Ryan Sleevi <>
Date: Wed, 02 Nov 2016 12:51:18 -0700
X-Gmail-Original-Message-ID: <>
Message-ID: <>
To: Peter Bowen <>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <>
Cc: Melinda Shore <>, "" <>
Subject: Re: [Trans] Relaxing section 5.1
X-Mailman-Version: 2.1.17
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, 02 Nov 2016 19:51:20 -0000

On Wed, Nov 2, 2016 at 7:08 AM, Peter Bowen <> wrote:
> I realize that 6962bis has passed WGLC, so I know there is a high bar
> for changes.  However I think this might pass that bar.  The highly
> restrictive language that imposes minimum policy for logs prevents
> interoperability with other IETF RFCs on the standards track very
> hard.  6962bis appears to assume that DANE (RFCs 7671 and 6698) will
> never be implemented and that concepts like RFC 6091 will never come
> to fruition.

To further expand on Peter's question regarding Section 5.1, as
presently specified, it shifts a significant burden to log clients
submitted certificates that might otherwise be addressed by log

Consider a CA which it itself a trust anchor (root cert) and has a
certificate cross-signed by another trust anchor (cross-sign). One log
may directly support the root, another log may only support the CA
issuing of the cross-sign.

One interpretation of the text is that "using the chain of
intermediate CA certificates provided by the submitter" means that
only the first log can be used, and that the second log cannot perform
any path building to determine that the cross-sign exists. As such, a
client submitting certs must have full knowledge of the PKI graph,
prior to submission, to determine which logs it can use, and logs are
prevented from using their knowledge.

Another interpretation is that the chain of intermediates is merely a
'hint', and may be discarded by the log when evaluating the path. This
would at least resolve some of Peter's concerns, but not all. The core
of this is the question regarding the MUST level requirement, and
whether that language unduly restricts possible implementations in a
way that may prevent standards adoption.