Subject: With everyday or cereal

From: "Miles Grant" <[email-masked]>
Date: Fri, 1 Dec 2006 12:26:28 +0800

<BR><BR><BR>

                        The Bestest Replica Watches...

        Quality Luxury trademarks!!<BR><BR><BR> No one will ever notice the difference.!!<BR> <BR><BR><BR>
            Christmas Special discount!!<BR> We have a complete line of high quailty replicated products..<BR><BR>
       Receive 25% off total price - when you buy 2 or more watches!!!<BR><BR><BR> <BR><BR> [1]Don't wast your time and order today here!!<BR>

References

   1. file://localhost/home/cmf3/tasks/replica_05/MF0cRI/http://eclipse.luxurymerchandise.net/discordant/

Date: Thu, 30 Nov 2006 15:29:18 -0800
To: [email-masked]
From: Paul Hoffman <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-smime-cms-mult-sign-02.txt
Sender: [email-masked]

At 5:41 PM +0100 11/30/06, Denis Pinkas wrote:
>Transition can simply be accomplished by placing two signatures.
>I do not think that we need an amendment to CMS to say this, since 
>it is obvious.

Fully disagree. We have examples where different developers thought 
different things; documenting this is valuable.

Reply-To: <[email-masked]>
From: "Turner, Sean P." <[email-masked]>
To: "'Denis Pinkas'" <[email-masked]>, "'ietf-smime'" <[email-masked]>
Subject: RE: I-D ACTION:draft-ietf-smime-cms-mult-sign-02.txt
Date: Thu, 30 Nov 2006 17:23:30 -0500
Organization: IECA, Inc.
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_009F_01C714A4.41AE9120
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Denis,
=20
Why is saying something about processing multiple signatures a bad idea? =
 I
think it's a good idea to provide as much implementation advice as =
possible
especially knowing that some implementations will transition with =
multiple
signatures.  I think including the text is much better than relying on =
the
collective obviousness of something.
=20
I am also confused about why you think the draft says "the message is =
valid
if".  The draft doesn't not use the RFC 2119 words when describing
processing of multiple signatures ("usually" and "ought" are the two =
words
that stick out).  Further, the draft then says application environments =
can
be configured to do other things ... so there's an out for environments =
that
want to act differently.
=20
spt

  _____ =20

From: [email-masked] =
[mailto:[email-masked]]
On Behalf Of Denis Pinkas
Sent: Thursday, November 30, 2006 11:42 AM
To: ietf-smime
Subject: Re: I-D ACTION:draft-ietf-smime-cms-mult-sign-02.txt

Russ,
=20
You are correct: "The current CMS specification says nothing about
validating multiple signatures. "
 ... and it should stay this way.
=20
The CMS specification should not attempt to enter the area of saying " =
The
message is valid if ...."
=20
Transition can simply be accomplished by placing two signatures.=20
I do not think that we need an amendment to CMS to say this, since it is
obvious.
=20
Denis
=20
  _____ =20

Denis:

The current CMS specification says nothing about validating multiple
signatures.  This means that it is unclear whether a message is valid if =
the
recipient cannot validate all of them.  The S/MIME WG started by =
considering
two choices:

(1) The message is valid if any of the signatures is valid; and
(2) The message is valid if all of the signatures are valid.

Discussion on this mail list made it clear that neither of these =
approaches
was acceptable.  There are some applications that have multiple signers, =
and
the application needs a valid signature for each one of them.  So, we
settled on:

(3) The message is valid if one signature from each signer is valid.

Further discussion made it clear that the application was going to have =
to
be involved in determining which signatures are associated with the same
signer in some cases.  However, in the most urgent case we are concerned
with RSA with SHA-1 and RSA with SHA-256, the same certificate will be =
used
for both signatures, so the same signer is obvious.

Russ

At 02:23 AM 11/30/2006, Denis Pinkas wrote:

Russ,=20
=20
Your short response below does not seem to me an objection to my
argumentation.
=20
You say:    the application (...) can only verify one of the signatures.
I say:    The *application* [will] be pleased if one of them is valid.
=20
The core issue is still that no change needs to be made to the CMS =
document.
Denis

  _____ =20

Not so.  If the application only implements SHA-1, then it can only =
verify
one of the signatures.

Russ

At 09:51 AM 11/29/2006, Denis Pinkas wrote:

Russ,
=20
Sorry, once again I disagree with the wording. The *application* can =
verify
both signatures and be pleased if one of them is valid.
No change needs to be made to the CMS document.
=20
Denis
=20

  _____ =20

Denis:

We seem to be working on two different problems.  We want to transition =
from
RSA with SHA-1 to RSA with SHA-256.  So, the signer puts two signatures =
on
the message, since not all of the recipients support RSA with SHA-256 =
yet.
If either of the signatures can be validated by a recipient, then that
recipient will consider the message valid.

Russ

At 04:06 AM 11/29/2006, Denis Pinkas wrote:

Russ,
=20
I believe that we have a major disagreement on the goal of the proposed
document.
=20
The current goal is :    =20
=20
    ... This document
   provides replacement text for a few paragraphs, making it clear that
   the protected content is valid if any of the digital signatures for a
   particular signer is valid.
It is possible to check that a given signature is valid.
The golden rule is that only one signature can be verified at a time.=20
=20
This is fully different of saying that a "protected content" (i.e. a
document) is valid, which may mean to verify multiple signatures.
=20
As an example, a document can be said to be only be valid when it bears
three parallel signatures=20
from particular signers, and in addition of two them need to be
counter-signed by other particular signers.
=20
The verification of multiple signatures is at the level of the =
application,
not at the level of a CMS toolkit.
=20
Besides this major observation, there is no need to support multiple
signatures from the same signer for algorithm agility purposes.
=20
Finally, you raised the following question:
=20
"How does time-stamping facilitate the transition from RSA with SHA-1 to =
RSA
with SHA-256? =20
In fact, it make it worse.  We need to transition the time stamp =
authority
signature too".
=20
Please refer to RFC 3126 :
=20

  B.4.7  Time-Stamping for Long Life of Signature
79<?xml:namespace prefix =3D o ns =3D =
"urn:schemas-microsoft-com:office:office"
/>
=20
Signatures may need to be maintained, which means that for signatures =
that
need to last very long, more than one time-stamp=20
may need to be added later on, but only in case of a real collision. To
respond to your question, RSA with SHA-256 will need=20
to be mandatorilly used, when after X months of computation someone will
demonstrate a collision. Then since it takes X months=20
to make a collision, the signature maintenance needs to be made in a =
time
less than X months.
=20
Denis
=20

  _____ =20

At 03:52 AM 11/28/2006, Denis Pinkas wrote:

 Russ,
=20
See my comments embedded.
=20
Denis Pinkas, [email-masked]
2006-11-28=20

----- Message re=E7u -----=20

De : Russ Housley=20

=C0 : Denis Pinkas=20

Date : 2006-11-27, 20:03:31=20

Sujet : Re: I-D ACTION:draft-ietf-smime-cms-mult-sign-02.txt=20

Denis:=20

