Subject: Re: Attributes within PK certs?

From: "David P. Kemp" <[email-masked]>
Date: Mon, 10 May 1999 16:56:24 -0400 (EDT)

> From: "Linn, John" <[email-masked]>
> 
>  ...  If experience is a guide, however,
> new certification infrastructures can take a long time to become
> established.  With this in mind, I suggest that we decouple the idea of
> certifying authorization attributes from the idea that they must be in ACs
> separate from public-key identity certificates.  As [XPDAM] allows, I
> suggest that PKIX-profiled authorization attributes alternatively be
> representable within subjectDirectoryAttributes of a public-key certificate,
> when CA and AA responsibilities and validity periods overlap appropriately.

When the program I am associated with began, X.509 was only v1.
Needing to do authorization, but lacking an extension mechanism, we
defined our own algorithmIDs and encoded authorization attributes into
subjectPublicKeyInfo.  This was an X.509-compliant approach, and it
worked.  Now that X.509 v3 is available and ACs are not, we do just as
you suggest, encoding authorization attributes in the
subjectDirectoryAttributes extension, which is no more or less
X.509-compliant than the first approach.

But although algorithm parameters and extensions can both be profiled
to hold attributes within communities of interest, I do not believe it
would be architecturally sound for a community as large as PKIX to
profile such practices.  Instead, PKIX should do everything possible
to encourage the distinction between identification and authorization;
allowing PK certs on the Internet scale to be long-lived and
(relatively) simple.  Standardized authorization structures, wherever
they are carried, will be a long time in coming.  Standardizing the
placement of attributes in PK certs will, IMO, delay the availability
of AC-enabled applications far more than it would accelerate the
availability of cert-based authorization.

---

From: "Linn, John" <[email-masked]>
Date: Wed, 12 May 1999 14:36:55 -0400

> availability of cert-based authorization.

Futures are hard to predict, but I'll venture an alternate view.  If
authorization attributes can be represented only in separate ACs, this means
that they can't be used until certificate-using protocols and their
implementations evolve to represent, transport, and support ACs as well as
PKCs.  If attributes could also be represented within (non-critical) PKC
extensions, a principal could obtain and use a common PKC to interoperate
with peers recognizing the attributes and (in an identity-based mode,
without the benefit of attribute-accorded rights) with other peers who don't
recognize attributes.  Depending on implementation structure, the
distinction might be confined within security modules invoked for
certificate processing, largely insulated from calling applications. By
incurring fewer dependencies on certificate-using applications, and allowing
incremental migration to attribute usage, this option could simplify rather
than delay attribute enablement. Its availability wouldn't preclude use of
separate ACs when supported and/or necessary to accomodate diverse
administrative structures or validity periods. 

--jl