Subject: Comments on draft-ietf-smime-3278bis-01.txt

From: "Jim Schaad" <[email-masked]>
Date: Thu, 14 Aug 2008 23:00:53 +1000

Section 1.2
 - bullet #1 - should be SHA-1 not SHA
 - bullet #3 - change 'e' to 'a'
 - be consistent on use of SHA-1 vs SHA1

Section 2.3.2 -- "SignerInfosignature" --> SignerInfo.signature

Snide remark - Can you use ECDH with CMS EnvelopedData w/o key agreement?

Section 3. - Is it permitted to do ECC static-static?

Section 3.1.1 - originator - The parameters SHOULD be ABSENT not NULL.  This
is 1) consistent with what is done for DH and 2) means that you don't have
one more additional encoding binding for the originator field as oppose to
the parameters 

Section 3.1.1 - please justify the requirement for DER encoding of ECPoint.

Section 3.1.1 - what about the ukm field?

Section 3.2 - I don't understand why ES ECDH cannot be used for
AuthenticatedData.  We can use the DH algorithm with it.  I can understand
if you want to state that some ADDITIONAL security properties exist from
using 1-pass ECMQV.

Section 3.2.1 - for the bullet ukm - the last sentence makes no sense---
Part of the problem is that the next paragraph is not further indented.

Section 3.2.1 - I would recommend for algorithm that absent rather than NULL
be used to simplify encoding/decoding steps

Section 3.2.2 - what are the domain parameters the same as?

Section 3.2.2 - where does the additional ukm come from  It is/is not an
ouptut of the key deployment/agreement algorithm?

Section 3.2.2 - Please elaborate on the re-used statement in the last
paragraph.  Can be re-used for what?  for how long?  why can't it be re-used
for encrypted data?

Section 3.2.2 - if you re-use the ephemeral - what does/does not need to be
changed?  The additional ukm?

Section 3.2.3 - Are there requirements/recommendations for validating a
sender's certificate?  Are there security implications for not doing so?

Section 4.1.2 - Note:  There is a legal attack where by the recipient
modifies the content and goes to court with the modified content.  Unless
you bind the output MAC in with the MAC key, you cannot prevent this type of
attack.

Section 5 - The first implementation requirement makes no sense.  Nor does
it provide for interop.  It makes more sense to talk about SignedData
conformance w/ the spec or Encryption conformance w/ the spec.

Section 5 - Why does ECDH care that P-256 curve be used with SHA-256?  What
is this paragraph trying to state?

Section 5 - What is sha1kdf - where is this referenced?  Is the what the
previous paragraph is talking about?

Section 5 - Are the KDF functions referenced here defined using an object
identifier in the X9.62 specifications?  If so it would be good to include
those OIDs in the ASN.1 module. (No private opinion)

Section 5 - Need to do some type of reference to where all of the key wrap
and content encryption algorithms are defined.

Section 8.2 - Has the following text:
   When the object identifier id-ecPublicKey is used here with an 
   algorithm identifier, the associated parameters contain NULL. 

   I thought that there were ec domain parameters that were to be encoded
with the public key.  Where else would this be used?  Is this from the
OriginatorKey clause above that I think is incorrect?

Section 8.1 - for ecdas-with-*, is it considered acceptable to have absent
parameters?

Section 8.1 - The parameters for the encryption schemes - 
        KeyWrap ::= OBJECT IDENTIFIER or
        KeyWrap ::= AlgorithmIdentifier 
        It is not clear from the text at the end of the last paragraph in
this section.  Many people use OID and "algorithm identifier" as the same
thing.

Section 8.2  What happens for keyInfo if the key wrap algorithm actually has
parameters?

Section 8.2 - suppPubInfo - Since AES128 is the required key wrap, use that
for the example not 3DES

---

From: "Turner, Sean P." <[email-masked]>
Date: Thu, 21 Aug 2008 18:09:40 -0400

Jim,

Responses inline... Still working on 3 of the comments, which have been
moved to the bottom of the email.

All,

Jim's raised some concerns about the parameters fields and whether they
should be NULL or ABSENT.  Additionally, this draft doesn't discuss hash
algorithm's parameter fields.  We've got two options:

1) We leave the text as is and include some wording similar to what we say
about hash algorithm parameters (must support both NULL and absent
parameters and SHOULD generate absent). Note we need to add this text
regardless for the hash algorithm parameters because right now the ID says
nothing about them.

2) We poll implementers. We'd need to ask those that implemented:

- The originatorKey algorithm field MUST contain the id-ecPublicKey object
identifier when implementing ES ECDH with EnvelopedData but is the parameter
field populated with a NULL or is it ABSENT (i.e., the originatorKey is a
SEQUENCE of one component, the OID id-ecPublicKey).

- The signatureAlgorithm algorithm field MUST contain the ecdsa-with-*
object identifier when implementing ECDSA with SignedData but is the
parameter field populated with a NULL or is it ABSENT (i.e., the
signatureAlgorithm is a SEQUENCE of one component, the OID ecdsa-with-*).

In the past, we've solve this problem with the weasel wording for hash
algorithm parameters, but do we want to continue along this path? Is there a
widely deployed base of ES ECDH with EnvelopedData and did anybody do
something different than what RFC5008 says for ECDSA (i.e., absent
parameters when you use ecdsa-with-sha*)?

spt

>-----Original Message-----
>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of Jim Schaad
>Sent: Thursday, August 14, 2008 9:01 AM
>To: Sean P. Turner
>Cc: Ietf-Smime
>Subject: Comments on draft-ietf-smime-3278bis-01.txt 
>
>
>Section 1.2

I fixed these and found some other instances of SHA1 that should have been
SHA-1. 

>Section 2.3.2 -- "SignerInfosignature" --> SignerInfo.signature

Fixed.

>Snide remark - Can you use ECDH with CMS EnvelopedData w/o key 

No ;)

>Section 3. - Is it permitted to do ECC static-static?

I believe it's permitted, but nobody asked for it so the RFC3278 authors
didn't include it.  Since ES DH was the MUST I assume they went with ES
ECDH. Do you want to add it?

>Section 3.1.1 - originator - The parameters SHOULD be ABSENT 
>not NULL.  This is 1) consistent with what is done for DH and 
>2) means that you don't have one more additional encoding 
>binding for the originator field as oppose to the parameters 

I think we should be doing what DH does and just have absent parameters.

>Section 3.1.1 - please justify the requirement for DER 

I assume there isn't one and this was a cut-and-paste from the other field.
We'd just drop the DER part and the sentence would read as follows: "The
originatorKey publicKey field MUST contain the value of the ASN.1 type
ECPoint (see Section 8.2), which represents the sending agent's ephemeral EC
public key."

>Section 3.1.1 - what about the ukm field?

The "but with the following restrictions:" before the bullets leads me to
believe there are no restrictions on the other 3 fields.  I assume you're
asking for more text and we could add a blurb about ukm being absent.  If we
add something about ukm we may just add something about the other fields and
change the intro sentence.

>Section 3.2 - I don't understand why ES ECDH cannot be used 
>for AuthenticatedData.  We can use the DH algorithm with it.  
>I can understand if you want to state that some ADDITIONAL 
>security properties exist from using 1-pass ECMQV.

I dug through the mail archives and found a thread between Francois
Rousseau, Dan Brown, and Simon Blake Wilson in March 2001.  Before we add
it, I think we'd need to address the points raised.  Here's how it went:
---
a. Sections 1, 3.2, 4.1 and 8.2, it is not clear why only the ECMQV key
agreement algorithm is supported with AuthenticatedData and not also the
ECDH key agreement algorithm. Although ECMQV is comparable to KEA, which can
also be used with AuthenticatedData, ECDH is the analog to the X9.42
Diffie-Hellman key agreement algorithm specified in RFC 2630 and is the
default algorithm with AuthenticatedData.

--> We looked at RFC 2630 which specifies the use of ephemeral-static
Diffie-Hellman within AuthenticatedData---but we didn't understand how this
mechanism provides authentication of the sender since the sender is not
certified. We didn't want to include the analogous technique based on these
concerns.

FR> However, as indicated in Section 4 of your ID, AuthenticatedData lacks
non-repudiation, and so in some instances is preferable to SignedData (For
example, the sending agent may not want the message to be authenticated when
forwarded). Using ephemeral-static ECDH within AuthenticatedData can achieve
this goal, but not necessarily ECMQV or static-static ECDH, which both
require a certified public key from the sender. As per Section 9 of RFC
2630, the goal of AuthenticatedData is to protect the integrity of the
content, but not to necessarily provide authentication of the sender. Note
also that RFC 2631 specifies both the ephemeral-static and the static-static
Diffie-Hellman modes.

--> Of course we could have included static-static ECDH, but this would
involve a fixed Diffie-Hellman "shared secret" (Z) between each pair of
correspondents, which seems undesirable.

FR> True, but I though this was the reason under Section 8.2 of your ID that
the octet string ukm in the entityUInfo field of the ECC-CMS-SharedInfo
could optionally be supplied by the sending agent. By mandating the use of
the octet string ukm with the static-static ECDH, you would certainly avoid
this undesirable effect. Similarly, in Section 2.1.2 of RFC 2631, the
partyAInfo MUST be used in Static-Static mode, but MAY appear in
Ephemeral-Static mode to avoid this same undesirable effect.

--> Make sense? Can anyone explain how ephemeral-static Diffie-Hellman
provides security with AuthenticatedData?

FR> I do not consider myself an expert with AuthenticatedData, but see my
two responses above.
---
>Section 3.2.1 - for the bullet ukm - the last sentence makes 
>no sense--- Part of the problem is that the next paragraph is 
>not further indented.

This was typo. The paragraph after it should have been connected to the ukm
paragraph.

>Section 3.2.1 - I would recommend for algorithm that absent 
>rather than NULL be used to simplify encoding/decoding steps

See intro.

>Section 3.2.2 - what are the domain parameters the same as?

The check is that the recipient's domain parameters and the sender's domain
parameters are the same. Will add ", as the sender's domain parameters" to
the end of that sentence.

