Re: [Trans] Relaxing section 5.1

Ben Laurie <> Thu, 03 November 2016 10:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C774A1294D2 for <>; Thu, 3 Nov 2016 03:29:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.497
X-Spam-Status: No, score=-3.497 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_NONE=-0.0001, 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 OkU-62qbvGWP for <>; Thu, 3 Nov 2016 03:29:05 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400c:c08::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 35F87129849 for <>; Thu, 3 Nov 2016 03:28:59 -0700 (PDT)
Received: by with SMTP id 51so35235136uai.1 for <>; Thu, 03 Nov 2016 03:28:59 -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=dw/1bYbMT1jO8JiPoLeeBJvTCYogvNYRBla3Qsg7b8A=; b=n3aVskpWOIeZaTsExux2ts9zMQnQesjUBCBCNxc1E4iTBGq8nDUijHJq0ot2fx5rPy o/mAN4ptgHtpk5vcZnMjBaXG/jhy42TT0FKTtjrr9lYJJegKvrEsCUXAIKn6r6wihqOG KvigvMBN1HvbBRBkkVf11SJeVtrFeDRcuBW5QDnqDtXfrfDbR1EITLo/Xhq/8iNQ27KG D07/o7Gz2t+zBAZfs9xPsEv19M4cl8TbRvsWDH/ekoY1bM4Bpcikg+LFFZFYtgO98a1l KUrylgBDjajLfG+JOIpjkUr0D4HPs57qttL/H+x+LowRRyX7GG00U+SBpKfGto6RWBz8 PdMQ==
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=dw/1bYbMT1jO8JiPoLeeBJvTCYogvNYRBla3Qsg7b8A=; b=iZxdgZGpINUUAPsEVBSbv8kQivXVb1b5NzWEyuZ5mF+udDyHYGhDIqsfGzWlur/dWD nMXm4AqHtlYiF+mYRAwlZR6Tf+nhlLxsJR4gNUTNlTll2quhG5eGUWKIcuvM/92sBkWS /Y6sqFCNPEAfEHnGlvBgBbyVfSNgyJlmFwKaM3gJ/eumJoZ0o5a9DqfrA4538ul8oCB5 pCNkuEvYp5+ye1kiZood8XQ2xEBUyVLcEQWWyGDge6te6LBostcOsIKZ5PrvmUgkGNZz zK6vFDCfdfY91jRypSolccsyM/+o3bZneZJG3uwaZBl+1dnq80y6dBC6MQk0jDSkFrtI mrjA==
X-Gm-Message-State: ABUngvd6JpiCZO/Mv4b34/TZH6yJjJVexwCDuTIYe7mN39srf4gpgRJSgyZe2Q9GDmEydNiYdWusAA16dou5v+ob
X-Received: by with SMTP id j3mr5790791uaj.151.1478168938145; Thu, 03 Nov 2016 03:28:58 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Thu, 3 Nov 2016 03:28:57 -0700 (PDT)
In-Reply-To: <>
References: <>
From: Ben Laurie <>
Date: Thu, 03 Nov 2016 10:28:57 +0000
Message-ID: <>
To: Peter Bowen <>
Content-Type: multipart/alternative; boundary="001a114cb0d27a2887054063062a"
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: Thu, 03 Nov 2016 10:29:08 -0000

On 2 November 2016 at 02:19, 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.

The problem this was designed to address was that a) knowing of a bad
certificate is not all that useful unless you also know who issued it, b)
without chaining to some responsible party, it is unclear how to prevent
DoS on the log by filling it with nonsense certificates.

Technically, I guess, the requirement could be that what is _logged_ MUST
blah blah, but then that leaves open the question of how to construct such
a chain (which is not standardised).

In any case, it seems to me that if a log operator wanted to offer a
service to construct chains, it would be trivial to have a different
end-point that would accept partial chains, attempt to fix them, then
submit them to the log.

Also, we do provide code for repairing chains:

Which fixes your first case. The second case sounds more like a job for
DNSSEC Transparency...

> Thanks,
> Peter
> _______________________________________________
> Trans mailing list