Bob,
We do agree that there is a need to be able to manually load
PCA keys into PEM UAs, until such time as the IPRA is up an operating.
If one wanted to operate a closed PEM community, one could also argue
for having this facility available on a permanen, it could be much
simplier if that were the goal, but I guess one could argue that if
PEM UAs are plentiful and cheap then people will want to use them in
closed environments too. So, in general, I admit that having a
facility that allows adding PCA keys to the cache is useful.
Re your comments about a user employing his private key to
sign these manually entered PCA keys and DNs, I don't know that this
is any better than other local key security options. It really
continues to fall into the "local matter" category, not a subject for
PEM standards. A "PCA" that doesn't operate under the IPRA is not, a
PCA. The term was developed for PEM and is not generic, e.g., it
isn't part of X.509. A CA operating outside of the IPRA-rooted
framework may or may not adopt the IPRA common policy and so a PEM UA
really does not know what it should or should not check, what needs to
be displayed, etc. This is analogous to the name-subordination on a
per-PCA basis discussion that just arose. Yes, a company could decide
to operate a closed system, divosced from the rest of the PEM
community, and one way to make that work with off-the-shelf PEM UA
software is for the company to establish a "PCA-like" entity and agree
to operate by the (relevant) common policy specs, so that the UA
software will work.
But, I think this will work with generic PEM software ONLY if
those specs are followed. If a company starts to communicate with
another company, and still stay outside the rest of the system, it
would need to be convinced that the other company's "PCA" follows the
same rules, then they would have to arrage to make each other's CRLs
available to each other's "PCAs" etc. After a while, if multiple
companies do this, they will be operating a system comparable in
complexity to the system described in 1422, but with a need to perform
bi-laterla key exchange and CRL exchange with each newly added
company, etc. Also, if any other company added to this closed
community was already participating in the IPRA-rooted system, it
would find this closed community an anomaly. The newcomer would not
find the CRLs for the closed community via its usual access path (to
the real PCA under which the newcomer is certified). This closed
community approach does not scale well, although I agree it could be
operated on a single-company basis.
As for individual users excahnging email wihout being part of
the system, this is even a harder example of trying to use a system
that was deisgned to scale in a situation where scaling is not an
issue. Such users would find PGP easier to employ.
Your argument about name subordination not being viable is
groundless. 1422 describes exactly how an organization other than a
civil government authority can certify users and maintain name
subordination. The key is that these other organizations are PCAs,
which operate CAs in the name of the civil authorities, permitting
different policies to be explicitly advertised by these other
organizations. Also, as you give exmaples involving banks, etc. I
think we are moving dangerously close to confusing authorization
vs. identification, a hole into which we seem to fall with frustrating
regularity.
[The tongue-in-cheek sophistry about the user as his own PCA
etc. is humerous!]
Bob, if we agree that these certificates provide
identification, not authorization, then the trust we talk about is
accuracy of identification, good management of CRLs, etc. I totally
disagree with your continuing argument that one needs to be able to
"reject" certificates issued under certain PCAs, irrespective of
authorization and access control. Let me make an analogy to the phone
system. If Caller ID were universally available, you seem to be
suggeting that your home (or office) phone needs to be programmed to
reject phone calls from certain types of callers. Well, let's say
that you could reject all calls from pay phones, because obscene
callers use pay phones to avoid revealing their identity. Well, if
your child or wife were stranded and needed to use a pay phone to
contact you, the shortsightedness of this access control decision
woiuld become aparent, belatedly. So long as we are talking about
email, I think it is critical that we retain the ability for universal
certificate validation. Users can them make (informed) value
judgements about rejecting or accepting the email.
I could make another analogy with the experience of corporate
Internet users who find themselves behind firewall gateways and thus
are having great difficulty mamking use of wonderful applications such
as WWW. The idea that a site can identify in advance the classes of
destinations that their users mught wish to cummunicate with is
becoming less and less true as we develop more powerful information
retrieval tools. If you build an application on top of PEM, then it
makes perfectly good sense to use the PCA identity and the
originator's certificate as input to an access control decision, e.g.,
for matching against an ACL.
Bob, my view of PGP's illsuitedness to scaling encompasses
much more than just CRLs. You observe that Apple's signature facility
also doesn't support CRLs yet. I'm an avid Mac user, but let's
remember that Apple is hardly a role model for developing network
architectures that scale. How would you like to have to deal with
communicating with the worldwide Internet community if it were
represented as a set of Appletalk zones?
My view of certificate validation is that it needs to be
automatic, and that the amount of information displayed to a user
needs to be minimized, to avoid confusion. This view is well-
documented in the paper published in the proceedings if INET93, as
well as having been articulated in previous messages. Automatic
validation and minimal display requires a certain level of syntactic
constraints. Semantics enters into the picture when the user looks at
the displayed information, including the PCA identification, and makes
value judgement. Certificates are used to covey only identification
information, NOT user or organization TRUSTWORTHINESS in ANY larger
framework. After providing a level of authenticated identity
characterized by the PCA policy statement, you can go on to make all
sorts of external trust associations that increase your confidence in
the individual, but that is outside of the scope of PEM.
Bob, your comment that ACLs are really Integrity Control Lists
is puzzling. ACLs (in the computer context) have a long, well
documented history, dating back at least as far as a paper by Butler
Lampson in CACM in the mid-late 70s. What are ICLs and why do you
believe what I was talking about really involves ICLs vs. ACLs?
I'm persuaded that some members of this list have some
expertise in the broader issues associated with certification, beyond
just the PEM context. To that end I agree that it is reasonable to
addres these issues on this list. However, to frame such discussions,
I think you ought to provide a strawman document that is as complete
in what defining its scope and an initial, proposed set of mechanisms,
as is 1422 (or even its precursor, 1114).
Steve