On Monday, June 02, 1997 3:05 PM, Keith Moore
[SMTP:moore(_at_)cs(_dot_)utk(_dot_)edu]
wrote:
I can see using a "pkcs7-" prefix for anything that uses pkcs7, and
I understand that micalgs have sometimes been specific to a particular
protocol. But I can't see any reason to require that all future
S/MIME micalgs use pkcs7.
It would seem far more desirable to move toward protocol-independent
micalgs, so that a message can be signed with a single micalg
but using more than one signature protocol. If I could sign the
same message with both PGP and S/MIME, then a lot more people could
verify that I signed it!
Oh, man, get over to IETF-PGP-MIME as soon as you can and check out the
messages about this. This exact discussion has been progressing with
input from both Ned Freed and Jim Galvin. The separation between the
definition of micalg and protocol is being discussed, as well as the use
of multiple values for each of those parameters.
The point has come up that supplying multiple values for the micalg and
protocol parameters could be a useful construct, and that in the event
multiple signatures from different protocols are desired, that the
second part of multipart/signed could contain all of those signatures
(my suggestion was to use multipart/alternative to further enforce the
semantics that they are equivalent signatures using different
protocols.)
For instance (the example I used from there):
Content-Type:
multipart/signed;micalg="rsa-md5;pgp-md5;pkcs7-md5";protocol="applicatio
n/moss-signature;application/pgp-signature;application/x-pkcs7-signature
";boundary="a"
-a
< first part of multipart/signed goes here>
-a
Content-Type: multipart/alternative;boundary="b"
-b
Content-Type: application/moss-signature
<MOSS signature goes here>
-b
Content-Type: application/pgp-signature
<PGP signature goes here>
-b
Content-Type: application/x-pkcs7-signature
<S/MIME signature goes here>
-b-
-a-
With the same disclaimer I used over there -- the MIME might be broken,
but the concept still remains.
The point that I was making for future micalgs about having the pkcs7-
prefix was to make sure that if PKCS #7 was still the underlying message
format, then any future digest algorithms would use the pkcs7- prefix to
make sure they kept the association with the protocol. Certainly if
there is an evolutionary turn that causes PKCS #7 *not* to be underneath
it all, then the pkcs7- would be nothing more than nostalgic...
Blake