If the MIME/PEM draft had a section discussing compatiblity issues
among the different supported methods, I imaging it would look
something like the following. This particular excerpt points out that
to interoperate with users who use <keysel> to keep the public key
hidden you need a database which does not expose its contents.
This is not backwards compatible with implementations which rely on
X.500-style public databases. Furthermore, the excerpt discusses the
danger that implementations of the non-hidden key school may
inadvertently publish a public key it receives by placing it in its
open database.
=====
Since a user may have more than one keypair, there needs to be a way
to indicate which is being used. This document supports two
approaches in order to service to two groups: the first which has a
certification and database system based on the public key being
public. This group will typically indicate a keypair by the public
key. The second group does not participate in public certification
hierarchies in order to reduce the chance that the public key will be
discovered and its modulus factored. This group will typically
indicate a keypair with a <keysel> field.
To send an encrypted message using the published public key method,
the originator typically obtains the recipient's public key from a
certificate database. The originator uses the public key to prepare
the encrypted message, and uses a Recipient-ID of the form:
Recipient-ID: PK, <publickey>
The recipient will recognize their own public key among those of
other message recipients and process accordingly.
To send an encrypted message using the hidden public key method, the
originator obtains the recipient's public key and <keysel> from a
non-public (local) database. (How the information can get ther will
be shown below.) The originator then uses the recipient's public key
to prepare the encrypted message, but only places the <keysel> in the
Recipient-ID. For example:
Recipient-ID: DN, <keysel>, <dnamestr>
An implementation with an existing database system based on public
certificates (such as described in RFC 1422) will not be able to
interoperate with users of the group who wish to keep the public key
hidden. This is because such databases do not store the <keysel> and
therefore cannot prepare a Recipient-ID of the form shown above.
Also, such a database is by definition public and therefore the
public keys are exposed. Therefore, recipients who want their public
key hidden would not be in this database.
When a user who uses a published public key prepares a signed
message, the Originator-ID typically looks like:
Originator-ID: PK, <publickey>
The public key indicates the keypair used to sign the message and can
also be used to locate the originator's certificate, either in the
recipient's database or in an application/pemkey-data body part
associated with the message. (Placing the certificate in the
application/pemkey-data like this is compatible with the
Originator-Certificate field of RFC 1421.)
When a user who wishes to keep the public key hidden prepares a
signed message, the Originator-ID typically looks like:
Originator-ID: DN, <keysel>, <dnamestr>
Again, the <keysel> is used instead of exposing the public key. An
implementation with an existing public certificate database will not
be able to process such a message because the <keysel> is not stored
in the database.
It is possible that a user who wishes to keep the public key hidden
may prepare an Originator-ID of the form:
Originator-ID: PK, <publickey>, DN, <keysel>, <dnamestr>
But a signed message with such an Originator-ID will typically be
wrapped within an encrypted message sent to a selected recipient.
(Thus the public key is not exposed.) This is a way that the
originator can indicate to the recipient what <keysel> is associated
with their public key, and the recipient should store this
association in a non-public (local) database, making efforts to
prevent the public key associated with its owner from being exposed.
If an application which uses a public certificate database receives
such an Originator-ID, it should be flagged as an error for two
reasons. Such databases do not have fields to store the <keysel>.
But more importantly, such an Originator-ID is from a user who is
conveying the <keysel> in order to use the hidden public key method.
If the application stores the public key in its public database, the
public key will be exposed, violating the wishes of the originator.
In general, the hidden key method is not compatible with applications
which are based on the published public key method because their
databases typically do not store the <keysel> field and moreover they
are not designed with the security protocols necessary to prevent the
public key from being exposed.