Dear all,
I have substantive comments that were initially raised during the S-MIME WG last call
(December 1, 2006) and that have not been incorporated into the draft.
The major issue is that the draft is proposing to state:
(...) the successful validation of one signature associated with each signer is usually treated
as a successful validation of the signed-data content type.
and also :
(...) the successful validation of one of signature from each signer ought to be
treated as a successful validation of the signed-data content type.
The CMS specification should not attempt to enter the area of the "validation of the signed-data content type".
Validity of the signed-data content type would imply validation of its semantics, whether it is signed by
the right entities or not, whether it is counter-signed by the right entities or not, etc ...
CMS should continue to restrict the topic of the validation of digital signatures signer by signer.
Digital signature validation occurs signer by signer, independently of any other signer.
Russ, one of the security area directors, responded on the list :
"The message is valid if one signature from each signer is valid".
This illustrates the misunderstanding.
We cannot say :"the mesage is valid if ", but
we should say :"the message is validly signed by one signer, if any of the signatures from that signer is valid".
The next issue is that before clarifying what we should do to verify a digital signature
when there are multiple signatures from the same signer, it is more important to clarify
what to do to verify a single signature. The current text is not precise enough.
Since it is proposed to clarify the text on validation, such a clarification should be made at the same time.
I have posted to the S-MIME Mailing list proposals to improve the text. There has been no response to to this proposal.
The latest strawman proposal is copied below :
"A recipient verifies a signature in the following way :
It MUST first identify the signer's public key to be used for the
verification. The signer's public key is referenced in the sid
value either by an issuer distinguished name along with an
issuer-specific serial number or by a subject key identifier that
identifies the certificate containing the public key. If the
essCertID signed attribute is present, then the public key
contained in the referenced certificate shall be used. The
signer's certificate may be included in the SignedData certificates
field.
It MUST verify that the signatureAlgorithm indicated in the
SignerInfo value is compatible with the digestAlgorithm indicated
in the SignerInfo value and the algorithm contained in the
subjectPublicKeyInfo from the signer?s certificate.
The following examples are provided:
- if the signatureAlgorithm is sha-1WithRSAEncryption, then the
digestAlgorithm must be id-sha1 and the algorithm contained in
the subjectPublicKeyInfo must be rsaEncryption.
- if the signatureAlgorithm is id-RSASSA-PSS, then the
hashAlgorithm included in the RSASSA-PSS-params must be the
same as the one indicated in the digestAlgorithm field from
SignerInfo. The algorithm contained in the subjectPublicKeyInfo
must either be id-RSASSA-PSS with the same parameters as those
indicated in the signature algorithm or be rsaEncryption.
It MUST then use the specific digestAlgorithm indicated in the
SignerInfo value to compute a digest and the signatureAlgorithm
indicated in the SignerInfo value with to verify the signature
value, as defined in Section 5.3.
In addition, it MUST verify that the strength and key size of
these algorithms are conformant with the security policy, otherwise
it shall discard the signature.
A given signer may apply more than one signature. This may be
useful in particular when some recipients are unable to process
some algorithms during an algorithm migration phase".
Then we could add:
"The signed-data content type is validly signed by one signer, if any
of the digital signatures from that signer is verified as valid".
Denis
>The IESG has received a request from the S/MIME Mail Security WG (smime)
>to consider the following document:
>
>- 'Cryptographic Message Syntax (CMS) Multiple Signer Clarification '
> <draft-ietf-smime-cms-mult-sign-02.txt> as a Proposed Standard
>
>The IESG plans to make a decision in the next few weeks, and solicits
>final comments on this action. Please send substantive comments to the
>ietf@xxxxxxxx mailing lists by 2007-02-12. Exceptionally,
>comments may be sent to iesg@xxxxxxxx instead. In either case, please
>retain the beginning of the Subject line to allow automated sorting.
>
>The file can be obtained via
>http://www.ietf.org/internet-drafts/draft-ietf-smime-cms-mult-sign-02.txt
>
>
>IESG discussion can be tracked via
>https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=14620&rfc_flag=0
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf