Peter,
You're on the wrong train. You want train 1421. On this train, you get
the same services as 1421, if you want them, plus a few other services
not previously available, BY DESIGN. In other words, 1421 is what it is
BY DESIGN, and PEM/MIME is what it is BY DESIGN.
(1) UA PEM procedure functionality will be required to handle key
management, rather than certificate management.
Then choose to ride only 1421. On this train, you get the same services
as 1421 in addition to the flexibility to help yourself.
(2) UA PEM procedures will be required to track on a
per-recipient basis the state of and procedures used in previous
key distribution interactions.
Excuse me?! Have you forgotten about the PCAs required in RFC 1422,
which by the way is required in a compliant 1421 implementation? Every
implementation is required to track the existence of every PCA and to be
able to report to a user the implications of a public key found to be
issued under that PCA.
Further, you're discussing database issues which, while they are
relevant to PEM in general, they are outside the scope of this
specification. This specification explicitly (BY DESIGN) divorces what
1421 and 1422 married. If you want that train, then you're on the wrong
track.
(3) no facility has been specified which facilitiates the
revocation of keying material distributed using authenicated or
unauthenicated channnels. A fundamentally incomplete identity
protocol is therefore introduced.
This topic is independent of the PEM/MIME specification and therefore
irrelevant to its status. Let me point out that even "classic" PEM
separated the topics into two documents: 1421 and 1422. This
specification explicitly (BY DESIGN) leaves the choice of key management
an independent event, instead of marrying them as required by 1421 and
1422.
(4) a recipient of a forwarded signed message may be in a
position of being required to establish out-of-band contact with
the originator in order to establish an authenticatyed channel
over which which to receive keying material necessary to
validate message origin. Name form cases exist in which no
communciation details are ever available, preventing third-party
reauthenication of the originator's cliamed identity. This
introduces ramifications for the anonymous origination usage
mode of PEM, in which it is not always the case that a given
message stream can always be proven to originate from a given
party.
Quoting Forrest Gump: "Stupid is as stupid does." :-)
In any case, if I've got a name form, then I've got as much information
as I would have with a certificate. If that's insufficient for locating
the user, then I would assert the user doesn't want to be found. Either
that or RFC 1422 is fundamentally flawed and we should kill it
immediately. Of course, why a user would sign a message, give me their
name, and then not want to be found escapes me.
Jim