[Trans] Misissuance vs auditing/monitoring

Paul Wouters <paul@nohats.ca> Mon, 06 October 2014 15:20 UTC

Return-Path: <paul@nohats.ca>
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F19C1A6FCD for <trans@ietfa.amsl.com>; Mon, 6 Oct 2014 08:20:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.887
X-Spam-Level:
X-Spam-Status: No, score=-0.887 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.786] autolearn=ham
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 RPSBY0bUzNlF for <trans@ietfa.amsl.com>; Mon, 6 Oct 2014 08:20:34 -0700 (PDT)
Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7B3C1A6FC2 for <trans@ietf.org>; Mon, 6 Oct 2014 08:20:33 -0700 (PDT)
Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 09F8B80055 for <trans@ietf.org>; Mon, 6 Oct 2014 11:20:30 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1412608831; bh=WgXIj1hus9b3VUXHWBEnmmYin/OG1uklQNp2t5nAqy0=; h=Date:From:To:Subject; b=hsrLZbUFqPgXV2C+bctD7+dwvDATmCNrUS4AXPjgw2leWjvI1qBxEkNe+bgcwwHw8 v2HNx22oJdtFsccN7C3LrfBnUGkCUdkgYCIsNG+aX9/F/dO7tBZ5fdHhi+255HxkDq j0dEwtX6ReG7aTXe+iJSezZJrDWMP/WnLQBlEMAM=
Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id s96FKUkq019194 for <trans@ietf.org>; Mon, 6 Oct 2014 11:20:30 -0400
X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs
Date: Mon, 06 Oct 2014 11:20:30 -0400
From: Paul Wouters <paul@nohats.ca>
To: trans@ietf.org
Message-ID: <alpine.LFD.2.10.1410031530320.1396@bofh.nohats.ca>
User-Agent: Alpine 2.10 (LFD 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; format="flowed"; charset="US-ASCII"
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/q2BqA3MT524OP_uwGds-jrBRfKU
Subject: [Trans] Misissuance vs auditing/monitoring
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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: Mon, 06 Oct 2014 15:20:39 -0000

It seems the discussion about misissuance is going into far too
many different policy decisions favoured by different people. That
makes it obvious that it does not belong in the base specification
document.

The goal is to provide a distributed logging infrastructure that people
can use with their clients and monitors. Consumers and providers can
pick those that match their operational expectations and policies.

Logs will have different policies on which kind of certificates they will
accept into the log or not. But we should not come up with policies for
people running the logs in different commercial or legal systems. Each
will develop their own rules.

The focus should be on what the minimum requirements are for inclusion
into the log in such a way that the log is able to fulfill its function.

Being resistant to spam/dos attacks is an important factor. But should we
just mention it in the security sections and leave it open for everyone to
decide on? Someone might want _only_ self signed certificates in their log
server and it would be wrong if the base specification would forbid that.

The serial number seems to be a hard requirement, as it is needed to
uniquely identify the certificate. CABF policy is not. I'm sure there
will be logs that will only allow EV certs. That's fine. Those policies
do not belong in our document.

For the base document, we need to focus only on the requirements needed
for self-preservation of the log.

If someone is interested in writing a separate policy document for a
specific type of log, that would be great. For instance a log that only
takes in CABF members issued certificates.

Paul