>Section 3.2.3 - where does the additional ukm come from  It 
>is/is not an ouptut of the key deployment/agreement algorithm?

The sentence was missing something from 3278. It should read: "The receiving
agent then retrieves the static and ephemeral EC public keys of the
originator, from the originator and ukm fields [as described in Section
3.2.1, and its static EC public key identified in the rid] field and checks
that the domain parameters are the same."  Does this clear things up?

>Section 3.2.3 - Are there requirements/recommendations for 
>validating a sender's certificate?  Are there security 
>implications for not doing so?

I think we could add something about validating the certificate prior to
use.  We've been discussing something similar for the S/MIME v3.2 IDs. I'll
add a reference to the security considerations and will grab the text from
MSGbis.

>Section 5 - The first implementation requirement makes no 
>sense.  Nor does it provide for interop.  It makes more sense 
>to talk about SignedData conformance w/ the spec or Encryption 
>conformance w/ the spec.

I'm happy to recast these.

>Section 5 - Why does ECDH care that P-256 curve be used with 
>SHA-256?  What is this paragraph trying to state?

It doesn't care. I mistakenly added the ECDH, or ECMQV to the paragraph it
should only be about ECDSA.

>Section 5 - What is sha1kdf - where is this referenced?  Is 
>the what the previous paragraph is talking about?

These are defined later.  I'll add a reference to the paragraph.

>Section 5 - Are the KDF functions referenced here defined 
>using an object identifier in the X9.62 specifications?  If so 
>it would be good to include those OIDs in the ASN.1 module. 
>(No private opinion)

Yes they use the OIDs from X9.62 and they are included in the modules.

>Section 5 - Need to do some type of reference to where all of 
>the key wrap and content encryption algorithms are defined.

Agreed.

>Section 8.1 - Has the following text:
>   I thought that there were ec domain parameters that were to 
>be encoded with the public key.  Where else would this be 
>used?  Is this from the OriginatorKey clause above that I 
>think is incorrect?

In this ID it's only used in the OriginatorKey clause.  I'd change the
following "The following object identifier is used in this document to
indicate an elliptic curve public key:" to "The following object identifier
is used in this document to indicate an elliptic curve public key in the
OriginatorKey field:" and change "When the object identifier id-ecPublicKey
is used here with an algorithm identifier, the associated parameters contain
NULL" to "When the object identifier id-ecPublicKey is used here with an
algorithm identifier, the associated parameters contain are absent."

>Section 8.1 - for ecdas-with-*, is it considered acceptable to 
>have absent parameters?

See intro.

>        It is not clear from the text at the end of the last 
>paragraph in this section.  Many people use OID and "algorithm 
>identifier" as the same thing.

How about: When the object identifiers are used here within an algorithm
identifier, the associated parameters field contains the KeyWrapAlgorithm
field, which indicates the key wrap algorithm and any assoicated parameters.

>Section 8.2  What happens for keyInfo if the key wrap 
>algorithm actually has parameters?

I think this is wrong.  It ought to allow for parameters and absent
parameters (i.e., for aes*-wrap).  I propose:
Old: keyInfo contains the object identifier of the key-encryption algorithm
(used to wrap the CEK) and NULL parameters.
New: keyInfo contains the object identifier of the key-encryption algorithm
(used to wrap the CEK) and associated parameters. In this specification,
3DES wrap has NULL parameters while the AES wraps have absent parameters.

>Section 8.2 - suppPubInfo - Since AES128 is the required key 
>wrap, use that for the example not 3DES

Fixed.

Still working on these:

>Section 3.2.2 - Please elaborate on the re-used statement in 
>the last paragraph.  Can be re-used for what?  for how long?  
>why can't it be re-used for encrypted data?
>
>Section 3.2.2 - if you re-use the ephemeral - what does/does 
>not need to be changed?  The additional ukm?

I'm leaning towards deleting this sentnece and the similar sentences in
4.1.2 and 4.2.2.

>Section 4.1.2 - Note:  There is a legal attack where by the 
>recipient modifies the content and goes to court with the 
>modified content.  Unless you bind the output MAC in with the 
>MAC key, you cannot prevent this type of attack.

Not sure what to do with this one.

---

From: "Jim Schaad" <[email-masked]>
Date: Tue, 26 Aug 2008 15:07:20 -0400

Sean,

I have removed items that I considered to be completed

Jim

> From: [email-masked] [mailto:owner-ietf-
> [email-masked]] On Behalf Of Turner, Sean P.
> Sent: Thursday, August 21, 2008 6:10 PM
> To: 'Jim Schaad'; [email-masked]
> Subject: RE: Comments on draft-ietf-smime-3278bis-01.txt
> 
> 
> Jim,
> 

The major problem I have this text as it stands, is that the associated of
OID and ASN.1 type becomes different for when it appears in an originator
key vs when it appears in a public key (i.e. certificate).  In theory, there
should actually not be a problem with having the full domain parameters
appear in the originator key field, although the reciver should check that
the parameters match those used for their key.

> ECDH. Do you want to add it?

We did allow for static-static DH, analogy says we might want to include it.
The question would be 1) would it be used (probably not) and 2) is there a
community that might thing you should validate the senders certificate prior
to decrypting a message (there were such communities, I think they have been
sufficiently discouraged from the practice).

I think a simple sentence -- Static-Static is not covered in this document,
the MQV method provides for better security, if you want to use ECSS - it is
analogous.  (clean up the language).

> I think we should be doing what DH does and just have absent

Issue open

> ECPoint (see Section 8.2), which represents the sending agent's

????

> change the intro sentence.

Text needs to be included as to what goes into the UKM field  - specifically
it also needs to say where and how to use the ukm material in the (I assume)
ECC-CMS-SharedInfo structure to be used during key derivation.

> certified. We didn't want to include the analogous technique based on

This is the key issue - Authenticated data DOES NOT provide data origination
assurance.  All it says is that the data was not modified during "transit".
It does not say that the data is the same as the original sender.

> add a reference to the security considerations and will grab the text

This is a problem of what AuthenticatedData provides vs what they think it
provides - see above comment.

> Yes they use the OIDs from X9.62 and they are included in the modules.

I don't see any identifier for sha1kdf (or what I would consider and
equivalent).  There are ones for the entire scheme, but not for this piece
of the scheme.

> algorithm identifier, the associated parameters contain are absent."

Result may be modified by discussion from top of mail message

> >Section 8.1 - for ecdas-with-*, is it considered acceptable to

Open

> field, which indicates the key wrap algorithm and any assoicated

Combined with a clarification in the ASN.1 - this should be fine

> 3DES wrap has NULL parameters while the AES wraps have absent

Fine

> Not sure what to do with this one.

This is part and parcel of the question of what AuthenticatedData does or
does not provide as a security service.  Fix that concept and this goes
away.

Jim

From: "Jim Schaad" <[email-masked]>
To: "'Turner, Sean P.'" <[email-masked]>, <[email-masked]>
Subject: RE: Comments on draft-ietf-smime-3278bis-01.txt 
Date: Tue, 26 Aug 2008 15:07:20 -0400
Sender: [email-masked]

Sean,

I have removed items that I considered to be completed

Jim

> From: [email-masked] [mailto:owner-ietf-
> [email-masked]] On Behalf Of Turner, Sean P.
> Sent: Thursday, August 21, 2008 6:10 PM
> To: 'Jim Schaad'; [email-masked]
> Subject: RE: Comments on draft-ietf-smime-3278bis-01.txt
> 
> 
> Jim,
> 

The major problem I have this text as it stands, is that the associated of
OID and ASN.1 type becomes different for when it appears in an originator
key vs when it appears in a public key (i.e. certificate).  In theory, there
should actually not be a problem with having the full domain parameters
appear in the originator key field, although the reciver should check that
the parameters match those used for their key.

> ECDH. Do you want to add it?

We did allow for static-static DH, analogy says we might want to include it.
The question would be 1) would it be used (probably not) and 2) is there a
community that might thing you should validate the senders certificate prior
to decrypting a message (there were such communities, I think they have been
sufficiently discouraged from the practice).

I think a simple sentence -- Static-Static is not covered in this document,
the MQV method provides for better security, if you want to use ECSS - it is
analogous.  (clean up the language).

> I think we should be doing what DH does and just have absent

Issue open

> ECPoint (see Section 8.2), which represents the sending agent's

????

> change the intro sentence.

Text needs to be included as to what goes into the UKM field  - specifically
it also needs to say where and how to use the ukm material in the (I assume)
ECC-CMS-SharedInfo structure to be used during key derivation.

> certified. We didn't want to include the analogous technique based on

This is the key issue - Authenticated data DOES NOT provide data origination
assurance.  All it says is that the data was not modified during "transit".
It does not say that the data is the same as the original sender.

> add a reference to the security considerations and will grab the text

This is a problem of what AuthenticatedData provides vs what they think it
provides - see above comment.

> Yes they use the OIDs from X9.62 and they are included in the modules.

I don't see any identifier for sha1kdf (or what I would consider and
equivalent).  There are ones for the entire scheme, but not for this piece
of the scheme.

> algorithm identifier, the associated parameters contain are absent."

Result may be modified by discussion from top of mail message

> >Section 8.1 - for ecdas-with-*, is it considered acceptable to

Open

> field, which indicates the key wrap algorithm and any assoicated

Combined with a clarification in the ASN.1 - this should be fine

> 3DES wrap has NULL parameters while the AES wraps have absent

Fine

> Not sure what to do with this one.

This is part and parcel of the question of what AuthenticatedData does or
does not provide as a security service.  Fix that concept and this goes
away.

Jim

From: [email-masked]
To: [email-masked]
Subject: I-D ACTION:draft-ietf-smime-3851bis-05.txt 
Date: Thu, 21 Aug 2008 16:30:01 -0700 (PDT)
Cc: [email-masked]
Reply-To: [email-masked]
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the S/MIME Mail Security Working Group of the IETF.

	Title		: Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification
	Author(s)	: B. Ramsdell, S. Turner
	Filename	: draft-ietf-smime-3851bis-05.txt
	Pages		: 45
	Date		: 2008-8-21
	
