Subject: Protocol Action: 'Multiple Signatures in S/MIME' to Proposed Standard

From: The IESG <[email-masked]>
Date: Tue, 27 May 2008 06:44:05 -0700 (PDT)

The IESG has approved the following document:

- 'Multiple Signatures in S/MIME '
   <draft-ietf-smime-multisig-05.txt> as a Proposed Standard

This document is the product of the S/MIME Mail Security Working Group. 

The IESG contact persons are Tim Polk and Pasi Eronen.

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

Technical Summary

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

Working Group Summary 

This ID was discussed on the smime mailing list and at several IETF
meetings. Initially, there was some confusion about the problem being
solved but moving the general attacks against CMS hashes text to an
Appendix addressed the WG's concerns. This initial confusion has really
been the only major issue.

Document Quality 

This document is new and there are no implementations - yet. There
has been interest from multiple vendors about when it will be
published as an RFC.

Personnel 

Blake Ramsdell is the document Shepherd. Tim Polk is the responsible
Security Area AD.

RFC Editor Note

Please make the following changes:

a) Please remove the "Discussion" section preceding the Table of
Contents.

b) Please replace all occurrences of "pkcs9(9)" with "pkcs-9(9)".

c) In section 2 list item 1), please make the following substitution

OLD

If both SignerInfo objects are not present, the relying party
can easily determine that another SignerInfo has been removed.

NEW

Relying parties can easily determine that a SignerInfo has been removed
if
another SignerInfo contains a multi-sig attribute that refers to it.

d) In section 8.1, Normative References, please make the following
substitution:

OLD

[PROFILE]     Housley, R., Polk, W., Ford, W., and D. Solo, 
              "Internet X.509 Public Key Infrastructure Certificate 
              and Certificate Revocation List (CRL) Profile", RFC 
              3280, April 2002.

NEW

[PROFILE]     Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
              Housley, R., and W. Polk, "Internet X.509 Public Key
              Infrastructure Certificate and Certificate Revocation
              List (CRL) Profile", RFC 5280, May 2008.

_______________________________________________
IETF-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf-announce

From: The IESG <[email-masked]>
To: IETF-Announce <[email-masked]>
Subject: Protocol Action: 'Multiple Signatures in S/MIME' to  Proposed Standard 
Date: Tue, 27 May 2008 06:44:05 -0700 (PDT)
Cc: Internet Architecture Board <[email-masked]>, smime chair <[email-masked]>, smime mailing list <[email-masked]>, RFC Editor <[email-masked]>
Sender: [email-masked]

The IESG has approved the following document:

- 'Multiple Signatures in S/MIME '
   <draft-ietf-smime-multisig-05.txt> as a Proposed Standard

This document is the product of the S/MIME Mail Security Working Group. 

The IESG contact persons are Tim Polk and Pasi Eronen.

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

Technical Summary

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

Working Group Summary 

This ID was discussed on the smime mailing list and at several IETF
meetings. Initially, there was some confusion about the problem being
solved but moving the general attacks against CMS hashes text to an
Appendix addressed the WG's concerns. This initial confusion has really
been the only major issue.

Document Quality 

This document is new and there are no implementations - yet. There
has been interest from multiple vendors about when it will be
published as an RFC.

Personnel 

Blake Ramsdell is the document Shepherd. Tim Polk is the responsible
Security Area AD.

RFC Editor Note

Please make the following changes:

a) Please remove the "Discussion" section preceding the Table of
Contents.

b) Please replace all occurrences of "pkcs9(9)" with "pkcs-9(9)".

c) In section 2 list item 1), please make the following substitution

OLD

If both SignerInfo objects are not present, the relying party
can easily determine that another SignerInfo has been removed.

NEW

Relying parties can easily determine that a SignerInfo has been removed
if
another SignerInfo contains a multi-sig attribute that refers to it.

d) In section 8.1, Normative References, please make the following
substitution:

OLD

[PROFILE]     Housley, R., Polk, W., Ford, W., and D. Solo, 
              "Internet X.509 Public Key Infrastructure Certificate 
              and Certificate Revocation List (CRL) Profile", RFC 
              3280, April 2002.

NEW

[PROFILE]     Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
              Housley, R., and W. Polk, "Internet X.509 Public Key
              Infrastructure Certificate and Certificate Revocation
              List (CRL) Profile", RFC 5280, May 2008.

_______________________________________________
IETF-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf-announce

From: The IESG <[email-masked]>
To: IETF-Announce <[email-masked]>
Cc: Internet Architecture Board <[email-masked]>, RFC Editor <[email-masked]>, smime mailing list <[email-masked]>, smime chair <[email-masked]>
Subject: Protocol Action: 'Multiple Signatures in S/MIME' to  Proposed Standard 
Date: Tue, 27 May 2008 06:44:05 -0700 (PDT)
Sender: [email-masked]

The IESG has approved the following document:

- 'Multiple Signatures in S/MIME '
   <draft-ietf-smime-multisig-05.txt> as a Proposed Standard

This document is the product of the S/MIME Mail Security Working Group. 

The IESG contact persons are Tim Polk and Pasi Eronen.

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

Technical Summary

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

Working Group Summary 

This ID was discussed on the smime mailing list and at several IETF
meetings. Initially, there was some confusion about the problem being
solved but moving the general attacks against CMS hashes text to an
Appendix addressed the WG's concerns. This initial confusion has really
been the only major issue.

Document Quality 

This document is new and there are no implementations - yet. There
has been interest from multiple vendors about when it will be
published as an RFC.

Personnel 

Blake Ramsdell is the document Shepherd. Tim Polk is the responsible
Security Area AD.

RFC Editor Note

Please make the following changes:

a) Please remove the "Discussion" section preceding the Table of
Contents.

b) Please replace all occurrences of "pkcs9(9)" with "pkcs-9(9)".

c) In section 2 list item 1), please make the following substitution

OLD

If both SignerInfo objects are not present, the relying party
can easily determine that another SignerInfo has been removed.

NEW

Relying parties can easily determine that a SignerInfo has been removed
if
another SignerInfo contains a multi-sig attribute that refers to it.

d) In section 8.1, Normative References, please make the following
substitution:

OLD

[PROFILE]     Housley, R., Polk, W., Ford, W., and D. Solo, 
              "Internet X.509 Public Key Infrastructure Certificate 
              and Certificate Revocation List (CRL) Profile", RFC 
              3280, April 2002.

NEW

[PROFILE]     Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
              Housley, R., and W. Polk, "Internet X.509 Public Key
              Infrastructure Certificate and Certificate Revocation
              List (CRL) Profile", RFC 5280, May 2008.

Reply-To: [email-masked]
From: "Denis Pinkas"<[email-masked]>
To: "ETSI ESI TC"<[email-masked]>, "ietf-smime"<[email-masked]>
CC: "Nick Pope"<[email-masked]>
Subject: Re: Extending CAdES to support usual signature upgrading to CAdES-T and further
Date: Mon, 26 May 2008 14:01:00 +0200
Sender: [email-masked]

------=_NextPart_08052614005700783103770_002
Content-Transfer-Encoding: base64
Content-Type: text/plain; 
	charset="ISO-8859-1"

------=_NextPart_08052614005700783103770_002
Content-Transfer-Encoding: base64
Content-Type: text/html; 
	charset="ISO-8859-1"

------=_NextPart_08052614005700783103770_002--

From: "Pavel V. Smirnov" <[email-masked]>
To: "'Pope, Nick'" <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: CAdES. Storing validation data.
Date: Mon, 26 May 2008 14:50:03 +0400
Sender: [email-masked]

------=_NextPart_000_0001_01C8BF3F.C8FBF720
Content-Type: text/plain; charset="koi8-r"
Content-Transfer-Encoding: 7bit

Hello all and personally Nick,

I want to draw your attention to the following problem.

There is only limited possible transformation between CAdES-X Type 1
signature and CAdES-X Long Type 1 signature. Notably, one must store
certificate and revocation values for signature-timestamp validation in the
timestamp itself, hence, after receiving CAdES-C-timestamp one cannot add or
remove these values from signature-timestamp.

An obvious solution is to allow to include timestamp validation data in
certificate-values and revocation-values attributes of the signature itself.
What do you think?

Pavel Smirnov

Crypto-Pro
Tel./Fax: +7 495 780-4820
WWW:  <http://www.cryptopro.ru/> http://www.CryptoPro.ru
e-mail:  <mailto:[email-masked]> [email-masked]

------=_NextPart_000_0001_01C8BF3F.C8FBF720
Content-Type: text/html; charset="koi8-r"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; charset=3Dkoi8-r">
<meta name=3DGenerator content=3D"Microsoft Word 12 (filtered medium)">
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page Section1
	{size:612.0pt 792.0pt;
	margin:2.0cm 42.5pt 2.0cm 3.0cm;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=3DRU link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><span lang=3DEN-US>Hello all and personally =
Nick,<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US>I want to draw your attention to =
the
following problem.<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US>There is only limited possible
transformation between CAdES-X Type 1 signature and CAdES-X Long Type 1
signature. Notably, one must store certificate and revocation values for
signature-timestamp validation in the timestamp itself, hence, after =
receiving
CAdES-C-timestamp one cannot add or remove these values from
signature-timestamp.<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US>An obvious solution is to allow =
to include
timestamp validation data in certificate-values and revocation-values
attributes of the signature itself. What do you =
think?<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US><o:p>&nbsp;</o:p></span></p>

<div>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:10.0pt;color:navy'>Pavel
Smirnov<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:10.0pt;color:navy'>Crypto-Pro<br>
Tel./Fax: +7 495 780-4820<br>
WWW: </span><a href=3D"http://www.cryptopro.ru/" =
title=3D"http://www.cryptopro.ru/"><span
lang=3DEN-US =
style=3D'font-size:10.0pt;color:blue'>http://www.CryptoPro.ru</span></a><=
span
lang=3DEN-US style=3D'font-size:10.0pt;color:navy'><br>
e-mail: </span><a href=3D"mailto:[email-masked]" =
title=3D"mailto:[email-masked]"><span
lang=3DEN-US =
style=3D'font-size:10.0pt;color:blue'>[email-masked]</span></a><span
lang=3DEN-US><o:p></o:p></span></p>

</div>

<p class=3DMsoNormal><span lang=3DEN-US><o:p>&nbsp;</o:p></span></p>

</div>

</body>

</html>

------=_NextPart_000_0001_01C8BF3F.C8FBF720--

From: "Pavel V. Smirnov" <[email-masked]>
To: "'Pope, Nick'" <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Extending CAdES to support usual signature upgrading to CAdES-T and further
Date: Mon, 26 May 2008 14:50:13 +0400
Sender: [email-masked]

------=_NextPart_000_0006_01C8BF3F.CEE13650
Content-Type: text/plain; charset="koi8-r"
Content-Transfer-Encoding: 7bit

Hello all and personally Nick,

In current CAdES wording a regular signature without at least one signed
attribute (Signing certificate reference) cannot be added with timestamps
and validation data to achieve CAdES-T or more advanced CAdES signature.
This need arises, e.g., in a system with existing regular signatures. There
is no chance to add the required attribute to the already computed
signature, but there is a strong need to add CAdES properties to such
signatures.

There is rather simple approach to achieve the same properties without
including signing certificate reference as a signed attribute. Let us
include this reference as an extension in the CAdES-T timestamp (signature
timestamp). To get such timestamp one would need to include this extension
in a timestamp request and a TSA would have to shift this extension to a
timestamp token.

Let us define the proposed extension to a timestamp protocol and call the
signature we get a valid CAdES-T signature. More advanced CAdES signature
types turn out from this new CAdES-T perfectly without any modification.
What do you think?

Pavel Smirnov

Crypto-Pro
Tel./Fax: +7 495 780-4820
WWW:  <http://www.cryptopro.ru/> http://www.CryptoPro.ru
e-mail:  <mailto:[email-masked]> [email-masked]

------=_NextPart_000_0006_01C8BF3F.CEE13650
Content-Type: text/html; charset="koi8-r"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; charset=3Dkoi8-r">
<meta name=3DGenerator content=3D"Microsoft Word 12 (filtered medium)">
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page Section1
	{size:612.0pt 792.0pt;
	margin:2.0cm 42.5pt 2.0cm 3.0cm;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=3DRU link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><span lang=3DEN-US>Hello all and personally =
Nick,<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US>In current CAdES wording a =
regular
signature without at least one signed attribute (Signing certificate =
reference)
cannot be added with timestamps and validation data to achieve CAdES-T =
or more
advanced CAdES signature. This need arises, e.g., in a system with =
existing
regular signatures. There is no chance to add the required attribute to =
the
already computed signature, but there is a strong need to add CAdES =
properties
to such signatures.<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US>There is rather simple approach =
to achieve
the same properties without including signing certificate reference as a =
signed
attribute. Let us include this reference as an extension in the CAdES-T
timestamp (signature timestamp). To get such timestamp one would need to =
include
this extension in a timestamp request and a TSA would have to shift this
extension to a timestamp token.<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US>Let us define the proposed =
extension to a
timestamp protocol and call the signature we get a valid CAdES-T =
signature.
More advanced CAdES signature types turn out from this new CAdES-T =
perfectly
without any modification. What do you think?<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:10.0pt;color:navy'>Pavel
Smirnov<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:10.0pt;color:navy'>Crypto-Pro<br>
Tel./Fax: +7 495 780-4820<br>
WWW: </span><a href=3D"http://www.cryptopro.ru/" =
title=3D"http://www.cryptopro.ru/"><span
lang=3DEN-US =
style=3D'font-size:10.0pt;color:blue'>http://www.CryptoPro.ru</span></a><=
span
lang=3DEN-US style=3D'font-size:10.0pt;color:navy'><br>
e-mail: </span><a href=3D"mailto:[email-masked]" =
title=3D"mailto:[email-masked]"><span
lang=3DEN-US =
style=3D'font-size:10.0pt;color:blue'>[email-masked]</span></a><span
lang=3DEN-US><o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US><o:p>&nbsp;</o:p></span></p>

</div>

</body>

</html>

------=_NextPart_000_0006_01C8BF3F.CEE13650--

From: Alfred =?hp-roman8?B?SM5uZXM=?= <[email-masked]>
Subject: draft-ietf-smime-3851bis-02  (notes, part 2) (fwd)
To: [email-masked]
Date: Wed, 21 May 2008 18:34:44 +0200 (MESZ)
Sender: [email-masked]

----- Forwarded message from Alfred HÎnes -----

>From [email-masked] Tue May 20 16:21:51 MES 2008
From: Alfred HÎnes <[email-masked]>
To: [email-masked], [email-masked]
Cc: [email-masked]
Date: Tue, 20 May 2008 16:21:47 +0200 (MESZ)
Subject: draft-ietf-smime-3851bis-02  (notes, part 2)

Hello all,
here we go with the second (and last) part of my review for
     draft-ietf-smime-3851bis-02 .

For ease of reference, the item enumeration below extends
the list from part 1 (posted yesterday).

(0)  Front Matter / Standards Actions

The draft already indicates in its front matter:
  Obsoletes: 3851

During supporting investigations, it became clear that, due to
specific circumstances, this will let us end up with two "valid"
sets of S/MIME specifications -- those for S/MIME v3.2  and
those for S/MIME v2  !

The historic reason for this scenario seems to be buried in the
S/MIME v2 specifications being published as Informational RFCs
and not expressly being Obsoleted by the S/MIME v3 RFCs.

In Section 1.3, this draft lists RFCs 2311 through 2315 as the
documents originally specifying S/MIME v2.  In the RFC index,
the entries for all these RFCs list INFORMATIONAL status,
  -  RFC 2313 is tagged (Obsoleted by RFC2437),
  -  RFC 2314 is tagged (Obsoleted by RFC2986), but
  -  RFCs 2311, 2312, and 2315 look like being current.

Arguably, it would be a matter of CMS to take action for RFC 2315,
but at least RFC 2311 and RFC 2312 are clearly within scope of the
S/MIME v3.2 drafts.

I suggest to take the opportunity to clean up the RFC metadata
and either:

  - also formally Obsolete the S/MIME v2 RFCs with the publication
    of the corresponding intended S/MIME v3.2 RFCs,
    (i.e. add RFC 2311 to the Obsoletes list of this draft,
    add RFC 2312 to the Obsoletes list of [CERT32], and
    defer action for RFC 2315 to CMS), or

  - to explicitely declare the S/MIME v2 RFCs as Historic in one place.

(14)  Section 2.5.3.1

The second bullet there says:

    - If an SMIMEEncryptionKeyPreference attribute is not found in a
      SignedData object received from the desired recipient, the set of
      X.509 certificates SHOULD be searched for a X.509 certificate
|     with the same subject name as the signing of a X.509 certificate
                                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|     which can be used for key management.
      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

I really do not understand precisely what the last two lines want to
say.  Please clean up and clarify.

(15)  Section 2.7.1.2

The visible paragraph structure there is broken; the section looks like:

   If the following two conditions are met:

    - ...

    - ...

   [[end of section]]

More closely looking at the text, it turns out that fortunately
the situation can be cured by inserting a paragraph break in the
second bullet.  For grammatical consistency, also the initial
capitalization of the bullets should be changed.

Thus, the section should be changed to:

   If the following two conditions are met:

    - the sending agent has no knowledge of the encryption capabilities
      of the recipient; and,

    - the sending agent has no knowledge of the version of S/MIME of the
      recipient,

   then the sending agent SHOULD use AES 128 because it is a stronger
   algorithm and is required by S/MIME v3.2.  If the sending agent
   chooses not to use AES 128 in this step, it SHOULD use tripleDES.

Additionally, the punctuation at the end of the first bullet now could
be easily simplified:    s/; and,/, and/

(16)  Section 3.1 ff. -- terminological issues

Being a designated Standards Track document, the draft should precisely
use established IETF terminology and not occasionally fall back to
common, yet sluggish (ab)use of the terms regarding the Internet
message structure.

Section 3.1.1 of RFC 4249 summarizes the terms established in the
Internet Mail and MIME RFCs, which I will explain again in my own
words:

  - at each conceptual protocol layer, a protocol data unit is
    comprised of a header and a payload (i.e., the "body" in textual
    protocols like email), and sometimes a trailer, as well;

  - the header within a protocol layer is comprised of header fields.

  Thus, each Internet (email) message has a single message header
  (Section 2.1 of I-D.2822-upd now even uses the term "message header
  section").
  In a structured MIME message body, each nesting level has a single
  "MIME header", "MIME entity header", or "MIME part header" of its
  own (cf. RFC 2045).
  (We are not interested in lower level details, like MIME prologue
  and epilogue, etc., for the purpose of this draft.)

  Each message header or MIME header is comprised of header fields,
  with in turn consist of a field name, the colon separator, and a
  field value.

  At the MIME top level, the MIME-related header fields are
  integrated in the RFC[2]822 message header; they sometimes
  collectively are denoted as the "MIME message header".

Furthermore, as explained in BCP 13, RFC 4288, the IETF should not
use the popular term "MIME type", in favor of "media type".
The former had not even been defined in [MIME-SPEC], and it has
become even more misleading with the spread of other protocols making
use of these media types.

I strongly recommend to update the draft to always use this precise
terminology.

As a side-show, I also recommend consistently using the same spelling
and capitalization for header field names -- preferably the spelling
and case used in the original document defining the header field --,
e.g., replace "content type" and "Content type" by "Content-Type".

Because there are some subtle cases, I try to address most affected
instances of these issues I found in the draft text in detail below.

(17)  Section 3.1 -- details

(17a)  1st paragraph

Applying the rationale of (16), I suggest to change  (also deleting
the repeated second "used" near the end of the third sentence,
to streamline the language a bit):

   S/MIME is used to secure MIME entities.  A MIME entity can be a sub-
   part, sub-parts of a message, or the whole message with all its sub-
   parts.  A MIME entity that is the whole message includes only the
|  MIME headers and MIME body, and does not include the RFC-822 headers.
       ^      ^                                             vvvvvv    ^
|  Note that S/MIME can also be used to secure MIME entities used in
   applications other than Internet mail.  If protection of the RFC-822
|  headers is required, the use of the message/rfc822 MIME type is
   explained later in this section.
---                                                   ^^^^
   S/MIME is used to secure MIME entities.  A MIME entity can be a sub-
   part, sub-parts of a message, or the whole message with all its sub-
   parts.  A MIME entity that is the whole message includes only the
|  MIME message headers and MIME body, and does not include the RFC-822
|  header.  Note that S/MIME can also be used to secure MIME entities in
   applications other than Internet mail.  If protection of the RFC-822
|  header is required, the use of the message/rfc822 media type is
   explained later in this section.

(17b)  1st paragraph below 'Step 3.'

Please remove the comma after "where" -- or put it in front of that
"where".

(17c)  2nd paragraph below 'Step 3.'

Correcting a typo and applying (16), I suggest to change:

|  In order to protect outer, non-content related message headers (for
  v                                           v           ^^^^^^^
|  nstance, the "Subject", "To", "From" and "CC" fields), the sending
   client MAY wrap a full MIME message in a message/rfc822 wrapper in
|  order to apply S/MIME security services to these headers.  It is up
                                                    ^^^^^^^
|  to the receiving client to decide how to present these "inner"
                                                    ^^^^^
|  headers along with the unprotected "outer" headers.
---      ^                                          ^
|  In order to protect outer, non-content related message header fields
|  (for instance, the "Subject", "To", "From" and "Cc" fields), the
   sending client MAY wrap a full MIME message in a message/rfc822
|  wrapper in order to apply S/MIME security services to these header
|  fields.  It is up to the receiving client to decide how to present
|  this "inner" header along with the unprotected "outer" header.

(18)  Section 3.1.1, 2nd paragraph

According to (16), please   s/MIME type/media type/   (2x).

(19)  Section 3.1.2

According to (16):

                  [...]  If no Content-Transfer-Encoding header is
   present, the transfer encoding is presumed to be 7BIT.
---                                                            vvvvvv
|                 [...]  If no Content-Transfer-Encoding header field is
   present, the transfer encoding is presumed to be 7BIT.

(20)  Section 3.1.4

The legacy example of BITNET seems to be rather aged and of very
low interest -- if any;  cf. http://en.wikipedia.org/wiki/BITNET .

I therefore suggest to simply delete  " (like BITNET)"

(21)  Section 3.2

(21a)  section title

For added precision and consistency, I suggest to add "Media"
in front of "Type"  -- cf. 3.4.3.1, discussed in (2x) below:

  3.2. The application/pkcs7-mime Type
---
  3.2. The application/pkcs7-mime Media Type

(21b) 3rd paragraph

According to (16), please   s/MIME type/media type/   (1x).

(21c) last paragraph

For added precision, and with respect to (16), the last sentence
should be amended:

|                                     [...].  The MIME headers of all
   application/pkcs7-mime objects SHOULD include the optional "smime-
   type" parameter, as described in the following sections.
---
|                                     [...].  The Content-Type header
|  field of all application/pkcs7-mime objects SHOULD include the
   optional "smime-type" parameter, as described in the following
   sections.

(22)  Section 3.2.1, last paragraph

According to (16), please   s/MIME type/media type/     (1x), and
                           s/MIME types/media types/   (1x).

(23)  Section 3.2.2, last numbered bullet

Please correct punctuation and case:
                                        vvvv
|     3. If no common string is assigned.  Then the common string of
      "OID.<oid>" is recommended (for example, "OID.1.3.6.1.5.5.7.6.1"
      would be DES40).
---                                     vvv
|     3. If no common string is assigned, then the common string of
      "OID.<oid>" is recommended (for example, "OID.1.3.6.1.5.5.7.6.1"
      would be DES40).

(24)  Section 3.4.3

According to (16), please   s/MIME type/media type/   (2x).

(25)  Section 3.4.3.1

(25a)  section title

With respect to (16) please change:

  3.4.3.1. The application/pkcs7-signature MIME Type
---
  3.4.3.1. The application/pkcs7-signature Media Type
                                           ^^^^^

(25b)  1st paragraph

According to (16), please   s/MIME type/media type/   (1x).

(26)   Section 3.4.3.2

(26a)  1st paragraph below 'Step 5'

Please adjust:
                               vv
|  The multipart/signed Content type has two required parameters: the
   protocol parameter and the micalg parameter.
---                            vv
|  The multipart/signed Content-Type has two required parameters: the
   protocol parameter and the micalg parameter.

(26b)  last paragraph:

The draft says:

|  The SHA-224 algorithm [SHA224] and SHA-384 and SHA-512 algorithms
   [FIPS180-3] are not currently recommended in S/MIME, and are included
   here for completeness.

There's an apparent disparity.  SHA-224 is also covered by FIPS 180-3,
and SHA-384 as well as SHA-512 are also covered by RFC 4634 not even
listed as a Reference.  Perhaps this has historical reasonse related to
the delayed introduction of SHA-224 via a Change Notice to FIPS 180-2.

Since the requirements statement is "not recommended", adding a bulk
of references might be overkill; the basic Ref. should suffice.
Thus, I suggest to drop [SHA224] and simplify the language:

|  The SHA-224, SHA-384, and SHA-512 algorithms [FIPS180-3] are not
   currently recommended in S/MIME, and are included here for
   completeness.

(27)  Setcion 3.9

(27a)  2nd paragraph

According to (16), please change:

   The file suffix in the table below comes from the "name" parameter in
|  the content-type header, or the "filename" parameter on the content-
   v   ^       ^    vv   ^^                                    ^
|  disposition header.  These parameters that give the file suffix are
   not listed below as part of the parameter section.
---
   The file suffix in the table below comes from the "name" parameter in
|  the Content-Type header field, or the "filename" parameter on the
|  Content-Disposition header field.  These parameters that give the
   file suffix are not listed below as part of the parameter section.

(27b)  table

According to (16), please   s/MIME type/media type/   (3x).

(28)  Section 4.1

The draft says:

   All generated key pairs MUST be generated from a good source of non-
   deterministic random input [RANDOM] and the private key MUST be
   protected in a secure fashion.

IMO, this 'MUST' requirement constitutes a *Normative* Reference;
so please promote '[RANDOM]' to Normative, moving the entry from
B.2 to B.1.

(29)  Section 5

Independent on the decision to be made regarding (0) above,
this section needs to be amended.

(29a)  Scenario 1:  RFC 2311 *not* Obsoleted / made HISTORIC

In this case, IANA should at least be directed to update the media type
registrations for

      "application/pkcs7-mime"
and
      "application/pkcs7-signature"

by adding an additional reference to [RFCTHIS], in order to point
the reader to the most current update of the media type information.

On the other hand, updating an old media type's information arguably
could require updating the registration entirely, using the new
registration template from BCP 13, RFC 4288.

I leave it to the high priests of exegesis (or lawyers) to figure
out whether RFC 4288 in fact even normatively requests to do so.

(29b)  Scenario 2:  RFC 2311 beinf Obsoleted or made HISTORIC

In this case, the draft should substantially be amended with the
two new media type registration templates, filled for both media
types, "application/pkcs7-mime" and "application/pkcs7-signature",
and IANA should be directed to update the registrations to
incorporate this new information.

(30)  Section 6, 7th paragraph

I suggest to make the statement on key size more specific (again, to
not interfere with the future addition of other signing algorithms
having other key size requirements), and to correct the placement of
hyphens, as follows:

   Some S/MIME agents created in the United States have chosen to create
|  512 bit keys in order to get more advantageous export licenses.
|  However, 512 bit keys are considered by many to be cryptographically
   insecure.
---
   Some S/MIME agents created in the United States have chosen to create
|  512-bit RSA keys in order to get more advantageous export licenses.
      ^   ^^^^ v   vvvv
|  However, 512-bit RSA keys are considered by many to be
   cryptographically insecure.

(31)  Appendix A

(31a)  general

At first glance, it comes to surprise that there's a "~~V3dot1"
ASN.1 module.

For clarity, I suggest adding an introductory statement indicating
that this module has been taken essentially unchanged from RFC 3851
and still applies to S/MIME v3.2.

(31b)  ASN.1 comment below id-cap OID definition

I suggest to improve the language a bit, by inserting "OID":

   -- The preferBinaryInside indicates an ability to receive messages
   -- with binary encoding inside the CMS wrapper
---                         vvvvv
   -- The preferBinaryInside OID indicates an ability to receive
   -- messages with binary encoding inside the CMS wrapper.

(32)   Appendix B

[ Interestingly, the last item for v3.2 happens to be #32  :-) ]

(32a)  section numbering

The RFC Editor prefers References as a numbered section, not as
an Appendix.  Therefore, I suggest to shuffle the Appendices and
turn this one into Section 7.

(32b)  B.1, [FIPS180-3]       { oooops }
                             vvvvvvvvvvv
   [FIPS180-3]   "Secure Hash Signature Standard (SHS)", National
                 Institute of Standards and Technology (NIST).  FIPS
                 Publication 180-3.
---
|  [FIPS180-3]   "Secure Hash Standard (SHS)", National Institute of
                 Standards and Technology (NIST), FIPS Publication
|                180-3, June 2007.
                      ^^^^^^^^^^^
or better, listing the source first (as also done for ITU-T documents):

|  [FIPS180-3]   National Institute of Standards and Technology (NIST),
|                "Secure Hash Standard (SHS)", FIPS Publication 180-3,
|                June 2007.

(32c)  B.2, [RANDOM]

Please add    "BCP 106, "  in front of "RFC 4086".
regarding eventual promotion to Normative, please see item (28) above.

Kind regards,
  Alfred HÎnes.

--

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [email-masked]                     |
+------------------------+--------------------------------------------+

----- End of forwarded message from Alfred HÎnes -----

From: Alfred =?hp-roman8?B?SM5uZXM=?= <[email-masked]>
Subject: draft-ietf-smime-3851bis-02  (notes, part 1) (fwd)
To: [email-masked]
Date: Wed, 21 May 2008 18:34:21 +0200 (MESZ)
Sender: [email-masked]

----- Forwarded message from Alfred HÎnes -----

>From [email-masked] Mon May 19 11:21:42 MES 2008
From: Alfred HÎnes <[email-masked]>
To: [email-masked], [email-masked]
Cc: [email-masked]
Date: Mon, 19 May 2008 11:21:38 +0200 (MESZ)
Subject: draft-ietf-smime-3851bis-02  (notes, part 1)

Hello,
I would like to also submit a few comments on your Internet-Draft,
draft-ietf-smime-3851bis-02.

Due to time constraints, I have decided to split the intended
comments.  This is the first part addressing the initial sections
of the draft, up to section 2.5.1; more will follow ASAP.

(1)  Conventions used ...

- The RFC Editor will want to make that a proper (numbered) section.
  I suggest to move it to between the current sub-sections 1.1 and 1.2.

- The comments I sent on the same part of draft-ietf-smime-3850bis-02
  also apply.

(2)  Section 1

(2a)  1st paragraph

For completeness (and matching of what is said in the Abtract),
I suggest to add a short note on message compression to the end
of the first paragraph of Section 1, for instance:

   As a supplementary service, S/MIME provides for message compression.

(2b)  2nd paragraph

Perhaps the most important usage scenario for S/MIME now is
bound to SIP (using the 'sips' URIs) to protect the negotioation
of multimedia session parameters (cf. RFC 3261).
Therefore, I suggest to replace in the second paragraph of Section 1
the clause "such as HTTP" by "such as HTTP or SIP".

(3)  General -- terminology

It has been generally recognized that the media type concept defined
in [MIME-SPEC] has outgrown the narrow context of MIME, and RFC 4288
(BCP 13) has confirmed that the popular sluggish term "MIME Type"
should not be used, in favor of the proper term "Media Type", which
already had been used throughout [MIME-SPEC].

Therefore, I recommend to also change in this draft all occurrences
of "MIME type" to "media type" (inclusive of the title of Section
3.4.3.1).

Also, when refering to MIME header fields, their names should be
quoted faithfully for clarity and precision; in particular, the
hyphen should always be included after "Content", e.g.,
  "Content type"  -->  "Content-type".

(4)  Section 1.1

(4a)  1st paragraph

The draft says:

   This document describes a protocol for adding cryptographic signature
   and encryption services to MIME data.  The MIME standard [MIME-SPEC]
|  provides a general structure for the content type of Internet
|  messages and allows extensions for new content type applications.

There are two issues with the use of "content type":

-  "structure of the content type" is a slight abuse of language;
   "structure of content" is the proper designation.

-  "content type applications" seems to be vague and unclear.
   I suggest to use "content type specific applications" or
   "content type based applications" instead

(4b)  2ns and 3rd paragraph

Please apply (3) -- 3 occurrences.

(5)  Section 1.3

For clarity, please add another comma after the first instance of
"inclusive", or place this word in parentheses.

(6)  Section 1.4

(6a)  section title

The legacy section title obviously is outdated, turning it ambiguous.
It should better be changed:

  1.4. Changes Since S/MIME v3
---
| 1.4. Changes From S/MIME v3 to S/MIME v3.1

This should properly complement the correctly entitled new section,

  1.5. Changes Since S/MIME v3.1

(6b)  last two paragraphs

Please apply (3) -- two occurrences.

(7)  Section 1.5 -- typo

Please replace "in parantheticals"  by either "parenthetical" or
"in parenthesis".

(7)  Section 1.5 -- typo

Please replace
                     vv    v
           "AES-CBC" in parantheticals.
by either:
           parenthetical "AES-CBC".
or:
           parenthetic "AES-CBC".
or:
           "AES-CBC" in parenthesis.

(8)  Section 2 -- clarification of the role of [ESS]

I suggest to add a note to the text in Section 2 clarifying
that RFC 2634 [ESS] is applicable for S/MIME v3.2 as well.

This is intended to complement the remarks in Section 1.3
stating that RFC 2634 is part of the S/MIME v3 and S/MIME v3.1
specification.

(9)  Section 2.3

Please replace
                using rsaEncryption algorithm.
by either:
                using the rsaEncryption algorithm.
or:
                using rsaEncryption.

(10)  Section 2.4.1

The draft says:

                vvvvvvvvvvvv
        ... the MIME content MUST be stored in the SignedData
    encapContentInfo eContent OCTET STRING ...

This is misleading; the Content-Type has to be stored there,
not the "content".
In line with (3) above, I suggest to use the phrase:

               vvvvvvvvvvv
|       ... the media type MUST be stored in the SignedData
    encapContentInfo eContent OCTET STRING ...

(11)  Section 2.4.4, 1st paragraph

I suggest to insert the article "the" giving "reduce the message size".

(12)  Section 2.5

(12a)   1st paragraph

The draft says, using redundant/replicated wording:

                              vvvvvvvvvvvvv
   The SignerInfo type allows the inclusion of unsigned and signed
   attributes to be included along with a signature.
              ^^^^^^^^^^^^^^
I suggest to simplify the wording to:

   The SignerInfo type allows the inclusion of unsigned and signed
|  attributes along with a signature.
             ^

(12b)  2nd-to-last paragraph

The draft says:

                    [..].  Receiving agents SHOULD handle attributes or
   values that it does not recognize in a graceful manner.

The wording "receiving agents ... it does not" should be improved upon.
I suggest either to turn to singular:

                           vv              vv
|                   [..].  A Receiving agent SHOULD handle attributes or
   values that it does not recognize in a graceful manner.

or substitute "they" in the last line:

                    [..].  Receiving agents SHOULD handle attributes or
|  values they do not recognize in a graceful manner.
          ^^^^^^^

(13)  Section 2.5.1

The rules for UTCTime vs. GeneralizedTime are unfortunate for
several reasons, as I have pointed out in recent comments on
RFC 5280.  They violate the lessons learned during Y2K that
4 decimal digits should *always* be encoded for year numbers,
and they cause general non-exercising of 'MUST implement'
code, generating a new security risk.

I strongly recommend to, at a minimum, demote the "MUST" to encode
signing-time through 2049 as UTCTime to a "MUST-", preferably "SHOULD",
to promote starting general migration to GeneralizedTime.

Kind regards,
  Alfred HÎnes.

--

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [email-masked]                     |
+------------------------+--------------------------------------------+

----- End of forwarded message from Alfred HÎnes -----

From: Alfred =?hp-roman8?B?SM5uZXM=?= <[email-masked]>
Subject: draft-ietf-smime-3850bis-02 (fwd)
To: [email-masked]
Date: Wed, 21 May 2008 18:34:04 +0200 (MESZ)
Sender: [email-masked]

----- Forwarded message from Alfred HÎnes -----

>From [email-masked] Sun May 18 16:37:14 MES 2008
From: Alfred HÎnes <[email-masked]>
To: [email-masked], [email-masked]
Date: Sun, 18 May 2008 16:37:12 +0200 (MESZ)
Subject: draft-ietf-smime-3850bis-02

Hello,
I'd like to also submit a few comments on your I-D,
    draft-ietf-smime-3850bis-02.

(1)  Conventions used ...

a)  I have not followed the progress of
    draft-hoffman-additional-key-words,
    but it looks like the evolution of that document might
    be worth being monitored or coordinated with, in order
    to avoid repeated re-specification of the new keywords.

b)  last paragraph:

     MUST- This term means the same as MUST.  However, we expect at some
      point that this algorithm will no longer be a MUST in a future
      document.  [...]

I'd give preference to the word-shuffled variant:

|    MUST- This term means the same as MUST.  However, we expect that at
|     some point this algorithm will no longer be a MUST in a future
      document.  [...]

(2)  Section 2.2

Without explanation, the draft says:

   Receiving agents MUST support v1 X.509 and v3 X.509 identity
   certificates as profiled in [KEYM].  [...]

This comes to surprise.  Why are v2 certificates excluded?

The deliberations in RFC 5280 seem to make v1 much less preferable.

If there ideed are reasons for this particular requirement, a hint
on the rationale would be useful.

(3)  Section 3

Below the ASN.1 fragment, please

     s/an upper bounds/an upper bound/
                     ^

(4)  Section 4.3

The last paragraph says:

   A receiving agent MUST be capable of verifying the signatures on
   certificates and CRLs with key sizes from 512 bits to 2048 bits.

This requirement seems to be taylored to RSA/DSA key sizes,
but possibly not appropriate for the developing ECDSA context.

To not inappropriately exclude shorter ECDSA key sizes and request
support for unusually large ECDSA key sizes, the above statement
should perhaps be restricted in scope.  Matching the algorithm
support requirements in the earlier parts of 4.3, but not precluding
future more previce specification of ECDSA use with PKIX, CMS, and
S/MIME, I propose to amend the above statement to say:

                                                 vvvvvvvvvvvvv
|  A receiving agent MUST be capable of verifying RSA and DSA signatures
   on certificates and CRLs with key sizes from 512 bits to 2048 bits.

(5)  Sections 6

The lenghty deliberations on MD2 in this section seem to be aged,
or almost historical now.  Shouldn't there be some words pointing
out more recent developments, in particular the perceived issues
with / reduced confidence in MD5 (and perhaps also SHA-1) as well?

(6)  Appendix A

It is very unusual to label these sections "Appendix".
I suggest to renumber "Appendix A" to "Section 7".

"[RFC-2822]" is the only ref. tag used incorporating an RFC number.
I do not know the planned schedule, but it might happen that
2822-upd will be faster on the publication track, making a ref.
update necessary.  To prepare for it, and to arrive at a more
homogenous ref. tag style, I suggest replacing "[RFC-2822]"
by "[IMF]".

For clerical completeness, I note the race condition that has
occurred by nearly concurrent publication events, making the
draft miss the ref. update:   [KEYM] --> RFC 5280.

Kind regards,
  Alfred HÎnes.

--

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [email-masked]                     |
+------------------------+--------------------------------------------+

----- End of forwarded message from Alfred HÎnes -----

From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: S/MIME v3.2  IDs key size text
Cc: [email-masked]
Date: Wed, 14 May 2008 18:35:56 +1200
Sender: [email-masked]

Paul Hoffman <[email-masked]> writes:

>...and none of these relate to the S/MIME standard, right?

Uhh, my posting specifically mentioned PKCS #7 signing (you actually quote the
sentence right below the above comment), which the last time I checked was
still S/MIME.

>>How many would you like?
>Only real ones that relate to this thread, thank you.

Geeze, how many do you want me to dig up?  The three I mentioned are ones
readily to hand and ones where I knew I could mention them (in anonymised
form), I'd have to ask about posting some of the others (and also spend way
more time than it's worth digging through old email to locate them).  In any
case here's another one, from some years ago, again PKCS #7 (although PKCS #7
could probably be valid today as well, some places still don't know there's
something called CMS).  Anyway, some folks were using 256-bit RSA keys to send
signed EDI messages around wrapped in PKCS #7 envelopes.  The reason they used
these was because their application, written by some contractor in Java [0],
ran really slowly and their security guy [1] told them that the performance
problems were because of the RSA key size being used, which was initially 1K
bits (it had nothing to do with the fact that it was written in Java, it was
purely the RSA key size's fault).  Since they were using keys twice as large
as the industry standard 128 bits and everyone knew 128 bits was totally
secure, they were perfectly OK.

>If you have actual quotes of people saying that, fine; quoting someone third-
>hand through an IETF security geek is not a good way to get accurate results.

It wasn't third-hand, it was either from me if I was involved in the work or
from the person who was involved if it wasn't me [2].  In the above case
(which I was directly involved with) "the standard doesn't disallow it" was
the argument given for using the 256-bit keys, some mere coders tried to point
out that this was wrong and the response was that there was nothing in the
standard so say it was wrong and anyway the contractors had already spent X
amount of time on it so unless anyone could come up with a good reason not to,
it was being deployed with 256-bit RSA signatures.  And so it went.

Peter.

[0] This was before things like Bouncy Castle were freely available and
    people had to build higher-level protocols from raw JCE parts with their
    own three hands.
[1] He'd read the first two chapters of Applied Crypto.
[2] Or are you saying that other members of this list, who provided some of
    the information, aren't reliable sources?  Is there a vetting procedure
    they're supposed to go through first?  Shall I ask for affidavits?

Date: Tue, 13 May 2008 12:18:23 -0700
To: Luther Martin <[email-masked]>, Peter Gutmann	<[email-masked]>
From: Paul Hoffman <[email-masked]>
Subject: RE: S/MIME v3.2  IDs key size text
Cc: "[email-masked]" <[email-masked]>
Sender: [email-masked]

At 10:47 AM -0700 5/13/08, Luther Martin wrote:
>  > -----Original Message-----
>  > From: [email-masked] [mailto:[email-masked]]
>  > On Behalf Of Paul Hoffman
>  > >In the
>  > >case of two of the three above the justification given was some variation
>  > on
>  > >"if these really were no good then they'd be explicitly disallowed.
>  > Since
>  > >they aren't, it's perfectly OK to do this".
>  >
>  > I'm skeptical, to say the least. If you have actual quotes of people
>  > saying that, fine; quoting someone third-hand through an IETF
>  > security geek is not a good way to get accurate results.
>
>I'm with Peter on this one.
>
>I don't want to try to one-up Peter's stories (although I might be 
>able to), I've also seen all sorts of blunders caused by people 
>unfamiliar with public-key technology not understanding things that 
>everyone on this list almost certainly takes for granted. I'd guess 
>that most people who have worked with users of public-key technology 
>for any length of time have a similar set of stories.

Of course this is true. What I question is Peter's assertion that 
putting a "don't be stupid" clause in the S/MIME RFC will cause any 
of them to be less stupid. In order to believe that, I want to hear 
someone say "I read the RFC and I still made this decision". I doubt 
that is true because I doubt any of these folks read the RFC.

>I've also seen people wanting to do make all sorts of 
>crypto-blunders to make things easier to use, more efficient, or to 
>comply with the letter of regulations instead of the spirit.
>
>So explicitly banning things that might qualify as such blunders is 
>probably a very good idea.

Maybe so, but that's not what Peter was advocating. I'm pretty sure 
he was supporting a statement that applications MUST NOT validate 
signatures that are 511 bits long while allow applications to 
validate signatures that are 512 bits long.

Date: Tue, 13 May 2008 10:57:06 -0700
From: Blake Ramsdell <[email-masked]>
To: [email-masked]
Subject: [CAT HERDING] Key lengths for interoperability and security considerations
Sender: [email-masked]

OK, so what needs to be done to come to closure on the key sizes. I think a
skeleton of The Right Thing looks something like this:

1. Normative language (MUST / SHOULD with lots of plusses and minuses and
   atsigns) describing the minimum and maximum lengths for keys. This covers
   the most important area of interoperability, and needs to be very clear
   about signing key lengths vs. verifying key lengths vs. generating key
   lengths.

2. An indication by those MUST / SHOULD statements pointing to the security
   considerations. This is the best we can do to guide people away from using
   one bit keys, and steer them in the direction of strong crypto.

3. Wording in the security considerations regarding the use of overshort or
   overlong keys.

Sean is preparing a summary of the existing discussion to address each point,
and we'll see where we're at.

Blake

From: Luther Martin <[email-masked]>
To: "'Paul Hoffman'" <[email-masked]>, Peter Gutmann <[email-masked]>
CC: "[email-masked]" <[email-masked]>
Date: Tue, 13 May 2008 10:47:59 -0700
Subject: RE: S/MIME v3.2  IDs key size text
Accept-Language: en-US
acceptlanguage: en-US
Sender: [email-masked]

--_000_B870629719727B4BA82A6C06A31C291203064022F4hqmailsvr01vo_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]=
]
> On Behalf Of Paul Hoffman
> >In the
> >case of two of the three above the justification given was some variatio=
n
> on
> >"if these really were no good then they'd be explicitly disallowed.
> Since
> >they aren't, it's perfectly OK to do this".
>
> I'm skeptical, to say the least. If you have actual quotes of people
> saying that, fine; quoting someone third-hand through an IETF
> security geek is not a good way to get accurate results.

