Doug,
I'm a subscriber to the "a certificate is just an
identification binding between a DN and a public key" school. The
issuer of a certificate, or others, may ascribe certain authorizations
(access rights) based on the identification provided by the
certificate, and that's natural. The company or university ID model
of access control is a natural analogy. In many computer systems we
grant access privileges based on names, implied group/project
affiliations, etc. I don't think we can prevent people from making
use of certified DNs in this fashion.
However, I expect people who do rely (primarliy) on DNs for
access control inputs, to be cognizant of the semantics implied by
such names. If the IRS were to use the format Steve Crocker explored
to issues certificates to H&R Block, I'd expect the IRS to interpret
those certificates as authorization to sign electronic tax returns.
They might insist on being the issuer of such certificates and even if
H&R Block had their own certificate issued under some high assurance
PCA, the IRS might decide not to accept it (organizations can be so
parochial ...).
If I were H&R Block, I would probably like a certificate with
my corporate name and without the IRS name, for use in other business
transactions. For example, the IRS assigns tax shelter registration
numbers to various real estate limited partnerships, but these
partnerships still need to have other identifying information to
represent them in other contexts (e.g., an incorporated name
registered with a secretary of state, ...). Some forms of ID are
useful for some contexts and others are required for other contexts.
Often, it is the binding between ID and implied authorization that
causes the issuance of multiple IDs. I don't think we can completely
prevent that, but I'm hoping that we can establish an envrionment in
which some forms of ID are perceived as having widespread utility, and
organizations become willing to accept that ID, or to bind their
authorizations to that ID, without issuing separate IDs for their
clients.
I am not sanguine about extending X.509 certificates to
encompass other than the ID and public key data they now contain. It
seems that additional, signed data items to convey authorizations are
not terrible baggage for systems to accommodate. Moreover signed
authorizations they represent only one of two major choices for
dealing with the traditional access control problem (i.e., they are
capabilities vs. ACLs), so I'd like not to burden the ID component of
a system with baggage linked to one of the two solutions.
Steve