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

From: Russ Housley <[email-masked]>
Date: Sun, 07 Sep 2008 15:44:29 -0400

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

---

From: "Denis Pinkas"<[email-masked]>
Date: Mon, 8 Sep 2008 16:19:05 +0200

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 

Russ

---

From: "Turner, Sean P." <[email-masked]>
Date: Mon, 8 Sep 2008 11:54:19 -0400

Denis,

Thanks for your comments.

spt 

>-----Original Message-----
>From: [email-masked] 
>[mailto:[email-masked]] 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 .. 
>
>I took a look at RFC 5280 [KEYM] and searched for "identity 
>certificate". 

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

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

Okay.

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

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

>...snip

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

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

>   4096 <  key size         : SHOULD NOT 

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

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

Okay.

>   the message even if signature verification fails.  

Others caught this too.  I deleted one.

>Denis

... snip

---

From: "Denis Pinkas"<[email-masked]>
Date: Thu, 11 Sep 2008 13:55:37 +0200

Sean,

My comments are embedded in the text.

Denis

=============================================
Denis,

spt 

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

(snip)

(snip) 

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)

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

---

From: "Turner, Sean P." <[email-masked]>
Date: Mon, 15 Sep 2008 18:11:35 -0400

________________________________

	From: [email-masked]
[mailto:[email-masked]] On Behalf Of Denis Pinkas
	Sent: Thursday, September 11, 2008 4:56 AM
	To: ietf-smime
	Subject: RE: WG Last Call: draft-ietf-smime-rfc3850bis-05.txt

	
(snip)

(snip) 

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)

In draft-ietf-smime-3850bis, I mistakenly had two sets of requirements for
RSA.   The first set of requirements is for RSA and the second is for DSA
(typo).  draft-ietf-smime-3850bis 4.3 changed to:

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

(snip)

Okay.

I'd prefer that you propose the text.

spt