ietf-smime
[Top] [All Lists]

RE: ESS-04 Comments

1998-03-16 10:52:38
Jim,

You make an excellent point, but I don't agree with your specific
recommendation because I don't believe that the MLA should reject a message
based on unauthenticated information.  I believe that the best way to
resolve this issue is to change ESS so that it requires that multiple
mlExpansionHistory attributes must be processed similar to multiple
eSSSecurityLabel attributes (except I don't believe that mlExpansionHistory
attributes MUST always be critical).  In addition to my original comments, I
propose the following changes to ESS, Sec 4.1:

1) Sec 4.1, 4th para, last sent: Please make the following change:

OLD: "Not all of the SignerInfos need to include mlExpansionHistory
attributes, but in all of the SignerInfos that do contain mlExpansionHistory
attributes, the mlExpansionHistory attributes MUST be identical."

NEW: "If any of the SignerInfos included in a SignedData object include an
mlExpansionHistory attribute, then all of the SignerInfos in that SignedData
object MUST include an mlExpansionHistory attribute and the value of each
MUST be identical."


2) Sec 4.1, 5th para: Please make the following change:  This replaces my
original comment 11:

OLD: "A recipient SHOULD only process an mlExpansionHistory attribute if the
recipient can verify the signature of the SignerInfo which covers the
attribute. A recipient SHOULD NOT use an mlExpansionHistory attribute which
the recipient cannot authenticate."

NEW: "A recipient MUST verify the signature of the SignerInfo which covers
the mlExpansionHistory attribute before processing it. A recipient MUST NOT
process an mlExpansionHistory attribute which the recipient has not verified."


These new comments combined with my original comments result in the
following text for the last three paragraphs in Sec 4.1:

"There can be multiple SignerInfos within a SignedData object, and each
SignerInfo may include authenticatedAttributes. Therefore, a single
SignedData object may include multiple SignerInfos, each SignerInfo having a
mlExpansionHistory attribute. For example, an MLA 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 mlExpansionHistory attribute, then all of the SignerInfos in that
SignedData object MUST include an mlExpansionHistory attribute and the value
of each MUST be identical.

A recipient MUST verify the signature of the SignerInfo which covers the
mlExpansionHistory attribute before processing it. A recipient MUST NOT
process an mlExpansionHistory attribute which the recipient has not been
verified.

When receiving a message that includes an outer SignedData object, a
receiving agent that processes mlExpansionHistory attributes MUST process
the mlExpansionHistory 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 mlExpansionHistory attributes
included in a single SignedData object. Because all mlExpansionHistory
attributes must be identical, the receiving application processes the first
mlExpansionHistory attribute that it encounters in a SignerInfo that it can
verify, and then ensures that all other mlExpansionHistory attributes in
signerInfos that it verifies are identical to the first one encountered.  If
the mlExpansionHistory attributes in the signerInfos that it verifies are
not all identical, then the receiving agent MUST stop processing the message
and MUST notify the user or MLA administrator of this error condition."


Does that sound meet your requirement?

- John Pawling



At 08:08 AM 3/16/98 -0800, Jim Schaad (Exchange) wrote:
John,

I have a small problem with the following change.  While I agree that it is
correct, there is a possiblity that this can lead to exactly the situation
we were trying to avoid.  If A cannot verify B's signature and B cannot
verify A's signature.  What is to stop them from sending messages back and
forth if some other item (such as a gateway) is also sticking in signatures.


11) Sec 4.1, 5th para: Please make the following change:

OLD: "A recipient SHOULD only process an mlExpansionHistory attribute if the
recipient can verify the signature of the SignerInfo which covers the
attribute. A recipient SHOULD NOT use an mlExpansionHistory attribute which
the recipient cannot authenticate."

NEW: "A recipient MUST verify the signature of the SignerInfo which covers
an mlExpansionHistory attribute before processing it. A recipient MUST NOT
process an mlExpansionHistory attribute which the recipient cannot
authenticate."

We perhaps should add a sentence along the lines of "If an
mlExpansionHistory is found in a signature which cannot be verified, and no
matching mlExpansionHistory is found in a verifiable signature, the MLA
SHOULD stop processing."

jim






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