I propose that the micalg parameter for multipart/signed messages with the "application/pkcs7-signature" protocol be defined as pkcs7-md5 and pkcs7-sha1 for the MD5 and SHA-1 digest algorithms respectively. I further propose that any future digest algorithms that are supported for S/MIME keep the "pkcs7-" prefix. Comments? Blake
After reviewing the draft informational rfc for PKCS #7 at http://www.imc.org/draft-hoffman-pkcs-crypt-msg, I believe... Keeping future S/MIME digest algorithms with the "pkcs7-" prefix is fine, but will PKCS #7 undergo any changes to allow for additional... 1. Public-Key algorithms, (elliptic curve, DSA-ElGamal,...) or will S/MIME be RSA (asymmetric) forever? 2. ContentEncryptionAlgorithmIdentifier ::= "for EP2 / as well as RC2" cb At 11:09 PM 6/1/97 -0700, Blake Ramsdell wrote: >I propose that the micalg parameter for multipart/signed messages with >the "application/pkcs7-signature" protocol be defined as pkcs7-md5 and >pkcs7-sha1 for the MD5 and SHA-1 digest algorithms respectively. I >further propose that any future digest algorithms that are supported for >S/MIME keep the "pkcs7-" prefix. > >Comments? > >Blake > >
On Monday, June 02, 1997 10:29 AM, Charles Breed [SMTP:cbreed <at> pgp.com] wrote: > Keeping future S/MIME digest algorithms with the "pkcs7-" prefix is fine, but > will PKCS #7 undergo any changes to allow for additional... > > 1. Public-Key algorithms, (elliptic curve, DSA-ElGamal,...) or will S/MIME be > RSA (asymmetric) forever? Both of these can definitely be defined in an alternative interoperability profile (as an informational RFC, perhaps). I'm not sure they fit into the base interoperability profile, since the goal of that is to provide the minimum required for interoperability. Blake
> I propose that the micalg parameter for multipart/signed messages with > the "application/pkcs7-signature" protocol be defined as pkcs7-md5 and > pkcs7-sha1 for the MD5 and SHA-1 digest algorithms respectively. I > further propose that any future digest algorithms that are supported for > S/MIME keep the "pkcs7-" prefix. Why? What technical purpose would be served by doing this? Keith
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! Keith
On Monday, June 02, 1997 2:46 PM, Keith Moore [SMTP:moore <at> cs.utk.edu] wrote: > > I propose that the micalg parameter for multipart/signed messages with > > the "application/pkcs7-signature" protocol be defined as pkcs7-md5 and > > pkcs7-sha1 for the MD5 and SHA-1 digest algorithms respectively. I > > further propose that any future digest algorithms that are supported for > > S/MIME keep the "pkcs7-" prefix. > > Why? What technical purpose would be served by doing this? Good point, and I just found out the answer myself. I have been keeping track of some of the other mailing lists, and this issue is being debated this very moment on IETF-PGP-MIME at the IMC. Ned Freed summarized it this way (my apologies if the citation out of context is inappropriate -- the whole message is on IETF-PGP-MIME): Ned Freed said: > > I note in passing that there is some confusion about the interpretation of > micalgs. The answer to this is simple: Micalgs names are pure names. You cannot > assume anything from the name unless you recognize it in its entirety; it is > quite possible for a micalg name to include the string "md5" yet not use the > MD5 hash, and it is also possible for a micalg to not include the string "md5" > yet use MD5. The fact that micalg names appear to be composite is simply an > artefact of our attempts to make them humand-readable; it is nothing a machine > should rly on.(Continue reading)
On Monday, June 02, 1997 3:05 PM, Keith Moore [SMTP:moore <at> cs.utk.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:(Continue reading)
[I've had quite a few requests for this so I'm sending this annoucement to the
three most appropriate lists, apologies if you see it more than once]
I've just updated my ASN.1 dump/diagnostic utility to handle the BER a bit
better, which means you can now display things like PKCS #7 objects and (in
general) anything else which mixes BER and DER-encoded data. The program is
aware of most of the common crypto-related object identifiers and types, so
it'll give you a proper description of what it is you're looking at. Here's
some sample output from the start of a cert:
0 30 618: SEQUENCE {
4 30 467: SEQUENCE {
8 2 4: INTEGER 830525701
14 30 13: SEQUENCE {
16 6 9: OBJECT IDENTIFIER
: md5withRSAEncryption (1 2 840 113549 1 1 4)
27 5 0: NULL
: }
29 30 125: SEQUENCE {
31 31 11: SET {
33 30 9: SEQUENCE {
35 6 3: OBJECT IDENTIFIER countryName (2 5 4 6)
40 13 2: PrintableString 'Ca'
: }
: }
[etc]
Hopefully the program will prove useful for picking apart certs and data
objects for debugging and diagnostic purposes, especially now that it handles
BER data properly. You can get it from
(Continue reading)
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. Oh. *that's* fine with me. I just don't want to constrain S/MIME to always use pkcs7 if something else turns out to be better. Keith
> From: pgut001 <at> cs.auckland.ac.nz (Peter Gutmann)
> To: ietf-pkix <at> tandem.com, ietf-smime <at> imc.org, ssl-talk <at> netscape.com
>
> I've just updated my ASN.1 dump/diagnostic utility to handle the BER a bit
> better, which means you can now display things like PKCS #7 objects and (in
> general) anything else which mixes BER and DER-encoded data. The program is
> aware of most of the common crypto-related object identifiers and types, so
> it'll give you a proper description of what it is you're looking at. Here's
> some sample output from the start of a cert:
>
> 0 30 618: SEQUENCE {
> 4 30 467: SEQUENCE {
> 8 2 4: INTEGER 830525701
> 14 30 13: SEQUENCE {
> 16 6 9: OBJECT IDENTIFIER
> : md5withRSAEncryption (1 2 840 113549 1 1 4)
> 27 5 0: NULL
> : }
> 29 30 125: SEQUENCE {
> 31 31 11: SET {
> 33 30 9: SEQUENCE {
> 35 6 3: OBJECT IDENTIFIER countryName (2 5 4 6)
> 40 13 2: PrintableString 'Ca'
> : }
> : }
> [etc]
Peter,
Thanks for publicising the program, making it available on your
(Continue reading)
RSS Feed9 | |
|---|---|
3 | |
7 | |
1 | |
1 | |
1 | |
2 | |
7 | |
8 | |
5 | |
13 | |
7 | |
7 | |
2 | |
7 | |
11 | |
21 | |
6 | |
11 | |
6 | |
3 | |
9 | |
1 | |
3 | |
8 | |
6 | |
8 | |
31 | |
23 | |
24 | |
10 | |
81 | |
76 | |
19 | |
37 | |
34 | |
27 | |
23 | |
30 | |
79 | |
20 | |
41 | |
24 | |
33 | |
27 | |
33 | |
41 | |
24 | |
30 | |
20 | |
25 | |
34 | |
59 | |
19 | |
13 | |
59 | |
27 | |
24 | |
12 | |
2 | |
3 | |
6 | |
10 | |
21 | |
17 | |
20 | |
1 | |
8 | |
17 | |
17 | |
3 | |
10 | |
6 | |
16 | |
16 | |
3 | |
2 | |
2 | |
30 | |
15 | |
10 | |
9 | |
7 | |
72 | |
20 | |
33 | |
22 | |
23 | |
35 | |
54 | |
9 | |
9 | |
13 | |
13 | |
34 | |
14 | |
74 | |
53 | |
54 | |
34 | |
22 | |
26 | |
22 | |
15 | |
11 | |
9 | |
30 | |
24 | |
38 | |
31 | |
14 | |
36 | |
30 | |
31 | |
29 | |
6 | |
44 | |
14 | |
60 | |
61 | |
78 | |
118 | |
25 | |
29 | |
61 | |
34 | |
38 | |
29 | |
29 | |
68 | |
21 | |
21 | |
52 | |
23 | |
43 | |
65 | |
34 | |
41 | |
40 | |
4 | |
30 | |
64 | |
41 | |
23 | |
45 | |
50 | |
37 | |
44 | |
26 | |
78 | |
113 | |
71 | |
95 | |
113 | |
74 | |
96 | |
55 | |
74 | |
50 | |
155 | |
161 | |
248 | |
233 | |
163 | |
152 | |
306 | |
64 | |
72 | |
17 | |
88 | |
21 | |
53 | |
123 | |
2 | |
2 | |
17 | |
2 |
