All,
My responses to Jim's comments are in-line:
At 06:40 PM 2/25/98 -0800, Jim Schaad (Exchange) wrote:
I have no problems with John's changes except as follows:
<snip>
This actually refers to Sec 2.2, bullet 5. The text appears to imply
that the sender must be included on in the receiptsTo field. This is
not correct. I suggest the line be "The message originator MUST
populate the rceiptsTo field with a GeneralNames for each entity to whom
the recipient should send the signed receipt. The message originator
MUST include their own Generalnames in the receiptsTo field to receive a
receipt."
[JSP: I agree. Great catch. In my effort to minimize the number of words
in the text, I added a false constraint. Recommend that Sec 2.3, bullet 5
should be replaced with the following text:
"5. The message originator MUST populate the receiptsTo field with a
GeneralNames for each entity to whom the recipient should send the signed
receipt. If the message originator requires that the recipient should send
the signed receipt to the originator, then the originator MUST include a
GeneralNames for itself in the receiptsTo field. 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 each GeneralNames. 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)."]
<snip>
I have the sma issue here as with the above change and would like to see
similar wording.
[JSP: Agree. Recommend that Sec 2.7, last para, last sentence should be
changed as follows:
OLD: "The field is mandatory, and the originator's name(s) MUST be included
in the receiptsTo list."
NEW: The message originator MUST populate the receiptsTo field with a
GeneralNames for each entity to whom the recipient should send the signed
receipt. If the message originator requires that the recipient should send
the signed receipt to the originator, then the originator MUST include a
GeneralNames for itself in the receiptsTo field."]
<snip>
This will also require a definition of UTF8String --- should we include
it at this point or only in the appendix at the end? I think the
appendix is sufficient.
[JSP: Appendix is sufficient.]
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
I would like to see this pargraph kept, in part because it gives a
rational for what follows in the next item.
[JSP: I respectfully disagree. I believe that the aforementioned paragraph
is confusing because it does not distinguish between the inner and outer
signedData objects. I believe that the following text expresses the
requirements more accurately and is placed in the optimal place in the MLA
processing description to emphasize the fact that we are talking about the
MLA creating/replacing the outer signedData object (and that this has
nothing to do with the inner signedData object). Furthermore, this is the
only place in the processing description that needs to address this topic,
so there is no need for an intro para earlier in the text.]
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: ....