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

"Denis Pinkas"<denis.pinkas@bull.net> Thu, 11 September 2008 12:19 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 2BF423A6819 for <ietfarch-smime-archive@core3.amsl.com>; Thu, 11 Sep 2008 05:19:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.889
X-Spam-Level:
X-Spam-Status: No, score=0.889 tagged_above=-999 required=5 tests=[AWL=0.299, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, 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 ZIpCUzGuBXkD for <ietfarch-smime-archive@core3.amsl.com>; Thu, 11 Sep 2008 05:19:24 -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 7AEE23A6907 for <smime-archive@ietf.org>; Thu, 11 Sep 2008 05:19:23 -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 m8BBuSCu078538 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 11 Sep 2008 04:56:28 -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 m8BBuSwj078537; Thu, 11 Sep 2008 04:56:28 -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 m8BBuGSl078522 for <ietf-smime@imc.org>; Thu, 11 Sep 2008 04:56:27 -0700 (MST) (envelope-from denis.pinkas@bull.net)
Received: from MSGA-001.frcl.bull.fr (msga-mcl2.frcl.bull.fr [129.184.87.21]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id OAA71066 for <ietf-smime@imc.org>; Thu, 11 Sep 2008 14:08:18 +0200
Received: from FRMYA-SIA24 ([129.182.109.111]) by MSGA-001.frcl.bull.fr (Lotus Domino Release 5.0.11) with SMTP id 2008091113553857:14691 ; Thu, 11 Sep 2008 13:55:38 +0200
Reply-To: denis.pinkas@bull.net
From: Denis Pinkas <denis.pinkas@bull.net>
To: ietf-smime <ietf-smime@imc.org>
Subject: RE: WG Last Call: draft-ietf-smime-rfc3850bis-05.txt
Date: Thu, 11 Sep 2008 13:55:37 +0200
Message-Id: <DreamMail__135537_74840450870@msga-001.frcl.bull.fr>
References: <200809071944.m87JiifQ052523@balder-227.proper.com> <DreamMail__161905_89570310603@msga-001.frcl.bull.fr>
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 11/09/2008 13:55:38, Serialize by Router on MSGA-001/FR/BULL(Release 5.0.11 |July 24, 2002) at 11/09/2008 13:56:14, Serialize complete at 11/09/2008 13:56:14
Content-Type: multipart/alternative; boundary="----=_NextPart_08091113553728837323313_002"
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>

Sean,

My comments are embedded in the text.

Denis

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

DP:  Let me try again. The text states:

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

(snip)

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

(snip) 

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

If the key size is between 512 and 1024 two lines of requirements apply.
It is unclear which line should be taken into consideration and thus whether a MUST or a MAY applies.

(snip)

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

DP: This is fine. However, my comment also said: "Additional efforts 
should be done on decrypting a content-encryption key or 
forming a pairwise symmetric key. Would you be able to provide 
some text to cover these aspects ?

Denis