Re: [Trans] Relaxing section 5.1

Eran Messeri <eranm@google.com> Wed, 02 November 2016 11:10 UTC

Return-Path: <eranm@google.com>
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFD5012955F for <trans@ietfa.amsl.com>; Wed, 2 Nov 2016 04:10:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.197
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tQgEPtXPpZNs for <trans@ietfa.amsl.com>; Wed, 2 Nov 2016 04:10:20 -0700 (PDT)
Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B673A129AE8 for <trans@ietf.org>; Wed, 2 Nov 2016 04:10:19 -0700 (PDT)
Received: by mail-wm0-x22c.google.com with SMTP id t79so29545604wmt.0 for <trans@ietf.org>; Wed, 02 Nov 2016 04:10:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; 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; d=1e100.net; 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 10.28.49.85 with SMTP id x82mr2862462wmx.129.1478085018137; Wed, 02 Nov 2016 04:10:18 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.28.31.21 with HTTP; Wed, 2 Nov 2016 04:10:17 -0700 (PDT)
In-Reply-To: <CAK6vND8_4OQ0du0MC8Z5=NJR5ho1EpT-8H41O+Te9tvM3YeNcg@mail.gmail.com>
References: <CAK6vND8_4OQ0du0MC8Z5=NJR5ho1EpT-8H41O+Te9tvM3YeNcg@mail.gmail.com>
From: Eran Messeri <eranm@google.com>
Date: Wed, 02 Nov 2016 11:10:17 +0000
Message-ID: <CALzYgEcuf+WoUVy=vsPYJ7t49ASe_5Tc7ySOuKoYJMzpODHtSA@mail.gmail.com>
To: Peter Bowen <pzbowen@gmail.com>
Content-Type: multipart/alternative; boundary="001a1142dd787491ff05404f7c34"
Archived-At: <https://mailarchive.ietf.org/arch/msg/trans/zjaTqIF9cqVEPb93a2BF8lymw-o>
Cc: "trans@ietf.org" <trans@ietf.org>
Subject: Re: [Trans] Relaxing section 5.1
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Public Notary Transparency working group discussion list <trans.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/trans>, <mailto:trans-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/trans/>
List-Post: <mailto:trans@ietf.org>
List-Help: <mailto:trans-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/trans>, <mailto:trans-request@ietf.org?subject=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
log.

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.

Eran

* - 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 <pzbowen@gmail.com> 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
> Trans@ietf.org
> https://www.ietf.org/mailman/listinfo/trans
>