The PEM model assumes a hierarchical distribution of keys, with some
small number of trusted root servers acting as the source from which
all trust flows, and a key distribution system which follows those
hierarchical lines of trust. I know who you are because the US Postal
Service has vouched for you, and because I implicitly trust the USPS
(or the Commander in Chief, King, or other soverign entity) to have it
right.
I'm not sure that I would agree with this characterization of PEM. Based on
the previous discussions along these lines with Steve Kent and Steve Crocker,
I think it would be useful to distinguish between syntactic _correctness_
and semantic _trust_.
In the fully developed PEM model, the IPRA will post and sign a certificate
for each PCA. This signature will attest to the fact that the PCA exists, and
that
it has published a policy statement, and that the public key for that PCA is
as contained in a certificate signed by the IPRA. But the IPRA does _not_
specify or enforce any particular level of trust that should be associated with
that
PCA. PCAs may be established that are specifically intended _not_ to
connote any trust at all with respect to a particular user, whose name may
be fictitious. In particular, PCAs may be established by various government
agencies
(which may or may not be considered to be trustworthy by various individuals
and/or
other governments). Resetting the calendar a couple of decades, The Committee
to
Reelect the President, the CIA, the Mafia, the UC Berkeley Student Association,
the ACLU, and the Communist Party of the United States would all have been
perfectly free to establish individual PCAs, and register them with the IPRA,
but that
doesn't necessarily imply a uniform, hierarchical trust model, even with respect
to identity, much less truth, beauty, financial responsiblity, etc.
Instead (although this point of view has been somewhat slow to develop and be
articulated), PEM allows and supports the use of various domains of trust,
where
the Policy Certification Authority essentially acts as the agent for a number
of
users (and their Certification Authorities) who have essentially agreed to
trust each
other to abide by the policy articulated (formally or informally) by the PCA.
The PEM RFCs specify quite nicely how one is to decide whether a given
certificate
is syntactically valid -- i.e., all of the certificates are signed in a
hierarchical fashion,
the current date (or the apparent date of signing) is within the validity
interval, and the
certificates have not been revoked.
The issue of whose digital signature is to be _trusted_, and to what extent,
must be
decided by the individual recipient. The de facto assumption within the Privacy
Enhanced Mail community is that the entire certificate chain is displayed for
the user's edification for each message, and the user makes a decision as to
the
believability of that message one at a time. The PEM software merely indicates
whether or not the certificate chain is syntactically valid, not whether there
is any
particular basis for trust in the content of the message, based on the identity
and perhaps affilaition of the originator.
Obviously letters of introduction, etc., may be useful in deciding whether to
believe
an individual user, especially if that user's CA or even PCA is not well known
or
trusted by the recipient. Likewise, if your company is your CA, and they have
valid business reasons for accepting or rejecting a given user or collection of
users,
then those dictates will govern whose signature you will trust, whether or not
they are
syntactically valid.
If you want to automate the acceptance/warning/rejection process, than some
implementation-dependent aids would be useful. As Kent suggested, you might
start off with something like the following in the start-up script (freely
inventing
syntax)
REJECT *.PCA (Reject all PCAs by default)
WARN COST.PCA (Issue a warning, but provisionally accept all CAs under this
PCA)
WARN MIT.PCA (ditto)
ACCEPT *.RSACH.CA (Accept all RSA Commercial Hierarchy CAs)
REJECT *.PERSONA-CA.* (Reject all persona CAs, regardless of the PCA)
ACCEPT Vielmetti.*.* (Accept your certificate on my own authority.)
Obviously, it will be necessary to carefully protect this script, less it be
modified. Depending on the particular circumstances, the individual user,
the user's MIS department, and/or the CA might be responsible for installing
the script. Any or all of them might digitally sign the script, but the public
key
necessary to validate this script must be provided in a trusted manner, somehow.
In some of the PEM implementations to date, the public key of the PCA is hard
coded
into the implementation software. This strikes me as undesirable, since that
key could
potentially be modified. The PEM RFCs are silent on this issue (at least I
don't recall
any discussion), but I would prefer that the user's private key (or keys) and
the
certificate containing his public key be stored on a removable diskette that is
encrypted in a passphrase which only the user knows. In addition, a small,
simple
cryptographic checksum validation routine should also be kept on the diskette
and
physiucally protected by the user.
When PEM is started up, the checksum validation routine on the protected
diskette
should be used to verify the correctness of the PEM software and the startup
script,
using the user's public key. The script can then define what level of
acceptance,
warning, and/or rejection should be associated with any given PCA, CA, or user.
In summary, although PEM provides mechanisms to syntactically verify the
correctness of a digital signature by validating the certificate chain, that
does
not in itself constitute a sufficient basis to trust the contents of the
message.
Before you can trust the message, you have to know that you can trust the
originator
(since the digital signature of a pathologicaly liar isn't worth much). Since
the CA can
impersonate any user within that CA's name subordination domain (but limted to
users under that domain -- one excellent requirement that PEM imposes that
other
validation systems may not), you also have to trust the CA, or else know via
a direct-trust path that the user's certificate is in fact that of the user.
Likewise,
although there is perhaps a lower risk of having a PCA counterfeit a CA, it
is necessary to trust the PCA or else have direct knowledge of the CA's
certificate.
But more important than anything else in this context is to finish the sentence:
" I, Robert R. Jueneman, trust user X do to and/or not do the following: ...."
I think that when implementations of PEM are available that support these
notions,
the difference between PEM and PGP with respect to the trust model will not be
as great as is presently perceived. And at least PEM does provide a workable,
if perhaps not ideal (IMHO) solution to the certificate revocation problem,
which is strictly a syntactic issue.
Bob