I have avoided jumping into the fray here because I have seen too much
conversation not concerning PEM directly, but, instead, a lot of
pseudo-legal wrangling. This sort of discussion belongs, more
properly, on one of the legal discussion groups and not here.
However, one misinterpretation of the PEM standard seems to be
cropping up with a great deal of frequency. The PEM standard
specifies a policy statement for a PCA not to constrain the users of
the leaf certificates issued under that particular PCA's tree but to
state under what conditions that certificate was issued. Hence, for
example, a policy statement should not declare a signature generated
with a key from a certificate issued under the corresponding PCA
invalid for a particular purpose. (It may, nevertheless, hold
harmless the organization running the PCA from any damage incurred by
anyone or any organization which accepted the signature as a legal
authorization.)
The concrete example I most often envision is the policy for the PCA
run by the Federal Reserve Board (one of perhaps hundreds of PCAs in
the US alone, according to my personal PEM world view). This policy
would likely state that only the CAs run by member banks would receive
certificates from the Fed's PCA and that said CAs would be required to
run software/hardware implementations meeting a specific minimum
security standard. Further, the member bank running a CA would be
required to sign an agreement with the Fed which stated under what
conditions the CA would issue certificates (such as only to officer's
of the bank authorized to carry out transactions). Another bank
(perhaps not a Fed member) could then, AT THEIR DISCRETION, decide to
accept a PEM message as sole authorization to enter a transaction if
the certification path was validated and verified to go through the
Fed's PCA. A message signed by the same entity but with a key from a
certificate not within this path might not hold the same weight.
Note that the policy stated by the Fed does not either forbid nor
condone such use of a signature. Merely, it states under what
conditions the certificate containing the key used to generate a
signature is supposed to be issued. By stepping through the
certification path of the sender I can satisfy myself that, since I
really believe the Fed is the Fed and can get a verifiable copy of
their PCA certificate and that any Fed member bank is not likely to
want to abuse their CA privileges (lest they risk losing their
membership), the transaction authorization is acceptable. Someone
else, however, may not care for this argument and may require some
other "out of band" confirmation of the authorization before
proceeding--it's their call. Their reasons may be that they don't
trust the Fed, they don't trust PEM, they don't trust the person or
entity named in the originator's certificate, etc.
Other organizations running PCAs might not have such power over the
CAs they authorize or may not desire to exercise it. This would be
clear from their policy. Whether or not one believes the policy is
adequate for their validation purposes or that the organization which
stated the policy is trustworthy or powerful enough to carry out the
policy is a personal judgement call (which must be made case by case)
in order for PEM to scale to a really large, general user community.
It is likely that legislative and judicial assistance will be provided
users in the form of laws requiring certain fiduciary responsibilities
for (at least some classes) of PCA operators. Likewise, legal
definitions of the meaning of a digital signature will, also, be drawn
up (and not, I suspect, requiring the signer to file a multipage,
densely worded document attesting to their intentions to be bound by
affixing their digital signature to a document). However, as a design
and implementation issue, these concepts do not bear upon PEM or
pem-dev.
Jeff Kimmelman
BBN Network Security Department
------------------------------
| Phone: (617) 873-2679
| Internet: jkimmelman(_at_)bbn(_dot_)com
| US Mail: 150 CambridgePark Drive, Cambridge, Ma. 02140
------------------------------