Re: [Trans] Relaxing section 5.1

Peter Bowen <> Wed, 02 November 2016 14:09 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 66CA5129491 for <>; Wed, 2 Nov 2016 07:09:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id nnWPLZrx-0UR for <>; Wed, 2 Nov 2016 07:09:39 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c0b::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5AC4212945E for <>; Wed, 2 Nov 2016 07:09:39 -0700 (PDT)
Received: by with SMTP id e187so83317401itc.0 for <>; Wed, 02 Nov 2016 07:09:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=X5qo3vPCnfrLxuBmcUwjYg7y4tmuBrrj+KV4eM2u7rg=; b=CetDFDSCCiRVylcuFaH+R5Wr1K8UMOR74Kp5A7FnkJrpRaCvJNMpdfxDKPkOGACJy9 keWTvMD6afs7Oj5Jgnl83VtbSMcLbA22Jkoex4KCx3q49M0HgncZos0Kiufiw1F5AUB7 XP8u4LsvXcEi3vV1WT2EWGkWctMbSUAeeqbnSAlbBhrzUI+yxq6E+0hl1eeLc2nQnXFD WStoa2uJ74tztxHmSlgckISUq+ePJJnlh9bsLnL29rc4sCv28bXaVg2Stp6DzDUAumyG pHauxgNjUeN2uAWpyNw0RvW3ou56sMkykLKHWmGA5HjZq2EMaG7UiXL98xXGvuR0sZ5Y aTGA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=X5qo3vPCnfrLxuBmcUwjYg7y4tmuBrrj+KV4eM2u7rg=; b=Iaba/VQC8FjuSrGMEtilaq3kWm648YbbXbgRSVrqEfUFOhjjqHHTbzgUvQjYKPP/Xh XEmCcJ/a1T3mpNIf9kxmI3PLtAXJRFqzP7paI+vqMlnms3cCIHL7Q1LnjMOa05hl35Qv Vvjj4TbXqtY6TaTh5jvAD4pM8YiRtFS3SpPBuZ7b7OH8608G0l/4zVsfe7Z8Jgd51BuT sx00fUIjZemA5pAVImB3G213lyJ1gFoogm3WfUFB+40KQXgbUZ9mJKsQjRnkn8M96QMs vUOdZ8+n3lC1OO+4Wab3xZcqcU6OblApfZPxJY/WoyR7fD9k7iLRdpSPncI2PJ4GJ6nb QsrQ==
X-Gm-Message-State: ABUngvekVxUMAs2ecmcepw7Pw70/w+T5M3JCBWxwiZmAJ2xacc2F8BRl7DVoip6vgnKOblu2UMj6mvVCgSrxkg==
X-Received: by with SMTP id i205mr4383753iof.167.1478095726564; Wed, 02 Nov 2016 07:08:46 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Wed, 2 Nov 2016 07:08:45 -0700 (PDT)
In-Reply-To: <>
References: <> <> <>
From: Peter Bowen <>
Date: Wed, 02 Nov 2016 07:08:45 -0700
Message-ID: <>
To: Melinda Shore <>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <>
Cc: "" <>
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 14:09:41 -0000

On Wed, Nov 2, 2016 at 6:39 AM, Melinda Shore <> wrote:
> 6962-bis has completed working group last call.  Minor editorial
> changes are fine, but let's try to avoid major changes that would
> require yet another WGLC.  If there's a need for an additional
> document dealing with operational considerations or operational
> specifications, we can do that.  If there's a major problem with
> 6962-bis, we can deal with that as well, but it would need to
> be serious (i.e. goes to the correctness of the specification,
> fixes something that's broken, etc.).

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.

By requiring all logs MUST accept any certificate that chains to a
root in the log's root list, 6962bis fails to allow log operators to
mitigate any Denial of Service attacks mounted by attempting to log
massive numbers of certificates that are not relevant to the log
scope.  For example, many existing certification authorities issue
both server authentication certificates and certificates for personal
identification.  For some roots, acquiring large numbers of these is
relatively easy (see discussion of fetching millions of Taiwanese
Citizen Digital Certificates in  As written
today, a log MUST accept these.  There is no option for a log to
require that all certificates must meet some usability criteria.

I agree that a future additional document dealing with operational
considerations is fine, but as drafted today, 6962bis does not allow a
log to implement these considerations.