>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.
Then we are agreed. By design, 1421 security and MIME/PEM
security are different, as they relate to the forwarding and
stored message models, and the message content architecture
models. The are vitally different in the security services they
specify and support, particularly in relation to storage of
non-repudiable messages.
No, we're not in agreement. In light of what John Linn said in his
message, let me revise what I said and be more specific.
The definition of PEM in 1421 and the PEM/MIME specification are
compatible. In fact, the PEM/MIME specification, in its current form,
depends on the existence of 1421. Where they differ is in the public
key validation model.
When I said, "you want train 1421," what I was really saying is that the
majority of the message you sent was focused on what RFC 1422 requires
and the fact that the PEM/MIME specifications do not require a specific
validation model. Or, to use my favorite phrase, insofar as you believe
that 1421 and 1422 are married, PEM/MIME divorces them. PEM/MIME allows
as a separate concept, a separate problem with an independent solution,
the problem of key management/validation/assurance/revocation.
Having said that, I believe I need only respond to the last line of the
rest of your message.
So as Dave says, put both on parallel tracks.
Here, here!!
Jim