Andrew makes many good points that should be considered by other S/MIME
authors. As for ESS:
ess-09.txt:
1: reference to MUSTSHOULD?
Er, yes. Added.
2.3, second paragraph: I'm unhappy with the two consecutive sentences which
say that if two verified signatures conflict, a signature must not be
generated, but a signature should be generated if any signature verifies (or
'validates') and another doesn't because you don't recognize the algorithm.
That's not what they say, I believe. They say if two *receiptRequest*
attributes in a SignedData conflict, don't send back a receipt. If you
can't validate a signature due to not knowing a particular algorithm, keep
going.
2.3, flowchart item 3.1: 'should' should be capitalised.
Yup.
4.2.3.2: I'm not sure this flowchart-like process will work. Unless I'm
mistaken, it gives different results on, for example, 4.2.1 example 5, where
I see it returning S4(S2(E1(S1(Original Content)))).
I don't see this. I think that step 3.2.1 strips off S2, yes?
Or example 2, where I
see it returning S4(S2(S1(Original Content))).
Yes, I agree; good catch! I have changed step 2 of 4.2.3.2 to:
2. If the outermost SignedData layer includes an signed mlExpansionHistory
attribute, the MLA checks for an expansion loop as described in the
"Detecting Mail List Expansion Loops" section, then go to step 3. If the
outermost SignedData layer does not include an signed mlExpansionHistory
attribute, go directly to step 4.
...and changed the flowchart to:
2. Does outermost SignedData layer contain mlExpansionHistory?
YES -> Check it, then -> 3.
NO -> 4.
If the text between 4.2 and
4.2.1 is what the group wants, I'm not convinced that the stuff between the
end of 4.2.1 and 4.3 does any good, apart from mentioning replacing
originatorInfo.
I think that it gives additional valuable examples of how to do processing.
--Paul Hoffman, Director
--Internet Mail Consortium