At 11:10 AM 5/12/97 -0700, Laurence Lundblade wrote:
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.
Are the four values specified above a suitable abstraction. For example, if
I want to publish a certificate to an LDAP repository (or similar), I may
want to send a PKCS7 certs-only message, with the certificate to be
published. I would like the receiving application to know that this was a
certificate publish request, as opposed to a response to a PKCS10
certificate request.
Does this require a new mime type, (eg pkcs7-publish-request), or could
this be embedded in the smime-type parameter proposed above. If it is to be
embedded in a smime-type parameter, then certs-only is not specific enough.
Graham