ietf-smime
[Top] [All Lists]

RE: ESS Questions

2000-10-11 14:34:18
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, john(_dot_)pawling(_at_)getronicsgov(_dot_)com
Getronics Government Solutions, LLC
===========================================



-----Original Message-----
From: mkicksee(_at_)aepos(_dot_)adga(_dot_)ca 
[mailto:mkicksee(_at_)aepos(_dot_)adga(_dot_)ca]
Sent: Thursday, October 05, 2000 1:54 PM
To: ietf-smime(_at_)imc(_dot_)org
Subject: RE: ESS Questions




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.


<Prev in Thread] Current Thread [Next in Thread>