This document defines Secure/Multipurpose Internet Mail Extensions 
   (S/MIME) version 3.2.  S/MIME provides a consistent way to send and 
   receive secure MIME data.  Digital signatures provide authentication, 
   message integrity, and non-repudiation with proof of origin. 
Encryption provides data confidentiality.  Compression can be used to 
   reduce data size.  This document obsoletes RFC 3851.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-smime-3851bis-05.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body;
	name="draft-ietf-smime-3851bis-05.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <[email-masked]>

--NextPart
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

--NextPart--

From: [email-masked]
To: [email-masked]
Subject: I-D ACTION:draft-ietf-smime-3850bis-05.txt 
Date: Thu, 21 Aug 2008 16:30:01 -0700 (PDT)
Cc: [email-masked]
Reply-To: [email-masked]
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the S/MIME Mail Security Working Group of the IETF.

	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

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body;
	name="draft-ietf-smime-3850bis-05.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <[email-masked]>

--NextPart
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

--NextPart--

From: "Turner, Sean P." <[email-masked]>
To: <[email-masked]>
Subject: WG Last Call: draft-ietf-smime-rfc3851bis-05.txt
Date: Thu, 21 Aug 2008 20:33:22 -0400
Organization: IECA, Inc.
Sender: [email-masked]

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

 Title	: Secure/Multipurpose Internet Mail Extensions (S/MIME)
              Version 3.2 Message Specification
 Author(s)	: B. Ramsdell, S. Turner
 Filename	: draft-ietf-smime-3851bis-05.txt
 Pages	: 45
 Date		: 2008-8-21
	
This document defines Secure/Multipurpose Internet Mail Extensions (S/MIME)
version 3.2.  S/MIME provides a consistent way to send and receive secure
MIME data.  Digital signatures provide authentication, message integrity,
and non-repudiation with proof of origin. Encryption provides data
confidentiality.  Compression can be used to reduce data size.  This
document obsoletes RFC 3851.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-smime-3851bis-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: "Turner, Sean P." <[email-masked]>
To: <[email-masked]>
Subject: WG Last Call: draft-ietf-smime-rfc3850bis-05.txt
Date: Thu, 21 Aug 2008 20:32:42 -0400
Organization: IECA, Inc.
Sender: [email-masked]

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: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: I-D ACTION:draft-ietf-smime-3850bis-05.txt 
Date: Thu, 21 Aug 2008 16:30:01 -0700 (PDT)
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the S/MIME Mail Security Working Group of the IETF.

	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

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body;
	name="draft-ietf-smime-3850bis-05.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--NextPart--

From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: I-D ACTION:draft-ietf-smime-3851bis-05.txt 
Date: Thu, 21 Aug 2008 16:30:01 -0700 (PDT)
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the S/MIME Mail Security Working Group of the IETF.

	Title		: Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification
	Author(s)	: B. Ramsdell, S. Turner
	Filename	: draft-ietf-smime-3851bis-05.txt
	Pages		: 45
	Date		: 2008-8-21
	
This document defines Secure/Multipurpose Internet Mail Extensions 
   (S/MIME) version 3.2.  S/MIME provides a consistent way to send and 
   receive secure MIME data.  Digital signatures provide authentication, 
   message integrity, and non-repudiation with proof of origin. 
Encryption provides data confidentiality.  Compression can be used to 
   reduce data size.  This document obsoletes RFC 3851.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-smime-3851bis-05.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body;
	name="draft-ietf-smime-3851bis-05.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--NextPart--

From: "Turner, Sean P." <[email-masked]>
To: "'Jim Schaad'" <[email-masked]>, <[email-masked]>
Subject: RE: Comments on draft-ietf-smime-3278bis-01.txt 
Date: Thu, 21 Aug 2008 18:09:40 -0400
Organization: IECA, Inc.
Sender: [email-masked]

Jim,

All,

spt

Fixed.

No ;)

See intro.

Agreed.

See intro.

Fixed.

From: "Turner, Sean P." <[email-masked]>
To: "'Tony Capel'" <[email-masked]>, <[email-masked]>
Subject: RE: I-D ACTION:draft-ietf-smime-3850bis-04.txt 
Date: Wed, 20 Aug 2008 17:26:24 -0400
Organization: IECA, Inc.
Sender: [email-masked]

Tony,

I incorporated these comments in a version I'm about to post.  Minor tweaks
to the text for the CERT security considerations.

spt

>From: Tony Capel [mailto:[email-masked]] 
>Sent: Friday, August 08, 2008 3:41 PM
>To: 'Turner, Sean P.'; [email-masked]
>Subject: RE: I-D ACTION:draft-ietf-smime-3850bis-04.txt 
>
>Sean:
>
>I know you will be putting in some text to address Jim (and 
>my) request for text re key sizes > 4096 for CERT 3850bis.
>
>A directly related security concern, and one that has been 
>around for some time, is the potential for other inappropriate 
>processing if an offered end entity cert (or any offered cert 
>in the chain) is processed prior to, or irrespective of, being 
>validated to a trusted root.  In addition to the problem of a 
>large key, there is the potential of inappropriate CDP (and/or 
>AIA) defined action (e.g. web access to an inappropriate 
>address).  Rfc5280 [KEYM] has a comment* about making sure 
>that such an action does not download malicious code, but in 
>practice even correctly formed CDP/AIA access(es) could raise 
>denial of service or privacy concerns.  Normally a user agent 
>will time out on an invalid CDP/AIA address; but certificates 
>can contain many addresses....  Also, the CDP/AIA address 
>could point to a special address defined by the originator, e.g.
>allowing a spammer to validate receipt of a signed message 
>(even if the signature fails).
>
>So I wonder, for CERT, whether it would be best to be more 
>general when identifying these security concerns so that 
>issues in addition to the key size are included?
>
>Some possible text (for CERT only):
>
>"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 certificates to allow the 
>originator to detect receipt of the message even if signature 
>verification fails."
>
>The above would just identify the concern, not offer any 
>solutions - I suggest leaving how to be cautious up to the 
>implementer! 
>
>
>Finally, I am still concerned that we are not making support 
>for (RSA) 4096 bit keys FOR CERTIFICATE SIGNATURE VERIFICATION 
>ONLY mandatory, i.e. in section 4.3 of 3850bis.  In practice 
>this size is widely supported today, e.g. both MS and Mozilla 
>have many 4k certs in their root stores**.
>The discussion here is verification only, NOT signature 
>generation or decryption
>- mandating support for these I agree needs to be limited to 
>2k; the typical crypto size limit for hardware tokens.  
>However, signature verification is not normally done in the 
>token anyway; so this is not an issue.  In practice many 
>authorities are going to 4k root certs because they want to 
>issue them with long lifetimes (longer than end user certs, so 
>shorter keys in end user certs are ok).  We need to make sure 
>common e-mail clients building to v3.2 can work with these 
>common new 4k RSA root certs.  This comment ONLY affects 
>support for cert signature processing (3850bis section 4.3, 
>and even then maybe only for Certificates, not CRLs).
>
>
>Tony
>
>
>*Abstract from KEYM:
>  "Implementers should be aware of risks involved if the CRL
>   distribution points or authority information access extensions of
>   corrupted certificates or CRLs contain links to malicious code.
>   Implementers should always take the steps of validating the 
>retrieved
>   data to ensure that the data is properly formed."
>
>** See GeoTrust Universal CA in both MS and Mozilla root stores.
>
>| -----Original Message-----
>| From: [email-masked]
>| [mailto:[email-masked]] On Behalf Of Turner, Sean P.
>| Sent: July 28, 2008 4:18 PM
>| To: [email-masked]
>| Subject: RE: I-D ACTION:draft-ietf-smime-3850bis-04.txt
>| 
>| 
>| 
>| Other things Jim requested offline:
>|  - Point to PKIXALG as opposed to CMSALG, which makes sense 
>since this 
>| is the CERT ID.
>|  - Add back in changes from v3 to v3.1, which also makes 
>sense because 
>| the section should not have been removed.
>| 
>| spt
>| >-----Original Message-----
>| >From: Jim Schaad [mailto:[email-masked]]
>| >Sent: Monday, July 28, 2008 2:43 PM
>| >To: Sean P. Turner; 'Blake Ramsdell'
>| >Cc: [email-masked]
>| >Subject: RE: I-D ACTION:draft-ietf-smime-3850bis-04.txt
>| >
>| >Comments on the draft.
>| >
>| >In section 4.4.3, I find the following text confusing:
>| >
>| >End-entity certificates contain an extension that 
>| >   constrains the certificate from being an issuing authority 
>| >   certificate (see Section 4.4.2).
>| >
>| >
>| >I believe that this text might be better as it clarifies what is 
>| >being stated.  I.e. it is not the fact that basic constraints is 
>| >being used which actually does the mentioned
>| constraint.
>| >
>| >
>| >End-entity certificates contain the Key Usage extension which 
>| >restraints the end-entity from using the key to perform issuing 
>| >authority operations (see
>| >4.4.4)
>| >
>| >Also the previous comment (on 3851bis) on key sizes > 4096 
>should be 
>| >applied to this document
>| >
>| >jim
>| >
>| >> -----Original Message-----
>| >> From: [email-masked] [mailto:owner-ietf- 
>| >> [email-masked]] On Behalf Of [email-masked]
>| >> Sent: Tuesday, July 01, 2008 1:30 AM
>| >> To: [email-masked]
>| >> Cc: [email-masked]
>| >> Subject: I-D ACTION:draft-ietf-smime-3850bis-04.txt
>| >> 
>| >> A New Internet-Draft is available from the on-line 
>Internet-Drafts 
>| >> directories.
>| >> This draft is a work item of the S/MIME Mail Security
>| >Working Group of
>| >> the IETF.
>| >> 
>| >> 	Title		: Secure/Multipurpose Internet Mail Extensions
>| >> (S/MIME) Version 3.2 Certificate Handling
>| >> 	Author(s)	: S. Turner, B. Ramsdell
>| >> 	Filename	: draft-ietf-smime-3850bis-04.txt
>| >> 	Pages		: 20
>| >> 	Date		: 2008-6-30
>| >> 
>| >> 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
>| 3280bis, 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 3280bis. This document
>| >>    obsoletes RFC 3850.
>| >> 
>| >> A URL for this Internet-Draft is: 
>| >> 
>http://www.ietf.org/internet-drafts/draft-ietf-smime-3850bis-04.txt
>| >> 
>| >> Internet-Drafts are also available by anonymous FTP at: 
>| >> ftp://ftp.ietf.org/internet-drafts/
>| >> 
>| >> Below is the data which will enable a MIME compliant mail reader 
>| >> implementation to automatically retrieve the ASCII version of the 
>| >> Internet-Draft.
>| >
>| 
>

