ietf-smime
[Top] [All Lists]

Re: 8/26/98 S/MIME WG Minutes

1998-09-28 03:09:19
Dr Stephen Henson has sent a few comments:

A few comments.

John Pawling wrote:


Slide #3: Signature Algorithms:

DSA-with-SHA1 is mandatory to implement.  The attendees decided that the CMS
I-D will state that the parameters must be absent (not ASN.1 NULL).  This is
required for consistency with PKIX Part I.


I presume it is implied that a NULL parameter should be tolerated. I
know of some implementations that generate NULL.


Slide #8: Content Encryption Algorithms 2: The group decided that CMS will
document RC2 in CBC mode as a "should" to implement (rather than "may").
The RC2-CBC OID will be used.


Will this include the number of bits that may/should be supported as
well?


1) Denis Pinkas asked if there was a way to verify the "correctness" of a
CMS message.  Denis considers signature generation time to be a critical
factor in determining whether or not that signature is valid.  If the
signing key is revoked, then the signing time would indicate if the message
signed before or after the revocation date.  John Pawling pointed out that
the MSG I-D already states that the signingTime attribute should always be
included in signed messages.  The attendees agreed that wording was 
sufficient.


IMHO this may need an additional comment.

Well, I don't think that "the attendees agreed that wording was sufficient" is 
the
right wording since I said during the last session in Chicago, that I would
reformulate a message sent on July 15, about :

1) the signature generation time,
2) the identification of the certificate.

The first item is precisely the topic raised by Stephan.

In the original message I was going straight to text replacement proposals with
insufficient explanations. Hereafter more explanations are provided, but, as
advertised, the text will be much longer. :-(

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?.

There is no information given here on the process by which the signer's public 
key is
obtained. If a wrong public key or a revoked key is being used, then the end 
result
of the verification process will be erroneous.

CMS can be used with real time communications or with store and forward 
environments,
i.e. within or without a S/MIME context. With real time communications, the 
signer?s
public key is either known from the context or will be extracted from the CMS 
syntax.
With store and forward environments, it is always be extracted from the CMS 
syntax.
This is where the danger lies.

It seems natural to use the issuerAndSerialNumber from the SignerInfo. The 
danger of
using it directly, without any additional control, is mentioned partly (i.e. 
one half
of it) in the document draft-ietf-smime-sigattr-01.txt [SIGATTR]... but no 
reference
is made to this document in CMS.

The danger here is to substitute a certificate by another one that would 
contain the
same public key value, since the issuerAndSerialNumber from the SignerInfo is 
NOT
part of the signature process. That situation may arise at least in two 
occasions:
the user has multiple certificates for the same public key from different CAs 
or a
malicious CA issues a certificate for a different entity while copying the 
public key
from another certificate. In the first case, a certificate that is different 
from the
certificate intended to be used by the signer is presented to the verifier, 
while in
the second case some "bad" CAs, i.e. omitting to perform POP -Proof of 
Possession of
the private key, cannot be detected. Full details are in [SIGATTR].

Substitutions can be detected by signing a Certificate Identifier.

However this is still insufficient to address the issue. The second part of it 
has to
do with key compromise. If a key is compromised, then the corresponding 
certificate
will be revoked. It is important to know if the certificate was revoked or not 
AT THE
TIME OF THE SIGNATURE. If it is not possible to know the time of the signature, 
then
unpredictable results may occurs in case of key compromise.

Although  John [Pawling] pointed out that the MSG I-D already states that the
signingTime attribute should always be included in signed messages, CMS can be 
used
in wider environments and thus people looking at CMS will not necessarily look 
at the
MSG I-D.

In addition, there are two unsolved problems with this approach:

1) the signingTime attribute alone does NOT solve the issue,
2) the current text of CMS is misleading on this issue. The current text of 
section
11.3 on page 29 says:

" No requirement is imposed concerning the correctness of the signing time, and
acceptance of a purported signing time is a matter of a recipient's discretion. 
 It
is expected, however, that some signers, such as time-stamp servers, will be 
trusted
implicitly."

The signingTime attribute only reflects the time the signer wanted to be 
included.
The signer may well pre-date that value, ... but more important, if the key of 
the
signer is compromised then an attacker may also pre-date that value. In such a
situation it cannot be made a difference between a past "honest" signature from 
the
right signer and a pre-dated "fake" signature from an attacker. This difference 
is
not important when CMS is used in real time contexts since the latest CRL or
equivalent will be used. However, if CMS is used in non repudiation contexts, 
then it
is important to be able to settle the dispute. The use of a Time Stamping 
Server can
then allow to make the difference between "good" and "fake" signatures.

