[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
- [Trans] Misissuance vs auditing/monitoring Paul Wouters
- Re: [Trans] Misissuance vs auditing/monitoring Stephen Kent