ietf-smime
[Top] [All Lists]

Mime types and parameters for certs-only message

1997-05-12 11:20:07
The current draft uses the MIME type application/pkcs7-mime for four
different things: signed-only, enveloped-only, cert-only and
signedAndEnveloped. There is no way from the MIME information to determine
which a message might be. You have to parse the PKCS7 to find out.

There are some reasons for bringing this information up to the MIME type
level which I'll mention below. The basic reason is that MIME type
information is already easily available in many implementations and it's
widely used to invoke viewers, display icons, etc.  A very good example is
IMAP where you can fetch the MIME information without the whole body.

To make this available in the MIME type, I suggest adding a MIME parameter
to the application/pkcs7-mime type. We can call it "smime-type", and it can
have the four values I mentioned above. The nice thing about a parameter is
that they are always ignored if not understood, thus nothing will break by
its addition. The bad thing about a parameter is that many MIME
implementations can switch viewers only on the MIME type, and not on the
parameters. However I think introducing new MIME types at this point would
be too traumatic.

To give a few reasons why this is important:

If you subscribe to a CA service which e-mails you certs and crls for
people you're interested in you want to process those before you process
any of the signed messages. That way you'll find out that a cert was
revoked before you sign the contract just e-mail to you, rather than after.
By having the type info in the MIME type it's easier to process the
certs-only messages first.

The IMAP case is also interesting. IMAP users often want to optimize
bandwidth use by fetching only MIME parts that they need at the moment.
Thus an IMAP user that is missing their private key because they left their
smartcard in the last city might not want to download encrypted messages.
Without putting the type of message in the MIME type info, they can never
know the type without downloading the whole part.

A gateway may want to pre-check signatures on all incoming e-mail as a
service to people behind the gateway. Most gateways are MIME aware, but not
PKCS7 aware. They are more likely to invoke separate PKCS7 applications to
do the work. Thus having labeling in the MIME type will significantly
increase the efficiency of the gateway.

Another application may just want to display a different icon for different
MIME types as an aid to the user, and the application doing this should not
have to understand PKCS7.

I think one of the core reasons for having this sort general mechanism in a
spec we expect to be used for years in the future is that we can't think of
all the possibilities now. The cost to enable greater possibilities in the
future is small with features like this.

LL



<Prev in Thread] Current Thread [Next in Thread>