I'm with Peter on this one.

I don't want to try to one-up Peter's stories (although I might be able to)=
, I've also seen all sorts of blunders caused by people unfamiliar with pub=
lic-key technology not understanding things that everyone on this list almo=
st certainly takes for granted. I'd guess that most people who have worked =
with users of public-key technology for any length of time have a similar s=
et of stories.

I've also seen people wanting to do make all sorts of crypto-blunders to ma=
ke things easier to use, more efficient, or to comply with the letter of re=
gulations instead of the spirit.

So explicitly banning things that might qualify as such blunders is probabl=
y a very good idea.

--_000_B870629719727B4BA82A6C06A31C291203064022F4hqmailsvr01vo_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<style>
<!--
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:10.0pt;
	font-family:"Courier New";}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 77.95pt 1.0in 77.95pt;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span style=3D'=
font-size:
10.0pt'>&gt; -----Original Message-----<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'>&gt; From: [email-masked]
[mailto:[email-masked]]<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'>&gt; On Behalf Of Paul Hoffman<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'>&gt; &gt;In the<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'>&gt; &gt;case of two of the three above the justification given was
some variation<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'>&gt; on<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'>&gt; &gt;&quot;if these really were no good then they'd be explicit=
ly disallowed.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'>&gt; Since<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'>&gt; &gt;they aren't, it's perfectly OK to do this&quot;.<o:p></o:p=
></span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'>&gt; <o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'>&gt; I'm skeptical, to say the least. If you have actual quotes of
people<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'>&gt; saying that, fine; quoting someone third-hand through an IETF<=
o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'>&gt; security geek is not a good way to get accurate results.<o:p><=
/o:p></span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'>I'm with Peter on this one. <o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'>I don't want to try to one-up Peter's stories (although I might be =
able
to), I've also seen all sorts of blunders caused by people unfamiliar with
public-key technology not understanding things that everyone on this list a=
lmost
certainly takes for granted. I'd guess that most people who have worked wit=
h
users of public-key technology for any length of time have a similar set of
stories.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'>I've also seen people wanting to do make all sorts of crypto-blunde=
rs
to make things easier to use, more efficient, or to comply with the letter =
of
regulations instead of the spirit. <o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'>So explicitly banning things that might qualify as such blunders is
probably a very good idea.<o:p></o:p></span></font></p>

</div>

</body>

</html>

--_000_B870629719727B4BA82A6C06A31C291203064022F4hqmailsvr01vo_--

Date: Tue, 13 May 2008 09:09:46 -0700
To: [email-masked]
From: [email-masked] (by way of Paul Hoffman)
Subject: I-D ACTION:draft-ietf-smime-3851bis-02.txt
Sender: [email-masked]

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-02.txt
	Pages		: 40
	Date		: 2008-5-12

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

Date: Tue, 13 May 2008 09:09:26 -0700
To: [email-masked]
From: [email-masked] (by way of Paul Hoffman)
Subject: I-D ACTION:draft-ietf-smime-3850bis-02.txt
Sender: [email-masked]

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-02.txt
	Pages		: 18
	Date		: 2008-5-12

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

Date: Tue, 13 May 2008 09:08:43 -0700
To: [email-masked] (Peter Gutmann)
From: Paul Hoffman <[email-masked]>
Subject: Re: S/MIME v3.2  IDs key size text
Cc: [email-masked]
Sender: [email-masked]

At 6:50 PM +1200 5/13/08, Peter Gutmann wrote:
>Paul Hoffman <[email-masked]> writes:
>
>>You'll need to justify this one, Peter. Show me some examples where any
>>previous version of S/MIME, none of which have "sane" lower limits, was used
>>by any organization to justify a stupid key size.
>
>How many would you like?

Only real ones that relate to this thread, thank you.

>Without naming names (if anyone really insists I
>could perhaps name them in private), there's an organisation using 128-bit RSA
>keys for access control to significant amounts of power switching gear because
>everyone knows that 128-bit keys are good so it should be fine for RSA.  Since
>this is in the US I'm not that fussed about someone using it to take out their
>power transmission systems :-), but I think some other people might be.  Uhh,
>Canadian health board using RSA in ECB mode to encrypt patient data, and they
>ended up using either 128- or 64-bit keys because otherwise things ran too
>slowly.  Signing using 384-bit keys by a european government organisation...
>how many do you want, and how long have you got?  I haven't got them all
>committed to memory so I'd have to dig back through old email and whatnot.

...and none of these relate to the S/MIME standard, right?

>I realise these aren't all specificially for S/MIME (the signing one was, at
>least for PKCS #7) but they're examples of just what people will do if the
>standards don't disallow it.

I'll take that as a "right, they don't relate to the S/MIME standard, 
they're general key-size blunders". That is, the current S/MIME 
standard mandates being able to sign with 512-bit keys, but your 
examples above show that the blunderers don't do that. Please explain 
why you think that changing the standard will have any effect on them 
at all.

>A number of the examples came from talking to
>other IETF security folks so there's probably a lot more like this floating
>around (every time I post one of these horror-story comments I tend to get a
>bunch of email saying "That's nothing, you should hear this one...").

Fully agree.

>In the
>case of two of the three above the justification given was some variation on
>"if these really were no good then they'd be explicitly disallowed.  Since
>they aren't, it's perfectly OK to do this".

I'm skeptical, to say the least. If you have actual quotes of people 
saying that, fine; quoting someone third-hand through an IETF 
security geek is not a good way to get accurate results.

>  >Please suggest specific text that would meet your criteria.
>
>The original (proposed) MUST NOT text.

There was no verb in that text. Are you supporting "MUST NOT sign 
with keys under 512 bits", "MUST NOT verify signatures whose keys are 
under 512 bits", or both?

>There's no point in verifying a
>signature that you know is insecure because you know no more about the
>validity of the data after the verification than you did before.

Fully agree. Please say why you know that every signature with keys 
of 511 bits is insecure, yet ones with 512 bits are secure enough.

>If the
>signature can't tell you anything about the validity of the data that's been
>signed then it should be rejected as an invalid signature because it's not
>serving the purpose for which it was intended.

Fully agree.

From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: S/MIME v3.2  IDs key size text
Cc: [email-masked]
Date: Tue, 13 May 2008 18:50:02 +1200
Sender: [email-masked]

Paul Hoffman <[email-masked]> writes:

>You'll need to justify this one, Peter. Show me some examples where any
>previous version of S/MIME, none of which have "sane" lower limits, was used
>by any organization to justify a stupid key size.

How many would you like?  Without naming names (if anyone really insists I
could perhaps name them in private), there's an organisation using 128-bit RSA
keys for access control to significant amounts of power switching gear because
everyone knows that 128-bit keys are good so it should be fine for RSA.  Since
this is in the US I'm not that fussed about someone using it to take out their
power transmission systems :-), but I think some other people might be.  Uhh,
Canadian health board using RSA in ECB mode to encrypt patient data, and they
ended up using either 128- or 64-bit keys because otherwise things ran too
slowly.  Signing using 384-bit keys by a european government organisation...
how many do you want, and how long have you got?  I haven't got them all
committed to memory so I'd have to dig back through old email and whatnot.

I realise these aren't all specificially for S/MIME (the signing one was, at
least for PKCS #7) but they're examples of just what people will do if the
standards don't disallow it.  A number of the examples came from talking to
other IETF security folks so there's probably a lot more like this floating
around (every time I post one of these horror-story comments I tend to get a
bunch of email saying "That's nothing, you should hear this one...").  In the
case of two of the three above the justification given was some variation on
"if these really were no good then they'd be explicitly disallowed.  Since
they aren't, it's perfectly OK to do this".

>Please suggest specific text that would meet your criteria.

The original (proposed) MUST NOT text.  There's no point in verifying a
signature that you know is insecure because you know no more about the
validity of the data after the verification than you did before.  If the
signature can't tell you anything about the validity of the data that's been
signed then it should be rejected as an invalid signature because it's not
serving the purpose for which it was intended.

Peter.

Date: Mon, 12 May 2008 15:20:31 -0700
To: "Turner, Sean P." <[email-masked]>
From: Paul Hoffman <[email-masked]>
Subject: RE: S/MIME v3.2  IDs key size text (resend, no signature)
Cc: <[email-masked]>
Sender: [email-masked]

At 5:57 PM -0400 5/12/08, Turner, Sean P. wrote:
>  >-----Original Message-----
>>From: [email-masked]
>>[mailto:[email-masked]] On Behalf Of Paul Hoffman
>>Sent: Monday, May 12, 2008 12:49 PM
>>To: Tony Capel
>>Cc: [email-masked]
>>Subject: RE: S/MIME v3.2 IDs key size text (resend, no signature)
>>
>>
>>At 12:14 PM -0400 5/12/08, Tony Capel wrote:
>>>Sean et al:
>>>
>>>How about:
>>>
>>>     0 <  key size < 512     : MAY     but refer to security
>>considerations
>>>section
>>>   512 <= key size < 1024    : SHOULD- but refer to security
>>considerations
>>>section
>>>1024 <= key size <= 2048   : MUST
>>>2048 <  key size           : MAY     but refer to security
>>considerations
>>>section
>>
>>Could you add verbs to your table? MAY what? SHOULD- what?
>
>Not sure what Tony was thinking but I suggested that this go in 3850bis so
>it would have been for receiving agents.

In your mind, what verb goes with "SHOULD-" for a receiving agent? 
"SHOULD be able to verify but we won't require it in a future 
version"? If so, that means that we are saying "we intend to break 
interoperability with previous versions of this spec because of 
security issues". Breaking the implied stability promise we made when 
there is no real threat (such as people forging 768-bit signatures) 
seems a bit over the top.

Further, such an interpretation of SHOULD- also means that we intend 
to deprecate 1024 bit keys in the foreseeable future even though the 
cryptographic security of >90% of Internet commerce is based on those 
keys. If the intention was to get implementers to take us seriously, 
saying this may not have the desired effect.

From: "Turner, Sean P." <[email-masked]>
To: "'Paul Hoffman'" <[email-masked]>, "'Tony Capel'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: S/MIME v3.2  IDs key size text (resend, no signature)
Date: Mon, 12 May 2008 17:57:54 -0400
Organization: IECA, Inc.
Sender: [email-masked]

>-----Original Message-----
>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of Paul Hoffman
>Sent: Monday, May 12, 2008 12:49 PM
>To: Tony Capel
>Cc: [email-masked]
>Subject: RE: S/MIME v3.2 IDs key size text (resend, no signature)
>
>
>At 12:14 PM -0400 5/12/08, Tony Capel wrote:
>>Sean et al:
>>
>>How about:
>>
>>    0 <  key size < 512     : MAY     but refer to security 
>considerations
>>section
>>  512 <= key size < 1024    : SHOULD- but refer to security 
>considerations
>>section
>>1024 <= key size <= 2048   : MUST
>>2048 <  key size           : MAY     but refer to security 
>considerations
>>section
>
>Could you add verbs to your table? MAY what? SHOULD- what?

Not sure what Tony was thinking but I suggested that this go in 3850bis so
it would have been for receiving agents.

>>"A denial of service opportunity may exploitable by attackers who 
>>provide an excessively large key, or a key selected to require 
>>excessive cryptographic processing.  One mitigation approach would 
>>require that the corresponding public key certificate be 
>validated to a 
>>trusted root [trust anchor] prior to use, thus ensuring that only 
>>trusted public keys are used.  However, some implementations 
>may choose 
>>to perform signature verification (or data encryption) in 
>parallel with 
>>certificate validation, or 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."
>
>Regardless of small key size issue, I think text like this 
>would be a good addition to the Security Considerations 
>section of many documents.

I had something similar in the -02 version, but I'll swap out that text for
this text.

spt

Date: Mon, 12 May 2008 14:25:34 -0700
To: Timothy J Miller <[email-masked]>
From: Paul Hoffman <[email-masked]>
Subject: Re: S/MIME v3.2  IDs key size text (resend, no signature)
Cc: <[email-masked]>
Sender: [email-masked]

At 3:51 PM -0500 5/12/08, Timothy J Miller wrote:
>On May 12, 2008, at 3:19 PM, Paul Hoffman wrote:
>
>>Only somewhat similar. Tony's proposed changes has a "SHOULD 
>>inform" and a "SHOULD provide a warning". The quoted test is 
>>"SHOULD provide alternate processing" which may be displaying a 
>>message. That's a big difference.
>
>Yet the very next paragraph says:
>
>"""
>A receiving agent SHOULD display a subject name or other certificate 
>details when displaying an indication of successful or unsuccessful 
>signature verification.
>"""
>
>Sounds the same to me.

Reading that quoted sentence, can you see that the "SHOULD" does not 
apply when not "displaying an indication..."? That sentence does not 
mandate showing anything. If there is something in an S/MIME document 
that mandates "showing" or "warning", it is an error. We spent years 
(well, now a decade) working on this so that a conformant 
implementation does not need to have a UI.

>Here's the thing:  You're advocating interpreting the spec as purely 
>a protocol spec.  If that's what you're after, then that's a bigger 
>issue than trading barbs over key length recommendations.  There are 
>a number of clauses that require UI implementation that need to be 
>struck out (or at least moved to the security considerations 
>section).

Struck out, definitely. By all means point them out. I've read this 
too many times to find them, I guess.

>But here's my problem with that thinking:  S/MIME isn't just a 
>protocol, it's a ceremony.  There's an fundamental UI aspect to 
>ceremonies.

I disagree strongly with the former while agreeing strongly with the latter.

>This needs to be dealt with properly and *prominently* or we'll end 
>up with implementations that don't just *allow* bad things to be 
>done, but that *mislead users* into thinking things are true about 
>messages that just aren't.

That "misleading" will happen regardless of what the spec says. It 
already happens now, and it happened before the IETF took over 
S/MIME. And it's not just S/MIME: nearly every security protocol the 
IETF has developed has the same problem. It's in the nature of 
security and users and vendors.

If you want to write a BCP for implementers, that's great. This 
mailing list would be a great place for it to be discussed. This spec 
is not a BCP: it is a standard that needs to be consistent on both 
interoperability and security.

>Moving all UI-related issues or security related recommendations to 
>a separate section lowers their visibility, and that's not a good 
>thing IMHO.

It definitely lowers their visibility, and it's also the way we 
usually do things in the IETF. We've done it for over a decade for 
much higher-profile security protocols such as TLS and IPsec as well.

From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: I-D ACTION:draft-ietf-smime-3850bis-02.txt 
Date: Mon, 12 May 2008 14:15:03 -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-02.txt
	Pages		: 18
	Date		: 2008-5-12
	
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-02.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-02.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-02.txt 
Date: Mon, 12 May 2008 14:15:03 -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-02.txt
	Pages		: 40
	Date		: 2008-5-12
	
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-02.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-02.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--NextPart--

Cc: <[email-masked]>
From: Timothy J Miller <[email-masked]>
To: Paul Hoffman <[email-masked]>
Subject: Re: S/MIME v3.2  IDs key size text (resend, no signature)
Date: Mon, 12 May 2008 15:51:22 -0500
Sender: [email-masked]

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

On May 12, 2008, at 3:19 PM, Paul Hoffman wrote:

> Only somewhat similar. Tony's proposed changes has a "SHOULD inform"  
> and a "SHOULD provide a warning". The quoted test is "SHOULD provide  
> alternate processing" which may be displaying a message. That's a  
> big difference.

Yet the very next paragraph says:

"""
A receiving agent SHOULD display a subject name or other certificate  
details when displaying an indication of successful or unsuccessful  
signature verification.
"""

Sounds the same to me.

Here's the thing:  You're advocating interpreting the spec as purely a  
protocol spec.  If that's what you're after, then that's a bigger  
issue than trading barbs over key length recommendations.  There are a  
number of clauses that require UI implementation that need to be  
struck out (or at least moved to the security considerations section).

But here's my problem with that thinking:  S/MIME isn't just a  
protocol, it's a ceremony.  There's an fundamental UI aspect to  
ceremonies.  This needs to be dealt with properly and *prominently* or  
we'll end up with implementations that don't just *allow* bad things  
to be done, but that *mislead users* into thinking things are true  
about messages that just aren't.

Moving all UI-related issues or security related recommendations to a  
separate section lowers their visibility, and that's not a good thing  
IMHO.

-- Tim

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

--Apple-Mail-20-390051725--

Date: Mon, 12 May 2008 13:19:10 -0700
To: Timothy J Miller <[email-masked]>
From: Paul Hoffman <[email-masked]>
Subject: Re: S/MIME v3.2  IDs key size text (resend, no signature)
Cc: <[email-masked]>
Sender: [email-masked]

At 1:43 PM -0500 5/12/08, Timothy J Miller wrote:
>On May 12, 2008, at 11:49 AM, Paul Hoffman wrote:
>>
>>>When feasible, sending and receiving agents SHOULD inform senders (prior
>>>to transmission) and recipients of the relative cryptographic strength of
>>>messages and SHOULD provide a warning if weak algorithms or key sizes are
>>>used.
>>
>>I'm lost here. Using the protocol described in the document, how 
>>would I send such information? How would I send such a warning?
>
>Yet similar advice exists elsewhere in the cert handling spec:
>
>"""
>A receiving agent SHOULD provide some explicit alternate processing 
>of the message if this comparison     fails, which may be to display 
>a message that shows the recipient the addresses in the certificate 
>or other certificate details.
>"""  (ref: sec 3)

Only somewhat similar. Tony's proposed changes has a "SHOULD inform" 
and a "SHOULD provide a warning". The quoted test is "SHOULD provide 
alternate processing" which may be displaying a message. That's a big 
difference.

>Are you saying that this should come out as well, since your 
>objection to the RFC advising implementors to warn users re: key 
>strength clearly also applies to the RFC advising implementors re: 
>an email mismatch?

Nope. I have nothing against advising implementers. Heck, I've 
written a lot of the text that does that. What I object to is a 
SHOULD-level "inform" or "provide a warning" when we have no 
protocol-standard way of doing so.

From: "Turner, Sean P." <[email-masked]>
To: <[email-masked]>
Subject: RE: draft-ietf-smime-rfc3278-update-02
Date: Mon, 12 May 2008 16:08:17 -0400
Organization: IECA, Inc.
Sender: [email-masked]

>-----Original Message-----
>From: Alfred H=CEnes [mailto:[email-masked]]=20
>Sent: Thursday, April 24, 2008 1:39 PM
>To: [email-masked]
>Cc: [email-masked]; [email-masked]
>Subject: Re: draft-ietf-smime-rfc3278-update-02

<snip>

>> All,
>>=20
>> Does anybody think it would be clearer to resubmit this to be a bis=20
>> draft (i.e., obsolete 3278) instead of an update draft?
>> Originally, the draft just updated the ECDSA 224-512 and SHA2=20
>> algorithms, but now it updates most of the sections in RFC3278.
>> I think it might be clearer to just obsolete RFC3278.
>>=20
>> spt
>
>When it comes to security, unnecessary complexity is evil.
>And complexity sometimes starts with the specification(s).
>
>In this case, the current draft already is an excellent=20
>example of how documents updating earlier specifications=20
>should be written to avoid any ambiguity related to what in=20
>detail is updated in which manner.
>
>Nevertheless, I strongly support the idea to merge the still=20
>valid parts of RFC 3278 with this draft, to obtain a single=20
>concise replacement document.  There are lots of examples=20
>where RFCs have been superseded by newer ones for much less=20
>substantial updates.

I haven't heard an objection to this so I'm going to submit a new -00 ID
that is going to obsolete 3278 as opposed to update it. The current ID =
will
die on the vine.

>A unified new document would also allow to update all the Refs=20
>in 3278 (including RFC-to-be 5280), split these into Normative=20
>and Informative, and adapt the boilerplate matter to the new=20
>ISOC/IETF position on IPR stuff.
>
>But when this step is undertaken, the next question immediately
>arises:  Why not also going from Informational to Standards Track?

Since there's IPR with ECC all the IETF IDs/RFCs that deal with ECC are
Informational.

spt

Cc: "Tony Capel" <[email-masked]>, <[email-masked]>
From: Timothy J Miller <[email-masked]>
To: Paul Hoffman <[email-masked]>
Subject: Re: S/MIME v3.2  IDs key size text (resend, no signature)
Date: Mon, 12 May 2008 13:43:37 -0500
Sender: [email-masked]

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

On May 12, 2008, at 11:49 AM, Paul Hoffman wrote:
>
>> When feasible, sending and receiving agents SHOULD inform senders  
>> (prior
>> to transmission) and recipients of the relative cryptographic  
>> strength of
>> messages and SHOULD provide a warning if weak algorithms or key  
>> sizes are
>> used.
>
> I'm lost here. Using the protocol described in the document, how  
> would I send such information? How would I send such a warning?

Yet similar advice exists elsewhere in the cert handling spec:

"""
A receiving agent SHOULD provide some explicit alternate processing of  
the message if this comparison     fails, which may be to display a  
message that shows the recipient the addresses in the certificate or  
other certificate details.
"""  (ref: sec 3)

Are you saying that this should come out as well, since your objection  
to the RFC advising implementors to warn users re: key strength  
clearly also applies to the RFC advising implementors re: an email  
mismatch?

-- Tim

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

--Apple-Mail-16-382386151--

Date: Mon, 12 May 2008 09:36:30 -0700
To: [email-masked] (Peter Gutmann)
From: Paul Hoffman <[email-masked]>
Subject: Re: S/MIME v3.2  IDs key size text
Cc: [email-masked]
Sender: [email-masked]

At 3:32 AM +1200 5/13/08, Peter Gutmann wrote:
>Paul Hoffman <[email-masked]> writes:
>
>>We are not the security nannies of the Internet. As long as we give a
>>reasonable number of bits that all implementations should be able to sign and
>>verify in order to make reasonably-strong signatures, we should step back and
>>let organizations make their own rules.
>
>No, that's exactly what we shouldn't do, because then organisations will use
>the fact that the standard doesn't set a sane limit on the key size to justify
>using completely stupid key sizes (or as a generalisation completely insecure
>"security" practices) [0].

You'll need to justify this one, Peter. Show me some examples where 
any previous version of S/MIME, none of which have "sane" lower 
limits, was used by any organization to justify a stupid key size.

>I realise that it's not possible to explicitly
>outlaw every kind of stupid behaviour that users will engage in, but since
>there's a list of key sizes in the doc anyway it's a pretty trivial change to
>add a sensible lower bound to it.

It is a list of two elements: there is already a sensible lower 
bound. Please suggest specific text that would meet your criteria.

Date: Mon, 12 May 2008 09:49:00 -0700
To: "Tony Capel" <[email-masked]>
From: Paul Hoffman <[email-masked]>
Subject: RE: S/MIME v3.2  IDs key size text (resend, no signature)
Cc: <[email-masked]>
Sender: [email-masked]

