All,
IMHO, Paul has done a fabulous job of incorporating the group's comments
into ESS-03. I have the following comments regarding the 1 Mar 98 ESS-03 I-D:
1) Sec 1.1.2, bullet 3: Please change as follows:
OLD:
"3. Sign the result of step 2 (the inner MIME headers and the original
content). The SignedData structure is encapsulated by a ContentInfo SEQUENCE
with a contentType of data. If the structure you create in step 4 is
multipart/signed, the eContent is missing; if the structure you create in
step 4 is application/pkcs7-mime, the eContent is the result of step 2 above."
NEW:
"3. Sign the result of step 2 (the inner MIME headers and the original
content). The SignedData encapContentInfo eContentType object identifier
MUST be id-data. If the structure you create in step 4 is multipart/signed,
then the SignedData encapContentInfo eContent MUST be absent. If the
structure you create in step 4 is application/pkcs7-mime, then the
SignedData encapContentInfo eContent MUST contain the result of step 2
above. The SignedData structure is encapsulated by a ContentInfo SEQUENCE
with a contentType of id-signedData."
2) Sec 1.1.2, bullet 5: Please change as follows:
OLD:
"5. Encrypt the result of step 4 as a single block, turning it into an
application/pkcs7-mime object. The EnvelopedData structure is encapsulated
by a ContentInfo SEQUENCE with a contentType of data. This is called the
"encrypted body"."
NEW:
"5. Encrypt the result of step 4 as a single block, turning it into an
application/pkcs7-mime object. The EnvelopedData encryptedContentInfo
contentType MUST be id-data. The EnvelopedData structure is encapsulated by
a ContentInfo SEQUENCE with a contentType of id-envelopedData. This is
called the "encrypted body"."
3) Sec 1.2: Please change the triple wrapped message example that uses
multipart/signed for both signatures as follows:
NEW:
[step 8] Content-type: multipart/signed;
[step 8] protocol="application/pkcs7-signature";
[step 8] boundary=outerboundary
[step 8]
[step 8] --outerboundary
[step 6] Content-type: application/pkcs7-mime; )
[step 6] smime-type=enveloped-data )
[step 6] )
[step 5] envelopedData block )
[step 5] | )
[step 4] Content-type: multipart/signed; | )
[step 4] protocol="application/pkcs7-signature"; | )
[step 4] boundary=innerboundary | )
[step 4] | )
[step 4] --innerboundary | )
[step 2] Content-type: text/plain | )
[step 2] | )
[step 1] Original content % | )
[step 4] | )
[step 4] --innerboundary | )
[step 4] Content-type: application/pkcs7-signature | )
[step 4] | )
[step 3] inner SignedData block (eContent is missing) | )
[step 6]
[step 8] --outerboundary
[step 8] Content-type: application/pkcs7-signature
[step 8]
[step 7] Outer SignedData block (eContent is missing)
4) Sec 1.2: Please change the sentence immediately prior to the triple
wrapped message example that uses application/pkcs7-mime for both signatures
as follows:
OLD:
"The format of a triple wrapped message that uses application/pkcs7-mime for
the outer signature is:"
NEW:
"The format of a triple wrapped message that uses application/pkcs7-mime for
both signatures is:"
5) Sec 1.2: Please change the triple wrapped message example that uses
application/pkcs7-mime for both signatures as follows:
NEW:
[step 8] Content-type: application/pkcs7-mime;
[step 8] smime-type=signed-data
[step 8]
[step 7] Outer SignedData block (eContent is present) !
[step 6] Content-type: application/pkcs7-mime; )
[step 6] smime-type=enveloped-data; )
[step 6] )
[step 5] envelopedData block )
[step 5] | )
[step 4] Content-type: application/pkcs7-mime; | )
[step 4] smime-type=signed-data | )
[step 4] | )
[step 3] Inner SignedData block (eContent is present) $ | )
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:"
7) Sec 2.3, Flow Chart: Please append "in outer signedData" to the
following: "1. Has mlExpansionHistory?"
8) Sec 2.3, Flow Chart: Please change "1.2.1. Use ML's policy, then -> STOP"
to "1.2.2. STOP". IMHO, this change is required because the ML's policy is
to STOP. The current wording implies that the software must do something
based on the ML's policy and then STOP.
9) Sec 2.3, Flow Chart: Please append "in outer signedData" to the
following: "2.2. Has mlExpansionHistory?"
10) Sec 2.4, bullet 1.1: Please delete "ASN.1 DER encoded" from the
following sentence: "1.1. The ASN.1 DER encoded content of the original
signedData object is digested as described in [CMS]."
11) Sec 2.4, bullet 2.2: Please make the following change:
OLD:
"2.2. The original signedData encapContentInfo eContentType object
identifier is copied into the Receipt contentType."
NEW:
"2.2. The object identifier from the contentType attribute included in the
original signedData signerInfo that includes the receiptRequest attribute is
copied into the Receipt contentType."
Note about the change: The signerInfo contentType OID and signedData
encapContentInfo eContentType OID express the same value, so this change
does not change the outcome of the processing described by this text. This
change makes the Signed Receipt creation process consistent with other
sections of the text that deal with the signed receipt verification process.
In other words, this single change saves us from having to make several
other changes.
12) Sec 2.4, bullet 2.4: Please add the following bullet: "2.4. The
signature value from the original signedData signerInfo that includes the
receiptRequest attribute is copied into the Receipt originatorSignatureValue."
13) Sec 2.4, bullet 9, 2nd sent: Please change "eContent" to "eContentType"
in the following sent: "The
id-ct-receipt object identifier MUST be included in the signedData
encapContentInfo eContent."
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."
15) Sec 2.7: Please delete the following sent: "A contentType attribute
including the id-ct-receipt object identifier must be part of the receipt
request."
16) Sec 3.2 and Appendix A: Recommend that ESSPrivacyMark should be changed
to the following:
ESSPrivacyMark ::= CHOICE {
pString PrintableString (SIZE (1..ub-privacy-mark-length)),
utf8String [0] IMPLICIT UTF8String (SIZE (1..ub-privacy-mark-length))
}
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."
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."
19) ASN.1 module: Please change "contentType OBJECT IDENTIFIER" to
"contentType ContentType" in the ContnetHints syntax.
20) Open Issues #1: I agree that contentHints should be moved to CMS.
21) Open Issues #2: I believe that my recommended text for Sec 4.2 resolves
the MLA procesing issue.
22) Open Issues #3: I believe that the mlExpansionHistory size should be
left as 64.
================================
John Pawling
jsp(_at_)jgvandyke(_dot_)com
J.G. Van Dyke & Associates, Inc.
================================