Russ,
The main message that I extracted from your e-mail is the following :
"What text needs to be added to the document ?
I am willing to consider additional text, but so far, I do not see a need".
I spent several hours working on a suitable text. You will find herafter my
proposed
replacements for the two text replacements.
First replacement:
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, e.g. if the
signatureAlgorithm is sha-1WithRSAEncryption then the
digestAlgorithm must be id-sha1 and the algorithm contained in the
subjectPublicKeyInfo must be rsaEncryption. In addition, it must
verify that the strength and key size of these algorithms are
conformant with its local security policy, otherwise it shall
discard the signature.
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.
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.
Second replacement:
signerInfos is a collection of per-signer information. There MAY
be any number of elements in the collection, including zero. In
order to determine whether some signatures were generated by the
same signer, the simple matching of the signer identifier may first
be used. However, it is only appropriate when the same signature
algorithm and key size is being used with a different digest
function. An additional means, is to check whether the subject
field and the issuer field from two signer?s certificates are the
same and relate to the same superior CA. The latter situation may
happen, for example, when the signed-data content type includes
signatures generated with the RSA signature algorithm and with the
ECDSA signature algorithm and when the certificates are issued by
the same CA. When the signer?s certificates are not issued by the
same CA and if they contain a permanent identifier field, then it
is possible to check whether two certificates relate to the same
signer.
The successful validation of one signature from the same signer
which conforms to the local security policy, ought to be treated as
a successful validation of the signed-data content type for that
signer.
The details of the SignerInfo type are discussed in section 5.3.
Since each signer can employ a different digital signature
technique and future specifications could update the syntax, all
implementations MUST gracefully handle unimplemented versions of
SignerInfo. Further, since all implementations will not support
every possible signature algorithm, all implementations MUST
gracefully handle unimplemented signature algorithms when they are
encountered.
A few explanations.
1 - The current explanations from CMS (in fact from PKCS#7) are far
insufficient to provide
sufficient guidance for a correct verification. This needed to be fixed and has
been fixed in
the first text proposal.
2 - In the second text replacement, I have detailed the verification process so
that a recipent may know
that two signerInfo relate to the same signer.
3 - The key sentence from the draft I cannot agree with is the following:
When the collection represents more than one signature, the successful
validation of one of signature from each signer ought to be treated
as a successful validation of the signed-data content type.
This sentence speaks about a global validation of a signed document that would
be valid,
if every signer placed one correct signature. However, with CMS signatures are
verified one by one.
There is no notion of the validation of a document by multiple signers.
This sentence has been replaced with :
The successful validation of one signature from the same signer
which conforms to the local security policy, ought to be treated as
a successful validation of the signed-data content type for that
signer.
Denis
Denis:
I do not know how to constructively continue this discussion. We do not seem
to be communicating with each other.
Trying one more time... See below.
[Russ]
Denis:
We are talking about signatures on CMS object, not signatures on
certificates. The recipient of the signed CMS object needs to be
able to validate the signature on the certificate as well as the CMS
signed object.
If the signer has a certified RSA public key, then the signer can
sign a CMS object using both RSA with SHA-1 and RSA with
SHA-256. Each one will be a SignerInfo, and the sid (using either
the issuerAndSerialNumber or the subjectKeyIdentifier) in each of
them will identify the same certified public key.
[Denis]
If the algorithm is "RSA" rather than "a hash function + RSA", then it works.
However, this kind of explanation is lacking in the current draft.
In most certificates used for S/MIME today, the subject public key identifier
contains the algorithm identifier listed in 2.3.1 of RFC 3279:
The OID rsaEncryption identifies RSA public keys.
pkcs-1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
rsadsi(113549) pkcs(1) 1 }
rsaEncryption OBJECT IDENTIFIER ::= { pkcs-1 1}
Then, the CMS SignerInfo indicates RSA as well as the one-way hash function
that is used for the encapsulated content. These are the OID that I found in
the RFCs:
md2WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 2 }
md5WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 4 }
sha-1WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 5 }
sha224WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 14 }
sha256WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 11 }
sha384WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 12 }
sha512WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 13 }
The certificate does not require the subject public key to be used with any
particular one-way hash function, but the signature itself tells which one-way
hash function way employed by the signer. None of this is new!
What text needs to be added to the document? I am willing to consider
additional text, but so far, I do not see a need.
[Russ]
If the RSA public key is placed in two certificates, one signed by
the CA using RSA with SHA-1 and the other signed by the CA using RSA
with SHA-256, then you get a better situation from a cryptographic
strength perspective. However, the subject key identifier will be
the same in both certificates, which allows the recipient to easily
detect that the signatures are from the same signer if that form of
sid is used. Which is the one that S/MIME has been encouraging for
quite some years, mostly due to size.
[Denis]
I disagree. RFC 3280 states:
4.2.1.2 Subject Key Identifier
The subject key identifier extension provides a means of identifying
certificates that contain a particular public key.
(...)
For end entity certificates, subject key identifiers SHOULD be
derived from the public key.
You did not quote the part of Section 4.2.1.2 of RFC 3280 that describe the
most commonly used technique for computing a key identifier:
(1) The keyIdentifier is composed of the 160-bit SHA-1 hash of the
value of the BIT STRING subjectPublicKey (excluding the tag,
length, and number of unused bits).
If the two certificates contain the same RSA public key, then this value will
most certainly be the same!
Since the public keys will be different, the subject key identifiers will NOT
be the same in both certificates.
Again, if the two certificates contain the same RSA public key, then this value
will most certainly be the same! You seem to be making some unstated
assumptions about certification policies.
If the certificates are issued by the same CA, the subject field from the
certificate would normally be the same.
If the certificates are not issued by the same CA, the permanent identifier, if
present would help.
These kinds of explanations are lacking in the current draft.
I am not trying to distinguish the certificates. The issuer and serial number
would allow me to do that.
At this point, I do not know what else to say. I am going to leave it to the
S/MIME WG Chairs to determine what changes, if any, are needed to resolve your
Last Call comment.
Russ