At 12:14 PM -0400 5/12/08, Tony Capel wrote:
>Sean et al:
>
>How about:
>
>    0 <  key size < 512     : MAY     but refer to security considerations
>section
>  512 <= key size < 1024    : SHOULD- but refer to security considerations
>section
>1024 <= key size <= 2048   : MUST
>2048 <  key size           : MAY     but refer to security considerations
>section

Could you add verbs to your table? MAY what? SHOULD- what?

>"A denial of service opportunity may exploitable by attackers who provide
>an excessively large key, or a key selected to require excessive
>cryptographic processing.  One mitigation approach would require that the
>corresponding public key certificate be validated to a trusted root [trust
>anchor] prior to use, thus ensuring that only trusted public keys are
>used.  However, some implementations may choose to perform signature
>verification (or data encryption) in parallel with certificate validation,
>or 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."

Regardless of small key size issue, I think text like this would be a 
good addition to the Security Considerations section of many 
documents.

>Proposed Draft text:
>
>"Using weak cryptography in S/MIME offers little actual security over
>sending plaintext.
>Some cryptographers consider public keys of less than 1024* bits to be
>weak, along with symmetric encryption algorithms of less than 64 bits and
>certain older hash algorithms used for signing.

And some don't consider 1024 bits weak. For example, there are lots 
of 1024-bit certificates in the trust anchor pile in your browser. To 
date, no one is known to have compromised even one of them, even 
though doing so would have higher value than compromising almost any 
individual's signing key. Cryptographers who look at the real world 
of costs and benefits have noticed this.

>In any given application, an appropriate analysis of the threats and risks
>SHOULD lead to the selection of appropriate algorithms and key sizes.

That SHOULD is misplaced. Please re-read RFC 2119. Further, we all 
know that this sentence is more often false than true in the real 
world. What is the advantage of reproducing this fairy tale in the 
S/MIME spec?

>When feasible, sending and receiving agents SHOULD inform senders (prior
>to transmission) and recipients of the relative cryptographic strength of
>messages and SHOULD provide a warning if weak algorithms or key sizes are
>used.

I'm lost here. Using the protocol described in the document, how 
would I send such information? How would I send such a warning?

From: "Tony Capel" <[email-masked]>
To: "'Timothy J Miller'" <[email-masked]>, "'Paul Hoffman'" <[email-masked]>
Cc: "'Turner, Sean P.'" <[email-masked]>, <[email-masked]>
Subject: RE: S/MIME v3.2  IDs key size text (resend, no signature)
Date: Mon, 12 May 2008 12:14:03 -0400
Importance: Normal
Sender: [email-masked]

Sean et al:

How about:

   0 <  key size < 512     : MAY     but refer to security considerations
section
 512 <= key size < 1024    : SHOULD- but refer to security considerations
section
1024 <= key size <= 2048   : MUST
2048 <  key size           : MAY     but refer to security considerations
section

For larger keys, some text for the security considerations section might
be added, e.g. something like:

"A denial of service opportunity may exploitable by attackers who provide
an excessively large key, or a key selected to require excessive
cryptographic processing.  One mitigation approach would require that the
corresponding public key certificate be validated to a trusted root [trust
anchor] prior to use, thus ensuring that only trusted public keys are
used.  However, some implementations may choose to perform signature
verification (or data encryption) in parallel with certificate validation,
or 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."

For smaller keys, this is already addressed to some extent for encryption
in the security considerations section, maybe this needs updating based on
our experience with smime:

Current text:

   40-bit encryption is considered weak by most cryptographers. Using
   weak cryptography in S/MIME offers little actual security over
   sending plaintext.  However, other features of S/MIME, such as the
   specification of tripleDES and the ability to announce stronger
   cryptographic capabilities to parties with whom you communicate,
   allow senders to create messages that use strong encryption.  Using
   weak cryptography is never recommended unless the only alternative is
   no cryptography.  When feasible, sending and receiving agents SHOULD
   inform senders and recipients of the relative cryptographic strength
   of messages.

Proposed Draft text:

"Using weak cryptography in S/MIME offers little actual security over
sending plaintext.
Some cryptographers consider public keys of less than 1024* bits to be
weak, along with symmetric encryption algorithms of less than 64 bits and
certain older hash algorithms used for signing.
In any given application, an appropriate analysis of the threats and risks
SHOULD lead to the selection of appropriate algorithms and key sizes.
For public keys, algorithms and key sizes are normally defined by the
public key issuer in the corresponding certificate, and thus not under the
control of the end user.
For symmetric encryption and hash algorithms, S/MIME supports the ability
of parties to communicate their capabilities to each other, allowing the
use of appropriately strong measures.
When feasible, sending and receiving agents SHOULD inform senders (prior
to transmission) and recipients of the relative cryptographic strength of
messages and SHOULD provide a warning if weak algorithms or key sizes are
used.
Such warnings are especially important if the symmetric encryption or hash
algorithm are significantly weaker than the corresponding public key,
since this will result in a message with weaker security than that implied
by the public key certificate. "

Tony

* of course this could be a smaller value.

PS: sorry about earlier e-mail with opaque signing, I did a "Reply to"
which copied the security properties from Timothy's e-mail (but not
cleartext option!) - defaulting to signing which I did not intend!!!

| -----Original Message-----
| From: [email-masked]
| [mailto:[email-masked]] On Behalf Of Timothy J Miller
| Sent: May 12, 2008 9:31 AM
| To: Paul Hoffman
| Cc: Turner, Sean P.; [email-masked]
| Subject: Re: S/MIME v3.2 IDs key size text
|
|
|
| On May 9, 2008, at 4:40 PM, Paul Hoffman wrote:
| >
| > At 12:37 PM -0400 5/6/08, Turner, Sean P. wrote:
| >>
| >>   0 < key size < 511  : MUST NOT
| >> 512 < key size < 1023 : SHOULD-
|
| > Beyond what Russ just pointed out, I find the first line to be in
| > bad taste. Any IETF spec that says "you must not be able to
| verify a
| > signature even though it is valid" is pretty offensive.
|
| How about adding a "MUST warn the user that key is too damn short to
| be considered safe, even though the signature is valid"
| clause instead?
|
| -- Tim
|
|

| -----Original Message-----
| From: [email-masked] 
| [mailto:[email-masked]] On Behalf Of Timothy J Miller
| Sent: May 12, 2008 9:31 AM
| To: Paul Hoffman
| Cc: Turner, Sean P.; [email-masked]
| Subject: Re: S/MIME v3.2 IDs key size text
| 
| 
| 
| On May 9, 2008, at 4:40 PM, Paul Hoffman wrote:
| >
| > At 12:37 PM -0400 5/6/08, Turner, Sean P. wrote:
| >>
| >>   0 < key size < 511  : MUST NOT
| >> 512 < key size < 1023 : SHOULD-
| 
| > Beyond what Russ just pointed out, I find the first line to be in
| > bad taste. Any IETF spec that says "you must not be able to 
| verify a  
| > signature even though it is valid" is pretty offensive.
| 
| How about adding a "MUST warn the user that key is too damn short to  
| be considered safe, even though the signature is valid" 
| clause instead?
| 
| -- Tim
| 
| 

From: "Tony Capel" <[email-masked]>
To: "'Turner, Sean P.'" <[email-masked]>
Cc: <[email-masked]>, "'Paul Hoffman'" <[email-masked]>, "'Timothy J Miller'" <[email-masked]>
Subject: RE: S/MIME v3.2  IDs key size text
Date: Mon, 12 May 2008 11:59:32 -0400
Importance: Normal
Sender: [email-masked]

From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: S/MIME v3.2  IDs key size text
Cc: [email-masked], [email-masked]
Date: Tue, 13 May 2008 03:32:46 +1200
Sender: [email-masked]

Paul Hoffman <[email-masked]> writes:

>We are not the security nannies of the Internet. As long as we give a
>reasonable number of bits that all implementations should be able to sign and
>verify in order to make reasonably-strong signatures, we should step back and
>let organizations make their own rules.

No, that's exactly what we shouldn't do, because then organisations will use
the fact that the standard doesn't set a sane limit on the key size to justify
using completely stupid key sizes (or as a generalisation completely insecure
"security" practices) [0].  I realise that it's not possible to explicitly
outlaw every kind of stupid behaviour that users will engage in, but since
there's a list of key sizes in the doc anyway it's a pretty trivial change to
add a sensible lower bound to it.

Peter.

[0] The best one I've ever heard in this area was a government department that
    said that while a NIST standard required the use of security technology
    X, it didn't say it had to be *effectively* applied, merely applied
    (imagine the computer equivalent of "doors must be fitted with Medeco
    locks", but since the standard never said you have to actually lock the
    doors, merely that they had to be there, it was fine to leave all the
    doors unlocked).  That's an extreme case, but it's merely the tip of the
    iceberg of lesser stupidity that organisations will engage in because a
    standard doesn't say they can't.

Date: Mon, 12 May 2008 08:10:10 -0700
To: Timothy J Miller <[email-masked]>
From: Paul Hoffman <[email-masked]>
Subject: Re: S/MIME v3.2  IDs key size text
Cc: "Turner, Sean P." <[email-masked]>, <[email-masked]>
Sender: [email-masked]

At 8:31 AM -0500 5/12/08, Timothy J Miller wrote:
>On May 9, 2008, at 4:40 PM, Paul Hoffman wrote:
>>
>>At 12:37 PM -0400 5/6/08, Turner, Sean P. wrote:
>>>
>>>   0 < key size < 511  : MUST NOT
>>>512 < key size < 1023 : SHOULD-
>
>>Beyond what Russ just pointed out, I find the first line to be in 
>>bad taste. Any IETF spec that says "you must not be able to verify 
>>a signature even though it is valid" is pretty offensive.
>
>How about adding a "MUST warn the user that key is too damn short to 
>be considered safe, even though the signature is valid" clause 
>instead?

I seriously doubt we could get consensus on the number of bits for 
that to kick in. Also, this would prevent an automated signature 
validation system with no UI from being able to be conformant.

We are not the security nannies of the Internet. As long as we give a 
reasonable number of bits that all implementations should be able to 
sign and verify in order to make reasonably-strong signatures, we 
should step back and let organizations make their own rules.

From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: RE: weak authentication issue with rfc5083
Date: Tue, 13 May 2008 02:17:29 +1200
Sender: [email-masked]

Daniel Brown <[email-masked]> writes:

>This is a serious problem, imo.  If Bob receives an AuthenticatedData from
>Alice but it is not really from Alice, then there really is no
>authentication, despite the promise that AuthenticatedData provides
>authentication.  What security service is AuthenticatedData providing in this
>case?

Maybe it would have been better to call it IntegrityProtectedData :-).  That's
actually the only thing I've ever used it for, my assumption was that you sign
email and you MAC stored data.

Peter.

Content-class: urn:content-classes:message
Subject: RE: S/MIME v3.2  IDs key size text
Date: Mon, 12 May 2008 10:03:10 -0400
From: "Carl Wallace" <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

> How about adding a "MUST warn the user that key is too damn short to
be considered safe, even though the=20
> signature is valid" clause instead?
>=20
> -- Tim

This isn't sufficient for verification of archived email.  A weak
signature may be covered by a timestamp that enables its verification.
This problem should be addressed using something like DSSC. =20

Cc: "Turner, Sean P." <[email-masked]>, <[email-masked]>
From: Timothy J Miller <[email-masked]>
To: Paul Hoffman <[email-masked]>
Subject: Re: S/MIME v3.2  IDs key size text
Date: Mon, 12 May 2008 08:31:18 -0500
Sender: [email-masked]

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

On May 9, 2008, at 4:40 PM, Paul Hoffman wrote:
>
> At 12:37 PM -0400 5/6/08, Turner, Sean P. wrote:
>>
>>   0 < key size < 511  : MUST NOT
>> 512 < key size < 1023 : SHOULD-

> Beyond what Russ just pointed out, I find the first line to be in  
> bad taste. Any IETF spec that says "you must not be able to verify a  
> signature even though it is valid" is pretty offensive.

How about adding a "MUST warn the user that key is too damn short to  
be considered safe, even though the signature is valid" clause instead?

-- Tim

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

--Apple-Mail-5-363644505--

Date: Sat, 10 May 2008 15:23:07 -0700
To: [email-masked] (Peter Gutmann), [email-masked], [email-masked]
From: Paul Hoffman <[email-masked]>
Subject: RE: S/MIME v3.2  IDs key size text
Sender: [email-masked]

At 7:45 PM +1200 5/10/08, Peter Gutmann wrote:
>Paul Hoffman <[email-masked]> writes:
>>At 12:37 PM -0400 5/6/08, Turner, Sean P. wrote:
>>>     0 < key size < 511  : MUST NOT
>>>   512 < key size < 1023 : SHOULD-
>>>1024 < key size < 2048 : MUST
>>>2049 < key size < 4096 : MAY
>>
>>Beyond what Russ just pointed out, I find the first line to be in bad taste.
>>Any IETF spec that says "you must not be able to verify a signature even
>>though it is valid" is pretty offensive.
>
>So an implementation is supposed to do what, tell the user that they can be
>absolutely totally assured that the signature is valid, all 12 bits of it?

Yes. Why not? If you don't want to fully comply with the standard for 
any of a variety of reasons, by all means don't.

From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked], [email-masked]
Subject: RE: S/MIME v3.2  IDs key size text
Date: Sat, 10 May 2008 19:45:00 +1200
Sender: [email-masked]

Paul Hoffman <[email-masked]> writes:
>At 12:37 PM -0400 5/6/08, Turner, Sean P. wrote:
>>    0 < key size < 511  : MUST NOT
>>  512 < key size < 1023 : SHOULD-
>>1024 < key size < 2048 : MUST
>>2049 < key size < 4096 : MAY
>
>Beyond what Russ just pointed out, I find the first line to be in bad taste.
>Any IETF spec that says "you must not be able to verify a signature even
>though it is valid" is pretty offensive.

So an implementation is supposed to do what, tell the user that they can be
absolutely totally assured that the signature is valid, all 12 bits of it?  I
guess it'll save implementation time because you can just report "signature
might be valid" without even having to verify it.

Peter.

Date: Fri, 9 May 2008 18:14:10 -0700
To: Blake Ramsdell <[email-masked]>
From: Paul Hoffman <[email-masked]>
Subject: Re: S/MIME v3.2  IDs key size text
Cc: "Turner, Sean P." <[email-masked]>, [email-masked]
Sender: [email-masked]

At 5:12 PM -0700 5/9/08, Blake Ramsdell wrote:
>On Fri, May 09, 2008 at 02:40:17PM -0700, Paul Hoffman wrote:
>>  Beyond what Russ just pointed out, I find the first line to be in bad
>>  taste. Any IETF spec that says "you must not be able to verify a signature
>>  even though it is valid" is pretty offensive.
>>
>>  Can we return to talking about interoperability?
>
>I think you and I are on the same page, and there's two things:
>
>1. Interoperability. The key sizes to guarantee two implementations will talk
>    to each other.
>
>2. Security considerations. The key sizes that are a no-no due to insufficient
>    or overly-sufficient size.
>
>Have we given up on the separation of these?

For interoperability, the receiver MUST be able to verify all sizes 
that the signer MUST be able to sign. For security, the signer MUST 
be able to sign using keys of at least a certain size.

A receiver should expect that some of the signatures it wants to 
verify will be bigger than the one size in the spec because a 
receiver cannot accurately predict the security decisions of all the 
senders with which it interacts.

I propose that that size is 1024 bits: that's plenty of strength for 
most typical non-paranoid applications for at least five years. If it 
turns out to be too short due to an unexpected large reduction in 
strength of RSA, we can revise then. Quite frankly, in that case, we 
might be recommending ECDSA anyhow.

Date: Fri, 9 May 2008 17:12:39 -0700
From: Blake Ramsdell <[email-masked]>
To: Paul Hoffman <[email-masked]>
Cc: "Turner, Sean P." <[email-masked]>, [email-masked]
Subject: Re: S/MIME v3.2  IDs key size text
Sender: [email-masked]

On Fri, May 09, 2008 at 02:40:17PM -0700, Paul Hoffman wrote:
> Beyond what Russ just pointed out, I find the first line to be in bad 
> taste. Any IETF spec that says "you must not be able to verify a signature 
> even though it is valid" is pretty offensive.
>
> Can we return to talking about interoperability?

I think you and I are on the same page, and there's two things:

1. Interoperability. The key sizes to guarantee two implementations will talk
   to each other.

2. Security considerations. The key sizes that are a no-no due to insufficient
   or overly-sufficient size.

Have we given up on the separation of these?

Blake

Date: Fri, 9 May 2008 14:40:17 -0700
To: "Turner, Sean P." <[email-masked]>, <[email-masked]>
From: Paul Hoffman <[email-masked]>
Subject: RE: S/MIME v3.2  IDs key size text
Sender: [email-masked]

At 12:37 PM -0400 5/6/08, Turner, Sean P. wrote:
>Just a thought ... since we've now got a way to indicate + and - with
>requirements should we apply it the key sizes in 3850bis?  That way people
>will have a hint that in the next update the shorter keys will likely become
>not so welcome and large keys more so?
>
>    0 < key size < 511  : MUST NOT
>  512 < key size < 1023 : SHOULD-
>1024 < key size < 2048 : MUST
>2049 < key size < 4096 : MAY

Beyond what Russ just pointed out, I find the first line to be in bad 
taste. Any IETF spec that says "you must not be able to verify a 
signature even though it is valid" is pretty offensive.

Can we return to talking about interoperability?

Date: Fri, 09 May 2008 14:11:21 -0400
To: "Turner, Sean P." <[email-masked]>, "'Tony Capel'" <[email-masked]>, "'Paul Hoffman'" <[email-masked]>, <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: RE: S/MIME v3.2  IDs key size text
Sender: [email-masked]

Are you saying that I MAY NOT support keys bigger than 4096?

At 12:37 PM 5/6/2008, Turner, Sean P. wrote:
>    0 < key size < 511  : MUST NOT
>  512 < key size < 1023 : SHOULD-
>1024 < key size < 2048 : MUST
>2049 < key size < 4096 : MAY

From: Trevor Freeman <[email-masked]>
To: pgut001 <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Fri, 9 May 2008 19:53:02 +0000
Subject: RE: weak authentication issue with rfc5083
Accept-Language: en-US
Sender: [email-masked]

Hi Peter,
The push back to why doesn't everyone just use signatures is when I have an=
 existing security mechanism like Kerberos which builds secure pair wise ke=
ys. Kerberos shared secrets can establish mutual authentication providing b=
oth parties demonstrate knowledge of the shared secret. I don't think the s=
olution is that complex. If I encrypt the MAC with the pair wise secret I a=
chieve mutual authentication. We use the same mechanism to learn the CEK, w=
e just need to do the same again to prove I know both the KEK and the MAC.

Trevor

-----Original Message-----
From: pgut001 [mailto:[email-masked]]
Sent: Friday, May 09, 2008 6:26 AM
To: [email-masked]; [email-masked]; [email-masked]; =
Trevor Freeman
Subject: RE: weak authentication issue with rfc5083

"Jim Schaad" <[email-masked]> writes:

>I believe you have misunderstood the issue that Trevor raised.
>
>His problem is:
>
>1. I send you and him a single Authenticated Message.
>
>2. He takes the common CEK in the original message, uses it to create a MA=
C
>on an new message and then sends it on to you.
>
>As is always true with Authenticated messages, there is no proof of origin=
.
>He worries that you might be confused and believe the second messages was
>from me rather than from him.  Since they both use the same CEK that is no=
t a
>factor that could be used to distinguish them.

Ah, OK, thanks.  How serious a threat is this in practice though?  Wouldn't
people just use asymmetric auth if they're worried about proof of origin?  =
I
realise it's kind of an interesting problem to solve, but does it need solv=
ing
beyond a security considerations note "If you're seriously worried about pr=
oof
of origin use a signature"?

Peter.

From: Daniel Brown <[email-masked]>
To: Peter Gutmann <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Fri, 9 May 2008 10:21:43 -0400
Subject: RE: weak authentication issue with rfc5083
Accept-Language: en-US
acceptlanguage: en-US
Sender: [email-masked]

Peter, Jim,

This is a serious problem, imo.  If Bob receives an AuthenticatedData from =
Alice but it is not really from Alice, then there really is no authenticati=
on, despite the promise that AuthenticatedData provides authentication.  Wh=
at security service is AuthenticatedData providing in this case?  If the Ch=
arles is the attacker, then cannot Charles strip off his RecipientInfo from=
 the AuthenticatedData, in which case, Bob has no way of knowing that Alice=
 originallly sent the AuthenticatedData to two parties?

A difference between SignedData and AuthenticatedData is that with the latt=
er Bob cannot prove (cryptographically) to others that Alice authenticated =
anything.  That's the motivation to use AuthenticatedData instead of Signed=
Data.

***

Maybe AuthEnvData is a little different from AuthData, though.  For example=
, if the key management mechanism is key transport, so Alice provides no ce=
rtificate, then effectively Alice is anonymous.  In that case, the MAC only=
 protects integrity of the message from modification in transit, it does no=
t provide authentication.  (Cf. TLS with unauthenticated clients, where rec=
ords are MAC for a similar purpose.)  If AuthEnvData is used for that lesse=
r purpose, then the substitutuion attack by Charles is not as significant, =
because Alice is essentially anonymous.

>From reading 5083, I interpret its intent only to be add integrity to EnvDa=
ta, since CBC mode does not provide full integrity.  However, for some choi=
ces of key management, it has the further capability of authenticating the =
sender (i.e. if the key management authenticates the sender, which in does =
in all cases except key transport).  This is a useful capability and should=
 be noted.  Regardless, it should be emphasized that, at least in the case =
of key transport, that no actual authentication is provided (just integrity=
).  Otherwise, evidently there is a risk of misinterpretation.

Best regards,

        Dan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] =
On Behalf Of Peter Gutmann
Sent: Friday, May 09, 2008 9:26 AM
To: [email-masked]; [email-masked]; [email-masked]; =
[email-masked]
Subject: RE: weak authentication issue with rfc5083

"Jim Schaad" <[email-masked]> writes:

>I believe you have misunderstood the issue that Trevor raised.
>
>His problem is:
>
>1. I send you and him a single Authenticated Message.
>
>2. He takes the common CEK in the original message, uses it to create a MA=
C
>on an new message and then sends it on to you.
>
>As is always true with Authenticated messages, there is no proof of origin=
.
>He worries that you might be confused and believe the second messages was
>from me rather than from him.  Since they both use the same CEK that is no=
t a
>factor that could be used to distinguish them.

Ah, OK, thanks.  How serious a threat is this in practice though?  Wouldn't
people just use asymmetric auth if they're worried about proof of origin?  =
I
realise it's kind of an interesting problem to solve, but does it need solv=
ing
beyond a security considerations note "If you're seriously worried about pr=
oof
of origin use a signature"?

Peter.

From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: RE: weak authentication issue with rfc5083
Date: Sat, 10 May 2008 01:25:46 +1200
Sender: [email-masked]

"Jim Schaad" <[email-masked]> writes:

>I believe you have misunderstood the issue that Trevor raised.
>
>His problem is:
>
>1. I send you and him a single Authenticated Message.
>
>2. He takes the common CEK in the original message, uses it to create a MAC
>on an new message and then sends it on to you.
>
>As is always true with Authenticated messages, there is no proof of origin.
>He worries that you might be confused and believe the second messages was
>from me rather than from him.  Since they both use the same CEK that is not a
>factor that could be used to distinguish them.

Ah, OK, thanks.  How serious a threat is this in practice though?  Wouldn't
people just use asymmetric auth if they're worried about proof of origin?  I
realise it's kind of an interesting problem to solve, but does it need solving
beyond a security considerations note "If you're seriously worried about proof
of origin use a signature"?

Peter.

From: Tim Polk <[email-masked]>
Subject: Fwd: NIST Identity-Based Encryption Workshop- Registration Deadline Approaching
Date: Wed, 7 May 2008 10:00:36 -0400
To: [email-masked], S-MIME / IETF <[email-masked]>
Sender: [email-masked]

Folks,

My apologies for a brief advertisement...

I am forwarding this workshop announcement since IBE documents are  
currently progressing through one
of the security area working groups, and because I am always anxious  
to see the needs of the Internet
community considered by NIST in our standardization activities.   
Attendance is one way to ensure your
voice is heard.  If you have a strong opinion about IBE and are  
unable to attend, please let me know so
I can pass it along!

Note that the early registration fee is only available through the  
end of the week.

Thanks,

Tim Polk

Begin forwarded message:

> From: Andrew Regenscheid <[email-masked]>
> Date: May 6, 2008 4:08:35 PM EDT
> To: Multiple recipients of list <[email-masked]>
> Subject: NIST Identity-Based Encryption Workshop- Registration  
> Deadline Approaching
> Reply-To: [email-masked]
>
>
> Applications of Pairing-Based Cryptography: Identity-Based  
> Encryption and Beyond
> June 3-4, 2008
> NIST, Gaithersburg, MD
>
> The early registration deadline is approaching!  Please join us at  
> the workshop and help NIST direct its future work on identity-based  
> encryption.
>
> This workshop brings together academia, government and industry to  
> explore innovative and practical applications of pairing-based  
> cryptography.  Pairings have been used to create identity-based  
> encryption schemes, but are also a powerful tool for solving other  
> cryptographic problems.  We hope to encourage the development of  
> new security applications and communication between researchers,  
> developers and users.  In addition to presentations, the workshop  
> will facilitate panel discussions among invited experts and  
> workshop participants.  NIST will seek guidance from workshop  
> presenters, panelists and attendees to direct its future work in  
> this area of cryptography, including possible standards work.
>
> Dr. Matt Franklin, co-inventor of one of the original identity- 
> based encryption schemes, will be presenting a keynote address  
> entitled "An Introduction to Identity Based Encryption."  Dr. Brent  
> Waters will be presenting a keynote address entitled "Functional  
> Encryption: Beyond Public Key Cryptography."  The workshop program  
> also includes two panel discussions and 13 presentations from  
> researchers from around the world.  The complete agenda has been  
> posted at http://www.nist.gov/ibe.
>
> The early registration deadline for the NIST Applications of  
> Pairing Based Cryptography workshop is quickly approaching.  The  
> registration fee is $110 until May 10th, and $145 until May 27th.   
> Please note that these fees have been reduced due to NIST no longer  
> being able to provide food and beverages. Voltage Security and  
> Trend Micro will be sponsoring the morning and afternoon breaks.  
> However, each attendee will be responsible for his/her own lunch.  
> NIST has a full-service cafeteria adjacent to the Green Auditorium.  
> Please note the cafeteria does not take any credit or debit cards.  
> Please be prepared with cash.
>
> More details on the workshop are available at http://www.nist.gov/ibe
>
>
>

From: Trevor Freeman <[email-masked]>
To: Jim Schaad <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Tue, 6 May 2008 21:29:34 +0000
Subject: RE: weak authentication issue with rfc5083
Accept-Language: en-US
Sender: [email-masked]

--_000_F767238E699C2E43895DDFB5F435088F0C2C102509DFMBX61exchan_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

The same is true of the MAC because that is sent as unauthenticated data. T=
he recipients computes the MAC then compares it to the unprotected value se=
nt with the message. The computed value and the transmitted value have to m=
atch otherwise it's an authentication failure.  If you strip or alter the M=
AC the recipient detects problem.
This proposal has exactly the same characteristics.

Trevor

From: Jim Schaad [mailto:[email-masked]]
Sent: Tuesday, May 06, 2008 12:31 PM
To: Trevor Freeman; [email-masked]
Subject: RE: weak authentication issue with rfc5083

I would have an issue with this since could be silently stripped without th=
e recipients or senders knowledge.  Thus I don't see it as solving your pro=
blem.

Jim

From: [email-masked] [mailto:[email-masked]] =
On Behalf Of Trevor Freeman
Sent: Monday, May 05, 2008 3:42 PM
To: Jim Schaad; [email-masked]
Subject: RE: weak authentication issue with rfc5083

Not if you send the recipient info's with the encrypted hmac as an unauthen=
ticated attribute.

Trevor

From: Jim Schaad [mailto:[email-masked]]
Sent: Monday, May 05, 2008 3:38 PM
To: Trevor Freeman; [email-masked]
Subject: RE: weak authentication issue with rfc5083

The downside of this would be that you could no longer do one pass encoding=
.  You would need to compute the HMAC prior to computing the recipient info=
s.

Jim

From: Trevor Freeman [mailto:[email-masked]]
Sent: Monday, May 05, 2008 2:03 PM
To: Trevor Freeman; Jim Schaad; [email-masked]
Subject: RE: weak authentication issue with rfc5083

Another suggestion is to use the kek to wrap the hmac just like you wrapped=
 the CEK.

From: [email-masked] [mailto:[email-masked]] =
On Behalf Of Trevor Freeman
Sent: Monday, May 05, 2008 1:40 PM
To: Jim Schaad; [email-masked]
Subject: RE: weak authentication issue with rfc5083

Hi Jim,
You can demonstrate knowledge of both HMAC and KEK fairly simply per recipi=
ent e.g. by concatenating the KEK with the message HMAC and hashing the res=
ult. Since Mallet does not know the KEK they cannot compute the new hash. T=
his fix works for both 3852 and 5083.

Trevor

From: Jim Schaad [mailto:[email-masked]]
Sent: Monday, May 05, 2008 1:23 PM
To: Trevor Freeman; [email-masked]
Subject: RE: weak authentication issue with rfc5083

Trevor,

The same issue also occurs for AuthenticatedData in RFC 3852.  This has bee=
n known for a long time.

I am not sure how a demonstration of the KEK would solve this issue however=
.  The only way that I know to actually deal with this problem is to place =
the computed MAC under encryption for each recipient.

Jim

From: [email-masked] [mailto:[email-masked]] =
On Behalf Of Trevor Freeman
Sent: Monday, May 05, 2008 12:52 PM
To: [email-masked]
Subject: weak authentication issue with rfc5083

We have identified a potential for spoofing when using rfc5083.

Rfc5083 computes a message HMAC over the content using the authenticated en=
cryption algorithms. The message HMAC is calculated based on the content an=
d the content encryption key (CEK).

A number of allowed key management techniques derive a key encryption key (=
KEK) which can be used to authenticate the sender e.g. Static-Static Diffie=
 Hellman, Kerberos shared secret, shared password. The KEK is used to encry=
pt the CEK per recipient.

However when the integrity of the message is validated via the message HMAC=
, the sender only demonstrates knowledge of the CEK to the recipient.

Any other recipient knows the CEK so can construct another message using th=
e same CEK and compute the new HMAC and reuse the encrypted KEK data from t=
he original message. For example:

Alice sends a message to Bob and Mallet. Alice uses  different KEK's  for b=
oth Bob and Mallet to encrypt the CEK. Bob decrypts the CEK using  his KEK.=
 The message decrypts and the HMAC checks out so Bob think the message is f=
rom Alice because only Bob and Alice know the KEK.

Mallet is the recipient of the original message so he can use his KEK to le=
arn the message CEK. Mallet then  constructs a new message and encrypts it =
using the same CEK as the original message. Mallet copies Bobs  KEK recipie=
nt Info from Alice's message which contains the same encrypted CEK. Because=
 Mallet knows the CEK he can also compute the correct HMAC for the new mess=
age. Mallet sends the new message to Bob. Bob again uses his KEK to discove=
r the CEK and successfully decrypts the message and the HMAC check out so B=
ob thinks this new message is also from Alice.

This issue only applies when there are multiple recipients. The motivation =
to use the new authenticated encryption is to improve performance so soluti=
ons like bifurcating messages to use different CEK or signing the message a=
re counterproductive.

We need an additional structure to allow the sender to demonstrate knowledg=
e of both the KEK and CEK per recipient when sending to multiple recipients=
.
What is the consensus to resolve this?

We can version 5083 to document the new structure or we can do document the=
 new structure via a standalone document.

--_000_F767238E699C2E43895DDFB5F435088F0C2C102509DFMBX61exchan_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:x=3D"urn:schemas-microsoft-com:office:excel" xmlns:p=3D"urn:schemas-m=
icrosoft-com:office:powerpoint" xmlns:a=3D"urn:schemas-microsoft-com:office=
:access" xmlns:dt=3D"uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:s=3D"=
uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" xmlns:rs=3D"urn:schemas-microsof=
t-com:rowset" xmlns:z=3D"#RowsetSchema" xmlns:b=3D"urn:schemas-microsoft-co=
m:office:publisher" xmlns:ss=3D"urn:schemas-microsoft-com:office:spreadshee=
t" xmlns:c=3D"urn:schemas-microsoft-com:office:component:spreadsheet" xmlns=
:oa=3D"urn:schemas-microsoft-com:office:activation" xmlns:html=3D"http://ww=
w.w3.org/TR/REC-html40" xmlns:q=3D"http://schemas.xmlsoap.org/soap/envelope=
/" xmlns:D=3D"DAV:" xmlns:x2=3D"http://schemas.microsoft.com/office/excel/2=
003/xml" xmlns:ois=3D"http://schemas.microsoft.com/sharepoint/soap/ois/" xm=
lns:dir=3D"http://schemas.microsoft.com/sharepoint/soap/directory/" xmlns:d=
s=3D"http://www.w3.org/2000/09/xmldsig#" xmlns:dsp=3D"http://schemas.micros=
oft.com/sharepoint/dsp" xmlns:udc=3D"http://schemas.microsoft.com/data/udc"=
 xmlns:xsd=3D"http://www.w3.org/2001/XMLSchema" xmlns:sub=3D"http://schemas=