Content-class: urn:content-classes:message
Subject: RE: Key size security considerations
Date: Wed, 20 Aug 2008 06:29:48 -0700
From: "Hallam-Baker, Phillip" <[email-masked]>
To: "Paul Hoffman" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

This is a multi-part message in MIME format.

------_=_NextPart_001_01C902C9.39BF1186
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Given what we know about the state of factoring algorithms I think that =
we could state that if your security needs demand higher security than =
you get from 2048 bit RSA you should consider a different algorithm and =
certainly at 4096.
=20
=20

________________________________

From: [email-masked] on behalf of Paul Hoffman
Sent: Sat 8/9/2008 9:15 PM
To: [email-masked]
Subject: Key size security considerations

Earlier, I proposed  a replacement for part of the security
considerations in 3851bis (S/MIME message). The current text reads:

    Larger keys are not necessarily better keys.  Larger keys take more
    computational resources, and this can quickly become impractical.  =
In
    fact, support for an excessively large key offers a denial of =
service
    opportunity if the attacker can cause excessive cryptographic
    processing by providing such a public key.  One mitigation approach
    would require that the corresponding public key certificate be
    validated to a trust anchor prior to use, thus ensuring that only
    trusted public keys are used.  However, some implementations may
    choose to perform signature verification (or key establishment for
    encryption) in parallel with certificate validation, even if
    certificate validation fails.  In such cases, measures should be
    included to limit the impact, for example by limiting cryptographic
    processing time or requiring certificate validation prior to the use
    of large keys.

There is no parallel text in 3850bis.

There has been some good discussion, and I now propose different,
more general wording that should be included in both documents. This
would replace the above paragraph in 3851bis and be added to 3850bis.

Sending and receiving agents need to be cautious of CPU usage and
other resources when handling public keys larger than those mandated
in this specification (that is, larger than 2048 bits). For example,
an attacker can send very large, bogus signatures in order to swamp
the CPU of the receiving party. Another example is that an attacker
can try to cause a sender to try to encrypt with a very large key.
One mitigation approach would require that the corresponding public
key certificate be validated to a trust anchor prior to use, thus
ensuring that only trusted public keys are used.  However, some
implementations may choose to perform signature verification (or key
establishment for encryption) in parallel with certificate
validation, even if certificate validation fails. Sending and
receiving parties are advised to have some sort of resource
management system to prevent such attacks.

------_=_NextPart_001_01C902C9.39BF1186
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<HTML dir=3Dltr><HEAD><TITLE>Key size security considerations</TITLE>=0A=
<META http-equiv=3DContent-Type content=3D"text/html; charset=3Dunicode">=0A=
<META content=3D"MSHTML 6.00.6000.16711" name=3DGENERATOR></HEAD>=0A=
<BODY>=0A=
<DIV id=3DidOWAReplyText46753 dir=3Dltr>=0A=
<DIV dir=3Dltr><FONT face=3DArial color=3D#000000 size=3D2>Given what we =
know about the state of factoring algorithms I think that we could state =
that if your security needs demand higher security than you get from =
2048 bit RSA you should consider a different algorithm and certainly at =
4096.</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>=0A=
<DIV dir=3Dltr>&nbsp;</DIV></DIV>=0A=
<DIV dir=3Dltr><BR>=0A=
<HR tabIndex=3D-1>=0A=
<FONT face=3DTahoma size=3D2><B>From:</B> [email-masked] =
on behalf of Paul Hoffman<BR><B>Sent:</B> Sat 8/9/2008 9:15 =
PM<BR><B>To:</B> [email-masked]<BR><B>Subject:</B> Key size security =
considerations<BR></FONT><BR></DIV>=0A=
<DIV><BR>=0A=
<P><FONT size=3D2>Earlier, I proposed&nbsp; a replacement for part of =
the security<BR>considerations in 3851bis (S/MIME message). The current =
text reads:<BR><BR>&nbsp;&nbsp;&nbsp; Larger keys are not necessarily =
better keys.&nbsp; Larger keys take more<BR>&nbsp;&nbsp;&nbsp; =
computational resources, and this can quickly become impractical.&nbsp; =
In<BR>&nbsp;&nbsp;&nbsp; fact, support for an excessively large key =
offers a denial of service<BR>&nbsp;&nbsp;&nbsp; opportunity if the =
attacker can cause excessive cryptographic<BR>&nbsp;&nbsp;&nbsp; =
processing by providing such a public key.&nbsp; One mitigation =
approach<BR>&nbsp;&nbsp;&nbsp; would require that the corresponding =
public key certificate be<BR>&nbsp;&nbsp;&nbsp; validated to a trust =
anchor prior to use, thus ensuring that only<BR>&nbsp;&nbsp;&nbsp; =
trusted public keys are used.&nbsp; However, some implementations =
may<BR>&nbsp;&nbsp;&nbsp; choose to perform signature verification (or =
key establishment for<BR>&nbsp;&nbsp;&nbsp; encryption) in parallel with =
certificate validation, even if<BR>&nbsp;&nbsp;&nbsp; certificate =
validation fails.&nbsp; In such cases, measures should =
be<BR>&nbsp;&nbsp;&nbsp; included to limit the impact, for example by =
limiting cryptographic<BR>&nbsp;&nbsp;&nbsp; processing time or =
requiring certificate validation prior to the use<BR>&nbsp;&nbsp;&nbsp; =
of large keys.<BR><BR>There is no parallel text in 3850bis.<BR><BR>There =
has been some good discussion, and I now propose different,<BR>more =
general wording that should be included in both documents. This<BR>would =
replace the above paragraph in 3851bis and be added to =
3850bis.<BR><BR>Sending and receiving agents need to be cautious of CPU =
usage and<BR>other resources when handling public keys larger than those =
mandated<BR>in this specification (that is, larger than 2048 bits). For =
example,<BR>an attacker can send very large, bogus signatures in order =
to swamp<BR>the CPU of the receiving party. Another example is that an =
attacker<BR>can try to cause a sender to try to encrypt with a very =
large key.<BR>One mitigation approach would require that the =
corresponding public<BR>key certificate be validated to a trust anchor =
prior to use, thus<BR>ensuring that only trusted public keys are =
used.&nbsp; However, some<BR>implementations may choose to perform =
signature verification (or key<BR>establishment for encryption) in =
parallel with certificate<BR>validation, even if certificate validation =
fails. Sending and<BR>receiving parties are advised to have some sort of =
resource<BR>management system to prevent such =
attacks.<BR><BR></FONT></P></DIV></BODY></HTML>
------_=_NextPart_001_01C902C9.39BF1186--

From: Timothy J Miller <[email-masked]>
To: [email-masked]
Subject: Anyone know of any specific opaque signed verification issues in Apple Mail?
Date: Tue, 19 Aug 2008 12:29:25 -0500
Sender: [email-masked]

--Apple-Mail-1-341603249
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed;
	delsp=yes
Content-Transfer-Encoding: 7bit

Blackberries with the S/MIME support package produce opaque signed S/ 
MIME, which I can read in just about every client (including OpenSSL)  
except Apple Mail.  I know Apple tends to take a strict approach when  
it comes to some parts of S/MIME (e.g., they're the only S/MIME MUA in  
common use that enforces case sensitivity in the local-part of an  
email address when matching sender to certificate) so I was wondering  
if this was another case of that.

Anyone know about any strictness issues or other bugs on this before I  
report it to Apple?

-- Tim

--Apple-Mail-1-341603249
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

--Apple-Mail-1-341603249--

From: "Jim Schaad" <[email-masked]>
To: "Sean P. Turner" <[email-masked]>
Cc: "Ietf-Smime" <[email-masked]>
Subject: Comments on draft-ietf-smime-3278bis-01.txt 
Date: Thu, 14 Aug 2008 23:00:53 +1000
Sender: [email-masked]

Section 1.2

From: [email-masked]
To: [email-masked]
Subject: I-D ACTION:draft-ietf-smime-ibearch-07.txt 
Date: Fri,  8 Aug 2008 10:45:02 -0700 (PDT)
Cc: [email-masked]
Reply-To: [email-masked]
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the S/MIME Mail Security Working Group of the IETF.

	Title		: Identity-based Encryption Architecture and Supporting Data Structures
	Author(s)	: M. Schertler
	Filename	: draft-ietf-smime-ibearch-07.txt
	Pages		: 37
	Date		: 2008-8-8
	
This document describes the security architecture required to 
     implement identity-based encryption, a public-key encryption 
     technology that uses a user's identity as a public key. It 
     also defines data structures that can be used to implement the 
     technology.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-smime-ibearch-07.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body;
	name="draft-ietf-smime-ibearch-07.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <[email-masked]>

--NextPart
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

--NextPart--

From: "Tony Capel" <[email-masked]>
To: "'Turner, Sean P.'" <[email-masked]>, <[email-masked]>, "'Hoffman, Paul'" <[email-masked]>
Subject: RE: I-D ACTION:draft-ietf-smime-3850bis-04.txt 
Date: Mon, 11 Aug 2008 10:54:09 -0400
Importance: Normal
Sender: [email-masked]

