Re: [Trans] Relaxing section 5.1

Eran Messeri <> Wed, 02 November 2016 11:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EFD5012955F for <>; Wed, 2 Nov 2016 04:10:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.197
X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.497, 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 tQgEPtXPpZNs for <>; Wed, 2 Nov 2016 04:10:20 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B673A129AE8 for <>; Wed, 2 Nov 2016 04:10:19 -0700 (PDT)
Received: by with SMTP id t79so29545604wmt.0 for <>; Wed, 02 Nov 2016 04:10:19 -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=gbzD0gp3osFyn93gN/TBrz9amzCauUu5O9vMZTPrPx0=; b=Qr9eJMdImwX3D7+VqwoMaW8i4ICRGEdLDasw3cXad0qhahWY4JpsZdYuCsDSLawJKp giJxfYDAkZXp+uo2BaSI6w2uuEbjCLjKEz8jZeqaPgjRUkXignDKrkudbsgbnBtF7nAw IM5nO9W4RzhY0YWw8KTW5CVsK4ap3NQoMhhzxJvs+lMT4haQWG5b9P0E6tVxN4C+BMAd lrAQhYsvxyZXWtqmUU+ZKNOK6vjceGs3E0aA5JHQ0/2NAiYlIj71X1UbQTIkISBFhVvY CZuIpGCUOJhzVmSjvqFhHpiTDNAi5vMdKKL52aMQ56L7RybYPBiJ+V+/sotdJck/TTnF 9dlA==
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=gbzD0gp3osFyn93gN/TBrz9amzCauUu5O9vMZTPrPx0=; b=nAdVxtG4ZDhFYyb8xtX41DZIeVF6nZ2+dmLVEj3TrFEUSEMaUg3L+Tb62PBMHKtIIR gI9M9W6CTyJOX9/w9x4pRlFcqTJJjJXLaW+Qq3/4JLTx3Q+EpbwC89hrgpkj9LUOY2Nv QN0Qpe6NviF0rjZNI/vPbJVncMJxuc+uLpp1EjZBH6PcS0vJbShKSxljjwjv/xwoFLGA nVuzWLbWc3E9fi+WWG7Ma9QD32SuqYeCFgl61I5Wm3e9mTi9EEEn1c53cZnGI571dI1M XEyYv7ukin/E3FtxZXkcnt2mtkbPq7ipUdY0JwaQVxfx5iE0U21PgnUtPb5COd1sXrR1 PYDg==
X-Gm-Message-State: ABUngveWr5izUssxdOEmh9qyO18gyQYGWzJZpYbsNVCa2YBvDhuxQl5LgoNRYzx01vea/E0ze8/p+YFYrEu7UD9F
X-Received: by with SMTP id x82mr2862462wmx.129.1478085018137; Wed, 02 Nov 2016 04:10:18 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Wed, 2 Nov 2016 04:10:17 -0700 (PDT)
In-Reply-To: <>
References: <>
From: Eran Messeri <>
Date: Wed, 02 Nov 2016 11:10:17 +0000
Message-ID: <>
To: Peter Bowen <>
Content-Type: multipart/alternative; boundary="001a1142dd787491ff05404f7c34"
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 11:10:28 -0000

This is a really good question, in that I can see why some log operators
would like to set their own policies for accepting certificates into the

Each of the potential policies I've personally encountered, though, seemed
unique - there wasn't a common set of parameters that could be standardized.

Not specifying, in a standard manner, which submissions should be accepted
by a log will make it difficult to (1) check a log implementation for spec
compliance (2) clients to figure out where they should submit their
certificates to or why submissions are rejected. The current text makes it
very straightforward for a client to figure out if their submission will be
accepted by a given log (overall makes the protocol very simple).

I think (and I may be wrong) that there's still flexibility in allowing the
log to control the accepted submissions in a fine-grained manner by being
selective about the trust anchors used - the trust anchors do not have to
be root certificates, they could be intermediates.

What I wrote above only applies to server certificates - with other uses,
such as DANE, there may be other aspects of 6962-bis that are not suitable.
Given lack of concrete interest in using Certificate Transparency logs* for
certificates other than server certificates I don't know how much sense
it'd make to account for them in 6962-bis.

To be clear: I am not opposed to relaxing section 5.1 (and there are
arguments for changing the MUST to a SHOULD so that a log that drops
submissions for DOS protection, for example, is not considered
non-compliant). My argument is that if we relax it, it should be done in a
well-defined way such that a client implementation will not have to rely on
unspecified knowledge / external metadata to figure out which logs will
accept its submissions.


* - There's plenty of interest in transparent logs / verifiable data
structures, but those projects utilize the underlying data structure and
general concepts, but are not tied to the -bis protocol/specification.

On Wed, Nov 2, 2016 at 2:19 AM, Peter Bowen <> wrote:

> Currently 6962bis section 5.1 says:
>   "Logs MUST verify that each submitted certificate or precertificate
>    has a valid signature chain to an accepted trust anchor, using the
>    chain of intermediate CA certificates provided by the submitter. [...]
>    logs MUST reject submissions without a
>    valid signature chain to an accepted trust anchor.  Logs MUST also
>    reject precertificates that do not conform to the requirements in
>    Section 3.2."
> Is there a reason this is enshrined as a MUST?  It seems like it
> should be up to the log operator to determine their policy.  For
> example, a log operator might want to add a feature to accept
> certificates which have incomplete chains and have the log add the
> missing links from data it already has or a log operator may want to
> allow logging of certificates that are also published for DANE with
> TLSA records with certificate usage 2 or 3.  It feels very restrictive
> to require that every log only accept certificates that follow the
> traditional hierarchical PKI model.
> I can see value in providing guidance of what a log MAY want to do.
> However requiring such seems to limit the potential of transparency in
> undesirable ways.
> Thanks,
> Peter
> _______________________________________________
> Trans mailing list