Agenda & Presentations

Comments on S/MIME v3.2

Minutes and Updated Agenda Posted

RE: Comments on S/MIME v3.2

With respect to the RSA key sizes, I see lots of demand for 3072-bit keys, but not much for 2048-bit, so I'd be
very inclined to make the range 1024 to 3072. To be compatible with AES, you need at least 3072, after all. 

If that's the case, then the corresponding range for EC should be 160 to 256. 

	-----Original Message----- 
	From: owner-ietf-smime <at> mail.imc.org on behalf of Turner, Sean P. 
	Sent: Wed 12/5/2007 9:00 AM 
	To: ietf-smime <at> imc.org 
	Cc: 
	Subject: Comments on S/MIME v3.2
	
	

	At the meeting we had some comments on the S/MIME v3.2 specs (draft-ietf-smime-3850bis-00.txt and draft-ietf-smime-3851bis-00.txt):

	 1. Define SHOULD+, SHOULD-, and MUST-. 
	 2. Update key size requirements and make sure you differentiate between RSA/DSA and EC key sizes. 
	 3. Check that there's no IPR wrt to ECDSA signed certificates and using them with S/MIME. 

	For #1 - I'm going to copy the text from RFC4307. 

	For #3 - Turns out we're the 1st group to make ECDSA a SHOULD (of any kind) so we've got our feelers out to see
what we can shake loose.

	For #2 RSA/DSA key sizes - There was some discussion that the RSA key size that MUST be supported should be
1024-3076 and others felt that it should be 1024-2048.  What do people think?

	For #2 EC key size - This discussion may be premature but what should we make the sizes?  Min 256 max 384? 

	Other comments are welcome. 

	spt 

summary of smime-wg session at IETF 70

<div>

<p>S/MIME Minutes/Summary - IETF 70
</p>

<p>3 drafts were published:

<br>&nbsp;&nbsp; RFC5055 (ESSCertId update),

<br>&nbsp;&nbsp; RFC 5083 (AuthEnvelopedData content type),

<br>&nbsp;&nbsp; RFC5084 (aes-ccm/aes-gcm use of AuthEnvelopedData content type)

<br>2 with RFC editor symkeydist and cades

<br>3 addressing IESG LC comments rsa-kem, ibearch, bfibecms

<br>4 active IDs:

<br>&nbsp;&nbsp; Multiple Signatures Attribute,

<br>&nbsp;&nbsp; SHA2 Algorithms,

<br>&nbsp;&nbsp; S/MIME V3.2 MSG,

<br>&nbsp;&nbsp; S/MIME v3.2 CERT
</p>

<p>Jim Schaad discussed the Multiple Signatures Attribute draft

<br>Only updates were to security considerations section. Consider work complete and move to issue 4-week WG LC (accounts for holidaze)</p>

<p>Sean Turner discussed the SHA2 algorithms draft 

<br>The draft was updated to include object identifiers for RSA and ECDSA algorithms. Consider work complete and move to issue 4-week WG LC</p>

<p>Sean Turner discussed the S/MIME v3.2 drafts

<br>Intent of drafts is to update algorithms. Adopted IKEv2 language with respect to MUST, SHOULD+, and SHOULD- to provide implementors more information. Dropped RC2 support, made SHA-256 MUST, SHA-1 SHOULD-, AES 128 MUST, etc. Two comments were raised about IPR: SHA2 and ECDSA. Should we have an IPR statement from NIST (or whoever) about SHA2? Since we made ECDSA a SHOULD+ is there any IPR with respect to ECDSA and issuing certificates or using it with S/MIME?</p>

<p>Paul Hoffman discussed draft-hoffman-cms-new-asn1-00

<br>Developed an ID to include ASN.1 for most S/MIME WG ASN.1 modules. Moving to support the latest ASN.1 which is made possible by the A2C compiler they have developed. Question was whether WG should adopt the draft as a WG item. The WG felt that it should be because a) the WG is place where S/MIME implmentors should discuss implementation issues b) it will be listed on the WG charter page and therefore will be easier to find. There were no objections to adding it to the WG.&nbsp; </p>

<p>Wrap-up discussion

<br>WG LCs will be issued for SHA2 and Mutliple Signatures.