| 
| >-----Original Message-----
| 
| Snip
| 
| >Some possible text (for CERT only):
| >
| >"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 certificates to allow the 
| >originator to detect receipt of the message even if signature 
| >verification fails."
| >
| >The above would just identify the concern, not offer any
| >solutions - I suggest leaving how to be cautious up to the 
| >implementer! 
| 
| Since Paul's replacement text removes the part about path 
| validation I like the idea of moving it to CERT.  Not sure I 
| understand the last sentence (how is the originator going to 
| insert fields in their certificate)? 

"Insert" may have been a misleading. I meant that its pretty
 easy* for an originator to create an end user cert
 (and possibly zero or more intermediate certificates)
 with selected content (including bad keys, arbitrary CDP/AIA
 URI entries, etc.)). These would not validate to a trust
 anchor, but IF they are processed anyway, the originator could
 get a receiver to use a large key, execute a specified URI, etc.
 So for CERT the problem is not only bad keys.

I do not suggest addressing anything other than bad keys in
 MSG, since I think the above additional issues (other certificate
 content) is a CERT processing issue not an MSG issue.  (For MSG its
 only the use of a key requiring excessive processing, and
 the mitigation measures are related to MSG crypto processing 
 and your point about time-out is good for MSG.)

|                                       I also don't want to 
| loose the ideas that we had in MSG about ensuring only 
| trusted keys are used before use and that a time-out isn't a 
| bad idea. That is I'd like to keep the following text:
| 
| One approach would require that the corresponding public key 
| certificate be validated to a trust anchor prior to use, thus 
| ensuring that only trusted public keys are used.  However, 
| some implementations may choose to perform signature 
| verification (or key establishment for encryption) in 
| parallel with certificate validation, even if certificate 
| validation fails.  In such cases, measures should be  
| included to limit the impact, for example by limiting 
| cryptographic  processing time or requiring certificate 
| validation prior to the use of large keys. 
| 

| >Finally, I am still concerned that we are not making support
| >for (RSA) 4096 bit keys FOR CERTIFICATE SIGNATURE VERIFICATION 
| >ONLY mandatory, i.e. in section 4.3 of 3850bis.  In practice 
| >this size is widely supported today, e.g. both MS and Mozilla 
| >have many 4k certs in their root stores**.
| >The discussion here is verification only, NOT signature 
| >generation or decryption
| >- mandating support for these I agree needs to be limited to 
| >2k; the typical crypto size limit for hardware tokens.  
| >However, signature verification is not normally done in the 
| >token anyway; so this is not an issue.  In practice many 
| >authorities are going to 4k root certs because they want to 
| >issue them with long lifetimes (longer than end user certs, so 
| >shorter keys in end user certs are ok).  We need to make sure 
| >common e-mail clients building to v3.2 can work with these 
| >common new 4k RSA root certs.  This comment ONLY affects 
| >support for cert signature processing (3850bis section 4.3, 
| >and even then maybe only for Certificates, not CRLs).
| 
| Unless I've misread my email from before, Paul objected to 
| having requirements on the verifiers that are in excess of 
| the  signers and that it's really more of a current practice 
| as opposed to an interoperability requirement.  Paul correct 
| me if I'm wrong.

This does not impose differing requirements on smime signers and
verifiers. I think both smime signers and verifiers need 4k 
support for certificate (and CRL) verification only.  I expect
these 4k certificates and CRLs to be created by certificate
authorities so only they need to create the 4k signatures. 

Tony

* i.e. the perpetrator could set up a CA and generate these certificates.

>>cut

Date: Sat, 9 Aug 2008 18:15:11 -0700
To: <[email-masked]>
From: Paul Hoffman <[email-masked]>
Subject: Key size security considerations
Sender: [email-masked]

Earlier, I proposed  a replacement for part of the security 
considerations in 3851bis (S/MIME message). The current text reads:

    Larger keys are not necessarily better keys.  Larger keys take more
    computational resources, and this can quickly become impractical.  In
    fact, support for an excessively large key offers a denial of service
    opportunity if the attacker can cause excessive cryptographic
    processing by providing such a public key.  One mitigation approach
    would require that the corresponding public key certificate be
    validated to a trust anchor prior to use, thus ensuring that only
    trusted public keys are used.  However, some implementations may
    choose to perform signature verification (or key establishment for
    encryption) in parallel with certificate validation, even if
    certificate validation fails.  In such cases, measures should be
    included to limit the impact, for example by limiting cryptographic
    processing time or requiring certificate validation prior to the use
    of large keys.

There is no parallel text in 3850bis.

There has been some good discussion, and I now propose different, 
more general wording that should be included in both documents. This 
would replace the above paragraph in 3851bis and be added to 3850bis.

Sending and receiving agents need to be cautious of CPU usage and 
other resources when handling public keys larger than those mandated 
in this specification (that is, larger than 2048 bits). For example, 
an attacker can send very large, bogus signatures in order to swamp 
the CPU of the receiving party. Another example is that an attacker 
can try to cause a sender to try to encrypt with a very large key. 
One mitigation approach would require that the corresponding public 
key certificate be validated to a trust anchor prior to use, thus 
ensuring that only trusted public keys are used.  However, some 
implementations may choose to perform signature verification (or key 
establishment for encryption) in parallel with certificate 
validation, even if certificate validation fails. Sending and 
receiving parties are advised to have some sort of resource 
management system to prevent such attacks.

From: "Turner, Sean P." <[email-masked]>
To: "'Tony Capel'" <[email-masked]>, <[email-masked]>, "Hoffman, Paul" <[email-masked]>
Subject: RE: I-D ACTION:draft-ietf-smime-3850bis-04.txt 
Date: Sat, 9 Aug 2008 18:45:42 -0400
Organization: IECA, Inc.
Sender: [email-masked]

>-----Original Message-----

Snip

>Some possible text (for CERT only):
>
>"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 certificates to allow the 
>originator to detect receipt of the message even if signature 
>verification fails."
>
>The above would just identify the concern, not offer any 
>solutions - I suggest leaving how to be cautious up to the 
>implementer! 

Since Paul's replacement text removes the part about path validation I like
the idea of moving it to CERT.  Not sure I understand the last sentence (how
is the originator going to insert fields in their certificate)?  I also
don't want to loose the ideas that we had in MSG about ensuring only trusted
keys are used before use and that a time-out isn't a bad idea. That is I'd
like to keep the following text:

One approach would require that the corresponding public key certificate be
validated to a trust anchor prior to use, thus ensuring that only trusted
public keys are used.  However, some implementations may choose to perform
signature verification (or key establishment for encryption) in parallel
with certificate validation, even if certificate validation fails.  In such
cases, measures should be  included to limit the impact, for example by
limiting cryptographic  processing time or requiring certificate validation
prior to the use of large keys. 

>Finally, I am still concerned that we are not making support 
>for (RSA) 4096 bit keys FOR CERTIFICATE SIGNATURE VERIFICATION 
>ONLY mandatory, i.e. in section 4.3 of 3850bis.  In practice 
>this size is widely supported today, e.g. both MS and Mozilla 
>have many 4k certs in their root stores**.
>The discussion here is verification only, NOT signature 
>generation or decryption
>- mandating support for these I agree needs to be limited to 
>2k; the typical crypto size limit for hardware tokens.  
>However, signature verification is not normally done in the 
>token anyway; so this is not an issue.  In practice many 
>authorities are going to 4k root certs because they want to 
>issue them with long lifetimes (longer than end user certs, so 
>shorter keys in end user certs are ok).  We need to make sure 
>common e-mail clients building to v3.2 can work with these 
>common new 4k RSA root certs.  This comment ONLY affects 
>support for cert signature processing (3850bis section 4.3, 
>and even then maybe only for Certificates, not CRLs).

Unless I've misread my email from before, Paul objected to having
requirements on the verifiers that are in excess of the  signers and that
it's really more of a current practice as opposed to an interoperability
requirement.  Paul correct me if I'm wrong.

>Tony
>
>
>*Abstract from KEYM:
>  "Implementers should be aware of risks involved if the CRL
>   distribution points or authority information access extensions of
>   corrupted certificates or CRLs contain links to malicious code.
>   Implementers should always take the steps of validating the 
>retrieved
>   data to ensure that the data is properly formed."
>
>** See GeoTrust Universal CA in both MS and Mozilla root stores.
>

Date: Sat, 9 Aug 2008 07:23:42 -0700
To: "Tony Capel" <[email-masked]>, "'Turner, Sean P.'" <[email-masked]>, "'Jim Schaad'" <[email-masked]>, "'Blake Ramsdell'" <[email-masked]>
From: Paul Hoffman <[email-masked]>
Subject: RE: I-D ACTION:draft-ietf-smime-3851bis-04.txt
Cc: <[email-masked]>
Sender: [email-masked]

At 5:51 PM -0400 8/8/08, Tony Capel wrote:
>1) I would prefer the security consideration apply to encryption as well as
>signature checking.  Although less likely, it could be a sending 
>agent who uses
>an intended receiver's unvalidated encryption certificate to get the 
>"big" key.

Someone who is encrypting blindly has many problems that just key 
size. We could add a warning about this as well, but it is should be 
a separate warning.

>I would not want the text to imply that this is ONLY a receiver 
>signature issue.

It is far easier to get someone to try to validate a signature than 
it is to get them to encrypt a message.

>2) The swamping is specifically related to the crypto element not necessarily
>the CPU (i.e. it may be the h/w token that is swamped).

Good point. I would be happy with "CPU or other resources".

From: "Tony Capel" <[email-masked]>
To: "'Turner, Sean P.'" <[email-masked]>, "'Paul Hoffman'" <[email-masked]>, "'Jim Schaad'" <[email-masked]>, "'Blake Ramsdell'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: I-D ACTION:draft-ietf-smime-3851bis-04.txt
Date: Fri, 8 Aug 2008 17:51:11 -0400
Importance: Normal
Sender: [email-masked]

My problems with the proposed text are:

