Denis:
>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 ?
You did not acknowledged that this is the goal of the draft
proposal.
>
>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.
When CMS was first adopted by the S/MIME
WG, we decided to keep the
specification as close to the structure of PKCS
#7 v1.5 as
possible. The idea was to make it easy for one to determine the
differences. I see no reason why this discussion ought to change
that
decision.
The text from PKCS # 7 v1.5 is:
A recipient verifies the signatures by
decrypting the encrypted message digest
for each signer with the signer's
public key, then comparing the recovered message
digest to an
independently computed message digest. The signer's public key is
either
contained in a certificate included in the signer information, or is
referenced
by an issuer distinguished name and an issuer-specific serial
number that uniquely
identify the certificate for the public
key.
The text from RFC 3852 is:
A recipient independently computes the message digest. This message digest and
the signer's public key are used to verify the
signature
value. The signer's public
key
is referenced either by an issuer distinguished
name along with an issuer-specific
serial number or by a subject key identifier that uniquely identifies the certificate
containing the public key. The signer's certificate can be
included in the SignedData
certificates
field.
These texts are clearly insufficient, since they do not
cover the case of certificate substitution.
The new draft is wishing to cover the case of
signatures from the same signer.
It is restricted to the use of certificates. Then
the only way to know that is is the same signer
is to compare the
certificates. We should say some words on how this
comparison shall be done.
If certificates are substituted, then we are also
running into trouble.
>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.
I recognize that this is true. That is the reason that the
proposed
text points to the application that is using CMS to help when the
sid
field is not sufficient.
The proposed text is clearly insufficient to cover the
case.
The second point, which is even more important, is that I am
not convinced
that this is the right way to solve the
problem.
If the certificate is used for non repudiation purposes,
then time-stamping provides
all the necessary protection.
If the certificate is used for authentication purposes,
then the signers' certificate can simply be changed.
Denis
Russ