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

[Stephen Wilson <[e-mail]>]

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

Not too sure if your smiley was a 'knowing' cheeky smiley?!  In "Public 
Key Superstructure" I address SPKI and argue that it's not really simple 
enough.  I believe SPKI retains at its core the orthodox misconception 
that authentication and authorisation should be constructed on the back 
of a single superior identification.

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

The directory is fine if the transactions are only ever processed in 
real time -- that is, you're never interested in checking an old 
signature on a transaction from months or years ago.  In that sort of 
case, what method exists for freezing the state of an attribute-rich 
directory for all time, so that all conceivable relying parties can at 
any time down the track look up the attribute of interest for all senders?

The very cool and unique thing about PKCs when attributes are in the 
certificate is that they bake the attributes into each transaction, such 
that you only need a CRL [or delta CRLs] to check a transaction, no 
matter how old it is.  Even long after all PKCs have expired.

This longevity is not important for all transaction settings, so I agree 
that the attribute-rich directory is sometimes a better fit.  But in 
e-health, digital mortgages, electronic trade documentation, pension 
funds management, insurance and similar fields, you cannot beat 
PKCs-with-included-attributes for elegance and efficient processing.

Cheers,

Stephen Wilson
Lockstep.