Since CMS will be used in S/MIME environments but also in non-S/MIME 
environments as
a successor of PKS#7, we have two options either correct the text in the 
section 5.6
and 11.3 (on page 29) or provide more awareness in the "Security consideration
section" on page 40.

If the first option is chosen, then here is a full text replacement for that 
section:

" 5.6  Message Signature Validation Process

The input to the signature validation process includes the result of the message
digest calculation process and the signer's public key. It is fairly important 
to
pick up the right signer's public key, valid at the time the signature was made.

The signer?s public key can be known in advance from the context. In such a 
case it
may be used directly. When this is not the case, it has to be obtained from the
information present in the CMS message. If the issuerAndSerialNumber from the
SignerInfo is used, then a substitution of certificates containing the same 
public
key value is possible. If such a substitution is a concern then the threat can 
be
addressed by making the certificate identifier part of the signature as 
described in
the Signing Certificate Attribute Specification [SIGATTR]. In such a case the 
right
public key is contained in the certificate pointed by the signed certificate
identifier.

In order to make sure that this 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.

If no time information is present in the CMS structure, then the assumption 
should be
that the message has just be signed. In that case the revocation information 
valid at
the time the verification is performed will be used.

If only the signingTime attribute is present, then no direct assumption can be 
made
on the time of the signature. If the certificate is not presently revoked and 
still
valid, then the time included in the signingTime attribute can be taken as the 
one
placed by the genuine signer and the certificate can be accepted. If the 
certificate
is presently revoked and/or no more valid, the verifier is at a risk to use
inadequate revocation information unless additional assurance may be obtained 
about
the time of the signature (see next).

If a counter signature from a trusted time Stamping Authority is used in 
addition to
the signingTime attribute and if these two time values are "close" enough (e.g. 
a few
hours) then the assumption should be that the signing time is the time 
mentioned in
the signingTime attribute. The revocation information that was valid at that 
signing
time should then be used.

The details of the signature validation 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 the signedAttributes of the
signedData signerInfo."


In order to address the text from section 11.3 on page 29, here is a text
replacement.

" The signing time is only the purported signing time as indicated by the 
signer. No
further assurance can be given upon the accuracy of that time unless additional
assurance can be obtained through other means, e.g. a counter-signature from a 
Time
Stamping Server. In particular, it should be noticed that in case of key 
compromise,
the message can be signed by an attacker that may use a pre-dated time, i.e. a 
time
in the past when the certificate was not revoked. In such a case, unpredictable
results may occur."

The changes I have provided are rather conservative from the current structure. 
The
Signing Certificate Attribute Specification [SIGATTR] addresses two topics. One 
has
to do, as the title indicates it, with Attribute Certificates while the other 
has to
do with the certificate identifier from the signer. It would/might be better to 
move
the section relative to the certificate identifier from SIGATTR into CMS since 
this
is just another VERY "useful attribute" from the section 11.


For example should the valdity (i.e. expiry) of the signing certificate
chain use the current time or the signingTime?

The signingTime attribute cannot be trusted in many cases.

If a certificate is revoked due to key compromise an attacker could
generate a message with a signingTime before it was revoked.

The corollary to this is that if a certificate has been revoked then the
posession of a signed message with a signingTime before the revokation
time is not sufficient for nonrepudiation purposes. Some corroboration
as to the signing time is required: such as a trusted timestamp
countersignature.

I think that the new text proposal provided hereabove may address your perfectly
valid concern.

3) Doug Maughn asked about the processing requirements for generating a
countersignature.  It was proposed on the list that the generator of a
countersignature must validate the original signature before generating the
countersignature.  Russ has included that proposal in the CMS draft that he
has not yet published.  He stated that "validate" means verify the signature
value of the CMS signedData, not necessarily validate the signer's cert 
path.


Does "verify the signature value of the CMS signedData" imply that just
the digital signature of the signedData is checked or the messageDigest
value as well, implying that the original content must be checked?

IMHO checking signedData is tolerable but the original content
verification has very serious implications, as I've mentioned before.

Even so this affects some existing implementations: for example the
Verisign AuthentiCode timestamper just takes the signedData signature
and produces a trusted timestamp countersignature from that.

Denis

FYI, follows the original text from July 15.

-----------------------------------------------------------------

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).

[Text deleted]

Denis


Steve.
--
Dr Stephen N. Henson. UK based freelance Cryptographic Consultant.
For info see homepage at http://www.drh-consultancy.demon.co.uk/
Email: shenson(_at_)drh-consultancy(_dot_)demon(_dot_)co(_dot_)uk
PGP key: via homepage.




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