1) I would prefer the security consideration apply to encryption as well =
as
signature checking.  Although less likely, it could be a sending agent =
who uses
an intended receiver's unvalidated encryption certificate to get the =
"big" key.
I would not want the text to imply that this is ONLY a receiver =
signature issue.
We should probably not make assumptions about how the certificates are
distributed and we need to address dual keypair use (the signing =
certificate
could be ok, but the encryption cert could be bad - a "time-bomb"?).  I =
agree
that implementers have more options to address the encryption case (not
beginning encryption until cert validation is done) but many =
implementers allow
encryption certificates to be manually marked as "trusted" - and it is =
not clear
that everyone only starts the encryption operations after successful =
cert
validation.  So my preference is to be generic: "be careful about using =
big keys
from unvalidated end user certs to validate signatures or encrypt".

2) The swamping is specifically related to the crypto element not =
necessarily
the CPU (i.e. it may be the h/w token that is swamped).

As per my post earlier today to the 3850bis list, the CERT security
considerations may be a bit more complex so having a separate discussion =
there
might be a good idea.

Tony

| -----Original Message-----
| From: [email-masked]=20
| [mailto:[email-masked]] On Behalf Of Turner, Sean P.
| Sent: August 8, 2008 4:09 PM
| To: 'Paul Hoffman'; 'Jim Schaad'; 'Blake Ramsdell'
| Cc: [email-masked]
| Subject: RE: I-D ACTION:draft-ietf-smime-3851bis-04.txt
|=20
|=20
|=20
| >-----Original Message-----
| >From: Paul Hoffman [mailto:[email-masked]]
| >Sent: Thursday, August 07, 2008 6:51 PM
| >To: Turner, Sean P.; 'Jim Schaad'; 'Blake Ramsdell'
| >Cc: [email-masked]
| >Subject: RE: I-D ACTION:draft-ietf-smime-3851bis-04.txt
| >
| >At 1:42 PM -0400 8/7/08, Turner, Sean P. wrote:
| >>  >Proposed wording:
| >>>
| >>>Receiving agents that validate signatures need to be=20
| cautious of CPU
| >>>usage when validating signatures larger than those=20
| mandated in this=20
| >>>specification. An attacker can send very large, bogus=20
| signatures in=20
| >>>order to swamp the CPU of the receiving party. Receiving=20
| >parties that
| >>>verify large signatures are advised to have some sort of resource
| >>>management system to prevent such an attack.
| >>
| >>Is this in addition to or to replace the para that starts
| >"Larger keys
| >>are not" in 3851bis Sec 5?
| >
| >Replace.
|=20
| I'm happy with replace, as long as we move the certificate=20
| path validation stuff to [CERT].  Russ, Steve, and Tony all=20
| suggested something about making sure the keys are validated=20
| prior to use.
|=20
| spt
|=20

From: "Turner, Sean P." <[email-masked]>
To: "'Paul Hoffman'" <[email-masked]>, "'Jim Schaad'" <[email-masked]>, "'Blake Ramsdell'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: I-D ACTION:draft-ietf-smime-3851bis-04.txt
Date: Fri, 8 Aug 2008 16:09:28 -0400
Organization: IECA, Inc.
Sender: [email-masked]

>From: Paul Hoffman [mailto:[email-masked]] 
>Sent: Thursday, August 07, 2008 6:51 PM
>To: Turner, Sean P.; 'Jim Schaad'; 'Blake Ramsdell'
>Cc: [email-masked]
>Subject: RE: I-D ACTION:draft-ietf-smime-3851bis-04.txt
>
>At 1:42 PM -0400 8/7/08, Turner, Sean P. wrote:
>>  >Proposed wording:
>>>
>>>Receiving agents that validate signatures need to be cautious of CPU 
>>>usage when validating signatures larger than those mandated in this 
>>>specification. An attacker can send very large, bogus signatures in 
>>>order to swamp the CPU of the receiving party. Receiving 
>parties that 
>>>verify large signatures are advised to have some sort of resource 
>>>management system to prevent such an attack.
>>
>>Is this in addition to or to replace the para that starts 
>"Larger keys 
>>are not" in 3851bis Sec 5?
>
>Replace.

I'm happy with replace, as long as we move the certificate path validation
stuff to [CERT].  Russ, Steve, and Tony all suggested something about making
sure the keys are validated prior to use.

spt

From: "Tony Capel" <[email-masked]>
To: "'Turner, Sean P.'" <[email-masked]>, <[email-masked]>
Subject: RE: I-D ACTION:draft-ietf-smime-3850bis-04.txt 
Date: Fri, 8 Aug 2008 15:40:39 -0400
Importance: Normal
Sender: [email-masked]

Sean:

I know you will be putting in some text to address Jim (and my) request =
for text
re key sizes > 4096 for CERT 3850bis.

A directly related security concern, and one that has been around for =
some time,
is the potential for other inappropriate processing if an offered end =
entity
cert (or any offered cert in the chain) is processed prior to, or =
irrespective
of, being validated to a trusted root.  In addition to the problem of a =
large
key, there is the potential of inappropriate CDP (and/or AIA) defined =
action
(e.g. web access to an inappropriate address).  Rfc5280 [KEYM] has a =
comment*
about making sure that such an action does not download malicious code, =
but in
practice even correctly formed CDP/AIA access(es) could raise denial of =
service
or privacy concerns.  Normally a user agent will time out on an invalid =
CDP/AIA
address; but certificates can contain many addresses....  Also, the =
CDP/AIA
address could point to a special address defined by the originator, e.g.
allowing a spammer to validate receipt of a signed message (even if the
signature fails).

So I wonder, for CERT, whether it would be best to be more general when
identifying these security concerns so that issues in addition to the =
key size
are included?

Some possible text (for CERT only):

"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 certificates to allow the originator to detect receipt =
of the
message even if signature verification fails."

The above would just identify the concern, not offer any solutions - I =
suggest
leaving how to be cautious up to the implementer!=20

Finally, I am still concerned that we are not making support for (RSA) =
4096 bit
keys FOR CERTIFICATE SIGNATURE VERIFICATION ONLY mandatory, i.e. in =
section 4.3
of 3850bis.  In practice this size is widely supported today, e.g. both =
MS and
Mozilla have many 4k certs in their root stores**.
The discussion here is verification only, NOT signature generation or =
decryption
- mandating support for these I agree needs to be limited to 2k; the =
typical
crypto size limit for hardware tokens.  However, signature verification =
is not
normally done in the token anyway; so this is not an issue.  In practice =
many
authorities are going to 4k root certs because they want to issue them =
with long
lifetimes (longer than end user certs, so shorter keys in end user certs =
are
ok).  We need to make sure common e-mail clients building to v3.2 can =
work with
these common new 4k RSA root certs.  This comment ONLY affects support =
for cert
signature processing (3850bis section 4.3, and even then maybe only for
Certificates, not CRLs).

Tony

*Abstract from KEYM:
  "Implementers should be aware of risks involved if the CRL
   distribution points or authority information access extensions of
   corrupted certificates or CRLs contain links to malicious code.
   Implementers should always take the steps of validating the retrieved
   data to ensure that the data is properly formed."

** See GeoTrust Universal CA in both MS and Mozilla root stores.

| -----Original Message-----
| From: [email-masked]=20
| [mailto:[email-masked]] On Behalf Of Turner, Sean P.
| Sent: July 28, 2008 4:18 PM
| To: [email-masked]
| Subject: RE: I-D ACTION:draft-ietf-smime-3850bis-04.txt=20
|=20
|=20
|=20
| Other things Jim requested offline:
|  - Point to PKIXALG as opposed to CMSALG, which makes sense=20
| since this is the CERT ID.
|  - Add back in changes from v3 to v3.1, which also makes=20
| sense because the section should not have been removed.
|=20
| spt
| >-----Original Message-----
| >From: Jim Schaad [mailto:[email-masked]]
| >Sent: Monday, July 28, 2008 2:43 PM
| >To: Sean P. Turner; 'Blake Ramsdell'
| >Cc: [email-masked]
| >Subject: RE: I-D ACTION:draft-ietf-smime-3850bis-04.txt=20
| >
| >Comments on the draft.
| >
| >In section 4.4.3, I find the following text confusing:
| >
| >End-entity certificates contain an extension that=20
| >   constrains the certificate from being an issuing authority=20
| >   certificate (see Section 4.4.2).
| >
| >
| >I believe that this text might be better as it clarifies what
| >is being stated.  I.e. it is not the fact that basic=20
| >constraints is being used which actually does the mentioned=20
| constraint.
| >
| >
| >End-entity certificates contain the Key Usage extension which
| >restraints the end-entity from using the key to perform=20
| >issuing authority operations (see
| >4.4.4)
| >
| >Also the previous comment (on 3851bis) on key sizes > 4096
| >should be applied to this document
| >
| >jim
| >
| >> -----Original Message-----
| >> From: [email-masked] [mailto:owner-ietf-
| >> [email-masked]] On Behalf Of [email-masked]
| >> Sent: Tuesday, July 01, 2008 1:30 AM
| >> To: [email-masked]
| >> Cc: [email-masked]
| >> Subject: I-D ACTION:draft-ietf-smime-3850bis-04.txt
| >>=20
| >> A New Internet-Draft is available from the on-line Internet-Drafts
| >> directories.
| >> This draft is a work item of the S/MIME Mail Security=20
| >Working Group of
| >> the IETF.
| >>=20
| >> 	Title		: Secure/Multipurpose Internet Mail Extensions
| >> (S/MIME) Version 3.2 Certificate Handling
| >> 	Author(s)	: S. Turner, B. Ramsdell
| >> 	Filename	: draft-ietf-smime-3850bis-04.txt
| >> 	Pages		: 20
| >> 	Date		: 2008-6-30
| >>=20
| >> This document specifies conventions for X.509 certificate usage by
| >>    Secure/Multipurpose Internet Mail Extensions (S/MIME) agents.=20
| >> S/MIME
| >>    provides a method to send and receive secure MIME messages, and
| >>    certificates are an integral part of S/MIME agent processing.=20
| >> S/MIME agents validate certificates as described in RFC=20
| 3280bis, the
| >>    Internet X.509 Public Key Infrastructure Certificate and CRL
| >> Profile.
| >>    S/MIME agents must meet the certificate processing=20
| requirements in
| >>    this document as well as those in RFC 3280bis. This document
| >>    obsoletes RFC 3850.
| >>=20
| >> A URL for this Internet-Draft is:=20
| >> http://www.ietf.org/internet-drafts/draft-ietf-smime-3850bis-04.txt
| >>=20
| >> Internet-Drafts are also available by anonymous FTP at:=20
| >> ftp://ftp.ietf.org/internet-drafts/
| >>=20
| >> Below is the data which will enable a MIME compliant mail reader
| >> implementation to automatically retrieve the ASCII version of the=20
| >> Internet-Draft.
| >
|=20

