ietf-smime
[Top] [All Lists]

Reply Requested Proposal (was RE: Rethinking Receipt)

1998-04-14 07:34:44
Rik,

In my opinion, your proposal is mixing apples and oranges.  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.  For example, you could
propose the addition of a "replyRequested" authenticated attribute which
requests that the recipient perform the services that you discuss in your
message.  Your proposal could also propose a strategy for implementing the
"replyRequested" mechanism.

Also, your previous message mentioned: "The disposition-mode,
disposition-type and disposition-modifier may be spelled in any combination
of upper and lower case characters."  Are you stating RFC 2298 does not use
ASN.1??  This is even more of an argument why it should be discussed
separately than the ESS signed receipt strategy (which uses ASN.1).

In summary, your proposal can and should be independent of the ESS signed
receipt mechanism.

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


At 09:06 AM 4/14/98 -0500, Rik Drummond wrote:
It can't be independent of the signed-receipt.

A signed-receipt which only gives status information that it got there and 
the signature was readable is not good enough for many 
application-to-application implementation. They often need to know more 
than that.  The signed-receipt (or just receipt) should convey the type of 
information that these applications need to automate the process. The 
status codes should be expanded to allow things like "deleted" or 
"processed" .

A tremendous amount of work went into this area over the last two years the 
groups should at least look at it to understand why I am saying what I am 
saying.

The IETF's EDIINT WG which has I-D out on how to do secure EDI over 
internet would some day like to use the work you are doing. We can't unless 
we have additional status codes in the signed-receipt.

Thanks for your help, Rik




<Prev in Thread] Current Thread [Next in Thread>
  • Reply Requested Proposal (was RE: Rethinking Receipt), John Pawling <=