All,
Jim makes a good point, but I still believe that the essSecurityLabel
authenticatedAttribute must always be critical. The basis of my opinion is
that when the signer decides to include an essSecurityLabel
authenticatedAttribute in a signedData object, then the signer has made a
deliberate decision that the data must be labeled with specific security
classification and security category values. By populating the
essSecurityLabel attribute, the signer is stating a requirement that the
recipient must honor that essSecurityLabel by processing it and by
performing access controls checks based on the included values. If ESS is
written to allow the essSecurityLabel to be non-critical, then the receiving
software could legally ignore the essSecurityLabel and continue processing
the signedData without acting on the essSecurityLabel and without indicating
that condition to the recipient. I believe that is not acceptable because
it is not consistent with the signer's requirements implied by the signer
populating the essSecurityLabel in the first place.
If the WG agrees that the essSecurityLabel must always be critical, then I
agree with Jim's comment that the intro to ESS should reflect the fact that
essSecurityLabels are not interoperable with legacy S/MIME v2 implementations.
- John Pawling
At 01:34 PM 2/27/98 -0800, Jim Schaad (Exchange) wrote:
There is a problem with making essSecurityLabel critical. This means
that it cannot be used in S/MIME v2 clients and they will not understand
the signed message which comes in. The version on the signedData object
would be 3. With this change we have now moved to the point where no
items in ESS (except for mlExpansionHistory which is a server side
"feature") can be done with S/MIME v2. If we accept this then we need
to re-write the intro to ESS.
jim