From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: I-D ACTION:draft-ietf-smime-ibearch-07.txt 
Date: Fri,  8 Aug 2008 10:45:02 -0700 (PDT)
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the S/MIME Mail Security Working Group of the IETF.

	Title		: Identity-based Encryption Architecture and Supporting Data Structures
	Author(s)	: M. Schertler
	Filename	: draft-ietf-smime-ibearch-07.txt
	Pages		: 37
	Date		: 2008-8-8
	
This document describes the security architecture required to 
     implement identity-based encryption, a public-key encryption 
     technology that uses a user's identity as a public key. It 
     also defines data structures that can be used to implement the 
     technology.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-smime-ibearch-07.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body;
	name="draft-ietf-smime-ibearch-07.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--NextPart--

Date: Thu, 7 Aug 2008 15:51:02 -0700
To: "Turner, Sean P." <[email-masked]>, "'Jim Schaad'" <[email-masked]>, "'Blake Ramsdell'" <[email-masked]>
From: Paul Hoffman <[email-masked]>
Subject: RE: I-D ACTION:draft-ietf-smime-3851bis-04.txt
Cc: <[email-masked]>
Sender: [email-masked]

At 1:42 PM -0400 8/7/08, Turner, Sean P. wrote:
>  >Proposed wording:
>>
>>Receiving agents that validate signatures need to be cautious
>>of CPU usage when validating signatures larger than those
>>mandated in this specification. An attacker can send very
>>large, bogus signatures in order to swamp the CPU of the
>>receiving party. Receiving parties that verify large
>>signatures are advised to have some sort of resource
>>management system to prevent such an attack.
>
>Is this in addition to or to replace the para that starts "Larger keys are
>not" in 3851bis Sec 5?

Replace.

From: "Turner, Sean P." <[email-masked]>
To: "'Paul Hoffman'" <[email-masked]>, "'Jim Schaad'" <[email-masked]>, "'Blake Ramsdell'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: I-D ACTION:draft-ietf-smime-3851bis-04.txt
Date: Thu, 7 Aug 2008 13:42:05 -0400
Organization: IECA, Inc.
Sender: [email-masked]

>From: Paul Hoffman [mailto:[email-masked]] 
>Sent: Wednesday, August 06, 2008 11:07 AM
>To: Jim Schaad; 'Sean P. Turner'; 'Blake Ramsdell'
>Cc: [email-masked]
>Subject: RE: I-D ACTION:draft-ietf-smime-3851bis-04.txt
>
>At 7:44 PM +1000 8/6/08, Jim Schaad wrote:
>>>  From: Paul Hoffman [mailto:[email-masked]]
>>>  Sent: Sunday, August 03, 2008 8:28 AM
>>>  To: Jim Schaad; Sean P. Turner; 'Blake Ramsdell'
>>>  Cc: [email-masked]
>>>  Subject: RE: I-D ACTION:draft-ietf-smime-3851bis-04.txt
>>>
>>>  At 2:17 PM +0100 7/28/08, Jim Schaad wrote:
>>>  >Comments on the draft:
>>>  >
>>>  >1.  We are not currently making any support statements for DSA w/ 
>>> the
>>>  >SHA-256 hash algorithms.  Should we be doing so?
>>>
>>>  Yes and no. Yes in the sense that US government users who use DSA
>>  > will want DSA-with-SHA-256. No in the sense that there is no
>>>  appropriate level of standards support that makes sense: 
>SHOULD is  
>>> too strong, given current deployments.
>>
>>I can deal with a SHOULD+ for this
>
>In retrospect, I agree with Jim and I'm happy with SHOULD+ for
>DSA-with-SHA-256 for both sending and receiving. It's not that 
>big of a change from 3851.
>
>>I am perfectly willing to use a non standards word here.  For 
>example, 
>>permitted.  I thought I saw enough consensus from the list that keys 
>>over this size will have either real-estate constraints or 
>performance 
>>constraints.  Either would be covered by referring to a security 
>>considerations discussion to this effect.  I don't want to 
>say or imply 
>>that keys longer than 4096 are not to be handled.
>
>Proposed wording:
>
>Receiving agents that validate signatures need to be cautious 
>of CPU usage when validating signatures larger than those 
>mandated in this specification. An attacker can send very 
>large, bogus signatures in order to swamp the CPU of the 
>receiving party. Receiving parties that verify large 
>signatures are advised to have some sort of resource 
>management system to prevent such an attack.

Is this in addition to or to replace the para that starts "Larger keys are
not" in 3851bis Sec 5?

spt

From: "Turner, Sean P." <[email-masked]>
To: "'Tony Capel'" <[email-masked]>, "'Paul Hoffman'" <[email-masked]>, "'Jim Schaad'" <[email-masked]>, "'Blake Ramsdell'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: I-D ACTION:draft-ietf-smime-3851bis-04.txt
Date: Thu, 7 Aug 2008 12:29:24 -0400
Organization: IECA, Inc.
Sender: [email-masked]

Tony,

In 3850, I added the (see Security Considerations [SMIME-MSG]) from 4.3 of
3850 to pull in the security consdierations from 3851. We already point to
it normatively so I think this might be better than copying the text in
different places.

spt

>[mailto:[email-masked]] On Behalf Of Tony Capel
>Sent: Wednesday, August 06, 2008 3:02 PM
>To: 'Paul Hoffman'; 'Jim Schaad'; 'Sean P. Turner'; 'Blake Ramsdell'
>Cc: [email-masked]
>Subject: RE: I-D ACTION:draft-ietf-smime-3851bis-04.txt
>
>
>
>| -----Original Message-----
>| From: [email-masked]
>| [mailto:[email-masked]] On Behalf Of Paul Hoffman
>| Sent: August 6, 2008 11:07 AM
>| To: Jim Schaad; 'Sean P. Turner'; 'Blake Ramsdell'
>| Cc: [email-masked]
>| Subject: RE: I-D ACTION:draft-ietf-smime-3851bis-04.txt
>| 
>| 
>>>cut
>| 
>| Proposed wording:
>| 
>| Receiving agents that validate signatures need to be cautious of CPU 
>| usage when validating signatures larger than those mandated in this 
>| specification. An attacker can send very large, bogus signatures in 
>| order to swamp the CPU of the receiving party. Receiving 
>parties that 
>| verify large signatures are advised to have some sort of resource 
>| management system to prevent such an attack.
>|
>
>I agree with the intent here, but this issue applies to both 
>signature and encryption operations.
>So the text needs to address both sections /4.3 Signature 
>Verification/  and
>/4.4 Encryption/
>(/4.5 Decryption/ should be ok since I presume the agent is 
>using a validated decryption key)
>
>So maybe the last line of both sections could change to: 
>
>"2048 <  key size         : MAY  (see Security Considerations, and
>                                  especially discussion of denial
>                                  of service vulnerability when
>                                  implementing support for large keys,
>                                  e.g. keys larger than 4096.)" 
>
>
>
>Similarly maybe it is also appropriate* to add the same text 
>to rfc3850bis-04 section  /4.3 Certificate and CRL Signing Algorithms/
>
>And the security considerations section of rfc3850bis updated 
>similarly to 3851 with regard to cautions about large key sizes.
> 
>
>Tony
>
>*Also a problem for cert validation if the provided 
>intermediate cert has a large key (which would be used to 
>check the end user certificate signature).
>Hopefully implementers will either a) identify the chain of 
>certificates and begin validation at the trust anchor or b) 
>limit crypto processing in some way.
>

From: "Tony Capel" <[email-masked]>
To: "'Paul Hoffman'" <[email-masked]>, "'Jim Schaad'" <[email-masked]>, "'Sean P. Turner'" <[email-masked]>, "'Blake Ramsdell'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: I-D ACTION:draft-ietf-smime-3851bis-04.txt
Date: Wed, 6 Aug 2008 15:01:56 -0400
Importance: Normal
Sender: [email-masked]

| -----Original Message-----
| From: [email-masked] 
| [mailto:[email-masked]] On Behalf Of Paul Hoffman
| Sent: August 6, 2008 11:07 AM
| To: Jim Schaad; 'Sean P. Turner'; 'Blake Ramsdell'
| Cc: [email-masked]
| Subject: RE: I-D ACTION:draft-ietf-smime-3851bis-04.txt
| 
| 
>>cut
| 
| Proposed wording:
| 
| Receiving agents that validate signatures need to be cautious of CPU 
| usage when validating signatures larger than those mandated in this 
| specification. An attacker can send very large, bogus signatures in 
| order to swamp the CPU of the receiving party. Receiving parties that 
| verify large signatures are advised to have some sort of resource 
| management system to prevent such an attack.
|

I agree with the intent here, but this issue applies to both signature and
encryption operations.
So the text needs to address both sections /4.3 Signature Verification/  and
/4.4 Encryption/
(/4.5 Decryption/ should be ok since I presume the agent is using a validated
decryption key)

So maybe the last line of both sections could change to: 

"2048 <  key size         : MAY  (see Security Considerations, and
                                  especially discussion of denial
                                  of service vulnerability when
                                  implementing support for large keys,
                                  e.g. keys larger than 4096.)" 

Similarly maybe it is also appropriate* to add the same text to rfc3850bis-04
section  /4.3 Certificate and CRL Signing Algorithms/

And the security considerations section of rfc3850bis updated similarly to 3851
with regard to cautions about large key sizes.

Tony

