Concerning http://www.ietf.org/internet-drafts/draft-ietf-smime-cms-mult-sign-01.txt
"Dale Moberg" <[email protected]> Thu, 20 Jul 2006 16:14:07 -0700
| Newsgroups | gmane.ietf.ediint |
|---|---|
| Message-ID | <[email protected]> |
This is a multi-part message in MIME format.
------_=_NextPart_001_01C6AC52.340F948B
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Readers of this list are likely to recognize that the CMS specification,
which underlies some SMIME RFCs, defines ASN.1 cryptographic data
layouts that are used in EDIINT application statements (AS1, AS2, ...)
=20
A proposed revision is under discussion that may be of interest to this
group as it could impact underlying implementations eventually.
=20
Cryptographic Message Syntax (CMS) Multiple Signer Clarification
<draft-ietf-smime-cms-mult-sign-01.txt>
=20
Normally, multiple signers are not used in EDIINT messages, but they
could occur because CMS allows them.
=20
The internet-draft says (and please read it for the exact language) that
when receiving CMS messages with multiple signatures, the default rule
(as I will call it) will be that the message is OK if one of the
signatures is OK. It also mentions that certain communities may wish to
have a different rule that replaces the default rule.
=20
One justification for the default rule is that it will promote
interoperability for use cases in which an old and a new certificate are
both used, and the signers want to provide signatures using both the old
and the new certificate (which may have different strengths, use new
improved hashes, etc). That way, receivers who have not managed to
update their systems (even after using CEM!) may still validate the
signatures and continue operations.=20
=20
I have not seen much discussion about security threats or risks that
might arise from adhering to this rule.
=20
Because changes to CMS options may impact security toolkits, it is worth
considering whether readers of this group have any questions for the
security group that is considering this change. Please send questions or
assessment of risks or threats to them.=20
=20
=20
------_=_NextPart_001_01C6AC52.340F948B
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=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;}
pre
{margin:0in;
margin-bottom:.0001pt;
font-size:10.0pt;
font-family:"Courier New";}
span.EmailStyle18
{mso-style-type:personal;
font-family:Arial;
color:windowtext;}
span.EmailStyle19
{mso-style-type:personal-reply;
font-family:Arial;
color:navy;}
@page Section1
{size:8.5in 11.0in;
margin:1.0in 1.25in 1.0in 1.25in;}
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><pre><font size=3D2 color=3Dnavy face=3D"Courier =
New"><span
style=3D'font-size:10.0pt;color:navy'>Readers of</span></font> this list =
are likely to recognize that the CMS specification, which underlies some =
SMIME RFCs, defines ASN.1 cryptographic data layouts <font
color=3Dnavy><span style=3D'color:navy'>that are </span></font>used in =
EDIINT application statements (AS1, AS2, =
…)<o:p></o:p></pre><pre><font
size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'><o:p> </o:p></span></font></pre><pre><fon=
t
size=3D2 face=3D"Courier New"><span style=3D'font-size:10.0pt'>A =
proposed revision is under discussion that may be of interest to this =
group as it could impact underlying implementations =
eventually.<o:p></o:p></span></font></pre><pre><font
size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'><o:p> </o:p></span></font></pre><pre><fon=
t
size=3D2 face=3D"Courier New"><span lang=3DFR =
style=3D'font-size:10.0pt'>Cryptographic Message Syntax (CMS) Multiple =
Signer Clarification<o:p></o:p></span></font></pre><pre><font
size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'><draft-ietf-smime-cms-mult-sign-01.txt><=
o:p></o:p></span></font></pre>
<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p> </o:p></span></font></p>
<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Normally, multiple signers are not used in EDIINT =
messages,
but they could <font color=3Dnavy><span =
style=3D'color:navy'>occur</span></font>
because CMS allows them.<o:p></o:p></span></font></p>
<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p> </o:p></span></font></p>
<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>The internet-draft says (and please read it for the =
exact
language) that when receiving CMS messages with multiple signatures<font
color=3Dnavy><span style=3D'color:navy'>,</span></font> the default =
rule<font
color=3Dnavy><span style=3D'color:navy'> (as I will call =
it)</span></font> will be
that the message is OK if one of the signatures is OK. It also <font
color=3Dnavy><span style=3D'color:navy'>mentions</span></font> that =
certain
communities may wish to have a different rule that replaces the default =
rule.<o:p></o:p></span></font></p>
<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p> </o:p></span></font></p>
<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>One justification for the default rule is that it =
will
promote interoperability for use cases in which an old and a new =
certificate <font
color=3Dnavy><span style=3D'color:navy'>are both</span></font> used, and =
the signer<font
color=3Dnavy><span style=3D'color:navy'>s</span></font> want to provide =
signature<font
color=3Dnavy><span style=3D'color:navy'>s</span></font> using both the =
old and the
new certificate (which may have different strengths, use new improved =
hashes,
etc). That way, receivers who have not managed to update their systems =
(even
after using CEM!) may still validate the signatures and continue =
operations. <o:p></o:p></span></font></p>
<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p> </o:p></span></font></p>
<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>I have not seen much discussion about security =
threats or
risks that might arise from adhering to this =
rule.<o:p></o:p></span></font></p>
<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p> </o:p></span></font></p>
<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Because changes to CMS options may impact security =
toolkits,
it is worth considering whether readers of this group have any questions =
for
the security group that is considering this change. Please send<font
color=3Dnavy><span style=3D'color:navy'> questions or assessment of =
risks or
threats</span></font> <font color=3Dnavy><span style=3D'color:navy'>to =
them. </span></font><o:p></o:p></span></font></p>
<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p> </o:p></span></font></p>
<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p> </o:p></span></font></p>
</div>
</body>
</html>
------_=_NextPart_001_01C6AC52.340F948B--