Re: WG Last Call: draft-ietf-smime-rfc3850bis-05.txt

"Denis Pinkas"<denis.pinkas@bull.net> Mon, 08 September 2008 14:40 UTC

Return-Path: <owner-ietf-smime@mail.imc.org>
X-Original-To: ietfarch-smime-archive@core3.amsl.com
Delivered-To: ietfarch-smime-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 60E223A6B77 for <ietfarch-smime-archive@core3.amsl.com>; Mon, 8 Sep 2008 07:40:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.188
X-Spam-Level: *
X-Spam-Status: No, score=1.188 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_64=0.6, RCVD_BAD_ID=2.837]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2aXtNR0ODtNC for <ietfarch-smime-archive@core3.amsl.com>; Mon, 8 Sep 2008 07:40:31 -0700 (PDT)
Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 6AC463A6A41 for <smime-archive@ietf.org>; Mon, 8 Sep 2008 07:40:30 -0700 (PDT)
Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m88EJodm068949 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Sep 2008 07:19:50 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org)
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m88EJoDv068948; Mon, 8 Sep 2008 07:19:50 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f
Received: from odin2.bull.net (odin2.bull.net [129.184.85.11]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m88EJbQC068921; Mon, 8 Sep 2008 07:19:48 -0700 (MST) (envelope-from denis.pinkas@bull.net)
Received: from MSGA-001.frcl.bull.fr (msga-mcl1.frcl.bull.fr [129.184.87.20]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id QAA82458; Mon, 8 Sep 2008 16:31:37 +0200
Received: from FRMYA-SIA24 ([129.182.109.111]) by MSGA-001.frcl.bull.fr (Lotus Domino Release 5.0.11) with SMTP id 2008090816190635:148786 ; Mon, 8 Sep 2008 16:19:06 +0200
Reply-To: denis.pinkas@bull.net
From: Denis Pinkas <denis.pinkas@bull.net>
To: ietf-smime <ietf-smime@imc.org>
CC: owner-ietf-smime <owner-ietf-smime@mail.imc.org>, Sean Turner <turners@ieca.com>
Subject: Re: WG Last Call: draft-ietf-smime-rfc3850bis-05.txt
Date: Mon, 08 Sep 2008 16:19:05 +0200
Message-Id: <DreamMail__161905_89570310603@msga-001.frcl.bull.fr>
References: <200809071944.m87JiifQ052523@balder-227.proper.com>
MIME-Version: 1.0
X-Priority: 3 (Normal)
X-Mailer: DreamMail 4.4.1.0
X-MIMETrack: Itemize by SMTP Server on MSGA-001/FR/BULL(Release 5.0.11 |July 24, 2002) at 08/09/2008 16:19:06, Serialize by Router on MSGA-001/FR/BULL(Release 5.0.11 |July 24, 2002) at 08/09/2008 16:19:36, Serialize complete at 08/09/2008 16:19:36
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset="ISO-8859-1"
Sender: owner-ietf-smime@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:ietf-smime-request@imc.org?body=unsubscribe>

Russ,

Since you asked .. 

Comment 1. Section 2.2. The text states : 

   Receiving agents MUST support v1 X.509 and v3 X.509 identity  
   certificates as profiled in [KEYM].   

I took a look at RFC 5280 [KEYM] and searched for “identity certificate”. 
There is not such a term in this document. 
Please provide the correct reference and section number. 
Since the sentence includes a MUST, this is rather important.  


Comment 2. Section 2.3. The text states : 

   Agents MAY send CA certificates, that is, certificates which can be  
   considered the "root" of other chains, and which MAY be self-signed.  

This is incorrect. A CA certificate is not necessarily a self-signed certificate. The text should be changed into : 

   Agents MAY send CA certificates, i.e. cross-certificates,  
   self-issued certificates, and self-signed certificates.  


Comment 3. Section 4.3. The text states : 

   The following are the RSA key size requirements for S/MIME receiving  
   agents during certificate and CRL signature verification:  

      0 <  key size <   512 : MAY  (see Section 6 [SMIME-MSG])  
    512 <= key size <= 4096 : MUST (see Section 6 [SMIME-MSG])  
   4096 <  key size         : MAY  (see Section 6 [SMIME-MSG])  

   The following are the RSA key size requirements for S/MIME receiving  
   agents during certificate and CRL signature verification:  

    512 <= key size <= 1024 : MAY  (see Section 6 [SMIME-MSG])  

Section 6 from [SMIME-MSG] does not explain why these key sizes have been chosen. 
So the reference to that section from that document is not appropriate and should be deleted. 

Furthermore, this is inconsistent: if the key size is 900 bits, should we apply a MUST or a MAY ? 

draft-ietf-smime-3851bis-05.txt contains the following requirements : 

4.2. Signature Generation  

   The following are the requirements for an S/MIME agent generated RSA  
   signatures:  

    512 <= key size <  1024 : MAY     (see Security Considerations)  
   1024 <= key size <= 2048 : SHOULD  (see Security Considerations)  
   2048 <  key size         : MAY     (see Security Considerations)  

   The following are the requirements for an S/MIME agent generated DSA  
   signatures:  

    512 <= key size <= 1024 : SHOULD (see Security Considerations)  

4.3. Signature Verification  

   The following are the requirements for S/MIME receiving agents during  
   signature verification of RSA signatures:  

    512 <= key size <= 2048 : MUST    (see Security Considerations)  
   2048 <  key size         : MAY     (see Security Considerations)  

   The following are the requirements for S/MIME receiving agents during  
   signature verification of DSA signatures:  

    512 <= key size <= 1024 : SHOULD (see Security Considerations)  

4.4. Encryption  

   The following are the requirements for an S/MIME agent when  
   establishing keys for content encryption using the RSA algorithms:  

    512 <= key size <  1024 : MAY    (see Security Considerations)  
   1024 <= key size <= 2048 : SHOULD (see Security Considerations)  
   2048 <  key size         : MAY    (see Security Considerations)  

   The following are the requirements for an S/MIME agent when  
   establishing keys for content encryption using the DH algorithms:  

    512 <= key size <= 1024 : SHOULD (see Security Considerations)  

4.5. Decryption  

   The following are the requirements for an S/MIME agent when  
   establishing keys for content decryption using the RSA algorithms:  

    512 <= key size <= 2048 : MUST   (see Security Considerations)  
   2048 <  key size         : MAY    (see Security Considerations)  

   The following are the requirements for an S/MIME agent when  
   establishing keys for content decryption using the DH algorithms:  

    512 <= key size <= 1024 : SHOULD  (see Security Considerations)  

draft-ietf-smime-3851bis places a boundary at 2048 bits. 
This is far sufficient today, since RSA 1024 is far from being broken. 

4096 bits provides higher security, but this not needed today. 
This key size should not be mandated to support. Supporting key size higher than 4096 bits 
can create denial of service, so implementations should not support them. 

I would rather think that the text should be changed into: 

   The following are the RSA key size requirements for S/MIME receiving  
   agents during certificate and CRL signature verification:  

      0 <  key size <=  512 : MAY 
    512 <  key size <= 2048 : MUST 
   2048 <  key size <= 4096 : SHOULD 
   4096 <  key size         : SHOULD NOT 


Comment 4. Section 4.2. The text states: 

   Certificate, CRL, and path  
   validation MUST be performed as per [KEYM] when validating a  
   correspondent's public key.  This is necessary before using a public  
   key to provide security services such as: verifying a signature;  
   encrypting a content-encryption key (ex: RSA); or forming a pairwise  
   symmetric key (ex: Diffie-Hellman) to be used to encrypt or decrypt a  
   content-encryption key.  

The text is silent on the way to identify the right certificate to be used 
as the input certificate for the path validation. I have focussed my efforts to provide 
some additional text when verifying a signature. Additional efforts should be done 
on decrypting a content-encryption key or forming a pairwise symmetric key. 

Additional text proposal: 

When verifying a signature, if a signingCertificate or a signingCertificateV2 attribute 
is found in an S/MIME message, it SHALL be used to identify the signer’s certificate. 
Otherwise, the certificate is identified in an S/MIME message, either using the 
issuerAndSerialNumber which identifies the signer's certificate by the issuer's 
distinguished name and the certificate serial number, or the subjectKeyIdentifier 
which identifies the signer's certificate by a key identifier. 


Comment 5. Section 6. 

There is duplication of text. The two following paragraph say the same. 
Please delete one of them: 

   In addition to the Security Considerations identified in [KEYM],  
   caution should be taken when processing certificates which have not  
   first been validated to a trust anchor.  Certificates could be  
   manufactured by untrusted sources for the purpose of mounting denial  
   of service or other attacks.  For example, keys selected to require  
   excessive cryptographic processing, or extensive lists of CDP and/or  
   AIA addresses in the certificate, could be used to mount denial of  
   service attacks.  Similarly, originator-specified CDP and/or AIA  
   addresses could be inserted into bogus certificates to allow the  
   originator to detect receipt of the message even if signature  
   verification fails.  

   In addition to the Security Considerations identified in [KEYM],  
   caution should be taken when processing certificates which have not  
   first been validated to a trust anchor.  Certificates could be  
   manufactured by untrusted sources for the purpose of mounting denial  
   of service or other attacks.  For example, keys selected to require  
   excessive cryptographic processing, or extensive lists of CDP and/or  
   AIA addresses in the certificate, could be used to mount denial of  
   service attacks.  Similarly, attacker-specified CRL distribution  
   point and/or authority information access addresses could be included  
   into fake certificates to allow the originator to detect receipt of  
   the message even if signature verification fails.  

Denis

----- Message reçu -----  
De : owner-ietf-smime  
À : Turner,Sean P.,ietf-smime  
Date : 2008-09-07, 21:44:29 
Sujet : Re: WG Last Call: draft-ietf-smime-rfc3850bis-05.txt 


So far, I have not seen any comments on this WG last Call  
thread. Note that the WG Last Call ends tomorrow. 

Russ 

At 08:32 PM 8/21/2008, Turner, Sean P. wrote: 

>This message initiates an SMIME Working Group Last Call on the document: 
> 
> Title : Secure/Multipurpose Internet Mail Extensions (S/MIME) 
> Version 3.2 Certificate Handling 
> Author(s) : S. Turner, B. Ramsdell 
> Filename : draft-ietf-smime-3850bis-05.txt 
> Pages : 20 
> Date : 2008-8-21 
> 
>This document specifies conventions for X.509 certificate usage by 
>Secure/Multipurpose Internet Mail Extensions (S/MIME) agents. S/MIME 
>provides a method to send and receive secure MIME messages, and certificates 
>are an integral part of S/MIME agent processing. S/MIME agents validate 
>certificates as described in RFC 5280, the Internet X.509 Public Key 
>Infrastructure Certificate and CRL Profile. S/MIME agents must meet the 
>certificate processing requirements in this document as well as those in RFC 
>5280. This document obsoletes RFC 3850. 
> 
>A URL for this Internet-Draft is: 
>http://www.ietf.org/internet-drafts/draft-ietf-smime-3850bis-05.txt 
> 
>The purpose of this WG Last Call is to ensure that the Working Group has 
>achieved consensus that the document is suitable for publication as a 
>Standards Track RFC. 
> 
>Please review the document for both technical and editorial problems. 
>Technical issues should be discussed on this list. Editorial issues may be 
>sent to the document editor. 
> 
>The Last Call period will end on 8 September 2008. 
> 
>Upon completion of the last call, the WG chairs will take action based upon 
>the consensus of the WG. As the authors are also the WG co-chairs, Russ 
>Housley has offered to make consensus calls and the WG chairs have agreed to 
>abide by Russ's consensus calls. Possible actions include: 
> 
> 1) recommending to the IETF Security Area Directors 
> that the document, after possible editorial or 
> other minor changes, be considered by the IESG 
> for publication as an Informational RFC 
> (which generally involves an IETF-wide Last Call); or 
> 
> 2) requiring that outstanding issues be adequately 
> addressed prior to further action (including, 
> possibly, another WG Last Call). 
> 
>Remember that it is our responsibility as Working Group members to ensure 
>the quality of our documents and of the Internet Standards process. So, 
>please read and comment! 
> 
>spt