John,
I agree with you except for the following:
6) Sec 2.3, Bullet 2.2: Please append "in the outer signedData layer" to the
following: "2.2. If the value of allOrFirstTier is firstTierRecipients, do
one of the following two steps based on the presence of an
mlExpansionHistory attribute:"
[Jim Schaad I think this should be "in an outer signedData layer" to deal
with the multiple outer layer problems]
14) Sec 2.4.1, last sent: Please change as follows:
OLD:
"The MLA cannot change the authenticatedAttributes of the received
SignedData/Receipt object, so it can't add the MLExpansionHistory to the
SignedData/Receipt."
NEW:
"The MLA cannot change the authenticatedAttributes of the received
SignedData/Receipt object without invalidating the signature, so the MLA
MUST NOT add the MLExpansionHistory to the SignedData/Receipt."
[Jim Schaad: I don't see the need for this change. At this point we are
not talking about the MLA adding the MLExpansionHistory but the receipient
adding it to the signature they are applying. I think the wording stands as
originally written.]
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 and create a new "outer"
signedData layer encapsulating the message before it distributes it to the
ML members. Furthermore, it MUST add or update an mlExpansionHistory
attribute to document MLA processing.
When a S/MIME message is received by the MLA, it MUST first determine if
there is an outer signedData layer that already includes an
mlExpansionHistory attribute. If there are several outer signedData layers,
then the MLA MUST decode each of the outer layers to determine if any of
them include an mlExpansionHistory attribute. If the MLA finds a signedData
layer that includes an mlExpansionHistory attribute, then that is the
"outer" signedData layer that is referred to in the rest of this section.
In this case, the MLA must strip off the "outer" layer (after remembering
the included authenticated attributes) and must strip off all of the
signedData layers that encapsulated the "outer" layer. This is required
because the MLA MUST change the existing mlExpansionHistory attribute and
that change invalidates all of the encapsulating signedData signatures.
If the MLA decodes the outer signedData layers and does not find an
mlExpansionHistory attribute, then the MLA MUST add a new signedData layer
that encapsulates all of the existing signedData layers. In this case, the
new signedData layer created by the MLA is the "outer" signedData layer that
is referred to in the rest of this section."
[Jim Schaad: I can accept this up to the last paragraph. 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.
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.
This means that all sorts of critical attributes can be stripped off by an
MLA without notice to ANYBODY. Is this acceptable?]
18) Sec 4.2, third para: Recommend moving the following existing text from
the old para 1 to a new para that follows the mlExpansionHistory para: "In
all cases, the MLA may need to perform access control before distributing
the message to mail list members if the message contains a SignedData block
and an associated eSSSecurityLabel attribute. If a eSSSecurityLabel
authenticated attribute is used for access control, then the signature of
the signerInfo block including the eSSSecurityLabel authenticated attribute
MUST be verified before using the security label. The MLA should continue
parsing the MIME-encapsulated message to determine if there is a security
label associated with an encapsulated SignedData object. This may include
decrypting an EnvelopedData object to determine if an encapsulated
SignedData object includes a eSSSecurityLabel attribute."
[Jim Schaad: I agree we need to keep this]
20) Open Issues #1: I agree that contentHints should be moved to CMS.
[Jim Schaad: I suggested this. I still think it is the right thing to do.]
21) Open Issues #2: I believe that my recommended text for Sec 4.2 resolves
the MLA procesing issue.
[Jim Schaad: Still open -- see above]
22) Open Issues #3: I believe that the mlExpansionHistory size should be
left as 64.
[Jim Schaad: Agreed -- Keep this at 64, I think it is probably far enough
that nobody should reasonably hit it.]