Without waiting for a last call for CMS-06, here are my comments:
On page 10, the text says ? The input to the signature validation
process includes the result of the message digest calculation process
and the signer?s public key?. This is not sufficient in order to give
the same and relaible result between two different implementations. The
knowledge of the certificate of the signer as well as the time of the
signature are both important. If there is an ambiguity on one or the
other component then the end-result can be different.
1) About the CertUid of the signer
Unless the unambiguous identifier of the certificate of the signer is
part of the signed attributes, attacks are possible. This is a weakness
of the original PKS-7 document that should be corrected.
This has already be advertised on the PKIX list and explained during the
last meeting in LA. This relates to the POP (Proof of Private key
possession) issue. In other words, using the certificate identifier from
the signer as an additional signed attribute is the only way to make
sure, and at the time the verification is performed, that the user
really has possession of the signing private key, whether or not the CA
has done POP correctly. This protects again a malicious CA that would
"forget" to make POP.
This discussion also relates about the way to uniquely identify a
certificate. From previous E-mail exchanges it has been demonstrated
that in some cases the hash of the issuer public key was a way to
discriminate between synonymous issuer names. Thus the syntax of the
certificate identifier should be extended to optionally support a hash
of the issuer key.
2) About the signature time
Unless the time is securely known (using a time stamp over the CMS
message), the time should be considered to be the time at which the
signer makes the verification. This means that different results may be
obtained since the signer?s certificate may have been revoked since the
signature was produced (see the recent E-mails exchanges on the mailing
list).
In order to care for these cases, the following text is proposed as an
addition after the first sentence of the section 5.6:
? The signer?s public key can be known in advance from the context. In
that case it is directly used. When this is not the case, it has to be
obtained from the information present in the message. The CertUid
present in the signed certificate shall be used for that purpose.
In order to make sure that the identified certificate is valid, e.g.
using CRLs and ARLs, it is important to know the status of the
certificate at the time the signature was performed. When that time
cannot be reliably known, then, by default, the current time shall be
used. It should be noticed that this can lead to different results
depending upon the time the validation is performed. When that time is
reliably known, e.g. using a time stamp over the CMS message, then that
time shall be used. It should be noticed that leads to the same result
whatever the time the validation is performed.?
The section 11 should be extended to add the "CertUid" as a "usefull"
attribute.
At the last meeting in LA, I explained during the S/MIME session why it
is important to allow for the presence of a CertUid as a signed
attribute. Refer to the slides that I presented. This section should be
expanded to allow that attribute to be included here, otherwise there
would be serious security problems.
Proposed text:
11.X Certificate Unique Identifier
The Certificate-Unique-Identifier attribute type specifies
unambiguously the certificate to be used for verifying the
signature, when it is not known otherwise from the context.
A Certificate-Unique-Identifier attribute must have a single
attribute value.
The following object identifier identifies the
Certificate-Unique-Identifier attribute:
id-certUid OBJECT IDENTIFIER ::= { iso(1) member-body(2)
XXXX }
Certificate-Unique-Identifier attribute values have ASN.1 type
CertUid:
CertUid ::= CertId
CertId ::= SEQUENCE {
issuerAndSerialNumber IssuerAndSerialNumber,
hashIssuerPublicKey HashIssuerPublicKey OPTIONAL}
The IssuerAndSerialNumber type identifies a certificate, and
thereby an entity and a public key, by the name of the certificate
issuer and an issuer-specific certificate serial number.
The hashIssuerPublicKey allows to discriminate between two CAs
that would have the same issuer name. Should that situation happen,
then the two CAs would have different public keys. The hash of the
public keys would thus be different.
HashIssuerPublicKey ::= SEQUENCE {
hashOid ObjectIdentifier,
hashedIssuerPublicKey OCTET STRING}
On page 5, there is a sentence stating: ?The signer?s certificate may be
included in the SignedData certificates field?. It is not clear why the
whole certificate should be included. The CertUid (or CertID) would be
sufficient. If the full certificate is needed it does not need to be
part of the signed attributes (note that it is not part of the list of
?useful attributes? described in the section 11).
Finally. At this time, the specification mandates for the use of DNs for
issuers. This question is being debated in the PKIX group. It would
seems more appropriate to write this specification in a way that would
be independent from the final resolution on this topic. In other ways,
the document should avoid to say whether a DN or an alternate name is
being used for the issuer.
Denis
--
Denis Pinkas Bull S.A.
mailto:Denis(_dot_)Pinkas(_at_)bull(_dot_)net
Rue Jean Jaures B.P. 68 Phone : 33 - 1 30 80 34 87
78340 Les Clayes sous Bois. FRANCE Fax : 33 - 1 30 80 33 21