ietf-smime
[Top] [All Lists]

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

2007-01-09 07:42:19
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
<Prev in Thread] Current Thread [Next in Thread>