Steve Crocker's point sparks something extremely important here that is
too easily lost when we think in terms of just mail and simple
affiliation. (I'm not sure if he meant to spark this, but in my mind it
did.) We are wrestling with some issues around certification in a
totally different arena, so it is appropriate that I get my 2c in here.
(Unfortunately, I'm not at the point that I want to publicly tell what
my arena of interest is, although Steve Kent knows.) Steve Crocker
writes:
Now it might be argued that H. & R. Block ought to have its own
certificate, issued by some PCA. Eventually this may be true, but we
foresee numerous situations in which the service organization -- the
IRS in this case -- will prefer to issue its own credentials, *and*,
with equal force, the client may be not be in a position to institute
general certificate issuing capability within its own organization.
I see two separate issues here, the first of which strikes my interest
the most.
1. The IRS and H&R Block example raises two important points, the
concepts of implied rights and an implied trusted working
relationships, conveyed along with the certificate. This is more
than just an affiliation, in the sense that one entity belongs to a
larger entity. It exemplifies a working relationship that just
happens to be orthogonal to organizational boundries. What I read
into the example was the following:
a. We, the IRS, hereby convey to H&R Block, by means of this
certificate, the right/privilege to sign income tax returns.
We, the IRS, can also revoke that right/privilege by revoking
this certificate. (They may possess other certificates for
other roles.
b. We, the IRS, trust the claimant, H&R Block, to operate in
this trusted relationship, because WE, not someone else, have
certified them.
We have had a number of arguments around the conveying of rights and
trusted relationships within certificates or by other means.
1. Many feel that the certificate should be ONLY a means of
identification, i.e., the binding of a DN and a public key, and that
all conveyance of rights or relationships should be done by
independent means, such as a PEM-signed power of attorney like
document.
2. On the other hand, there are cases where you may want to tie the two
together for some very valid reasons and/or could eliminate the need
for the distribution and maintenance of yet another signed document
by simply combining it with the certificate, explicitly or
implicitly.
3. One obvious way to do this is to build the relationship into the
naming hierarchy, as the DN in Steve Crocker's example indicates
and as Steve Kent suggests by making the IRS a PCA.
Perhaps, point 3. is the right solution, but I can envision a lot of
PCAs, an additional one for each such trusted working relationship. I
can also envision small-scale relationships being locked out for lack of
the ability to become a PCA. I would truly welcome a more general
solution, e.g., a "role" bound into the certificate, for the system I am
working on. Any possibilities of this?
doug stell, Digital Equipment Corp.