I'm glad to hear it. In case you didn't know, this is exactly the
approach taken by RIPEM 2.0 which we have now released. We use the
syntax from RFC 1421 and modify only one thing by introducing
Recipient-Key-Asymmetric which indicates the recipient of an ENCRPTED
message simply by the public key. (RFC 1421 indicates the recipient
by the issuer, which doesn't work in a direct trust environment with
no issuers. Besides, a recipient will always recognize and trust
their own public key without need of certification. This in fact works
fine with full-blown RFC 1422 hiererchies.)
- Jeff
Jeff, I 'm not sure who or what netcom is, or what exactly your role is, but you
seem to be playing a significant role in the RIPEM development.
I would be quite interested to know your thoughts on the degree to which the
modifications I have suggested to the PEM/MIME spec would dovetail with RIPEM,
and
what the possibilities are of enhancing the interoperability between the two
systems.
Would you outline the existing differences, and which ones you consider
relatively
major, either from a philosophy or an inpact-on-code and/or the existing user
base?
Can you estimate how many RIPEM users there are now?
And finally, since RIPEM seems to be using bare keys (if I understand you
correctly?) as opposed to certificates, what kind of a system is used for
storing
the keys and/or binding them to users?
Bob