ietf-smime
[Top] [All Lists]

Re: Last Call Comments on CMS-10

1999-01-19 09:47:26
Russ,

As advertised at the last IETF meeting in Orlando, I have a comment on the
lastest version of the CMS draft published.

On page 12, in the section 5.6  Message Signature Validation Process 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?.

The problem is how to get the right signer?s public key and how to know that is
valid or not. If no indication is given, then different results will be obtained
between different implementations. The process is thus much more complicated
than currently indicated as this is explained later on.

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 may be quite the opposite.

The certificate is important because a user might use the same public key for
different certificates which include different attributes. In such a case it is
important to know which certificate has been selected by the signer.

The time of the signature is important because the certificate may have been
revoked since the document was signed and thus it is important to verify that
the certificate was valid when the document was signed.

In order to care for these cases, the following text is proposed for section
5.6:

 ? When a signed CMS structure is received, it is important to know who the
signer is and whether the digital signature valid or not. The certificate allows
to identify the signer and possibly some other attributes. A signer may have
multiple certificates, e.g. with the same public key in it. In such a case,
these certificates will have different security attributes in it. It is thus
important to know which certificate has been selected by the signer.

The time of the signature is important because the certificate may have been
revoked since the document was signed and thus it is important to verify that
the certificate was valid when the document was signed.

This means that the certificate to be used for the verification process has to
be verified as valid, i.e. before verifying that the result of the message
digest, the digital signature and the signer?s public key match altogether.

Two cases may be considered:

1) the certificate of the signer is already securely known in advance from the
context and is checked to be valid according to a security policy (i.e. not
individually revoked and the trusted path not revoked as well). In that case it
may be used directly and the public key may be extracted out of it and used as
an input to the verification process.

2) Neither the certificate of the signer,  nor the signature time are known in
advance from the context.. In such a case it is needed to obtain all the
information, i.e. both the certificate of the signer and the correct signing
time, from the data that has been received, in particular from the CMS
structure.

The SignerIdentifier may be used to obtain the right certificate. In some cases
that information may however be insufficient or/and insecure (see [ESS], section
5.4) and the ESSCertId signed attribute shall be used in addition.

If the signer?s certificate and all the cross-certificates from the
certification path are all valid (e.g. not on the appropriate certificate
revocation list (CRL) or authority  revocation list (ARL) or a « not revoked »
status is given back by an OCSP server) and during their validity period at the
time the verification is made, then the public key may be used as an input to
the signature verification process. Otherwise the signature is said to be
invalid.

If the signer?s certificate has been revoked but all the cross-certificates from
the certification path are valid (e.g. at the time the verification is made,
then additional information is needed to know whether the certificate may be
used or not. It is then needed to verify that the signer?s certificate was valid
at the time the signature was made. The signing-time attribute, when present,
may only be used as an hint, since it only specify the time at which the signer
(purportedly) performed the signing process. The time contained in a time stamp
over the CMS structure from a TSA (Time Stamping Authority) will be needed to
know whether or not the certificate was revoked at the time the signature was
made. If the time from the time stamping authority is prior to the reviocation
of the signers? certificate then the public key may be used as an input to the
signature verification process. Otherwise the signature is said to be invalid.

If one of the cross-certificates is revoked, a time stamp prior to the
revocation of that cross-certificate shall be obtained for that
cross-certificate (or alternatively on the whole certification path). This will
prove that the cross-certificate was valid before the revocation (or even the
key compromise) of that CA. If it is missing, the signature is said to be
invalid.

The input to the signature verification process includes the result of the
message digest calculation process and the signer's public key. The details of
the signature verification depend on the signature algorithm employed.

The recipient may not rely on any message digest values computed by the
originator.  If the signedData signerInfo includes signedAttributes, then the
content message digest must be calculated as described in section 5.4.  For the
signature to be valid, the message digest value calculated by the recipient must
be the same as the value of the messageDigest attribute included in
thesignedAttributes of the signedData signerInfo. »


Denis




<Prev in Thread] Current Thread [Next in Thread>