1. Section 1 pargraph #2: Since as time goes by it becomes harder for
me to understand what sections of this document require SMIME3 and what
can be implemented using SMIME2, I would like to be explicit here.
Replace with the following paragraph: "The services described here are
extensions to S/MIME version 2 [SMIME2] and S/MIME version 3 [SMIME3].
The Security Label and Mail List Agent services can be added to S/MIME
version 2, but the Secure Reciepts service requires [CMS] and can only
be added to S/MIME version 3." then contue with the last sentence.
Please note that I am note sure that MLAs can be implemented using v2
S/MIME since I remember that there are some wrapping and nesting
implementations in the original specs and I don't remember how much got
removed when went into the IETF.
2. Section 1.2: This applies both to the current spec and to the
modification suggested by John. Lets reverse the order of the wrapping
so we go from outermost to inner most (thus matching what one sees when
reading one of these things) and add some indentiation so that we can
assoicate wrapping layers with the steps in section 1.1.2.
3. Section 1.3.4 It would be convenent to add a column which defines in
what document each of the attributes is defined. The list that I have
today would be:
contentHints ESS
contentIdentifer ESS
contentType CMS
counterSignature CMS
messageDigest CMS
mlExpansionHistory ESS
receiptRequest ESS
signingTime CMS
smimeCapabilites SMIME3
essSecurityLabel ESS
msgSigDigest ESS inner only
yes
4. Section 1.5 -- I would like to add a new section at this point to
define and describe the new ESS attributes which can be used outside of
the three different security services. The exception to this is
contentHints, I would like to see contentHints move from the ESS to the
CMS drafts. This attribute is going to be useful for a number of
different services (such as PKIP) and I see no reason why they should
reference ESS just to get this one attribute.
5. Section 2.10 -- Please insert a section describing the
msgDigestAttribute here:
2.10 Message Digest Attribute
This attribute is used only in a Secure Receipt authenticated attributes
section. It contains the message digest of the SignedData object for
which a receipt is being created. Only one msgDigestAttribute can
appear in an authenteicated attributes set.
ASN goes here...
6. Section 2.9 -- Please move this from the ESS draft to the CMS draft.
7. Section 3.1.1 Please add the following sentence to the end of the
last paragraph. "A local security policy should exist for handling of
messages which contain an eSSSecurityLabel attribute only in SignerInfos
which cannot be validated."
8. Section 4.1, paragraph 4.
9. Section 4.1, paragraph 5. Please as the following sentence. "An
MLA SHOULD NOT expand and redistribute a message if it cannot validate
one or more outer signatures."
10. Section 4.2.1, Bullet 2.
This is along the lines of a question, Should the new RecipientInfos be
unioned with the existing set or replaced. There are no security
reasons why it cannot be replacement but this seems odd to me.
11. Section 4.4 paragraph 1. Replace "the processing agent should
return an error." with "the processing agent should provide notification
of the error to a human mail list adminstrator. The mail list
administrator is responsible for correcting the overflow condition."
12. Section 4.4. We are in the process of removing almost every other
instance of a bounded sequence. Do we want to remove the bound of
ub-ml-expansion-history as well? I see no reason not to and recomend we
do so. This would create the following changes:
- Remove the last sentence in Section 4.4 paragraph 1.
- Change the ASN to
MLExpansionHistory ::= SEQUENCE SIZE (1..MAX) OF MLData
- delete the definition of ub-ml-expansion-history.
13. Section 1.4 and Appendix A. We should not be refering to the imc
URL for the oids anymore or saying we intend to move to IANA to keep the
registry. Recommend deletion of section 1.4 and the inclusion of the
OIDs used by this draft in Appendix A.