Russ,
The issue is more complex than presented. :-(
The idea is to say that a message is correctly signed by a given signer, if one
of the signatures
from the *same* signer computed using a different signature algorithm is valid.
Correct ?
In the same section from RFC 3852, just above we have:
" The process by which signed-data is constructed involves the
following steps:
1. For each signer, a message digest, or hash value, is computed
on the content with a signer-specific message-digest algorithm.
If the signer is signing any information other than the
content, the message digest of the content and the other
information are digested with the signer's message digest
algorithm (see Section 5.4), and the result becomes the
"message digest."
2. For each signer, the message digest is digitally signed using
the signer's private key.
3. For each signer, the signature value and other signer-specific
information are collected into a SignerInfo value, as defined
in Section 5.3. Certificates and CRLs for each signer, and
those not corresponding to any signer, are collected in this
step.
4. The message digest algorithms for all the signers and the
SignerInfo values for all the signers are collected together
with the content into a SignedData value, as defined in Section
5.1".
We should have a similar construct for verification, but we don't.
It should start with:
The process by which signed-data is verified involves the
following steps:
1. For each SignerInfo present in SignerInfos ...
The exercise is more difficult than it looks, because unless ESSCertID is being
used,
it is not possible to know for sure that a signature is from the same signer.
Denis
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the S/MIME Mail Security Working Group of the
IETF.
Title : Cryptographic Message Syntax (CMS) Multiple Signer
Clarification
Author(s) : R. Housley
Filename : draft-ietf-smime-cms-mult-sign-02.txt
Pages : 5
Date : 2006-11-9
This document updates the Cryptographic Message Syntax (CMS), which
is published in RFC 3852. This document clarifies the proper
handling of the SignedData protected content type when more than one
digital signature is present.
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-smime-cms-mult-sign-02.txt
To remove yourself from the I-D Announcement list, send a message to
i-d-announce-request(_at_)ietf(_dot_)org with the word unsubscribe in the body
of
the message.
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.
Internet-Drafts are also available by anonymous FTP. Login with the
username "anonymous" and a password of your e-mail address. After
logging in, type "cd internet-drafts" and then
"get draft-ietf-smime-cms-mult-sign-02.txt".
A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
Internet-Drafts can also be obtained by e-mail.
Send a message to:
mailserv(_at_)ietf(_dot_)org(_dot_)
In the body type:
"FILE /internet-drafts/draft-ietf-smime-cms-mult-sign-02.txt".
NOTE: The mail server at ietf.org can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e. documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
Content-Type: text/plain
Content-ID: <2006-11-9160843(_dot_)I-D(_at_)ietf(_dot_)org>
ENCODING mime
FILE /internet-drafts/draft-ietf-smime-cms-mult-sign-02.txt
Regards,
Denis Pinkas