DESCRIPTION
Currently, with the exception of the use of certificates, the key
selector is an arbitrary value chosen by the owner of the public/private
key pair.
It has been asserted that this is unnecessarily complex and that the
value of the key selector should be restricted to being the public key.
POSITION
Leave the specification of the key selector as currently stated.
ACTION
If you disagree with this position you must send a message to the
pem-dev(_at_)tis(_dot_)com mailing list by 12am EST saturday, December 24.
Consider these two cases:
Case 1.
Suppose that all trust mechanisms are established off-line, outside
of the syntax of MIME/PEM message. A user downloads a certificate
from an X.500 server that is under a trusted hierarchy and stores it
in the local database. Or two users exchange public keys at an IETF
conference and put them on their laptop computers along with the
owner's email address. Or a user gets access to the certificate from
someone's Apple AOCE signer file.
Under case 1, when MIME/PEM messages are exchanged, the trust is
already established. The name forms are already established. The
trusted bindings are already available. In such a case, suppose I
receive a MIME/PEM message that looks like:
To: jefft(_at_)netcom(_dot_)com
Subject: Hi Jeff!
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/pem-signature";
micalg="rsa-md5"; boundary="Signed Boundary"
--Signed Boundary
Content-Type: text/plain; charset="us-ascii"
Content-ID: <21436(_dot_)785186814(_dot_)2(_at_)tis(_dot_)com>
How do you like the new MIME/PEM without all this unnecesary
proliferation of name forms?
Jim
--Signed Boundary
Content-Type: application/pem-signature
Content-ID: <21436(_dot_)785186814(_dot_)1(_at_)tis(_dot_)com>
Content-Transfer-Encoding: quoted-printable
Version: 5
Originator-ID: PK,MHkwCgYEVQgBAQICAwADawAwaAJhAMAHQ45ywA357G4fqQ61aoC1fO6B=
ekJmG4475mJkwGIUxvDkwuxe/EFdPkXDGBxzdGrW1iuh5K8kl8KRGJ9wh1HU4TrghGdhn0Lw8g=
G67Dmb5cBhY9DGwq0CDnrpKZV3cQIDAQAB
MIC-Info: RSA-MD5,RSA,PnEvyFV3sSyTSiGh/HFgWUIFa22jbHoTrFIMVERfMZXUKzFsHbmK=
tIowJlJR56OoImo+t7WjRfzpMH7MOKgPgzRnTwk0T5dOcP/lfbsOVJjleV7vTe9yoNp2P8mi/h=
s7
--Signed Boundary--
The only Originator-ID form need be the public key. When I receive
this message, I already have the certificate (or other binding)
available and I use the public key to locate it. When the signature
verifies, I display the name bound to the key. *There is no need for
the ID to contain any naming information.* Therefore, the public key
should be the only identifier form in the message.
I am *not* saying we should only allow a public key as the key
selector in the many name forms (as stated in the description of
problem above). I am saying the public key is the only identifier
needed. Naming information is not needed. It is an unnecessary
complication. Many people have complained about the proliferation of
name forms. The problem is solved. We don't need *any* name forms.
Only the public key.
(The case of Recipient-ID in an encrypted message is even more
evident, as others have pointed out. The recipient implicitly
recognizes their own public key. No naming help is needed to
recognize or trust it.)
Now, why might name forms come into the picture? That brings us to
the next case:
Case 2.
If I don't already explicitly trust the public key in the message,
there are two possibilities: I implicitly trust it via a certificate
hierarchy. In this case, the originator can send along certificates
in the application/pemkey-data, like we'd been planning all along. I
use the public key in the Originator-ID to find the certificate in the
application/pemkey-data and verify the chain.
Otherwise, the public key really is foreign. In this case, attaching
naming information to a public key *is an implicit certification
request*. What else can I do with an unrecognized name? I am
supposed to decide if I trust the originator and bind the public key
to the name. And again, MIME/PEM already has a great mechanism for
certification requests and other trust information: the
application/pemkey-data body part.
This is what the MIME/PEM spec is really trying to accomplish with
suggesting all the name forms. It is trying to anticipate the name
forms that people might want to bind to public keys, and to offer
mechanisms for these bindings. Consider the text from the
application/pemkey-data discussion in section 5:
The principal objective of this content type is to convey cryptographic
keying material from a source to a destination. However, no explicit
provision is made for determining the authenticity or accuracy of the
data being conveyed. In particular, when a public key and its
identifier is conveyed, there is nothing to prevent the source or an
interloper along the path from the source to the destination from
substituting alternate values for either the public key or the
identifier, thus setting up the destination such that when the data is
used sensitive information may be intercepted and disclosed
inappropriately.
It is incumbent upon a recipient to verify the authenticity and accuracy
of the data received prior to its use. The problem is addressed by the
use of certificates, since a certification hierarchy is a well-defined
mechanism that conveniently supports the automatic verification of the
data. Alternatively, the application/key-data body part could be
digitally signed by the source. In this way, if the destination
believes that a correct source's public key is available locally and if
the destination believes the source would convey accurate data, then the
key data received from the source can be believed.
NOTE: Insofar as a certificate represents a mechanism by which a
third party vouches for the binding between a name and a public
key, the signing of an application/pemkey-data body part is a
similar mechanism.
ACTION
Since name forms are only useful for certification information, I
suggest we keep them, but move them into section 5, Key Management
Content Types. Name forms don't even need to be specified earlier in
the document. The Originator-ID and Recipient-ID only need the public
key identifier.
- Jeff