ietf-smime
[Top] [All Lists]

RE: ESS-01 issues not finished

1998-03-17 14:06:41
Russ,

We did not change course.  ESS-04 includes your proposal regarding multiple
eSSSecurityLabel attributes included in a signedData object.  The recent
debate has been regarding the processing of multiple mlExpansionHistory
attributes in a signedData object.  The last para of ESS-04, sec 3.1.1 and
first paras of 3.1.2 read as follows:

"There can be multiple SignerInfos within a SignedData object, and each
SignerInfo may include authenticatedAttributes. Therefore, a single
SignedData object may include multiple eSSSecurityLabels, each SignerInfo
having an eSSSecurityLabel attribute. For example, an originator can send a
signed message with two SignerInfos, one containing a DSS signature, the
other containing an RSA signature. If any of the SignerInfos included in a
SignedData object include an eSSSecurityLabel attribute, then all of the
SignerInfos in that SignedData object MUST include an eSSSecurityLabel
attribute and the value of each MUST be identical.

3.1.2 Processing Security Labels

Before processing an eSSSecurityLabel authenticatedAttribute, the receiving
agent MUST verify the signature of the SignerInfo which covers the
eSSSecurityLabel attribute. A recipient MUST NOT process an
eSSSecurityLabel attribute that has not been verified.

A receiving agent MUST process the eSSSecurityLabel attribute, if present,
in each SignerInfo in the SignedData object for which it verifies the
signature. This may result in the receiving agent processing multiple
eSSSecurityLabels included in a single SignedData object. Because all
eSSSecurityLabels in a SignedData object must be identical, the receiving
agent processes (such as performing access control) on the first
eSSSecurityLabel that it encounters in a SignerInfo that it verifies, and
then ensures that all other eSSSecurityLabels in signerInfos that it
verifies are identical to the first one encountered. If the
eSSSecurityLabels in the signerInfos that it verifies are not all
identical, then the receiving agent MUST warn the user of this condition."

================================
John Pawling   
jsp(_at_)jgvandyke(_dot_)com                             
J.G. Van Dyke & Associates, Inc.           
================================


At 06:21 AM 3/16/98 -0500, Russ Housley wrote:
S/MIME WG:

I thought we were going down this track, but I still see a fair amount of
discussion of recipient processing of mis-matched labels.  When did we
change course, and why?

Russ



<Prev in Thread] Current Thread [Next in Thread>