All,
As usual, Paul has done a brilliant job of incorporating the comments into
ESS. I have the following comments regarding the 16 Feb 98 ESS-02 I-D:
1) General: Please ensure that all occurrences of essSecurityLabel are
spelled consistently. The capitalization of the leading "ess" has been
expressed in several different manners.
2) Sec 1.2, last para: Jim Schaad asked that support for multipart/signed
should be added to ESS. Recommend changing first sentence of last para to
start with "There is usually no purpose...".
3) Sec 1.2, new last para: Please add: "The following layers depict an
example of a triple wrapped message in which the inner MIME messages is
multipart/signed. Starting from the innermost layer and working outwards,
the layers are:
ContentInfo: data type
Inner SignedData block with absent content
MIME entity (multipart/signed: part 2: Inner SignedData w/o content)
Original content ("Hello, world!")
MIME entity (multipart/signed: part 1: original content)
ContentInfo: data type
EnvelopedData block
MIME entity
ContentInfo: data type
Outer SignedData block
MIME entity"
4) Sec 1.3.2, last para, last sent: Please replace "eSSSsecurityLabel" with
"essSecurityLabel".
5) Sec 1.3.4, Table: Jim Schaad stated "Change contentType to be "MUST BE
authenticated" this is called for in the CMS and PKCS 1.7 specifications if
any attributes are present. The purpose of this attribute unauthenticated
makes no sense and is required authenticated." I agree with Jim.
6) Sec 1.3.4, Table: Please delete encapsulatedContentType row because the
encapsulatedContentType is being eliminated.
7) Sec 1.3.4, last para, last sent: Please delete this sentence because
encapsulatedContentType is being eliminated.
8) Sec 2.2, bullet 2: Please change "encapsulatedContentType" to "contentType".
9) Sec 2.3, bullet 5: Please replace bullet 5 with the following: "The
message originator MUST populate the receiptsTo field so that the recipient
can determine the address(es) to which to send the signed receipt. The
message originator MUST populate the receiptsTo field with a GeneralNames
for each entity to whom the recipient should send the signed receipt
including, but not limited to, the message originator itself. GeneralNames
is a SEQUENCE OF GeneralName. receiptsTo is a SEQUENCE OF GeneralNames in
which each GeneralNames represents an entity. There may be multiple
GeneralName instances in the GeneralNames which represents an entity. At a
minimum, the message originator MUST populate each entity's GeneralNames
with the address to which the signed receipt should be sent. Optionally,
the message originator MAY also populate each entity's GeneralNames with
other GeneralName instances (such as directoryName)."
10) Sec 2.3, 3rd para, last sent: Please replace "MUST" with "SHOULD" in the
following: "A receipt MUST be returned if any signature containing a receipt
request can be validated, even if other signatures containing the same
receipt request cannot be validated." In all other places in the spec, we
have stated that the recipient SHOULD (rather than MUST) return a signed
receipt.
11) Sec 2.4, bullet 2.2: Please change "encapsulatedContentType" to
"contentType".
12) Sec 2.4, bullet 9, first sent: Please replace "contentInfo content ANY
field" with "EncapsulatedContentInfo eContent OCTET STRING" in the following
sent: "The ASN.1 DER encoded Receipt content MUST be directly encoded
within the signedData contentInfo content ANY field."
13) Sec 2.4, bullet 9, 2nd sent: Please replace "contentInfo contentType"
with "EncapsulatedContentInfo eContentType" in the following sent: "The
id-ct-receipt object identifier MUST be included in the signedData
contentInfo contentType."
14) Sec 2.5, bullet 1, 2nd sent: Please delete everything after the
semi-colon in the following sent: "The software initiates the sequence of
recipients with the value(s) of receiptsTo; otherwise, the software
initiates the sequence of recipients with the signer (that is, the
originator) of the SignerInfo that includes the receiptRequest attribute."
15) Sec 2.6, 1rst para, 2nd sent: Please replace "contentInfo contentType"
with "EncapsulatedContentInfo eContentType" in the following sent: "It is
identified by the presence of the id-ct-receipt object identifier in the
contentInfo contentType value of the signedData object including the Receipt
content."
16) Sec 2.6, bullets 2, 5 and 5.2: Please change "encapsulatedContentType"
to "contentType".
17) Sec 2.7: Please replace "encapsulatedContentType
EncapsulatedContentType" with "contentType ContentType" in the
receiptRequest ASN.1 definition.
18) Sec 2.7: Please delete the following text:
"The encapsulatedContentType field identifies the content type of the
original message. In BuiltinContentType, the values of 0 and 1 have been
deprecated and SHOULD NOT be used. Unless the data to be placed in the
encapsulatedContentType field has been profiled to be different in the
present operating environment, the internal content type SHOULD be placed in
the ExternalContentType choice of encapsulatedContentType.
EncapsulatedContentType ::= CHOICE {
built-in BuiltinContentType,
external ExternalContentType,
externalWithSubtype ExternalContentWithSubtype }
BuiltinContentType ::= [APPLICATION 6] INTEGER {
-- APPLICATION 6 is used for binary compatibility with X.411
unidentified (0),
external (1),
interpersonal-messaging-1984 (2),
interpersonal-messaging-1988 (22),
edi-messaging (35),
voice-messaging (40)} (0..ub-built-in-content-type)
ub-built-in-content-type INTEGER ::= 32767
ExternalContentType ::= OBJECT IDENTIFIER
ExternalContentWithSubtype ::= SEQUENCE {
external ExternalContentType,
subtype INTEGER }"
19) Sec 2.7, last para, last sent: Please replace "The field is mandatory,
and the originator's name(s) MUST be included in the receiptsTo list." with
"The message originator MUST populate the receiptsTo field with a
GeneralNames for each entity to whom the recipient should send the signed
receipt including, but not limited to, the message originator itself."
20) Sec 2.8: Please replace "encapsulatedContentType
EncapsulatedContentType" with "contentType ContentType" in the Receipt ASN.1
definition.
21) Sec 2.8, last para: Please change "encapsulatedContentType" to
"contentType".
22) Sec 2.9: Please change ContentHints to the following (note changes to
both components):
"ContentHints ::= SEQUENCE {
contentDescription UTF8String SIZE (1..MAX) OPTIONAL,
contentType ContentType}"
23) Sec 2.9: Please delete the following text:
"DirectoryString ::= CHOICE {
teletexString TeletexString (SIZE (1..MAX)),
printableString PrintableString (SIZE (1..MAX)),
bmpString BMPString (SIZE (1..MAX)),
universalString UniversalString (SIZE (1..MAX)) }
The construct "SIZE (1..MAX)" is used in the DirectoryString syntax to
constrain each CHOICE to have at least one entry. MAX indicates that the
upper bound is unspecified. Implementations are free to choose an upper
bound that suits their environment."
24) Sec 3.2, 1rst para: Please change "[MSP4]" to "[ACP120]".
25) Sec 3.2: Please change ESSPrivacyMark to:
"ESSPrivacyMark ::= CHOICE {
pString PrintableString SIZE (1..ub-privacy-mark-length),
utf8String UTF8String SIZE (1..MAX)
-- If utf8String is used, the contents must be in UTF-8 [UTF8]
}"
26) Sec 4.2, intro, 3rd para: Please delete the following paragraph: "When
the MLA creates the new attribute list for its signature, the MLA MUST
propagate forward each attribute in the old signature, unless the MLA
explicitly replaces the attribute with a new value. An MLA will frequently
encounter attributes, or parts of attributes, which it does not understand.
Attributes such as security labels cannot be removed from the new signature
being created without compromising the security of the system. Because it is
impossible to enumerate the future list of attributes which have security
implicitions, an MLA MUST propagate forward all attributes which it does not
explicity replace."
27) sec 4.2.2, bullet 3.2.1 should be changed as follows:
OLD: 3.2.1. The MLA strips the existing outermost SignedData layer
after remembering the value of the mlExpansionHistory
attribute in that layer, if one was there.
NEW: 3.2.1. The MLA strips the existing outermost SignedData layer
after remembering the value of the mlExpansionHistory and
all other authenticated attributes in that layer, if
present.
28) sec 4.2.2, bullet 3.2.3, first para, should be changed as follows:
OLD: 3.2.3. The MLA adds an mlExpansionHistory attribute. The
SignedData layer created by the MLA replaces the original
outermost SignedData layer.
NEW: 3.2.3. The outermost signedData layer created by the MLA
replaces the original outermost signedData layer. The
MLA MUST create an authenticated attribute list for the
new outermost signedData layer which MUST include each
authenticated attribute present in the original outermost
signedData layer, unless the MLA explicitly replaces the
attribute with a new value. A special case is the
mlExpansionHistory attribute. The MLA MUST add an
mlExpansionHistory authenticated attribute to the outer
signedData layer as follows: ....
29) Sec 4.3 Title: Please replace "Recipt" with "Receipt".
30) Sec 4.3, last para: Please replace "The interesting cases are combining
insteadOf with inAddtionTo." with "In the table above, the term
"insteadOf(A+B)" means that the effective policy is the union of A's
insteadOf GeneralNames and B's inAdditionTo GeneralNames. The term
"inAdditionTo(A+B)" means that the effective policy is the union of A's and
B's inAdditionTo GeneralNames."
31) Sec 4.4: Please change MLReceiptPolicy as follows:
"MLReceiptPolicy ::= CHOICE {
none [0] NULL,
insteadOf [1] SEQUENCE SIZE (1..MAX) OF GeneralNames,
inAdditionTo [2] SEQUENCE SIZE (1..MAX) OF GeneralNames }"
32) Sec 4.4: Please delete "ub-insteadOf INTEGER ::= 16" and
"ub-inAdditionTo INTEGER ::= 16".
33) ASN.1 Module: Please add ContentType as an import from the CMS module.
34) ASN.1 Module: Please change all ASN.1 syntaxes as described above.
35) ASN.1 Module: Please add: "MsgSigDigest ::= OCTET STRING"
36) ASN.1 Module: Please add the following comment:
"--The construct "SEQUENCE SIZE (1..MAX) OF" appears in several ASN.1
--constructs. A valid ASN.1 SEQUENCE can have zero or more entries.
--The SIZE (1..MAX) construct constrains the SEQUENCE to have at least
--one entry. MAX indicates the upper bound is unspecified.
--Implementations are free to choose an upper bound that suits their
--environment."
37) App B: Please delete the [MSP4] reference and add the [ACP120] reference
as follows: "[ACP120] Oct 97 Allied Communication Publication (ACP) 120
Communication Security Protocol Specification."
38) App D: Please delete the open issue because the msgSigDigest OID has
been defined and is included in the S/MIME OIDs document.
================================
John Pawling
jsp(_at_)jgvandyke(_dot_)com
J.G. Van Dyke & Associates, Inc.
================================