Jim,
I agree with all of Jim Schaad's comments except for the following:
17) Sec 4.2, first para:
<snip>
[Jim Schaad: I can accept this up to the last paragraph.
[JSP: I agree that Jim makes some good points and that my proposal needs to
be enhanced. Please read on.]
Does the following algrithm sound reasonable for identification of "the"
outer signature:
Verifiy signatures in until you find
1) A mlExpansionHistory Attribute or
2) The enclosed data is encryptedData
The signature which has this property is the "outer" signature. If you
don't find an outer signature you add a new one. If you find an outer
signature you strip everything including that signature and resign. If you
find an outer signature from test 1 AND you find an encryptedData farther
in, you strip all signature to the encryptedData and then re-sign using the
"defined" outer signature.
[JSP: I agree except please change "Verifiy signatures in" to "Verify
signatures and fully process authenticatedAttributes in". Also, please
change "2) The enclosed data is encryptedData" to "2) The enclosed data is
envelopedData, or". Also, please add "3) The enclosed data is the original
content". Consider the example (S3(S2(S1(Orig Content)))) in which none of
the layers include an MLExpansion history attribute. In this case the MLA
verifies and fully processes the authenticatedAttributes in S3, S2 and S1,
but never finds an envelopedData and never finds an mlExpansionHistory
attribute. In this case, the MLA calculates a new signedData layer, S4,
resulting in the following message sent to the ML recipients:
(S4(S3(S2(S1(Orig Content))))). S4 includes an mlExpansionHistory attribute
created by the MLA.]
[JSP: Based on Jim's comments, I re-submit my comment 17 to ESS-03 as
follows: "17) Sec 4.2, first para: This change addresses the Open Issue
regarding MLA processing. Please replace the first para with: "MLA message
processing depends on the structure of the S/MIME layers in the message sent
to the MLA for expansion. For example, an entity can send a single-wrapped
signedData or envelopedData message to an MLA. As another example, an
entity can send a double-wrapped message (i.e. signed and enveloped;
enveloped and signed; signed and signed; etc) to an MLA. As another
example, an entity can send a quadruple-wrapped message to the MLA (i.e. a
well-formed triple-wrapped message was sent through a gateway that added an
outer SignedData layer). In all cases, the MLA MUST sign the message to be
sent to the ML members in a new "outer" signedData layer. The MLA MUST add
or update an mlExpansionHistory attribute in the "outer" signedData that it
creates to document MLA processing. If there was an "outer" signedData
layer included in the original message received by the MLA, then the
MLA-created "outer" signedData layer MUST include each authenticated
attribute present in the original "outer" signedData layer, unless the MLA
explicitly replaces an attribute (such as mlExpansionHistory) with a new
value.
When an S/MIME message is received by the MLA, the MLA MUST first determine
which received signedData layer, if any, is the "outer" signedData layer.
To identify the received "outer" signedData layer, the MLA MUST verify the
signature and fully process the authenticatedAttributes in each of the outer
signedData layers (working from the outside in) to determine if any of them:
1) include an mlExpansionHistory attribute;
2) encapsulate an envelopedData object; or
3) encapsulate the original content (i.e. not envelopedData and not signedData).
If the MLA does not find an "outer" signedData layer then it MUST sign the
original, received message in a new "outer" signedData layer. If the MLA
finds an "outer" signedData layer, then the MLA MUST: strip off all of the
signedData layers that encapsulated the "outer" signedData layer; strip off
the "outer" signedData layer itself (after remembering the included
authenticatedAttributes); expand the envelopedData (if present); and sign
the message to be sent to the ML members in a new "outer" signedData layer
that includes the authenticatedAttributes (unless explictly replaced) from
the original, received "outer" signedData layer. If the MLA finds an
"outer" signedData layer that includes an mlExpansionHistory attribute AND
the MLA also finds an envelopedData layer buried deeper with the layers of
the received message, then the MLA MUST strip off all of the signedData
layers down to the envelopedData layer (including stripping off the original
"outer" signedData layer) and MUST sign the expanded envelopedData in a new
"outer" signedData layer that includes the authenticatedAttributes (unless
explictly replaced) from the original, received "outer" signedData layer. .
Consider the following examples:
1) A message (S1(Original Content)) (where S = SignedData) is sent to the
MLA in which the signedData layer does not include an MLExpansionHistory
attribute. The MLA verifies and fully processes the authenticatedAttributes
in S1. The MLA decides that there is not an original, received "outer"
signedData layer since it finds the original content, but never finds an
envelopedData and never finds an mlExpansionHistory attribute. The MLA
calculates a new signedData layer, S2, resulting in the following message
sent to the ML recipients: (S2(S1(Original Content))). S2 includes an
mlExpansionHistory attribute created by the MLA.
2) A message (S2(E1(S1(Original Content)))) (where E = envelopedData) is
sent to the MLA in which S2 includes an MLExpansionHistory attribute. The
MLA verifies the signature and fully processes the authenticatedAttributes
in S2. The MLA finds the mlExpansionHistory attribute in S2, so it decides
that S2 is the "outer" signedData. The MLA remembers the
authenticatedAttributes included in S2 for later inclusion in the new outer
signedData that it applies to the message. The MLA strips off S2. The MLA
then expands the recipientInformation in E1 (this invalidates the signature
in S2 which is why it was stripped). The MLA calculates a new signedData
layer, S3, resulting in the following message sent to the ML recipients:
(S3(E1(S1(Original Content)))). The MLA includes in S3 the attributes from
S2 (unless it specifically replaces an attribute value) including an updated
mlExpansionHistory attribute.
3) A message (S3(S2(E1(S1(Original Content))))) is sent to the MLA in which
none of the signedData layers include an MLExpansionHistory attribute. In
this case, the MLA verifies the signature and fully processes the
authenticatedAttributes in S3 and S2. When the MLA encounters E1, then it
will consider S2 to be the "outer" signedData since S2 encapuslates E1. The
MLA remembers the authenticatedAttributes included in S2 for later inclusion
in the new outer signedData that it applies to the message. The MLA strips
off S3 and S2. The MLA then expands the recipientInformation in E1 (this
invalidates the signatures in S3 and S2 which is why they were stripped).
The MLA calculates a new signedData layer, S4, resulting in the following
message sent to the ML recipients: (S4(E1(S1(Original Content)))). The MLA
includes in S4 the attributes from S2 (unless it specifically replaces an
attribute value) and includes a new mlExpansionHistory attribute.
4) A message (S3(S2(E1(S1(Original Content))))) is sent to the MLA in which
S3 includes an MLExpansionHistory attribute. In this case, the MLA verifies
the signature and fully processes the authenticatedAttributes in S3. The MLA
finds the mlExpansionHistory in S3, so it decides that S3 is the "outer"
signedData. The MLA remembers the authenticatedAttributes included in S3
for later inclusion in the new outer signedData that it applies to the
message. The MLA verifies the signature and fully processes the
authenticatedAttributes in S2. When the MLA encounters E1, then it strips
off S3 and S2. The MLA then expands the recipientInformation in E1 (this
invalidates the signatures in S3 and S2 which is why they were stripped).
The MLA calculates a new signedData layer, S4, resulting in the following
message sent to the ML recipients: (S4(E1(S1(Original Content)))). The MLA
includes in S4 the attributes from S3 (unless it specifically replaces an
attribute value) including an updated mlExpansionHistory attribute.]
The problem with
this is that security labels which I (as sender) apply to a signedData
object will get lost potentially. For example consider the case of
S1(S2(E1(S3)). If S1 and/or S2 has a security label on it, that label will
get lost by the process of MLA expansion. I am starting to admit defeat and
say that the processing just cannot be done correctly in all cases.
[JSP: In your example, (S1(S2(E1(S3)))), the security label that is used for
end-to-end, writer-to-reader security is the one in S3. The security
labels, if any, included in S1 and S2 are intended to be "processed
hop-by-hop, where each hop is an intermediate entity" (ESS, Sec 1.1.1, last
para). As implied in the aforementioned examples, the MLA verifies the
signature and fully processes the authenticatedAttributes in S1 and S2. It
fully processes the securityLabel attributes found in S1 and S2, if present.
In summary, the security labels in S1 and S2 are fully processed by the MLA,
so they are not "lost". They are processes as was intended by ESS, Sec 1.1.1.]
This means that all sorts of critical attributes can be stripped off by an
MLA without notice to ANYBODY. Is this acceptable?]
[JSP: The critical attributes in the inner signedData (S3 in your example)
cannot be stripped off by the MLA without invalidating the signature of the
inner signedData. The critical attributes in outer signedData layers (S1
and S2) can be stripped off by the MLA. This is consistent with the
definition of "outer signature" as stated in ESS, sec 1.1.1:
"The outside signature provides authentication and integrity for information
that is processed hop-by-hop, where each hop is an intermediate entity such
as a mail list agent. The outer signature binds attributes (such as a
security label) to the encrypted body. These attributes can be used for
access control and routing decisions."]
- John Pawling