RE: Requirements and defintions documents

[David Burdett <david.burdett@commerceone.com>]

Dwight

>>>I see that I have missed the deadline by more than a day<<<

... don't worry. I've been ill with the flu so the deadline's automatically
been extended ... a bit !! 

See comments below

David

-----Original Message-----
From: Dwight Arthur [mailto:darthur@bigfoot.com]
Sent: Sunday, January 16, 2000 5:53 AM
To: David Burdett
Subject: RE: Requirements and defintions documents


David, I am just starting up in this discussion and after I wrote these
comments I see that I have missed the deadline by more than a day. Also, I
am hesitant to offer updates to these documents as I am unaware of the
extent to which some passages offered may be drawn from authoritative
sources or may be the result of long thorough discussions. I do not want to
restart any controversies that may have quiesced, etc.

Please feel free to discard these comments if they are not helpful - but I
thought I would send them along in case they might be helpful. . .

*Definitions Document*
COMMENT ONE
Section 1.1 currently states:
A Message can optionally include a Digital Signature so that:
1) The authenticity of the message might be determined
2) Any changes to the message can be identified.

I would change it to:
A Message can optionally include a Digital Signature so that:
1) The identity of the party sending the message can be authenticated
2) Any changes to the message can be detected.

Reasoning: I can send you message containing an offer to sell you
merchandise that does not exist, complete with a bogus photograph, and sign
it digitally. The signature has little if any bearing on the authenticity of
the offer contained in the message, but does authenticate that I sent it. If
someone modifies the message by inserting <warning>fraudulent
message</warning> into the message, the digital signature will not single
out the "warning" entity as the changed data, but will clearly show that
some change unidentified change has occurred.
##Useful clarifications.##

COMMENT TWO
Sections 1.2.1 and 1.2.11 indicate that a Document Exchange is either a
simple >>request>>, <<response<< pair or else is composed of multiple round
trips. Both of these alternatives share the characteristic that it is an
even number of messages between exactly two parties.

A simple transaction that does not follow this scenario is >>offer>>,
<<counteroffer<<, >>acceptance>>.
##It is exactly this open ended exchange of messages that section 1.2.11 is
trying to describe as a Multiple Round Trip Document Exchange##

A more complex example is >>(consumer to bank)initiate payment to
merchant>>, >>(bank to merchant)consumer initiated payment>>, <<(merchant to
consumer)receipt of payment<<. A careful reading of your definitions
document would suggest that you would see this as three services or
sub-services,  each with its own request and response, for a total of six
messages. 
##Here you're describing a "three-way" conversation. Although this type of
conversation is quite feasible, it can be hard to make this work reliably.
For example if the Consumer doesn't get a receipt from the Merchant, then
who does he go to when he wants to fixe the problem. You can always solve
the problem by breaking it down into a series of request response pairs, for
example by routing the consumer to bank payment through the Merchant. But
then their are potentially privacy issues over, for example, credit card
info that could make this less than desirable which is one of the reasons
why the Card Associations invented SET ... but that'a another long story. So
to summarize, I think that although there is a requirement along the lines
you suggest I'm not sure it adds much by way of clarification.##

If so, I would drop this example but leave the
offer/counteroffer/acceptance example on the table.
##See previous comment.##

COMMENT THREE
It's the digital signature thing again, in section 1.2.5 - I'm concerned
that this definition may be a part of some canon, in which case I would not
want to comment. Or, there may be some excellent definition available from
the ITU x509, IETF-PKIX or ANSI X9.59 standards, none of which I have with
me. Just to create a definition from the top of my head I would say that:

A digital signature represents a string of binary digits of arbitrary length
created by using a cryptographic key known only to the party sending a
message. The string is composed of an encrypted digest of some or all of the
data in the message or in another location addressable by a URI. 
It is accompanied by some method (such as a digital certificate)of
identifying to
the party receiving the  message, what key can be used to validate the
digest against the original data. The digital certificate can (among other
things) be used to authenticate that the sender of the message must be a
party who holds the subject key, and that the message has not been changes
since the signature was applied.
##I think your definition describes more how to calculate what a signature
is rather than what it can be used for. Your description also focuses on use
of PKI wheras symmetric keys might be used in some circumstances between two
parties. In my definition I was trying to describe what signatures could be
used for. However I've added part of your description as a footnote.##

*Requirements Document*
COMMENT FOUR
In section one about the envelope, items seven and nine presume that a
message queuing transport is in use. They could be expressed in a more
general form by saying:

7. Message Envelopes should contain an address to which response messages
can be routed; actual use of this property by sending and receiving
applications is optional.

9. Message envelopes should contain an administrative address to which
acknowledgement, messages can be routed; actual use of this property by
sending and receiving applications is optional.
##Good clarifications - included.##

COMMENT FIVE
Paragraph 2.1.c discusses recovery from failure to receive a response to a
request. It would appear that you are referring to an application-level
timeout rather than a transport-level timeout. (e.g. when I send an order to
purchase a mutual fund investment I expect the communications
acknowledgement in 2 minutes, the order acknowledgement within two hours,
and the order confirmation within two days. I think the order confirm is
your response message, with the order acknowledgement being an exchange,
even though there is no reply to an order ack.) If I am reading this
correctly, this paragraph should eliminate the ambiguity, perhaps by stating
"if an application-level response message is not received etc."
##Agreed##

