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

"Turner, Sean P." <turners@ieca.com> Mon, 08 September 2008 16:06 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 412E528C12C for <ietfarch-smime-archive@core3.amsl.com>; Mon, 8 Sep 2008 09:06:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.606
X-Spam-Level:
X-Spam-Status: No, score=-1.606 tagged_above=-999 required=5 tests=[AWL=-0.496, BAYES_05=-1.11]
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 U+ekSAIzD-En for <ietfarch-smime-archive@core3.amsl.com>; Mon, 8 Sep 2008 09:06:48 -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 5EA1928C15F for <smime-archive@ietf.org>; Mon, 8 Sep 2008 09:06:47 -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 m88Fsvr6076110 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Sep 2008 08:54:57 -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 m88Fsvda076109; Mon, 8 Sep 2008 08:54:57 -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 smtp102.biz.mail.re2.yahoo.com (smtp102.biz.mail.re2.yahoo.com [68.142.229.216]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m88FskWJ076095 for <ietf-smime@imc.org>; Mon, 8 Sep 2008 08:54:56 -0700 (MST) (envelope-from turners@ieca.com)
Received: (qmail 50418 invoked from network); 8 Sep 2008 15:54:37 -0000
Received: from unknown (HELO Wylie) (turners@ieca.com@96.241.96.147 with login) by smtp102.biz.mail.re2.yahoo.com with SMTP; 8 Sep 2008 15:54:36 -0000
X-YMail-OSG: pANRBogVM1lb0AteeOzdeyBemBu_c8iheM.qsOeA4O7TOZVjQZXCLUdRUvZXd21OMT1MnQnBuyc8cg5T3BKb3IhA4VkCHKfsrlyRcYtY6KtvK9fC28kl0UYY4PLY10UWEdUAsGcChfEWtMElxXXtZfol
X-Yahoo-Newman-Property: ymail-3
From: "Turner, Sean P." <turners@ieca.com>
To: denis.pinkas@bull.net, 'ietf-smime' <ietf-smime@imc.org>
References: <200809071944.m87JiifQ052523@balder-227.proper.com> <DreamMail__161905_89570310603@msga-001.frcl.bull.fr>
Subject: RE: WG Last Call: draft-ietf-smime-rfc3850bis-05.txt
Date: Mon, 08 Sep 2008 11:54:19 -0400
Organization: IECA, Inc.
Message-ID: <500915C8D6A04C0CBEE68126322EC8EB@Wylie>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579
In-Reply-To: <DreamMail__161905_89570310603@msga-001.frcl.bull.fr>
Thread-Index: AckRwNavuISvQ3MlSbegyy/9so2D9gAATD1Q
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>

Denis,

Thanks for your comments.

spt 

>-----Original Message-----
>From: owner-ietf-smime@mail.imc.org 
>[mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Denis Pinkas
>Sent: Monday, September 08, 2008 10:19 AM
>To: ietf-smime
>Cc: owner-ietf-smime; Sean Turner
>Subject: Re: WG Last Call: draft-ietf-smime-rfc3850bis-05.txt
>
>
>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.  

I think we can just strike "identity".  Note that I also deleted "identity"
from section 3.

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

Okay.

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

The 1024 text in draft-ietf-smime-3851bis addresses the 1024 size for
DSA/DH.  I'll add something for 2048 RSA.  Something along the lines of (I
won't try to change what's in RFC3766 to be todays equipment):

The choice of 2048 bits as the RSA asymmetric key size in this specification
is based on the desire to provide 100 bits of security.  The choice of 1024
bits as the DSA, and DH asymmetric key size in this specification is based
on the desire to provide 80 bits of security.

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

Don't understand this one.  If the key is 900-bits then it MUST be
supported.

>draft-ietf-smime-3851bis-05.txt contains the following requirements : 
>
>...snip
>
>draft-ietf-smime-3851bis places a boundary at 2048 bits. 
>This is far sufficient today, since RSA 1024 is far from being broken. 

The WG consensus was 2048 for RSA as the upper limit.

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

draft-ietf-smime-3850bis only addresses validation of certificates and since
4096 is already in root cert stores it seems appropriate to support this.

>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 

We argued about this for a long time.  What's in the document was the WG
consensus.

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

Okay.

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

Others caught this too.  I deleted one.

>Denis

... snip