.microsoft.com/sharepoint/soap/2002/1/alerts/" xmlns:ec=3D"http://www.w3.or=
g/2001/04/xmlenc#" xmlns:sp=3D"http://schemas.microsoft.com/sharepoint/" xm=
lns:sps=3D"http://schemas.microsoft.com/sharepoint/soap/" xmlns:xsi=3D"http=
://www.w3.org/2001/XMLSchema-instance" xmlns:udcxf=3D"http://schemas.micros=
oft.com/data/udc/xmlfile" xmlns:wf=3D"http://schemas.microsoft.com/sharepoi=
nt/soap/workflow/" xmlns:mver=3D"http://schemas.openxmlformats.org/markup-c=
ompatibility/2006" xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/o=
mml" xmlns:mrels=3D"http://schemas.openxmlformats.org/package/2006/relation=
ships" xmlns:ex12t=3D"http://schemas.microsoft.com/exchange/services/2006/t=
ypes" xmlns:ex12m=3D"http://schemas.microsoft.com/exchange/services/2006/me=
ssages" xmlns:Z=3D"urn:schemas-microsoft-com:" xmlns=3D"http://www.w3.org/T=
R/REC-html40">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 12 (filtered medium)">
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:Consolas;
	panose-1:2 11 6 9 2 2 4 3 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
	{mso-style-priority:99;
	mso-style-link:"Plain Text Char";
	margin:0in;
	margin-bottom:.0001pt;
	font-size:10.5pt;
	font-family:Consolas;}
span.PlainTextChar
	{mso-style-name:"Plain Text Char";
	mso-style-priority:99;
	mso-style-link:"Plain Text";
	font-family:Consolas;}
span.EmailStyle19
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
span.EmailStyle20
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
span.EmailStyle21
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
span.EmailStyle22
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
span.EmailStyle23
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
span.EmailStyle24
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
span.EmailStyle25
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
span.EmailStyle26
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><span style=3D'color:#1F497D'>The same is true of the =
MAC because
that is sent as unauthenticated data. The recipients computes the MAC then
compares it to the unprotected value sent with the message. The computed va=
lue
and the transmitted value have to match otherwise it&#8217;s an authenticat=
ion failure.
&nbsp;If you strip or alter the MAC the recipient detects problem. <o:p></o=
:p></span></p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'>This proposal has exactl=
y the same
characteristics. <o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span>=
</p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'>Trevor<o:p></o:p></span>=
</p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span>=
</p>

<div>

<div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in =
0in 0in'>

<p class=3DMsoNormal><b><span style=3D'font-size:10.0pt;font-family:"Tahoma=
","sans-serif"'>From:</span></b><span
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'> Jim Schaad
[mailto:[email-masked]] <br>
<b>Sent:</b> Tuesday, May 06, 2008 12:31 PM<br>
<b>To:</b> Trevor Freeman; [email-masked]<br>
<b>Subject:</b> RE: weak authentication issue with rfc5083<o:p></o:p></span=
></p>

</div>

</div>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'>I would have an issue wi=
th this
since could be silently stripped without the recipients or senders knowledg=
e.
&nbsp;Thus I don&#8217;t see it as solving your problem.<o:p></o:p></span><=
/p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span>=
</p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'>Jim<o:p></o:p></span></p=

<p class=3DMsoNormal><span style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span>=
</p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span>=
</p>

<div style=3D'border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in =
4.0pt'>

<div>

<div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in =
0in 0in'>

<p class=3DMsoNormal><b><span style=3D'font-size:10.0pt;font-family:"Tahoma=
","sans-serif"'>From:</span></b><span
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>
[email-masked] [mailto:[email-masked]] <b>On
Behalf Of </b>Trevor Freeman<br>
<b>Sent:</b> Monday, May 05, 2008 3:42 PM<br>
<b>To:</b> Jim Schaad; [email-masked]<br>
<b>Subject:</b> RE: weak authentication issue with rfc5083<o:p></o:p></span=
></p>

</div>

</div>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'>Not if you send the reci=
pient
info&#8217;s with the encrypted hmac as an unauthenticated attribute.<o:p><=
/o:p></span></p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span>=
</p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'>Trevor<o:p></o:p></span>=
</p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span>=
</p>

<div>

<div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in =
0in 0in'>

<p class=3DMsoNormal><b><span style=3D'font-size:10.0pt;font-family:"Tahoma=
","sans-serif"'>From:</span></b><span
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'> Jim Schaad
[mailto:[email-masked]] <br>
<b>Sent:</b> Monday, May 05, 2008 3:38 PM<br>
<b>To:</b> Trevor Freeman; [email-masked]<br>
<b>Subject:</b> RE: weak authentication issue with rfc5083<o:p></o:p></span=
></p>

</div>

</div>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'>The downside of this wou=
ld be
that you could no longer do one pass encoding.&nbsp; You would need to comp=
ute
the HMAC prior to computing the recipient infos.<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span>=
</p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'>Jim<o:p></o:p></span></p=

<p class=3DMsoNormal><span style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span>=
</p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span>=
</p>

<div style=3D'border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in =
4.0pt'>

<div>

<div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in =
0in 0in'>

<p class=3DMsoNormal><b><span style=3D'font-size:10.0pt;font-family:"Tahoma=
","sans-serif"'>From:</span></b><span
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'> Trevor Freema=
n
[mailto:[email-masked]] <br>
<b>Sent:</b> Monday, May 05, 2008 2:03 PM<br>
<b>To:</b> Trevor Freeman; Jim Schaad; [email-masked]<br>
<b>Subject:</b> RE: weak authentication issue with rfc5083<o:p></o:p></span=
></p>

</div>

</div>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'>Another suggestion is to=
 use the
kek to wrap the hmac just like you wrapped the CEK.<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span>=
</p>

<div>

<div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in =
0in 0in'>

<p class=3DMsoNormal><b><span style=3D'font-size:10.0pt;font-family:"Tahoma=
","sans-serif"'>From:</span></b><span
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>
[email-masked] [mailto:[email-masked]] <b>On
Behalf Of </b>Trevor Freeman<br>
<b>Sent:</b> Monday, May 05, 2008 1:40 PM<br>
<b>To:</b> Jim Schaad; [email-masked]<br>
<b>Subject:</b> RE: weak authentication issue with rfc5083<o:p></o:p></span=
></p>

</div>

</div>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'>Hi Jim,<o:p></o:p></span=
></p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'>You can demonstrate know=
ledge of
both HMAC and KEK fairly simply per recipient e.g. by concatenating the KEK
with the message HMAC and hashing the result. Since Mallet does not know th=
e
KEK they cannot compute the new hash. This fix works for both 3852 and 5083=
.<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span>=
</p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'>Trevor<o:p></o:p></span>=
</p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span>=
</p>

<div>

<div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in =
0in 0in'>

<p class=3DMsoNormal><b><span style=3D'font-size:10.0pt;font-family:"Tahoma=
","sans-serif"'>From:</span></b><span
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'> Jim Schaad
[mailto:[email-masked]] <br>
<b>Sent:</b> Monday, May 05, 2008 1:23 PM<br>
<b>To:</b> Trevor Freeman; [email-masked]<br>
<b>Subject:</b> RE: weak authentication issue with rfc5083<o:p></o:p></span=
></p>

</div>

</div>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'>Trevor,<o:p></o:p></span=
></p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span>=
</p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'>The same issue also occu=
rs for
AuthenticatedData in RFC 3852.&nbsp; This has been known for a long time.<o=
:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span>=
</p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'>I am not sure how a
demonstration of the KEK would solve this issue however.&nbsp; The only way
that I know to actually deal with this problem is to place the computed MAC
under encryption for each recipient.<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span>=
</p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'>Jim<o:p></o:p></span></p=

<p class=3DMsoNormal><span style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span>=
</p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span>=
</p>

<div style=3D'border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in =
4.0pt'>

<div>

<div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in =
0in 0in'>

<p class=3DMsoNormal><b><span style=3D'font-size:10.0pt;font-family:"Tahoma=
","sans-serif"'>From:</span></b><span
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>
[email-masked] [mailto:[email-masked]] <b>On
Behalf Of </b>Trevor Freeman<br>
<b>Sent:</b> Monday, May 05, 2008 12:52 PM<br>
<b>To:</b> [email-masked]<br>
<b>Subject:</b> weak authentication issue with rfc5083<o:p></o:p></span></p=

</div>

</div>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>We have identified a potential for spoofing when using
rfc5083.<o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>Rfc5083 computes a message HMAC over the content using=
 the
authenticated encryption algorithms. The message HMAC is calculated based o=
n
the content and the content encryption key (CEK). <o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>A number of allowed key management techniques derive a=
 key
encryption key (KEK) which can be used to authenticate the sender e.g.
Static-Static Diffie Hellman, Kerberos shared secret, shared password. The =
KEK
is used to encrypt the CEK per recipient.<o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>However when the integrity of the message is validated=
 via
the message HMAC, the sender only demonstrates knowledge of the CEK to the
recipient.<o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>Any other recipient knows the CEK so can construct ano=
ther
message using the same CEK and compute the new HMAC and reuse the encrypted=
 KEK
data from the original message. For example:<o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoPlainText><span style=3D'font-size:11.0pt;font-family:"Calibr=
i","sans-serif"'>Alice
sends a message to Bob and Mallet. Alice uses &nbsp;different KEK&#8217;s
&nbsp;for both Bob and Mallet to encrypt the CEK. Bob decrypts the CEK
using&nbsp; his KEK. The message decrypts and the HMAC checks out so Bob th=
ink
the message is from Alice because only Bob and Alice know the KEK.<o:p></o:=
p></span></p>

<p class=3DMsoPlainText><span style=3D'font-size:11.0pt;font-family:"Calibr=
i","sans-serif"'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoPlainText><span style=3D'font-size:11.0pt;font-family:"Calibr=
i","sans-serif"'>Mallet
is the recipient of the original message so he can use his KEK to learn the
message CEK. Mallet then &nbsp;constructs a new message and encrypts it usi=
ng
the same CEK as the original message. Mallet copies Bobs &nbsp;KEK recipien=
t
Info from Alice's message which contains the same encrypted CEK. Because Ma=
llet
knows the CEK he can also compute the correct HMAC for the new message. Mal=
let
sends the new message to Bob. Bob again uses his KEK to discover the CEK an=
d
successfully decrypts the message and the HMAC check out so Bob thinks this=
 new
message is also from Alice.<o:p></o:p></span></p>

<p class=3DMsoPlainText><span style=3D'font-size:11.0pt;font-family:"Calibr=
i","sans-serif"'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoPlainText><span style=3D'font-size:11.0pt;font-family:"Calibr=
i","sans-serif"'>This
issue only applies when there are multiple recipients. The motivation to us=
e
the new authenticated encryption is to improve performance so solutions lik=
e
bifurcating messages to use different CEK or signing the message are
counterproductive.<o:p></o:p></span></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>We need an additional structure to allow the sender to
demonstrate knowledge of both the KEK and CEK per recipient when sending to
multiple recipients.<o:p></o:p></p>

<p class=3DMsoNormal>What is the consensus to resolve this? <o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>We can version 5083 to document the new structure or w=
e can
do document the new structure via a standalone document.<o:p></o:p></p>

</div>

</div>

</div>

</div>

</body>

</html>

--_000_F767238E699C2E43895DDFB5F435088F0C2C102509DFMBX61exchan_--

Date: Tue, 6 May 2008 13:54:37 -0700
To: [email-masked]
From: Paul Hoffman <[email-masked]>
Subject: Patent disclosure of interest
Sender: [email-masked]

<https://datatracker.ietf.org/ipr/950/>

From: "Jim Schaad" <[email-masked]>
To: "'Trevor Freeman'" <[email-masked]>, <[email-masked]>
Subject: RE: weak authentication issue with rfc5083
Date: Tue, 6 May 2008 12:30:47 -0700
Sender: [email-masked]

This is a multipart message in MIME format.

------=_NextPart_000_14C7_01C8AF75.0332BB70
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

I would have an issue with this since could be silently stripped without the
recipients or senders knowledge.  Thus I don't see it as solving your
problem.

Jim

From: [email-masked] [mailto:[email-masked]]
On Behalf Of Trevor Freeman
Sent: Monday, May 05, 2008 3:42 PM
To: Jim Schaad; [email-masked]
Subject: RE: weak authentication issue with rfc5083

Not if you send the recipient info's with the encrypted hmac as an
unauthenticated attribute.

Trevor

From: Jim Schaad [mailto:[email-masked]] 
Sent: Monday, May 05, 2008 3:38 PM
To: Trevor Freeman; [email-masked]
Subject: RE: weak authentication issue with rfc5083

The downside of this would be that you could no longer do one pass encoding.
You would need to compute the HMAC prior to computing the recipient infos.

Jim

From: Trevor Freeman [mailto:[email-masked]] 
Sent: Monday, May 05, 2008 2:03 PM
To: Trevor Freeman; Jim Schaad; [email-masked]
Subject: RE: weak authentication issue with rfc5083

Another suggestion is to use the kek to wrap the hmac just like you wrapped
the CEK.

From: [email-masked] [mailto:[email-masked]]
On Behalf Of Trevor Freeman
Sent: Monday, May 05, 2008 1:40 PM
To: Jim Schaad; [email-masked]
Subject: RE: weak authentication issue with rfc5083

Hi Jim,

You can demonstrate knowledge of both HMAC and KEK fairly simply per
recipient e.g. by concatenating the KEK with the message HMAC and hashing
the result. Since Mallet does not know the KEK they cannot compute the new
hash. This fix works for both 3852 and 5083.

Trevor

From: Jim Schaad [mailto:[email-masked]] 
Sent: Monday, May 05, 2008 1:23 PM
To: Trevor Freeman; [email-masked]
Subject: RE: weak authentication issue with rfc5083

Trevor,

The same issue also occurs for AuthenticatedData in RFC 3852.  This has been
known for a long time.

I am not sure how a demonstration of the KEK would solve this issue however.
The only way that I know to actually deal with this problem is to place the
computed MAC under encryption for each recipient.

Jim

From: [email-masked] [mailto:[email-masked]]
On Behalf Of Trevor Freeman
Sent: Monday, May 05, 2008 12:52 PM
To: [email-masked]
Subject: weak authentication issue with rfc5083

We have identified a potential for spoofing when using rfc5083.

Rfc5083 computes a message HMAC over the content using the authenticated
encryption algorithms. The message HMAC is calculated based on the content
and the content encryption key (CEK). 

A number of allowed key management techniques derive a key encryption key
(KEK) which can be used to authenticate the sender e.g. Static-Static Diffie
Hellman, Kerberos shared secret, shared password. The KEK is used to encrypt
the CEK per recipient.

However when the integrity of the message is validated via the message HMAC,
the sender only demonstrates knowledge of the CEK to the recipient.

Any other recipient knows the CEK so can construct another message using the
same CEK and compute the new HMAC and reuse the encrypted KEK data from the
original message. For example:

Alice sends a message to Bob and Mallet. Alice uses  different KEK's  for
both Bob and Mallet to encrypt the CEK. Bob decrypts the CEK using  his KEK.
The message decrypts and the HMAC checks out so Bob think the message is
from Alice because only Bob and Alice know the KEK.

Mallet is the recipient of the original message so he can use his KEK to
learn the message CEK. Mallet then  constructs a new message and encrypts it
using the same CEK as the original message. Mallet copies Bobs  KEK
recipient Info from Alice's message which contains the same encrypted CEK.
Because Mallet knows the CEK he can also compute the correct HMAC for the
new message. Mallet sends the new message to Bob. Bob again uses his KEK to
discover the CEK and successfully decrypts the message and the HMAC check
out so Bob thinks this new message is also from Alice.

This issue only applies when there are multiple recipients. The motivation
to use the new authenticated encryption is to improve performance so
solutions like bifurcating messages to use different CEK or signing the
message are counterproductive.

We need an additional structure to allow the sender to demonstrate knowledge
of both the KEK and CEK per recipient when sending to multiple recipients.

What is the consensus to resolve this? 

We can version 5083 to document the new structure or we can do document the
new structure via a standalone document.

------=_NextPart_000_14C7_01C8AF75.0332BB70
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:x=3D"urn:schemas-microsoft-com:office:excel" =
xmlns:p=3D"urn:schemas-microsoft-com:office:powerpoint" =
xmlns:a=3D"urn:schemas-microsoft-com:office:access" =
xmlns:dt=3D"uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" =
xmlns:s=3D"uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" =
xmlns:rs=3D"urn:schemas-microsoft-com:rowset" xmlns:z=3D"#RowsetSchema" =
xmlns:b=3D"urn:schemas-microsoft-com:office:publisher" =
xmlns:ss=3D"urn:schemas-microsoft-com:office:spreadsheet" =
xmlns:c=3D"urn:schemas-microsoft-com:office:component:spreadsheet" =
xmlns:oa=3D"urn:schemas-microsoft-com:office:activation" =
xmlns:html=3D"http://www.w3.org/TR/REC-html40" =
xmlns:q=3D"http://schemas.xmlsoap.org/soap/envelope/" xmlns:D=3D"DAV:" =
xmlns:x2=3D"http://schemas.microsoft.com/office/excel/2003/xml" =
xmlns:ois=3D"http://schemas.microsoft.com/sharepoint/soap/ois/" =
xmlns:dir=3D"http://schemas.microsoft.com/sharepoint/soap/directory/" =
xmlns:ds=3D"http://www.w3.org/2000/09/xmldsig#" =
xmlns:dsp=3D"http://schemas.microsoft.com/sharepoint/dsp" =
xmlns:udc=3D"http://schemas.microsoft.com/data/udc" =
xmlns:xsd=3D"http://www.w3.org/2001/XMLSchema" =
xmlns:sub=3D"http://schemas.microsoft.com/sharepoint/soap/2002/1/alerts/"=
 xmlns:ec=3D"http://www.w3.org/2001/04/xmlenc#" =
xmlns:sp=3D"http://schemas.microsoft.com/sharepoint/" =
xmlns:sps=3D"http://schemas.microsoft.com/sharepoint/soap/" =
xmlns:xsi=3D"http://www.w3.org/2001/XMLSchema-instance" =
xmlns:udcxf=3D"http://schemas.microsoft.com/data/udc/xmlfile" =
xmlns:wf=3D"http://schemas.microsoft.com/sharepoint/soap/workflow/" =
xmlns:mver=3D"http://schemas.openxmlformats.org/markup-compatibility/2006=
" xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" =
xmlns:mrels=3D"http://schemas.openxmlformats.org/package/2006/relationshi=
ps" =
xmlns:ex12t=3D"http://schemas.microsoft.com/exchange/services/2006/types"=
 =
xmlns:ex12m=3D"http://schemas.microsoft.com/exchange/services/2006/messag=
es" xmlns:Z=3D"urn:schemas-microsoft-com:" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 12 (filtered medium)">
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:Consolas;
	panose-1:2 11 6 9 2 2 4 3 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
	{mso-style-priority:99;
	mso-style-link:"Plain Text Char";
	margin:0in;
	margin-bottom:.0001pt;
	font-size:10.5pt;
	font-family:Consolas;}
span.PlainTextChar
	{mso-style-name:"Plain Text Char";
	mso-style-priority:99;
	mso-style-link:"Plain Text";
	font-family:Consolas;}
span.EmailStyle19
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
span.EmailStyle20
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
span.EmailStyle21
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
span.EmailStyle22
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
span.EmailStyle23
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
span.EmailStyle24
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
span.EmailStyle25
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><span style=3D'color:#1F497D'>I would have an issue =
with this
since could be silently stripped without the recipients or senders =
knowledge. &nbsp;Thus
I don&#8217;t see it as solving your problem.<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'color:#1F497D'>Jim<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<div style=3D'border:none;border-left:solid blue 1.5pt;padding:0in 0in =
0in 4.0pt'>

<div>

<div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt =
0in 0in 0in'>

<p class=3DMsoNormal><b><span =
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span>=
</b><span
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>
[email-masked] [mailto:[email-masked]] =
<b>On
Behalf Of </b>Trevor Freeman<br>
<b>Sent:</b> Monday, May 05, 2008 3:42 PM<br>
<b>To:</b> Jim Schaad; [email-masked]<br>
<b>Subject:</b> RE: weak authentication issue with =
rfc5083<o:p></o:p></span></p>

</div>

</div>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'>Not if you send the =
recipient
info&#8217;s with the encrypted hmac as an unauthenticated =
attribute.<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'color:#1F497D'>Trevor<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<div>

<div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt =
0in 0in 0in'>

<p class=3DMsoNormal><b><span =
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span>=
</b><span
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'> Jim Schaad
[mailto:[email-masked]] <br>
<b>Sent:</b> Monday, May 05, 2008 3:38 PM<br>
<b>To:</b> Trevor Freeman; [email-masked]<br>
<b>Subject:</b> RE: weak authentication issue with =
rfc5083<o:p></o:p></span></p>

</div>

</div>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'>The downside of this =
would be
that you could no longer do one pass encoding.&nbsp; You would need to =
compute
the HMAC prior to computing the recipient infos.<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'color:#1F497D'>Jim<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<div style=3D'border:none;border-left:solid blue 1.5pt;padding:0in 0in =
0in 4.0pt'>

<div>

<div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt =
0in 0in 0in'>

<p class=3DMsoNormal><b><span =
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span>=
</b><span
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'> Trevor =
Freeman
[mailto:[email-masked]] <br>
<b>Sent:</b> Monday, May 05, 2008 2:03 PM<br>
<b>To:</b> Trevor Freeman; Jim Schaad; [email-masked]<br>
<b>Subject:</b> RE: weak authentication issue with =
rfc5083<o:p></o:p></span></p>

</div>

</div>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'>Another suggestion is =
to use the
kek to wrap the hmac just like you wrapped the =
CEK.<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<div>

<div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt =
0in 0in 0in'>

<p class=3DMsoNormal><b><span =
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span>=
</b><span
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>
[email-masked] [mailto:[email-masked]] =
<b>On
Behalf Of </b>Trevor Freeman<br>
<b>Sent:</b> Monday, May 05, 2008 1:40 PM<br>
<b>To:</b> Jim Schaad; [email-masked]<br>
<b>Subject:</b> RE: weak authentication issue with =
rfc5083<o:p></o:p></span></p>

</div>

</div>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'>Hi =
Jim,<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'>You can demonstrate =
knowledge of
both HMAC and KEK fairly simply per recipient e.g. by concatenating the =
KEK
with the message HMAC and hashing the result. Since Mallet does not know =
the
KEK they cannot compute the new hash. This fix works for both 3852 and =
5083.<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'color:#1F497D'>Trevor<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<div>

<div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt =
0in 0in 0in'>

<p class=3DMsoNormal><b><span =
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span>=
</b><span
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'> Jim Schaad
[mailto:[email-masked]] <br>
<b>Sent:</b> Monday, May 05, 2008 1:23 PM<br>
<b>To:</b> Trevor Freeman; [email-masked]<br>
<b>Subject:</b> RE: weak authentication issue with =
rfc5083<o:p></o:p></span></p>

</div>

</div>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal><span =
style=3D'color:#1F497D'>Trevor,<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'>The same issue also =
occurs for
AuthenticatedData in RFC 3852.&nbsp; This has been known for a long =
time.<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'>I am not sure how a =
demonstration
of the KEK would solve this issue however.&nbsp; The only way that I =
know to
actually deal with this problem is to place the computed MAC under =
encryption
for each recipient.<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'color:#1F497D'>Jim<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<div style=3D'border:none;border-left:solid blue 1.5pt;padding:0in 0in =
0in 4.0pt'>

<div>

<div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt =
0in 0in 0in'>

<p class=3DMsoNormal><b><span =
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span>=
</b><span
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>
[email-masked] [mailto:[email-masked]] =
<b>On
Behalf Of </b>Trevor Freeman<br>
<b>Sent:</b> Monday, May 05, 2008 12:52 PM<br>
<b>To:</b> [email-masked]<br>
<b>Subject:</b> weak authentication issue with =
rfc5083<o:p></o:p></span></p>

</div>

</div>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>We have identified a potential for spoofing when =
using
rfc5083.<o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>Rfc5083 computes a message HMAC over the content =
using the
authenticated encryption algorithms. The message HMAC is calculated =
based on
the content and the content encryption key (CEK). <o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>A number of allowed key management techniques =
derive a key
encryption key (KEK) which can be used to authenticate the sender e.g.
Static-Static Diffie Hellman, Kerberos shared secret, shared password. =
The KEK
is used to encrypt the CEK per recipient.<o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>However when the integrity of the message is =
validated via
the message HMAC, the sender only demonstrates knowledge of the CEK to =
the
recipient.<o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>Any other recipient knows the CEK so can construct =
another
message using the same CEK and compute the new HMAC and reuse the =
encrypted KEK
data from the original message. For example:<o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoPlainText><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'>Alice
sends a message to Bob and Mallet. Alice uses &nbsp;different =
KEK&#8217;s &nbsp;for
both Bob and Mallet to encrypt the CEK. Bob decrypts the CEK using&nbsp; =
his
KEK. The message decrypts and the HMAC checks out so Bob think the =
message is
from Alice because only Bob and Alice know the =
KEK.<o:p></o:p></span></p>

<p class=3DMsoPlainText><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'><o:p>&nbsp;=
</o:p></span></p>

<p class=3DMsoPlainText><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'>Mallet
is the recipient of the original message so he can use his KEK to learn =
the
message CEK. Mallet then &nbsp;constructs a new message and encrypts it =
using
the same CEK as the original message. Mallet copies Bobs &nbsp;KEK =
recipient
Info from Alice's message which contains the same encrypted CEK. Because =
Mallet
knows the CEK he can also compute the correct HMAC for the new message. =
Mallet
sends the new message to Bob. Bob again uses his KEK to discover the CEK =
and
successfully decrypts the message and the HMAC check out so Bob thinks =
this new
message is also from Alice.<o:p></o:p></span></p>

<p class=3DMsoPlainText><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'><o:p>&nbsp;=
</o:p></span></p>

<p class=3DMsoPlainText><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'>This
issue only applies when there are multiple recipients. The motivation to =
use
the new authenticated encryption is to improve performance so solutions =
like bifurcating
messages to use different CEK or signing the message are =
counterproductive.<o:p></o:p></span></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>We need an additional structure to allow the sender =
to
demonstrate knowledge of both the KEK and CEK per recipient when sending =
to
multiple recipients.<o:p></o:p></p>

<p class=3DMsoNormal>What is the consensus to resolve this? =
<o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>We can version 5083 to document the new structure =
or we can
do document the new structure via a standalone document.<o:p></o:p></p>

</div>

</div>

</div>

</div>

</body>

</html>

------=_NextPart_000_14C7_01C8AF75.0332BB70--

From: "Jim Schaad" <[email-masked]>
To: "'Peter Gutmann'" <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: RE: weak authentication issue with rfc5083
Date: Tue, 6 May 2008 12:29:43 -0700
Sender: [email-masked]

Peter,

I believe you have misunderstood the issue that Trevor raised.

His problem is:

1.  I send you and him a single Authenticated Message.
2.  He takes the common CEK in the original message, uses it to create a MAC
on an new message and then sends it on to you.

As is always true with Authenticated messages, there is no proof of origin.
He worries that you might be confused and believe the second messages was
from me rather than from him.  Since they both use the same CEK that is not
a factor that could be used to distinguish them.

Jim

> -----Original Message-----
> From: [email-masked] [mailto:owner-ietf-
> [email-masked]] On Behalf Of Peter Gutmann
> Sent: Monday, May 05, 2008 11:47 PM
> To: [email-masked]; [email-masked]
> Subject: Re: weak authentication issue with rfc5083
> 
> 
> Trevor Freeman <[email-masked]> writes:
> 
> >However when the integrity of the message is validated via the message
> HMAC,
> >the sender only demonstrates knowledge of the CEK to the recipient.
> >
> >Any other recipient knows the CEK so can construct another message
> using the
> >same CEK and compute the new HMAC and reuse the encrypted KEK data
> from the
> >original message. For example:
> 
> Uhh, AuthEnv doesn't specify any use of HMAC, it can be used with HMAC
> if
> required (the other use is with a combined MAC+encrypt mode), but in
> the HMAC
> usage the HMAC and CEK keys are derived from a single key using a PRF,
> so
> knowledge of the CEK doesn't give you the HMAC key, and vice versa.  It
> was
> specifically designed that way to prevent rollbacks where you strip off
> the
> MAC and rewrite it as plain encrypted data.  Or have I misunderstood
> your
> point?
> 
> Peter.

From: Trevor Freeman <[email-masked]>
To: pgut001 <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Tue, 6 May 2008 19:25:05 +0000
Subject: RE: weak authentication issue with rfc5083
Accept-Language: en-US
Sender: [email-masked]

I should have use MAC to be more accurate.

5083 generates a MAC using the message contents and the CEK.

If there are multiple recipients - all know the CEK so any can generate new=
 messages with the same CEK. So you only can presume the message is from on=
e of the group who know the CEK but you don't know which one.

You could have used a pair wise shared secret to protect the CEK but 5083 d=
oes not define how to use the pair wise shared secret to also authenticate =
the sender. If the sender encrypted the MAC using the KEK and attached that=
 to the message as an unauthenticated attribute the receiver can authentica=
te the sender.

-----Original Message-----
From: pgut001 [mailto:[email-masked]]
Sent: Monday, May 05, 2008 11:47 PM
To: [email-masked]; Trevor Freeman
Subject: Re: weak authentication issue with rfc5083

Trevor Freeman <[email-masked]> writes:

>However when the integrity of the message is validated via the message HMA=
C,
>the sender only demonstrates knowledge of the CEK to the recipient.
>
>Any other recipient knows the CEK so can construct another message using t=
he
>same CEK and compute the new HMAC and reuse the encrypted KEK data from th=
e
>original message. For example:

Uhh, AuthEnv doesn't specify any use of HMAC, it can be used with HMAC if
required (the other use is with a combined MAC+encrypt mode), but in the HM=
AC
usage the HMAC and CEK keys are derived from a single key using a PRF, so
knowledge of the CEK doesn't give you the HMAC key, and vice versa.  It was
specifically designed that way to prevent rollbacks where you strip off the
MAC and rewrite it as plain encrypted data.  Or have I misunderstood your
point?

Peter.

From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: I-D ACTION:draft-ietf-smime-rfc3278-update-04.txt 
Date: Tue,  6 May 2008 10:45: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		: Update to Use of Elliptic Curve Cryptography (ECC) Algorithms in Cryptographic Message Syntax (CMS)
	Author(s)	: S. Turner
	Filename	: draft-ietf-smime-rfc3278-update-04.txt
	Pages		: 28
	Date		: 2008-5-6
	
RFC 3278 describes how to use Elliptic Curve Cryptography (ECC) 
   public-key algorithms in the Cryptographic Message Syntax (CMS).  
   This document updates RFC 3278 to add support for the SHA2 family of 
   hash algorithms, Elliptic Curve Digital Signature Algorithm (ECDSA) 
   224-512, and Key Derivation Functions (KDFs) that utilize SHA2 
   algorithms.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-smime-rfc3278-update-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.

--NextPart
Content-Type: Message/External-body;
	name="draft-ietf-smime-rfc3278-update-04.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: "'Tony Capel'" <[email-masked]>, "'Paul Hoffman'" <[email-masked]>, <[email-masked]>
Subject: RE: S/MIME v3.2  IDs key size text
Date: Tue, 6 May 2008 12:37:19 -0400
Organization: IECA, Inc.
Sender: [email-masked]

Tony,

Inline...

spt

>-----Original Message-----
>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of Tony Capel
>Sent: Monday, May 05, 2008 5:34 PM
>To: 'Turner, Sean P.'; 'Paul Hoffman'; [email-masked]
>Subject: RE: S/MIME v3.2 IDs key size text
>
>
>Sean:
>
>Agreed, the text in 3850bis and 3851bis needs to align.  I 
>have no problems with support for smaller key sizes.

You got it.  I was just trying to say we need to keep the two algined.

>I expect constraints on key size to be implemented by the 
>certificate issuer anyway.  If you get a 512 key in a cert you 
>trust you must be able to use it, no?  

Originally, I thought the answer really was no, but I think for interop with
v3 and v3.1 we need to say yes. If you get a 512 key in a cert from a source
you trust, then you can decide to not use it but it's not because you don't
trust the source it's because of some other reason. I can see where maybe
short lived certs are used because the info gets stale quickly, they need to
sign/verify really quickly, etc. I am a little concerned about the FIP-140
issue though.

Just a thought ... since we've now got a way to indicate + and - with
requirements should we apply it the key sizes in 3850bis?  That way people
will have a hint that in the next update the shorter keys will likely become
not so welcome and large keys more so? 

   0 < key size < 511  : MUST NOT
 512 < key size < 1023 : SHOULD-
1024 < key size < 2048 : MUST
2049 < key size < 4096 : MAY