*Also a problem for cert validation if the provided intermediate cert has a
large key (which would be used to check the end user certificate signature).
Hopefully implementers will either a) identify the chain of certificates and
begin validation at the trust anchor or b) limit crypto processing in some way.

Date: Wed, 6 Aug 2008 08:06:31 -0700
To: "Jim Schaad" <[email-masked]>, "'Sean P. Turner'" <[email-masked]>, "'Blake Ramsdell'" <[email-masked]>
From: Paul Hoffman <[email-masked]>
Subject: RE: I-D ACTION:draft-ietf-smime-3851bis-04.txt
Cc: <[email-masked]>
Sender: [email-masked]

At 7:44 PM +1000 8/6/08, Jim Schaad wrote:
>>  From: Paul Hoffman [mailto:[email-masked]]
>>  Sent: Sunday, August 03, 2008 8:28 AM
>>  To: Jim Schaad; Sean P. Turner; 'Blake Ramsdell'
>>  Cc: [email-masked]
>>  Subject: RE: I-D ACTION:draft-ietf-smime-3851bis-04.txt
>>
>>  At 2:17 PM +0100 7/28/08, Jim Schaad wrote:
>>  >Comments on the draft:
>>  >
>>  >1.  We are not currently making any support statements for DSA w/ the
>>  >SHA-256 hash algorithms.  Should we be doing so?
>>
>>  Yes and no. Yes in the sense that US government users who use DSA
>  > will want DSA-with-SHA-256. No in the sense that there is no
>>  appropriate level of standards support that makes sense: SHOULD is
>>  too strong, given current deployments.
>
>I can deal with a SHOULD+ for this

In retrospect, I agree with Jim and I'm happy with SHOULD+ for 
DSA-with-SHA-256 for both sending and receiving. It's not that big of 
a change from 3851.

>I am perfectly willing to use a non standards word here.  For example,
>permitted.  I thought I saw enough consensus from the list that keys over
>this size will have either real-estate constraints or performance
>constraints.  Either would be covered by referring to a security
>considerations discussion to this effect.  I don't want to say or imply that
>keys longer than 4096 are not to be handled.

Proposed wording:

Receiving agents that validate signatures need to be cautious of CPU 
usage when validating signatures larger than those mandated in this 
specification. An attacker can send very large, bogus signatures in 
order to swamp the CPU of the receiving party. Receiving parties that 
verify large signatures are advised to have some sort of resource 
management system to prevent such an attack.

X-Antivirus-MOVIELINK.NET.AU-Mail-From: [email-masked] via mail.movielink.net.au
X-Antivirus-MOVIELINK.NET.AU: 1.25-st-qms (Clear:RC:1(203.36.227.132):. Processed in 0.650914 secs Process 12615)
From: "Jim Schaad" <[email-masked]>
To: "'Paul Hoffman'" <[email-masked]>, "'Sean P. Turner'" <[email-masked]>, "'Blake Ramsdell'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: I-D ACTION:draft-ietf-smime-3851bis-04.txt
Date: Wed, 6 Aug 2008 19:44:42 +1000
Sender: [email-masked]

> From: Paul Hoffman [mailto:[email-masked]]
> Sent: Sunday, August 03, 2008 8:28 AM
> To: Jim Schaad; Sean P. Turner; 'Blake Ramsdell'
> Cc: [email-masked]
> Subject: RE: I-D ACTION:draft-ietf-smime-3851bis-04.txt
> 
> At 2:17 PM +0100 7/28/08, Jim Schaad wrote:
> >Comments on the draft:
> >
> >1.  We are not currently making any support statements for DSA w/ the
> >SHA-256 hash algorithms.  Should we be doing so?
> 
> Yes and no. Yes in the sense that US government users who use DSA
> will want DSA-with-SHA-256. No in the sense that there is no
> appropriate level of standards support that makes sense: SHOULD is
> too strong, given current deployments.

I can deal with a SHOULD+ for this 

> 
> >2.  For key size support, key of L>1024 are not supported for DSA-SHA-
> 1.
> 
> Arrgh. Quite right. Sections 4.2 and 4.3 need to be rewritten to
> indicate that anything greater than 1024 is about RSA *only*.
> 
> >3.  I would like to add the following text to the table.
> >
> >Key size > 4096   MAY NOT (See security considerations on large keys)
> >
> >This would finish the table entry out and also reference the
> discussion on
> >why very large keys are not recommended.  It is possible that MAY NOT
> is not
> >currently valid 2119 language.  In this case I would be happy with
> ether MAY
> >or SHOULD NOT.  I would not be happy with MUST NOT.
> 
> "MAY NOT" is not part of 2119. Further, we do not have enough
> evidence to know size key is "too large". Further still, the number
> will be different for receivers of RSA and DSA keys, I believe.
> 
> "MAY" makes no sense. "SHOULD NOT" is too strong, I believe, without
> more than just data-less guessing on our part.

I am perfectly willing to use a non standards word here.  For example,
permitted.  I thought I saw enough consensus from the list that keys over
this size will have either real-estate constraints or performance
constraints.  Either would be covered by referring to a security
considerations discussion to this effect.  I don't want to say or imply that
keys longer than 4096 are not to be handled.

> 
> At 4:43 PM +0100 7/31/08, Jim Schaad wrote:
> >I really feel that we need to have two MUST signature algorithms for
> safety.
> >When ECC signatures where present that was fine.  Without having the
> ECC
> >signature algorithms we really must have one of the DSA algorithms as
> a must
> 
> I disagree. If RSA falls for some reason that cannot be fixed with
> longer key sizes, a "SHOULD" on DSA-SHA256 for fallback reasons
> assumes that the attack on RSA will not apply to DSA, which seems
> like a stretch. Having a "SHOULD" for a fallback seems reasonable.

From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: I-D ACTION:draft-ietf-smime-bfibecms-10.txt 
Date: Mon,  4 Aug 2008 14:30:01 -0700 (PDT)
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the S/MIME Mail Security Working Group of the IETF.

	Title		: Using the Boneh-Franklin and Boneh-Boyen identity-based Encryption Algorithms with the Cryptographic Message Syntax (CMS)
	Author(s)	: L. Martin, M. Schertler
	Filename	: draft-ietf-smime-bfibecms-10.txt
	Pages		: 16
	Date		: 2008-8-4
	
This document describes the conventions for using the Boneh-
        Franklin (BF) and Boneh-Boyen (BB1) identity-based 
        encryption algorithms in the Cryptographic Message Syntax 
        (CMS) to encrypt content-encryption keys. Object identifiers 
        and the convention for encoding a recipient's identity are 
        also defined.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-smime-bfibecms-10.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body;
	name="draft-ietf-smime-bfibecms-10.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--NextPart--

Date: Sun, 3 Aug 2008 16:27:36 +0100
To: "Jim Schaad" <[email-masked]>, "Sean P. Turner" <[email-masked]>, "'Blake Ramsdell'" <[email-masked]>
From: Paul Hoffman <[email-masked]>
Subject: RE: I-D ACTION:draft-ietf-smime-3851bis-04.txt
Cc: <[email-masked]>
Sender: [email-masked]

At 2:17 PM +0100 7/28/08, Jim Schaad wrote:
>Comments on the draft:
>
>1.  We are not currently making any support statements for DSA w/ the
>SHA-256 hash algorithms.  Should we be doing so?

Yes and no. Yes in the sense that US government users who use DSA 
will want DSA-with-SHA-256. No in the sense that there is no 
appropriate level of standards support that makes sense: SHOULD is 
too strong, given current deployments.

>2.  For key size support, key of L>1024 are not supported for DSA-SHA-1.

Arrgh. Quite right. Sections 4.2 and 4.3 need to be rewritten to 
indicate that anything greater than 1024 is about RSA *only*.

>3.  I would like to add the following text to the table.
>
>Key size > 4096   MAY NOT (See security considerations on large keys)
>
>This would finish the table entry out and also reference the discussion on
>why very large keys are not recommended.  It is possible that MAY NOT is not
>currently valid 2119 language.  In this case I would be happy with ether MAY
>or SHOULD NOT.  I would not be happy with MUST NOT.

"MAY NOT" is not part of 2119. Further, we do not have enough 
evidence to know size key is "too large". Further still, the number 
will be different for receivers of RSA and DSA keys, I believe.

"MAY" makes no sense. "SHOULD NOT" is too strong, I believe, without 
more than just data-less guessing on our part.

At 4:43 PM +0100 7/31/08, Jim Schaad wrote:
>I really feel that we need to have two MUST signature algorithms for safety.
>When ECC signatures where present that was fine.  Without having the ECC
>signature algorithms we really must have one of the DSA algorithms as a must

I disagree. If RSA falls for some reason that cannot be fixed with 
longer key sizes, a "SHOULD" on DSA-SHA256 for fallback reasons 
assumes that the attack on RSA will not apply to DSA, which seems 
like a stretch. Having a "SHOULD" for a fallback seems reasonable.

Date: Sun, 3 Aug 2008 16:20:10 +0100
To: "Jim Schaad" <[email-masked]>, "Sean P. Turner" <[email-masked]>, "'Blake Ramsdell'" <[email-masked]>
From: Paul Hoffman <[email-masked]>
Subject: RE: I-D ACTION:draft-ietf-smime-3850bis-04.txt
Cc: <[email-masked]>
Sender: [email-masked]

At 2:43 PM +0100 7/28/08, Jim Schaad wrote:
>Comments on the draft.
>
>In section 4.4.3, I find the following text confusing:
>
>End-entity certificates contain an extension that
>    constrains the certificate from being an issuing authority
>    certificate (see Section 4.4.2).
>
>
>I believe that this text might be better as it clarifies what is being
>stated.  I.e. it is not the fact that basic constraints is being used which
>actually does the mentioned constraint.
>
>
>End-entity certificates contain the Key Usage extension which restraints the
>end-entity from using the key to perform issuing authority operations (see
>4.4.4)

s/restraints/restrains/

>Also the previous comment (on 3851bis) on key sizes > 4096 should be applied
>to this document

My same reply applies.