Dave,
The ESS signed receipt concept and syntax has been designed to meet a
specific purpose which is to simply indicate that the original message was
received and the signature was verified. Your proposal includes services
that go well beyond that scope. I am not saying that your proposal is not a
valid requirement, but I am saying that it includes requirements that are
significantly different than the security services provided by the ESS
signed receipt and should be implemented in a separate mechanism. I am
opposed to proposals that overload the current ESS signed receipt concept
and syntax. Please re-formulate your proposal so that it is independent of
the ESS signed receipt concept and syntax. For example, you could propose
the addition of a "signedContentReference" authenticated attribute which
requests that the recipient perform the services that you discuss in your
message. Your proposal should also propose a strategy for implementing the
"signedContentReference" mechanism.
I am opposed to the following idea because of the aforementioned reasons:
OK, how about using attribute IDs to distinguish purpose. Come to
think of it, I like this better than the original proposal anyway.
id-aa-receipt OBJECT IDENTIFIER ::= { ... }
-- with syntax SignedContentReference
id-aa-reference OBJECT IDENTIFIER ::= { ... }
-- with syntax SignedContentReference
SignedContentReference ::= SEQUENCE {
contentType ContentType,
signedContentIdentifier ContentIdentifier,
originatorSignatureValue OCTET STRING }
================================
John Pawling, jsp(_at_)jgvandyke(_dot_)com
J.G. Van Dyke & Associates, Inc.
www.jgvandyke.com
================================