What are certificates fundamentally all about? [was: draft-turner-caclearanceconstraints-01.txt]
Stephen Wilson <swilson@lockstep.com.au> Fri, 10 October 2008 22:40 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 818F43A6901 for <ietfarch-pkix-archive@core3.amsl.com>; Fri, 10 Oct 2008 15:40:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 6FL8K4Pn+K7a for <ietfarch-pkix-archive@core3.amsl.com>; Fri, 10 Oct 2008 15:40:57 -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 C4CF13A69CA for <pkix-archive@ietf.org>; Fri, 10 Oct 2008 15:40:56 -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 m9AMGYHM024775 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 10 Oct 2008 15:16:34 -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 m9AMGYRV024774; Fri, 10 Oct 2008 15:16:34 -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 smtp132.sat.emailsrvr.com (smtp132.sat.emailsrvr.com [66.216.121.132]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9AMGN9v024762 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <ietf-pkix@imc.org>; Fri, 10 Oct 2008 15:16:33 -0700 (MST) (envelope-from swilson@lockstep.com.au)
Received: from relay3.relay.sat.mlsrvr.com (localhost [127.0.0.1]) by relay3.relay.sat.mlsrvr.com (SMTP Server) with ESMTP id F03F825AC2C for <ietf-pkix@imc.org>; Fri, 10 Oct 2008 18:16:22 -0400 (EDT)
Received: by relay3.relay.sat.mlsrvr.com (Authenticated sender: swilson-AT-lockstep.com.au) with ESMTP id 1FA1725AC38 for <ietf-pkix@imc.org>; Fri, 10 Oct 2008 18:16:21 -0400 (EDT)
Message-ID: <48EFD404.6090602@lockstep.com.au>
Date: Sat, 11 Oct 2008 09:15:32 +1100
From: Stephen Wilson <swilson@lockstep.com.au>
Reply-To: swilson@lockstep.com.au
Organization: Lockstep
User-Agent: Thunderbird 2.0.0.17 (Windows/20080914)
MIME-Version: 1.0
To: "ietf-pkix@imc.org" <ietf-pkix@imc.org>
Subject: What are certificates fundamentally all about? [was: draft-turner-caclearanceconstraints-01.txt]
References: <p0624051bc5098b483ca0@[128.89.89.71]> <9F11911AED01D24BAA1C2355723C3D3218DDA55C66@EA-EXMSG-C332.europe.corp.microsoft.com>
In-Reply-To: <9F11911AED01D24BAA1C2355723C3D3218DDA55C66@EA-EXMSG-C332.europe.corp.microsoft.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
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>
Stefan Santesson wrote (quoted in reverse): > 2) If clearance would make it into certificates, then that should > be more than enough that we reasonable could handle as a standard. To > specify constraints for such information is to ask for big trouble. I suspect you're right about that -- too much to bear in a standard. However I don't agree that: > 1) ... a certificate is a very bad place to manage > clearance. [Clearance] is in its nature fundamentally different from Public > Key certificates as the certificate is an assertion of an entity’s key and > identity, which is generic and static ... Back in March at the NIST IDtrust2008 conference I presented a paper called "Public Key Superstructure" in which I argued for an adjusted view of what public key certificates are "fundamentally" all about. I submit that the view that PKCs are purely an assertion of an entity’s key and [generic and static] identity has led to most of the historic problems with PKI, because it predicts a single all-purpose generic certificate and in the process, overloads a single "identity". My paper on these issues is at http://middleware.internet2.edu/idtrust/2008/papers/07-wilson-public-key-superstructure.pdf In line with contemporary thinking about identity plurality (as per e.g. The Laws of Identity) I think it's more powerful to construct multiple PKCs with each representing a different identity in a particular context. 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. In my Public Key Superstructure paper I argued that it might be clearer to refer to these 'identities' as "Relationships"; in practice, the relationship is vouched for by an RA that has some connection to the Subject. The Policy OID suffices to uniquely point to a comprehensive definition of exactly what that relationship is, the processes that underpin it, the context in which the relationship is meaningful and, by extension, the applications for which the PKC is meaningful. To illustrate the point, I don't actually see any reason in principle why a PKC could not be used to assert my identity (or relationship) as 'a person cleared to Top Secret' so long as that relationship is relatively long lived; say a few months. Path validation is a cinch: the relationship I would have express in my PKC is with a particular vetting agency, which would appear in the path, with a Policy OID in the Subject PKC that specifies the clearance protocol. The Public Key of the vetting agency -- or a higher Root Key -- would be the trust anchor needed in a whole class of applications processing my digital signature applied to Secret documents. Cheers, Stephen Wilson Managing Director Lockstep Technologies Phone +61 (0)414 488 851 www.lockstep.com.au/technologies ------------------- * Global Security Challenge Asia Top Five 2008 * Australian Technology Showcase 2008 * AusIndustry COMET Grant Recipient 2007 * ICT Secrets of Innovation Finalist 2007 * Anthill / PwC Cool Company Finalist 2007 ------------------- Lockstep Consulting provides independent specialist advice and analysis on authentication, PKI and smartcards. Lockstep Technologies develops unique new smart ID solutions that safeguard identity and privacy.
- draft-turner-caclearanceconstraints-01.txt Stephen Kent
- RE: draft-turner-caclearanceconstraints-01.txt Turner, Sean P.
- RE: draft-turner-caclearanceconstraints-01.txt Turner, Sean P.
- RE: draft-turner-caclearanceconstraints-01.txt Santosh Chokhani
- RE: draft-turner-caclearanceconstraints-01.txt Reddy, Raksha Patel
- RE: draft-turner-caclearanceconstraints-01.txt Russ Housley
- Re: draft-turner-caclearanceconstraints-01.txt Kurt Zeilenga
- RE: draft-turner-caclearanceconstraints-01.txt Ashmore, Samuel R.
- Re: draft-turner-caclearanceconstraints-01.txt Stephen Farrell
- RE: draft-turner-caclearanceconstraints-01.txt Stefan Santesson
- RE: draft-turner-caclearanceconstraints-01.txt Denis Pinkas
- Re: draft-turner-caclearanceconstraints-01.txt Yoav Nir
- What are certificates fundamentally all about? [w… Stephen Wilson
- RE: draft-turner-caclearanceconstraints-01.txt Carl Wallace
- Re: What are certificates fundamentally all about… Timothy J. Miller
- Re: draft-turner-caclearanceconstraints-01.txt Timothy J. Miller
- RE: What are certificates fundamentally all about… Santosh Chokhani
- RE: draft-turner-caclearanceconstraints-01.txt Santosh Chokhani
- Re: What are certificates fundamentally all about… Stephen Wilson
- Re: What are certificates fundamentally all about… Stephen Kent
- RE: draft-turner-caclearanceconstraints-01.txt Turner, Sean P.
- RE: draft-turner-caclearanceconstraints-01.txt Stefan Santesson
- RE: draft-turner-caclearanceconstraints-01.txt Santosh Chokhani
- RE: draft-turner-caclearanceconstraints-01.txt Tom Gindin
- RE: draft-turner-caclearanceconstraints-01.txt Stefan Santesson
- RE: draft-turner-caclearanceconstraints-01.txt Santosh Chokhani
- RE: draft-turner-caclearanceconstraints-01.txt Santosh Chokhani
- RE: draft-turner-caclearanceconstraints-01.txt Russ Housley
- RE: draft-turner-caclearanceconstraints-01.txt Stefan Santesson
- RE: draft-turner-caclearanceconstraints-01.txt Santosh Chokhani
- RE: draft-turner-caclearanceconstraints-01.txt Tom Gindin
- RE: draft-turner-caclearanceconstraints-01.txt Santosh Chokhani
- Re: draft-turner-caclearanceconstraints-01.txt Timothy J. Miller
- RE: draft-turner-caclearanceconstraints-01.txt Stefan Santesson
- RE: draft-turner-caclearanceconstraints-01.txt Santosh Chokhani
- Re: draft-turner-caclearanceconstraints-01.txt Timothy J. Miller
- RE: draft-turner-caclearanceconstraints-01.txt Santosh Chokhani
- RE: draft-turner-caclearanceconstraints-01.txt Stefan Santesson
- RE: draft-turner-caclearanceconstraints-01.txt Tom Gindin
- RE: draft-turner-caclearanceconstraints-01.txt Santosh Chokhani
- RE: draft-turner-caclearanceconstraints-01.txt Tom Gindin