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

From: "Turner, Sean P." <[email-masked]>
Date: Wed, 3 Jan 2007 09:40:15 -0500

Dennis,

Comments inline..

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Denis Pinkas
Sent: Tuesday, December 26, 2006 6:19 AM
To: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-smime-multisig-00.txt

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

..snip

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.

spt> The draft is intended to address all three types of RPs.

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.

spt> The main advantage of the draft is to allow you to know if an attacker
stripped off a SignerInfo.  I will add the point about being easier able to
find the other signature if you only support one of the two.

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.

spt> See above.

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. 

spt> We will add text to address this - this part was going to go in to
section 5.

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.

spt> I do not believe time should have anything to do with this. If you're
not worried about downgrade attacks then don't use the 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: 

spt> While this might be true there are times when an RP won't know and this
draft addresses those instances.

      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.

spt> The point of the draft is to protect against a downgrade attack and I
will not change the abstract because I believe your suggestion misses the
point of the draft.

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

spt> Agreed that we need to fill in the processing rules.

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. 

spt> No the digest alg is sha-1 and the signature alg is rsa with sha-1 so
the values are different. 

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 
>> >[email-masked] 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:
>> >       [email-masked].
>> >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:    <[email-masked]>
>> >
>> >ENCODING mime
>> >FILE /internet-drafts/draft-ietf-smime-multisig-00.txt

---

From: "Denis Pinkas" <[email-masked]>
Date: Tue, 9 Jan 2007 14:01:35 +0100

Sean,

My replies are in line too.

>spt> The draft is intended to address all three types of RPs.

This is what I believed, but these cases are not discussed in detail in the text.
I am  awaiting some new text.

>spt> We will add text to address this - this part was going to go in to

OK. I am  awaiting some new text.

>not worried about downgrade attacks then don't use the attribute.

The key point is to explain when this attribute is really useful. 
When you will have detailed the six cases, which case, if any, makes that attribute useful ?
The anwser could be none.

>draft addresses those instances.

Really ? I believe that the local security policy of the recipient needs to know whether SHA-1 is secure enough 
and whether SHA-1 is better or lower than SHA-256.

>will not change the abstract because I believe your suggestion misses the

This point still needs to be proven.

>spt> Agreed that we need to fill in the processing rules.

OK. I am  awaiting some new text.

>the values are different. 

OK. You are correct.

Denis

---

From: "Denis Pinkas" <[email-masked]>
Date: Tue, 9 Jan 2007 13:52:06 +0100

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