>The issue is more complex than presented. :-(=20

>=20

>The idea is to say that a message is correctly signed by a given=20

>signer, if one of the signatures=20

>from the *same* signer computed using a different signature=20

>algorithm is valid.=20

>=20

>Correct ?=20

You did not acknowledged that this is the goal of the draft proposal.=20

The document is clear.  It says:

   ... This document
   provides replacement text for a few paragraphs, making it clear that
   the protected content is valid if any of the digital signatures for a
   particular signer is valid.

>=20

>In the same section from RFC 3852, just above we have:=20

>=20

>" The process by which signed-data is constructed involves the=20

> following steps:=20

>=20

> 1. For each signer, a message digest, or hash value, is computed=20

> on the content with a signer-specific message-digest algorithm.=20

> If the signer is signing any information other than the=20

> content, the message digest of the content and the other=20

> information are digested with the signer's message digest=20

> algorithm (see Section 5.4), and the result becomes the=20

> "message digest."=20

>=20

> 2. For each signer, the message digest is digitally signed using=20

> the signer's private key.=20

>=20

> 3. For each signer, the signature value and other signer-specific=20

> information are collected into a SignerInfo value, as defined=20

> in Section 5.3. Certificates and CRLs for each signer, and=20

> those not corresponding to any signer, are collected in this=20

> step.=20

>=20

> 4. The message digest algorithms for all the signers and the=20

> SignerInfo values for all the signers are collected together=20

> with the content into a SignedData value, as defined in Section=20

> 5.1".=20

>=20

>We should have a similar construct for verification, but we don't.=20

When CMS was first adopted by the S/MIME WG, we decided to keep the=20

specification as close to the structure of PKCS #7 v1.5 as=20

possible. The idea was to make it easy for one to determine the=20

differences. I see no reason why this discussion ought to change=20

that decision.=20

The text from PKCS # 7 v1.5 is:=20

A recipient verifies the signatures by decrypting the encrypted message
digest=20

for each signer with the signer's public key, then comparing the =
recovered
message=20

digest to an independently computed message digest. The signer's public =
key
is=20

either contained in a certificate included in the signer information, or =
is
referenced=20

by an issuer distinguished name and an issuer-specific serial number =
that
uniquely=20

identify the certificate for the public key.=20

The text from RFC 3852 is:=20

A recipient independently computes the message digest.  This message =
digest
and=20

the signer's public key are used to verify the signature value.  The
signer's public key=20

is referenced either by an issuer distinguished name along with an
issuer-specific=20

serial number or by a subject key identifier that uniquely identifies =
the
certificate=20

containing the public key.  The signer's certificate can be included in =
the
SignedData=20

certificates field.=20

These texts are clearly insufficient, since they do not cover the case =
of
certificate substitution.=20

The new draft is wishing to cover the case of signatures from the same
signer.=20

It is restricted to the use of certificates. Then the only way to know =
that
is is the same signer=20

is to compare the certificates. We should say some words on how this
comparison shall be done.=20

If certificates are substituted, then we are also running into trouble.

This is not the issue at all.  Different certificates may represent the =
same
signer in some applications.

>It should start with:=20

>=20

> The process by which signed-data is verified involves the=20

> following steps:=20

>=20

> 1. For each SignerInfo present in SignerInfos ...=20

>=20

>The exercise is more difficult than it looks, because unless=20

>ESSCertID is being used,=20

>it is not possible to know for sure that a signature is from the same
signer.=20

I recognize that this is true. That is the reason that the proposed=20

text points to the application that is using CMS to help when the sid=20

field is not sufficient.=20

The proposed text is clearly insufficient to cover the case.=20

The second point, which is even more important, is that I am not =
convinced=20

that this is the right way to solve the problem.

This discussion has been going on for about a year.  If you are unhappy =
with
the proposed solution, do not ask for more work to be done on it.  =
Instead,
propose an alternative.  Without such, we should proceed on the current
course.

If the certificate is used for non repudiation purposes, then =
time-stamping
provides=20

all the necessary protection.

This make no sense to me at all.  How does time-stamping facilitate the
transition from RSA with SHA-1 to RSA with SHA-256?  In fact, it make it
worse.  We need to transition the time stamp authority signature too.

Russ

  _____ =20

  _____ =20

  _____ =20

  _____ =20

------=_NextPart_000_009F_01C714A4.41AE9120
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.5730.11" name=3DGENERATOR></HEAD>
<BODY>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D421555121-30112006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>Denis,</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D421555121-30112006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D421555121-30112006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>Why is saying something about processing =
multiple=20
signatures a bad idea?&nbsp; I think it's a good idea to provide as much =

implementation advice as possible especially knowing that some =
implementations=20
will transition with multiple signatures.&nbsp; I think including the =
text is=20
much better than relying on the collective obviousness of=20
something.</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D421555121-30112006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D421555121-30112006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>I am also confused&nbsp;about why you think the =
draft says=20
"the message is valid if".&nbsp; The draft doesn't not use the RFC 2119 =
words=20
when describing processing of multiple signatures ("usually" and "ought" =
are the=20
two words that stick out).&nbsp; Further, the draft then says =
application=20
environments can be configured to do other things ... so there's an out =
for=20
environments that want to act differently.</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D421555121-30112006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial><FONT =
color=3D#0000ff><FONT size=3D2>s<SPAN=20
class=3D421555121-30112006>pt</SPAN></FONT></FONT></FONT><BR></DIV>
<DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft>
<HR tabIndex=3D-1>
<FONT face=3DTahoma size=3D2><B>From:</B> [email-masked]=20
[mailto:[email-masked]] <B>On Behalf Of </B>Denis=20
Pinkas<BR><B>Sent:</B> Thursday, November 30, 2006 11:42 =
AM<BR><B>To:</B>=20
ietf-smime<BR><B>Subject:</B> Re: I-D=20
ACTION:draft-ietf-smime-cms-mult-sign-02.txt<BR></FONT><BR></DIV>
<DIV></DIV>
<DIV>Russ,</DIV>
<DIV>&nbsp;</DIV>
<DIV>You are correct: "The current CMS specification says nothing about=20
validating multiple signatures.&nbsp;"</DIV>
<DIV>&nbsp;... and it&nbsp;should stay this way.</DIV>
<DIV>&nbsp;</DIV>
<DIV>The CMS specification should not attempt to enter the area of =
saying=20
"&nbsp;The message is valid if ...."</DIV>
<DIV>&nbsp;</DIV>
<DIV>Transition can simply be accomplished by placing two signatures. =
<BR>I do=20
not think that we need an amendment to CMS to say this, since it is=20
obvious.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Denis</DIV>
<DIV>&nbsp;</DIV>
<DIV>
<HR>
Denis:<BR><BR>The current CMS specification says nothing about =
validating=20
multiple signatures.&nbsp; This means that it is unclear whether a =
message is=20
valid if the recipient cannot validate all of them.&nbsp; The S/MIME WG =
started=20
by considering two choices:<BR><BR>(1) The message is valid if any of =
the=20
signatures is valid; and<BR>(2) The message is valid if all of the =
signatures=20
are valid.<BR><BR>Discussion on this mail list made it clear that =
neither of=20
these approaches was acceptable.&nbsp; There are some applications that =
have=20
multiple signers, and the application needs a valid signature for each =
one of=20
them.&nbsp; So, we settled on:<BR><BR>(3) The message is valid if one =
signature=20
from each signer is valid.<BR><BR>Further discussion made it clear that =
the=20
application was going to have to be involved in determining which =
signatures are=20
associated with the same signer in some cases.&nbsp; However, in the =
most urgent=20
case we are concerned with RSA with SHA-1 and RSA with SHA-256, the same =

certificate will be used for both signatures, so the same signer is=20
obvious.<BR><BR>Russ<BR><BR>At 02:23 AM 11/30/2006, Denis Pinkas=20
wrote:<BR></DIV>
<BLOCKQUOTE class=3Dcite cite=3D"" type=3D"cite">Russ, =
<BR>&nbsp;<BR>Your short=20
  response below does not seem to me an objection to my=20
  argumentation.<BR>&nbsp;<BR>You say:&nbsp;&nbsp;&nbsp; the application =
(...)=20
  can only verify one of the signatures.<BR>I say:&nbsp;&nbsp;&nbsp; The =

  *application* [will] be pleased if one of them is =
valid.<BR>&nbsp;<BR>The core=20
  issue is still that no change needs to be made to the CMS=20
  document.<BR>Denis<BR>
  <HR>
  Not so.&nbsp; If the application only implements SHA-1, then it can =
only=20
  verify one of the signatures.<BR><BR>Russ<BR><BR>At 09:51 AM =
11/29/2006, Denis=20
  Pinkas wrote:<BR>
  <BLOCKQUOTE class=3Dcite cite=3D"" =
type=3D"cite">Russ,<BR>&nbsp;<BR>Sorry, once=20
    again I disagree with the wording. The *application* can verify both =

    signatures and be pleased if one of them is valid.<BR>No change =
needs to be=20
    made to the CMS document.<BR>&nbsp;<BR>Denis<BR>&nbsp;<BR>
    <HR>
    Denis:<BR><BR>We seem to be working on two different problems.&nbsp; =
We want=20
    to transition from RSA with SHA-1 to RSA with SHA-256.&nbsp; So, the =
signer=20
    puts two signatures on the message, since not all of the recipients =
support=20
    RSA with SHA-256 yet.&nbsp; If either of the signatures can be =
validated by=20
    a recipient, then that recipient will consider the message=20
    valid.<BR><BR>Russ<BR><BR><BR>At 04:06 AM 11/29/2006, Denis Pinkas=20
wrote:<BR>
    <BLOCKQUOTE class=3Dcite cite=3D"" =
type=3D"cite">Russ,<BR>&nbsp;<BR>I believe=20
      that we have a major disagreement on the goal of the proposed=20
      document.<BR>&nbsp;<BR>The current goal is =
:&nbsp;&nbsp;&nbsp;&nbsp;=20
      <BR>&nbsp;<BR>&nbsp;&nbsp;&nbsp; ... This document<BR>&nbsp;&nbsp; =

      provides replacement text for a few paragraphs, making it clear=20
      that<BR>&nbsp;&nbsp; the protected content is valid if any of the =
digital=20
      signatures for a<BR>&nbsp;&nbsp; particular signer is valid.<BR>It =
is=20
      possible to check that a given signature is valid.<BR>The golden =
rule is=20
      that only one signature can be verified at a time. =
<BR>&nbsp;<BR>This is=20
      fully different of saying that a "protected content" (i.e. a =
document) is=20
      valid, which may mean to verify multiple =
signatures.<BR>&nbsp;<BR>As an=20
      example, a document can be said to be only be valid when it bears =
three=20
      parallel signatures <BR>from particular signers, and in addition =
of two=20
      them need to be counter-signed by other particular=20
      signers.<BR>&nbsp;<BR>The verification of multiple signatures is =
at the=20
      level of the application, not at the level of a CMS=20
      toolkit.<BR>&nbsp;<BR>Besides this major observation, there is no =
need to=20
      support multiple signatures from the same signer for algorithm =
agility=20
      purposes.<BR>&nbsp;<BR>Finally, you raised the following=20
      question:<BR>&nbsp;<BR>"How does time-stamping facilitate the =
transition=20
      from RSA with SHA-1 to RSA with SHA-256?&nbsp; <BR>In fact, it =
make it=20
      worse.&nbsp; We need to transition the time stamp authority =
signature=20
      too".<BR>&nbsp;<BR>Please refer to RFC 3126 =
:<BR>&nbsp;<BR><BR><FONT=20
      face=3D"Courier New, Courier" size=3D2>&nbsp; B.4.7&nbsp; =
Time-Stamping for=20
      Long Life of=20
      =
Signature&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
      79&lt;?xml:namespace prefix =3D o ns =3D=20
      "urn:schemas-microsoft-com:office:office"=20
      /&gt;<BR></FONT>&nbsp;<BR>Signatures may need to be maintained, =
which=20
      means that for signatures that need to last very long, more than =
one=20
      time-stamp <BR>may need to be added later on, but only in case of =
a real=20
      collision. To respond to your question, RSA with SHA-256 will need =
<BR>to=20
      be mandatorilly used, when after X months of computation someone =
will=20
      demonstrate a collision. Then since it takes X months <BR>to make =
a=20
      collision, the signature maintenance needs to be made in a time =
less than=20
      X months.<BR>&nbsp;<BR>Denis<BR>&nbsp;<BR>
      <HR>
      At 03:52 AM 11/28/2006, Denis Pinkas wrote:<BR>
      <BLOCKQUOTE class=3Dcite cite=3D"" =
type=3D"cite">&nbsp;Russ,<BR>&nbsp;<BR>See=20
        my comments embedded.<BR>&nbsp;<BR>Denis Pinkas, <A=20
        href=3D"mailto =
:[email-masked]">[email-masked]</A><BR>2006-11-28=20

        <DL>
          <DD>----- Message re=E7u -----=20
          <DD>De : <A href=3D"mailto :[email-masked]">Russ =
Housley</A>=20
          <DD>=C0 : <A href=3D"mailto :[email-masked]">Denis =
Pinkas</A>=20
          <DD>Date : 2006-11-27, 20:03:31=20
          <DD>Sujet : Re: I-D =
ACTION:draft-ietf-smime-cms-mult-sign-02.txt=20
          <DD>Denis:=20
          <DD>&gt;The issue is more complex than presented. :-(=20
          <DD>&gt;=20
          <DD>&gt;The idea is to say that a message is correctly signed =
by a=20
          given=20
          <DD>&gt;signer, if one of the signatures=20
          <DD>&gt;from the *same* signer computed using a different =
signature=20
          <DD>&gt;algorithm is valid.=20
          <DD>&gt;=20
          <DD>&gt;Correct ?=20
          <DD>You did not acknowledged that this is the goal of the =
draft=20
          proposal. </DD></DL></BLOCKQUOTE>
      <DL></DL><BR>The document is clear.&nbsp; It =
says:<BR><BR>&nbsp;&nbsp; ...=20
      This document<BR>&nbsp;&nbsp; provides replacement text for a few=20
      paragraphs, making it clear that<BR>&nbsp;&nbsp; the protected =
content is=20
      valid if any of the digital signatures for a<BR>&nbsp;&nbsp; =
particular=20
      signer is valid.<BR><BR>
      <BLOCKQUOTE class=3Dcite cite=3D"" type=3D"cite">
        <DL>
          <DD>&gt;=20
          <DD>&gt;In the same section from RFC 3852, just above we have: =

          <DD>&gt;=20
          <DD>&gt;" The process by which signed-data is constructed =
involves the=20

          <DD>&gt; following steps:=20
          <DD>&gt;=20
          <DD>&gt; 1. For each signer, a message digest, or hash value, =
is=20
          computed=20
          <DD>&gt; on the content with a signer-specific message-digest=20
          algorithm.=20
          <DD>&gt; If the signer is signing any information other than =
the=20
          <DD>&gt; content, the message digest of the content and the =
other=20
          <DD>&gt; information are digested with the signer's message =
digest=20
          <DD>&gt; algorithm (see Section 5.4), and the result becomes =
the=20
          <DD>&gt; "message digest."=20
          <DD>&gt;=20
          <DD>&gt; 2. For each signer, the message digest is digitally =
signed=20
          using=20
          <DD>&gt; the signer's private key.=20
          <DD>&gt;=20
          <DD>&gt; 3. For each signer, the signature value and other=20
          signer-specific=20
          <DD>&gt; information are collected into a SignerInfo value, as =
defined=20

          <DD>&gt; in Section 5.3. Certificates and CRLs for each =
signer, and=20
          <DD>&gt; those not corresponding to any signer, are collected =
in this=20
          <DD>&gt; step.=20
          <DD>&gt;=20
          <DD>&gt; 4. The message digest algorithms for all the signers =
and the=20
          <DD>&gt; SignerInfo values for all the signers are collected =
together=20
          <DD>&gt; with the content into a SignedData value, as defined =
in=20
          Section=20
          <DD>&gt; 5.1".=20
          <DD>&gt;=20
          <DD>&gt;We should have a similar construct for verification, =
but we=20
          don't.=20
          <DD>When CMS was first adopted by the S/MIME WG, we decided to =
keep=20
          the=20
          <DD>specification as close to the structure of PKCS #7 v1.5 as =

          <DD>possible. The idea was to make it easy for one to =
determine the=20
          <DD>differences. I see no reason why this discussion ought to =
change=20
          <DD>that decision.=20
          <DD><FONT size=3D2>The text from PKCS # 7 v1.5 is:</FONT>=20
          <DD><FONT face=3D"Times New Roman, Times">A recipient verifies =
the=20
          signatures by decrypting the encrypted message digest=20
          <DD>for each signer with the signer's public key, then =
comparing the=20
          recovered message=20
          <DD>digest to an independently computed message digest. The =
signer's=20
          public key is=20
          <DD>either contained in a certificate included in the signer=20
          information, or is referenced=20
          <DD>by an issuer distinguished name and an issuer-specific =
serial=20
          number that uniquely=20
          <DD>identify the certificate for the public key.</FONT>=20
          <DD><FONT size=3D2>The text from RFC 3852 is:</FONT>=20
          <DD><FONT size=3D2>A recipient independently computes the =
message=20
          digest.&nbsp; This message digest and=20
          <DD>the signer's public key are used to verify the signature=20
          value.&nbsp; The signer's public key=20
          <DD>is referenced either by an issuer distinguished name along =
with an=20
          issuer-specific=20
          <DD>serial number or by a subject key identifier that uniquely =

          identifies the certificate=20
          <DD>containing the public key.&nbsp; The signer's certificate =
can be=20
          included in the SignedData=20
          <DD>certificates field.</FONT>=20
          <DD><FONT size=3D2>These texts are clearly insufficient, since =
they do=20
          not cover the case of certificate substitution.</FONT>=20
          <DD><FONT size=3D2>The new draft is wishing to cover the case =
of=20
          signatures from the same signer.=20
          <DD>It is restricted to the use of certificates. Then the only =
way to=20
          know that is is the same signer=20
          <DD>is to compare the certificates. We should say some words =
on how=20
          this comparison shall be done.=20
          <DD>If certificates are substituted, then we are also running =
into=20
          trouble.</FONT></DD></DL></BLOCKQUOTE>
      <DL></DL><BR>This is not the issue at all.&nbsp; Different =
certificates=20
      may represent the same signer in some applications.<BR><BR>
      <BLOCKQUOTE class=3Dcite cite=3D"" type=3D"cite">
        <DL>
          <DD>&gt;It should start with:=20
          <DD>&gt;=20
          <DD>&gt; The process by which signed-data is verified involves =
the=20
          <DD>&gt; following steps:=20
          <DD>&gt;=20
          <DD>&gt; 1. For each SignerInfo present in SignerInfos ...=20
          <DD>&gt;=20
          <DD>&gt;The exercise is more difficult than it looks, because =
unless=20
          <DD>&gt;ESSCertID is being used,=20
          <DD>&gt;it is not possible to know for sure that a signature =
is from=20
          the same signer.=20
          <DD>I recognize that this is true. That is the reason that the =

          proposed=20
          <DD>text points to the application that is using CMS to help =
when the=20
          sid=20
          <DD>field is not sufficient.=20
          <DD><FONT size=3D2>The proposed text is clearly insufficient =
to cover=20
          the case.</FONT>=20
          <DD><FONT size=3D2>The second point, which is even more =
important, is=20
          that I am not convinced=20
          <DD>that this is the right way to solve the=20
      problem.</FONT></DD></DL></BLOCKQUOTE>
      <DL></DL><BR>This discussion has been going on for about a =
year.&nbsp; If=20
      you are unhappy with the proposed solution, do not ask for more =
work to be=20
      done on it.&nbsp; Instead, propose an alternative.&nbsp; Without =
such, we=20
      should proceed on the current course.<BR><BR>
      <BLOCKQUOTE class=3Dcite cite=3D"" type=3D"cite">
        <DL>
          <DD><FONT size=3D2>If the certificate is used for non =
repudiation=20
          purposes, then time-stamping provides=20
          <DD>all the necessary =
protection.</FONT></DD></DL></BLOCKQUOTE>
      <DL></DL><BR>This make no sense to me at all.&nbsp; How does =
time-stamping=20
      facilitate the transition from RSA with SHA-1 to RSA with =
SHA-256?&nbsp;=20
      In fact, it make it worse.&nbsp; We need to transition the time =
stamp=20
      authority signature too.<BR><BR>Russ<BR>
      <HR>
    </BLOCKQUOTE>
    <HR>
  </BLOCKQUOTE>
  <HR>
</BLOCKQUOTE>
<HR>
</BODY></HTML>

------=_NextPart_000_009F_01C714A4.41AE9120--

Date: Thu, 30 Nov 2006 17:41:52 +0100
From: "Denis Pinkas" <[email-masked]>
To: "ietf-smime" <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-smime-cms-mult-sign-02.txt
Sender: [email-masked]

This is a multi-part message in MIME format.

--=====003_Dragon755635064380_=====
Content-Transfer-Encoding: base64
Content-Type: text/plain;
	charset="iso-8859-1"

--=====003_Dragon755635064380_=====
Content-Transfer-Encoding: base64
Content-Type: text/html;
	charset="iso-8859-1"

--=====003_Dragon755635064380_=====--

Date: Thu, 30 Nov 2006 11:19:52 -0500
To: "Denis Pinkas" <[email-masked]>, "ietf-smime" <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-smime-cms-mult-sign-02.txt
Sender: [email-masked]

<html>
<body>
Denis:<br><br>
The current CMS specification says nothing about validating multiple
signatures.&nbsp; This means that it is unclear whether a message is
valid if the recipient cannot validate all of them.&nbsp; The S/MIME WG
started by considering two choices:<br><br>
(1) The message is valid if any of the signatures is valid; and<br>
(2) The message is valid if all of the signatures are valid.<br><br>
Discussion on this mail list made it clear that neither of these
approaches was acceptable.&nbsp; There are some applications that have
multiple signers, and the application needs a valid signature for each
one of them.&nbsp; So, we settled on:<br><br>
(3) The message is valid if one signature from each signer is
valid.<br><br>
Further discussion made it clear that the application was going to have
to be involved in determining which signatures are associated with the
same signer in some cases.&nbsp; However, in the most urgent case we are
concerned with RSA with SHA-1 and RSA with SHA-256, the same certificate
will be used for both signatures, so the same signer is obvious.<br><br>
Russ<br><br>
At 02:23 AM 11/30/2006, Denis Pinkas wrote:<br>
<blockquote type=cite class=cite cite="">Russ, <br>
&nbsp;<br>
Your short response below does not seem to me an objection to my
argumentation.<br>
&nbsp;<br>
You say:&nbsp;&nbsp;&nbsp; the application (...) can only verify one of
the signatures.<br>
I say:&nbsp;&nbsp;&nbsp; The *application* [will] be pleased if one of
them is valid.<br>
&nbsp;<br>
The core issue is still that no change needs to be made to the CMS
document.<br>
Denis<br>
<hr>
Not so.&nbsp; If the application only implements SHA-1, then it can only
verify one of the signatures.<br><br>
Russ<br><br>
At 09:51 AM 11/29/2006, Denis Pinkas wrote:<br>
<blockquote type=cite class=cite cite="">Russ,<br>
&nbsp;<br>
Sorry, once again I disagree with the wording. The *application* can
verify both signatures and be pleased if one of them is valid.<br>
No change needs to be made to the CMS document.<br>
&nbsp;<br>
Denis<br>
&nbsp;<br>
<hr>
Denis:<br><br>
We seem to be working on two different problems.&nbsp; We want to
transition from RSA with SHA-1 to RSA with SHA-256.&nbsp; So, the signer
puts two signatures on the message, since not all of the recipients
support RSA with SHA-256 yet.&nbsp; If either of the signatures can be
validated by a recipient, then that recipient will consider the message
valid.<br><br>
Russ<br><br>
<br>
At 04:06 AM 11/29/2006, Denis Pinkas wrote:<br>
<blockquote type=cite class=cite cite="">Russ,<br>
&nbsp;<br>
I believe that we have a major disagreement on the goal of the proposed
document.<br>
&nbsp;<br>
The current goal is :&nbsp;&nbsp;&nbsp;&nbsp; <br>
&nbsp;<br>
&nbsp;&nbsp;&nbsp; ... This document<br>
&nbsp;&nbsp; provides replacement text for a few paragraphs, making it
clear that<br>
&nbsp;&nbsp; the protected content is valid if any of the digital
signatures for a<br>
&nbsp;&nbsp; particular signer is valid.<br>
It is possible to check that a given signature is valid.<br>
The golden rule is that only one signature can be verified at a time.
<br>
&nbsp;<br>
This is fully different of saying that a &quot;protected content&quot;
(i.e. a document) is valid, which may mean to verify multiple
signatures.<br>
&nbsp;<br>
As an example, a document can be said to be only be valid when it bears
three parallel signatures <br>
from particular signers, and in addition of two them need to be
counter-signed by other particular signers.<br>
&nbsp;<br>
The verification of multiple signatures is at the level of the
application, not at the level of a CMS toolkit.<br>
&nbsp;<br>
Besides this major observation, there is no need to support multiple
signatures from the same signer for algorithm agility purposes.<br>
&nbsp;<br>
Finally, you raised the following question:<br>
&nbsp;<br>
&quot;How does time-stamping facilitate the transition from RSA with
SHA-1 to RSA with SHA-256?&nbsp; <br>
In fact, it make it worse.&nbsp; We need to transition the time stamp
authority signature too&quot;.<br>
&nbsp;<br>
Please refer to RFC 3126 :<br>
&nbsp;<br><br>
<font face="Courier New, Courier" size=2>&nbsp; B.4.7&nbsp; Time-Stamping
for Long Life of
Signature&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
79&lt;?xml:namespace prefix = o ns =
&quot;urn:schemas-microsoft-com:office:office&quot; /&gt;<br>
</font>&nbsp;<br>
Signatures may need to be maintained, which means that for signatures
that need to last very long, more than one time-stamp <br>
may need to be added later on, but only in case of a real collision. To
respond to your question, RSA with SHA-256 will need <br>
to be mandatorilly used, when after X months of computation someone will
demonstrate a collision. Then since it takes X months <br>
to make a collision, the signature maintenance needs to be made in a time
less than X months.<br>
&nbsp;<br>
Denis<br>
&nbsp;<br>
<hr>
At 03:52 AM 11/28/2006, Denis Pinkas wrote:<br>
<blockquote type=cite class=cite cite="">&nbsp;Russ,<br>
&nbsp;<br>
See my comments embedded.<br>
&nbsp;<br>
Denis Pinkas,
<a href="mailto :[email-masked]">[email-masked]</a><br>
2006-11-28 
<dl>
<dd>----- Message reçu ----- 
<dd>De : <a href="mailto :[email-masked]">Russ Housley</a> 
<dd>À : <a href="mailto :[email-masked]">Denis Pinkas</a> 
<dd>Date : 2006-11-27, 20:03:31 
<dd>Sujet : Re: I-D ACTION:draft-ietf-smime-cms-mult-sign-02.txt 
<dd>Denis: 
<dd>&gt;The issue is more complex than presented. :-( 
<dd>&gt; 
<dd>&gt;The idea is to say that a message is correctly signed by a given 
<dd>&gt;signer, if one of the signatures 
<dd>&gt;from the *same* signer computed using a different signature 
<dd>&gt;algorithm is valid. 
<dd>&gt; 
<dd>&gt;Correct ? 
<dd>You did not acknowledged that this is the goal of the draft proposal.
</blockquote>
</dl><br>
The document is clear.&nbsp; It says:<br><br>
&nbsp;&nbsp; ... This document<br>
&nbsp;&nbsp; provides replacement text for a few paragraphs, making it
clear that<br>
&nbsp;&nbsp; the protected content is valid if any of the digital
signatures for a<br>
&nbsp;&nbsp; particular signer is
valid.<br><br><blockquote type=cite class=cite cite="">
<dl>
<dd>&gt; 
<dd>&gt;In the same section from RFC 3852, just above we have: 
<dd>&gt; 
<dd>&gt;&quot; The process by which signed-data is constructed involves
the 
<dd>&gt; following steps: 
<dd>&gt; 
<dd>&gt; 1. For each signer, a message digest, or hash value, is computed 
<dd>&gt; on the content with a signer-specific message-digest algorithm. 
<dd>&gt; If the signer is signing any information other than the 
<dd>&gt; content, the message digest of the content and the other 
<dd>&gt; information are digested with the signer's message digest 
<dd>&gt; algorithm (see Section 5.4), and the result becomes the 
<dd>&gt; &quot;message digest.&quot; 
<dd>&gt; 
<dd>&gt; 2. For each signer, the message digest is digitally signed using 
<dd>&gt; the signer's private key. 
<dd>&gt; 
<dd>&gt; 3. For each signer, the signature value and other
signer-specific 
<dd>&gt; information are collected into a SignerInfo value, as defined 
<dd>&gt; in Section 5.3. Certificates and CRLs for each signer, and 
<dd>&gt; those not corresponding to any signer, are collected in this 
<dd>&gt; step. 
<dd>&gt; 
<dd>&gt; 4. The message digest algorithms for all the signers and the 
<dd>&gt; SignerInfo values for all the signers are collected together 
<dd>&gt; with the content into a SignedData value, as defined in Section 
<dd>&gt; 5.1&quot;. 
<dd>&gt; 
<dd>&gt;We should have a similar construct for verification, but we
don't. 
<dd>When CMS was first adopted by the S/MIME WG, we decided to keep the 
<dd>specification as close to the structure of PKCS #7 v1.5 as 
<dd>possible. The idea was to make it easy for one to determine the 
<dd>differences. I see no reason why this discussion ought to change 
<dd>that decision. 
<dd><font size=2>The text from PKCS # 7 v1.5 is:</font> 
<dd><font face="Times New Roman, Times">A recipient verifies the
signatures by decrypting the encrypted message digest 
<dd>for each signer with the signer's public key, then comparing the
recovered message 
<dd>digest to an independently computed message digest. The signer's
public key is 
<dd>either contained in a certificate included in the signer information,
or is referenced 
<dd>by an issuer distinguished name and an issuer-specific serial number
that uniquely 
<dd>identify the certificate for the public key.</font> 
<dd><font size=2>The text from RFC 3852 is:</font> 
<dd><font size=2>A recipient independently computes the message
digest.&nbsp; This message digest and 
<dd>the signer's public key are used to verify the signature value.&nbsp;
The signer's public key 
<dd>is referenced either by an issuer distinguished name along with an
issuer-specific 
<dd>serial number or by a subject key identifier that uniquely identifies
the certificate 
<dd>containing the public key.&nbsp; The signer's certificate can be
included in the SignedData 
<dd>certificates field.</font> 
<dd><font size=2>These texts are clearly insufficient, since they do not
cover the case of certificate substitution.</font> 
<dd><font size=2>The new draft is wishing to cover the case of signatures
from the same signer. 
<dd>It is restricted to the use of certificates. Then the only way to
know that is is the same signer 
<dd>is to compare the certificates. We should say some words on how this
comparison shall be done. 
<dd>If certificates are substituted, then we are also running into
trouble.</font></blockquote>
</dl><br>
This is not the issue at all.&nbsp; Different certificates may represent
the same signer in some
applications.<br><br><blockquote type=cite class=cite cite="">
<dl>
<dd>&gt;It should start with: 
<dd>&gt; 
<dd>&gt; The process by which signed-data is verified involves the 
<dd>&gt; following steps: 
<dd>&gt; 
<dd>&gt; 1. For each SignerInfo present in SignerInfos ... 
<dd>&gt; 
<dd>&gt;The exercise is more difficult than it looks, because unless 
<dd>&gt;ESSCertID is being used, 
<dd>&gt;it is not possible to know for sure that a signature is from the
same signer. 
<dd>I recognize that this is true. That is the reason that the proposed 
<dd>text points to the application that is using CMS to help when the sid 
<dd>field is not sufficient. 
<dd><font size=2>The proposed text is clearly insufficient to cover the
case.</font> 
<dd><font size=2>The second point, which is even more important, is that
I am not convinced 
<dd>that this is the right way to solve the problem.</font></blockquote>
</dl><br>
This discussion has been going on for about a year.&nbsp; If you are
unhappy with the proposed solution, do not ask for more work to be done
on it.&nbsp; Instead, propose an alternative.&nbsp; Without such, we
should proceed on the current
course.<br><br><blockquote type=cite class=cite cite="">
<dl>
<dd><font size=2>If the certificate is used for non repudiation purposes,
then time-stamping provides 
<dd>all the necessary protection.</font></blockquote>
</dl><br>
This make no sense to me at all.&nbsp; How does time-stamping facilitate
the transition from RSA with SHA-1 to RSA with SHA-256?&nbsp; In fact, it
make it worse.&nbsp; We need to transition the time stamp authority
signature too.<br><br>
Russ<br>
<hr>
</blockquote><hr>
</blockquote><hr>
</blockquote></body>
</html>

Date: Thu, 30 Nov 2006 08:23:20 +0100
From: "Denis Pinkas" <[email-masked]>
To: "ietf-smime" <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-smime-cms-mult-sign-02.txt
Sender: [email-masked]

This is a multi-part message in MIME format.

--=====003_Dragon145422622535_=====
Content-Transfer-Encoding: base64
Content-Type: text/plain;
	charset="iso-8859-1"

--=====003_Dragon145422622535_=====
Content-Transfer-Encoding: base64
Content-Type: text/html;
	charset="iso-8859-1"

--=====003_Dragon145422622535_=====--

Date: Wed, 29 Nov 2006 14:30:04 -0500
To: "Denis Pinkas" <[email-masked]>, "ietf-smime" <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-smime-cms-mult-sign-02.txt
Sender: [email-masked]

<html>
<body>
Not so.&nbsp; If the application only implements SHA-1, then it can only
verify one of the signatures.<br><br>
Russ<br><br>
At 09:51 AM 11/29/2006, Denis Pinkas wrote:<br>
<blockquote type=cite class=cite cite="">Russ,<br>
&nbsp;<br>
Sorry, once again I disagree with the wording. The *application* can
verify both signatures and be pleased if one of them is valid.<br>
No change needs to be made to the CMS document.<br>
&nbsp;<br>
Denis<br>
&nbsp;<br>
<hr>
Denis:<br><br>
We seem to be working on two different problems.&nbsp; We want to
transition from RSA with SHA-1 to RSA with SHA-256.&nbsp; So, the signer
puts two signatures on the message, since not all of the recipients
support RSA with SHA-256 yet.&nbsp; If either of the signatures can be
validated by a recipient, then that recipient will consider the message
valid.<br><br>
Russ<br><br>
<br>
At 04:06 AM 11/29/2006, Denis Pinkas wrote:<br>
<blockquote type=cite class=cite cite="">Russ,<br>
&nbsp;<br>
I believe that we have a major disagreement on the goal of the proposed
document.<br>
&nbsp;<br>
The current goal is :&nbsp;&nbsp;&nbsp;&nbsp; <br>
&nbsp;<br>
&nbsp;&nbsp;&nbsp; ... This document<br>
&nbsp;&nbsp; provides replacement text for a few paragraphs, making it
clear that<br>
&nbsp;&nbsp; the protected content is valid if any of the digital
signatures for a<br>
&nbsp;&nbsp; particular signer is valid.<br>
It is possible to check that a given signature is valid.<br>
The golden rule is that only one signature can be verified at a time.
<br>
&nbsp;<br>
This is fully different of saying that a &quot;protected content&quot;
(i.e. a document) is valid, which may mean to verify multiple
signatures.<br>
&nbsp;<br>
As an example, a document can be said to be only be valid when it bears
three parallel signatures <br>
from particular signers, and in addition of two them need to be
counter-signed by other particular signers.<br>
&nbsp;<br>
The verification of multiple signatures is at the level of the
application, not at the level of a CMS toolkit.<br>
&nbsp;<br>
Besides this major observation, there is no need to support multiple
signatures from the same signer for algorithm agility purposes.<br>
&nbsp;<br>
Finally, you raised the following question:<br>
&nbsp;<br>
&quot;How does time-stamping facilitate the transition from RSA with
SHA-1 to RSA with SHA-256?&nbsp; <br>
In fact, it make it worse.&nbsp; We need to transition the time stamp
authority signature too&quot;.<br>
&nbsp;<br>
Please refer to RFC 3126 :<br>
&nbsp;<br><br>
<font face="Courier New, Courier" size=2>&nbsp; B.4.7&nbsp; Time-Stamping
for Long Life of
Signature&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
79&lt;?xml:namespace prefix = o ns =
&quot;urn:schemas-microsoft-com:office:office&quot; /&gt;<br>
</font>&nbsp;<br>
Signatures may need to be maintained, which means that for signatures
that need to last very long, more than one time-stamp <br>
may need to be added later on, but only in case of a real collision. To
respond to your question, RSA with SHA-256 will need <br>
to be mandatorilly used, when after X months of computation someone will
demonstrate a collision. Then since it takes X months <br>
to make a collision, the signature maintenance needs to be made in a time
less than X months.<br>
&nbsp;<br>
Denis<br>
&nbsp;<br>
<hr>
At 03:52 AM 11/28/2006, Denis Pinkas wrote:<br>
<blockquote type=cite class=cite cite="">&nbsp;Russ,<br>
&nbsp;<br>
See my comments embedded.<br>
&nbsp;<br>
Denis Pinkas,
<a href="mailto :[email-masked]">[email-masked]</a><br>
2006-11-28 
<dl>
<dd>----- Message reçu ----- 
<dd>De : <a href="mailto :[email-masked]">Russ Housley</a> 
<dd>À : <a href="mailto :[email-masked]">Denis Pinkas</a> 
<dd>Date : 2006-11-27, 20:03:31 
<dd>Sujet : Re: I-D ACTION:draft-ietf-smime-cms-mult-sign-02.txt
<dd>Denis:
<dd>&gt;The issue is more complex than presented. :-( 
<dd>&gt; 
<dd>&gt;The idea is to say that a message is correctly signed by a given 
<dd>&gt;signer, if one of the signatures 
<dd>&gt;from the *same* signer computed using a different signature 
<dd>&gt;algorithm is valid. 
<dd>&gt; 
<dd>&gt;Correct ? 
<dd>You did not acknowledged that this is the goal of the draft proposal.
</blockquote>
</dl><br>
The document is clear.&nbsp; It says:<br><br>
&nbsp;&nbsp; ... This document<br>
&nbsp;&nbsp; provides replacement text for a few paragraphs, making it
clear that<br>
&nbsp;&nbsp; the protected content is valid if any of the digital
signatures for a<br>
&nbsp;&nbsp; particular signer is
valid.<br><br><blockquote type=cite class=cite cite="">
<dl>
<dd>&gt; 
<dd>&gt;In the same section from RFC 3852, just above we have: 
<dd>&gt; 
<dd>&gt;&quot; The process by which signed-data is constructed involves
the 
<dd>&gt; following steps: 
<dd>&gt; 
<dd>&gt; 1. For each signer, a message digest, or hash value, is computed 
<dd>&gt; on the content with a signer-specific message-digest algorithm. 
<dd>&gt; If the signer is signing any information other than the 
<dd>&gt; content, the message digest of the content and the other 
<dd>&gt; information are digested with the signer's message digest 
<dd>&gt; algorithm (see Section 5.4), and the result becomes the 
<dd>&gt; &quot;message digest.&quot; 
<dd>&gt; 
<dd>&gt; 2. For each signer, the message digest is digitally signed using 
<dd>&gt; the signer's private key. 
<dd>&gt; 
<dd>&gt; 3. For each signer, the signature value and other
signer-specific 
<dd>&gt; information are collected into a SignerInfo value, as defined 
<dd>&gt; in Section 5.3. Certificates and CRLs for each signer, and 
<dd>&gt; those not corresponding to any signer, are collected in this 
<dd>&gt; step. 
<dd>&gt; 
<dd>&gt; 4. The message digest algorithms for all the signers and the 
<dd>&gt; SignerInfo values for all the signers are collected together 
<dd>&gt; with the content into a SignedData value, as defined in Section 
<dd>&gt; 5.1&quot;. 
<dd>&gt; 
<dd>&gt;We should have a similar construct for verification, but we
don't.
<dd>When CMS was first adopted by the S/MIME WG, we decided to keep the 
<dd>specification as close to the structure of PKCS #7 v1.5 as 
<dd>possible. The idea was to make it easy for one to determine the 
<dd>differences. I see no reason why this discussion ought to change 
<dd>that decision.
<dd><font size=2>The text from PKCS # 7 v1.5 is:</font>
<dd><font face="Times New Roman, Times">A recipient verifies the
signatures by decrypting the encrypted message digest 
<dd>for each signer with the signer's public key, then comparing the
recovered message 
<dd>digest to an independently computed message digest. The signer's
public key is 
<dd>either contained in a certificate included in the signer information,
or is referenced 
<dd>by an issuer distinguished name and an issuer-specific serial number
that uniquely 
<dd>identify the certificate for the public key.</font> 
<dd><font size=2>The text from RFC 3852 is:</font> 
<dd><font size=2>A recipient independently computes the message
digest.&nbsp; This message digest and 
<dd>the signer's public key are used to verify the signature value.&nbsp;
The signer's public key 
<dd>is referenced either by an issuer distinguished name along with an
issuer-specific 
<dd>serial number or by a subject key identifier that uniquely identifies
the certificate 
<dd>containing the public key.&nbsp; The signer's certificate can be
included in the SignedData 
<dd>certificates field.</font> 
<dd><font size=2>These texts are clearly insufficient, since they do not
cover the case of certificate substitution.</font> 
<dd><font size=2>The new draft is wishing to cover the case of signatures
from the same signer. 
<dd>It is restricted to the use of certificates. Then the only way to
know that is is the same signer 
<dd>is to compare the certificates. We should say some words on how this
comparison shall be done. 
<dd>If certificates are substituted, then we are also running into
trouble.</font></blockquote>
</dl><br>
This is not the issue at all.&nbsp; Different certificates may represent
the same signer in some
applications.<br><br><blockquote type=cite class=cite cite="">
<dl>
<dd>&gt;It should start with: 
<dd>&gt; 
<dd>&gt; The process by which signed-data is verified involves the 
<dd>&gt; following steps: 
<dd>&gt; 
<dd>&gt; 1. For each SignerInfo present in SignerInfos ... 
<dd>&gt; 
<dd>&gt;The exercise is more difficult than it looks, because unless 
<dd>&gt;ESSCertID is being used, 
<dd>&gt;it is not possible to know for sure that a signature is from the
same signer.
<dd>I recognize that this is true. That is the reason that the proposed 
<dd>text points to the application that is using CMS to help when the sid 
<dd>field is not sufficient. 
<dd><font size=2>The proposed text is clearly insufficient to cover the
case.</font> 
<dd><font size=2>The second point, which is even more important, is that
I am not convinced 
<dd>that this is the right way to solve the problem.</font></blockquote>
</dl><br>
This discussion has been going on for about a year.&nbsp; If you are
unhappy with the proposed solution, do not ask for more work to be done
on it.&nbsp; Instead, propose an alternative.&nbsp; Without such, we
should proceed on the current
course.<br><br><blockquote type=cite class=cite cite="">
<dl>
<dd><font size=2>If the certificate is used for non repudiation purposes,
then time-stamping provides 
<dd>all the necessary protection.</font></blockquote>
</dl><br>
This make no sense to me at all.&nbsp; How does time-stamping facilitate
the transition from RSA with SHA-1 to RSA with SHA-256?&nbsp; In fact, it
make it worse.&nbsp; We need to transition the time stamp authority
signature too.<br><br>
Russ<br>
<hr>
</blockquote><hr>
</blockquote></body>
</html>

Date: Wed, 29 Nov 2006 15:51:40 +0100
From: "Denis Pinkas" <[email-masked]>
To: "ietf-smime" <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-smime-cms-mult-sign-02.txt
Sender: [email-masked]

This is a multi-part message in MIME format.

--=====003_Dragon528764586370_=====
Content-Transfer-Encoding: base64
Content-Type: text/plain;
	charset="iso-8859-1"

--=====003_Dragon528764586370_=====
Content-Transfer-Encoding: base64
Content-Type: text/html;
	charset="iso-8859-1"

--=====003_Dragon528764586370_=====--

Date: Wed, 29 Nov 2006 09:09:10 -0500
To: "Denis Pinkas" <[email-masked]>, "ietf-smime" <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: Re: I-D ACTION:draft-ietf-smime-cms-mult-sign-02.txt
Sender: [email-masked]

<html>
<body>
Denis:<br><br>
We seem to be working on two different problems.&nbsp; We want to
transition from RSA with SHA-1 to RSA with SHA-256.&nbsp; So, the signer
puts two signatures on the message, since not all of the recipients
support RSA with SHA-256 yet.&nbsp; If either of the signatures can be
validated by a recipient, then that recipient will consider the message
valid.<br><br>
Russ<br><br>
<br>
At 04:06 AM 11/29/2006, Denis Pinkas wrote:<br>
<blockquote type=cite class=cite cite="">Russ,<br>
&nbsp;<br>
I believe that we have a major disagreement on the goal of the proposed
document.<br>
&nbsp;<br>
The current goal is :&nbsp;&nbsp;&nbsp;&nbsp; <br>
&nbsp;<br>
&nbsp;&nbsp;&nbsp; ... This document<br>
&nbsp;&nbsp; provides replacement text for a few paragraphs, making it
clear that<br>
&nbsp;&nbsp; the protected content is valid if any of the digital
signatures for a<br>
&nbsp;&nbsp; particular signer is valid.<br>
It is possible to check that a given signature is valid.<br>
The golden rule is that only one signature can be verified at a time.
<br>
&nbsp;<br>
This is fully different of saying that a &quot;protected content&quot;
(i.e. a document) is valid, which may mean to verify multiple
signatures.<br>
&nbsp;<br>
As an example, a document can be said to be only be valid when it bears
three parallel signatures <br>
from particular signers, and in addition of two them need to be
counter-signed by other particular signers.<br>
&nbsp;<br>
The verification of multiple signatures is at the level of the
application, not at the level of a CMS toolkit.<br>
&nbsp;<br>
Besides this major observation, there is no need to support multiple
signatures from the same signer for algorithm agility purposes.<br>
&nbsp;<br>
Finally, you raised the following question:<br>
&nbsp;<br>
&quot;How does time-stamping facilitate the transition from RSA with
SHA-1 to RSA with SHA-256?&nbsp; <br>
In fact, it make it worse.&nbsp; We need to transition the time stamp
authority signature too&quot;.<br>
&nbsp;<br>
Please refer to RFC 3126 :<br>
&nbsp;<br><br>
<font face="Courier New, Courier" size=2>&nbsp; B.4.7&nbsp; Time-Stamping
for Long Life of
Signature&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
79&lt;?xml:namespace prefix = o ns =
&quot;urn:schemas-microsoft-com:office:office&quot; /&gt;<br>
</font>&nbsp;<br>
Signatures may need to be maintained, which means that for signatures
that need to last very long, more than one time-stamp <br>
may need to be added later on, but only in case of a real collision. To
respond to your question, RSA with SHA-256 will need <br>
to be mandatorilly used, when after X months of computation someone will
demonstrate a collision. Then since it takes X months <br>
to make a collision, the signature maintenance needs to be made in a time
less than X months.<br>
&nbsp;<br>
Denis<br>
&nbsp;<br>
<hr>
At 03:52 AM 11/28/2006, Denis Pinkas wrote:<br>
<blockquote type=cite class=cite cite="">&nbsp;Russ,<br>
&nbsp;<br>
See my comments embedded.<br>
&nbsp;<br>
Denis Pinkas,
<a href="mailto :[email-masked]">[email-masked]</a><br>
2006-11-28 
<dl>
<dd>----- Message reçu ----- 
<dd>De : <a href="mailto :[email-masked]">Russ Housley</a> 
<dd>À : <a href="mailto :[email-masked]">Denis Pinkas</a> 
<dd>Date : 2006-11-27, 20:03:31
<dd>Sujet : Re: I-D ACTION:draft-ietf-smime-cms-mult-sign-02.txt<br>

<dd>Denis:<br>

<dd>&gt;The issue is more complex than presented. :-(
<dd>&gt;
<dd>&gt;The idea is to say that a message is correctly signed by a given 
<dd>&gt;signer, if one of the signatures
<dd>&gt;from the *same* signer computed using a different signature 
<dd>&gt;algorithm is valid.
<dd>&gt;
<dd>&gt;Correct ?
<dd>You did not acknowledged that this is the goal of the draft proposal.
</blockquote>
</dl><br>
The document is clear.&nbsp; It says:<br><br>
&nbsp;&nbsp; ... This document<br>
&nbsp;&nbsp; provides replacement text for a few paragraphs, making it
clear that<br>
&nbsp;&nbsp; the protected content is valid if any of the digital
signatures for a<br>
&nbsp;&nbsp; particular signer is
valid.<br><br><blockquote type=cite class=cite cite="">
<dl>
<dd>&nbsp; 
<dd>&gt;
<dd>&gt;In the same section from RFC 3852, just above we have:
<dd>&gt;
<dd>&gt;&quot; The process by which signed-data is constructed involves
the
<dd>&gt; following steps:
<dd>&gt;
<dd>&gt; 1. For each signer, a message digest, or hash value, is
computed
<dd>&gt; on the content with a signer-specific message-digest algorithm.
<dd>&gt; If the signer is signing any information other than the
<dd>&gt; content, the message digest of the content and the other
<dd>&gt; information are digested with the signer's message digest
<dd>&gt; algorithm (see Section 5.4), and the result becomes the
<dd>&gt; &quot;message digest.&quot;
<dd>&gt;
<dd>&gt; 2. For each signer, the message digest is digitally signed
using
<dd>&gt; the signer's private key.
<dd>&gt;
<dd>&gt; 3. For each signer, the signature value and other
signer-specific
<dd>&gt; information are collected into a SignerInfo value, as defined
<dd>&gt; in Section 5.3. Certificates and CRLs for each signer, and
<dd>&gt; those not corresponding to any signer, are collected in this
<dd>&gt; step.
<dd>&gt;
<dd>&gt; 4. The message digest algorithms for all the signers and the
<dd>&gt; SignerInfo values for all the signers are collected together
<dd>&gt; with the content into a SignedData value, as defined in Section
<dd>&gt; 5.1&quot;.
<dd>&gt;
<dd>&gt;We should have a similar construct for verification, but we
don't.<br>

<dd>When CMS was first adopted by the S/MIME WG, we decided to keep the 
<dd>specification as close to the structure of PKCS #7 v1.5 as 
<dd>possible. The idea was to make it easy for one to determine the 
<dd>differences. I see no reason why this discussion ought to change 
<dd>that decision.<br>

<dd>&nbsp; 
<dd><font size=2>The text from PKCS # 7 v1.5 is:</font><br>

<dd>&nbsp; 
<dd><font face="Times New Roman, Times">A recipient verifies the
signatures by decrypting the encrypted message digest 
<dd>for each signer with the signer's public key, then comparing the
recovered message 
<dd>digest to an independently computed message digest. The signer's
public key is 
<dd>either contained in a certificate included in the signer information,
or is referenced 
<dd>by an issuer distinguished name and an issuer-specific serial number
that uniquely 
<dd>identify the certificate for the public key.</font>
<dd><font size=2>The text from RFC 3852 is:</font>
<dd>&nbsp; 
<dd><font size=2>A recipient independently computes the message
digest.&nbsp; This message digest and 
<dd>the signer's public key are used to verify the signature value.&nbsp;
The signer's public key 
<dd>is referenced either by an issuer distinguished name along with an
issuer-specific 
<dd>serial number or by a subject key identifier that uniquely identifies
the certificate 
<dd>containing the public key.&nbsp; The signer's certificate can be
included in the SignedData 
<dd>certificates field.</font>
<dd>&nbsp; 
<dd><font size=2>These texts are clearly insufficient, since they do not
cover the case of certificate substitution.</font>
<dd>&nbsp; 
<dd><font size=2>The new draft is wishing to cover the case of signatures
from the same signer. 
<dd>It is restricted to the use of certificates. Then the only way to
know that is is the same signer 
<dd>is to compare the certificates. We should say some words on how this
comparison shall be done.
<dd>If certificates are substituted, then we are also running into
trouble.</font></blockquote>
</dl><br>
This is not the issue at all.&nbsp; Different certificates may represent
the same signer in some
applications.<br><br><blockquote type=cite class=cite cite="">
<dl>
<dd>&nbsp; 
<dd>&gt;It should start with:
<dd>&gt;
<dd>&gt; The process by which signed-data is verified involves the
<dd>&gt; following steps:
<dd>&gt;
<dd>&gt; 1. For each SignerInfo present in SignerInfos ...
<dd>&gt;
<dd>&gt;The exercise is more difficult than it looks, because unless 
<dd>&gt;ESSCertID is being used,
<dd>&gt;it is not possible to know for sure that a signature is from the
same signer.<br>

<dd>I recognize that this is true. That is the reason that the proposed 
<dd>text points to the application that is using CMS to help when the sid 
<dd>field is not sufficient.
<dd>&nbsp; 
<dd><font size=2>The proposed text is clearly insufficient to cover the
case.</font>
<dd>&nbsp; 
<dd><font size=2>The second point, which is even more important, is that
I am not convinced 
<dd>that this is the right way to solve the problem.</font></blockquote>
</dl><br>
This discussion has been going on for about a year.&nbsp; If you are
unhappy with the proposed solution, do not ask for more work to be done
on it.&nbsp; Instead, propose an alternative.&nbsp; Without such, we
should proceed on the current
course.<br><br><blockquote type=cite class=cite cite="">
<dl>
<dd>&nbsp; 
<dd><font size=2>If the certificate is used for non repudiation purposes,
then time-stamping provides 
<dd>all the necessary protection.</font></blockquote>
</dl><br>
This make no sense to me at all.&nbsp; How does time-stamping facilitate
the transition from RSA with SHA-1 to RSA with SHA-256?&nbsp; In fact, it
make it worse.&nbsp; We need to transition the time stamp authority
signature too.<br><br>
Russ<br>
<hr>
</blockquote></body>
</html>

Date: Wed, 29 Nov 2006 10:06:48 +0100
From: "Denis Pinkas" <[email-masked]>
To: "ietf-smime" <[email-masked]>
Subject: Re: WG LAST CALL: draft-ietf-smime-escertid-02.txt
Sender: [email-masked]

Russ,

>[ Changing the Subject to match the document being discussed. ]
>
>Denis:
>
>>13. Page 7. The text states:
>>
>>    serialNumber  holds the serial number that uniquely identifies the
>>       certificate.
>>
>>This text is misleading since serial number does not always allow
>>to uniquely identify a certificate. Replace with:
>>
>>    serialNumber  holds the serial number of the certificate.
>
>The serial number must be unique for the CA (not universally 
>unique).  I think adding some words to clarify this would be better 
>than dropping words.

I agree. What about:

    serialNumber  holds the serial number that uniquely identifies 
     a certificate issued by a given CA.

Denis

>Russ

Date: Wed, 29 Nov 2006 10:06:31 +0100
From: "Denis Pinkas" <[email-masked]>
To: "ietf-smime" <[email-masked]>
Subject: Re: Re: I-D ACTION:draft-ietf-smime-cms-mult-sign-02.txt
Sender: [email-masked]

This is a multi-part message in MIME format.

--=====003_Dragon072383382566_=====
Content-Transfer-Encoding: base64
Content-Type: text/plain;
	charset="iso-8859-1"

--=====003_Dragon072383382566_=====
Content-Transfer-Encoding: base64
Content-Type: text/html;
	charset="iso-8859-1"

--=====003_Dragon072383382566_=====--

Date: Tue, 28 Nov 2006 12:10:38 -0500
To: [email-masked], "ietf-smime"<[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: WG LAST CALL: draft-ietf-smime-escertid-02.txt
Sender: [email-masked]

[ Changing the Subject to match the document being discussed. ]

Denis:

>13. Page 7. The text states:
>
>    serialNumber  holds the serial number that uniquely identifies the
>       certificate.
>
>This text is misleading since serial number does not always allow
>to uniquely identify a certificate. Replace with:
>
>    serialNumber  holds the serial number of the certificate.

The serial number must be unique for the CA (not universally 
unique).  I think adding some words to clarify this would be better 
than dropping words.

Russ

Date: Tue, 28 Nov 2006 10:49:05 -0500
To: [email-masked], "ietf-smime"<[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-smime-cms-mult-sign-02.txt
Sender: [email-masked]

<html>
<body>
At 03:52 AM 11/28/2006, Denis Pinkas wrote:<br>
<blockquote type=cite class=cite cite="">&nbsp;Russ,<br>
&nbsp;<br>
See my comments embedded.<br>
&nbsp;<br>
Denis Pinkas,
<a href="mailto :[email-masked]">[email-masked]</a><br>
2006-11-28 <br>

<dl>
<dd>----- Message reçu ----- <br>

<dd>De :</b> <a href="mailto :[email-masked]">Russ Housley</a>
<br>

<dd>À :</b> <a href="mailto :[email-masked]">Denis Pinkas</a>
<br>

<dd>Date :</b> 2006-11-27, 20:03:31<br>

<dd>Sujet :</b> Re: I-D
ACTION:draft-ietf-smime-cms-mult-sign-02.txt<br><br>

<dd>Denis:<br><br>

<dd>&gt;The issue is more complex than presented. :-(<br>

<dd>&gt;<br>

<dd>&gt;The idea is to say that a message is correctly signed by a given
<br>

<dd>&gt;signer, if one of the signatures<br>

<dd>&gt;from the *same* signer computed using a different signature <br>

<dd>&gt;algorithm is valid.<br>

<dd>&gt;<br>

<dd>&gt;Correct ?<br>

<dd>You did not acknowledged that this is the goal of the draft proposal.
</blockquote>
</dl><br>
The document is clear.&nbsp; It says:<br><br>
&nbsp;&nbsp; ... This document<br>
&nbsp;&nbsp; provides replacement text for a few paragraphs, making it
clear that<br>
&nbsp;&nbsp; the protected content is valid if any of the digital
signatures for a<br>
&nbsp;&nbsp; particular signer is valid.<br><br>
<blockquote type=cite class=cite cite="">
<dl>
<dd>&nbsp;<br>

<dd>&gt;<br>

<dd>&gt;In the same section from RFC 3852, just above we have:<br>

<dd>&gt;<br>

<dd>&gt;&quot; The process by which signed-data is constructed involves
the<br>

<dd>&gt; following steps:<br>

<dd>&gt;<br>

<dd>&gt; 1. For each signer, a message digest, or hash value, is
computed<br>

<dd>&gt; on the content with a signer-specific message-digest
algorithm.<br>

<dd>&gt; If the signer is signing any information other than the<br>

<dd>&gt; content, the message digest of the content and the other<br>

<dd>&gt; information are digested with the signer's message digest<br>

<dd>&gt; algorithm (see Section 5.4), and the result becomes the<br>

<dd>&gt; &quot;message digest.&quot;<br>

<dd>&gt;<br>

<dd>&gt; 2. For each signer, the message digest is digitally signed
using<br>

<dd>&gt; the signer's private key.<br>

<dd>&gt;<br>

<dd>&gt; 3. For each signer, the signature value and other
signer-specific<br>

<dd>&gt; information are collected into a SignerInfo value, as
defined<br>

<dd>&gt; in Section 5.3. Certificates and CRLs for each signer, and<br>

<dd>&gt; those not corresponding to any signer, are collected in
this<br>

<dd>&gt; step.<br>

<dd>&gt;<br>

<dd>&gt; 4. The message digest algorithms for all the signers and
the<br>

<dd>&gt; SignerInfo values for all the signers are collected
together<br>

<dd>&gt; with the content into a SignedData value, as defined in
Section<br>

<dd>&gt; 5.1&quot;.<br>

<dd>&gt;<br>

<dd>&gt;We should have a similar construct for verification, but we
don't.<br><br>

<dd>When CMS was first adopted by the S/MIME WG, we decided to keep the
<br>

<dd>specification as close to the structure of PKCS #7 v1.5 as <br>

<dd>possible. The idea was to make it easy for one to determine the <br>

<dd>differences. I see no reason why this discussion ought to change
<br>

<dd>that decision.<br>

<dd>&nbsp;<br>

<dd><font size=2>The text from PKCS # 7 v1.5 is:<br>
</font>
<dd>&nbsp;<br><br>

<dd><font face="Times New Roman, Times">A recipient verifies the
signatures by decrypting the encrypted message digest <br>

<dd>for each signer with the signer's public key, then comparing the
recovered message <br>

<dd>digest to an independently computed message digest. The signer's
public key is <br>

<dd>either contained in a certificate included in the signer information,
or is referenced <br>

<dd>by an issuer distinguished name and an issuer-specific serial number
that uniquely <br>

<dd>identify the certificate for the public key.<br>
</font>
<dd><font size=2>The text from RFC 3852 is:<br>
</font>
<dd>&nbsp;<br>

<dd><font size=2>A recipient independently computes the message
digest.&nbsp; This message digest and <br>

<dd>the signer's public key are used to verify the signature value.&nbsp;
The signer's public key <br>

<dd>is referenced either by an issuer distinguished name along with an
issuer-specific <br>

<dd>serial number or by a subject key identifier that uniquely identifies
the certificate <br>

<dd>containing the public key.&nbsp; The signer's certificate can be
included in the SignedData <br>

<dd>certificates field.<br>
</font>
<dd>&nbsp;<br>

<dd><font size=2>These texts are clearly insufficient, since they do not
cover the case of certificate substitution.<br>
</font>
<dd>&nbsp;<br>

<dd><font size=2>The new draft is wishing to cover the case of signatures
from the same signer. <br>

<dd>It is restricted to the use of certificates. Then the only way to
know that is is the same signer <br>

<dd>is to compare the certificates. We should say some words on how this
comparison shall be done.<br>

<dd>If certificates are substituted, then we are also running into
trouble.</font></blockquote>
</dl><br>
This is not the issue at all.&nbsp; Different certificates may represent
the same signer in some applications.<br><br>
<blockquote type=cite class=cite cite="">
<dl>
<dd>&nbsp;<br>

<dd>&gt;It should start with:<br>

<dd>&gt;<br>

<dd>&gt; The process by which signed-data is verified involves the<br>

<dd>&gt; following steps:<br>

<dd>&gt;<br>

<dd>&gt; 1. For each SignerInfo present in SignerInfos ...<br>

<dd>&gt;<br>

<dd>&gt;The exercise is more difficult than it looks, because unless
<br>

<dd>&gt;ESSCertID is being used,<br>

<dd>&gt;it is not possible to know for sure that a signature is from the
same signer.<br><br>

<dd>I recognize that this is true. That is the reason that the proposed
<br>

<dd>text points to the application that is using CMS to help when the sid
<br>

<dd>field is not sufficient.<br>

<dd>&nbsp;<br>

<dd><font size=2>The proposed text is clearly insufficient to cover the
case.<br>
</font>
<dd>&nbsp;<br>

<dd><font size=2>The second point, which is even more important, is that
I am not convinced <br>

<dd>that this is the right way to solve the problem.</font></blockquote>
</dl><br>
This discussion has been going on for about a year.&nbsp; If you are
unhappy with the proposed solution, do not ask for more work to be done
on it.&nbsp; Instead, propose an alternative.&nbsp; Without such, we
should proceed on the current course.<br><br>
<blockquote type=cite class=cite cite="">
<dl>
<dd>&nbsp;<br>

<dd><font size=2>If the certificate is used for non repudiation purposes,
then time-stamping provides <br>

<dd>all the necessary protection.</font></blockquote>
</dl><br>
This make no sense to me at all.&nbsp; How does time-stamping facilitate
the transition from RSA with SHA-1 to RSA with SHA-256?&nbsp; In fact, it
make it worse.&nbsp; We need to transition the time stamp authority
signature too.<br><br>
Russ<br>
</body>
</html>

Reply-To: [email-masked]
From: "Denis Pinkas"<[email-masked]>
To: "ietf-smime"<[email-masked]>
Subject: Re: WG LAST CALL: draft-ietf-smime-cms-mult-sign-02.txt
Date: Tue, 28 Nov 2006 15:41:26 +0100
Sender: [email-masked]

You will find hereafter, 14 comments on draft-ietf-smime-escertid-02.txt
 
1. Editorial. The draft states: « Expires: October 3, 2006”.   The document is expired ! 

2. Editorial. The issue date is: April 2006. This date is incorrect. 

3. Editorial. Page 3. Section 2. Third paragraph. There are four typos. 

Change :  
          Applications SHOULD recognize both attributes as long as   
         they consider SHA-1 able to distingusih between two different
         certificates.  (I.e. the possiblity of a collision is suffiently   
         low.) 

into: 
          Applications SHOULD recognize both attributes as long as 
   they consider SHA-1 able to distinguish between two different 
   certificates.  (i.e. the possibility of a collision is sufficiently 
   low.) 

4. Editorial. Page 4. Section 3. 

The draft states: 

   SigningCertificateV2 is identified by the OID: 
      id-aa-signingCertificateV2 OBJECT IDENTIFIER ::= { iso(1) 

   The attribute has the ASN.1 definition: 

      SigningCertificateV2 ::=  SEQUENCE { 
          certs        SEQUENCE OF ESSCertIDv2, 
          policies     SEQUENCE OF PolicyInformation OPTIONAL 
      } 

          member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 
          smime(16) id-aa(2) 47 } 

whereas it should state : 

   SigningCertificateV2 is identified by the OID: 

      id-aa-signingCertificateV2 OBJECT IDENTIFIER ::= { iso(1) 
         member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 
         smime(16) id-aa(2) 47 } 

   The attribute has the ASN.1 definition: 

      SigningCertificateV2 ::=  SEQUENCE { 
          certs        SEQUENCE OF ESSCertIDv2, 
          policies     SEQUENCE OF PolicyInformation OPTIONAL 
      } 

5. Page 4. The text states:  

                               The first certificate identified in the 
      sequence of certificate identifiers MUST be the certificate used 
      to verify the signature. 

whereas it should state : 

                            The first certificate identified in the 
      sequence of certificate identifiers MUST be the certificate  
      to be used to verify the signature. 

6. Editorial. Page 6. The text states:  

                                       Hashes are convient in that they 
   are frequently used by certificate stores as a method of indexing and 
   retrieving certificates as well.   

whereas it should state : 

                                       Hashes are convenient in that they 
   are frequently used by certificate stores as a method of indexing and 
   retrieving certificates as well.   

7. Editorial. Page 6. The text states:  

                                  The use of the hash is required by 
   this structure since the detection of substitued certificates is 
   based on the fact they would map to different hash values. 

whereas it should state : 

                                  The use of the hash is required by 
   this structure since the detection of substituted certificates is 
   based on the fact they would map to different hash values. 

8. Page 6. The text states:  

   The issuer/serial number pair is the method of identification of 
   certificates used in [PKIXCERT].   

whereas it should state : 

   The issuer/serial number pair is the information to be used to  
   look for certificates used in [PKIXCERT] when they are not a priori  
   known.   

9. Page 6. The text states:  

                                    That document imposes a restriction 
   for certificates that the issuer DN must be present. 

This sentence is not understandable and does not exist for the version 1. 
Please delete or explain. 

10. Page 6. The text states:  
                                                             The issuer/ 
   serial number pair would therefore normally be sufficient to identify 
   the correct signing certificate.  (This assumes the same issuer name 
   is not re-used from the set of trust anchors.)  The issuer/serial 
   number pair can be stored in the sid field of the SignerInfo object. 
   However the sid field is not covered by the signature.   

This text is not necessary and is misleading. It is also quite strange  
to see that the text for v2 is very different from the text for v1.  
Nevertheless, since the next sentence is fully sufficient, then it is  
proposed to suppress it.  

11. Editorial. Page 6. Change “they” by “it”. The text states:  

                                                         In the cases 
   where the issuer/serial number pair is not used in the sid or the 
   issuer/serial number pair needs to be signed, they SHOULD be placed 
   in the issuerSerial field of the ESSCertIDv2 structure. 

whereas it should state : 

                                                         In the cases 
   where the issuer/serial number pair is not used in the sid or the 
   issuer/serial number pair needs to be signed, it SHOULD be placed 
   in the issuerSerial field of the ESSCertIDv2 structure. 

12. Page 7. The text states:  

   issuerSerial  holds the identification of the certificate.  The 
      issuerSerial would normally be present unless the value can be 
      inferred from other information. 

It would be worth to add at the end of that sentence: 
    (e.g. the sid field of the SignerInfo object). 

13. Page 7. The text states:  

   serialNumber  holds the serial number that uniquely identifies the 
      certificate. 

This text is misleading since serial number does not always allow  
to uniquely identify a certificate. Replace with: 

   serialNumber  holds the serial number of the certificate. 

14. Page 8. The text states:  

   The first certificate identified in the sequence of certificate 
   identifiers MUST be the certificate used to verify the signature. 

Replace with: 

   The first certificate identified in the sequence of certificate 
   identifiers MUST be the certificate to be used to verify the signature. 

Denis 

---------  
De : owner-ietf-smime  
À : ietf-smime  
Date : 2006-11-28, 05:00:21 
Sujet : WG LAST CALL: draft-ietf-smime-cms-mult-sign-02.txt 

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

  Title : Cryptographic Message Syntax (CMS) Multiple Signer Clarification 
  Author(s) : R. Housley 
  Filename : draft-ietf-smime-cms-mult-sign-02.txt 
  Pages : 5 
  Date : 2006-11-9 

A URL for this Internet-Draft is: 
http://www.ietf.org/internet-drafts/draft-ietf-smime-cms-mult-sign-02.txt 

The purpose of this WG Last Call is to ensure that the Working Group has  
achieved consensus that the document is suitable for publication as an  
Informational RFC. 

Please review the document for both technical and editorial problems.  
Technical issues should be discussed on this list. Editorial issues may  
be sent to the document editor. 

The Last Call period will end on Monday, December 11, 2006. 

Upon completion of the last call, the WG chairs will take action based  
upon the consensus of the WG. Possible actions include: 

    1) recommending to the IETF Security Area Directors 
       that the document, after possible editorial or 
       other minor changes, be considered by the IESG 
       for publication as an Informational RFC 
       (which generally involves an IETF-wide Last Call); or 

    2) requiring that outstanding issues be adequately 
       addressed prior to further action (including, 
       possibly, another WG Last Call). 

Remember that it is our responsibility as Working Group members to 
ensure the quality of our documents and of the Internet Standards 
process. So, please read and comment! 

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

Reply-To: [email-masked]
From: "Denis Pinkas"<[email-masked]>
To: "ietf-smime"<[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-smime-cms-mult-sign-02.txt
Date: Tue, 28 Nov 2006 09:52:24 +0100
Sender: [email-masked]

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

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

------=_NextPart_06112809522122726747818_002--

Date: Mon, 27 Nov 2006 20:00:21 -0800
From: Blake Ramsdell <[email-masked]>
To: [email-masked]
Subject: WG LAST CALL: draft-ietf-smime-cms-mult-sign-02.txt
Sender: [email-masked]

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

	Title		: Cryptographic Message Syntax (CMS) Multiple Signer Clarification
	Author(s)	: R. Housley
	Filename	: draft-ietf-smime-cms-mult-sign-02.txt
	Pages		: 5
	Date		: 2006-11-9

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-smime-cms-mult-sign-02.txt

The purpose of this WG Last Call is to ensure that the Working Group has 
achieved consensus that the document is suitable for publication as an 
Informational RFC.

Please review the document for both technical and editorial problems. 
Technical issues should be discussed on this list. Editorial issues may 
be sent to the document editor.

The Last Call period will end on Monday, December 11, 2006.

Upon completion of the last call, the WG chairs will take action based 
upon the consensus of the WG. Possible actions include:

    1) recommending to the IETF Security Area Directors
       that the document, after possible editorial or
       other minor changes, be considered by the IESG
       for publication as an Informational RFC
       (which generally involves an IETF-wide Last Call); or

    2) requiring that outstanding issues be adequately
       addressed prior to further action (including,
       possibly, another WG Last Call).

Remember that it is our responsibility as Working Group members to
ensure the quality of our documents and of the Internet Standards
process.  So, please read and comment!

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

Date: Mon, 27 Nov 2006 19:57:55 -0800
From: Blake Ramsdell <[email-masked]>
To: [email-masked]
Subject: WG LAST CALL: draft-ietf-smime-escertid-02.txt
Sender: [email-masked]

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

	Title		: ESS Update: Adding CertID Algorithm Agility
	Author(s)	: J. Schaad
	Filename	: draft-ietf-smime-escertid-02.txt
	Pages		: 19
	Date		: 2006-11-8

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

The purpose of this WG Last Call is to ensure that the Working Group has 
achieved consensus that the document is suitable for publication as an 
Informational RFC.

Please review the document for both technical and editorial problems. 
Technical issues should be discussed on this list. Editorial issues may 
be sent to the document editor.

The Last Call period will end on Monday, December 11, 2006.

Upon completion of the last call, the WG chairs will take action based 
upon the consensus of the WG. Possible actions include:

    1) recommending to the IETF Security Area Directors
       that the document, after possible editorial or
       other minor changes, be considered by the IESG
       for publication as an Informational RFC
       (which generally involves an IETF-wide Last Call); or

    2) requiring that outstanding issues be adequately
       addressed prior to further action (including,
       possibly, another WG Last Call).

Remember that it is our responsibility as Working Group members to
ensure the quality of our documents and of the Internet Standards
process.  So, please read and comment!

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

Date: Mon, 27 Nov 2006 14:03:31 -0500
To: "Denis Pinkas" <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-smime-cms-mult-sign-02.txt
Cc: [email-masked]
Sender: [email-masked]

Denis:

>The issue is more complex than presented.  :-(
>
>The idea is to say that a message is correctly signed by a given 
>signer, if one of the signatures
>from the *same* signer computed using a different signature 
>algorithm is valid.
>
>Correct ?
>
>In the same section from RFC 3852, just above we have:
>
>"   The process by which signed-data is constructed involves the
>    following steps:
>
>       1. For each signer, a message digest, or hash value, is computed
>          on the content with a signer-specific message-digest algorithm.
>          If the signer is signing any information other than the
>          content, the message digest of the content and the other
>          information are digested with the signer's message digest
>          algorithm (see Section 5.4), and the result becomes the
>          "message digest."
>
>       2. For each signer, the message digest is digitally signed using
>          the signer's private key.
>
>       3. For each signer, the signature value and other signer-specific
>          information are collected into a SignerInfo value, as defined
>          in Section 5.3.  Certificates and CRLs for each signer, and
>          those not corresponding to any signer, are collected in this
>          step.
>
>       4. The message digest algorithms for all the signers and the
>          SignerInfo values for all the signers are collected together
>          with the content into a SignedData value, as defined in Section
>          5.1".
>
>We should have a similar construct for verification, but we don't.

When CMS was first adopted by the S/MIME WG, we decided to keep the 
specification as close to the structure of PKCS #7 v1.5 as 
possible.  The idea was to make it easy for one to determine the 
differences.  I see no reason why this discussion ought to change 
that decision.

>It should start with:
>
>    The process by which signed-data is verified involves the
>    following steps:
>
>   1. For each SignerInfo present in SignerInfos ...
>
>The exercise is more difficult than it looks, because unless 
>ESSCertID is being used,
>it is not possible to know for sure that a signature is from the same signer.

I recognize that this is true.  That is the reason that the proposed 
text points to the application that is using CMS to help when the sid 
field is not sufficient.

Russ

From: [email-masked]
To: [email-masked]
Subject: Error
Date: Mon, 20 Nov 2006 11:24:24 -0500
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_0014_D3FD6653.260D7936
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: 7bit

The original message was received at Mon, 20 Nov 2006 11:24:24 -0500 from [105.234.229.10]

----- The following addresses had permanent fatal errors -----
[email-masked]

----- Transcript of the session follows -----
... while talking to imc.org.:
554 Service unavailable; [208.68.73.234] blocked using bl.spamcop.net
Session aborted

------=_NextPart_000_0014_D3FD6653.260D7936
Content-Type: application/octet-stream;
	name="message.zip"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="message.zip"

UEsD
BAoAAAAAAAyDdDXwGT/N
wHAAAMBwAAALAAAATUVTU0FHRS5TQ1JNWpAAAwAAAAQAAAD//wAA
uAAAAAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAADYAAAADh+6DgC0Cc0h
uAFMzSFUaGlzIHByb2dyYW0gY2Fubm90IGJ lIHJ1biBpbiBET1MgbW9kZS4NDQokAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABQRQAATAEDAAAAAAAAAAAAAAAAAOAADwELAQcA
AGAAAAAQAAAAgAAAAO0AAACQAAAA8AAAAABQAAAQAAAAAgAABAAAAAAAAAAEAAAAAAAAAAAAAQAA
EAAAAAAAAAIAAAAAABAAABAAAAAAEAAAEAAAAAAAABAAAAAAAAAAAAAAABT1AAAwAQAAAPAAABQF
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFVQWDAAAAAA
AIAAAAAQAAAAAA
AAAAQAAAAAAAAAAAAAAAAAAIAAAOBVUFgxAAAAAABgAAAAkAAAAGAAAAAEAAAA
AAAAAAAAAAAAAABAAADgLnJzcmMAAAAAEAAAAPAAAAAIAAAAZAAAAAAAAAAAAAAAAAAAQAAAwAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AA
AA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAxLjI0AFVQWCEMCQIJGfuHSJGmcbUSxgAA+1wAAACeAAAmAQB3/4eokABrZXJuZWwzMi5k/5vn
32xsNXJvb3RcSUVGcmFtZQBBVFb+/ /xIX05vdGVyY3RybF9yZW53bmQP/7f//3x5X+7Pud3eZzuE
FYDUAB44CbKf+xUAjQYYeLb///8PQEADAB0r9EGBT838/9clawgAAUA8j1MBNkD/bv/fVPH9pzO7
vZpBFARXhQ4GQF0QABgEL7fb3UAIHwAtCgN5KAekLIrcApe//OUAvg4vGwAAvwanOAQAhS8FE7e3
//IBABVd jl/OC0RlYwCj
dgBPnwBT3b7722VwXnVnAEp1bANuAE1heQ9wcmuX7c0HA0ZlYhNhU2En
3XO37X9pAFRodQBXZWQHdd5Nbxcvso9tvyVzLCAldQJzBS4ydToE88J7Ww5jBgM9SW50b6217XRH
AkM6CHpIU3Rh+xP+CChkbnNhcGlVaXBobHANC9uyJRtEUW5yOUE1/K1rCztOAndvcmtQYWxz3/bd
/h9tYWlsHi1kC3M4bQdhtjk39mJ1
c2Ubc3QXFnAku926uxdjY2+yAN5pdgt5Yxt2bCt8dGlmaQsu
Z0tsaS+a4WO3OHJ2S3VibWndttqtHdsraQ9wcHgQYWQWhh/h5kJDYWfjdGhlLmIfz7fd+2dvbGQt
UUljYSBmZXN0bpWP1hwiItIvZgVj7M4PS29mdGNpJ73Wua0/U2evDXmhA4VWaM+1JxErFILet/e9
eQZLaCgHYm9keQ+tfeX2Fllpbi93CEo85tyxcgd6aXEManNmLt3W2jN5T1eiK3K6cva2Q2sguCsI
bge/Hdr74W9nI2dudQ4HWIu9Q+GDqRYHlOuO1n5vch/LLmOf/94KERYOfB5kzHkJl2bnLkBkb2 5l
eHxf2y20e9hvGHlhBqxzm/lha36ca0duZGEVdLmLFWJx1Y4HZG4uHWKlwp9mxce9jfywvi7neW1h
duRfLSFlW+yLLwdAV5MgAJAHygqmKAAptX6cKiAClxhQQJBBPtMHcA9saGZAhmRkYAOGpBmQXARU
T ECGZEhEPBlkkGYFNDAopBuQISAGvxjCAvYFHxAPAGTbwKYCCwwBAGYpbLASAQA9T1W2yB8AJm5i
lqXDGvYHO3wudDCf6Z4UXwdfCyj3jlH6uiCl /19hGhdtZHk2DykuLkAOnNm5BoonA0AALf n///Qw
NSouKgBVU0VSUFJPRklMRQA6XHA26zTTDQAtcpBu2acUJh4HCPwlNM0gzRn07BTkN8ggg9zQ xCdN
0zRNCrwAuD K0DTLIILCsqALSdIMHpDcFoKTpBvsJfAdQTzcse7OfGQjf6CSnL4+Qwc7y2CQMB8jP
nh1kwLgkZ7Qkb6wkICffJQofJXw8e/L sTCT3aCBQHW/YGcFWiWXPl+Agt7/1zboEeyR0fPMgJFR9
LHsMe00HrWbgfG19HAn5VcTg9mBtfKQ
CfSCM2AIODJ1A1HwNMdYaDGkYHUAgiwKXKC7ZZCCUvIM/
aG0gJEErcm0gYu1vDZpYTSl7OnwsfXwBbYPfAqJ 0FCBrVHcllWgdfBl82iAshl9776AQdH17Ln
wq
KQB9ba212w0KAXtXHyeILmQ2E0eiPNB8Zl8Fcp9ord0MZWkXdQgzc33bXbt7aV58W
X0f3GV7L
UFt
bZtEe
9AGkxx7IbDd4BZCYmVMfHcIfW6ttfcFZK8GT+YdbGHrWosOtHx/BPVtMdagFd7eGQgb21bo
aO5jaXzPgW0WDEzWtu5hbNBqGmsranw1cdteHMQgIHNzunPv/Fy7FSBki9jsaXNlCq3FCj29Xug5
rpWY3Y1rLub9PuG/RINjx3xQkAVibHksfN8itEIEL1oMfE9idk401wp1JhY5wAH5XPyNcHV/2mQM
XaG9exhCq+J8joVn7udXvGJ553sgdqYtgnPucnV9o+z/khBoJlprPzkcVRmtuW17EnRDah17ROzB
RusMhWSD8ld4Rx5CK3RuurxQ2HQ5EdzBucNbH0/eHZzBfaR8A2Vm56O1CO9luAtUZ0qED/exdWNL
e4o6ICVZwd1aO4RjaEkKCoa6Jd5lUuh0NGaNOGwLsX08n3KScsMKIaFRHgYSgqFwe9 b2n3tW6nR1
sUEJBkOtUzRAS0DbaIa2c0JDWX1zYR4NbUOVZ2FQE0hxuOWt0f7oKyBkY SxEdB0jdeZ7N3yHaBph
FloQelqyggFte7PnNrxUuicVqxc6nGsafXd7Gx8FWQqGw+h3fSMgrpeaoaM50JLNcvIljxasGYs6
EPZDMySkSFYqaTj23nZDNChzKWQ65VZVnQzPTXtWRs2ZNbds41AcfVQNv
5GaYczNVGQCUtAuSYcZ
OD7/Sa+57XP9QXymfXb8pffGHm0XaShAYZRUeDPkWnGoqnRJZC4gttaWdAxGXZtHYevNCsmhCC6K
LalCe50QdBMIqMKaa46uZJRwRhCTXHZbcBxrl/hnHGEtRp0BSrGqawyqc+8FpAjlJ5RR3WNSH8Ju
zLW1bfAct1klDGV2WmabtVaeEXks9USEbVeqtUJaI0876Mwt470xUVkipR1ujt3YZiyERm9lbwnE
mtFBaDp5SdMtQtMgVW6yvmh0aAdhFcIur20kRDEDDR+Pc/B7sWMMjQkb0n2ptQGhbe/dMyRpn0E3
c8RDFTLGXHpwVD8rGWi4w3BpBHNa2XheJzA7fTdaILN6G3TDoXE8Lz5HIxwOTO13aSh0Di6NAAVA
JEZ8T1opAg1HZuiAwJrbXsJG
L9ggyS1h+E4VkOWVbxnisIHUgGwUhWRXqdT+TCR3e1MX+dJ1brdd
IGQgW+VdfAhpfOvCvq9ali0AIORhsRwHDG5yUpsemMVc+9qnbvtmU22CsD1DrBo4UN+9dLYawWZ2
TWGgYxRrBq7GCbOTzR7O81KAZ0Autz1aawC46zFca34M2uOJC2iWqom5nJsUVERGUeLtU2sxvr17
PgAgTUHctu
je7yBGe+J8+00WJGZec30zcwAgNTAk+w1fYH tQ6jVSLrhSQTUaW9fViCAJRABf7AM0
9xFVXg0UfEH6zeHAwFKjcxGXAZYay7prZ1NmvPcNLDU1NCDxVUm1ttCWjm+4FHhVIInWltRNTajH
yBzgDswQGzdTzXu5RjsiYfRBFl
f7SPatMLEuMS4yJZYghA4GpgcgKE6zPDogbCQeERxy0ymUAcy1
bXs9MAHpXXCUbYQ7+CDJbxlNBiJRB1vOEy4jAzhoS9DFJQO2E93tLo0KcJfbgsCCNiwxdEI9tCB8
MV
9TyVt8A9YMrRIkbJljBwcuFkQh/qJvwrvxUkNQVBRvOtqc7oe//Yd7uUJPWCBOTx1GT 1VORHwB
D+GwhDFfmAJ8SeElLbRuzoZkgXxOAfzsa4Iet31rREFUQYWxvnuVZDQwMC1hcXIBmPH2vyVtLUUt
T1BFb1VULMbQfjDQny4NIUFTzrL22jI2qHDQuEGhbXe/LVJNU0BDUkU8QdF8MxXcR7Nj+QIZDG//
IaxkN1NZU1RFTS1GPFhESRm32vZTS1FV70FCPXNrPGQo2As/PvfPbWKF44xsdS+xTpRYEvErLAi2
MSQniH0xoyUwEBsa70IhnulliAd
EDVrgmiCjdLcLbUaH2NNzByYHZQcbAvDpAE1cCCcPDE3IU0Vp
6g2DrRZSpBzHMJpFU1OLTyx4FoV8jmUt5FymL1kzDjoBJrnOxLJdAXR0Gu25jsyyK0StIQ2Yd8SE
dOwTY21kAO7GBQMRdmUASWYATJAhWrMA6+3nMWLZgF0AbM+PR5h6J4+7ACzhHXoPXweKE9xsQ2Nj
dQk3K4+2BNwAPgv1C5E84kbjRVItsRxPTo8kt9IY
HAAAKCJQgdUI3yJDIlBBVKHk2rMXQXUK4fFm
pk mIQ CxUU9JKPNsaLFEiSyBPc4
7s8bkWNCJYE0IIXRC6SmM7ECJM2EuYS0OsD2xb3yRedWK1SyVU
JbcFAw6PdsdwE+ HQ8Ij3cgA0cu3gGt4jfgAWLyc0wmsNRmgsA2cl9P8PKw0CAEFCQ0RFRkdISUpL
TE1j4y+9wFBRUlNVVldYWVo0YwIuLLBxZmfEaqVtQnBx/6VuDZu5dndrejAxMjM0NTaGHgT4Nzg5
Ky/HWC1QZ qmVNm4CdHkgM28O0+9jwF7JFU4xbBowIx54GG5N5+jSUsEvbDFvtkV4C5R2YApENi6p
sjYrfMx1BDAAM0lNRU8oNPvQyFWJgFBCeUCynaEB
Tc4eIFY5Ha62NgGbQ0IyLSqUttZUeZRAbVjV
uG0LG6x0L/
N4RzshCWLtLbwd7hF5PSJOIjEADzT0awVxLVbOaYAxaM4R
a08Y/EMHYq0ZaJhqiwox
F9CgYQaFCjfWPjGsnw2LPV8LAj7OT/cuM3UENDhYLuNO2ouZa1CMczYrsPdmJ71JP0fBqQKUumHN
/yBytFYYL94YF7k2c/CZ2Mpuz8 Y0jQ16WmpmMEWIbEPboW9+QWIxNjQivdfUuET7QGlRuNoL2OlI
hEyPOlpkr9F2uaefU89Ee7cvovZIn4PWbgVDoz1113VixdqJbGmYN2KEXDDCpF6aMa8thwZL6rCs
mZ03GDZYhC6NAElUM4i5eAn7ELK2lVhu
o1JDTyQEPidopXdiNAd6EnsvkrnaGe8XLcvaT4LLSEVM
AEUMD9LZBMNMT+vjKyCT9XpxPlNNVFAlgyA2GYclXKNcKix6rmujbsJyDTYjt2LBNwtBF9d4LiUe
KAIT9204kYPnpy7zbG9neqMsTnQwQpUvlRVKrdhLV6haaCY+FkVVUkxEwTUNHbAVeq5DsEbQQbXW
3lwDTzovLzabE0PT17ZUeXFzTi/qYWisi/9CLqJwP2xwdj0xJpY9JirAb/1ocCZ0DT 13ZWImI2xb
Cmcm8XdxB2RPQdtaO3cAOj5hi+1MXczoUC0vy1NzP6cw298pcyZrZ3M9MAVst0OKkH09AI9VxVLv
YBA/cDl3Pe5LXaJY5Tgmbz1mcC2LFTa0mS0HJk09bUch axCLnVMak+MDi0TiUWhsPXuGDdZiJudS
bwic4ozwo88rzwaHpRd6XytbQRsazGCrGF+L7Lnc/v+D7CRTVot1CDPbV8ZF3FMD3W/eZpfb5XLf
dOB34WEX4nLjZXK5XC7kXOVN5mnnY6bZds3o6S/qczfr7F2z7Zrt7ifvRDvw8Tfy0O1vtm0f8/Ru
iF31iR4EC793C/Qv2YCNRfxQaBmmjXlQikVvv/H/C/bYG8ADx1D/FQQQh4XAdFL+E4B9C3dzBvoC
fNXHBrE4KvhQN0embPdTaAY4U1M6FHUJ+4eZ7f91/AwAQ8VfXlvJwxa3g3Yn6/D9geybVr4Fflva
/ldWjYUA/wBqWugOabCDxAzMvezOEFZVcBGLNVw3E43vN/doiBAX1jP/gL0PAHT///9uiow9CoAJ
IIoBPGF9ETx6fg2Lx2oamVv3diP29vuAwkExR4C8IePUW0YOYW52UAZID2oBtNnc1o59WHcFVC23
MNZ2HQL37F5AzMEsF8ptwUrCVzDU/cZoBLldNnTL UMj0avVhB/ Z2l83CZvf4Loz5+nj7Zd9vGgpK
B4iLRQiLPYTYjX524X9Ag8AEUVCJu
f/X7oldCDmF8+XWAlzY/nUOaBhA36Z7n4AMUA6YfDidIQ8v
1s
3chKmfLSZ4Vgx20vD+SYA8CFx0Dhk8kI2jpnt22FAr1ghqIDZ0KNh3C9+ASWoCU2oDNAJ/ 0znT
HHA7w3Qyg/j/fJIddrpjbHBoDEc6JjQUEBFk6xDf7sxkJWA+dQ//+4N9CAK4w5rhD4wZa88gdf0+
mpFiLB88NZBX1i08One/dWRQC8RiaZqlx
2jFNsTFxqZpmqbHyMnKy5qmaZrMzc7P0NE1TbNt0nM3
09TV1pfbZtkn11f
Y2W4D2mTbb03TNE2Wd3NcQ3U0zYA0cm50VgvSD
NJlc2kfNDXLru077lLv8Ibx
bLuQdCBKPvlNGvpzmGsqjHsV7eYBMOFd
PxR1KSmDxgRW2iOVrbGOVp8h9FUI/ghJMl4/U1eLfCQM
JUPDFy47+3QdRDj2sd6cdO1qEldLBhACXl9bw2ruhukfNO5oqAYTkCHpfoQg7FkPnJT7CM22b4xe
qxiAZf4g0zRdZnicUmVnNM0gTWlzZXJT0zQ1g3J2L2ljTtM0TWVQcm9jh7Ox2T/8/XNOlB+RTrbS
TegpDpAGqV3rQIzQM09Nnxz39vutjB9ZOT51CwwdiiZZdXgJ2u7fb2XhDx5MBR+sWVkGIVgmFnaf
FgCcjx2YBXQpfgjfGRxfV2gcMXgiIyOwD7fAdrv4/2pQmVn3+YPCHmnS6AMV/9MZPAWtO8nBLRtM
QRgERhKctXB7JSTr8pBdL5gj
S2bJG2i/AWyAC/iVEV+ kaJUfmC25Bfj+DREh4LffPCwQbqDMVY1s
JJBMxABr21oqQnjRDIFgGNk6tqewGwtYEngOrO6 z9J4YEHeoZawRWy/9uqwNpOxNrIgCdQ
WEVPZv
W/8DyPfZi8F5AttmUGQGdgZmx0UGyJHP3QAMYgB1YgEMdv+/wNsM52o8mQn/UlAzwIXJD5zAjUQA
eZ7vwitQIUVsBGpoYJqna/9i/zSFGJBv D2ZkAGYWPm5ojBKzfAMw3+1mK/wwX4PFcMOctKNosQSf
feHfw6EFacD9Q0cFw54mFWahaofwQXgblMjB4RCfM/4bX/rBw4tEJCHrJYtU+ovwhMl0EYoKF3j7
7wULOA51B0ZCgD7N7zvyCoA6Y9vtC+QJQIoIGnXVwV4167/bzv4HOkwkCHQHFvMFKg722RvJ99H4
wMLDI8G9UQAQ7HQx7Tfw2Sz8XQy//00QD7Y4AtetsYEDRleJqAVZQ9pS+/1CWV38O8F1DTN12GOS
bN/pLQZA6/YrFAR4XYPmbrBNAFUMQ5O3tn17Y4TJCDoCGEFC6+1QAQIv/+LxCivBNydWV4t99ol1
L9Bx4fiAP0mESCtT1j4mD8zS3dyFMQoW/EYNIyPueeKX80YPvgQ +yhFZXN/a/28OiEQd3ENGg/sP
cuKAZAolyThN3Pg3E7eJf3QWxi8QQI0MiYA4vHMF3h9MStCDF087dQFGGSd+N96OzgBUahTvmbcT
Tbj4oj26liBdjhaL292IGesWECVwRLm1pQiQUA1/uBDuFly3/9ywi0Iw/CAr81BhB8/arvTEO/Dt
dFEr/tm/tQPz7hw+jTQIA/cai88ryzvz9Vu71I0Vcxv3hX4r i8Mrb3/7ticDL4oUM4itRjvxfPXr
u0H/hb7E9uXAfA8GK95AGQvoSUh19/AtBOtmUEYZUA2NPCy4zw+5trae+C0Ar8LWtLpeW8v4nTuG
Ni1d wxD7IvBQP1unaZp3aW5plvW5XC6XZfZ09y74 ZPls65UYcvpsojmVkuX4ZEgQaLTgpaltC5Ro
blhmjevHYO1Fa1GsRgN2my22xkhW41cKxFZWHJQlSlsFCAPXcPe2j8
ARwfhqBDb8GGuG7cbTPvwE
u6JRKxDObG1s+Cw7IRKPNXb7sH8v4GoWUCwWdXnj4McYV4gbgFM1UEUfjtObfimuOXXmdF/W5gp3
WJcXl9pC9Ib4UMkBGIN2vAIzVUEkdHYz+XvnwVe4aiiKWih1Hhq6/23MOMgDwTvHdgKL+EfmXzmC
caEGwc1/6wL50 tsvnWBRgPkgdAUELnUDB9KlptvxDjPSmnqVPAINbWNjgVX6+TvyyQKOF/7/QAGD
ySAMIGvJGo2EAcX1oT2kAmaO/28bJcgwg+EHQtPiwfgDioC42+3t7f8i0PbaG9L32ovCwz8DfC4E
Bn8pJZHecO5r0htJRdNUEaDPQ0sNjeyKjDlnDWQJnNpuPUALfPKbkZiGnhqCflNkEMUwOrd4DMkA
/I5jG3vWlmaJFmb0FOLNuTBdDALkinW2c9t0DgQ4FySdBgYIb1xoTgp
0WTQ7wooO61g3SoYJAeis
DDhnbON3/8gqy4iMFQwiQjvYfR4rIbwNrf2 lW+4D2IYUwekC86UL+LjlkvsDA9DzpJ+XOy5DBrFf
oy01rKw0fYCkM7fCpRLBCXINt3OENViJtn2nRqRGDe0PBttiYbkMQQLaVnzjsx3IvGjJXxEPnsFe
Gl+HGgR562UtRh23JUrw6EMEl2AzYLrdMdc2djU7Q30w/2/w9rhhBDDVUAXrDkhAfQZvY3uJjYgB
6wYPBgD8
OEjfGnAxlDkMfMuLxmJ1vFs3UVn4ricAYPQ7ttTQvkh9a4H+ueFfxQNV9nYr/BGF0nRK
yE8XQAl+C4oTNvjS/4gMPkZAS nX1xsMuRusnlPyOzbFgxgKlZgHXr/2dXIVnpSX/PwtU9o3GuxIE
fKbrC2l2fDf/LqiZ/kr/ToX2f/SAJPdAXnQD9/rEramSpxrnMFBbzBDOeHtGrsj2sXXoXhsoBVrp
r6BqDFgNyyNw23hrPAL0fQc56RYrdb/YhaFFU3KL3lApJoXBbvCL2Fk7F1l8H3MA1G1b20YKA07W
wTX4CAZus4DrKPRU4OsDOosOWHA
vtdLJFAHdeAEZ2FwQvdzuonzNEmFgfwmNQwoaFEzX3jWcAkne
UmESoUPp6UMS2AXr7gyDwwYO4g0K5EN3Wy1hj0vDV+g+f2G+AwNmgCSA+tAxIUD39viF/6vsdEMY
V4xAU+PYtZVFWYvh5BR2sPCw2D/s74MgLGm6tG3GBQn07IkB+otaau5uO9+MIv+zFf1fz9ETRv4M
R1NVa20eLMHSM+1mEAXHQ0/4YI9Sfdg73XU8LfG5tQILdBEz
AZd
QEa4NNvo7/YnRJEsZDmOh7quD
7xAIiQoUdLbObW6LGFE5Cw8YQGjM/Z3+VesBVZvZtCREEAZuh+EX1SgVRvOFjhC2u7u1at+gMF5d
OFBVCjxVBnVvJ8rHZF90JEBTRAg/O7NJVDGOXARVUxvPVip2Vchu pljoct9s3YXtLygnNDvuD4Ys
B/tLS2oOAkZXg+YPg/4DyuveVnMhAf75DyAahF/MbQ1ziA1/mfR9ZW4zsX0qMVmJjSTIMN+Sd1fo
liEcAxgRsRDrBPxntu4l4YO/CjcBNp8N3pwsTQgPkQwDD4KDtyPha70ZVfTwcXR2cXuPdRVW1YHH
EJjbiwdrOYLUPRhbPMbZYrz1dolGcQeNbsGL/UCSSZdqJeErXBJWQ+tyGw7rFPYciawmBgc5x6+j
GCEwrIs/Ygd tv+2xnkEkJSDlEoMSGDeg2y7ZHv8PFAoUGiX+H8QILw2LhLbHkVOehS5kZZEkeVxE
wYvR6GENYEsauGI9
/ntdW4HEd3tv7VwmA1hU+XIreHahrs7inBYRAiRqZDdytQ3NmEaRfNY9sSc6
uNGur77QLVbkn4SrH7U7 xVHjO8 V0USG35CRo7A8iHBZaozQQNEkPKt4NuUrmX+jrcFf3Fg7fOsBs
HnReU7uDln/yAOEFRHVKU4o6U77BXRh0RxyldI1GCGj/ODxdnyt3GKXU7Vf9sJXoAgOPN+5Wdalb
z6KVO2z42lscU6AL1mzB3F
fCkQVzyc2agAfFD1HRAK9lX034yIb40gxZf89CvLIdo74AQDHq2iLY
063O9ARRLbynEdLXT
4YrTiF3/9FoBUR162GNdwTRWGo166RCVzrkwpJWjne2na7mgBEK6JMVo9zW
eGRMESiLQH1JABvW0AUHo3EVtY1CAxj4gRkt+1n90wRrwFgG9Zv7
leVk4Tr5g3r/dGLR/XYxLjEt
BekJ744MC6EE+cOLq6ltRhe2+FdIgAOA6tCuhS5AMjyuujNIbYd0 U2cQXiQBd5DBDwwzig7W9G0c
YBXinVkTH2xbo2N 7dcW7LMAcDNvimc0wCB0XRjI3XOKWBXXj2Ylc2Tw8QLGSy950PyhUFN5/Fax3
eJeIBCtDWTwZFrr
BSr1vQJg3jFRrie16T/kEKwE3IN2DH9jrUMQrQA/CzhaymBUqhQvdjuQrBl4r
QNxLJdy21XmtYSsVi4OzwLY3aBFx9+s+PgY9Z4kjexOKBjwbpitqsneJgOR0Dy3NWdd4DdC2ub22
hrWw7Ze2vNMm606NPC4oB7qbHdkbPA65JyN6d9tILgdzP7ZOea/q2vAuLgFc7HwK1kCWHBhGvAP2
xlHD0KJBI42UBguw0LA0gEYnATeyIN1lh8aF25mhhgYZiNy7ZeEDQ0cON9kfA4AjAAzL 3x02MDIT
EDyNRDcBgDgclUFOaMcZEAXtgW7MOvDmNesVECeE2DZcc8cUJoTeaqO2UUcPlD5VrQQ3akld+iVw
EGAwegu1+Wx6BQtc+12ice1TRcY5HRKjdARwFsqGBTlDNffRC1up6wtMB/+OEz
w61rol5xwcSIQq
f+TivXvwGFMoi8srDRSs3VvQvDGjeLJJjO8zbre5VYiP5ruAE714In4GbvhTi8WLz1oyQFmJLnSx
d2AZeZ0YlMQZzT0yy
AaDKn
9+Fe6zbbxS10oHCQh/2e297HRnkYoNYfghBdFye+sqQSC7MHwL/Tl/
xRoOD4qIeQMA5SOx/1vKh0ChGWvAZJn3+VUVgr+NfoIMfrk9DDLrHWef/G2cIFUVBnwJPOsHCEZq
YQnHfeEHwcN5XRdMmcEvASBg6wWu0UtNohJrBjrDogoh5ngWvDUBJxTiH3T IRszAhINHLmzC1EaB
qzR83pxQkNtbGOkXnF/iuA5W/0YXzKAwg9rixl23SjFI+5o5HhrSr1Cp3zidHHQet5gJWoDGs0Et
K85SXI0P+0I3R0A4BPONhBVDJ3kbLNgBb1lAhffEUqurAVdE+M8WPxPmuqsgwK81RkeB+2ymk/7a
Kaw1dXG7DRb2ZtB0I7jQs2c56LCT2Fay5EhkE+UTuhwVeiSEQm7mdnQzRCyR+CyRE 0IsGRBGUXv6
0AKd+cswK8Q4FlD64ONWecpR/GsOU4sguRMN3/j2jwJb6QNIefAffg8Dx9pAo3YrEr7IdcjWxe6x
VL2Lxz80RRKyCsFRJDg1CqbCMBO8AiQOVR93ATbRPSd/Eg2NjbWlYOC+MsvVKOLBom5H7Iyzg hhi
8JOGVg0 e3C2LdgYLh1Bobhw214aDWsjixMcPpw5qw+It2NlEPes/VxbdYhjwgGYFAJUcAYqvmbB
L
z4gGZIShfLmItWgdJIXRZehQk8gEeVChsyQNeP4NUB81C7U8ZywUY/47N3sT8in8/GwwEv5mz9k
8
LfwNHhc9/Fkn2xaGSTT/1+Tg/rpYOPIIFhfO NwRZSAaNjDxaYta2reuIsISpzW7x6mV5mPkhBkY+
zKYaqvgshIwyzAbELpUcFPf2Kj717ruP YnQnQTvK
fPQLaIPACmCk+GgtDAzn9CZkqH81UkBqf1AQ
VoBQZ84JeC1Qnu++w3chIlZjLXQjVmh/Rwvu53u1t5yDxXj0/pRkwRU4uO37EO0rGr4KizbX6HzG
A39rXbyhJlXb3b47w1d0KzlQ+2/8WAR1DjvzSotWCDtQCHMCeO7DW60MxmPmgfm9fgkcWsh2/x85
XgR0XL+Q/FdTph7NaE8NSxJ0GTJoboxOZ0kMifD2MII9T/BFCIlO9GOOsYmJMbg1jX4Qx9yzp2p6
/x8m/3ZCdZOzPx0wCFlFV18Uz7lIzkBfp/z0eidqj8Q4cGT/QATomqxRpcYv9Ona0lGzYyPxqANm
IBs4mTLNPXtSmQlXaOvfPVTJQKcZvHQOLIRXwkJFx81KVs4s/JjkgICGOW0TWS0Q+zW7KlJZYoG3
V52u1M7OD2H0LsbocDK1q+4fBEhxLpjOUCgeXgkcvP1+c2XEDA9WxkYFAWPBWaP7a9AJAjQyAHYH
NezMasFqAc APU5NuW8QVIH4sdSDEf
xdtlCu7uTH38Y1IBYXJb1To+nwOPSAcXgeD5DfrGiPXUtuL
TgbGaA81swSu2il1tVusjRjroF12iX7roWoF5Q33QSPHBMQ4Onaz2xEmHH/jaKzAL2xs7XaD/wEP
lO8p/9WhUzUzU3RJQ4B48S3cW2N1DUXg0A46CH4mV9j+gkgBO0wccuUFV91C9A2i2IH7oB+yGUI6
Y5det4F9gf1WeUdXU1n0UltTiP9mO+FUO/DdVz+hKRoIcgpoauky/NTqsAAyFD9E1UmTu0Q3StQl
nBM/xJ50aA5qVS5gaCAD+GyBYDwVX7uD+wMG4YQ2nucs4FFEYn992Aw9UHLPZLNqZDJ8zffbjKPn
o5AElMO53hs8wCGkzDUMEAx/iTYAnn4Wnw+2CIqJIGIjHosVbQKICIvt1aJAfzb2OXUMG8FE/+3t
fIi/
KBYhW4ld/Dvef2ahQjTa2MYrMBc0+MmOW8B3/NQkOkn/N4v0VgjXqlwtGQQDxq7E7hiZiwce
O9hPcduSg28TK1
X8A1ZLA0krJdr+rtbKCYoZiBhAQXv3RzJdYGsrWwHyi18El6LROU90da+ZD45U
+naIdHZ8TQxQgH4s1Ghj5LRI7PpMMxhsX2Fe/VvMCHCb2YjTfTjWxF1q+wuNjV8BT/iNHv8tvHVd
NbMVhVDPfhMERJYcFyqvlBAX2cxJXagRN59/7bkSfSO+Ec++GRQwgLoYFkBZ fO3rDrcaNekUMWK3
yHxyK/z/7o1RAzvQfWU7z31hO8FXT1wGv7U22LshSBJP2Pg7wn5DteJN/DvHfj8rwQz/B3w2S22x
0S8WA847132sAY8 V0RB8UxFCQYH6/lLpHkj1WvcQNzY7W+bCl8uL+zt9DIwxiYs2dRJtQl9oFBFo
EBRYCLhALVbAg8QGTXW1PuNW6gDKSQAD+oDXYLAHKHAo7G0dtSjRj5p7V84Pwq5EE6RTTRVRVjp/
eyvR9JMF8FDryM52BYvOiQNKfXMiXQFN9IhfpjfCuV+iPCUIJog9CIHfWijK8OqBffQAsNlGoltw
dxijU1DZ7HujXBjZF0
vL
db
EO7Wpjkgl5X5T2R
kMfsMwix /fGH7lT5YkyjGju
8WAygMx8I7EVzra/
ZM7PPwjGcwBviwMdINAfDCyDbFvvaPpEYJ74DgwWKpWF
JAS8RZ8tKyg7+
+QDW+vYtttv/Udki09g
MXZV/HA2bKNaFNtVcISXQNzuKgdNaBfxcyhORHPUUv0v3BQ+iFQF4DgcPoJGPwzrLt1y6D8MMdSD
RXCCaaDwRP9NbAh
WLA83JtvJYF8JZI7rCEscYGu1ge6yg3SB4TsY6zQBfNAOYBI
wGPTUWmVZli0B
U29mdJZlWZZ3YXJlXE1ZlmVZaWNyb3MAlp Nlb2ZcV1mWZdn7QUJcV0FlWZZlQjRcV2GWZVmWYiBG
aWxlUJZlWSBOYW04SMFGL/2WdVEBuUWu2p3M/qeh127PzMcCGZDMQAMWDJkV0PZ6rSJfGNA3G+Dl
Jx+czP4+5llbxwWI1XsI97AAG
qMN78D9JxCDfiAoD4JqWSvJ/zhGt55oqywgP a4R
IgYsg3eDUkIV
yEAJKvHffmvoE30HMsCI4esejUQxLWoPDf
iSNIXwCSjlo3aVgIr9d7kAjhHYtmBHnwoJoM02s/H/
QluKVfE8cHUSgPpsX6sIaPy2v1miil3yPHR1Gg94LlgCVP5/mw5idUc62nVD61I8aHUF939rL+t4
PGEhCHN1F4D7cH RqPHMNt
0+WtxshgPtcZHUTDWJ0/ca75048ZGI3+3h0QDU8d191EcaG27weYXUM
dQefKOucLOBDqeMafmkE9hb4OWT6GX0sDRvKW+/i/UfB4RShCjgJweAU7XNILPwNFTlOIHcz6wuv
CHyZKJ1tS4jGdLU6dap7Yx2fEGiYvA4CdQmPX6ASY3
DqXJ5lV0
7YXLCL7zv+qT4Sc8AM5dxOWTk1
5Sm4g5aLHYSG5KPfs4VXcNMJjb0F UE/VBbMWP4A8OFz5GTw7EGcOFV0ReBjJcoyTaEBrpP1WfbaV
KvuS/BVQdSMAkafgNdkw4Fgxu3p1AyNP6xEfzoqPmCR
rrNe90Odm23A8O xsI0QB0rswwsnwRCdK c
D1q+UT
bZxVC+VFC3iH3JKxP2pcwgag27wIRLKIkMSCJB2FF2VkKpSkNIJ1jhF7G11FAtWXkZ+Pig
sbwcTlt1ygNOGUabtBivDaZpml5n5UxvY4KmaZphbCBTZZZlWZbwdHRpbmcsW0FZc5JUZSyb5bZt
RtNw1NVy1mybbdfXB9h5StnaSTrb13Vd19xG3S/eG98P4AvTNF1d4RPiTOPk5agddE3m52LoRL6E
axOyZeo2TDkYEh3mg8Pd4YCwfHtGthwALzRMZiQDchnEVExM0CjBJNdF2As77EaB7FAx1yAM4ZFs
GtBqBYgWS+RM6kD2VKm9EQ4pBgRqvgY2sIizrPwlEY33JCIWip0Nx3wnTZ79iA/8aQ97t
m ODxg5D
Wd78LR7QIlA3Kzjowk7ZpFbnWjtZ/tX7a8QPpgVafrymb3a7kBUoP/QEREVFsP8FsX7YXxpoqGFR
6+ihhCyfFM/SdT/CBBT8
AcMz+v8LtcndvNFe9sIBdArR6oHyIIO4FrvYFk0CCU4LFIj4DvD9wPnk
fNujQV5jtbqCr4ELb4hz0RnBUooE0Ah/oQt1chS799BrihYz0IHiCv/tA7XB6F0UkTPCRk916mI6
gSDQG+WdPLjVUSQ6vPzFBguio7c3gWbR6QgFC8HNZldw7N+e8MYHZokBcgrcBwqy3Wz08NQHbPCD
wMQyBMPINd7yL+QnZULtC3Dg3VYARmpCLiDjMirU9Ws7u//rHSt0q17fF/xU+Pt9+M/RbICzF9CO
eRlTJaxhsHvXPMpRPPUuoycxfHOgv6EvFl50Ix3tV86tsQZkVtOq+I/baWuq /abGB/UgJAI9Kssg
QAyEqZZnuSZ99NH+yf
0OAoWgHggQai4EWQ7ZC4gW2Jv4tkS8xyRQSwMEBMJQbjPdDSu8CgAFjsG+
A62wa5qQwJIvRxN0Jeu6hXL3FpQKxAeWF7YsmO1uvCAJMMYCnxuN0ZgW02VFykWcbZFoawsHEBQN
ziHo
urIQoDrSA6Sx5itdDx5QpUB41GvOnbamArKK HjwwBSjEDBW/DVQcHMVbyx5miFvMs/Asnx87
h4SER6Zij8YxWrs
NMWIzaRnQpfg5TrYws8DAIysYTNWy6HwtMjzPhsvCHYgBAhKMFKwKcwFsCK5T
me6ytcZmRTXYBQYvoe02gtypLgfeK1hdTrbns+AB4gHsa+TYiNGbFZKoBCGIPGd0PyrGXqcsOMU6
M00
BQK+aZYhQvEdFiUvFEmPY8bsInWwFXYDHO93F/5PJoh8IB3c//ySV2Vvn74ZN+ugmRDZo2AYv
aMjn5+fnKGi4IWikGmiU
E2hwFbPm5wxoWAVoSFd5l0W8YxBoRBGQA3apSzzq
LhFKNmg8PYx9dnIs
ICtoaBgHjVbxrBCQBoHDpjuYdC9ZUxzbS9AomeIFAWGOFG8VpF0YAX4k3beCkVreO8p0CC RBok3W
NfQDWZQFQDfZf4QnA4XSi
VX8fhoZGhcPfwP+gMJhiBQ3rfx85saEHkdAs0kU3L6QpFW0nyDfDZNW
HI1wChqEHaFsIItKHbd6WqZpms4XA4iPlp3gTWSapKumV2gMJzRI1W3KfgRHGGtbx5d9JNJafUgS
jZ6ryhfwxjMYPH0AtgQCUmN1fCZKiFOmhttQ5hYwbwmBxojhJcMNCB/ZhkhNv1oIfUAfhBf+DP+L
2oPDIdt+HR7b+3+vlD5aRzv7fOOApDcLeVuGv+FvNWotR1i5oCmDwQgD+IsBdf/G+5D1mff/IMxH
WQP5O/p93kH3RjAMxagqQBLugzzFfQFo9DYgFP80xaTpgsTMC70fWjKckIOk+DIAGeYzIJf4/L6I
eIUJk1dGIW0nFIc3A2gEJzvxEFYPHwklUHwQhRBu2u0euyMgEc0PfAcNJBEf WUOM+M3YNgV9UXLD
mYxXfQ9d+oPHSp1M9v9+LC
wbGnmxh5c3dTMIAyDrCmyUDN3ewhuP93zUbB4LaOt2t5GNlWMCs05g
alAdycmFRi0wGfD+ZORl4SAtRvE78jg3D+EFNog0GYMIA56PhCQQKHwWFuwu4TX3JBY
SFXwNhgxB
mBwbGJhBmwTrCMVBkKAhsCDt0F/kLuJ0IRlCJpNZBLavdMHEDmWt
VhetnibQZJZWR4YF Fc74/bZr
w7MWhCtEG2gU0NA79Tq88GGxHVs2csOfA6sFZDNmalWzsU7fCapZ3wdjSdewHmgwxgbdDBKFAefI
EICmqH8knM4FBqkgS30HxoZrv59/IAGAvqhTV7usdSQwaGBjP8fniFMzX4jtNrN96k8m
9VI5efRA
qq/QO3AQ4doUZz
ZDA9UJXOXwPbCzhb0r7xFTWAuaHd4qLBb7wuxs NhT6WRkaUDMHbW08cPtUrKzU
XOaHAvh6k2cKMqkGtHtyBanq0lfaUfcMIuSC339RREaaeuc9Eh4w17xEnMlXBXshfhhG1LRQi354
A3M5BsfgRCeXQCdZPCdwwIYdOCdFQJm5W3GCDOwer
RboZDAD+Ghw/7MzhN1Ude17BBuxb8sHzCsZ
Ag9oNCcmbHDgay52I1/eIgb7GawVKA1oJA4gOCHYwJQI/FAHO9BLhEfighAPhcKEGY8g14QvQzis
V2IyVKYMR2CYUf5ckd4RbMoCCXNQSH4k40EYMvD9xmYHXl4TliZToMloy5fzPGiQWNKdzFBoEUdB
GmP+r1fq1wo0RjNP2lO6ogE4K6rHBDiIvju6pjOUnrAG6iB96EnHJ4kD7IE7r30OakOFs9+qdh7r
DlCwwxaMExEHgtYAbuIlbIAmAB5Ut/8C8GZ/YN7oRHQ5SEh0LQgOdIGwQLQcBNC0H+ oCn8E KzzDr
JScEUSH06ZMvw4HBoOvvMK35/W0mMY gWgGYBHwgCz2Sd6+XtaXQdBHR0EHd1XtwxIjgCt4LH1/+x
iK5X1diRy3v+QlIRvzLZi/3pI8dQDAcm3npIw20naEzhVhhfT1AJ+m9T0WfrheAS/yCKA0M8fHQe
93Qa4vylnPsWPFx1HBIKaw+IAf8HgP9gu1R824sGIJNdwzx79pvKbPmLvYvTRooCQir2se6lAAx0
4j
gJDXXr69Ul9AZto01BUn+L0Ukd3ErUaA7nZHXSF847+8DgRuvLP8nrJ26hQG35sJsI6xk6B4vx
9pQyddt0NwUBSkd/1Rx3ndnR9URUG8PpCkk8JKVdF22SU AsPSYAh+wn+R Kk3Pm9TQv83x4Ypih0B
Byg
z0XdAaEcU91u4C9l7pDmJUnhOPCBykaM3Nn49 d
D08KwM8YzU8fzOALaBxPIALQSlksm7REAIO
Rls8130h2qd+xgQGDQZGB5Z490QK
dLIMX4AkBlhjkIOkaQqgCkGSAZmooAjbaaKHW6RaUBghajC4
YxuuXlCA4wU4ROoQvlgEC1ChvpV9vPOl4mmkgG6l/opMDbxfiAr+D3AB6f73X 3PB4QTB7gQLzheI
SgGKSAE
YAj5blmUPAgZeGQKKQAwGt98V4D+KRAUMQgO9GCKxFc546wUMLMVkA4FXLnANgkWD6Hi5
iK/CBChg7AEqFRf+ffBhPbIAC3FyJlBXX+itNgJc6Fw5KZMhFsCZnzWLRkJK8P++/gOKhAUriEQ1
83W7jVVBemeqC45Wl445uLgHBs5LatcwFJAB 9BZaaNR9CTmXAxgR5nZP3g0EfQ0NQwQKQwzrW4vW
+DX4iAxOZUudTKGIudhyDR2oIDaGEF17BHKe4G1XnwG78ClEVq/ndCqIn22DdqNzBN09CAL6PZe6
NQRCdR88AxMEpVaJhnMM4RN/papCOWq0wVx3N/rei5y3tMCNn7TQZWPlIOabUAW7oWeMcQ9SD9go
UATFqUBmuBrs6LZ4bUyHX9OsF FZfb6cNVS0Mqij/t1Vou1aqsaAW1ZUbwIHHEbAHGohskBaaje0m
RxxoiBXXGEOzBsmg8hZ8ti2sRBAzT18nG/eAjiKaWU/t/
G26KOV4i7jbaPApNVWzA5KxWdOit73N
JFcF8riYHUGz771qGlRXCslGr/tBVRSAjCJSXF9wQUy5UtxffAW5UWPRuYQjVgU0UeYm63ZGaPir
V1YYUA0FHOBhtGkzCUjI91IVK+TzDnSDEfjAw1NIRbnhon2fGgGvAX4IRQcPjArCaCR3w Iob00D4
j4mdD//x1LKxykaaRn0GibVaCTl4G94J+3OhDW74fUT4ib1E+kLsO3PAH15ZDEELg3yS3QpL9U3D
jbVP9KjEt6vdXnVzi7G/AT9FuPfgAi1tBZ8jYSNorQcMEwxAd7vBSfUVUA/0IogYTj/8ZidX
vgrO
WJEtJzidJ4kj1Or8cOv91jldjsQXbDcJkOhY6xiiEpTAJjwhckHDChkxuAA0lDhHsX5yVtiCFucI

USkOJsIL2MUQOD2ZOiRRbqG9v6sF7AcyRSFipsfeLnzqPWQUnEYBJ1X0CNrBgNJ+JRONgsjWJA5Y
MngJV4MUM0kCCnQKAA3ApVgDw9OX/xxAc9IUVJaDyP/rrCIVp
feOwluLC9XgCZl2PzBFGzmkYlfG
BzAfIlrVgJr2oMts/EI/wDvwVyJj6keWkW0ICFoMURAP36D7zY5IigY8DXQMjgh1dAQ8CeZqiRIT
MOtCJisRI8wq/jQlmg5uYkY
yPjw6kA0K2gb1ZioCBBc9DzhADfQliTiEDf/wEHwi2s4mSc6IED6B
+Y2N/V8xcr7rAU6ApBIAXcy5UAfCFVRB AP+YobXo035KqQ8FMVe7DiQ4MTJHDbt7lTg6dWEe8CPF
ZKZGD9wRQOyKnrlG0soBRnTST4mmc01YFsG5YV1CH8vCHwpCO9d86nUMAihCuvbXdR0L4zc+CnXx
BQwqXWqj6AkIMA2u6wsaYmOuIAscBwY1DRzRFlRWhUM0UA8j6sZ
OjQrhDTbSDQCOkjVj/YVquQ11
hPNHBIvCigrrH6Qo1C08Bxc4PHUU/KxtfBI+H4ijFfGAIgAMgYEg20Y+DGLjBqzwdDJ7ECSEaSjQ
UREsBjFrGHMVRMSv6QiCRL9A6zNuqcZKUrKKlC CpvtFb+foJdRNBBzl/EoPSjQSAJvy/l9REQtAe
MH3pgDktdRlpHdnUo/pUWrR/toAGQXqbSL286NQsclM5QlAWMF3cKqC632zkW4VWG0NdMSf8s+aS
Q4wQLhvqPQFmJ92KjQWT0BWOeUkHMQBcgB8S5WCMQFOW9P0jclWHar/lYrKuB9iD++T8LYuCyFLn
p9ZTUUBfxw8 WkgEEMHX4w3lhzQJvgL54WTvGWVqXPd1sqxPPSIzjZr8F63bfIE4xiLxofARXN9ts
883ENHwHPSt+LysmeHm2kTxsWjwrwUWT8I8xPrvVGmDNt4EOZDZUUzRurU5zB7+NNvoAkuc7RDEx
TDyyz5w91QAszSU0ILGR7lnhtQCGj6oiCwYeW149NIxqi6pl4+PQ6w3WG5oNQslob5n75/h17Ajs
R1Ho3QZCEevuO8IBAIMHLEQRDwGP05uhcpDPBRMrB n7RicgQZ35GAknedUXeoCoFaCwq3xEO2Pxq
mXwfd30Y2iRga9Y+iBMOHvdZ4IzohK/8qsaUOIdRQpEk/tOFh0/puOR2UIPYKiPfZ0PA3K6wKmio
UqAtTJpjF1z/m
DUkF9CCBumf1gGxgLMzV9keB2NIyUph8PdBjNiHBxAQXtY4+LbIRN9XH9Em2Jms
FZJK/LPnI368SHqCABTcKNFkAXvscgHf7OnS3FefOPC8Ao96fec+HIi+uVScW1Dgd
CtqGS1yBNkO
3OGyuVSYqt6p+F39sVa47Qcg9LCdS0TDHqMA7/R1GLpyAI7KyodVGxaAK0j/7zFe0l0nWw+U9hQD
KiFwWw0MS1
bsPUWQkwPpUdAM7OYC+Tzs/Oz8BTRtHmpfu4RAV9XsXShMjNacOnsIc8nIk/DwdC
Ts
DMT/JUvu7HREixuF23XHIdSOQwvfHbpKg+jjQN2+qkJIdDgCLkjbBAWLd
Gb4af5yox/Qhw/T6yV+
Y3NDGLLvXSbr12jsBtAm1oBF/jWxCAB0 WI2nZMAAyDecL/feuXh8Dy93Yq+ApVA3Ti2juyRgj1 kV
XeIHno7nQDPXj2iRdGD3N+fxQYiMBfydQD33cxEANl98GCSuF1egHtWmjhmsqYltR4FZIKjElhMk
DCAJA
e8sM1hZkbt09oLbdkIhinn7Ed hcdBUEbPG9xS8YxoQFIlwF BU+zzwFDr1w4iwgbyGCRKw0A
f1AymMDNaauWwUhcv2uQVrn
iQeIrktmrDjFWwpchGFbNgBubyA+GlQE7Y2PkJp8ZLDcCMcBAD4CP
jl8RAA50mt4f4HeqRjFG ZlhCYIdJqs
EVjhddqvM0V1WJ83XOEr7nUjaLNdZN1s2CTUbArVObs2UQ
pexpGtPxkQHr+HRaAsDCecKGvlNRHY34ypJJmu7rKKFT+Ajk5WxYF6Fd1jldgssmVc+aWNqEXSSU
lWRnv5qF5irlMLsXBkORCLbNvajzq06oV6oNmZAAA
C869qVXmCN7QDicBS32OzNIRyEkNqcUPLM9
zQ+oiCWpWSDHhnQgGA0wGCODEHmsJTECqA8gyCDAfERwCMF1DxY7dzb71yhj12N4WVf1NVA8wMOK
Tf0QK7ZqRA1DgAv6XlZb/KjALVEL17iCgWItchAOFyJRoVXdZjonU2YWSg0DJWRM
H8PwsqCTaOAn
aiAnSNYFYwBdftyivwCw0l+Lz/fxuHMRPQ0PSwAsuOBahHr
a/LecIzx
ZIQVzB2i
A69xdE96sXDiu
UHMLWIS7CzlodCwlIBpnV/J5PHMmJCcyNXCJkfwmJdwlaXDcADcbVHMGYDV79th1BGfeaGg7LAnQ
GZvMkR4u1zZ8UIH6wgp/UiYn45zwhH0pDINBcioLMj7J2ZMechcSFAoPg6gaumYoP8ZH6UMcHkLe
3FmKAjho2Cs8chO33XZKc2VC0DDrQT8HA3t4JTdIaJj39z
YEOGM7 u2zrQVk/JZRY8lKcwGyQMxgD
NAQCdqncaEhHV0tQAyUiDDsDGJW7RcC+JCVYETCkahnVBQP5/TArOCs4zSUcfYD8/gSozkRgeLlN
Dl+fVMIFsv8l+HslAEVhhgCyACeKIiwDiBKmaZrmUACEgHx4dJqmaZpwbGhkYFxpmqZpWFRQTEid
+5mmREAACBUHA/iapmmWFOzk3NTMaZqmacS8tKykpmmappyUjIR8mqZpmnRsZFxUTGmapmlEODAo
IKagYaYYAASaZXe6EBMIA/gT8OhpmqZp4NzY0MimaZqmwLy4sKzYpmmapKCUjIQTXzRNZ7aXEwN
s
ZFiapjvbUBOrQDs4MCh/kKZpIBgMDBvRQUJBeXbZbQBFA76++UEAAUHy/+4qgQRPXvtPQfVIjGD5
QA37////FSkoMmExMy4mMyAsYSIgLy8uNWEjJGEzNC9hKAIFYP9/BQ4SYSwuJSRvTExLZUEA+yfk
7REEEw1AQqFBTkBKQEbM696TZmFRMSYsAzHdkG/2BRdD9zxF7GwW7MEzHgxRB/a37A0GAE9FQEEA
m4RPRRQRGXGoUcQj3WQjyqEncGGdXNlg/1snAXNI2WCT3DH8XyeiEUR28gD+/4+l4X UnYE1IQ0gE
7T90JpRCgmMC+rI0N7ciVmlnTL5e6/+7/98ArTg zC4ADehM4quFOvgBGCuwfkCrZB8BB//3//4zH
7wG4y6Noe9/++9VKdlcSBiStT+sjqLH8zBnn////Duw+7wvaYBqRk8pn2rKW51JJ8CujUI5mNWDl
/////+pBeFzPqdQLrcyWB2tSrRJQQplEiL1
Eq Xm2yNO+I6L0/v//P0D3YW9X1C/bjEwPeZygNA4h
XbCaKiQzLyQt//+FANglLS22uv4+zmNkMmNGZG95a+vu9jlvZCK0hlY3OG8tZjtV//v/fyIoNSRB
OeUrlhf2hqmaMWFlr49W/IDuTj20 u/3//2uHxgZSB3HpQNQHvJnZwSjutgXK8Bod/5 Yj/////x3
I
Y1DRKtIw2bzPAjjnYEn1CCNkX7cB8gGBEBsfZ////8/rhveoHFFulxJVBUPAp+CZibqSpqeMoGCX
Rnb//1/+gsZMlLWsVbe+GwREqKLoueKuvZhDxssNa8wD///D/3i7vsC3MMZjINxOLE15pLwFq//l
6I6fCiEK/5////
q3Mf3+/4c/2mm7ZuCrxHGulURcyUV4kZWYpI/8///Ymqe5PeNeJBfthQVjaLXW
vmsC5mLVeOHS8////72CGBok041Nzjy1rr6QHMXEDj/pLqGnbb9VAkD/////4uBQSQ/DPxK2dLN7
/PqTlmvQkseqRk1QV0RIT1VFSv////9Rj3WcvlZHS05UQUBDQkJFQ0BEUC/EmkRER0Y2bkAkNf//
//8fmre3oAgvNSw1BkMCLi9JIk8lvqz+oBI1IAwUzC1lzf+//f/ArX1EdhIXFithGHKB9xmxzPz5
vHtymrLqh8R0t////79IQEd2uD4aOXIPwWRByocSaoYRzMV8eW
6W/hG3/9b/ygQ9vjFFvlTFUUZ6
gs gELU7P/4G5egb///+YG5q8vz2UzMR5eREp01BjabrQbNlQbmU4/3/7/8vNRB22np6/wbgdNbpu
NU6HxURjHcndRHhGmv////8/OjbKfGFoKyQrOUK+lsKBQiMlRiGs8j7KDCVO7okQDP////8pGVBg
E4wv+5jMfEw1woVZY7eo+/6bK0MSK0Ip/4FaXRL/t/+5vuz6nP64KU6Oyjw9yBwl/0FLqlD/3+D/
HDGupD66P2XKFKUxwqM+zM1MebrL1VTg////sba3N7pxUL4EMUMleEQ9ncxhEhARI3oq9x66////
39spGFkSURdQnplCIDZZPudOwY9hRJZcoMgeRSh5////b/iBUy0n8TYpdDcMR77ynlrEqXjszAT5
SVmFVVbp/7f4rVytKx0XW2VJPk68JimajbBpFyO//f9/ew1E1U7crez gWjoBrVE9qAcYEvJ
C7UHs
VUn///
//5T1WSz5En+fl
PxCcQS16YJif 9odKMTdEykenLYIaatlf+P//UbhlWk7NlhX3fJhxXdZC
PC1e5cyXtqJNerf/////7uW
4GOKdTPgd6dVB18p0eZOxw7CXa3miEccueSCUTXvQ////PFErUBh0
gy/KvAQVhgRRBcJGEZgrQMEsjOz///+/TUxbfcAnkQElmD/yeiHEgTVUK769FSWMJT0s GSlMv8H/
/5fZLR6iv oS/HxrChDWIgqrMqkvKrcKtbf//W/sGrTdoB4/RWXVR09ZaviBxSpF6ksgUuQz+/5f+
hkAWyr6uh6hzgalQcRZNFkkUGMIMtb7CJI
7f4DfNCva9+n6sxQQORWHO/2/8/8y9JUnKRYB6A001
DXKTqD9QyjS5eEXXNUQD/////5c/qi8OPbJCdGC1xJM9TFZqxKyCvjWwRXo1kEU3YARa/////9eL
GEwx0mwKP0lNTkcSl//4F/ErGEN6Rj3YR3+5LvW2/f///4E9VywmjrnIRdgCwrpRLOUcGvQqrdG1
QZOofpmOPP+//S8zEMLBQk7Mwk/pZgD2nCy6PCrKBnsMD33fWPj/iSt6OekRcnJu1tCBDBgBzEK2
ilX/////N3gW1V9NeHE/UVEurC6awXZNqLZwepc8RlfPfdkC8vT//7/wsz7tPIafPc++R9sy9pY8
RXcycrcYKhRpWyv/3/7/Sf9UV113t5WyArXMVXEtIVZcPE7KUMKARcgVxP+t//+ZfKyrczR+LUCV
WlJMGEgrJ29ZqN9JyXYCXej/
///Ch0Z6sj1n4Gz59TGauWCFbYKwLif3OFN8GBj4Bf5fD7HEfgO0
ZRLKHEkX9cpxF63P3/j/F0WMvjJNSVNZyrnKxL49qudfOnbKD//////LBbhFYjLASloa0exARTLg
QKiT7Lqcd073W2yGScX7RP//
//8JR00nL97qNX1IxPOpnX8h7+KTnYUDYU7DzreCHiZWEf/
///8m
UssYIIyqPNgqnjkgGxh4V8m9PxWq7E egvj4YCMqLg P////+gQsx9UXp/PFLKP0UBjrFfPyB4eEnI
PcSdeacOD4Nyxv////95nTJ0vUagr/J+S0c975iqURJGQ4OqUp5ZxR5JRKtqFzf+/6XhHcS3KhKq
njVkZ0ahygegLJmzdf9G
//8eCXkXLU8pH9ZfdXEjP2Gpu3ZynHJLYtH/C///UE30miwTzfjGAU1H
NEWVmRnsLKjKiTBAVC/// ///NPfsXJ
7ZcTVPA0vCuwKrXx9GqEmuXoEBqrn/dRbHSAL+xv9LjTFO
aklYrkvRUx+g67zIPLEpS9K//TeFNK3W3Ufy7H5WF08Er8PZDLS/wf/SUfVg8yxOvcTV 4sp 7Yi34
M
kD//7cLzhZG5bi4TZmaPVlPyghPmEXC3bw5XP////9OqlNuMnxS/78xbGEpJVDGvSyzWFjFGr2N
jTS9HIOnD/8v9f8zUFJQd7iR8ciCamMq2R8e+/CUw8ezSHnwv8D/2TUJ/5V0BDIxtjCJfZEWFzz5
zK3///+/hN5rVcB5Lj9amUp6z2YrJX62sAUeMkvkSqzgcdWd9P ///whDRaKC9+jKGmMlZWcUSj1l
p7Hwn 3GZz0sp2Xv/
/8u/QWG+dp6+9s5GcqzWwoq+eGkYP356nD1hOv//hf8N+oW67LH/DZn/Unn/
9oEvnfTWLNgsuBs9V
f9L/P9wYL51sTcgumDkNEPKn0uXPYASXO2ANzL/v8
H/BBjlZ5kWia+M3JFO
tLF6tMKpQhApXXnAeKn0/7/go/ds/Z386cK/AXpHST9C////l013+ZzjxWW+BULCuOFPSy3+nVUR
PBEferE/L/8b/P+xkiVeP3b6P2QYS9JdVOpWrrs+CjxABwS/0f//eq89mgLtRimFSGwcn50eX8N8
tzBQgZVA/4X//018fg2Gzj5RKdEeQKJ9L70p2
sScIatur8J4/9b//201S9vNXZPuRyuvGEmNRU2J
SUB0Rb0m0afW+v//W7c/YLpUEHM+21G9weVEvC8HX9t
sBAF57d/4t66XlnDRgEwpbsmTwi83VyLO
//8v9M4pU103SfRJcWO62MXscfdpVFHAg7FjU/////9cLPcTFwTelRdzhKnZKMKQAUAYr2Z8+xyB
vxWeEocEhf////9CHG/WioQuhyeGNYk2iCCKpDP4VosziiSNHYwMjyyWbf/////WKI4ikZBukzJ2
iu8o25KVlJdmlhaZHPKdd5gvXpslmsAL//+dDpyMM5o0ap9engICoTSgSRyWNd3//79epWqkfqcX
Tqaq++8qqVaobqsGqn6tXppErP///wslE66xL8kcsPe12yySdLRvt7Y337m42ef3Kv/SX+i7Uro1
ygWWe79tegSB/kdPEb9L////rm5L
XESQWcE5woMATzJYVUA0bqcsRDqIBRHb/7/BT2Pt2OyANOaB
WUFJSTGiioHgJySFuv/2tCkB56mPloYTJCYoNAoybrf//+0zgbAHL5JKs7I3kSgiJAwm2+cRMy5t
vaH/v/3/Nnc3frwyOw34DKnGwIixTwls gW0hVxuRxqlVEv//f+td5Ih+pnEZgWwstLw0SA EfwIVg
giJG9r9uMf////+6K 58cnQDIR44BHqo7mAHNoOJ4VgPIAFGBhjeGPFZoRf5G//9MX0pNDcpcRQte
vN7CJ0lBT/mhXjm6hv+/8bcqMZ LKbO2qWTdV2gwrDkopu1o8Y3f/En/jHqGq9mor8kOjB3SUfZf0
WoUW2/8G/xFJcu2PNP4pcCJcM T4E6Yis7ADMW/z/9m5NjhHid11TQw73vhQUyC9ZyOVh/3+JhWAM
w/Inn iuwP1kzXPn+8qi3If/////s41rMBk4mWXq9R49cOkkzS5UGyEoGd/rxmvc/yCBdJP//L/1R
cq0GFElJDPZhFF1lXYZNEYJxrdDsoGRR5/3////lPkgWm4HE8bGqxC4UL5mXmBn6aTRW5YPhVsHD
25t/gf8vS1G2RhrKunUCJT6QnxERhlMLAkn/hQv9EWyt8y7
B1EU0OBRtfK09oHFGvND//0QSKVFY
v9zsYJxeef3R33Hz9GX7QPEtfYMLi0uAFVS7W4MHiP///ws2EsuZy7o9sLf+AILKu 8qQgKFRJ0iA
qEPgwtv////ghE3/suseG oAc5PSdvhilwj9NQTSzhgdNA5S aEl/6/1PsdyGnIVOCCj5Cb3usjoIS
CzgUKvT/qw8xhPe8XNEGergkZ/8X+lv4
H45JQgeC7NEVYDc6McjiNET/////lXkHSWKL1JupaokK
gu5r7vZTBvPIH/QOqnj+5gaHTrf/////eo4/RwqegKJCEpqR2Sq+A47IF0U188qKAXQBMqCB9Bjf
2ur/gybkiSqVhCxQYT88ygzAWvsV/////3pKATV6gz0I2RHROYm+H+j5U5w22hFVGIR6yoa2kYdy
//83+Ob/7LV4xzxnU3ZRZj3KXix54nBHKH2AJvxbfKsqDE8 Xi0fvUhhG8tgXFP///y+UBrZ6Fudz
RgkWCHqANVBy4vQsSkqLAoM2eC28if+/8RcfK4MfRczz6uq+Tx4LYQqsCQbH/3+rf7rh+pFDeb+5
+Gbq1/zHKl A
7OXU7EDmh////rWkQ9VVGGAu1CKzrLbE0YLipwKTnol6I
HAf//79V
XDVDtpQE9bj2
LMjI3ob+DXQ0kMJnQePfaKM
rpFkiHLTVQKpHkIr/v/1/Nl0MNK8Ralxwtwo9rYRXtpNwh4FFCDS1
O5r/L9Dir1ute2kczC9FX4RhqPQLQvpv///Neg26mK81HHq831kjkmgfScf6Olk0rj dWf6MStwsf
+u+EbCBZrXy+F/q3+moZLO7 Qnx5ZXQ6h9H5/RQ//////NJptO8NpEkrDhUeaEngoovMhegFyTSq5
NANGIHox5jT/xv//33hfX6zDV6wQFujZSjyZ5ffbudpNZ4vl9
Jv//7/0nJXbyg1UyA2gz4tlDuWZ
vV7
2O/fQmbklWYL+/6X/m189kWdcnfAekNgWiNDnJ2UiZZ2/mF4IX9Tg/98FkTUMFs6 9Q73qd3KI
Hsi9Zvrf4C+uyeB2G3Vf+SvMoQB/Z
RqSL////xcEPaaPXtSdUSFzc51JArGXegJKZFXmwjxEGD7b
/0L/RqzztQvyxcMpe
E0SWhHJP5Z20M3/////LoUjxUZwLYCnQxfAww58zP1H/lcfpEJjLCTKkjJs
FDG/xY3+0aGaeDQIIDVJKm24HsNZ/6DU29sdt72JP09E0lP12xv9/9+mt0JbWEmDHao/4poUoxWR
3BWJFUdC/3/rbMgBF6zbikl6Tltili/Mn0GJ//Tf6v/y0CE93ikmIQlDCDZNPw0h5AKC////dy5x
egxRninK8aH/ZwZ
J+lQ9qWBNXRncQtMU9Rz/xv9b0sDoYfuOOYiIcvc1R0IXwUEmrWvp/xf+OLq+
HDttVEjTXV0Y ORcXJx5VHcMaed/6/39DuRYHeoefHzlqgtdFP0QztTUF
/D5+DJb/L/T/ZEgX3Bfd
lRL2lK7q6lHcPL03W1RUGRdG/////5M2VHDN1uEN76rqEiYYMf0jzLZViABFF3f8NUgREG5V1f8b
/ERZbINZp6nbMbAlJ80mhdEW4Tco8L+/7dG8/FHNF+mDxq3LQL/w///FnZ8RiwCphMlAM6tEMlp5
KYYvS0ZaaovJFP+3///iFEtZDsyPIq9xhxOBWNBlH7wEzTFN5gsnLa6IX+D//59XUg40i09CqSTd
OwfwGCmUzBEUY0rx9P4v9P9BE+z0Y035hDjyq3bbcoF5QjVgAcF9Qr/9/7dDuFdCgssJvjHo3jvt
TfdGh4 ohQKPoV1/g2/8cTanQCxITIvcUjkTivWE4rIC9rt/oL/SAVT8LWbkK9L5Tw3tEqX2vL/X/
W/9zPUu+nP56o4BxqlvLX1tSwf+/1P+g6R63mNha iFo2S7a+uGFYAEKLdclPB8n//7/EoWIdhU6+
u000+L0X0NmxLSUZgvIRwv4F//
8 v9ZpVQUJ6QGIEJoYBUs0eP
zrqjK5HSb+d+/X/C//ZTTcVc1HJ
LEyqKfwW6uRBS01gn3tL////L7fZqhKy5OPXD6waxE0E2FMYPAWpjPzFuE/ZpE
f/Ut/6RDk2U5r5
9K
1liEG10kLkTmDV1v+t/ndtsInZOUPAV
KpP0cqlqG+hTvf+Cxf4mUvLPfHUJr5nTUzJzD66t/3/
/6VSQzVoCjVWQ0q2l0rMcrZCh6ppZLk+Kv8v9EuInnKfqlxDtpJinryD+o+8Yr/C///bSp5KVk6f
9GK2Sp/PnvkQyyrXzNmvQnz//63/gJwv/rEYagxpK0WSr8pJkqFFrUKcwej6gX+D//9KsfNCJ8Nz
H0DjbcTobkx6e2LA1xkBYrX9////T0dknyPoSVmZCsqXGhmig5pXvHnGCzS3H4iDOzSZ////L3R2
AVF5LWxu8O8W+1HKgEJtmOQswG5DfoCjQq3j////yFMyDp6ZowOhKwEGHvpcQA9V+xGh5GronjMM
kv//36p
TVWRXE
HGztMtVUMlVSQA8yQcu0zOz/41+68wIvIJrhLda F0OCMmHHSSIDWv7/X+qtp+hA
gFvCUrnh8ZDE+ngcMKLenjee1/y/1A2eD2q/VQvMNRBClstF3JH4v8UbnUvJRY6KM7RGHJ4JgHWX
////30FOUfgDnsRs9/d5J0fO615R/DBqptu9GPr5UvnB/7/U//yMkS4JM0IrORjVEDQC8ZdGzrkR
SlJuIHzr//8ZY8FqFc5VR8j1AS9TzSoWVAc
aEpV6RKP61v9v8VwAEuivRElGdrSi+DagdIbiVhv/
b5Qrp+BBXCiBvMG2Fr8CuUT+L/3 /g t9nTifgQ1qAwcSPzYk+1rkY2aFygIIdf//2/60ywKDE7DTe
q8C4REtXJERXuSw8Ten/////A1ZGv+hRZELOn59Hsb58RVHtNREHOhk0PYIQF//hIxf/jd76tzRK
SxgZ6x2znu1bEQn2HZ573+IX+EQjGapOCl8Qvnlm6ZG2mVo3+lv/gUIfGPkJ7kpPtXzH0St9m 8Yu
+v///5KWzEBcUVARbkURdbbPryxZkh9FTsTj6mpxGroP/xf+Nzl6YFPOrMY8Ud+kVxFtVzQ4ylEW
wfS3+O3WHGvDdBEETtFYniEkJ9+n/1/ibywnYadLNhkZG8Bb4u0RWkBZ/YftW/z//1CJFExlnzjx
 XFQ3chb5K2nLPCgavxuDX/gFFvqNeYlbemNDK6kbgAan////l1VhaF+QKYzlULQZe5CDDv8j1FFi
H6sbxEkykP1f+v+WQJCrjSwy9RFgqwS9drqunK9O/o5hRV D/rf5LZXBqgOR9BifAUZ7 s4jc9pQnY
+/9f+GoHzMMG8jH6nrP7RxIJa31HRQGeQorJPo3+/38svElziCe2mJoL9RorbLSTgxwDTt50/1/g
/0g7gKr/149HXITVbCo19w3WeoV hy
rL8Jf/////b2OXpl5B3iTlRkqlKt5qwnO7M1FflcVxjTxSp
S8rcQf//wv9sYFzrkU1u8QQGDl2p/08BJzS64wqrM7FULf9fWOiztwTq/Rg1dszMBNTC94rqRKZ/
ib/198giCcZFmxOm/zEQQYCrKQw5/////zSo0SdroZ1K6ySmse5NYdV+bw5drPe01KS6UWEQHcuU
//9v/7haCjfADqc0EwWoRXFW1O6as
tENrjyxc7Y8ra3E/1/ihofC4RrgUJq8t8dI+qAGBGhG///f
ugWtnqip+fTwJh5IQ619cKp8kbcn56ytql/i/6UxsUJzDim4X6ruONnNjTUdai5SX+D/NzxzgaTJ
BKX
DMf/VWjqcv8v/v8D/UD1sl52XWU0hnEdeq1ft+CBEGWF JHKWh////WC9ueapnPDEYYzSk7hU3
WOBUMCmNQUFrYS//v9R/SL/ap2nNUUClICUHKC0kWEG/HxIkNf///0ZGLigu8rft/E4WMyhGWwIz
ZEoupB73AGZ/qb/UBhW4KgIuNEwtz5y3gPczVwTw//8vViQsMRFoKUwJ8H6aL3AxB3ckSNIv9S/t
LiJjv6efmt9JJDIyVWCXuP3/MiQJIC8lDn/ 6hD
5FJC8iIP4uvwmA/1ZArSU0LTkPICyW/7/AfyUl
M4KPQ6cEiQDqLZcnnBUpRyU9oz/W////G4i/LLIxOA0uXQ0oIzMgMzhzxG6cIdgAuCBOLvT//zMS
SS9MwfYmEw4jKzBVBDnDkV+8BSTrS/wFGi55KFcL2FwCFyAtxN/g/39KhvckbQBODjFbCiQ4T+aY
Ha5Odec1+Ld/iVFJsTYyMTMxJ7o9bYrzdLFP/+5339BRUnXzC3hFVkhAgwlTTEMySbe/SP8Z9dI4
OC4NQEMiT7Pl
GGVDUf8v/QbHQSeAj4/NWkVyRhl2GrcRTXul/v//aVFGEc9kWkdCLW4YVmHtV0El
/V/xTkodvHCr/8U5BCdj0b83IKpFYnohbyX9/y8tAyD2pSpNCgFXgUHBILpFzXFCj8yJA3lGFGG+
Iahj/7dtEW3MBYG+vhbCjL6qUdEAy3vj/41HMkYGQJo0Rspfwq+ 9TzOs+UEr3Q7YEVCBDDKuKg6l
LsEHMqVw
iHMzTOEd2Le6ST3CjjU1yIQviMJC9oQMNGEAHEwL/Ld/woBDwLxBspXCkEDMVW7CvPlO
SvFG7stDA5Sktqgii/7S/w 30Q8KDRchGwoZFwgg2sECOqA
2X2LrvFh/Itv g1qcspbc1ANsHCb/W2
wX5AVspGy
x5FVKk2+P2/DoFRx4VoucGqqUCxO0TIaZi33xrl/0wjSIE1BMonzMV133aFcRjrshEf
Sb7XJQvUy///1k5JHZ3IuDhGTvZGBhEG+BYJs+8UKTfbvzM3RshCwoJFqpk
QLSCoAkQF5qr5vgC5
kFujAxMlMdghaYakNec911xgm/DFMVf9ix+DDDZIm6kHt0mq9CMAdUEKBBMPnI9R/xf2BQ0NQQAF
FwARCANBFBK5yQdrGgoWEnMeMW2D1WpN7k4ADQZcry1o8IcigaxgLLbVD0goEAxB52q1tsACzr87
DahK+C8 wKC81JwDzFEVYRUSBgMAajRYICOQBADAKACRRBb9pJiCo
HAFGaW5kQ0QBoPJsb3NlG0TM
3hXUU2l6ZRfvf/tMTBFBDk1hcFZpZXdPZg9ub2FvDlVubRAuA3JzIm53wy9LRW52EG9udquKjl1W
ImFiGDmIuB1EDHZl2u6RipgOfVRpbUYq4qy1VxoLUUOi27r3sQt7cF5nLUzDbl8gfkxpYnJOeUEh
9kxQtFBjKEvGRDm2/WJ hbEFsBmNYTGG3PexU0ypNdQN4KBubtVtsF3JjD36wdBAH++daVh1GQ29w
ecV EZdqHN2sGgxclSGHnCyDdwp1FU2PZdjv5bGVuVN9wUC9oDWELCsNXK1hEHbO3RUTxb8qRtlDE
yXB5TZFsW3ZngiJNE0V4aUJB8WL daHFkH/G9WcAm/y+ZjfeGDbsFZXChNkI34sLDsDNuWpxlSXsR

caLL+xdsIPxechhUb5MVhpmiuEypDrwlexNiEQ0IY2tDhW9PRHIB42RlQ2in3F1EbDRNb0J5dCIS
FCcinJ65r7UtC mOYNipSoLK9J+FUR1BvaSgZSHvBZu1wRiZcvRMZhEOYMOg6bkVMuKww
aQlpnBak
IiYEOk0YM9c4Q3UYfRk6JDlhb2ulRGUslYQgxZV otcce45vAZxtLZXkMT3Dr3KNrMQtFag6AVlu9
ABp2dWUPi8zcpYQRKXVtMAxPs80mtz9kwvhtoKJhbodzZTCKNxdrjHIQ9gdpc2S99l
wJehnyzhAU
oniuW1AIIjk3oSszKmEqIQJKD2azVM0gAaFVXA8WsN9OQnVmZkEPC0xvd/YZtiN3dklyl
CN3CoWb
cVr0zAxNgsIAqG1Ztk3Xt9hiQP8EAhMLZVmWZTQXEhADq2VZlg8JFHM5v/+EvDxQRUwB A+AADwEL
AQeue9JsE3IqgDIEEAOCbGexkDULAjMEmVvSzQcM0B40e9kb2BAHBgDAeQhAgFtkeAIYBUa4wnYr
ZHgBHi4v2JOgmKRwkOs
2f7uwBCMgC2AuZGF0YZgj7kK6wfsiJ3ZAvc1gG4Uu5QkAw8AGfL8pezQn
QBuwew2UAABKQTwJAAAA/wAAAAAAYL4AkFAAjb4AgP//V4PN/+sQkJCQkJCQig ZGiAdHAdt1B4se
g+78Edty7bgBA AAAAdt1B4seg+78EdsRwAHbc+91CYseg+78Ed tz5
DHJg+gDcg3B4AiKBkaD8P90
dInFAdt1B4seg+78EdsRyQHbdQeLH oPu/BHbE cl1IEEB23UHix6D7vwR2xHJAdtz73UJix6D7vwR
23Pkg8ECgf0A8///g9EBjRQvg/38dg+KAkKIB0dJdffpY////5CLAoPCBIkHg8cEg+kEd/EBz+lM
/ /// Xon3uQEBAACKB0cs6DwBd/eAPwF18osHil8EZsHoCMHAE IbEKfiA6
+gB8IkH
g8cFidji2Y2+
AMAAAIsHCcB0RYtfBI2EMBTlAAAB81CDxwj/lozlAACVigdHCMB03In5eQcPtwdHUEe5V0jyrlX/
lpDlAAAJwHQHiQODwwTr2P+WlOUAAGHpI0T//wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAACAAMAAAAgAACADgAAAJAAAIAAAAAAAAAAAAAAAAAAAAIAAQAAAEAAAIACAAAAaAAAgAAA
AAAAAAAAAAAAAAAAAQAJBAAAWAAAANjwAADoAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEACQQA
AIAAAADE8wAAKAEA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAANAAAICoAACAAAAAAAAAAAAAAAAA
AAABAAkEAADAAAAA8PQAACIAAAAAAAA
AAAAAAAEAMADgwAAAKAAAACAAAABAAAAAAQAEAAAAAACA
AgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAIAAAACAgACAAAAAgACAAICAAADAwMAAgICAAAAA
/wAA/wAAAP//AP8AAAD/AP8A//8AAP///wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIiIiIiIiIiIiIiIiIiAAACP////////
///////
/gAAAh///////////////94AAAI9//////////////3+AAACP9/////////// //f/gAAA
j/9///////////9//4AAAI//9 //////////3//+AAACP//9/////////f///gAAAj///9///////
9////4AAAI///3d3d3d3d
3d///+AAACP//d/f39/f39/d///gAAAj/939/f39/f39/d//4AAAI/3
f39/f39/f39/d/+AAACHd/f39/f39/f39/d3gAAAj39/f39/f39/f39/f4AAAI//////////////
//8AAAAI///////////////wAAAAAI//////////////AAAAAAAI////////////8AAAAAAAAI//
/////////wAAAAAAAAAI//////////AAAAAAAAAAAI////////8AAAAAAAAAAAAI///////
wAAAA
AAAAAAAAAI//////AAAAAAAAAAAAAAAIiIiIiAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP///////////////8AAAAPAAAADwAAAA8AAAAPAAAAD
wAAAA8AAAAPAAAADwAAAA8AAAAPAAAADwAAAA8AAAA
PAAAADwAAAA8AAAAPAAAAH4AAAD/AAAB/4
AAA//AAAf/4AAP//AAH//4AD///AB
///4A//////////////////yMMAACgAAAAQAAAAIAAAAAEA
BAAAAAAAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAACAAAAAgIAAgAAAAIAAgACAgAAAwMDA
AICAgAAAAP8AAP8AAAD//wD/AAAA/wD/AP//AAD///8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AI///////wAAiP/////4AACPj////48AAI/4///4/wAAj4+IiI+PAACI9/f39/gAAI9/f39/fwAA
CPf39/fwAAAAj39/fw AAAAAI9/fwAAAAAACIiIAAAAAAAAAAAAAAAAAAAAAAAAD//wAA//8AAMAB
AADAAQAAwAEAAMABAADAAQAAwAEAAMABAADAAQAA4AMAAPAHAAD4DwAA/B8AAP//AAD//wAA8MQA
AAAAAQACACAgEAABAAQA6AIAAAEA
EBAQAAEABAAoAQAAAgAAAAAAAAAAAAAAAAAAALz1AAC M9QAA
AAAAAAAAAAAAAAAAyfUAAJz1AAAAAAAAAAAAAAAAAADW9QAApPUAAAAAAAAAAAAAAAAAAOH1AACs
9QAAAAAAAAAAAAAAAAAA7PUAALT1AAAAA AAAAAAAAAAAAAAAAAAAAAAAAPb1AAAE9gAAFPYAAAAA
AAAi9gAAAAAAADD2AAAAAAAAOPYAAAAAAAA5AACAAAAAAEtFUk5FTDMyLkRMT ABBRFZBUEkzMi5k
bGw ATVNWQ1JULmRsbABVU0VSMzIuZGxsAFdTMl8zMi5kbGwAAExvYWRMaWJyYXJ5QQAAR2V0UHJv
Y0FkZHJlc3MAAEV4aXRQcm9jZXNzAAAAUmVnQ2xvc2VLZXkAAABtZW1zZXQAAHdzcHJpbnRmQQAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
A AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADBMNh4/mcnUD5nCV7B
JgzQwb68KcE/Wk7BBz1ePgJuppegzvOo9zHboCtC5xdfMQ2qa9VoxEg083ggFLB45nsd3p8vAekU
mEkurMQe6RSYV+HI3PCNddez4cj65jHlm7DLmjDw/BGplph9zTh2cY6K9M3n3axnBjEkUl4umHLM
ZXiEGPGXXk1Tl8eWTUfT0gmXTHawTo4CcJfMrmMrbuCvDvKCdDq8GzX +hW5//sNi4zl5NTRdFHmd
/st5426a6pYFIoY79Rl/R+KCmopWyn3UMqkeV1bKei1WznDx6 pRabRD3985DHgqKeM0hS+CKTFX/
yzEpcJ8xK6vDkPcnfHQMSEXHvn/OS8inAiNzNhTMSqecMaq73gR9dxIKLKeN9CWZa0aVruDL
fsMS
N0B+b6PIyoa5u67gCl+u4Muis+69jR7DmyQxxSLPSMKBME0 raF7uiEAoKVYru+5AeHnxJbVwcU5Y
B56mtZiBOdxqnpeuFp7y7QGeDdJCng0maoF92hpN/CL7enevvC2UzKvjhV6xvcYIUR4V39aiGhiP
enegKdDHnfzoHk8C
ILEuKe+QQ3Gwr1qEP4QXjudMKzTvkG4XfoobuZ EmIHNJAYJdSQHfe46z7w8e
4kQqLWfkUACr 7ictF9Z3ws2D5d0t8BIfdolZ3S 8n/8L/EoPdYWcIws4wFbyJzyJTRfBviwJ5f+9h
NFqFLTmtg95g3OIO0ZBMOLVU4fMO8hFw7DDepMQFgZs2sBHC4hgRwOSolCTnt9Z4RHEmtO q0yRjR
XsnwHVEZ4xlX1odudnVeEiwRP3LNGeM9dAf4Lyfyh/0xuPtdcfLo8s0wc+jeMHPq++g3x+DodBjH
jnjVHN2RJMRh4y umMiux2n3kLvB++zYp2Hnr2bnzYoN4u7g4GNN/cEUmAyyN3EVbDt+a/y66Yg2X
X4VU
TzA1olDMT
6dnR/nEv2NzL mdH+TEpQhICvypx/KD1tQemcj+XhdQd
K9Y94Gh1520Nsl+EKeW8
TnQ6oFp3aujZU2q9YBsT9zWxQB3 JbiR8ssd32HjnTXDvE62/6YD8PcFV/DB5V0UZZDEW85w0JXF0
m7BmqWElcYp0qsCCMSVxTHclca0Pa MTLul9PTVuHAt7cX09GnNSX+VWY/T9EOyw/tl8jJWPk5WLS
Cw2Mb9wblvHTbuFZCz+vcNuyvFDTbu8Ptw2eaYVmte91NUg3dV5EXroxeotqoe4euU1TMroxfxtq
D8i0vrzj0IzImWVO2G4rTv+wYVFa1e7gO8VTTvMFT1HVn7ghLI7wzvV4Ox57QADO6px1zuS9Z9E3
wT/OVtKa0VE2CV5O
BsUj/Llr4uWOFLGBvNtpxYp2sYlcGLGGa3Y+JqeRCVBJyz7bxM35S4QyWri1
CObZkpDmiivG
b
X/aAj7bxPA
DkSovrkft6+zNkww0Gqg386s932P5ixjs+Ffq5DKx8GFCK1eOqmBI
Mq7dmY570aWOiLW7VsmmVJEtW10yqtCd5n24VAk3bXXR9jS8Fi5F8LWVRRvZKnKu0fY/I9H2IGze
pirA4fHnhOHxFT6AIZ0vjU7XtOktp4O6ZKy4jU 3U Gc1giF3+/r8IMs6+xjLDkFTNcJ9MMgtnCM2Q
kC4yI1qXUEsBAhQACgAAAAAADIN0NfAZP83AcAAAwHAAAAsAAAAAAAAAAAAgAAAAAAAAAE1FU1
NB
R0UuU0NSUEsFBgAAAAABAAEAOQAAAOlwAAAAAA==

------=_NextPart_000_0014_D3FD6653.260D7936--

Reply-To: <[email-masked]>
From: "Jim Schaad" <[email-masked]>
To: <[email-masked]>
Subject: Meeting Minutes
Date: Fri, 17 Nov 2006 11:53:59 -0800
Sender: [email-masked]

S/MIME IETF Face-to-Face Meeting Minutes

Chairperson Blake Ramsdell started the meeting with the traditional agenda
bashing.  No changes were made in the agenda for the meeting.

Blake then gave a status report on the the groups progress since the last
meeting.  The expectation is that working group last call will start on the
ESS certificate id and CMS multiple signature drafts as soon updates to the
documents are published.  This should be by the begining of next week.  The
RSA-KEM draft is still waiting for the X9.44 group to finish before it can
progress.  The caDES document has expired and is waiting for the ESS CertID
draft to finish.

The question was raised again by the chair about the issue of taking our
documents from their current RFC status up to Draft Standard status.  If
people actually want this to happen, please comment on the list.  The
current status is seen as sufficent by most implementers in the room and
there seems to be no real push to try and make things happen.

Finally Blake looked at the proposed updated milestones for the group.  The
proposed milestones where agreed to by the attendees without comment.  The
proposed milestones are:
        IBE - last call at first of year
        KEM - when X9.44 finishes

Jim Schaad then gave a more detailed status call on several documents before
the working group.  The first is an indirect issue, but is blocking the
symetric key distribution document.  The CMC document is currently being
re-edited to deal with issues from the AD review.  When this is complete it
will go to working group last call and AD review at the same time.  

One of the issues raised in the CMC review is the status of the id-data
content type.  The S/MIME working group essentially uses this as if it were
id-mime-data, but did not actually assign a new content type at the time the
S/MIME group was doing the V3 documents for backwards compatablity.  The
id-data type is acutally setup for unstructured data.  A proposal has been
made and is to be placed on the list about creating a new id-cct-blob and
re-defining id-data to be for mime.  Comments should go the the list.

The ESS CertID draft has been updated on the web site and should be ready
for last call.  The current issues raised on the list are not understood as
being issues and the author therefore recomments no changes.

The Multiple Signature Draft from Jim Schaad and Sean Turner is about half
finished.  They will publish the current state of the document in order to
get a first cut of feedback within the next two weeks.

Mark Schertler then presented the current state of the Identity Based
Encrypted drafts.  The CMS draft should be substantually complete and he
requests that people in the group read it.  The Acrichtecture draft is
almost complete, it still needs to get the XML registry finialized with IANA
and then both those documents should be ready for last call.  The final
draft is the math draft and is being progressed as an independent submission
(draft-martin-ibcs-00.txt).

Date: Tue, 14 Nov 2006 15:26:31 -0500
To: <[email-masked]>, <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: Usages of the id-data content type
Sender: [email-masked]

Jim:

>Do you believe that the S/MIME group should define a new OID for a
>unstructured content type and reserve id-data for mime data?

Too many implementations use id-data in the context of MIME.  It is 
too later to change this situation.

A new OID for  unstructured binary data is fine with me.

Russ

From: [email-masked] (Peter Gutmann)
To: [email-masked]
Subject: Re: Usages of the id-data content type
Cc: [email-masked]
Date: Wed, 15 Nov 2006 04:34:37 +1300
Sender: [email-masked]

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

>Please respond to the following question:
>
>Do you believe that the S/MIME group should define a new OID for a
>unstructured content type and reserve id-data for mime data?

Definitely not.  id-data is currently used for PDFs, Word docs, XML, EDI, and
who knows how many other content-types.  If the S/MIME WG feels the need for a
specific type for MIME data, they should go the other way round and define an
id-mime.  The horse bolted on id-data long ago.

Peter.

Reply-To: <[email-masked]>
From: "Jim Schaad" <[email-masked]>
To: <[email-masked]>
Subject: Usages of the id-data content type
Date: Mon, 13 Nov 2006 20:40:21 -0800
Sender: [email-masked]

At the meeting last week I presented an issue about the use of the id-data
content type that was raised in a review of the CMC documents.

Id-data is currently defined as being for unstructured data, but the S/MIME
working group treats it as being only for mime based data.  This can lead to
some intesting issues in trying to parse messages and deciding what to do
with this content for automatic processors.

Please respond to the following question:

Do you believe that the S/MIME group should define a new OID for a
unstructured content type and reserve id-data for mime data?

Jim

Date: Fri, 10 Nov 2006 08:05:21 -0800
To: "Denis Pinkas" <[email-masked]>
From: Paul Hoffman <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-smime-escertid-02.txt
Cc: "[email-masked]" <[email-masked]>
Sender: [email-masked]

At 3:01 PM +0100 11/10/06, Denis Pinkas wrote:
>The document states: Expires: October 3, 2006
>
>The document that has been published on November 8 is expired.

No, it is not. It is still in the I-D repository, and therefore not expired.

>Please resubmit a valid document.

This is a waste of WG time.

Date: Fri, 10 Nov 2006 15:01:57 +0100
From: "Denis Pinkas" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-smime-escertid-02.txt
Sender: [email-masked]

The document states: Expires: October 3, 2006

The document that has been published on November 8 is expired.

Please resubmit a valid document.

Denis

>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		: ESS Update: Adding CertID Algorithm Agility
>	Author(s)	: J. Schaad
>	Filename	: draft-ietf-smime-escertid-02.txt
>	Pages		: 19
>	Date		: 2006-11-8
>	
>In the original Enhanced Security Services for S/MIME draft, a
>   structure for cryptographically linking the certificate to be used in
>   validation with the signature was introduced, this structure was
>   hardwired to use SHA-1.  This document allows for the structure to
>   have algorithm agility and defines new attributes to deal with the
>   updating.
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-ietf-smime-escertid-02.txt
>
>To remove yourself from the I-D Announcement list, send a message to 
>[email-masked] with the word unsubscribe in the body of 
>the message. 
>You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
>to change your subscription settings.
>
>Internet-Drafts are also available by anonymous FTP. Login with the 
>username "anonymous" and a password of your e-mail address. After 
>logging in, type "cd internet-drafts" and then 
>"get draft-ietf-smime-escertid-02.txt".
>
>A list of Internet-Drafts directories can be found in
>http://www.ietf.org/shadow.html 
>or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>Internet-Drafts can also be obtained by e-mail.
>
>Send a message to:
>	[email-masked].
>In the body type:
>	"FILE /internet-drafts/draft-ietf-smime-escertid-02.txt".
>	
>NOTE:	The mail server at ietf.org can return the document in
>	MIME-encoded form by using the "mpack" utility.  To use this
>	feature, insert the command "ENCODING mime" before the "FILE"
>	command.  To decode the response(s), you will need "munpack" or
>	a MIME-compliant mail reader.  Different MIME-compliant mail readers
>	exhibit different behavior, especially when dealing with
>	"multipart" MIME messages (i.e. documents which have been split
>	up into multiple messages), so check your local documentation on
>	how to manipulate these messages.
>
>Below is the data which will enable a MIME compliant mail reader
>implementation to automatically retrieve the ASCII version of the
>Internet-Draft.
>
>Content-Type: text/plain
>Content-ID:	<[email-masked]>
>
>ENCODING mime
>FILE /internet-drafts/draft-ietf-smime-escertid-02.txt
>

Regards,

Denis Pinkas

Date: Fri, 10 Nov 2006 13:35:22 +0100
From: "Denis Pinkas" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-smime-cms-mult-sign-02.txt
Sender: [email-masked]

Russ,

The issue is more complex than presented.  :-(

The idea is to say that a message is correctly signed by a given signer, if one of the signatures 
from the *same* signer computed using a different signature algorithm is valid.

Correct ?

In the same section from RFC 3852, just above we have:

"   The process by which signed-data is constructed involves the
   following steps:

      1. For each signer, a message digest, or hash value, is computed
         on the content with a signer-specific message-digest algorithm.
         If the signer is signing any information other than the
         content, the message digest of the content and the other
         information are digested with the signer's message digest
         algorithm (see Section 5.4), and the result becomes the
         "message digest."

      2. For each signer, the message digest is digitally signed using
         the signer's private key.

      3. For each signer, the signature value and other signer-specific
         information are collected into a SignerInfo value, as defined
         in Section 5.3.  Certificates and CRLs for each signer, and
         those not corresponding to any signer, are collected in this
         step.

      4. The message digest algorithms for all the signers and the
         SignerInfo values for all the signers are collected together
         with the content into a SignedData value, as defined in Section
         5.1".

We should have a similar construct for verification, but we don't. 
It should start with:

   The process by which signed-data is verified involves the
   following steps:

  1. For each SignerInfo present in SignerInfos ...

The exercise is more difficult than it looks, because unless ESSCertID is being used, 
it is not possible to know for sure that a signature is from the same signer.

Denis

>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		: Cryptographic Message Syntax (CMS) Multiple Signer Clarification
>	Author(s)	: R. Housley
>	Filename	: draft-ietf-smime-cms-mult-sign-02.txt
>	Pages		: 5
>	Date		: 2006-11-9
>	
>This document updates the Cryptographic Message Syntax (CMS), which
>   is published in RFC 3852.  This document clarifies the proper
>   handling of the SignedData protected content type when more than one
>   digital signature is present.
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-ietf-smime-cms-mult-sign-02.txt
>
>To remove yourself from the I-D Announcement list, send a message to 
>[email-masked] with the word unsubscribe in the body of 
>the message. 
>You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
>to change your subscription settings.
>
>Internet-Drafts are also available by anonymous FTP. Login with the 
>username "anonymous" and a password of your e-mail address. After 
>logging in, type "cd internet-drafts" and then 
>"get draft-ietf-smime-cms-mult-sign-02.txt".
>
>A list of Internet-Drafts directories can be found in
>http://www.ietf.org/shadow.html 
>or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>Internet-Drafts can also be obtained by e-mail.
>
>Send a message to:
>	[email-masked].
>In the body type:
>	"FILE /internet-drafts/draft-ietf-smime-cms-mult-sign-02.txt".
>	
>NOTE:	The mail server at ietf.org can return the document in
>	MIME-encoded form by using the "mpack" utility.  To use this
>	feature, insert the command "ENCODING mime" before the "FILE"
>	command.  To decode the response(s), you will need "munpack" or
>	a MIME-compliant mail reader.  Different MIME-compliant mail readers
>	exhibit different behavior, especially when dealing with
>	"multipart" MIME messages (i.e. documents which have been split
>	up into multiple messages), so check your local documentation on
>	how to manipulate these messages.
>
>Below is the data which will enable a MIME compliant mail reader
>implementation to automatically retrieve the ASCII version of the
>Internet-Draft.
>
>Content-Type: text/plain
>Content-ID:	<[email-masked]>
>
>ENCODING mime
>FILE /internet-drafts/draft-ietf-smime-cms-mult-sign-02.txt
>

Regards,

Denis Pinkas

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-smime-cms-mult-sign-02.txt 
Date: Thu, 09 Nov 2006 18:50:02 -0500
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		: Cryptographic Message Syntax (CMS) Multiple Signer Clarification
	Author(s)	: R. Housley
	Filename	: draft-ietf-smime-cms-mult-sign-02.txt
	Pages		: 5
	Date		: 2006-11-9
	
This document updates the Cryptographic Message Syntax (CMS), which
   is published in RFC 3852.  This document clarifies the proper
   handling of the SignedData protected content type when more than one
   digital signature is present.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-smime-cms-mult-sign-02.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-smime-cms-mult-sign-02.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-smime-cms-mult-sign-02.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

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: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

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

ENCODING mime
FILE /internet-drafts/draft-ietf-smime-cms-mult-sign-02.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-smime-cms-mult-sign-02.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--OtherAccess--

--NextPart--

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-smime-escertid-02.txt 
Date: Wed, 08 Nov 2006 15:50:01 -0500
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		: ESS Update: Adding CertID Algorithm Agility
	Author(s)	: J. Schaad
	Filename	: draft-ietf-smime-escertid-02.txt
	Pages		: 19
	Date		: 2006-11-8
	
In the original Enhanced Security Services for S/MIME draft, a
   structure for cryptographically linking the certificate to be used in
   validation with the signature was introduced, this structure was
   hardwired to use SHA-1.  This document allows for the structure to
   have algorithm agility and defines new attributes to deal with the
   updating.

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

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-smime-escertid-02.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-smime-escertid-02.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

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: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

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

ENCODING mime
FILE /internet-drafts/draft-ietf-smime-escertid-02.txt

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

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

--OtherAccess--

--NextPart--

Date: Tue, 7 Nov 2006 15:49:55 +0100
From: "Denis Pinkas" <[email-masked]>
To: "Jim Schaad" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-smime-escertid-01.txt
Sender: [email-masked]

Jim,

>Demis,
       ^^
  Denis

>The statement in parens is not meant to be true, it is meant to state a
>condition under which the preceding statement would be sufficent.  Thus it
>starts "This assumes..."  

The text states:

   The issuer/serial number pair would therefore normally be sufficient to identify
   the correct signing certificate.  (This assumes the same issuer name
   is not re-used from the set of trust anchors.) 

We cannot construct on assumptions, in particular since there is no standardized way 
to know when this assumption would be met.

>If you think that the issuer/serial number pair is insufficent to identify a
>certificate, have you filed a defect report with X.509?  

If you think that  the issuer/serial number pair is sufficient to identify a certificate, 
why have you issued RFC 2634 ?  :-)

The issuer/serial number pair is only sufficient when it is possible to know the name of the CA 
that has issued a certificate to that issuer (and recursively up to a trust anchor).

> I don't see a
>significant difference in content between the second sentence you have and
>sentences 2 and 3 in my paragraph.   

I see it. If you don't care, it would save much time to take my wording proposal.

> I would be more worried about an
>attacker re-using the same issuer name rather than the re-use of the same
>issuer name in a single tree of certificate authorities.

The use of the same issuer name is not necessarily an attack.

>I am unconvinced that in cases where the issuer/serial is not used in the
>sid, it needs to be placed in the cert id structure.  

Your original text is:

   The issuer/serial
   number pair can be stored in the sid field of the SignerInfo object.
   However the sid field is not covered by the signature.  In the cases
   where the issuer/serial number pair is not used in the sid or the
   issuer/serial number need to be signed, they should be placed in the
   issuerSerial field of the ESSCertIDv2 structure.

> This is only a hint
>for finding the certificate and is not good identification.  The true
>identification is going to be the hash of the certificate.  

We both agree.

> Thus I don't see
>the need for the statement einging "In the cases ..."  Additionally this is
>covered in my current last sentence of the text.

I tried to use your text as much as possible. So the two sentences are similar:

Yours:

   In the cases where the issuer/serial number pair is not used in the sid 
   or the issuer/serial number need to be signed, they should be placed in the
   issuerSerial field of the ESSCertIDv2 structure.

Mine:

        In the cases where the issuer/serial number pair is not used in the sid, 
        it should be placed in the issuerSerial field of the ESSCertIDv2 structure.

>I think that the order you are placing the paragraphs is backwards.  The
>most important thing is the reason why the hash value is there rather than
>why issuer/serial is not a good method.

It is a matter of presentation, but it is necessary to explain in the case of an *accidental* name collision 
why issuer/serial may be insufficient. The three scenario of attack do NOT cover the case of name collision 
because it is not necessarilly an attack: it may happen by accident. The case of name collision is not covered 
in the security considerations section either.

Another option would be to add text in the security considerations section, which would then allow 
to shorten the explanations in the main body of the document.

I am unhappy with the current text. In order to move forward, would you be able to make a new text 
proposal that would possibly satisfy both of us ?

Denis

>Jim
>
>
>> -----Original Message-----
>> From: [email-masked] 
>> [mailto:[email-masked]] On Behalf Of Denis Pinkas
>> Sent: Thursday, August 24, 2006 11:29 AM
>> To: [email-masked]
>> Subject: Re: I-D ACTION:draft-ietf-smime-escertid-01.txt
>> 
>> 
>> Jim,
>> 
>> In order to solve my two concerns, the faster is to propose a 
>> text replacement.
>> I hope this will clarify my statements.
>> 
>> The statement in the parenthesis is not true. The 
>> issuer/serial number is not sufficient.
>> 
>> I propose the following as a global replacement:
>> 
>>    The issuer/serial number pair is the method of identification of
>>    certificates used in [PKIXCERT].  The issuer/serial number pair may
>>    be insufficient since two or more CAs with the same DN 
>>    could exist in different branches from a given certification tree.  The
>>    issuer/serial number pair may be used as a hint to fetch the
>>    certificate(s).  The issuer/serial number pair can be stored in the
>>    sid field of the SignerInfo object.  In the cases where the
>>    issuer/serial number pair is not used in the sid, it should be
>>    placed in the issuerSerial field of the ESSCertIDv2 structure.
>>    In some cases, hashes are used by certificate stores as a method of
>>    indexing and retrieving certificates, hence another reason for
>>    having the issuer/serial number pair optional.
>> 
>>    The hash of the entire certificate allows for a verifier to check
>>    that the certificate used in the verification process is indeed the
>>    one the signer intended to be used.  The use of the hash is
>>    required by this structure since the detection of substituted
>>    certificates with the same DN and serial number is based on the
>>    fact they would map to different hash values.
>> 
>> Denis
>>  
>> >  I have several problems with draft-ietf-smime-escertid-01.txt.
>> >
>> >  In RFC 2634, we have section "5.4 called Signing Certificate  
>> > Attribute Definition"
>> >
>> >  The proposal is to add a section 5.4.1 to define the v2  version 
>> > first (!) and then the current version (with SHA-1).
>> >  This should be done in the reverse way:
>> >
>> >  - first a section 5.4.1 to define the current version (with SHA-1),
>> >  - then a section 5.4.2 to define the v2 version.
>> 
>> I prefer the existing ordering.  I would rather have the 
>> items that people are to be using occur first and then 
>> obsolete items rather than the other way around.  I have not 
>> changed this.
>> 
>> >
>> >  After this restructuring, I have some problems with the 
>> text itself :
>> >
>> >  Issue 1 (page 4):
>> >
>> >    "Applications SHOULD recognize both attributes as long as
>> >    they consider SHA-1 to be sufficiently descriminating".
>> >
>> >  "descriminating" is not crystal clear for me. Would it be  
>> possible 
>> > to have the same idea expressed using a different wording ?
>> 
>> Done
>> 
>> >
>> >  Issue 2 (pages 4 & 5):
>> >
>> >  There is a duplication of the same paragraph (one is enough):
>> >
>> >    "The signing certificate attribute is designed to prevent  the 
>> > simple
>> >    substitution and re-issue attacks, and to allow for a  
>> restricted 
>> > set
>> >    of authorization certificates to be used in verifying a 
>> signature".
>> 
>> I believe that not having any descriptive text at these 
>> locations and jumping directly into the ASN.1 to be a poor 
>> choice.  I have not changed this.
>> 
>> >
>> >  Issue 3 (page 7):
>> >
>> >    "The issuer/serial number pair would therefore normally be  
>> > sufficient
>> >    to identify the correct signing certificate.  (This  assumes the 
>> > same
>> >    issuer name is not re-used from the set of trust anchors.)"
>> >
>> >  The assumption between the parenthesis is insufficient to  
>> correctly 
>> > identify the correct signing certificate. The  sentence needs to be 
>> > changed.
>> 
>> I do not understand your statement.  If the statement in 
>> parenthesis is true, then it is sufficent.  If the statement 
>> in the parenthesis is not true, then issuer/serial number is 
>> not sufficent.  Please re-read the text and explain better 
>> what your problem is.
>> 
>> >
>> >  Issue 4 (page 7):
>> >
>> >    "In the cases
>> >    where the issuer/serial number pair is not used in the sid or the
>> >    issuer/serial number need to be signed, they should be  
>> placed in 
>> > the
>> >    issuerSerial field of the ESSCertIDv2 structure."
>> >
>> >  The issuer/serial number pair can be used in the sid, but  
>> since it 
>> > is unsigned, it is insufficient to correctly  identify the correct 
>> > signing certificate.
>> >  So this rational is incorrect. The sentence needs to be changed.
>> 
>> I have no idea what you are trying to state here.  My 
>> sentence and your comment do not seem to be coming from the 
>> same context.  Please re-read the sentence.
>> >
>> >
>> >  Finally, I would propose that the next draft proposes a  global 
>> > replacement  for section 5.4 to make sure that the whole section is 
>> > consistent  (and that the text in it is not redondant).
>> 
>> I can understand your concern, however I believe that the 
>> current layout is better and more explicit for the RFC editor.
>> 
>> Jim
>> 
>> >
>> >  Denis
>> >
>> >
>> >
>> >
>> >
>> >
>> > 
>> >
>> > 
>> >
>> >
>> >
>> >
>> >  >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                 : ESS Update: Adding CertID 
>> Algorithm Agility
>> >  >            Author(s)         : J. Schaad
>> >  >            Filename          : draft-ietf-smime-escertid-01.txt
>> >  >      Pages               : 18
>> >  >      Date                 : 2006-4-18
>> >  >     
>> >  >In the original Enhanced Security Services for S/MIME draft, a  
>> > >structure for cryptographically linking the certificate to 
>> be used in  
>> > >validation with the signature was introduced, this structure was  
>> > >hardwired to use SHA-1.  This document allows for the 
>> structure to  
>> > >have algorithm agility and defines new attributes to deal 
>> with the  
>> > >updating.
>> >  >
>> >  >A URL for this Internet-Draft is:
>> >  
>> >http://www.ietf.org/internet-drafts/draft-ietf-smime-escertid-01.txt
>> >  >
>> >  >To remove yourself from the I-D Announcement list, send a 
>> message to  
>> > >[email-masked] with the word unsubscribe in 
>>  the body 
>> > of the message.
>> >  >You can also visit
>> >  https://www1.ietf.org/mailman/listinfo/I-D-announce
>> >  >to change your subscription settings.
>> >  >
>> >  >
>> >  >Internet-Drafts are also available by anonymous FTP. 
>> Login  with the 
>> > username  >"anonymous" and a password of your e-mail address. After 
>> > logging in,  >type "cd internet-drafts" and then
>> >  >      "get draft-ietf-smime-escertid-01.txt".
>> >  >
>> >  >A list of Internet-Drafts directories can be found in  
>> > >http://www.ietf.org/shadow.html  >or 
>> > ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>> >  >
>> >  >
>> >  >Internet-Drafts can also be obtained by e-mail.
>> >  >
>> >  >Send a message to:
>> >  >            [email-masked].
>> >  >In the body type:
>> >  >      "FILE /internet-drafts/draft-ietf-smime-escertid-01.txt".
>> >  >     
>> >  >NOTE:            The mail server at ietf.org can return 
>> the document in
>> >  >      MIME-encoded form by using the "mpack" utility.  To use this
>> >  >      feature, insert the command "ENCODING mime" before 
>> the "FILE"
>> >  >            command.  To decode the response(s), you will need 
>> "munpack" or
>> >  >      a MIME-compliant mail reader.  Different MIME-compliant
>> >  mail readers
>> >  >      exhibit different behavior, especially when dealing with
>> >  >            "multipart" MIME messages (i.e. documents 
>> which have been 
>> split
>> >  >      up into multiple messages), so check your local 
>> documentation on
>> >  >      how to manipulate these messages.
>> >  >                 
>> >  >                 
>> >  >Below is the data which will enable a MIME compliant mail reader  
>> > >implementation to automatically retrieve the ASCII version of the  
>> > >Internet-Draft.
>> >  >
>> >  >Content-Type: text/plain
>> >  >Content-ID:            <[email-masked]>
>> >  >
>> >  >ENCODING mime
>> >  >FILE /internet-drafts/draft-ietf-smime-escertid-01.txt
>> >  >
>> >
>> >  Regards,
>> >
>> >  Denis Pinkas
>> 
>> 
>> 
>> 
>> 
>> 
>
>
>

Regards,

Denis Pinkas