Subject: RE: ESS Questions

From: [email-masked]
Date: Thu, 5 Oct 2000 13:53:33 -0400

>4.2.3.2 Processing for SignedData
>
>Q.  Step 2 of this process has been changed from the
>Internet draft version (draft-ietf-smime-ess-09.txt).  It
>seems that now if the "outer" signed data layer is absent
>or does not contain an mlExpansionHistory attribute, the
>MLA simply adds a new outer signed layer, lists itself in
>the mlExpansionHistory attribute, and sends the message to
>the recipients.  It would no longer expand any encrypted
>data for the recipients.  If someone sent a message that
>was encrypted then signed to the MLA, the recipients would
>not be able to decrypt it.  Have I misread this paragraph?
>
>[JSP: You have misinterpreted the paragraph.]

Did I also misinterpret the flowchart (quoted below)?

   1. Has a valid signature?
          YES -> 2.
          NO  -> STOP.
   2. Does outermost SignedData layer contain mlExpansionHistory?
          YES -> Check it, then -> 3.
          NO  -> Sign message (including outermost SignedData that
                 doesn't have mlExpansionHistory), deliver it, STOP.

   It seems clear that the MLA would not expand encrypted data unless the outer
signature is either absent or that of an MLA.

---

From: "Pawling, John" <[email-masked]>
Date: Wed, 11 Oct 2000 17:38:23 -0400

All,

It seems that mkicksee has pointed out an error in RFC 2634.  It seems that
the second sentence should be deleted from Section 4.2.3.2 Processing for
SignedData, bullet 2 as follows:

   2. If the outermost SignedData layer includes a signed
      mlExpansionHistory attribute, the MLA checks for an expansion loop
      as described in the "Detecting Mail List Expansion Loops" section,
      then go to step 3. If the outermost SignedData layer does not
      include a signed mlExpansionHistory attribute, the MLA signs the
      whole message (including this outermost SignedData layer that
      doesn't have an mlExpansionHistory attribute), and delivers the
      updated message to mail list members to complete MLA processing.

Example 5 in section 4.2.1 indicates that the MLA would continue processing
the layers of the received message if the outermost SignedData layer does
not include a signed mlExpansionHistory attribute, so that seems to
contradict the second sentence of Section 4.2.3.2, bullet 2.

As best I can remember, the second sentence of Section 4.2.3.2, bullet 2 was
included in RFC 2634 to address the case in which an MLA is processing a
message composed of a single signedData layer.  However, it seems that
section 3.3 addresses this case, so the second sentence of Section 4.2.3.2,
bullet 2 is not needed.

Unless somebody objects, I recommend that the second sentence should be
deleted from Section 4.2.3.2, bullet 2 and that the flow chart should be
updated accordingly.

===========================================
John Pawling, [email-masked]
Getronics Government Solutions, LLC
===========================================

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, October 05, 2000 1:54 PM
To: [email-masked]
Subject: RE: ESS Questions

   It seems clear that the MLA would not expand encrypted data unless the
outer
signature is either absent or that of an MLA.