Page 8 of the pem-mime document states the following:
<id-publickey> ::= "PK" "," <publickey> [ "," <id-subset> ] CRLF
<publickey> ::= <encbin>
; a printably encoded, ASN.1 encoded public key (as
; defined by the 'SubjectPublicKeyInfo' production
; specified in X.509)
<id-subset> ::= <id-email> / <id-string> / <id-dname>
... Recipients of a public key identifier must take care to verify the
accuracy of the purported association. If not, it may be possible
for a malicious originator to assert an identifier that accords the
originator unauthorized privileges. See Section 5.2 for more details.
Section 5.2 says:
5.2. application/pemkey-data Content Type Definition
... 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.
Regarding the example on page 19:
To: Ned Freed <ned(_at_)innosoft(_dot_)com>
Subject: Hi Ned!
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?
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,EN,2,galvin(_at_)tis(_dot_)com
MIC-Info: RSA-MD5,RSA,PnEvyFV3sSyTSiGh/HFgWUIFa22jbHoTrFIMVERfMZXUKzFsHbmK=
tIowJlJR56OoImo+t7WjRfzpMH7MOKgPgzRnTwk0T5dOcP/lfbsOVJjleV7vTe9yoNp2P8mi/h=
s7
--Signed Boundary--
If I read the document correctly, it says "Don't accept the Public
Key/ID-Subset association at face value." The PEM-MIME document goes on to say
(page 17 again):
"... It is incumbent upon a recipient to verify the authenticity and accuracy
of the data received prior to its use."
I agree with all this but ask "Why bother transferring the public key with the
name form if that public key is not to be trusted?" Doesn't this provide the
unsuspecting user with the opportunity to make a SERIOUS error?
Instead, why not require the key/name form to be transmitted separately and
validated before use. Please don't say this is an implementation issue.
If a sender (and recipeint) wanted to send the key/name form association along
with a signed message then could this be accomplished with another Content-Type
within the same multipart message? This way, sender and receiver take
conscious steps when using an unvalidated public key.
I have a similar question regarding use of certificates. In Classic PEM, the
originator certificate and cert chain was transmitted along with the signed
(and optionally encrypted) message. One advantage of this was it enabled a
recipient to validate the certificate with information in the message. That is,
the originator certificate and cert chain were there to be traversed and
evaluated. This is a nice feature for mobil users (with notebook pc's) who want
to read secure e-mail while travelling. They need only the public key of any
trusted root(s), their own private key, and the PEM software to do this.
Based on the MIME-PEM document, the sender can specify an issuer name/serial
number identifier. Is it anticipated that the certchain will be transmitted
with this identifier or will it be retrieved from receiver's certificate data
base? For mobil users, access to a non-local cert data base is problematic. It
means that every signed message must be evaluated before disconnecting from the
certificate data base or certificates are maintained locally (bad idea IMHO).
How is this addressed in MIME-PEM?
I REALLY tried to make this brief. If I've left out anything, let me know.
Phil Smiley