This concept of an application-level timeout suggests a couple of implicit
requirements which should be made explicit.
(a) It would be bad for the network if parties had differing ideas of
"expected timeframes" - there should be some explicit definition of this
either in a protocol spec that defines a service, or in the message
envelope.
##I agree, but there are other alternatives too such as negotiating the
response. This is particularly true for business (application) level
responses. I've added a comment to the spec.##

(b) There should be some clear spec, perhaps again as a part of a service
definition, of what message the sender of a request message should send if a
response is not received in expected times. There should probably also be a
spec for what message a receiver of a request message should send if
application timeout is approaching and the response is not ready. For
example for the message exchange >>order>>, <<invoice<< there might be an
exchange initiated by the sender >>request order status>>, <<order status<<
which the receiver could avoid by sending <<backorder<<. The service
definition could state that every order will be responded to by an invoice
or backorder within one week, that request order status will be rejected if
the order is less than one week old and otherwise order status will be sent
within one hour.

The preceding also carries an implicit need for hours of operation to be
defined, perhaps as a part of a service definition, which in turn may
reference other locations. For example, a service definition could state
that elapsed time counts only 1400-2100 GMT on days when the New York Stock
Exchange is open as defined at http://www.nyse.com/holidays, or 1300-2000
GMT on dates when daylight savings time is in effect as defined at
http://www.time.gov/DST
##Good ideas. I've adapted the requirements.##

COMMENT SIX
I believe that this document is specifying transport layer errors and rules
by which a service definition will specify the reporting of application
layer errors. I think it's important to keep these separate. I believe that
2.2.a through 2.2.e are a good representative sample of transport layer
errors. I believe that 2.2.f is a broad allusion to the requirement for
application layer error messages unique to each defined service and should
be separated from the others. An example of this is that the FIXml protocol
covers a considerable variety of conditions that lie somewhere between
success and failure including:
- Order stopped (order not yet filled but will be before end of day at a
price equal to or better than the price specified in the STOP message)
- Partially filled, specifying quantity remaining to be filled
- Done for the Day
- Etc.
##I agree with you. This separation is a good characteristic for a protocol.
The separation also exists in the IOTP specification I'm the author of. I
think the presence or absence of this separation is one of the things we
should use when evaluating altenative approaches.##

COMMENT SEVEN
In 2.3 a comma after the word "failed" will prevent people from misreading
as I did about a message that "fails to discover" the reason why.
## I see what you mean ;-) Fixed.##

COMMENT EIGHT
In 2.4 the word secure implies a lot and requires little. Perhaps you mean
that this message should have verifiable integrity, an authentic source, and
assured delivery?
##Good point. I've clarified the text##

COMMENT NINE
Re 2.5 I am afraid of another three year long debate about the problematic
nature of non-repudiation, which can be achieved only with massive
infrastructure such as audit trails, notary services, net-wide verifiable
synchronization to a source of authentic time, _plus_ legal and regulatory
changes. Is it realistic to expect that every defined service will
necessarily support all of this? Perhaps you meant something less stringent
than non-repudiation, like verifiable source and integrity.
##You're right about what's required for non-repudiation. I think it all
depends on what is meant by the word "enable" in the original text ...

5) Support must be provided that **enables** the sending or receipt of
messages to be non-repudiatable

I think what I mean is that nothing in the security support of a messaging
protocol should preclude making messages non-repudiatable. This means that
if you want the audit trails, notary services, etc, you can do ... but you
don't have to. I've clarified the text.##

COMMENT TEN
In 3.1 I believe that point b represents two distinct routs: broadcast
(simultaneous delivery to multiple parties) and workflow (serial delivery to
a list of recipients, with each delivery after the first occurring when the
prior recipient designates completion). Perhaps you meant this by the
comments in 3.2 but I took 3.2 as addressing timing issues between multiple
related messages where 3.1 addressed timing issues between multiple
recipients of a single message.
##I actually meant that a single message may be sent to a single or multiple
destinations in parallel. The heading of the section is Message Routing
rather than Message Workflow.##

COMMENT ELEVEN
I do not understand 4.2.b - would it make sense if this was about Messages
rather than Documents? To my way of thinking, transport protocols should not
necessarily be able to see the documents that may comprise a message in
transit, and would therefore have to encrypt at the message level.
##Agreed changed documents to messages.##

COMMENT TWELVE
A can of worms is opened in footnote one where mention is made of persistent
signatures. Let's discuss whether there is a requirement that the signature
used to verify the integrity and attribution of a message must be a
candidate for persistent storage with the message content for subsequent
re-verification. The infrastructure mandated by this requirement would be a
historical archive of information necessary for verifying that a given
digital signature was valid at a specified historical pint in time. The fact
that today's impenetrable cryptography will be tomorrow's toy makes this
task especially challenging - A recommended alternative would be for the
party storing the record to store an indication that the signature was valid
at the time of receipt.
##Your comments are accurate - it is a very large can of worms. However, the
reason this text was placed in a footnote is that it an explanation rather
than a requirement. I also don't think that we can specify requirements on
persisting signatures since that will be dependent on the application that
will use them.##




That's it this time.
-Dwight Arthur
Managing Director, Systems
Depository Trust and Clearing Corporation
Darthur@bigfoot.com