Re: [Trans] Relaxing section 5.1

Peter Bowen <pzbowen@gmail.com> Thu, 03 November 2016 01:30 UTC

Return-Path: <pzbowen@gmail.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 0E2291297AA for <trans@ietfa.amsl.com>; Wed, 2 Nov 2016 18:30:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 B6jDQCHoppEe for <trans@ietfa.amsl.com>; Wed, 2 Nov 2016 18:29:58 -0700 (PDT)
Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com [IPv6:2607:f8b0:4003:c06::230]) (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 9BFBD1294F8 for <trans@ietf.org>; Wed, 2 Nov 2016 18:29:58 -0700 (PDT)
Received: by mail-oi0-x230.google.com with SMTP id 62so52575124oif.1 for <trans@ietf.org>; Wed, 02 Nov 2016 18:29:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=5zZqb/6XBMgtdtLkUYrnbtZm/pb3ehVmLKksq2OJwUM=; b=C0Y0RHxTuzBjSustPcArVV6ollvGEvbOpST0jdJ9QZFlek3P5W9KglWJCPdMW+y3TS WJ0kKrD3pzBLXSJheMHRcDeOTMpSv1ovdEh7UQmeBCRcBkvmdpTJMuI/HfIgWVAAh86A WbtbN8YJHreaxgzA01XwKBWFnzyVXgl48ooiQSk8+V9+elGxwg1xTX1M+/euueqbPZQe A8e4I50kaFgnnbZCXU1NzQy3ScJ4EtsTCTlHEMirGBUpLlIVzbVEtcKhY5ebrXkC+g99 GfA7D0vskGq30DtHo3Ytca8P/MYAgyMX7KW4rtkcKsRa7wLjUat6AnSwrDHlmZPdTYd4 KNQw==
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=5zZqb/6XBMgtdtLkUYrnbtZm/pb3ehVmLKksq2OJwUM=; b=lERrxyXRDk0k7Sfeq4WBDEaGhZNgThuqSBMq3mGU5VyRTZ/ggc7mkqwW3xyJU2K+rS Gtw09Nya7sESGKyfYraW+wQhxp0UYGgl5joL1LIbCc+j8TgnOxYjWBWoEH96jFd77W73 Pxl9GgwHTqiBFwkIZAWd6mCbkPbHIA7yv4eINZI3OcMgWL3dKcZd+KXNzBKsmOkn4CZT HdqnnZiuZw/iYYy9+r1eia52yetw+p49NYPc49zHNekeTL9Yw/dJQXsdZE/BmzSN+qDL UCjmIomnDSsj9O79J/tjRcB437sn+ls9OV6vXQR6DQ4XYe0oqbScEQ0+LhrgJUgx9kZW rUjw==
X-Gm-Message-State: ABUngvc5jdyDF9os9G6ED+b8sDCXaAvd8ODlul9v8oVfo1xDZeixSI++HMasKcD+aclCfIYWu5gQrs6WzwawpA==
X-Received: by 10.107.184.214 with SMTP id i205mr6660827iof.167.1478136597994; Wed, 02 Nov 2016 18:29:57 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.64.39.68 with HTTP; Wed, 2 Nov 2016 18:29:57 -0700 (PDT)
In-Reply-To: <CAFewVt4_7VYf3UkP+7drqVLQ7hKAotg1VQEaqgMmw6kJBtzwLA@mail.gmail.com>
References: <CAK6vND8_4OQ0du0MC8Z5=NJR5ho1EpT-8H41O+Te9tvM3YeNcg@mail.gmail.com> <CAFewVt4_7VYf3UkP+7drqVLQ7hKAotg1VQEaqgMmw6kJBtzwLA@mail.gmail.com>
From: Peter Bowen <pzbowen@gmail.com>
Date: Wed, 02 Nov 2016 18:29:57 -0700
Message-ID: <CAK6vND-otfOKf6g5TF3LUki68MF1xiEc23dMsMw8WnJVwoDVVQ@mail.gmail.com>
To: Brian Smith <brian@briansmith.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/trans/iPO1xCAwkmXCwUfbV0OgKZiaq5M>
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: Thu, 03 Nov 2016 01:30:00 -0000

On Wed, Nov 2, 2016 at 1:08 PM, Brian Smith <brian@briansmith.org> wrote:
> 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.
>
>
> 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.

Right, but why?  If the log can fix it up on the fly, why not return a
SCT?  Why can a log not include a certificate it finds acceptable even
if it can't link it back to a root?  Why should a log have a separate
store of certs for "future submission" instead of logging them
directly?

I see the worry about spam, but this would seem to be a greater risk
for the log operator than anyone else.  After all the log has to store
all the data and transfer it to all the clients, so their bandwidth
usage is far greater than any given client.

Thanks,
Peter