Mark,
I think the outline is generally good. Here are some
comments on a few points:
Concept of certificates: A document containing a someone's
public key, and a digital signature from someone you trust
assuring you this is really the right key for this person.
You might mention that a certificate also identifies the issuer, i.e.,
the entity who is trusted to vouch for the identity of the subject of
the certificate. I think noting the validity interval feature of
certificates, and relating it to the typical credit card "not good
before, not good after" notion helps here. It also would allow you to
discuss CRLs, very briefly, as analogous to credit card hot lists.
Several in Europe Probably Unix-only (?)
Cite the GMD, INRIA and UCL/Cambridge versions explicitly
* No means of obtaining someone's public key.
Receiving a MIC-CLEAR or MIC-ONLY message from someone is a means,
though not an easy one, of obtraining someone's public key. This is a
directory problem in general.
* Use of certificate issuer and serial number to identify users
is awkward, limits audience.
I'm puzzled by this comment. How a recipient is identified to a
sender is a function of the user interface to PEM. The certificate
issuer and serial number is one of two ways for the software, not the
user, to specify a recipient's token in the PEM header.
* Allow specification of a recipient by name or email address,
in addition to certificate-based identification.
See comment above. What you really want to say here is that
other forms of names are proposed for use in certificates.
* Allow for retrieval of a someone's public key (certificate) by
email.
Means for doing this with the existing PEM are available, and have
been operated on an experimental basis at Bell Labs, so this is not a
fundamental differenec between MIME-PEM and vanilla PEM.