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

["Santosh Chokhani" <[e-mail]>]

There are many ways to promulgate privileges and authorizations.  Two of
these methods are public key certificates and attribute certificates.

The I-D deals with how to process the clearance information in a chain
of public key and attribute certificates.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of Timothy J. Miller
Sent: Monday, October 13, 2008 9:40 AM
To: [e-mail]
Cc: [e-mail]
Subject: Re: What are certificates fundamentally all about? [was:
draft-turner-caclearanceconstraints-01.txt]

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.  :)

> 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.

However, that's a *lot* of work, infrastructure, and code needed to 
communicate an attribute the relying party can more simply look up in a 
directory at the time of the transaction, or that the relying party can 
have communicated to it as part of an authorization token (InfoCard, 
OpenID, SAML, WS-*, etc.).

These schemes have the advantage of accommodating both static, 
relatively static, and highly dynamic attributes, *plus* supports 
non-person attributes such as environment level, current threat posture,

etc.

In short, you have to have the directory anyway for at least some 
attributes, so it's simpler in the long run to stuff *all* the 
attributes in there.

-- Tim