Re: [Trans] Relaxing section 5.1

Brian Smith <> Wed, 02 November 2016 20:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EBC63129469 for <>; Wed, 2 Nov 2016 13:08:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=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 Hjs77LSf62Ip for <>; Wed, 2 Nov 2016 13:08:45 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4003:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 27FCD127076 for <>; Wed, 2 Nov 2016 13:08:45 -0700 (PDT)
Received: by with SMTP id x4so35187783oix.2 for <>; Wed, 02 Nov 2016 13:08:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=xIfPkEEs/xET6BNZb/noW/rDOay4hz2ZJYmqw7N6Kns=; b=r8KyK1QMWV49mLemJvWVjIiPhrfBrJLiTvMjBlGMsFgDdXIlTLz7W+uIxyNoAzAJ9Q 0tmqIhkfJvtSySWFxPdaGdHCk0h6Gini2xOK1HMR+8+G0s72kgsBA7csqEIZqz0ryR6k CzszJvrWBzqwijtOdP7f9V7wsaKPdDV6XEbQgmVEdNZtPTvGq4h+gQvvKNW2SjnjGx1e K/T/sxrcnYXIcOcgWT6ruMX7DnNBJn4ffSdqUHkzdM/m0KB5Qi8w5ivOlGS5Zo/X+GjR y6g8JINCl/PUPJN85xi9/WWV8djfmtyMiwyctySULl4eIx6VMVIbQaIKoLcYwNYFRIAm yUAw==
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=xIfPkEEs/xET6BNZb/noW/rDOay4hz2ZJYmqw7N6Kns=; b=f1aGSsU5R63LwjpUIhySqbhgJoHbb6AO9OXX7VYDJBMhkwOpOASCLC/xQ19k9OYBr3 bBk0M3kl+Z3XEiBWvoDC9/0UP5W9pX2kt5PETqwWmYZuDBfi7zjOo09VohXKhLbv1L8L 0b+DBXE9sThZgRXwielj3ts6iAr6C/WSLjW+N+2PVpgm52FspBLkiD9vCoY903i3Ck16 geZfcEAb0Fx/FfPHKitRvMY739OUN3HK3jWnObQeIQHGjN1WwtH+SxM2QiM18AhMKesp tkX/AIUtCx0EwtqwpJ3/91cBjKSK/eRxWH0+gPe5J08A+nHbLm1YOtis5zMEfuOwHdpD QDFA==
X-Gm-Message-State: ABUngvd5cQbA6rhK6OayL1jaqU52EN6UPRfRy5q0//ERf9UtjTB56gu1dpVGietWpjMSKGjj/HTsdnOVmx2cpA==
X-Received: by with SMTP id 93mr123863ioh.136.1478117324264; Wed, 02 Nov 2016 13:08:44 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Wed, 2 Nov 2016 13:08:43 -0700 (PDT)
In-Reply-To: <>
References: <>
From: Brian Smith <>
Date: Wed, 02 Nov 2016 10:08:43 -1000
Message-ID: <>
To: Peter Bowen <>
Content-Type: multipart/alternative; boundary="001a113ec7d00cad4405405702ac"
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 20:08:47 -0000

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.

The log can reject the submission (return a non-2xx response) and still
incorporate the certificate into the log, especially if it can build its
own path to a trust anchor it trusts. The only thing that the log is
prohibited from doing is giving the submitter a 200 response with an SCT
when the submitter supplies an incomplete/untrusted chain.

In particular, the log can reject a submission (with a non-2xx response)
but then re-submit the same certificate to itself with a different
certificate chain (returning a 2xx response).

A log can store rejected submissions in a holding bin for later
self-submission when new intermediates are discovered and/or new roots are

Note that when people query the log using get-entries, the log shouldn't
return certificates it has never been able to build a valid chain for, by
default, I think. Otherwise the system doing the querying might be DoS'd
with untrusted certificates. But, it is probably a good idea to have a way
to query rejected/not-yet-trusted submissions too.