Bob,
I think you extrapolated from our discussion last week to
include more than I feel comfortable with in terms of local
certificate management facilities. For example, while the user's key
could be used to certify the IPRA's key, I don't recall discussing
that option explicitly. I don't view it as attractive if the
implication is a user-centric certification system. The user could
employ his key to cerify the IPRA key, or the whole local cache
without turing the cache into a tree that begins with the user as its
root.
Yes, the user trusts himself, but I am opposed to a having PEM
users establish self-centric certification paths because of the
complexity that results. In a certification mesh of that sort, where
does name subordination kick in? How do you automatically distinguish
between PCAs, CAs and users? I'm not saying that one cannot develop a
system of this sort, but rather that the resulting trust model becomes
pretty complex in a hurry and I don't believe that most users are
prepared to manage it without getting surprizes. If you want that
sort of facility, use PGP.
Later aspects of your memo discuss authorization, which can be
managed through selective CA/PCA certificate management. However,
that is outside the scope of PEM. Also, I'd argue that what you are
talking about is really an ACL, with apporpriate *-name conventions,
not a certification model. One can be caoable of validating any
certificate in the system, but can make access control decisions based
on more restrictive criteria, on a per-application basis. The
fundamental issues here is separating the ability to validate a
certificate from the authorization to perform an operation. In current
password systems, we distinguish the ability to authentication ones
self from the authorization to access a file. The same analogy
applies here.
So, I will argue that the development of ACL mechanisms, based
on certificates, is out of scope for this WG. It is better addressed
on the access control and authorization WG mailing list.
Steve