>Tony
>
>| -----Original Message-----
>| From: [email-masked]
>| [mailto:[email-masked]] On Behalf Of Turner, Sean P.
>| Sent: May 5, 2008 4:58 PM
>| To: 'Tony Capel'; 'Paul Hoffman'; [email-masked]
>| Subject: RE: S/MIME v3.2 IDs key size text
>| 
>| 
>| 
>| Tony,
>| 
>| There was a comment from Paul against the text you cite from 
>3850bis. 
>| He objected to moving the lower bounds from 512 to 1024. I 
>figured I'd 
>| post both -02 drafts once we knocked this issue out.
>| 
>| spt
>| 
>| >-----Original Message-----
>| >From: Tony Capel [mailto:[email-masked]]
>| >Sent: Monday, May 05, 2008 4:09 PM
>| >To: 'Paul Hoffman'; 'Turner, Sean P.'; [email-masked]
>| >Subject: RE: S/MIME v3.2 IDs key size text
>| >
>| >All:
>| >
>| >I agree that deleting " namely 1024 bits" from the first 
>sentence of 
>| >the proposed security considerations section paragraph is 
>good.  The 
>| >second "1024"
>| >in the proposed paragraph is not a problem for me since it is not 
>| >"normative".
>| >
>| >With respect to section 4.1 (Key Pair Generation).  Is it 
>intended to 
>| >change the title of this section?  The second paragraph of the 
>| >current text in 3851bis-01.txt begins "If an S/MIME agent needs to 
>| >generate ...".  So if the S/MIME agent does NOT need to 
>generate keys 
>| >(and this is typically the case, most enrollment & key 
>generation are 
>| >done externally to messaging clients) the balance of this paragraph 
>| >(which mentions the key sizes) is not normative (as 
>currently drafted
>| >- its quite possible that the last sentence of this 
>paragraph should 
>| >have been in a separate paragraph).  Key generation 
>requirements are 
>| >normally (hopefully!) cited in the corresponding CP, where things 
>| >such as required key sizes, where they are generated (locally or at 
>| >the CA), FIPS-140 Level, etc. should be (!!) explicitly 
>identified.  
>| >Maybe the second paragraph of
>| >4.1 could be replaced with a simple statement:
>| >
>| >"If an S/MIME agent needs to generate one or more key pairs, each 
>| >SHOULD be generated according to the corresponding certificate 
>| >policy, refer for example to [RFC3647]."
>| >
>| >The proposed text, and the discussion so far, is really speaking 
>| >about "what range of RSA key sizes" needs to be supported.  We are 
>| >NOT providing security advice, we are just trying to ensure 
>that most 
>| >smime v3.2 implementations will interwork in the typical 
>environments 
>| >expected "in the wild"
>| >(and special environments will be understood by purchasers 
>anyway, so 
>| >we likely need not worry about high security applications - 
>only the 
>| >general "public"
>| >environments). 
>| >
>| >A similar issue is already addressed in CERT v3.2 ( 
>| >draft-ietf-smime-3850bis-01.txt ) in Section 4.3 for certificate  
>| >validation.
>| >We might consider copying the last sentence of CERT v3.2 Sec
>| >4.3 to the end of sections 2.2 and 2.3 (just before the Notes):
>| >
>| >   "Key sizes from 1024 bits to 2048 bits MUST be supported."
>| >
>| >This would also have the advantage of aligning CERT and MSG.
>| >
>| >Tony
>| >
>| >
>| >| -----Original Message-----
>| >| From: [email-masked] 
>| >| [mailto:[email-masked]] On Behalf Of Paul Hoffman
>| >| Sent: May 3, 2008 10:08 PM
>| >| To: Turner, Sean P.; [email-masked]
>| >| Subject: RE: S/MIME v3.2 IDs key size text
>| >| 
>| >| 
>| >| 
>| >| At 8:51 PM -0400 5/3/08, Turner, Sean P. wrote:
>| >| >I think if we struck ", namely 1024 bits" from the text in
>| >| the security
>| >| >considerations that it's still a true statement and we
>| >won't have to
>| >| >change it every time we update the spec.
>| >| 
>| >| I'm OK with that, but I also feel that if we're updating
>| the minimum
>| >| mandatory signing length, it is trivial to update the Security 
>| >| Considerations as well.
>| >| 
>| >
>| 
>

From: "Turner, Sean P." <[email-masked]>
To: "'Jim Schaad'" <[email-masked]>, "'Ietf-Smime'" <[email-masked]>
Subject: RE: New ASN.1 modules comments/questions
Date: Tue, 6 May 2008 12:09:49 -0400
Organization: IECA, Inc.
Sender: [email-masked]

Jim,

No worries on the delay. Some thoughts on your responses.

spt 

>> The definitions of AlgorithmIdentifier in the PKIX and SMIME modules 
>> are different - is there a reason for the difference? Does 
>it matter? 
>> In PKIX it's AlgorithmSet, in SMIME it's InfoObjectSet, in RFC2976 
>> it's IOSet, in ANSI X9 docs it's also IOSet, and in X.509 it's 
>> SupportedAlgorithms. If it matters, then I guess I lean 
>towards what's 
>> in RFC2976 since it's already in an RFC.
>
>There is no effective difference between the two definitions.  
>The two differences are 1) the name of a parameter and 2) 
>comments.  The name of the parameter makes no difference.  
>Just as the name of a parameter makes no difference if you are 
>writing a C function.  The same is true for comments.

I figured as much, but if we can control it I think they should be called
the same thing. Don't really care what it's called just that they're called
the same thing.

>> -------------------
>> 
>> In the 3370 section,
>> 
>>  2. You used alg- as tag for hash algs, sig- for signature 
>algs, kea- 
>> for key agreement algs, alg- for symmetric key encryption algs.  I 
>> think it might be easier to figure out which algs go where 
>if the tag 
>> matches the type of algorithm like mda- for MessageDigestAlgorithms, 
>> sa- for SignatureAlgorithms, and kaa- for KeyAgreementAlgorithms.
>
>Thanks for suggesting some potential tags to be used.  I agree 
>that we need some short simple notation to mark the different 
>types of algorithm objects.

Since I'm using some of these tags in other IDs, I'll try to make sure we're
in synch.

>>  3. Could we change SymmetricKeyEncryptionAlgorithms to just 
>> KeyWrapAlgorithms and use kwa- as the tag? There's also a 
>> KeyWrapAlgorithm that I think is supposed to be the same as the 
>> SymmetricKeyEncryptionAlgorithms so one or the other can get deleted 
>> (if you delete the later change SupportKeyWrapAlgorithms to 
>> KeyWrapAlgorithms)?
>
>I have no problems with this change.  There is a minor 
>question here about doing a good job of distinguishing Key 
>Wrap Algorithms and Key Transport Algorithms.  
>
>I added the Symmetric to the front to distinguish from Key 
>Transport algorithms which, as the KEA algorithm suggest, can 
>also be thought of as
>Key Encryption algorithms.    The use of Key Wrap might be 
>sufficient to
>distinguish between them, but CMS uses Key Encryption as the 
>name of these types of algorithms.
>
>Which is a better way to go?

I think it's a toss up.  I guess I was just confused because it wasn't clear
to me whether the keyEncryptionAlgorithm in 3852 was constrainted by
SymmetricKeyEncryption or KeyWrapAlgorithm.  Now that I think about it the
KeyWrapAlgorithms in this module is used to define the algorithm. This makes
me think that adding comments above each IOset to say what it's constraining
would help the reader a lot.
 
>>  4. Shouldn't SymmetricKeyEncryptionAlgorithms be extensible?
>> 
>
>Welcome to a long philosophical discussion.
>
>There are two different places where this extensibility can be 
>placed.  The two different locations imply different things.  
>This means that depending on how you look at things this 
>should or should not be extensible.
>
>If you place the extensibility here, you are saying that we 
>think that this document is going to be updated, and that we 
>are going to add new algorithms to this document.  
>
>Alternatively, if you place the extensibility in CMS, you are 
>saying that we are going to define new algorithms by creating 
>new documents with new modules and they should be "imported" 
>into the CMS document in one manner or another. 
>
>The compiler that we are working on has a planned directive to 
>allow for an object to be added to an extensible object set.  
>Part of the question at this point would be as follows.  Where 
>should the new algorithm be added, in this document - thus 
>potentially effecting more than just CMS - or in CMS thus 
>limiting where the changes are set.
>
>My personal beliefs are:
>- 1.  New algorithms should be added by creating new documents 
>not by updating this document
>- 2.  Changes in algorithm sets should be as narrow as 
>possible - thus the updates should be done in CMS not here. 
>
>The upshot of this is that I believe this object set is NOT 
>extensible, but the corresponding one in CMS should be extensible.

I agree with you. We're already on this track because we've not updated 3370
every time a new alg comes along - what we've done is define a new ID with a
new module. Don't see any reason to change from that course.

