Re: What are certificates fundamentally all about? [was: draft-turner-caclearanceconstraints-01.txt]

Stephen Kent <kent@bbn.com> Mon, 13 October 2008 17:02 UTC

Return-Path: <owner-ietf-pkix@mail.imc.org>
X-Original-To: ietfarch-pkix-archive@core3.amsl.com
Delivered-To: ietfarch-pkix-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5899D3A6895 for <ietfarch-pkix-archive@core3.amsl.com>; Mon, 13 Oct 2008 10:02:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.725
X-Spam-Level:
X-Spam-Status: No, score=-2.725 tagged_above=-999 required=5 tests=[AWL=-0.126, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MYPIh6sdob-l for <ietfarch-pkix-archive@core3.amsl.com>; Mon, 13 Oct 2008 10:02:38 -0700 (PDT)
Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 84D9F3A67B0 for <pkix-archive@ietf.org>; Mon, 13 Oct 2008 10:02:35 -0700 (PDT)
Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9DGY2pf016379 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Oct 2008 09:34:02 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org)
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9DGY2Ja016378; Mon, 13 Oct 2008 09:34:02 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f
Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9DGXpNw016353 for <ietf-pkix@imc.org>; Mon, 13 Oct 2008 09:34:02 -0700 (MST) (envelope-from kent@bbn.com)
Received: from dhcp89-089-071.bbn.com ([128.89.89.71]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from <kent@bbn.com>) id 1KpQMg-0005nv-D2; Mon, 13 Oct 2008 12:33:50 -0400
Mime-Version: 1.0
Message-Id: <p06240513c51921f728eb@[128.89.89.71]>
In-Reply-To: <48F34FB6.2020205@mitre.org>
References: <p0624051bc5098b483ca0@[128.89.89.71]> <9F11911AED01D24BAA1C2355723C3D3218DDA55C66@EA-EXMSG-C332.europe.corp.micr osoft.com> <48EFD404.6090602@lockstep.com.au> <48F34FB6.2020205@mitre.org>
Date: Mon, 13 Oct 2008 12:12:19 -0400
To: "Timothy J. Miller" <tmiller@mitre.org>
From: Stephen Kent <kent@bbn.com>
Subject: Re: What are certificates fundamentally all about? [was: draft-turner-caclearanceconstraints-01.txt]
Cc: swilson@lockstep.com.au, "ietf-pkix@imc.org" <ietf-pkix@imc.org>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe>

At 8:40 AM -0500 10/13/08, Timothy J. Miller wrote:
>Stephen Wilson wrote:
>
>>Then you can subtly adjust the conception of a PKC as being "an 
>>assertion of an entity's key and a RELATIVELY STATIC identity IN A 
>>DEFINED CONTEXT".  A flexible interpretation of "identity in a 
>>defined context" embraces things like my identity as an chartered 
>>engineer, my identity as a business owner, my identity as a health 
>>insurance subscriber, my identity as a bank account holder.  In 
>>each of these scenarios, it would be very powerful for me to carry 
>>a separate dedicated certificate with which to sign specific types 
>>of transactions (e.g. engineering test reports, tax returns, health 
>>insurance claims, and payment instructions respectively).  That is, 
>>four different certificates all independently registered and 
>>managed, tightly coupled to regular customer relationship 
>>management processes, probably carried on separate smartcards.
>
>We have that; it's called SPKI/SDSI.  :)

No, it's called not VeriSign :-).

I authored a paper in 1997 that made the same argument as Stephen 
Wilson did (maybe it's a Stephen thing). Moreover, there is a report 
published in 2003 by the National Academies Press ("Who Goes There? 
Authentication Through the Lens of Privacy?") that also observes that 
an individual does not have just one identity, and thus we ought not 
assume that a single cert will suffice to identify/authorize an 
individual.


Moreover, arguments that clearances are not sufficiently long-lived 
to be put into certs do not match lots of experience.  Basic 
clearance info (vs. compartments) tends to be very stable, for 
multiple years, in the the U.S. DoD.  They have issued certs 
containing clearance info for a while, and not found that clearance 
changes create undue CRL activity. They have issued certs with more 
than just basic clearance info, e.g., to secure phones and data 
encryption devices, and those too have proved to be long-lived. So we 
ought not waste time debating this aspect of the proposal, because 
there is enough experience to resolve these specific arguments.

Steve