Steve (Crocker), you asked me to post a message on issues we discussed
at the Seattle meeting. I would like to address two issues in MIME:
1. Single-pass processing.
2. Originator and recipient identifiers for flexible trust models.
1. Single-Pass Processing.
The current MIME/PEM draft (March 1994) puts the cryptographic info
after the content for both signed and encrypted messages. This was to
avoid clutter at the beginning of a message. But both cases need to be
changed to allow single-pass processing. My suggestions follow PKCS #7:
For encrypted messages, simply put the application/keys part before
the content. For an ecrypted message, the content can't be read anyway so
we aren't worried about clutter at the beginning. When receiving the
message, an application proceses the application/keys, recovers the
DEK and proceeds to decrypt the message in a single pass.
For signed messages, it is good to keep the application/signature part
after the content. This especially makes single-pass processing easy when
preparing the message by allowing the application to digest the content
while copying it to the message, compute the signature and then output
the application/signature after the content.
When receiving the message in a single pass, however, an application
needs to know the digest algorithm(s) for digesting the content.
Therefore, a signed message should have three parts: a declaration of
digest algorithms, the content, and the application/signature. For example:
To: ned(_at_)innosoft(_dot_)com
Subject: example #1
MIME-Version: 1.0
Content-Type: multipart/security; boundary="----- =Signature Boundary"
------- =Signature Boundary
Content-Type: application/digest-ids; protocol="pem"
Digest-ID: RSA-MD5
------- =Signature Boundary
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1685(_dot_)762723090(_dot_)2(_at_)tis(_dot_)com>
Hi Ned. See how much nicer this works!
------- =Signature Boundary
Content-Type: application/signature; protocol="pem"
Content-ID: <1685(_dot_)762723090(_dot_)1(_at_)tis(_dot_)com>
Content-Transfer-Encoding: quoted-printable
Version: 5
Originator-ID-Asymmetric: MFMxCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJNRDEkMCIGA1UE
ChMbVHJ1c3RlZCBJbmZvcm1hdGlvbiBTeXN0ZW1zMREwDwYDVQQLEwhHbGVud29vZA=,02
MIC-Info: RSA-MD5,RSA,qJ8q9mzkH/B+/ntR3xFDwTCOKaIyvIAyPw0ZoseDSCMQ6uDXD9RE
n3QHrU5IGq1kK8bk4OU13TIh0ke7ZeRriCaypz25KoUGl9S6rUAsDSRo7De9K0FtJDzlJpnPhI
CB
------- =Signature Boundary--
I may have missed some subtleties about MIME, but you get the idea.
All the digest algorithms used by signatures in the
application/signature part need to be mentioned in the
application/digest-ids. Usually, there is only one. (NOTE: I am
going to change the Originator-ID-Asymmetric in the examples below,
but I left it here.)
2. Originator and Recipient Identifiers for Flexible Trust Models.
The current MIME/PEM draft (March 1994) uses the
Originator-ID-Asymmetric and Recipient-ID-Asymmetric fields as
defined in RFC 1421. However, this syntax enforces a model where
each user must have a certificate issuer in order to be identified,
and may be certified by one and only one issuer. Here are some
suggestions for originator and recipient identifiers to allow other
trust models.
Since a MIME signed and encrypted message encrypts all of the
signature information inside the encrypted content, it is not
compatible with the RFC 1421 ENCRYPTED process type which needs the
signature information in the clear. Since MIME is not compatible
with 1421 encrypted messages, we are free to indroduce changes
without worrying about backwards compatibility. I suggest changing
application/keys to use Recipient-Key-ID instead of
Recipient-ID-Asymmetric. For example:
Content-Type: application/keys; protocol="pem"
Content-ID: <1778(_dot_)762724901(_dot_)1(_at_)tis(_dot_)com>
Content-Transfer-Encoding: quoted-printable
Version: 5
DEK-Info: DES-CBC,933A1AB95512E140
Recipient-Key-ID: RSA-MD5, 786F6DAB337019BC6DF228A617D46A67
Key-Info: RSA,r8kCmWCqfe39FYybN7kTOPzVuCw4LXagpCdeYJcy942eKv2hXX8LkplY3f8Q
E3Z8gkBh3WZjNephpor4rul7UvlKW1t+/IHmcReiWRiwSiBwuuET3o7ScOMAbdZfe8vl
The Recipient-Key-ID field contains a digest algorithm identifer and
the digest of the DER encoding of the recipient's
SubjectPublicKeyInfo. The digest is encoded in hexadecimal. The
recipient identifier is only for the recipient to locate the Key-Info
which belongs to them. Since the recipient already knows their own
public key, it is a simple matter to locate its digest in the
Recipient-Key-ID field.
[NOTE: In an Internet draft, Steve Dusse and I proposed modifying RFC
1421 to use a Recipient-Key-Asymmetric which contained the
recipient's public key, not its digest. Using the digest for MIME is
an improvement suggested by Jeff Schiller.]
For signed messages, the Originator-ID-Asymmetric field presents the
problem that most certificate databases are indexed by subject name,
not issuer name. But an originator identifier by subject name must
also indicate which of the subjects possible public keys should be
used to verify the message. I suggest an Originator-Key-ID as follows:
Content-Type: application/signature; protocol="pem"
Content-ID: <1685(_dot_)762723090(_dot_)1(_at_)tis(_dot_)com>
Content-Transfer-Encoding: quoted-printable
Version: 5
Originator-Key-ID: X500, MFMxDzAJBgNVBAYTAlVTMQswCQYDVQQIEwJNRDEkMCIGA1UE
ChMbVHJ1c3RlZCBJbmZvcm1hdGlvbiBTeXN0ZW1zMREwDwYDVQQLEwhHbGVud29vyT=,
RSA-MD5, 786F6DAB337019BC6DF228A617D46A67
MIC-Info: RSA-MD5,RSA,qJ8q9mzkH/B+/ntR3xFDwTCOKaIyvIAyPw0ZoseDSCMQ6uDXD9RE
n3QHrU5IGq1kK8bk4OU13TIh0ke7ZeRriCaypz25KoUGl9S6rUAsDSRo7De9K0FtJDzlJpnPhI
CB
The Originator-Key-ID contains four fields: a name type identifier, the
subject's name, a digest algorithm ID, and the digest of the DER
encoding of the recipient's SubjectPublicKeyInfo. The digest is
encoded in hexadecimal. The name type identifier of X500 indicates
that the subject name is the DER encoding of the subject's
distinguished name. [This suggestion is due to Jeff Schiller: a
name type identifier of RFC822 would allow an email address for the
subject's name.]
The recipient uses the subject name to locate the originator's
certificate(s), perhaps in an X.500 directory, and then uses the
public key digest to filter out certificates with the wrong public
key.
Someone may say that the message should be more specific about
indicating exacly which certificate should be used in verifying the
message. I would argue that this information is not cryptograhically
protected. An attacker could substitute any certificate with a
public key which verifies the message signature. If there are
multiple certificates which the recipient trusts and they all have
the correct public key, then it is cryptographically ambiguous as to
which one applies. Presumably, the recipient should choose the most
recent certificate.
Summary.
In summary, for one-pass processing, put the application/keys before
the content and use an application/digest-ids for a signed message.
To allow other trust models, change Recipient-ID-Asymmetric to
Recipent-Key-ID, and Originator-ID-Asymmetric to Originator-Key-ID.
- Jeff