>> -------------------
>> 
>> In the 3852 section,
>> 
>>  2. Are you going to remove the version notations [[3:, [[4:, etc?
>
>It is my belief that having the version tags included adds 
>information to the ASN.1 module.  Thus I plan on keeping them 
>unless I get some large objections.

Still thinking about whether I should object ;)

>>  3. For consistency with 3370, can we change DigestAlgorithmList to 
>> MessageDigestAlgorithms?
>
>I don't want these to have the same names.  In the long run we 
>will do the
>following:
>    DigestAlgorithmList ALGORITHM ::= {MessageDigestAlgorithms,...}
>
>
>However I am open to the following:
>-  We create a standardized but descriptive method of naming 
>the sets of algorithms defined in a module - thus in 3370 we might say
>	CMSAlgs-MessageDigestAlgorithm
>
>- Do the suggested re-name here.

Okay

>>  10. For consistency, can we change KeyEncryptionAlgorithmList to be 
>> KeyEncryptionAlgorithms?
>
>The above note about matching the name in 3370 needs to be 
>taken into account.  I used List (but could have used Set) but 
>I am not wedded to this.
>I worry about using an 's' at the end as this could be a 
>sequence of algorithms as well.  There exists a potential 
>confusion in the future.

Sometimes we've used an 's' sometimes we've used 'list' - I guess I'd like
them to be the same for no other reason than consistency.

>> -------------------
>> 
>> In the 4998 section,
>> 
>>  3. Why is Extensions and EXTENSION imported?
>
>To use a single standardized version, as with Attribute

I might have missed it but I don't think it's used in the module?

>> -------------------
>> 
>> In the 5035 section,
>> 
>>  1. Why is Extensions and EXTENSION imported?
>> 
>
>See above

I might have missed it but I don't think it's used in the module?

>>  6. Is the note about the identical SecurityCategories encoding
>> required
>> anymore?
>
>I have no opinion one way or the other on this.  Being 
>conservative says it
>stays.

Okay

From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: weak authentication issue with rfc5083
Date: Tue, 06 May 2008 18:47:00 +1200
Sender: [email-masked]

Trevor Freeman <[email-masked]> writes:

>However when the integrity of the message is validated via the message HMAC,
>the sender only demonstrates knowledge of the CEK to the recipient.
>
>Any other recipient knows the CEK so can construct another message using the
>same CEK and compute the new HMAC and reuse the encrypted KEK data from the
>original message. For example:

Uhh, AuthEnv doesn't specify any use of HMAC, it can be used with HMAC if
required (the other use is with a combined MAC+encrypt mode), but in the HMAC
usage the HMAC and CEK keys are derived from a single key using a PRF, so
knowledge of the CEK doesn't give you the HMAC key, and vice versa.  It was
specifically designed that way to prevent rollbacks where you strip off the
MAC and rewrite it as plain encrypted data.  Or have I misunderstood your
point?

Peter.

From: Trevor Freeman <[email-masked]>
To: Jim Schaad <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Mon, 5 May 2008 22:41:31 +0000
Subject: RE: weak authentication issue with rfc5083
Accept-Language: en-US
Sender: [email-masked]

--_000_F767238E699C2E43895DDFB5F435088F0C2C07BE77DFMBX61exchan_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Not if you send the recipient info's with the encrypted hmac as an unauthen=
ticated attribute.

Trevor

From: Jim Schaad [mailto:[email-masked]]
Sent: Monday, May 05, 2008 3:38 PM
To: Trevor Freeman; [email-masked]
Subject: RE: weak authentication issue with rfc5083

The downside of this would be that you could no longer do one pass encoding=
.  You would need to compute the HMAC prior to computing the recipient info=
s.

Jim

From: Trevor Freeman [mailto:[email-masked]]
Sent: Monday, May 05, 2008 2:03 PM
To: Trevor Freeman; Jim Schaad; [email-masked]
Subject: RE: weak authentication issue with rfc5083

Another suggestion is to use the kek to wrap the hmac just like you wrapped=
 the CEK.

From: [email-masked] [mailto:[email-masked]] =
On Behalf Of Trevor Freeman
Sent: Monday, May 05, 2008 1:40 PM
To: Jim Schaad; [email-masked]
Subject: RE: weak authentication issue with rfc5083

Hi Jim,
You can demonstrate knowledge of both HMAC and KEK fairly simply per recipi=
ent e.g. by concatenating the KEK with the message HMAC and hashing the res=
ult. Since Mallet does not know the KEK they cannot compute the new hash. T=
his fix works for both 3852 and 5083.

Trevor

From: Jim Schaad [mailto:[email-masked]]
Sent: Monday, May 05, 2008 1:23 PM
To: Trevor Freeman; [email-masked]
Subject: RE: weak authentication issue with rfc5083

Trevor,

The same issue also occurs for AuthenticatedData in RFC 3852.  This has bee=
n known for a long time.

I am not sure how a demonstration of the KEK would solve this issue however=
.  The only way that I know to actually deal with this problem is to place =
the computed MAC under encryption for each recipient.

Jim

From: [email-masked] [mailto:[email-masked]] =
On Behalf Of Trevor Freeman
Sent: Monday, May 05, 2008 12:52 PM
To: [email-masked]
Subject: weak authentication issue with rfc5083

We have identified a potential for spoofing when using rfc5083.

Rfc5083 computes a message HMAC over the content using the authenticated en=
cryption algorithms. The message HMAC is calculated based on the content an=
d the content encryption key (CEK).

A number of allowed key management techniques derive a key encryption key (=
KEK) which can be used to authenticate the sender e.g. Static-Static Diffie=
 Hellman, Kerberos shared secret, shared password. The KEK is used to encry=
pt the CEK per recipient.

However when the integrity of the message is validated via the message HMAC=
, the sender only demonstrates knowledge of the CEK to the recipient.

Any other recipient knows the CEK so can construct another message using th=
e same CEK and compute the new HMAC and reuse the encrypted KEK data from t=
he original message. For example:

Alice sends a message to Bob and Mallet. Alice uses  different KEK's  for b=
oth Bob and Mallet to encrypt the CEK. Bob decrypts the CEK using  his KEK.=
 The message decrypts and the HMAC checks out so Bob think the message is f=
rom Alice because only Bob and Alice know the KEK.

Mallet is the recipient of the original message so he can use his KEK to le=
arn the message CEK. Mallet then  constructs a new message and encrypts it =
using the same CEK as the original message. Mallet copies Bobs  KEK recipie=
nt Info from Alice's message which contains the same encrypted CEK. Because=
 Mallet knows the CEK he can also compute the correct HMAC for the new mess=
age. Mallet sends the new message to Bob. Bob again uses his KEK to discove=
r the CEK and successfully decrypts the message and the HMAC check out so B=
ob thinks this new message is also from Alice.

This issue only applies when there are multiple recipients. The motivation =
to use the new authenticated encryption is to improve performance so soluti=
ons like bifurcating messages to use different CEK or signing the message a=
re counterproductive.

We need an additional structure to allow the sender to demonstrate knowledg=
e of both the KEK and CEK per recipient when sending to multiple recipients=
.
What is the consensus to resolve this?

We can version 5083 to document the new structure or we can do document the=
 new structure via a standalone document.

--_000_F767238E699C2E43895DDFB5F435088F0C2C07BE77DFMBX61exchan_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:x=3D"urn:schemas-microsoft-com:office:excel" xmlns:p=3D"urn:schemas-m=
icrosoft-com:office:powerpoint" xmlns:a=3D"urn:schemas-microsoft-com:office=
:access" xmlns:dt=3D"uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:s=3D"=
uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" xmlns:rs=3D"urn:schemas-microsof=
t-com:rowset" xmlns:z=3D"#RowsetSchema" xmlns:b=3D"urn:schemas-microsoft-co=
m:office:publisher" xmlns:ss=3D"urn:schemas-microsoft-com:office:spreadshee=
t" xmlns:c=3D"urn:schemas-microsoft-com:office:component:spreadsheet" xmlns=
:oa=3D"urn:schemas-microsoft-com:office:activation" xmlns:html=3D"http://ww=
w.w3.org/TR/REC-html40" xmlns:q=3D"http://schemas.xmlsoap.org/soap/envelope=
/" xmlns:D=3D"DAV:" xmlns:x2=3D"http://schemas.microsoft.com/office/excel/2=
003/xml" xmlns:ois=3D"http://schemas.microsoft.com/sharepoint/soap/ois/" xm=
lns:dir=3D"http://schemas.microsoft.com/sharepoint/soap/directory/" xmlns:d=
s=3D"http://www.w3.org/2000/09/xmldsig#" xmlns:dsp=3D"http://schemas.micros=
oft.com/sharepoint/dsp" xmlns:udc=3D"http://schemas.microsoft.com/data/udc"=
 xmlns:xsd=3D"http://www.w3.org/2001/XMLSchema" xmlns:sub=3D"http://schemas=
.microsoft.com/sharepoint/soap/2002/1/alerts/" xmlns:ec=3D"http://www.w3.or=
g/2001/04/xmlenc#" xmlns:sp=3D"http://schemas.microsoft.com/sharepoint/" xm=
lns:sps=3D"http://schemas.microsoft.com/sharepoint/soap/" xmlns:xsi=3D"http=
://www.w3.org/2001/XMLSchema-instance" xmlns:udcxf=3D"http://schemas.micros=
oft.com/data/udc/xmlfile" xmlns:wf=3D"http://schemas.microsoft.com/sharepoi=
nt/soap/workflow/" xmlns:mver=3D"http://schemas.openxmlformats.org/markup-c=
ompatibility/2006" xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/o=
mml" xmlns:mrels=3D"http://schemas.openxmlformats.org/package/2006/relation=
ships" xmlns:ex12t=3D"http://schemas.microsoft.com/exchange/services/2006/t=
ypes" xmlns:ex12m=3D"http://schemas.microsoft.com/exchange/services/2006/me=
ssages" xmlns:Z=3D"urn:schemas-microsoft-com:" xmlns=3D"http://www.w3.org/T=
R/REC-html40">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 12 (filtered medium)">
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:Consolas;
	panose-1:2 11 6 9 2 2 4 3 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
	{mso-style-priority:99;
	mso-style-link:"Plain Text Char";
	margin:0in;
	margin-bottom:.0001pt;
	font-size:10.5pt;
	font-family:Consolas;}
span.PlainTextChar
	{mso-style-name:"Plain Text Char";
	mso-style-priority:99;
	mso-style-link:"Plain Text";
	font-family:Consolas;}
span.EmailStyle19
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
span.EmailStyle20
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
span.EmailStyle21
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
span.EmailStyle22
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
span.EmailStyle23
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
span.EmailStyle24
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><span style=3D'color:#1F497D'>Not if you send the reci=
pient info&#8217;s
with the encrypted hmac as an unauthenticated attribute.<o:p></o:p></span><=
/p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span>=
</p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'>Trevor<o:p></o:p></span>=
</p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span>=
</p>

<div>

<div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in =
0in 0in'>

<p class=3DMsoNormal><b><span style=3D'font-size:10.0pt;font-family:"Tahoma=
","sans-serif"'>From:</span></b><span
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'> Jim Schaad
[mailto:[email-masked]] <br>
<b>Sent:</b> Monday, May 05, 2008 3:38 PM<br>
<b>To:</b> Trevor Freeman; [email-masked]<br>
<b>Subject:</b> RE: weak authentication issue with rfc5083<o:p></o:p></span=
></p>

</div>

</div>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'>The downside of this wou=
ld be
that you could no longer do one pass encoding.&nbsp; You would need to comp=
ute
the HMAC prior to computing the recipient infos.<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span>=
</p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'>Jim<o:p></o:p></span></p=

<p class=3DMsoNormal><span style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span>=
</p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span>=
</p>

<div style=3D'border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in =
4.0pt'>

<div>

<div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in =
0in 0in'>

<p class=3DMsoNormal><b><span style=3D'font-size:10.0pt;font-family:"Tahoma=
","sans-serif"'>From:</span></b><span
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'> Trevor Freema=
n
[mailto:[email-masked]] <br>
<b>Sent:</b> Monday, May 05, 2008 2:03 PM<br>
<b>To:</b> Trevor Freeman; Jim Schaad; [email-masked]<br>
<b>Subject:</b> RE: weak authentication issue with rfc5083<o:p></o:p></span=
></p>

</div>

</div>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'>Another suggestion is to=
 use the
kek to wrap the hmac just like you wrapped the CEK.<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span>=
</p>

<div>

<div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in =
0in 0in'>

<p class=3DMsoNormal><b><span style=3D'font-size:10.0pt;font-family:"Tahoma=
","sans-serif"'>From:</span></b><span
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'> owner-ietf-sm=
[email-masked]
[mailto:[email-masked]] <b>On Behalf Of </b>Trevor Freeman<b=
r>
<b>Sent:</b> Monday, May 05, 2008 1:40 PM<br>
<b>To:</b> Jim Schaad; [email-masked]<br>
<b>Subject:</b> RE: weak authentication issue with rfc5083<o:p></o:p></span=
></p>

</div>

</div>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'>Hi Jim,<o:p></o:p></span=
></p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'>You can demonstrate know=
ledge of
both HMAC and KEK fairly simply per recipient e.g. by concatenating the KEK
with the message HMAC and hashing the result. Since Mallet does not know th=
e
KEK they cannot compute the new hash. This fix works for both 3852 and 5083=
.<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span>=
</p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'>Trevor<o:p></o:p></span>=
</p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span>=
</p>

<div>

<div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in =
0in 0in'>

<p class=3DMsoNormal><b><span style=3D'font-size:10.0pt;font-family:"Tahoma=
","sans-serif"'>From:</span></b><span
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'> Jim Schaad
[mailto:[email-masked]] <br>
<b>Sent:</b> Monday, May 05, 2008 1:23 PM<br>
<b>To:</b> Trevor Freeman; [email-masked]<br>
<b>Subject:</b> RE: weak authentication issue with rfc5083<o:p></o:p></span=
></p>

</div>

</div>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'>Trevor,<o:p></o:p></span=
></p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span>=
</p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'>The same issue also occu=
rs for
AuthenticatedData in RFC 3852.&nbsp; This has been known for a long time.<o=
:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span>=
</p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'>I am not sure how a
demonstration of the KEK would solve this issue however.&nbsp; The only way
that I know to actually deal with this problem is to place the computed MAC
under encryption for each recipient.<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span>=
</p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'>Jim<o:p></o:p></span></p=

<p class=3DMsoNormal><span style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span>=
</p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span>=
</p>

<div style=3D'border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in =
4.0pt'>

<div>

<div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in =
0in 0in'>

<p class=3DMsoNormal><b><span style=3D'font-size:10.0pt;font-family:"Tahoma=
","sans-serif"'>From:</span></b><span
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'> owner-ietf-sm=
[email-masked]
[mailto:[email-masked]] <b>On Behalf Of </b>Trevor Freeman<b=
r>
<b>Sent:</b> Monday, May 05, 2008 12:52 PM<br>
<b>To:</b> [email-masked]<br>
<b>Subject:</b> weak authentication issue with rfc5083<o:p></o:p></span></p=

</div>

</div>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>We have identified a potential for spoofing when using
rfc5083.<o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>Rfc5083 computes a message HMAC over the content using=
 the
authenticated encryption algorithms. The message HMAC is calculated based o=
n
the content and the content encryption key (CEK). <o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>A number of allowed key management techniques derive a=
 key
encryption key (KEK) which can be used to authenticate the sender e.g.
Static-Static Diffie Hellman, Kerberos shared secret, shared password. The =
KEK
is used to encrypt the CEK per recipient.<o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>However when the integrity of the message is validated=
 via the
message HMAC, the sender only demonstrates knowledge of the CEK to the
recipient.<o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>Any other recipient knows the CEK so can construct ano=
ther
message using the same CEK and compute the new HMAC and reuse the encrypted=
 KEK
data from the original message. For example:<o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoPlainText><span style=3D'font-size:11.0pt;font-family:"Calibr=
i","sans-serif"'>Alice
sends a message to Bob and Mallet. Alice uses &nbsp;different KEK&#8217;s
&nbsp;for both Bob and Mallet to encrypt the CEK. Bob decrypts the CEK
using&nbsp; his KEK. The message decrypts and the HMAC checks out so Bob th=
ink
the message is from Alice because only Bob and Alice know the KEK.<o:p></o:=
p></span></p>

<p class=3DMsoPlainText><span style=3D'font-size:11.0pt;font-family:"Calibr=
i","sans-serif"'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoPlainText><span style=3D'font-size:11.0pt;font-family:"Calibr=
i","sans-serif"'>Mallet
is the recipient of the original message so he can use his KEK to learn the
message CEK. Mallet then &nbsp;constructs a new message and encrypts it usi=
ng
the same CEK as the original message. Mallet copies Bobs &nbsp;KEK recipien=
t
Info from Alice's message which contains the same encrypted CEK. Because Ma=
llet
knows the CEK he can also compute the correct HMAC for the new message. Mal=
let
sends the new message to Bob. Bob again uses his KEK to discover the CEK an=
d
successfully decrypts the message and the HMAC check out so Bob thinks this=
 new
message is also from Alice.<o:p></o:p></span></p>

<p class=3DMsoPlainText><span style=3D'font-size:11.0pt;font-family:"Calibr=
i","sans-serif"'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoPlainText><span style=3D'font-size:11.0pt;font-family:"Calibr=
i","sans-serif"'>This
issue only applies when there are multiple recipients. The motivation to us=
e
the new authenticated encryption is to improve performance so solutions lik=
e
bifurcating messages to use different CEK or signing the message are
counterproductive.<o:p></o:p></span></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>We need an additional structure to allow the sender to
demonstrate knowledge of both the KEK and CEK per recipient when sending to
multiple recipients.<o:p></o:p></p>

<p class=3DMsoNormal>What is the consensus to resolve this? <o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>We can version 5083 to document the new structure or w=
e can
do document the new structure via a standalone document.<o:p></o:p></p>

</div>

</div>

</div>

</body>

</html>

--_000_F767238E699C2E43895DDFB5F435088F0C2C07BE77DFMBX61exchan_--

From: "Jim Schaad" <[email-masked]>
To: "'Trevor Freeman'" <[email-masked]>, <[email-masked]>
Subject: RE: weak authentication issue with rfc5083
Date: Mon, 5 May 2008 15:38:14 -0700
Sender: [email-masked]

This is a multipart message in MIME format.

------=_NextPart_000_130A_01C8AEC6.0A39D8E0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

The downside of this would be that you could no longer do one pass encoding.
You would need to compute the HMAC prior to computing the recipient infos.

Jim

From: Trevor Freeman [mailto:[email-masked]] 
Sent: Monday, May 05, 2008 2:03 PM
To: Trevor Freeman; Jim Schaad; [email-masked]
Subject: RE: weak authentication issue with rfc5083

Another suggestion is to use the kek to wrap the hmac just like you wrapped
the CEK.

From: [email-masked] [mailto:[email-masked]]
On Behalf Of Trevor Freeman
Sent: Monday, May 05, 2008 1:40 PM
To: Jim Schaad; [email-masked]
Subject: RE: weak authentication issue with rfc5083

Hi Jim,

You can demonstrate knowledge of both HMAC and KEK fairly simply per
recipient e.g. by concatenating the KEK with the message HMAC and hashing
the result. Since Mallet does not know the KEK they cannot compute the new
hash. This fix works for both 3852 and 5083.

Trevor

From: Jim Schaad [mailto:[email-masked]] 
Sent: Monday, May 05, 2008 1:23 PM
To: Trevor Freeman; [email-masked]
Subject: RE: weak authentication issue with rfc5083

Trevor,

The same issue also occurs for AuthenticatedData in RFC 3852.  This has been
known for a long time.

I am not sure how a demonstration of the KEK would solve this issue however.
The only way that I know to actually deal with this problem is to place the
computed MAC under encryption for each recipient.

Jim

From: [email-masked] [mailto:[email-masked]]
On Behalf Of Trevor Freeman
Sent: Monday, May 05, 2008 12:52 PM
To: [email-masked]
Subject: weak authentication issue with rfc5083

We have identified a potential for spoofing when using rfc5083.

Rfc5083 computes a message HMAC over the content using the authenticated
encryption algorithms. The message HMAC is calculated based on the content
and the content encryption key (CEK). 

A number of allowed key management techniques derive a key encryption key
(KEK) which can be used to authenticate the sender e.g. Static-Static Diffie
Hellman, Kerberos shared secret, shared password. The KEK is used to encrypt
the CEK per recipient.

However when the integrity of the message is validated via the message HMAC,
the sender only demonstrates knowledge of the CEK to the recipient.

Any other recipient knows the CEK so can construct another message using the
same CEK and compute the new HMAC and reuse the encrypted KEK data from the
original message. For example:

Alice sends a message to Bob and Mallet. Alice uses  different KEK's  for
both Bob and Mallet to encrypt the CEK. Bob decrypts the CEK using  his KEK.
The message decrypts and the HMAC checks out so Bob think the message is
from Alice because only Bob and Alice know the KEK.

Mallet is the recipient of the original message so he can use his KEK to
learn the message CEK. Mallet then  constructs a new message and encrypts it
using the same CEK as the original message. Mallet copies Bobs  KEK
recipient Info from Alice's message which contains the same encrypted CEK.
Because Mallet knows the CEK he can also compute the correct HMAC for the
new message. Mallet sends the new message to Bob. Bob again uses his KEK to
discover the CEK and successfully decrypts the message and the HMAC check
out so Bob thinks this new message is also from Alice.

This issue only applies when there are multiple recipients. The motivation
to use the new authenticated encryption is to improve performance so
solutions like bifurcating messages to use different CEK or signing the
message are counterproductive.

We need an additional structure to allow the sender to demonstrate knowledge
of both the KEK and CEK per recipient when sending to multiple recipients.

What is the consensus to resolve this? 

We can version 5083 to document the new structure or we can do document the
new structure via a standalone document.

------=_NextPart_000_130A_01C8AEC6.0A39D8E0
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:x=3D"urn:schemas-microsoft-com:office:excel" =
xmlns:p=3D"urn:schemas-microsoft-com:office:powerpoint" =
xmlns:a=3D"urn:schemas-microsoft-com:office:access" =
xmlns:dt=3D"uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" =
xmlns:s=3D"uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" =
xmlns:rs=3D"urn:schemas-microsoft-com:rowset" xmlns:z=3D"#RowsetSchema" =
xmlns:b=3D"urn:schemas-microsoft-com:office:publisher" =
xmlns:ss=3D"urn:schemas-microsoft-com:office:spreadsheet" =
xmlns:c=3D"urn:schemas-microsoft-com:office:component:spreadsheet" =
xmlns:oa=3D"urn:schemas-microsoft-com:office:activation" =
xmlns:html=3D"http://www.w3.org/TR/REC-html40" =
xmlns:q=3D"http://schemas.xmlsoap.org/soap/envelope/" xmlns:D=3D"DAV:" =
xmlns:x2=3D"http://schemas.microsoft.com/office/excel/2003/xml" =
xmlns:ois=3D"http://schemas.microsoft.com/sharepoint/soap/ois/" =
xmlns:dir=3D"http://schemas.microsoft.com/sharepoint/soap/directory/" =
xmlns:ds=3D"http://www.w3.org/2000/09/xmldsig#" =
xmlns:dsp=3D"http://schemas.microsoft.com/sharepoint/dsp" =
xmlns:udc=3D"http://schemas.microsoft.com/data/udc" =
xmlns:xsd=3D"http://www.w3.org/2001/XMLSchema" =
xmlns:sub=3D"http://schemas.microsoft.com/sharepoint/soap/2002/1/alerts/"=
 xmlns:ec=3D"http://www.w3.org/2001/04/xmlenc#" =
xmlns:sp=3D"http://schemas.microsoft.com/sharepoint/" =
xmlns:sps=3D"http://schemas.microsoft.com/sharepoint/soap/" =
xmlns:xsi=3D"http://www.w3.org/2001/XMLSchema-instance" =
xmlns:udcxf=3D"http://schemas.microsoft.com/data/udc/xmlfile" =
xmlns:wf=3D"http://schemas.microsoft.com/sharepoint/soap/workflow/" =
xmlns:mver=3D"http://schemas.openxmlformats.org/markup-compatibility/2006=
" xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" =
xmlns:mrels=3D"http://schemas.openxmlformats.org/package/2006/relationshi=
ps" =
xmlns:ex12t=3D"http://schemas.microsoft.com/exchange/services/2006/types"=
 =
xmlns:ex12m=3D"http://schemas.microsoft.com/exchange/services/2006/messag=
es" xmlns:Z=3D"urn:schemas-microsoft-com:" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 12 (filtered medium)">
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:Consolas;
	panose-1:2 11 6 9 2 2 4 3 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
	{mso-style-priority:99;
	mso-style-link:"Plain Text Char";
	margin:0in;
	margin-bottom:.0001pt;
	font-size:10.5pt;
	font-family:Consolas;}
span.PlainTextChar
	{mso-style-name:"Plain Text Char";
	mso-style-priority:99;
	mso-style-link:"Plain Text";
	font-family:Consolas;}
span.EmailStyle19
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
span.EmailStyle20
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
span.EmailStyle21
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
span.EmailStyle22
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
span.EmailStyle23
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><span style=3D'color:#1F497D'>The downside of this =
would be
that you could no longer do one pass encoding.&nbsp; You would need to =
compute the HMAC
prior to computing the recipient infos.<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'color:#1F497D'>Jim<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<div style=3D'border:none;border-left:solid blue 1.5pt;padding:0in 0in =
0in 4.0pt'>

<div>

<div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt =
0in 0in 0in'>

<p class=3DMsoNormal><b><span =
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span>=
</b><span
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'> Trevor =
Freeman
[mailto:[email-masked]] <br>
<b>Sent:</b> Monday, May 05, 2008 2:03 PM<br>
<b>To:</b> Trevor Freeman; Jim Schaad; [email-masked]<br>
<b>Subject:</b> RE: weak authentication issue with =
rfc5083<o:p></o:p></span></p>

</div>

</div>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'>Another suggestion is =
to use the
kek to wrap the hmac just like you wrapped the =
CEK.<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<div>

<div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt =
0in 0in 0in'>

<p class=3DMsoNormal><b><span =
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span>=
</b><span
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>
[email-masked] [mailto:[email-masked]] =
<b>On
Behalf Of </b>Trevor Freeman<br>
<b>Sent:</b> Monday, May 05, 2008 1:40 PM<br>
<b>To:</b> Jim Schaad; [email-masked]<br>
<b>Subject:</b> RE: weak authentication issue with =
rfc5083<o:p></o:p></span></p>

</div>

</div>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'>Hi =
Jim,<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'>You can demonstrate =
knowledge of
both HMAC and KEK fairly simply per recipient e.g. by concatenating the =
KEK
with the message HMAC and hashing the result. Since Mallet does not know =
the
KEK they cannot compute the new hash. This fix works for both 3852 and =
5083.<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'color:#1F497D'>Trevor<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<div>

<div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt =
0in 0in 0in'>

<p class=3DMsoNormal><b><span =
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span>=
</b><span
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'> Jim Schaad
[mailto:[email-masked]] <br>
<b>Sent:</b> Monday, May 05, 2008 1:23 PM<br>
<b>To:</b> Trevor Freeman; [email-masked]<br>
<b>Subject:</b> RE: weak authentication issue with =
rfc5083<o:p></o:p></span></p>

</div>

</div>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal><span =
style=3D'color:#1F497D'>Trevor,<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'>The same issue also =
occurs for
AuthenticatedData in RFC 3852.&nbsp; This has been known for a long =
time.<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'>I am not sure how a
demonstration of the KEK would solve this issue however.&nbsp; The only =
way
that I know to actually deal with this problem is to place the computed =
MAC
under encryption for each recipient.<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'color:#1F497D'>Jim<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<div style=3D'border:none;border-left:solid blue 1.5pt;padding:0in 0in =
0in 4.0pt'>

<div>

<div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt =
0in 0in 0in'>

<p class=3DMsoNormal><b><span =
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span>=
</b><span
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>
[email-masked] [mailto:[email-masked]] =
<b>On
Behalf Of </b>Trevor Freeman<br>
<b>Sent:</b> Monday, May 05, 2008 12:52 PM<br>
<b>To:</b> [email-masked]<br>
<b>Subject:</b> weak authentication issue with =
rfc5083<o:p></o:p></span></p>

</div>

</div>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>We have identified a potential for spoofing when =
using
rfc5083.<o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>Rfc5083 computes a message HMAC over the content =
using the
authenticated encryption algorithms. The message HMAC is calculated =
based on
the content and the content encryption key (CEK). <o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>A number of allowed key management techniques =
derive a key
encryption key (KEK) which can be used to authenticate the sender e.g.
Static-Static Diffie Hellman, Kerberos shared secret, shared password. =
The KEK
is used to encrypt the CEK per recipient.<o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>However when the integrity of the message is =
validated via
the message HMAC, the sender only demonstrates knowledge of the CEK to =
the
recipient.<o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>Any other recipient knows the CEK so can construct =
another
message using the same CEK and compute the new HMAC and reuse the =
encrypted KEK
data from the original message. For example:<o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoPlainText><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'>Alice
sends a message to Bob and Mallet. Alice uses &nbsp;different =
KEK&#8217;s &nbsp;for
both Bob and Mallet to encrypt the CEK. Bob decrypts the CEK using&nbsp; =
his
KEK. The message decrypts and the HMAC checks out so Bob think the =
message is
from Alice because only Bob and Alice know the =
KEK.<o:p></o:p></span></p>

<p class=3DMsoPlainText><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'><o:p>&nbsp;=
</o:p></span></p>

<p class=3DMsoPlainText><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'>Mallet
is the recipient of the original message so he can use his KEK to learn =
the
message CEK. Mallet then &nbsp;constructs a new message and encrypts it =
using the
same CEK as the original message. Mallet copies Bobs &nbsp;KEK recipient =
Info
from Alice's message which contains the same encrypted CEK. Because =
Mallet
knows the CEK he can also compute the correct HMAC for the new message. =
Mallet
sends the new message to Bob. Bob again uses his KEK to discover the CEK =
and
successfully decrypts the message and the HMAC check out so Bob thinks =
this new
message is also from Alice.<o:p></o:p></span></p>

<p class=3DMsoPlainText><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'><o:p>&nbsp;=
</o:p></span></p>

<p class=3DMsoPlainText><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'>This
issue only applies when there are multiple recipients. The motivation to =
use
the new authenticated encryption is to improve performance so solutions =
like
bifurcating messages to use different CEK or signing the message are
counterproductive.<o:p></o:p></span></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>We need an additional structure to allow the sender =
to
demonstrate knowledge of both the KEK and CEK per recipient when sending =
to
multiple recipients.<o:p></o:p></p>

<p class=3DMsoNormal>What is the consensus to resolve this? =
<o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>We can version 5083 to document the new structure =
or we can
do document the new structure via a standalone document.<o:p></o:p></p>

</div>

</div>

</div>

</body>

</html>

------=_NextPart_000_130A_01C8AEC6.0A39D8E0--

From: Daniel Brown <[email-masked]>
To: Trevor Freeman <[email-masked]>
CC: "[email-masked]" <[email-masked]>
Date: Mon, 5 May 2008 18:09:29 -0400
Subject: RE: weak authentication issue with rfc5083
Accept-Language: en-US
acceptlanguage: en-US
Sender: [email-masked]

--_000_C49217E2D694874EB820EA90DCE67619C22761EEEX40exchserverc_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Trevor,

Essentially the same problem was commented upon in RFC 3278:

http://tools.ietf.org/html/rfc3278#section-4.1.2

but no solution was provided other than to use separate AuthenticatedData p=
er recipient. There are some other possible solutions, however.

For example, in the case of Diffie-Hellman, the input into the KDF used to =
compute the KEK from the raw DH secret can be include the MAC tag, which pr=
events message substitution.  See Section 5 of http://eprint.iacr.org/2005/=
056 for more discussion.

Best regards,

                Dan

From: [email-masked] [mailto:[email-masked]] =
On Behalf Of Trevor Freeman
Sent: Monday, May 05, 2008 3:52 PM
To: [email-masked]
Subject: weak authentication issue with rfc5083

We have identified a potential for spoofing when using rfc5083.

Rfc5083 computes a message HMAC over the content using the authenticated en=
cryption algorithms. The message HMAC is calculated based on the content an=
d the content encryption key (CEK).

A number of allowed key management techniques derive a key encryption key (=
KEK) which can be used to authenticate the sender e.g. Static-Static Diffie=
 Hellman, Kerberos shared secret, shared password. The KEK is used to encry=
pt the CEK per recipient.

However when the integrity of the message is validated via the message HMAC=
, the sender only demonstrates knowledge of the CEK to the recipient.

Any other recipient knows the CEK so can construct another message using th=
e same CEK and compute the new HMAC and reuse the encrypted KEK data from t=
he original message. For example:

Alice sends a message to Bob and Mallet. Alice uses  different KEK's  for b=
oth Bob and Mallet to encrypt the CEK. Bob decrypts the CEK using  his KEK.=
 The message decrypts and the HMAC checks out so Bob think the message is f=
rom Alice because only Bob and Alice know the KEK.

Mallet is the recipient of the original message so he can use his KEK to le=
arn the message CEK. Mallet then  constructs a new message and encrypts it =
using the same CEK as the original message. Mallet copies Bobs  KEK recipie=
nt Info from Alice's message which contains the same encrypted CEK. Because=
 Mallet knows the CEK he can also compute the correct HMAC for the new mess=
age. Mallet sends the new message to Bob. Bob again uses his KEK to discove=
r the CEK and successfully decrypts the message and the HMAC check out so B=
ob thinks this new message is also from Alice.

This issue only applies when there are multiple recipients. The motivation =
to use the new authenticated encryption is to improve performance so soluti=
ons like bifurcating messages to use different CEK or signing the message a=
re counterproductive.

We need an additional structure to allow the sender to demonstrate knowledg=
e of both the KEK and CEK per recipient when sending to multiple recipients=
.
What is the consensus to resolve this?

We can version 5083 to document the new structure or we can do document the=
 new structure via a standalone document.

--_000_C49217E2D694874EB820EA90DCE67619C22761EEEX40exchserverc_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 12 (filtered medium)">
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:Consolas;
	panose-1:2 11 6 9 2 2 4 3 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
	{mso-style-priority:99;
	mso-style-link:"Plain Text Char";
	margin:0in;
	margin-bottom:.0001pt;
	font-size:10.5pt;
	font-family:Consolas;}
span.PlainTextChar
	{mso-style-name:"Plain Text Char";
	mso-style-priority:99;
	mso-style-link:"Plain Text";
	font-family:Consolas;}
span.EmailStyle19
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
span.EmailStyle20
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><span style=3D'color:#1F497D'>Trevor,<o:p></o:p></span=
></p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span>=
</p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'>Essentially the same pro=
blem was
commented upon in RFC 3278:<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span>=
</p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'><a
href=3D"http://tools.ietf.org/html/rfc3278#section-4.1.2">http://tools.ietf=
.org/html/rfc3278#section-4.1.2</a><o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span>=
</p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'>but no solution was prov=
ided other
than to use separate AuthenticatedData per recipient. There are some other =
possible
solutions, however.&nbsp; <o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span>=
</p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'>For example, in the case=
 of
Diffie-Hellman, the input into the KDF used to compute the KEK from the raw=
 DH
secret can be include the MAC tag, which prevents message substitution.&nbs=
p;
See Section 5 of <a href=3D"http://eprint.iacr.org/2005/056">http://eprint.=
iacr.org/2005/056</a>
for more discussion.<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span>=
</p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'>Best regards,<o:p></o:p>=
</span></p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span>=
</p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'>&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Dan<o:p>=
</o:p></span></p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span>=
</p>

<div>

<div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in =
0in 0in'>

<p class=3DMsoNormal><b><span style=3D'font-size:10.0pt;font-family:"Tahoma=
","sans-serif"'>From:</span></b><span
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>
[email-masked] [mailto:[email-masked]] <b>On
Behalf Of </b>Trevor Freeman<br>
<b>Sent:</b> Monday, May 05, 2008 3:52 PM<br>
<b>To:</b> [email-masked]<br>
<b>Subject:</b> weak authentication issue with rfc5083<o:p></o:p></span></p=

</div>

</div>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>We have identified a potential for spoofing when using
rfc5083.<o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>Rfc5083 computes a message HMAC over the content using=
 the
authenticated encryption algorithms. The message HMAC is calculated based o=
n
the content and the content encryption key (CEK). <o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>A number of allowed key management techniques derive a=
 key
encryption key (KEK) which can be used to authenticate the sender e.g.
Static-Static Diffie Hellman, Kerberos shared secret, shared password. The =
KEK
is used to encrypt the CEK per recipient.<o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>However when the integrity of the message is validated=
 via
the message HMAC, the sender only demonstrates knowledge of the CEK to the
recipient.<o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>Any other recipient knows the CEK so can construct ano=
ther
message using the same CEK and compute the new HMAC and reuse the encrypted=
 KEK
data from the original message. For example:<o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoPlainText><span style=3D'font-size:11.0pt;font-family:"Calibr=
i","sans-serif"'>Alice
sends a message to Bob and Mallet. Alice uses &nbsp;different KEK&#8217;s
&nbsp;for both Bob and Mallet to encrypt the CEK. Bob decrypts the CEK
using&nbsp; his KEK. The message decrypts and the HMAC checks out so Bob th=
ink
the message is from Alice because only Bob and Alice know the KEK.<o:p></o:=
p></span></p>

<p class=3DMsoPlainText><span style=3D'font-size:11.0pt;font-family:"Calibr=
i","sans-serif"'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoPlainText><span style=3D'font-size:11.0pt;font-family:"Calibr=
i","sans-serif"'>Mallet
is the recipient of the original message so he can use his KEK to learn the
message CEK. Mallet then &nbsp;constructs a new message and encrypts it usi=
ng
the same CEK as the original message. Mallet copies Bobs &nbsp;KEK recipien=
t
Info from Alice's message which contains the same encrypted CEK. Because Ma=
llet
knows the CEK he can also compute the correct HMAC for the new message. Mal=
let
sends the new message to Bob. Bob again uses his KEK to discover the CEK an=
d
successfully decrypts the message and the HMAC check out so Bob thinks this=
 new
message is also from Alice.<o:p></o:p></span></p>

<p class=3DMsoPlainText><span style=3D'font-size:11.0pt;font-family:"Calibr=
i","sans-serif"'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoPlainText><span style=3D'font-size:11.0pt;font-family:"Calibr=
i","sans-serif"'>This
issue only applies when there are multiple recipients. The motivation to us=
e
the new authenticated encryption is to improve performance so solutions lik=
e
bifurcating messages to use different CEK or signing the message are
counterproductive.<o:p></o:p></span></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>We need an additional structure to allow the sender to
demonstrate knowledge of both the KEK and CEK per recipient when sending to
multiple recipients.<o:p></o:p></p>

<p class=3DMsoNormal>What is the consensus to resolve this? <o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>We can version 5083 to document the new structure or w=
e can
do document the new structure via a standalone document.<o:p></o:p></p>

</div>

</body>

</html>

--_000_C49217E2D694874EB820EA90DCE67619C22761EEEX40exchserverc_--

From: "Tony Capel" <[email-masked]>
To: "'Turner, Sean P.'" <[email-masked]>, "'Paul Hoffman'" <[email-masked]>, <[email-masked]>
Subject: RE: S/MIME v3.2  IDs key size text
Date: Mon, 5 May 2008 17:34:02 -0400
Importance: Normal
Sender: [email-masked]

Sean:

Agreed, the text in 3850bis and 3851bis needs to align.  I have no =
problems with
support for smaller key sizes.

I expect constraints on key size to be implemented by the certificate =
issuer
anyway.  If you get a 512 key in a cert you trust you must be able to =
use it,
no? =20

Tony

| -----Original Message-----
| From: [email-masked]=20
| [mailto:[email-masked]] On Behalf Of Turner, Sean P.
| Sent: May 5, 2008 4:58 PM
| To: 'Tony Capel'; 'Paul Hoffman'; [email-masked]
| Subject: RE: S/MIME v3.2 IDs key size text
|=20
|=20
|=20
| Tony,
|=20
| There was a comment from Paul against the text you cite from=20
| 3850bis. He objected to moving the lower bounds from 512 to=20
| 1024. I figured I'd post both -02 drafts once we knocked this=20
| issue out.
|=20
| spt
|=20
| >-----Original Message-----
| >From: Tony Capel [mailto:[email-masked]]
| >Sent: Monday, May 05, 2008 4:09 PM
| >To: 'Paul Hoffman'; 'Turner, Sean P.'; [email-masked]
| >Subject: RE: S/MIME v3.2 IDs key size text
| >
| >All:
| >
| >I agree that deleting " namely 1024 bits" from the first
| >sentence of the proposed security considerations section=20
| >paragraph is good.  The second "1024"
| >in the proposed paragraph is not a problem for me since it is=20
| >not "normative".
| >
| >With respect to section 4.1 (Key Pair Generation).  Is it
| >intended to change the title of this section?  The second=20
| >paragraph of the current text in 3851bis-01.txt begins "If an=20
| >S/MIME agent needs to generate ...".  So if the S/MIME agent=20
| >does NOT need to generate keys (and this is typically the=20
| >case, most enrollment & key generation are done externally to=20
| >messaging clients) the balance of this paragraph (which=20
| >mentions the key sizes) is not normative (as currently drafted=20
| >- its quite possible that the last sentence of this paragraph=20
| >should have been in a separate paragraph).  Key generation=20
| >requirements are normally (hopefully!) cited in the=20
| >corresponding CP, where things such as required key sizes,=20
| >where they are generated (locally or at the CA), FIPS-140=20
| >Level, etc. should be (!!) explicitly identified.  Maybe the=20
| >second paragraph of
| >4.1 could be replaced with a simple statement:
| >
| >"If an S/MIME agent needs to generate one or more key pairs,
| >each SHOULD be generated according to the corresponding=20
| >certificate policy, refer for example to [RFC3647]."
| >
| >The proposed text, and the discussion so far, is really
| >speaking about "what range of RSA key sizes" needs to be=20
| >supported.  We are NOT providing security advice, we are just=20
| >trying to ensure that most smime v3.2 implementations will=20
| >interwork in the typical environments expected "in the wild"=20
| >(and special environments will be understood by purchasers=20
| >anyway, so we likely need not worry about high security=20
| >applications - only the general "public"
| >environments).=20
| >
| >A similar issue is already addressed in CERT v3.2 (
| >draft-ietf-smime-3850bis-01.txt ) in Section 4.3 for=20
| >certificate  validation.
| >We might consider copying the last sentence of CERT v3.2 Sec=20
| >4.3 to the end of sections 2.2 and 2.3 (just before the Notes):
| >
| >   "Key sizes from 1024 bits to 2048 bits MUST be supported."
| >
| >This would also have the advantage of aligning CERT and MSG.
| >
| >Tony
| >
| >
| >| -----Original Message-----
| >| From: [email-masked]=20
| >| [mailto:[email-masked]] On Behalf Of Paul Hoffman
| >| Sent: May 3, 2008 10:08 PM
| >| To: Turner, Sean P.; [email-masked]
| >| Subject: RE: S/MIME v3.2 IDs key size text
| >|=20
| >|=20
| >|=20
| >| At 8:51 PM -0400 5/3/08, Turner, Sean P. wrote:
| >| >I think if we struck ", namely 1024 bits" from the text in
| >| the security
| >| >considerations that it's still a true statement and we
| >won't have to
| >| >change it every time we update the spec.
| >|=20
| >| I'm OK with that, but I also feel that if we're updating=20
| the minimum
| >| mandatory signing length, it is trivial to update the Security=20
| >| Considerations as well.
| >|=20
| >
|=20

From: Trevor Freeman <[email-masked]>
To: Trevor Freeman <[email-masked]>, Jim Schaad <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Mon, 5 May 2008 21:03:23 +0000
Subject: RE: weak authentication issue with rfc5083
Accept-Language: en-US
Sender: [email-masked]

--_000_F767238E699C2E43895DDFB5F435088F0C2C06CFE4DFMBX61exchan_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Another suggestion is to use the kek to wrap the hmac just like you wrapped=
 the CEK.

From: [email-masked] [mailto:[email-masked]] =
On Behalf Of Trevor Freeman
Sent: Monday, May 05, 2008 1:40 PM
To: Jim Schaad; [email-masked]
Subject: RE: weak authentication issue with rfc5083

Hi Jim,
You can demonstrate knowledge of both HMAC and KEK fairly simply per recipi=
ent e.g. by concatenating the KEK with the message HMAC and hashing the res=
ult. Since Mallet does not know the KEK they cannot compute the new hash. T=
his fix works for both 3852 and 5083.

Trevor

From: Jim Schaad [mailto:[email-masked]]
Sent: Monday, May 05, 2008 1:23 PM
To: Trevor Freeman; [email-masked]
Subject: RE: weak authentication issue with rfc5083

Trevor,

The same issue also occurs for AuthenticatedData in RFC 3852.  This has bee=
n known for a long time.

I am not sure how a demonstration of the KEK would solve this issue however=
.  The only way that I know to actually deal with this problem is to place =
the computed MAC under encryption for each recipient.

Jim

From: [email-masked] [mailto:[email-masked]] =
On Behalf Of Trevor Freeman
Sent: Monday, May 05, 2008 12:52 PM
To: [email-masked]
Subject: weak authentication issue with rfc5083

We have identified a potential for spoofing when using rfc5083.

Rfc5083 computes a message HMAC over the content using the authenticated en=
cryption algorithms. The message HMAC is calculated based on the content an=
d the content encryption key (CEK).

A number of allowed key management techniques derive a key encryption key (=
KEK) which can be used to authenticate the sender e.g. Static-Static Diffie=
 Hellman, Kerberos shared secret, shared password. The KEK is used to encry=
pt the CEK per recipient.

However when the integrity of the message is validated via the message HMAC=
, the sender only demonstrates knowledge of the CEK to the recipient.

Any other recipient knows the CEK so can construct another message using th=
e same CEK and compute the new HMAC and reuse the encrypted KEK data from t=
he original message. For example:

Alice sends a message to Bob and Mallet. Alice uses  different KEK's  for b=
oth Bob and Mallet to encrypt the CEK. Bob decrypts the CEK using  his KEK.=
 The message decrypts and the HMAC checks out so Bob think the message is f=
rom Alice because only Bob and Alice know the KEK.

Mallet is the recipient of the original message so he can use his KEK to le=
arn the message CEK. Mallet then  constructs a new message and encrypts it =
using the same CEK as the original message. Mallet copies Bobs  KEK recipie=
nt Info from Alice's message which contains the same encrypted CEK. Because=
 Mallet knows the CEK he can also compute the correct HMAC for the new mess=
age. Mallet sends the new message to Bob. Bob again uses his KEK to discove=
r the CEK and successfully decrypts the message and the HMAC check out so B=
ob thinks this new message is also from Alice.

This issue only applies when there are multiple recipients. The motivation =
to use the new authenticated encryption is to improve performance so soluti=
ons like bifurcating messages to use different CEK or signing the message a=
re counterproductive.

We need an additional structure to allow the sender to demonstrate knowledg=
e of both the KEK and CEK per recipient when sending to multiple recipients=
.
What is the consensus to resolve this?

We can version 5083 to document the new structure or we can do document the=
 new structure via a standalone document.

--_000_F767238E699C2E43895DDFB5F435088F0C2C06CFE4DFMBX61exchan_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:x=3D"urn:schemas-microsoft-com:office:excel" xmlns:p=3D"urn:schemas-m=
icrosoft-com:office:powerpoint" xmlns:a=3D"urn:schemas-microsoft-com:office=
:access" xmlns:dt=3D"uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:s=3D"=
uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" xmlns:rs=3D"urn:schemas-microsof=
t-com:rowset" xmlns:z=3D"#RowsetSchema" xmlns:b=3D"urn:schemas-microsoft-co=
m:office:publisher" xmlns:ss=3D"urn:schemas-microsoft-com:office:spreadshee=
t" xmlns:c=3D"urn:schemas-microsoft-com:office:component:spreadsheet" xmlns=
:oa=3D"urn:schemas-microsoft-com:office:activation" xmlns:html=3D"http://ww=
w.w3.org/TR/REC-html40" xmlns:q=3D"http://schemas.xmlsoap.org/soap/envelope=
/" xmlns:D=3D"DAV:" xmlns:x2=3D"http://schemas.microsoft.com/office/excel/2=
003/xml" xmlns:ois=3D"http://schemas.microsoft.com/sharepoint/soap/ois/" xm=
lns:dir=3D"http://schemas.microsoft.com/sharepoint/soap/directory/" xmlns:d=
s=3D"http://www.w3.org/2000/09/xmldsig#" xmlns:dsp=3D"http://schemas.micros=
oft.com/sharepoint/dsp" xmlns:udc=3D"http://schemas.microsoft.com/data/udc"=
 xmlns:xsd=3D"http://www.w3.org/2001/XMLSchema" xmlns:sub=3D"http://schemas=
.microsoft.com/sharepoint/soap/2002/1/alerts/" xmlns:ec=3D"http://www.w3.or=
g/2001/04/xmlenc#" xmlns:sp=3D"http://schemas.microsoft.com/sharepoint/" xm=
lns:sps=3D"http://schemas.microsoft.com/sharepoint/soap/" xmlns:xsi=3D"http=
://www.w3.org/2001/XMLSchema-instance" xmlns:udcxf=3D"http://schemas.micros=
oft.com/data/udc/xmlfile" xmlns:wf=3D"http://schemas.microsoft.com/sharepoi=
nt/soap/workflow/" xmlns:mver=3D"http://schemas.openxmlformats.org/markup-c=
ompatibility/2006" xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/o=
mml" xmlns:mrels=3D"http://schemas.openxmlformats.org/package/2006/relation=
ships" xmlns:ex12t=3D"http://schemas.microsoft.com/exchange/services/2006/t=
ypes" xmlns:ex12m=3D"http://schemas.microsoft.com/exchange/services/2006/me=
ssages" xmlns:Z=3D"urn:schemas-microsoft-com:" xmlns=3D"http://www.w3.org/T=
R/REC-html40">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 12 (filtered medium)">
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:Consolas;
	panose-1:2 11 6 9 2 2 4 3 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
	{mso-style-priority:99;
	mso-style-link:"Plain Text Char";
	margin:0in;
	margin-bottom:.0001pt;
	font-size:10.5pt;
	font-family:Consolas;}
span.PlainTextChar
	{mso-style-name:"Plain Text Char";
	mso-style-priority:99;
	mso-style-link:"Plain Text";
	font-family:Consolas;}
span.EmailStyle19
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
span.EmailStyle20
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
span.EmailStyle21
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
span.EmailStyle22
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><span style=3D'color:#1F497D'>Another suggestion is to=
 use the
kek to wrap the hmac just like you wrapped the CEK.<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span>=
</p>

<div>

<div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in =
0in 0in'>

<p class=3DMsoNormal><b><span style=3D'font-size:10.0pt;font-family:"Tahoma=
","sans-serif"'>From:</span></b><span
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>
[email-masked] [mailto:[email-masked]] <b>On
Behalf Of </b>Trevor Freeman<br>
<b>Sent:</b> Monday, May 05, 2008 1:40 PM<br>
<b>To:</b> Jim Schaad; [email-masked]<br>
<b>Subject:</b> RE: weak authentication issue with rfc5083<o:p></o:p></span=
></p>

</div>

</div>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'>Hi Jim,<o:p></o:p></span=
></p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'>You can demonstrate know=
ledge of
both HMAC and KEK fairly simply per recipient e.g. by concatenating the KEK
with the message HMAC and hashing the result. Since Mallet does not know th=
e
KEK they cannot compute the new hash. This fix works for both 3852 and 5083=
.<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span>=
</p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'>Trevor<o:p></o:p></span>=
</p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span>=
</p>

<div>

<div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in =
0in 0in'>

<p class=3DMsoNormal><b><span style=3D'font-size:10.0pt;font-family:"Tahoma=
","sans-serif"'>From:</span></b><span
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'> Jim Schaad
[mailto:[email-masked]] <br>
<b>Sent:</b> Monday, May 05, 2008 1:23 PM<br>
<b>To:</b> Trevor Freeman; [email-masked]<br>
<b>Subject:</b> RE: weak authentication issue with rfc5083<o:p></o:p></span=
></p>

</div>

</div>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'>Trevor,<o:p></o:p></span=
></p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span>=
</p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'>The same issue also occu=
rs for
AuthenticatedData in RFC 3852.&nbsp; This has been known for a long time.<o=
:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span>=
</p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'>I am not sure how a
demonstration of the KEK would solve this issue however.&nbsp; The only way
that I know to actually deal with this problem is to place the computed MAC
under encryption for each recipient.<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span>=
</p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'>Jim<o:p></o:p></span></p=

<p class=3DMsoNormal><span style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span>=
</p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span>=
</p>

<div style=3D'border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in =
4.0pt'>

<div>

<div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in =
0in 0in'>

<p class=3DMsoNormal><b><span style=3D'font-size:10.0pt;font-family:"Tahoma=
","sans-serif"'>From:</span></b><span
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>
[email-masked] [mailto:[email-masked]] <b>On
Behalf Of </b>Trevor Freeman<br>
<b>Sent:</b> Monday, May 05, 2008 12:52 PM<br>
<b>To:</b> [email-masked]<br>
<b>Subject:</b> weak authentication issue with rfc5083<o:p></o:p></span></p=

</div>

</div>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>We have identified a potential for spoofing when using
rfc5083.<o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>Rfc5083 computes a message HMAC over the content using=
 the
authenticated encryption algorithms. The message HMAC is calculated based o=
n
the content and the content encryption key (CEK). <o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>A number of allowed key management techniques derive a=
 key
encryption key (KEK) which can be used to authenticate the sender e.g.
Static-Static Diffie Hellman, Kerberos shared secret, shared password. The =
KEK
is used to encrypt the CEK per recipient.<o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>However when the integrity of the message is validated=
 via
the message HMAC, the sender only demonstrates knowledge of the CEK to the
recipient.<o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>Any other recipient knows the CEK so can construct ano=
ther
message using the same CEK and compute the new HMAC and reuse the encrypted=
 KEK
data from the original message. For example:<o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoPlainText><span style=3D'font-size:11.0pt;font-family:"Calibr=
i","sans-serif"'>Alice
sends a message to Bob and Mallet. Alice uses &nbsp;different KEK&#8217;s
&nbsp;for both Bob and Mallet to encrypt the CEK. Bob decrypts the CEK
using&nbsp; his KEK. The message decrypts and the HMAC checks out so Bob th=
ink
the message is from Alice because only Bob and Alice know the KEK.<o:p></o:=
p></span></p>

<p class=3DMsoPlainText><span style=3D'font-size:11.0pt;font-family:"Calibr=
i","sans-serif"'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoPlainText><span style=3D'font-size:11.0pt;font-family:"Calibr=
i","sans-serif"'>Mallet
is the recipient of the original message so he can use his KEK to learn the
message CEK. Mallet then &nbsp;constructs a new message and encrypts it usi=
ng
the same CEK as the original message. Mallet copies Bobs &nbsp;KEK recipien=
t
Info from Alice's message which contains the same encrypted CEK. Because Ma=
llet
knows the CEK he can also compute the correct HMAC for the new message. Mal=
let
sends the new message to Bob. Bob again uses his KEK to discover the CEK an=
d
successfully decrypts the message and the HMAC check out so Bob thinks this=
 new
message is also from Alice.<o:p></o:p></span></p>

<p class=3DMsoPlainText><span style=3D'font-size:11.0pt;font-family:"Calibr=
i","sans-serif"'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoPlainText><span style=3D'font-size:11.0pt;font-family:"Calibr=
i","sans-serif"'>This
issue only applies when there are multiple recipients. The motivation to us=
e
the new authenticated encryption is to improve performance so solutions lik=
e
bifurcating messages to use different CEK or signing the message are
counterproductive.<o:p></o:p></span></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>We need an additional structure to allow the sender to
demonstrate knowledge of both the KEK and CEK per recipient when sending to
multiple recipients.<o:p></o:p></p>

<p class=3DMsoNormal>What is the consensus to resolve this? <o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>We can version 5083 to document the new structure or w=
e can
do document the new structure via a standalone document.<o:p></o:p></p>

</div>

</div>

</body>

</html>

--_000_F767238E699C2E43895DDFB5F435088F0C2C06CFE4DFMBX61exchan_--

From: "Turner, Sean P." <[email-masked]>
To: "'Tony Capel'" <[email-masked]>, "'Paul Hoffman'" <[email-masked]>, <[email-masked]>
Subject: RE: S/MIME v3.2  IDs key size text
Date: Mon, 5 May 2008 16:57:48 -0400
Organization: IECA, Inc.
Sender: [email-masked]

Tony,

There was a comment from Paul against the text you cite from 3850bis. He
objected to moving the lower bounds from 512 to 1024. I figured I'd post
both -02 drafts once we knocked this issue out.

spt

>-----Original Message-----
>From: Tony Capel [mailto:[email-masked]] 
>Sent: Monday, May 05, 2008 4:09 PM
>To: 'Paul Hoffman'; 'Turner, Sean P.'; [email-masked]
>Subject: RE: S/MIME v3.2 IDs key size text
>
>All:
>
>I agree that deleting " namely 1024 bits" from the first 
>sentence of the proposed security considerations section 
>paragraph is good.  The second "1024"
>in the proposed paragraph is not a problem for me since it is 
>not "normative".
>
>With respect to section 4.1 (Key Pair Generation).  Is it 
>intended to change the title of this section?  The second 
>paragraph of the current text in 3851bis-01.txt begins "If an 
>S/MIME agent needs to generate ...".  So if the S/MIME agent 
>does NOT need to generate keys (and this is typically the 
>case, most enrollment & key generation are done externally to 
>messaging clients) the balance of this paragraph (which 
>mentions the key sizes) is not normative (as currently drafted 
>- its quite possible that the last sentence of this paragraph 
>should have been in a separate paragraph).  Key generation 
>requirements are normally (hopefully!) cited in the 
>corresponding CP, where things such as required key sizes, 
>where they are generated (locally or at the CA), FIPS-140 
>Level, etc. should be (!!) explicitly identified.  Maybe the 
>second paragraph of
>4.1 could be replaced with a simple statement:
>
>"If an S/MIME agent needs to generate one or more key pairs, 
>each SHOULD be generated according to the corresponding 
>certificate policy, refer for example to [RFC3647]."
>
>The proposed text, and the discussion so far, is really 
>speaking about "what range of RSA key sizes" needs to be 
>supported.  We are NOT providing security advice, we are just 
>trying to ensure that most smime v3.2 implementations will 
>interwork in the typical environments expected "in the wild" 
>(and special environments will be understood by purchasers 
>anyway, so we likely need not worry about high security 
>applications - only the general "public"
>environments). 
>
>A similar issue is already addressed in CERT v3.2 ( 
>draft-ietf-smime-3850bis-01.txt ) in Section 4.3 for 
>certificate  validation.
>We might consider copying the last sentence of CERT v3.2 Sec 
>4.3 to the end of sections 2.2 and 2.3 (just before the Notes):
>
>   "Key sizes from 1024 bits to 2048 bits MUST be supported." 
>
>This would also have the advantage of aligning CERT and MSG.
>
>Tony
>
>
>| -----Original Message-----
>| From: [email-masked]
>| [mailto:[email-masked]] On Behalf Of Paul Hoffman
>| Sent: May 3, 2008 10:08 PM
>| To: Turner, Sean P.; [email-masked]
>| Subject: RE: S/MIME v3.2 IDs key size text
>| 
>| 
>| 
>| At 8:51 PM -0400 5/3/08, Turner, Sean P. wrote:
>| >I think if we struck ", namely 1024 bits" from the text in
>| the security
>| >considerations that it's still a true statement and we 
>won't have to 
>| >change it every time we update the spec.
>| 
>| I'm OK with that, but I also feel that if we're updating the minimum 
>| mandatory signing length, it is trivial to update the Security 
>| Considerations as well.
>| 
>

From: Trevor Freeman <[email-masked]>
To: Jim Schaad <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Mon, 5 May 2008 20:40:19 +0000
Subject: RE: weak authentication issue with rfc5083
Accept-Language: en-US
Sender: [email-masked]

--_000_F767238E699C2E43895DDFB5F435088F0C2C06B884DFMBX61exchan_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi Jim,
You can demonstrate knowledge of both HMAC and KEK fairly simply per recipi=
ent e.g. by concatenating the KEK with the message HMAC and hashing the res=
ult. Since Mallet does not know the KEK they cannot compute the new hash. T=
his fix works for both 3852 and 5083.

Trevor

From: Jim Schaad [mailto:[email-masked]]
Sent: Monday, May 05, 2008 1:23 PM
To: Trevor Freeman; [email-masked]
Subject: RE: weak authentication issue with rfc5083

Trevor,

The same issue also occurs for AuthenticatedData in RFC 3852.  This has bee=
n known for a long time.

I am not sure how a demonstration of the KEK would solve this issue however=
.  The only way that I know to actually deal with this problem is to place =
the computed MAC under encryption for each recipient.

Jim

From: [email-masked] [mailto:[email-masked]] =
On Behalf Of Trevor Freeman
Sent: Monday, May 05, 2008 12:52 PM
To: [email-masked]
Subject: weak authentication issue with rfc5083

We have identified a potential for spoofing when using rfc5083.

Rfc5083 computes a message HMAC over the content using the authenticated en=
cryption algorithms. The message HMAC is calculated based on the content an=
d the content encryption key (CEK).

A number of allowed key management techniques derive a key encryption key (=
KEK) which can be used to authenticate the sender e.g. Static-Static Diffie=
 Hellman, Kerberos shared secret, shared password. The KEK is used to encry=
pt the CEK per recipient.

However when the integrity of the message is validated via the message HMAC=
, the sender only demonstrates knowledge of the CEK to the recipient.

Any other recipient knows the CEK so can construct another message using th=
e same CEK and compute the new HMAC and reuse the encrypted KEK data from t=
he original message. For example:

Alice sends a message to Bob and Mallet. Alice uses  different KEK's  for b=
oth Bob and Mallet to encrypt the CEK. Bob decrypts the CEK using  his KEK.=
 The message decrypts and the HMAC checks out so Bob think the message is f=
rom Alice because only Bob and Alice know the KEK.

Mallet is the recipient of the original message so he can use his KEK to le=
arn the message CEK. Mallet then  constructs a new message and encrypts it =
using the same CEK as the original message. Mallet copies Bobs  KEK recipie=
nt Info from Alice's message which contains the same encrypted CEK. Because=
 Mallet knows the CEK he can also compute the correct HMAC for the new mess=
age. Mallet sends the new message to Bob. Bob again uses his KEK to discove=
r the CEK and successfully decrypts the message and the HMAC check out so B=
ob thinks this new message is also from Alice.

This issue only applies when there are multiple recipients. The motivation =
to use the new authenticated encryption is to improve performance so soluti=
ons like bifurcating messages to use different CEK or signing the message a=
re counterproductive.

We need an additional structure to allow the sender to demonstrate knowledg=
e of both the KEK and CEK per recipient when sending to multiple recipients=
.
What is the consensus to resolve this?

We can version 5083 to document the new structure or we can do document the=
 new structure via a standalone document.

--_000_F767238E699C2E43895DDFB5F435088F0C2C06B884DFMBX61exchan_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:x=3D"urn:schemas-microsoft-com:office:excel" xmlns:p=3D"urn:schemas-m=
icrosoft-com:office:powerpoint" xmlns:a=3D"urn:schemas-microsoft-com:office=
:access" xmlns:dt=3D"uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:s=3D"=
uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" xmlns:rs=3D"urn:schemas-microsof=
t-com:rowset" xmlns:z=3D"#RowsetSchema" xmlns:b=3D"urn:schemas-microsoft-co=
m:office:publisher" xmlns:ss=3D"urn:schemas-microsoft-com:office:spreadshee=
t" xmlns:c=3D"urn:schemas-microsoft-com:office:component:spreadsheet" xmlns=
:oa=3D"urn:schemas-microsoft-com:office:activation" xmlns:html=3D"http://ww=
w.w3.org/TR/REC-html40" xmlns:q=3D"http://schemas.xmlsoap.org/soap/envelope=
/" xmlns:D=3D"DAV:" xmlns:x2=3D"http://schemas.microsoft.com/office/excel/2=
003/xml" xmlns:ois=3D"http://schemas.microsoft.com/sharepoint/soap/ois/" xm=
lns:dir=3D"http://schemas.microsoft.com/sharepoint/soap/directory/" xmlns:d=
s=3D"http://www.w3.org/2000/09/xmldsig#" xmlns:dsp=3D"http://schemas.micros=
oft.com/sharepoint/dsp" xmlns:udc=3D"http://schemas.microsoft.com/data/udc"=
 xmlns:xsd=3D"http://www.w3.org/2001/XMLSchema" xmlns:sub=3D"http://schemas=
.microsoft.com/sharepoint/soap/2002/1/alerts/" xmlns:ec=3D"http://www.w3.or=
g/2001/04/xmlenc#" xmlns:sp=3D"http://schemas.microsoft.com/sharepoint/" xm=
lns:sps=3D"http://schemas.microsoft.com/sharepoint/soap/" xmlns:xsi=3D"http=
://www.w3.org/2001/XMLSchema-instance" xmlns:udcxf=3D"http://schemas.micros=
oft.com/data/udc/xmlfile" xmlns:wf=3D"http://schemas.microsoft.com/sharepoi=
nt/soap/workflow/" xmlns:mver=3D"http://schemas.openxmlformats.org/markup-c=
ompatibility/2006" xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/o=
mml" xmlns:mrels=3D"http://schemas.openxmlformats.org/package/2006/relation=
ships" xmlns:ex12t=3D"http://schemas.microsoft.com/exchange/services/2006/t=
ypes" xmlns:ex12m=3D"http://schemas.microsoft.com/exchange/services/2006/me=
ssages" xmlns:Z=3D"urn:schemas-microsoft-com:" xmlns=3D"http://www.w3.org/T=
R/REC-html40">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 12 (filtered medium)">
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:Consolas;
	panose-1:2 11 6 9 2 2 4 3 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
	{mso-style-priority:99;
	mso-style-link:"Plain Text Char";
	margin:0in;
	margin-bottom:.0001pt;
	font-size:10.5pt;
	font-family:Consolas;}
span.PlainTextChar
	{mso-style-name:"Plain Text Char";
	mso-style-priority:99;
	mso-style-link:"Plain Text";
	font-family:Consolas;}
span.EmailStyle19
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
span.EmailStyle20
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
span.EmailStyle21
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><span style=3D'color:#1F497D'>Hi Jim,<o:p></o:p></span=
></p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'>You can demonstrate know=
ledge of
both HMAC and KEK fairly simply per recipient e.g. by concatenating the KEK
with the message HMAC and hashing the result. Since Mallet does not know th=
e KEK
they cannot compute the new hash. This fix works for both 3852 and 5083.<o:=
p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span>=
</p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'>Trevor<o:p></o:p></span>=
</p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span>=
</p>

<div>

<div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in =
0in 0in'>

<p class=3DMsoNormal><b><span style=3D'font-size:10.0pt;font-family:"Tahoma=
","sans-serif"'>From:</span></b><span
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'> Jim Schaad
[mailto:[email-masked]] <br>
<b>Sent:</b> Monday, May 05, 2008 1:23 PM<br>
<b>To:</b> Trevor Freeman; [email-masked]<br>
<b>Subject:</b> RE: weak authentication issue with rfc5083<o:p></o:p></span=
></p>

</div>

</div>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'>Trevor,<o:p></o:p></span=
></p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span>=
</p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'>The same issue also occu=
rs for
AuthenticatedData in RFC 3852.&nbsp; This has been known for a long time.<o=
:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span>=
</p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'>I am not sure how a
demonstration of the KEK would solve this issue however.&nbsp; The only way
that I know to actually deal with this problem is to place the computed MAC
under encryption for each recipient.<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span>=
</p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'>Jim<o:p></o:p></span></p=

<p class=3DMsoNormal><span style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span>=
</p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span>=
</p>

<div style=3D'border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in =
4.0pt'>

<div>

<div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in =
0in 0in'>

<p class=3DMsoNormal><b><span style=3D'font-size:10.0pt;font-family:"Tahoma=
","sans-serif"'>From:</span></b><span
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>
[email-masked] [mailto:[email-masked]] <b>On
Behalf Of </b>Trevor Freeman<br>
<b>Sent:</b> Monday, May 05, 2008 12:52 PM<br>
<b>To:</b> [email-masked]<br>
<b>Subject:</b> weak authentication issue with rfc5083<o:p></o:p></span></p=

</div>

</div>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>We have identified a potential for spoofing when using
rfc5083.<o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>Rfc5083 computes a message HMAC over the content using=
 the authenticated
encryption algorithms. The message HMAC is calculated based on the content =
and
the content encryption key (CEK). <o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>A number of allowed key management techniques derive a=
 key
encryption key (KEK) which can be used to authenticate the sender e.g.
Static-Static Diffie Hellman, Kerberos shared secret, shared password. The =
KEK
is used to encrypt the CEK per recipient.<o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>However when the integrity of the message is validated=
 via the
message HMAC, the sender only demonstrates knowledge of the CEK to the
recipient.<o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>Any other recipient knows the CEK so can construct ano=
ther
message using the same CEK and compute the new HMAC and reuse the encrypted=
 KEK
data from the original message. For example:<o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoPlainText><span style=3D'font-size:11.0pt;font-family:"Calibr=
i","sans-serif"'>Alice
sends a message to Bob and Mallet. Alice uses &nbsp;different KEK&#8217;s
&nbsp;for both Bob and Mallet to encrypt the CEK. Bob decrypts the CEK
using&nbsp; his KEK. The message decrypts and the HMAC checks out so Bob th=
ink
the message is from Alice because only Bob and Alice know the KEK.<o:p></o:=
p></span></p>

<p class=3DMsoPlainText><span style=3D'font-size:11.0pt;font-family:"Calibr=
i","sans-serif"'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoPlainText><span style=3D'font-size:11.0pt;font-family:"Calibr=
i","sans-serif"'>Mallet
is the recipient of the original message so he can use his KEK to learn the
message CEK. Mallet then &nbsp;constructs a new message and encrypts it usi=
ng
the same CEK as the original message. Mallet copies Bobs &nbsp;KEK recipien=
t
Info from Alice's message which contains the same encrypted CEK. Because Ma=
llet
knows the CEK he can also compute the correct HMAC for the new message. Mal=
let
sends the new message to Bob. Bob again uses his KEK to discover the CEK an=
d
successfully decrypts the message and the HMAC check out so Bob thinks this=
 new
message is also from Alice.<o:p></o:p></span></p>

<p class=3DMsoPlainText><span style=3D'font-size:11.0pt;font-family:"Calibr=
i","sans-serif"'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoPlainText><span style=3D'font-size:11.0pt;font-family:"Calibr=
i","sans-serif"'>This
issue only applies when there are multiple recipients. The motivation to us=
e
the new authenticated encryption is to improve performance so solutions lik=
e
bifurcating messages to use different CEK or signing the message are
counterproductive.<o:p></o:p></span></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>We need an additional structure to allow the sender to
demonstrate knowledge of both the KEK and CEK per recipient when sending to
multiple recipients.<o:p></o:p></p>

<p class=3DMsoNormal>What is the consensus to resolve this? <o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>We can version 5083 to document the new structure or w=
e can
do document the new structure via a standalone document.<o:p></o:p></p>

</div>

</div>

</body>

</html>

--_000_F767238E699C2E43895DDFB5F435088F0C2C06B884DFMBX61exchan_--

From: "Jim Schaad" <[email-masked]>
To: "'Trevor Freeman'" <[email-masked]>, <[email-masked]>
Subject: RE: weak authentication issue with rfc5083
Date: Mon, 5 May 2008 13:23:22 -0700
Sender: [email-masked]

This is a multipart message in MIME format.

------=_NextPart_000_12C9_01C8AEB3.31759E70
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Trevor,

The same issue also occurs for AuthenticatedData in RFC 3852.  This has been
known for a long time.

I am not sure how a demonstration of the KEK would solve this issue however.
The only way that I know to actually deal with this problem is to place the
computed MAC under encryption for each recipient.

Jim

From: [email-masked] [mailto:[email-masked]]
On Behalf Of Trevor Freeman
Sent: Monday, May 05, 2008 12:52 PM
To: [email-masked]
Subject: weak authentication issue with rfc5083

We have identified a potential for spoofing when using rfc5083.

Rfc5083 computes a message HMAC over the content using the authenticated
encryption algorithms. The message HMAC is calculated based on the content
and the content encryption key (CEK). 

A number of allowed key management techniques derive a key encryption key
(KEK) which can be used to authenticate the sender e.g. Static-Static Diffie
Hellman, Kerberos shared secret, shared password. The KEK is used to encrypt
the CEK per recipient.

However when the integrity of the message is validated via the message HMAC,
the sender only demonstrates knowledge of the CEK to the recipient.

Any other recipient knows the CEK so can construct another message using the
same CEK and compute the new HMAC and reuse the encrypted KEK data from the
original message. For example:

Alice sends a message to Bob and Mallet. Alice uses  different KEK's  for
both Bob and Mallet to encrypt the CEK. Bob decrypts the CEK using  his KEK.
The message decrypts and the HMAC checks out so Bob think the message is
from Alice because only Bob and Alice know the KEK.

Mallet is the recipient of the original message so he can use his KEK to
learn the message CEK. Mallet then  constructs a new message and encrypts it
using the same CEK as the original message. Mallet copies Bobs  KEK
recipient Info from Alice's message which contains the same encrypted CEK.
Because Mallet knows the CEK he can also compute the correct HMAC for the
new message. Mallet sends the new message to Bob. Bob again uses his KEK to
discover the CEK and successfully decrypts the message and the HMAC check
out so Bob thinks this new message is also from Alice.

This issue only applies when there are multiple recipients. The motivation
to use the new authenticated encryption is to improve performance so
solutions like bifurcating messages to use different CEK or signing the
message are counterproductive.

We need an additional structure to allow the sender to demonstrate knowledge
of both the KEK and CEK per recipient when sending to multiple recipients.

What is the consensus to resolve this? 

We can version 5083 to document the new structure or we can do document the
new structure via a standalone document.

------=_NextPart_000_12C9_01C8AEB3.31759E70
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 12 (filtered medium)">
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:Consolas;
	panose-1:2 11 6 9 2 2 4 3 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
	{mso-style-priority:99;
	mso-style-link:"Plain Text Char";
	margin:0in;
	margin-bottom:.0001pt;
	font-size:10.5pt;
	font-family:Consolas;}
span.PlainTextChar
	{mso-style-name:"Plain Text Char";
	mso-style-priority:99;
	mso-style-link:"Plain Text";
	font-family:Consolas;}
span.EmailStyle19
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
span.EmailStyle20
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><span =
style=3D'color:#1F497D'>Trevor,<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'>The same issue also =
occurs for
AuthenticatedData in RFC 3852.&nbsp; This has been known for a long =
time.<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'>I am not sure how a
demonstration of the KEK would solve this issue however.&nbsp; The only =
way that I
know to actually deal with this problem is to place the computed MAC =
under
encryption for each recipient.<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'color:#1F497D'>Jim<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<div style=3D'border:none;border-left:solid blue 1.5pt;padding:0in 0in =
0in 4.0pt'>

<div>

<div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt =
0in 0in 0in'>

<p class=3DMsoNormal><b><span =
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span>=
</b><span
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'> =
[email-masked]
[mailto:[email-masked]] <b>On Behalf Of </b>Trevor =
Freeman<br>
<b>Sent:</b> Monday, May 05, 2008 12:52 PM<br>
<b>To:</b> [email-masked]<br>
<b>Subject:</b> weak authentication issue with =
rfc5083<o:p></o:p></span></p>

</div>

</div>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>We have identified a potential for spoofing when =
using
rfc5083.<o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>Rfc5083 computes a message HMAC over the content =
using the
authenticated encryption algorithms. The message HMAC is calculated =
based on
the content and the content encryption key (CEK). <o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>A number of allowed key management techniques =
derive a key
encryption key (KEK) which can be used to authenticate the sender e.g.
Static-Static Diffie Hellman, Kerberos shared secret, shared password. =
The KEK
is used to encrypt the CEK per recipient.<o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>However when the integrity of the message is =
validated via
the message HMAC, the sender only demonstrates knowledge of the CEK to =
the
recipient.<o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>Any other recipient knows the CEK so can construct =
another
message using the same CEK and compute the new HMAC and reuse the =
encrypted KEK
data from the original message. For example:<o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoPlainText><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'>Alice
sends a message to Bob and Mallet. Alice uses &nbsp;different =
KEK&#8217;s &nbsp;for
both Bob and Mallet to encrypt the CEK. Bob decrypts the CEK using&nbsp; =
his
KEK. The message decrypts and the HMAC checks out so Bob think the =
message is
from Alice because only Bob and Alice know the =
KEK.<o:p></o:p></span></p>

<p class=3DMsoPlainText><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'><o:p>&nbsp;=
</o:p></span></p>

<p class=3DMsoPlainText><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'>Mallet
is the recipient of the original message so he can use his KEK to learn =
the
message CEK. Mallet then &nbsp;constructs a new message and encrypts it =
using
the same CEK as the original message. Mallet copies Bobs &nbsp;KEK =
recipient
Info from Alice's message which contains the same encrypted CEK. Because =
Mallet
knows the CEK he can also compute the correct HMAC for the new message. =
Mallet
sends the new message to Bob. Bob again uses his KEK to discover the CEK =
and
successfully decrypts the message and the HMAC check out so Bob thinks =
this new
message is also from Alice.<o:p></o:p></span></p>

<p class=3DMsoPlainText><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'><o:p>&nbsp;=
</o:p></span></p>

<p class=3DMsoPlainText><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'>This
issue only applies when there are multiple recipients. The motivation to =
use
the new authenticated encryption is to improve performance so solutions =
like
bifurcating messages to use different CEK or signing the message are
counterproductive.<o:p></o:p></span></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>We need an additional structure to allow the sender =
to
demonstrate knowledge of both the KEK and CEK per recipient when sending =
to
multiple recipients.<o:p></o:p></p>

<p class=3DMsoNormal>What is the consensus to resolve this? =
<o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>We can version 5083 to document the new structure =
or we can
do document the new structure via a standalone document.<o:p></o:p></p>

</div>

</div>

</body>

</html>

------=_NextPart_000_12C9_01C8AEB3.31759E70--

From: "Tony Capel" <[email-masked]>
To: "'Paul Hoffman'" <[email-masked]>, "'Turner, Sean P.'" <[email-masked]>, <[email-masked]>
Subject: RE: S/MIME v3.2  IDs key size text
Date: Mon, 5 May 2008 16:08:35 -0400
Importance: Normal
Sender: [email-masked]

All:

I agree that deleting " namely 1024 bits" from the first sentence of the
proposed security considerations section paragraph is good.  The second =
"1024"
in the proposed paragraph is not a problem for me since it is not =
"normative".

With respect to section 4.1 (Key Pair Generation).  Is it intended to =
change the
title of this section?  The second paragraph of the current text in
3851bis-01.txt begins "If an S/MIME agent needs to generate ...".  So if =
the
S/MIME agent does NOT need to generate keys (and this is typically the =
case,
most enrollment & key generation are done externally to messaging =
clients) the
balance of this paragraph (which mentions the key sizes) is not =
normative (as
currently drafted - its quite possible that the last sentence of this =
paragraph
should have been in a separate paragraph).  Key generation requirements =
are
normally (hopefully!) cited in the corresponding CP, where things such =
as
required key sizes, where they are generated (locally or at the CA), =
FIPS-140
Level, etc. should be (!!) explicitly identified.  Maybe the second =
paragraph of
4.1 could be replaced with a simple statement:

"If an S/MIME agent needs to generate one or more key pairs, each SHOULD =
be
generated according to the corresponding certificate policy, refer for =
example
to [RFC3647]."

The proposed text, and the discussion so far, is really speaking about =
"what
range of RSA key sizes" needs to be supported.  We are NOT providing =
security
advice, we are just trying to ensure that most smime v3.2 =
implementations will
interwork in the typical environments expected "in the wild" (and =
special
environments will be understood by purchasers anyway, so we likely need =
not
worry about high security applications - only the general "public"
environments).=20

A similar issue is already addressed in CERT v3.2 (
draft-ietf-smime-3850bis-01.txt ) in Section 4.3 for certificate  =
validation.
We might consider copying the last sentence of CERT v3.2 Sec 4.3 to the =
end of
sections 2.2 and 2.3 (just before the Notes):

   "Key sizes from 1024 bits to 2048 bits MUST be supported."=20

This would also have the advantage of aligning CERT and MSG.

Tony

| -----Original Message-----
| From: [email-masked]=20
| [mailto:[email-masked]] On Behalf Of Paul Hoffman
| Sent: May 3, 2008 10:08 PM
| To: Turner, Sean P.; [email-masked]
| Subject: RE: S/MIME v3.2 IDs key size text
|=20
|=20
|=20
| At 8:51 PM -0400 5/3/08, Turner, Sean P. wrote:
| >I think if we struck ", namely 1024 bits" from the text in=20
| the security=20
| >considerations that it's still a true statement and we won't have to=20
| >change it every time we update the spec.
|=20
| I'm OK with that, but I also feel that if we're updating the minimum=20
| mandatory signing length, it is trivial to update the Security=20
| Considerations as well.
|=20

From: Trevor Freeman <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Mon, 5 May 2008 19:52:08 +0000
Subject: weak authentication issue with rfc5083
Accept-Language: en-US
Sender: [email-masked]

--_000_F767238E699C2E43895DDFB5F435088F0C2C06204ADFMBX61exchan_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

We have identified a potential for spoofing when using rfc5083.

Rfc5083 computes a message HMAC over the content using the authenticated en=
cryption algorithms. The message HMAC is calculated based on the content an=
d the content encryption key (CEK).

A number of allowed key management techniques derive a key encryption key (=
KEK) which can be used to authenticate the sender e.g. Static-Static Diffie=
 Hellman, Kerberos shared secret, shared password. The KEK is used to encry=
pt the CEK per recipient.

However when the integrity of the message is validated via the message HMAC=
, the sender only demonstrates knowledge of the CEK to the recipient.

Any other recipient knows the CEK so can construct another message using th=
e same CEK and compute the new HMAC and reuse the encrypted KEK data from t=
he original message. For example:

Alice sends a message to Bob and Mallet. Alice uses  different KEK's  for b=
oth Bob and Mallet to encrypt the CEK. Bob decrypts the CEK using  his KEK.=
 The message decrypts and the HMAC checks out so Bob think the message is f=
rom Alice because only Bob and Alice know the KEK.

Mallet is the recipient of the original message so he can use his KEK to le=
arn the message CEK. Mallet then  constructs a new message and encrypts it =
using the same CEK as the original message. Mallet copies Bobs  KEK recipie=
nt Info from Alice's message which contains the same encrypted CEK. Because=
 Mallet knows the CEK he can also compute the correct HMAC for the new mess=
age. Mallet sends the new message to Bob. Bob again uses his KEK to discove=
r the CEK and successfully decrypts the message and the HMAC check out so B=
ob thinks this new message is also from Alice.

This issue only applies when there are multiple recipients. The motivation =
to use the new authenticated encryption is to improve performance so soluti=
ons like bifurcating messages to use different CEK or signing the message a=
re counterproductive.

We need an additional structure to allow the sender to demonstrate knowledg=
e of both the KEK and CEK per recipient when sending to multiple recipients=
.
What is the consensus to resolve this?

We can version 5083 to document the new structure or we can do document the=
 new structure via a standalone document.

--_000_F767238E699C2E43895DDFB5F435088F0C2C06204ADFMBX61exchan_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 12 (filtered medium)">
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Consolas;
	panose-1:2 11 6 9 2 2 4 3 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
	{mso-style-priority:99;
	mso-style-link:"Plain Text Char";
	margin:0in;
	margin-bottom:.0001pt;
	font-size:10.5pt;
	font-family:Consolas;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
span.PlainTextChar
	{mso-style-name:"Plain Text Char";
	mso-style-priority:99;
	mso-style-link:"Plain Text";
	font-family:Consolas;}
.MsoChpDefault
	{mso-style-type:export-only;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal>We have identified a potential for spoofing when using
rfc5083.<o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>Rfc5083 computes a message HMAC over the content using=
 the authenticated
encryption algorithms. The message HMAC is calculated based on the content =
and
the content encryption key (CEK). <o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>A number of allowed key management techniques derive a=
 key encryption
key (KEK) which can be used to authenticate the sender e.g. Static-Static
Diffie Hellman, Kerberos shared secret, shared password. The KEK is used to=
 encrypt
the CEK per recipient.<o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>However when the integrity of the message is validated=
 via the
message HMAC, the sender only demonstrates knowledge of the CEK to the
recipient.<o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>Any other recipient knows the CEK so can construct ano=
ther message
using the same CEK and compute the new HMAC and reuse the encrypted KEK dat=
a from
the original message. For example:<o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoPlainText><span style=3D'font-size:11.0pt;font-family:"Calibr=
i","sans-serif"'>Alice
sends a message to Bob and Mallet. Alice uses &nbsp;different KEK&#8217;s &=
nbsp;for
both Bob and Mallet to encrypt the CEK. Bob decrypts the CEK using&nbsp; hi=
s KEK.
The message decrypts and the HMAC checks out so Bob think the message is fr=
om
Alice because only Bob and Alice know the KEK.<o:p></o:p></span></p>

<p class=3DMsoPlainText><span style=3D'font-size:11.0pt;font-family:"Calibr=
i","sans-serif"'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoPlainText><span style=3D'font-size:11.0pt;font-family:"Calibr=
i","sans-serif"'>Mallet
is the recipient of the original message so he can use his KEK to learn the
message CEK. Mallet then &nbsp;constructs a new message and encrypts it usi=
ng
the same CEK as the original message. Mallet copies Bobs &nbsp;KEK recipien=
t
Info from Alice's message which contains the same encrypted CEK. Because Ma=
llet
knows the CEK he can also compute the correct HMAC for the new message. Mal=
let
sends the new message to Bob. Bob again uses his KEK to discover the CEK an=
d
successfully decrypts the message and the HMAC check out so Bob thinks this=
 new
message is also from Alice.<o:p></o:p></span></p>

<p class=3DMsoPlainText><span style=3D'font-size:11.0pt;font-family:"Calibr=
i","sans-serif"'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoPlainText><span style=3D'font-size:11.0pt;font-family:"Calibr=
i","sans-serif"'>This
issue only applies when there are multiple recipients. The motivation to us=
e the
new authenticated encryption is to improve performance so solutions like bi=
furcating
messages to use different CEK or signing the message are counterproductive.=
<o:p></o:p></span></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>We need an additional structure to allow the sender to=
 demonstrate
knowledge of both the KEK and CEK per recipient when sending to multiple re=
cipients.<o:p></o:p></p>

<p class=3DMsoNormal>What is the consensus to resolve this? <o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>We can version 5083 to document the new structure or w=
e can
do document the new structure via a standalone document.<o:p></o:p></p>

</div>

</body>

</html>

--_000_F767238E699C2E43895DDFB5F435088F0C2C06204ADFMBX61exchan_--

From: Luther Martin <[email-masked]>
To: "'Paul Hoffman'" <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Sun, 4 May 2008 11:49:29 -0700
Subject: RE: S/MIME v3.2  IDs key size text (resend, this time not opaque signed with 2k key)
Accept-Language: en-US
acceptlanguage: en-US
Sender: [email-masked]

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]=
]
> On Behalf Of Paul Hoffman
> Sent: Saturday, May 03, 2008 12:11 PM
> To: [email-masked]
> Subject: RE: S/MIME v3.2 IDs key size text (resend, this time not opaque
> signed with 2k key)

> Our task is to create a standard that is usable by as many people as
> possible while at the same time as setting some minimum operational
> security expectations. For interoperability, we need to say "you can
> verify signatures created following this spec". For minimum
> operational security, we have to pick a size that is reasonable for
> the vast majority of users while encouraging software developers to
> support all reasonable sizes.
>
> Please read RFC 3766. If you believe that the numbers in there are
> wrong, by all means let the IETF community know. If you believe that
> the numbers there are right but you still think that a typical user
> needs more than 75 bits of symmetric strength for their signatures,
> even though no one has ever done that much effort for even a single
> attack in public, please say why.

These are interesting points.

I believe that the vast majority of users are actually either at government=
 agencies or financial institutions. The government guys need FIPS 140-2, w=
hich is fairly clear about requiring bigger keys (actually the SP that the =
IG refers to is), and the FI people need to follow the ANSI X9 recommendati=
ons. Both of these require the use of 2K keys Really Soon. Because of this,=
 I believe that making things reasonable for the vast majority of users mea=
ns requiring the support for 2K keys ASAP.

I'd also say that what RFC 3766 says is totally irrelevant. The people who =
rely on cryptography are the ones that say what an acceptable level of risk=
 is. In the case of FIs who rely on X9 standards, this means using keys tha=
t are fairly big, and may be bigger that RFC 3766 describes. In the case of=
 government users, this is defined by NIST in SP 800-57.

>From the point of view of a cryptographer, the key sizes that they require =
may seem a bit big, but then the cryptographers aren't the ones dealing wit=
h trillions of dollars of risk, either.

From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked], [email-masked]
Subject: RE: S/MIME v3.2  IDs key size text
Date: Sun, 04 May 2008 19:57:46 +1200
Sender: [email-masked]

Paul Hoffman <[email-masked]> writes:
>At 4:56 PM +1200 5/3/08, Peter Gutmann wrote:
>>  >>(The "or shorter" attached to the "1024" is also going to prove problematic
>>>>with FIPS-evaluated crypto implementations, since you can't do < 1024 bits
>>>>for those).
>>>
>>>That's just plain wrong. Nothing in the FIPS evaluation says that you cannot
>>>verify signatures shorter than what they require.
>>
>>I didn't say you couldn't verify sigs, I said you couldn't get the code to do
>>that evaluated because the minimum they'll accept is 1024 bits.  In other
>>words you'd be using non-evaluated code (or code run in a non-evaluated mode)
>>to do the sig. verification.
>
>I admit that I haven't gone through a FIPS evaluation myself, but what you
>say seems wrong.

I've gone through several, and talked to numerous others who have as well.
It's the usual crapshoot, some labs will allow < 1024-bit keys and some won't.
For my own code I've had one lab pass 512-bit keys OK and another one say that
any ability to use keys of less than 1024 bits would mean it couldn't be
evaluated.  In another, more amusing case reported to me by someone else, they
got one lab to OK it at 512 bits, then a second lab required them to submit
paperwork showing that they blocked all keys of less than 1024 bits, and after
they did that the first lab complained that they were failing their tests on
512-bit keys.  In the end they just declared that their product didn't support
any keys less than 1024 bits and everything was OK.

>If someone from NIST or from a test lab wants to chime in here, that would be
>grand.

What really matters is what the labs in sum total enforce, not what NIST
thinks or what one individual lab does.  As the above examples show, you can
jury-shop your lab to get 512-bit keys passed if you like, but it only works
in some cases and to be safe you need to use a minimum key size of 1024 bits.

Peter.

Date: Sat, 3 May 2008 19:08:13 -0700
To: "Turner, Sean P." <[email-masked]>, <[email-masked]>
From: Paul Hoffman <[email-masked]>
Subject: RE: S/MIME v3.2  IDs key size text
Sender: [email-masked]

At 8:51 PM -0400 5/3/08, Turner, Sean P. wrote:
>I think if we struck ", namely 1024 bits" from the text in the security
>considerations that it's still a true statement and we won't have to change
>it every time we update the spec.

I'm OK with that, but I also feel that if we're updating the minimum 
mandatory signing length, it is trivial to update the Security 
Considerations as well.

From: "Turner, Sean P." <[email-masked]>
To: <[email-masked]>
Subject: RE: S/MIME v3.2  IDs key size text
Date: Sat, 3 May 2008 20:51:28 -0400
Organization: IECA, Inc.
Sender: [email-masked]

I think if we struck ", namely 1024 bits" from the text in the security
considerations that it's still a true statement and we won't have to change
it every time we update the spec.

spt 

>-----Original Message-----
>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of Paul Hoffman
>Sent: Friday, May 02, 2008 5:44 PM
>To: [email-masked]
>Subject: RE: S/MIME v3.2 IDs key size text
>
>
>At 6:16 AM +1200 5/3/08, Peter Gutmann wrote:
>>"Turner, Sean P." <[email-masked]> writes:
>>
>>>A receiving agent needs to be able to verify signatures whose key 
>>>length is chosen by the signer. For interoperability, a receiving 
>>>agent MUST be able to verify signatures whose key length is 
>1024 bits or shorter.
>>
>>[...]
>>
>>>Receiving agents are only required to validate signatures 
>that are the 
>>>same length as sending agents are required to produce, 
>namely 1024 bits.
>>
>>Aren't these mutually exclusive?
>
>Yes; that's why they are in separate sections.
>
>>(The "or shorter" attached to the "1024" is also going to prove 
>>problematic with FIPS-evaluated crypto implementations, since 
>you can't 
>>do < 1024 bits for those).
>
>That's just plain wrong. Nothing in the FIPS evaluation says 
>that you cannot verify signatures shorter than what they require.
>

From: "Jim Schaad" <[email-masked]>
To: "'Turner, Sean P.'" <[email-masked]>, "'Ietf-Smime'" <[email-masked]>
Subject: RE: New ASN.1 modules comments/questions
Date: Sat, 3 May 2008 15:52:19 -0700
Sender: [email-masked]

Sean,

Sorry for the delay in getting back to you.  I had some work that needed to
get finished.

Jim

> -----Original Message-----
> From: [email-masked] [mailto:owner-ietf-
> [email-masked]] On Behalf Of Turner, Sean P.
> Sent: Monday, April 21, 2008 9:18 AM
> To: 'Ietf-Smime'
> Subject: New ASN.1 modules comments/questions
> 
> 
> Jim and Paul,
> 
> Here are some comments/questions on the ASN.1 modules.
> 
> spt
> 
> -------------------
> 
> The definitions of AlgorithmIdentifier in the PKIX and SMIME modules
> are
> different - is there a reason for the difference? Does it matter? In
> PKIX
> it's AlgorithmSet, in SMIME it's InfoObjectSet, in RFC2976 it's IOSet,
> in
> ANSI X9 docs it's also IOSet, and in X.509 it's SupportedAlgorithms. If
> it
> matters, then I guess I lean towards what's in RFC2976 since it's
> already in
> an RFC.

There is no effective difference between the two definitions.  The two
differences are 1) the name of a parameter and 2) comments.  The name of the
parameter makes no difference.  Just as the name of a parameter makes no
difference if you are writing a C function.  The same is true for comments.

