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.