ietf-smime
[Top] [All Lists]

Re: I-D ACTION:draft-ietf-smime-multisig-00.txt

2006-12-26 04:49:24

Comments on draft-ietf-smime-multisig-00.txt

This document is necessary so that draft-ietf-smime-cms-mult-sign-02.txt may be 
applicable. 
The two documents should be merged.

Let me explain briefly :draft-ietf-smime-cms-mult-sign-02.txt does not provide 
any means so that, 
at the CMS level, an application can figure out that the same signer has placed 
two SignerInfo structures. 
This new draft fills in the gap.

However, this draft is unclear on how it applies. There are three types of RPs 
concerned with this draft:

a)      RPs able to process ?weak? algorithms, 
b)      RPs able to process ?strong? algorithms only, and
c)      RPs able to process both ?weak? and ?strong? algorithms.

In case a, the main advantage of this draft is to allow to link digital 
signatures from the same signer 
in case of algorithm migration. If the RP decodes a SignerInfo with the 
?strong? algo, then it cannot 
verify the digital signature, but then it can easily figure out that there is 
another signature with the 
weak algorithms that it can process. The draft is silent about this scenario.

In case b, the RPs is only able to process strong algorithms. If the RP decodes 
a SignerInfo with 
the ?weak? algo, then it can also figure out that there is another signature 
that it can process. 
The draft is silent about this scenario.

In case c, the RPs is able to process both the weak and the strong algorithms. 
If the RP decodes 
a SignerInfo with the ?weak? algo, then it can also figure out that there is 
another signature that 
it can process. What about if a single bit from the digital signature made with 
the stronger algorithm 
is changed by an attacker ? The digital signature is not suppressed, but 
becomes invalid. 
What should the RP do ? The draft is silent about this scenario. 

The draft does not say either whether it applies to the verification of a CMS 
structure at the present time 
or at a time in the past. 

If it is the present time, both the ?weak? and ?strong? algorithms are safe, 
and there is no concern 
for the ?downgrade attack?.

If it is a time in the past, then it is important to make a difference between :

-       the weakness of hash algorithms, and 
-       the weakness of asymmetric algorithm of short keys. 

In the later case, time-stamping or time-marking over the digital signature 
provides a protection. 

In the former case, time-stamping or time-marking over the digital signature 
does not provide a protection, 
but an archive time-stamping provides a protection, since a different and 
stronger hash algorithm may be used.

This means that there exist solutions to handle the problem without the need to 
use the new signed attribute.

In addition, RPs should know which hash algorithms is no more safe, which means 
that they will not use 
the digital signature made with a weak algorithm. They may try to use the newly 
defined MultipleSignatures 
signed attribute to find out another signature made with a strong algorithm. In 
other words, the ?downgrade attack? 
is not a concern, but the newly defined MultipleSignatures signed attribute is 
useful to link signatures from 
the same signer. The abstract should be changed. Hereafter is a proposal: 

      CMS SignedData includes the SignerInfo structure to convey per-
      signer information. SignedData supports multiple signers and 
      multiple signature algorithms per-signer with multiple SignerInfo 
      structures. During periods of algorithm migration, a signer may 
      wish to attach more than one SignerInfo. However, there is no 
      way to identify that they are from the same signer. This document 
      defines a signed attribute, its generation rules, and its 
      processing rules to allow a RP to detect SignerInfo structures 
      generated by the same signer.

The processing rules for the various RPs should be given (six cases should be 
covered).

The MultipleSignature attribute, as defined, is not good enough, to establish a 
link without ambiguity.

           MultipleSignature ::= SEQUENCE { 
             bodyHashAlg     DigestAlgorithIdentifier, 
             signAlg         SignatureAlgorithmIdentifier, 
             signAttrsHash   SignAttrsHash, 
             cert            ESSCertIDv2 OPTIONAL} 

If the same algorithm are used (e.g. SHA-1 with RSA) bodyHashAlg and signAlg 
will likely be the same. 
If a signature has few signed attributes signAttrsHash will also likely be the 
same. The difference will 
always be guaranteed with cert, which thus should be made mandatory. 

Denis


It is a companion document, not a replacement.

Russ

At 05:28 AM 12/20/2006, Denis Pinkas wrote:

How does this document relate to <draft-ietf-smime-cms-mult-sign-02.txt> ?

Does it replace it ?

Denis

A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the S/MIME Mail Security Working 
Group of the IETF.

      Title           : Multiple Signatures in S/MIME
      Author(s)       : S. Turner
      Filename        : draft-ietf-smime-multisig-00.txt
      Pages           :
      Date            : 2006-12-19

        CMS SignedData includes the SignerInfo structure to convey per-
        signer information. SignedData supports multiple signers and
        multiple signature algorithms per-signer with multiple SignerInfo
        structures. If a signer attaches more than one 
SignerInfo, there are
        concerns that an attacker could perform a downgrade attack by
        removing the SignerInfo(s) with the 'stronger' algorithm(s). This
        document defines a signed attribute, its generation rules, and its
        processing rules to allow signers to convey multiple SignerInfo
        while protecting against downgrade attacks. Additionally, this
        attribute may assist during periods of algorithm migration.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-smime-multisig-00.txt

To remove yourself from the I-D Announcement list, send a message to
i-d-announce-request(_at_)ietf(_dot_)org with the word unsubscribe in the 
body of
the message.
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the
username "anonymous" and a password of your e-mail address. After
logging in, type "cd internet-drafts" and then
"get draft-ietf-smime-multisig-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
      mailserv(_at_)ietf(_dot_)org(_dot_)
In the body type:
      "FILE /internet-drafts/draft-ietf-smime-multisig-00.txt".

NOTE:  The mail server at ietf.org can return the document in
      MIME-encoded form by using the "mpack" utility.  To use this
      feature, insert the command "ENCODING mime" before the "FILE"
      command.  To decode the response(s), you will need "munpack" or
      a MIME-compliant mail reader.  Different MIME-compliant mail readers
      exhibit different behavior, especially when dealing with
      "multipart" MIME messages (i.e. documents which have been split
      up into multiple messages), so check your local documentation on
      how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

Content-Type: text/plain
Content-ID:    <2006-12-19135046(_dot_)I-D(_at_)ietf(_dot_)org>

ENCODING mime
FILE /internet-drafts/draft-ietf-smime-multisig-00.txt