> 
> -------------------
> 
> In the 3370 section,
> 
>  1. Shouldn't AlgorithmIdentifier be imported from the PKIX module?

Long term, AlgorithmIdentifier will be imported from the new Algorithm
Information module.  So this should become moot.

> 
>  2. You used alg- as tag for hash algs, sig- for signature algs, kea-
> for
> key agreement algs, alg- for symmetric key encryption algs.  I think it
> might be easier to figure out which algs go where if the tag matches
> the
> type of algorithm like mda- for MessageDigestAlgorithms, sa- for
> SignatureAlgorithms, and kaa- for KeyAgreementAlgorithms.

Thanks for suggesting some potential tags to be used.  I agree that we need
some short simple notation to mark the different types of algorithm objects.

> 
>  3. Could we change SymmetricKeyEncryptionAlgorithms to just
> KeyWrapAlgorithms and use kwa- as the tag? There's also a
> KeyWrapAlgorithm
> that I think is supposed to be the same as the
> SymmetricKeyEncryptionAlgorithms so one or the other can get deleted
> (if you
> delete the later change SupportKeyWrapAlgorithms to KeyWrapAlgorithms)?

I have no problems with this change.  There is a minor question here about
doing a good job of distinguishing Key Wrap Algorithms and Key Transport
Algorithms.  