<br>Ask WG what key sizes should be required, track down IPR issues.

<br>Accept ASN ID as work item.
</p>

</div>

SHA2 IPR

Re: Comments on S/MIME v3.2

RE #1: Seems right to copy text from RFC 4307.

RE #2: I think that 1024 and 2048 ought to be MUST.  Other sizes MAY 
be supported.

RE #3:  This seems to be the license agreement in question:
http://www.ietf.org/ietf/IPR/certicom_smime_license.pdf

At 12:00 PM 12/5/2007, Turner, Sean P. wrote:

>At the meeting we had some comments on the S/MIME v3.2 specs 
>(draft-ietf-smime-3850bis-00.txt and draft-ietf-smime-3851bis-00.txt):
>
>  1. Define SHOULD+, SHOULD-, and MUST-.
>  2. Update key size requirements and make sure you differentiate 
> between RSA/DSA and EC key sizes.
>  3. Check that there's no IPR wrt to ECDSA signed certificates and 
> using them with S/MIME.
>
>For #1 - I'm going to copy the text from RFC4307.
>
>For #3 - Turns out we're the 1st group to make ECDSA a SHOULD (of 
>any kind) so we've got our feelers out to see what we can shake loose.
>
>For #2 RSA/DSA key sizes - There was some discussion that the RSA 
>key size that MUST be supported should be 1024-3076 and others felt 
>that it should be 1024-2048.  What do people think?
>
>For #2 EC key size - This discussion may be premature but what 
>should we make the sizes?  Min 256 max 384?
>
>Other comments are welcome.
>
>spt

WG Last Call: draft-ietf-smime-sha2-01

This message initiates an SMIME Working Group Last Call on the document:

 Title     : Using SHA2 Algorithms with Cryptographic Message Syntax
 Author(s) : S. Turner
 Filename  : draft-ietf-smime-sha2-01.txt
 Pages     : 10
 Date      : 2007-7-25

This document describes the conventions for using the message digest
algorithms SHA-224, as defined in [RFC3874], and SHA-256, SHA-384, SHA-512,
as defined in [SHA2], with the Cryptographic Message Syntax (CMS) [RFC3852].
It also describes the conventions for using these algorithms with CMS and
the DSA, RSA, and ECDSA signature algorithms. 

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-smime-sha2-01.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 9 Janurary 2008.

Upon completion of the last call, the WG chairs will take action based upon
the consensus of the WG. 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!

Blake
--

-- 
Blake Ramsdell | Sendmail, Inc. | http://www.sendmail.com

WG Last Call: draft-ietf-smime-multisig-03

This message initiates an SMIME Working Group Last Call on the document:

 Title     : Multiple Signatures in S/MIME 
 Author(s) : S. Turner and J. Schaad
 Filename  : draft-ietf-smime-multisig-03.txt
 Pages     : 19
 Date      : 2007-11-16

CMS SignedData includes the SignerInfo structure to convey per-signer
information. SignedData supports multiple signers and multiple signature
algorithms per-signer with multiple SignerInfo structures. If a signer
attaches more than one SignerInfo, there are concerns that an attacker could
perform a downgrade attack by removing the SignerInfo(s) with the 'strong'
algorithm(s). This document defines the multiple-signatures attribute, its
generation rules, and its processing rules to allow signers to convey
multiple SignerInfo while protecting against downgrade attacks.
Additionally, this attribute may assist during periods of algorithm
migration.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-smime-multisig-03.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 9 Janurary 2008.

Upon completion of the last call, the WG chairs will take action based upon
the consensus of the WG. 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!

Blake
--

-- 
Blake Ramsdell | Sendmail, Inc. | http://www.sendmail.com

RE: Comments on S/MIME v3.2

"Luther Martin" <martin <at> voltage.com> writes:

>With respect to the RSA key sizes, I see lots of demand for 3072-bit keys,
>but not much for 2048-bit, so I'd be very inclined to make the range 1024 to
>3072. To be compatible with AES, you need at least 3072, after all.

How widely supported are values > 2K bits in hardware and crypto toolkits?
The last time I looked (which admittedly was a few years ago), you ran into
problems if you assumed that everyone could handle > 2K bit keys.

Peter.