ietf-smime
[Top] [All Lists]

RE: Rethinking Receipt

1998-04-16 08:36:46
From: jsp(_at_)jgvandyke(_dot_)com (John Pawling)

Rik,

I respectfully disagree with your proposal to add fields to the ESS signed
receipt to accomplish MDN functionality.


I don't believe it is necessary to add fields to the receipt syntax
in order to accomplish MDN functionality.

Instead of interpreting proposals literally and picking them apart based
on narrow issues, perhaps it would be more productive for us all to
attempt to understand what the proposer has in mind.
"Read what I meant, not what I wrote" - computers are literal, but humans
are supposed to be able to exercise judgement.



From: Paul Hoffman / IMC <phoffman(_at_)imc(_dot_)org>

reply: user does a reply-to email or news

Rat hole alert! Megabytes have been wasted on the DRUMS WG mailing list
about this topic recently. There is no consensus on the topic. To be
honest, there is violent disagreement. There is no agreement on what
"reply-to" means.

Paul, respectfully speaking, I don't give a rat's behind about the
specific semantics of an RFC822 Reply-to: email header field.  I used
the term "reply-to" generically, to indicate that a human user has seen
a message and wishes to respond to it in some manner.  Nothing more.


and assuming that all four have a requirement to provide an integrity-
 protected link from the response back to the original message it is
 responding to,

Wrong. This is not mentioned in DSNs or MDNs.

Has the Security Area Director sufficiently drummed into our heads the
fact that the Security working groups SHALL work more closely with the
Application working groups to accomplish common goals?

I assume that Applications have some requirement for meaningful
security.  I assume that authors of Application RFCs are not necessarily
security experts.  I assume that if we, as security experts, identify
an instance where the security of applications can be improved, it is
up to us to draft both the requirements/security-considerations/vulner-
ability assessments and the proposed solutions for consideration by
the Application folks, and work interactively with them to iterate
down to the best solution.

If our position is "they didn't state it as an unmet requirement in
RFC 1894 or RFC 2298, therefore we have no responsibility to address it",
then fine.  We'll just produce our RFCs, declare victory, and go home.


How about the reply case, where the user wants to say "I agree with
your proposal" and wants to guarantee that his reply is unambiguous
without including the entire original text in the reply?

This is a new topic, and an interesting one. You are suggesting an
unambiguous message-identifier that can be inserted in a signed message as
a reference. You may want to look at draft-fielding-uri-syntax-02.txt and
see if your proposal fits into that framework.

It could be forced to fit, but doing so would be highly duplicative.

Here's a picture of two scenarios, ESS Receipt and a generic reply:

Scenario 1:
  Message 1:                     Message 2 (ESS Receipt):
  _______________________        _____________________________
 | Content (id-data)     |      | Content (id-ct-receipt)     |
 |- - - - - - - - - - - -|      |  SignedContentID, SigValue  |
 | SignerInfo            |      |- - - - - - - - - - - - - - -|
 |  id-aa-ReceiptRequest |      | SignerInfo                  |
 |   SignedContentID     |      |_____________________________|
 |_______________________|


Scenario 2:
  Message 1:                   Message 2 (response to message 1):
  _____________________        _______________________________
 | Content (id-data)   |      | Content (id-data)             |
 |- - - - - - - - - - -|      |- - - - - - - - - - - - - - - -|
 | SignerInfo          |      | SignerInfo                    |
 |  id-aa-ContentID    |      |  id-aa-SignedContentReference |
 |    ContentURI       |      |   ContentURI, SigValue        |
 |_____________________|      |_______________________________|


If you wanted to use URI syntax, it would have to uniquely identify
the message for retrieval purposes, and be included in the signed
attributes of Message 1 to prevent tampering/substitution.
Draft-fielding-uri-syntax-02.txt lists examples of ftp, gopher, http,
mailto, news, and telnet URIs, but it does not give any examples
of retrieving a message (say via ftp or http) using Message-IDs or
some other unique identifier.   Since ESS currently has a perfectly
good recommendation for the construction of ContentIdentifier, it
seemed reasonable to reuse it.  However, if there is an equivalent
strength spec for the construction of Message-ID:, one could use
it as the ContentIdentifier.  I don't see any benefit in encoding
either the ESS ContentIdentifier or a Message-ID as a URI for use
in a signed attribute, but if you think it would serve a purpose,
I wouldn't strenuously object to URI encoding.


But forget all of the above for a moment.

My proposal is simply to modify the ESS receipt syntax to change it
from a content type to an attribute.  This would have absolutely no
effect on the operation or semantics of Receipt, and is not
dependent upon any other proposals regarding any other message types.

                                 Message 2 (ESS Receipt):
                                 _____________________________
                                | Content (id-data) (absent)  |
                                |- - - - - - - - - - - - - - -|
                                | SignerInfo                  |
                                |  id-aa-receipt              |
                                |   SignedContentID, SigValue |
                                |_____________________________|


To avoid getting wrapped up in rat holes and irrelevancies, lets
just proceed one step at a time, beginning with this simple proposal.


--- Replace ESS Section 2.8
--- and the corresponding ASN.1 in Appendix A with:

  Section 2.8 Receipt Syntax

  Receipts are represented using the Receipt attribute.  The Receipt
  attribute shall have ASN.1 type Receipt.  Receipts must be carried
  in the signedAttributes of a SignerInfo.  The SignedData eContentType
  field is id-data, and the eContent field is absent.

  Receipt ::= SEQUENCE {
    contentType ContentType,
    signedContentIdentifier ContentIdentifier,
    originatorSignatureValue OCTET STRING }

  id-aa-receipt OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
     rsadsi(113549) pkxs(1) pkcs-9(9) smime(16) id-aa(2) 8 }

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