I added the Symmetric to the front to distinguish from Key Transport
algorithms which, as the KEA algorithm suggest, can also be thought of as
Key Encryption algorithms.    The use of Key Wrap might be sufficient to
distinguish between them, but CMS uses Key Encryption as the name of these
types of algorithms.

Which is a better way to go?

> 
>  4. Shouldn't SymmetricKeyEncryptionAlgorithms be extensible?
> 

Welcome to a long philosophical discussion.

There are two different places where this extensibility can be placed.  The
two different locations imply different things.  This means that depending
on how you look at things this should or should not be extensible.

If you place the extensibility here, you are saying that we think that this
document is going to be updated, and that we are going to add new algorithms
to this document.  

Alternatively, if you place the extensibility in CMS, you are saying that we
are going to define new algorithms by creating new documents with new
modules and they should be "imported" into the CMS document in one manner or
another. 

The compiler that we are working on has a planned directive to allow for an
object to be added to an extensible object set.  Part of the question at
this point would be as follows.  Where should the new algorithm be added, in
this document - thus potentially effecting more than just CMS - or in CMS
thus limiting where the changes are set.

My personal beliefs are:
- 1.  New algorithms should be added by creating new documents not by
updating this document
- 2.  Changes in algorithm sets should be as narrow as possible - thus the
updates should be done in CMS not here. 

The upshot of this is that I believe this object set is NOT extensible, but
the corresponding one in CMS should be extensible.

>  5. Do we need to add a MessageAuthenticationCodeAlgorithms for the
> hmac
> alg? Then we could use maca- in front of the hMAC-SHA1.

I have no issues with this.

> 
>  6. Some of the IOSets are {...} (like SignatureAlgorithms) while
> others
> lists algorithms (like MessageDigestAlgorithms) - shouldn't all of them
> list
> algorithms or none?

This has to do with the fact that the module updates are not finished, but
the symbols needed to be defined for different reasons.  These will become
closed sets with the appropriate algorithm objects in them.

> 
> -------------------
> 
> In the 3565 section, I think the algorithms need to be defined using
> the new
> syntax, import ALGORITHM, and define the algs as follows:
> 
>   ContentEncryptionAlgorithms ALGORITHM ::= {
>      cea-aes128-cbc   |
>      cea-aes192-cbc   |
>      cea-aes256-cbc,
>      ... -- Extensible
>      }
> 
>    cea-aes128-cbc ALGORITHM ::= {
>      OID id-aes128-CBC PARMS AES-IV }
> 
>    cea-aes192-cbc ALGORITHM ::= {
>      OID id-aes192-CBC PARMS AES-IV }
> 
>    cea-aes256-cbc ALGORITHM ::= {
>      OID id-aes256-CBC PARMS AES-IV }
> 
>   KeyWrapAlgorithms ALGORITHM ::= {
>      kwa-aes128 |
>      kwa-aes192 |
>      kwa-aes256,
>      ... -- Extensible
>    }
> 
>    kwa-aes128 ALGORITHM ::= {
>      OID id-aes128-wrap PARMS ABSENT }
> 
>    kwa-aes192 ALGORITHM ::= {
>      OID id-aes192-wrap PARMS ABSENT }
> 
>    kwa-aes256 ALGORITHM ::= {
>      OID id-aes256-wrap PARMS ABSENT }
> 

Module has not be updated to reflect what is going on in modules.  I was
waiting to get the Algorithm Information module finished first.

> -------------------
> 
> In the 3851 section, shouldn't SMimeAttributeSet be extensible? r/{
> attr-smimeCapabilities | attr-encrypKeyPref }/{ attr-smimeCapabilities
> |
> attr-encrypKeyPref, ... }

See discussion above about whether we think we are going to add new
attributes to a future version of this document.

> 
> -------------------
> 
> In the 3852 section,
> 
>  1. OID for PKIX1 module doesn't match the new PKIX asn ID OID - I
> think it
> should be id-pkix-explict(19) instead of (18).

First, at some point we are going to replace all of the module numbers.  We
have just not yet gotten to that point.  Based on the documents that I
looked at, the explicit module is 18.

> 
>  2. Are you going to remove the version notations [[3:, [[4:, etc?

It is my belief that having the version tags included adds information to
the ASN.1 module.  Thus I plan on keeping them unless I get some large
objections.

> 
>  3. For consistency with 3370, can we change DigestAlgorithmList to
> MessageDigestAlgorithms?

I don't want these to have the same names.  In the long run we will do the
following:
    DigestAlgorithmList ALGORITHM ::= {MessageDigestAlgorithms,...}

However I am open to the following:
-  We create a standardized but descriptive method of naming the sets of
algorithms defined in a module - thus in 3370 we might say
	CMSAlgs-MessageDigestAlgorithm

- Do the suggested re-name here.

> 
>  4. For consistency, can we change UnsigedAttributes to
> UnsignedAttributesSet and UnprotectedAttributes to
> UnprotectedAttribuesSet?

No problems

> 
>  5. In AuthenticatedData, SupportedAttributes is used in AuthAttributes
> and
> UnauthAttributes. In AuthAttributes, can we change SupportAttributes to
> AuthAttributesSet and in UnauthAttributes can we change
> SupportedAttributes
> to UnauthAttributesSet?

No problems

> 
>  6. For consistency with the 3370 section, can we change
> SignatureAlgorithmList to SignatureAlgorithms, DigestAlgorithmList to
> MessageDigestAlgorithms, KeyAgreementAlgorithmList to
> KeyAgreementAlgorithms, and ContentEncryptionAlgorithmLists to
> ContentEncryptionAlgorithms?

See above note

> 
>  7. Can we change KeyDerivationAlgorithmIdentifier to use
> KeyDerivationAlgorithms instead of AlgorithmList?

Yes this should be done.

> 
>  8. Can we change MessageAuthenticationCodeAlgorithm to use
> MessageAuthenticationCodeAlgorithms instead of AlgorithmList?
> 

Yes this should be done

>  9. Don't we want to define an OriginatorPKAlgorithms instead of using
> AlgorithmList in OriginatorPublicKey:
> 
>        OriginatorPublicKey ::= SEQUENCE {
>          algorithm AlgorithmIdentifier {{OriginatorPKAlgorithms}},
>          publicKey BIT STRING
>        }
> 
>        OriginatorPKAlgorithms ALGORITHM ::= {
>          ... -- Extensible
>        }
> 

Yes this should be done in the end.

>  10. For consistency, can we change KeyEncryptionAlgorithmList to be
> KeyEncryptionAlgorithms?

The above note about matching the name in 3370 needs to be taken into
account.  I used List (but could have used Set) but I am not wedded to this.
I worry about using an 's' at the end as this could be a sequence of
algorithms as well.  There exists a potential confusion in the future.

> 
> -------------------
> 
> In the 4108 section, can we make FirwareContentTypes and
> FirmwareSignedAttrs
> extensible?

See discussion on the question - do we think this module will be updated in
the future.

> 
> -------------------
> 
> In the 4998 section,
> 
>  1. Shouldn't we constrain the digestAlgorithms and digestAlgorithm?

Probably - this is actually not a CMS module.  I was waiting to figure out
how algorithms are actually done first

> 
>  2. Should the import for Attribute come from PKIX or RFC3852 update
> module?

This has been moved to the PKIX-COMMON module

> 
>  3. Why is Extensions and EXTENSION imported?

To use a single standardized version, as with Attribute

> 
> -------------------
> 
> In the 5035 section,
> 
>  1. Why is Extensions and EXTENSION imported?
> 

See above

>  2. Should the import for Attribute come from PKIX or RFC3852 update
> module?
>

See above

>  3. OID for PKIX1 module doesn't match the new PKIX asn ID OID - I
> think it
> should be id-pkix-explict(19) instead of (18).
> 

See above note

>  4. Should EssSignedAttributes be SignedAttributes? Should it also be
> extensible?
> 

See both above philosophy discussion and discussions on naming of items

>  5. Should EssContentTypes be just ContentSet?
> 

Same as above.

>  6. Is the note about the identical SecurityCategories encoding
> required
> anymore?

I have no opinion one way or the other on this.  Being conservative says it
stays.

> 
>  7. Shouldn't we say HashAlgorithms ::= MessageDigestAlgorithms instead
> of
> HashAlgorithms ::= AlgorithmIdentifier {{...}}?

Yes it should - it also needs to import it - which is a new module.

> 
>  8. Shouldn't we import the shaa256 alg?
>

Yes - it would be wise - I did not do it originally so that I did not import
a new module.
 
> -------------------
> 
> In the 5084 section, we should import ALGORITHM from PKIX and define
> the
> algorithms as follows:
> 
>    ContentEncryptionAlgorithms ALGORITHM ::= {
>      cea-aes128-ccm   |
>      cea-aes192-ccm   |
>      cea-aes256-ccm   |
>      cea-aes128-gcm   |
>      cea-aes128-gcm   |
>      cea-aes128-gcm,
>      ... -- Extensible
>      }
> 
>    cea-aes128-ccm ALGORITHM ::= {
>      OID id-aes128-CCM PARMS CCMParameters }
> 
>    cea-aes192-ccm ALGORITHM ::= {
>      OID id-aes192-CCM PARMS CCMParameters }
> 
>    cea-aes256-ccm ALGORITHM ::= {
>      OID id-aes256-CCM PARMS CCMParameters }
> 
>    cea-aes128-gcm ALGORITHM ::= {
>      OID id-aes128-GCM PARMS GCMParameters }
> 
>    cea-aes192-gcm ALGORITHM ::= {
>      OID id-aes192-GCM PARMS GCMParameters }
> 
>    cea-aes256-gcm ALGORITHM ::= {
>      OID id-aes256-GCM PARMS GCMParameters }

This is waiting on the new Algoirthm Information module.

Date: Sat, 3 May 2008 12:11:20 -0700
To: <[email-masked]>
From: Paul Hoffman <[email-masked]>
Subject: RE: S/MIME v3.2  IDs key size text (resend, this time not opaque signed with 2k key)
Sender: [email-masked]

At 2:49 PM -0400 5/3/08, Tony Capel wrote:
>1A) Both signing and verifying.
>
>Verisign has been issuing both 1k and 2k single keypair certs for some
>time, 2k is becoming common in many product specifications and recommended
>by many reputable authorities.

How is this relevant to the discussion thread? There are lots of 
communities that use (and even require) higher security than what is 
in the current spec. For example, the US Department of Defense is now 
mandating the use of elliptic curve cryptography for digital 
signatures. Using them as the base, instead of VeriSign, we would 
have a mandatory-to-implement requirement for ECC. I do not imagine 
you would support that, so I don't see why picking one product (the 
2K certs) from one vendor should affect our decision for the 
mandatory-to-implement requirements as long as we make it clear that 
it is likely that any application will probably want to do more than 
that.

>So if we wish to guarantee a minimum level of "out-of-the-box"
>interoperability from a box which has a simplistic specification
>"compliant to smime v3.2"; then we should include a mandate for 2k and
>lower support for all operations to meet today's requirement.

This completely confuses mandatory-to-implement and optional. 
VeriSign uses one of the options available to them, namely longer key 
sizes. They also use the mandatory-to-implement size, and they still 
distribute their own certificates using much-lower-than-mandatory 
sizes. None of that is relevant to anyone other than VeriSign and 
their customers.

Our task is to create a standard that is usable by as many people as 
possible while at the same time as setting some minimum operational 
security expectations. For interoperability, we need to say "you can 
verify signatures created following this spec". For minimum 
operational security, we have to pick a size that is reasonable for 
the vast majority of users while encouraging software developers to 
support all reasonable sizes.

Please read RFC 3766. If you believe that the numbers in there are 
wrong, by all means let the IETF community know. If you believe that 
the numbers there are right but you still think that a typical user 
needs more than 75 bits of symmetric strength for their signatures, 
even though no one has ever done that much effort for even a single 
attack in public, please say why.

From: "Tony Capel" <[email-masked]>
To: "'Paul Hoffman'" <[email-masked]>, <[email-masked]>
Subject: RE: S/MIME v3.2  IDs key size text (resend, this time not opaque signed with 2k key)
Date: Sat, 3 May 2008 14:49:57 -0400
Importance: Normal
Sender: [email-masked]

Paul:

1A) Both signing and verifying.

Verisign has been issuing both 1k and 2k single keypair certs for some
time, 2k is becoming common in many product specifications and recommended
by many reputable authorities.

I communicate today within a community of 2k and lower certificate holders
not 1K and lower holders.  I have a 2k "off-the-shelf" cert from Verisign,
I cannot generate 1k signatures, so anyone I send to must be able to
verify 2k signatures.  So verify 2k support is required today.  It is true
that users who only intend to use 1k certs could get away with software
which cannot sign using 2k keys; but I think this is a pretty subtle
detail which would be lost in the noise of most specifications.

1B) And encryption and decryption as well.

Furthermore, since those Versign certs are single keypair, I need 2k
encrypt/decrypt since obviously the same keypair is used.  Those using
multiple keypair infrastructures with separate signing and encryption
certs could use differing sizes, but in my experience the infrastructures
themselves tend to have the same specification for both sign and encrypt
(sign/verify and decrypt/encrypt).

For encryption of course the keysize is specified by the destination cert;
so if anyone in my community has 2k keys, I must be able to encrypt with
2k keys.  So encrypt support for 2k keys is required today.  Again, 1k
only support for decryption would be lost in the noise.

So if we wish to guarantee a minimum level of "out-of-the-box"
interoperability from a box which has a simplistic specification
"compliant to smime v3.2"; then we should include a mandate for 2k and
lower support for all operations to meet today's requirement.

2) Support beyond the mandatory.

I agree that support beyond 2k should be optional.  I am sorry I misused
the word "SHOULD", I operate in several standardization arenas and rfc2119
is not a universal standard!!  I meant OPTIONAL or MAY for the larger
sizes.

The reason for my identifying the specific 3k and 4k values was an attempt
to address an earlier thread where 4k and larger keysizes were proposed -
which led to a discussion of denial of service attacks by senders
specifying large keysizes - and then this led to comments about improper
modulus selection, etc. etc....

The origin of the earlier thread was concern about leaving larger keysizes
completely open (even as OPTIONAL). I prefer to leave this issue, if it
remains an issue, to Peter and the others who contributed to that thread.
(I would just note that in my reading 3k and 4k certs are mentioned, but
it is not clear to me that there is a future beyond 4k RSA with
competition from other algorithms.)

Tony

| -----Original Message-----
| From: [email-masked] 
| [mailto:[email-masked]] On Behalf Of Paul Hoffman
| Sent: May 2, 2008 5:44 PM
| To: [email-masked]
| Subject: RE: S/MIME v3.2 IDs key size text
| 
| 
| 
| At 2:35 PM -0400 5/2/08, Tony Capel wrote:
| >I think the minimum supported size needs to be 2048 because:
| 
| Please be more specific. Supported for what? Signing, 
| verifying, or both?
| 
| >1) Since at least April 2007 (over a year ago) Verisign has been 
| >issuing certs with 2048 keys (I believe this is selectable when 
| >enrolling) (although the root cert is only 1024!).
| >2) NIST is recommending 2048 by end of 2008 for signatures and key 
| >transport for
| >some apps [SP-800-78-1 Table 3.1].
| >3) Many/most hardware tokens (e.g. Safenet, Gem, Aladdin) 
| are supporting 1024
| >and 2048 (only).
| 
| The wording clearly says that you should expect to validate larger 
| keys, which are covered by those three data points.
| 
| Your last point (hardware tokens signing at 1024) is exactly why I 
| think mandating the ability to sign at least 1024 bits is a good idea.
| 
| >As far as going larger than 2048, in my brief survey, while there
| >appears to be
| >a small level of interest in 3072 (and even 4096), beyond that many 
| >appear to be
| >recommending a switch to ECC because of the exponentially rising 
| >power/cpu costs
| >for larger RSA sizes (e.g. NSA Suite B).
| 
| The current text encourages being able to verify at any level, not 
| just 1024 or even 2048.
| 
| >So I would suggest making 2048 and smaller mandatory. And using a
| >sentence like:
| >" Note that receiving agents may see signatures whose key length is 
| >longer than
| >2048
| >  bits in the future, and support for lengths of 3072 and 
| 4078 SHOULD 
| >be provided
| >
| >  to verify those signatures."
| 
| I fully disagree. We are talking about interoperability here, not 
| best practice. We should not be mandating that receivers be able to 
| verify things that beyond what is mandated for signers. If you want 
| to change the length of what signers are required to do, that's fine, 
| I would want both sides to be accordance. But until then, saying "you 
| must be able to verify something larger than what you can sign" 
| doesn't make sense from an interoperability standpoint.
| 
| Also, we should not mandate SHOULD-level requirements for particular 
| size keys. For verification, specific bit-lengths are not important: 
| it is the maximum key length.
| 
| >Or
| >
| >  "... for lengths up to and including 4078 SHOULD ..."
| >
| >to address optional support.
| 
| This doesn't seem to be a good reading of RFC 2119.
| 

From: "Tony Capel" <[email-masked]>
To: "'Paul Hoffman'" <[email-masked]>, <[email-masked]>
Subject: RE: S/MIME v3.2  IDs key size text
Date: Sat, 3 May 2008 14:08:38 -0400
Importance: Normal
Sender: [email-masked]

Date: Sat, 3 May 2008 08:49:25 -0700
To: [email-masked] (Peter Gutmann), [email-masked]
From: Paul Hoffman <[email-masked]>
Subject: RE: S/MIME v3.2  IDs key size text
Sender: [email-masked]

At 4:56 PM +1200 5/3/08, Peter Gutmann wrote:
>How does this reconcile them?  Do we get to choose which ones we want?

You follow the MUST, not the "if you care about doing things 
flexibly, you also do this". This is the same as for almost any IETF 
standard.

>  >>(The "or shorter" attached to the "1024" is also going to prove problematic
>>>with FIPS-evaluated crypto implementations, since you can't do < 1024 bits
>>>for those).
>>
>>That's just plain wrong. Nothing in the FIPS evaluation says that you cannot
>>verify signatures shorter than what they require.
>
>I didn't say you couldn't verify sigs, I said you couldn't get the code to do
>that evaluated because the minimum they'll accept is 1024 bits.  In other
>words you'd be using non-evaluated code (or code run in a non-evaluated mode)
>to do the sig. verification.

I admit that I haven't gone through a FIPS evaluation myself, but 
what you say seems wrong. .I assume that verifying code does not have 
different code paths for different sizes of keys being verified, so 
the evaluated code works for the mandated sizes and others. Even if 
you structured your code along key sizes, the "wrong" sizes would be 
non-evaluated, and the "right" sizes would be evaluated.

If someone from NIST or from a test lab wants to chime in here, that 
would be grand.

From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: RE: S/MIME v3.2  IDs key size text
Date: Sat, 03 May 2008 16:56:38 +1200
Sender: [email-masked]

Paul Hoffman <[email-masked]> writes:
>At 6:16 AM +1200 5/3/08, Peter Gutmann wrote:
>>Aren't these mutually exclusive?
>
>Yes; that's why they are in separate sections.

How does this reconcile them?  Do we get to choose which ones we want?

>>(The "or shorter" attached to the "1024" is also going to prove problematic
>>with FIPS-evaluated crypto implementations, since you can't do < 1024 bits
>>for those).
>
>That's just plain wrong. Nothing in the FIPS evaluation says that you cannot
>verify signatures shorter than what they require.

I didn't say you couldn't verify sigs, I said you couldn't get the code to do
that evaluated because the minimum they'll accept is 1024 bits.  In other
words you'd be using non-evaluated code (or code run in a non-evaluated mode)
to do the sig. verification.

Peter.

Date: Fri, 2 May 2008 15:46:21 -0700
To: Luther Martin <[email-masked]>, "[email-masked]"	<[email-masked]>
From: Paul Hoffman <[email-masked]>
Subject: RE: S/MIME v3.2  IDs key size text
Sender: [email-masked]

At 3:17 PM -0700 5/2/08, Luther Martin wrote:
>  > >(The "or shorter" attached to the "1024" is also going to prove
>>  problematic
>>  >with FIPS-evaluated crypto implementations, since you can't do < 1024
>>  bits for
>>  >those).
>>
>>  That's just plain wrong. Nothing in the FIPS evaluation says that you
>>  cannot verify signatures shorter than what they require.
>
>I'm not sure that's accurate. A FIPS security policy is fairly clear 
>about exactly what keys and key sizes you can use in FIPS mode, and 
>I'm fairly sure that this stops you from using smaller keys in FIPS 
>mode, even to verify a signature.

That's quite different than what I said. In FIPS mode, you may need 
to only validate FIPS-mandated signatures (there is even some 
disagreement about this). However, a FIPS-evaluated system can also 
validate non-FIPS-mandated signatures, just not in FIPS mode (maybe).

From: Luther Martin <[email-masked]>
To: "'Paul Hoffman'" <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Fri, 2 May 2008 15:17:43 -0700
Subject: RE: S/MIME v3.2  IDs key size text
Accept-Language: en-US
acceptlanguage: en-US
Sender: [email-masked]

> >(The "or shorter" attached to the "1024" is also going to prove
> problematic
> >with FIPS-evaluated crypto implementations, since you can't do < 1024
> bits for
> >those).
>
> That's just plain wrong. Nothing in the FIPS evaluation says that you
> cannot verify signatures shorter than what they require.

I'm not sure that's accurate. A FIPS security policy is fairly clear about =
exactly what keys and key sizes you can use in FIPS mode, and I'm fairly su=
re that this stops you from using smaller keys in FIPS mode, even to verify=
 a signature.

Date: Fri, 2 May 2008 14:43:30 -0700
To: <[email-masked]>
From: Paul Hoffman <[email-masked]>
Subject: RE: S/MIME v3.2  IDs key size text
Sender: [email-masked]

At 2:35 PM -0400 5/2/08, Tony Capel wrote:
>I think the minimum supported size needs to be 2048 because:

Please be more specific. Supported for what? Signing, verifying, or both?

>1) Since at least April 2007 (over a year ago) Verisign has been issuing certs
>with 2048 keys (I believe this is selectable when enrolling) 
>(although the root
>cert is only 1024!).
>2) NIST is recommending 2048 by end of 2008 for signatures and key 
>transport for
>some apps [SP-800-78-1 Table 3.1].
>3) Many/most hardware tokens (e.g. Safenet, Gem, Aladdin) are supporting 1024
>and 2048 (only).

The wording clearly says that you should expect to validate larger 
keys, which are covered by those three data points.

Your last point (hardware tokens signing at 1024) is exactly why I 
think mandating the ability to sign at least 1024 bits is a good idea.

>As far as going larger than 2048, in my brief survey, while there 
>appears to be
>a small level of interest in 3072 (and even 4096), beyond that many 
>appear to be
>recommending a switch to ECC because of the exponentially rising 
>power/cpu costs
>for larger RSA sizes (e.g. NSA Suite B).

The current text encourages being able to verify at any level, not 
just 1024 or even 2048.

>So I would suggest making 2048 and smaller mandatory. And using a 
>sentence like:
>" Note that receiving agents may see signatures whose key length is 
>longer than
>2048
>  bits in the future, and support for lengths of 3072 and 4078 SHOULD 
>be provided
>
>  to verify those signatures."

I fully disagree. We are talking about interoperability here, not 
best practice. We should not be mandating that receivers be able to 
verify things that beyond what is mandated for signers. If you want 
to change the length of what signers are required to do, that's fine, 
I would want both sides to be accordance. But until then, saying "you 
must be able to verify something larger than what you can sign" 
doesn't make sense from an interoperability standpoint.

Also, we should not mandate SHOULD-level requirements for particular 
size keys. For verification, specific bit-lengths are not important: 
it is the maximum key length.

>Or
>
>  "... for lengths up to and including 4078 SHOULD ..."
>
>to address optional support.

This doesn't seem to be a good reading of RFC 2119.

Date: Fri, 2 May 2008 14:43:47 -0700
To: [email-masked]
From: Paul Hoffman <[email-masked]>
Subject: RE: S/MIME v3.2  IDs key size text
Sender: [email-masked]

At 6:16 AM +1200 5/3/08, Peter Gutmann wrote:
>"Turner, Sean P." <[email-masked]> writes:
>
>>A receiving agent needs to be able to verify signatures whose key length is
>>chosen by the signer. For interoperability, a receiving agent MUST be able to
>>verify signatures whose key length is 1024 bits or shorter.
>
>[...]
>
>>Receiving agents are only required to validate signatures that are the same
>>length as sending agents are required to produce, namely 1024 bits.
>
>Aren't these mutually exclusive?

Yes; that's why they are in separate sections.

>(The "or shorter" attached to the "1024" is also going to prove problematic
>with FIPS-evaluated crypto implementations, since you can't do < 1024 bits for
>those).

That's just plain wrong. Nothing in the FIPS evaluation says that you 
cannot verify signatures shorter than what they require.

From: "Tony Capel" <[email-masked]>
To: "'Turner, Sean P.'" <[email-masked]>, <[email-masked]>
Subject: RE: S/MIME v3.2  IDs key size text
Date: Fri, 2 May 2008 14:35:55 -0400
Importance: Normal
Sender: [email-masked]

Sean:

I think the minimum supported size needs to be 2048 because:

1) Since at least April 2007 (over a year ago) Verisign has been issuing =
certs
with 2048 keys (I believe this is selectable when enrolling) (although =
the root
cert is only 1024!).
2) NIST is recommending 2048 by end of 2008 for signatures and key =
transport for
some apps [SP-800-78-1 Table 3.1].
3) Many/most hardware tokens (e.g. Safenet, Gem, Aladdin) are supporting =
1024
and 2048 (only).

As far as going larger than 2048, in my brief survey, while there =
appears to be
a small level of interest in 3072 (and even 4096), beyond that many =
appear to be
recommending a switch to ECC because of the exponentially rising =
power/cpu costs
for larger RSA sizes (e.g. NSA Suite B).

So I would suggest making 2048 and smaller mandatory. And using a =
sentence like:
" Note that receiving agents may see signatures whose key length is =
longer than
2048=20
 bits in the future, and support for lengths of 3072 and 4078 SHOULD be =
provided

 to verify those signatures."

Or

 "... for lengths up to and including 4078 SHOULD ..."

to address optional support.

Tony

| -----Original Message-----
| From: [email-masked]=20
| [mailto:[email-masked]] On Behalf Of Turner, Sean P.
| Sent: May 2, 2008 1:39 PM
| To: [email-masked]
| Subject: RE: S/MIME v3.2 IDs key size text
|=20
|=20
|=20
| Paul has suggest a rewording of his text for 4.1 as follows:
|=20
| A receiving agent needs to be able to verify signatures whose=20
| key length is chosen by the signer. For interoperability, a=20
| receiving agent MUST be able to verify signatures whose key=20
| length is 1024 bits or shorter. Being able to verify=20
| signatures is mandatory because earlier versions of this=20
| specification required the ability to generate signatures=20
| with shorter key lengths. Note that most receiving agents are=20
| likely to see signatures whose key length is longer than 1024=20
| bits during the next decade, and those receiving agents will=20
| want to be able to verify those signatures.
|=20
| He's also suggested the following security consideration:
|=20
| Receiving agents are only required to validate signatures=20
| that are the same length as sending agents are required to=20
| produce, namely 1024 bits. Many people feel that signatures=20
| of 1024 bits do not meet their security requirements today,=20
| or even if they meet their requirements today, they will not=20
| meet their requirements in the foreseeable future. Therefore,=20
| sending and receiving agents need to decide what strength of=20
| signature they want to produce and validate, respectively.=20
| Further, those decisions need to be reviewed periodically in=20
| light of decreasing cryptographic strength over time of signatures.
|=20
| spt
|=20
| >-----Original Message-----
| >From: Paul Hoffman [mailto:[email-masked]]
| >Sent: Tuesday, March 25, 2008 2:12 PM
| >To: Turner, Sean P.; 'Russ Housley'; [email-masked]
| >Subject: RE: S/MIME v3.2 IDs key size text
| >
| >At 10:16 AM -0400 3/25/08, Turner, Sean P. wrote:
| >>This sounds reasonable. I replace the following sentence in 3851bis:
| >>
| >>A receiving agent SHOULD be able to verify signatures with
| >keys of any
| >>size over 512 bits.
| >>
| >>with
| >>
| >>A receiving agent SHOULD be able to verify signatures with=20
| keys up to
| >>16384 bits.
| >
| >I disagree with the upper limit. Verifying signatures with 16K
| >bit keys is very difficult for constrained  devices; this=20
| >"SHOULD" may have the effect of making device makers need to=20
| >use faster CPUs than they would normally want to have.
| >
| >It is unclear which part of the SHOULD is not a MUST here.
| >Because we are talking only about interoperability, then the=20
| >number is 1024, which is what the key creators SHOULD be=20
| >making. But that is clearly a lower bound of what a typical=20
| >receiver might expect. Therefore, a short sentence like the=20
| >one proposed is insufficient. How about:
| >
| >A receiving agent needs to be able to verify signatures whose
| >key length is chosen by the signer. At a minimum, a receiving=20
| >agent MUST be able to verify signatures whose key length is=20
| >1024 bits or shorter. However, most receiving agents are=20
| >likely to see signatures whose key length is longer than that=20
| >during the next decade.
|=20

From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: RE: S/MIME v3.2  IDs key size text
Date: Sat, 03 May 2008 06:16:23 +1200
Sender: [email-masked]

"Turner, Sean P." <[email-masked]> writes:

>A receiving agent needs to be able to verify signatures whose key length is
>chosen by the signer. For interoperability, a receiving agent MUST be able to
>verify signatures whose key length is 1024 bits or shorter.

[...]

>Receiving agents are only required to validate signatures that are the same
>length as sending agents are required to produce, namely 1024 bits.

Aren't these mutually exclusive?

(The "or shorter" attached to the "1024" is also going to prove problematic
with FIPS-evaluated crypto implementations, since you can't do < 1024 bits for
those).

Peter.

From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: I-D ACTION:draft-ietf-smime-rfc3278-update-03.txt 
Date: Fri,  2 May 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		: Update to Use of Elliptic Curve Cryptography (ECC) Algorithms in Cryptographic Message Syntax (CMS)
	Author(s)	: S. Turner
	Filename	: draft-ietf-smime-rfc3278-update-03.txt
	Pages		: 28
	Date		: 2008-5-2
	
RFC 3278 describes how to use Elliptic Curve Cryptography (ECC) 
   public-key algorithms in the Cryptographic Message Syntax (CMS).  
   This document updates RFC 3278 to add support for the SHA2 family of 
   hash algorithms, Elliptic Curve Digital Signature Algorithm (ECDSA) 
   224-512, and Key Derivation Functions (KDFs) that utilize SHA2 
   algorithms.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-smime-rfc3278-update-03.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-rfc3278-update-03.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: <[email-masked]>
Subject: RE: S/MIME v3.2  IDs key size text
Date: Fri, 2 May 2008 13:39:03 -0400
Organization: IECA, Inc.
Sender: [email-masked]

Paul has suggest a rewording of his text for 4.1 as follows:

A receiving agent needs to be able to verify signatures whose key length is
chosen by the signer. For interoperability, a receiving agent MUST be able
to verify signatures whose key length is 1024 bits or shorter. Being able to
verify signatures is mandatory because earlier versions of this
specification required the ability to generate signatures with shorter key
lengths. Note that most receiving agents are likely to see signatures whose
key length is longer than 1024 bits during the next decade, and those
receiving agents will want to be able to verify those signatures.

He's also suggested the following security consideration:

Receiving agents are only required to validate signatures that are the same
length as sending agents are required to produce, namely 1024 bits. Many
people feel that signatures of 1024 bits do not meet their security
requirements today, or even if they meet their requirements today, they will
not meet their requirements in the foreseeable future. Therefore, sending
and receiving agents need to decide what strength of signature they want to
produce and validate, respectively. Further, those decisions need to be
reviewed periodically in light of decreasing cryptographic strength over
time of signatures.

spt

>-----Original Message-----
>From: Paul Hoffman [mailto:[email-masked]] 
>Sent: Tuesday, March 25, 2008 2:12 PM
>To: Turner, Sean P.; 'Russ Housley'; [email-masked]
>Subject: RE: S/MIME v3.2 IDs key size text
>
>At 10:16 AM -0400 3/25/08, Turner, Sean P. wrote:
>>This sounds reasonable. I replace the following sentence in 3851bis:
>>
>>A receiving agent SHOULD be able to verify signatures with 
>keys of any 
>>size over 512 bits.
>>
>>with
>>
>>A receiving agent SHOULD be able to verify signatures with keys up to 
>>16384 bits.
>
>I disagree with the upper limit. Verifying signatures with 16K 
>bit keys is very difficult for constrained  devices; this 
>"SHOULD" may have the effect of making device makers need to 
>use faster CPUs than they would normally want to have.
>
>It is unclear which part of the SHOULD is not a MUST here. 
>Because we are talking only about interoperability, then the 
>number is 1024, which is what the key creators SHOULD be 
>making. But that is clearly a lower bound of what a typical 
>receiver might expect. Therefore, a short sentence like the 
>one proposed is insufficient. How about:
>
>A receiving agent needs to be able to verify signatures whose 
>key length is chosen by the signer. At a minimum, a receiving 
>agent MUST be able to verify signatures whose key length is 
>1024 bits or shorter. However, most receiving agents are 
>likely to see signatures whose key length is longer than that 
>during the next decade.