RE: ebxml packaging and transport conference call

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

See comments below marked with ## ...

David

-----Original Message-----
From: Rik Drummond [mailto:drummond@onramp.net]
Sent: Thursday, December 09, 1999 6:30 AM
To: Henry Lowe; David Burdett
Cc: 'Juan Carlos Cruellas'; ebXML-Transport@lists.oasis-open.org
Subject: RE: ebxml packaging and transport conference call


I agree.

-----Original Message-----
From: owner-ebxml-transport@lists.oasis-open.org
[mailto:owner-ebxml-transport@lists.oasis-open.org]On Behalf Of Henry
Lowe
Sent: Wednesday, December 08, 1999 3:04 PM
To: David Burdett
Cc: 'Juan Carlos Cruellas'; Rik Drummond;
ebXML-Transport@lists.oasis-open.org
Subject: RE: ebxml packaging and transport conference call


Juan Carlos and David,

What Juan Carlos (well, the Spanish EANCOM users) is asking for is
non-repudiation as well as an assurance the message arrived.  I don't
see why that should be out of scope.  Non-repudiation is a well
understood service and is offered by a number of transports, including
CORBA, as part of their security service.  For some commercial
services, it's probably necessary -- although it is does make the
implementation/product more heavy weight.  But, in commercial
applications where this is necessary, people are probably willing
to pay the price.

##Henry. In many ways I agree with you. Perhaps I've been following the
IETF/W3C dsig stuff for too long but there is an argument that goes along
the lines of, if someone gets unauthorized access to your digital
certificates then they can pretend to be you. This means that someone else
could get a message that appears to be from you even if it actually isn't.
This is what I meant in an earlier email when I was talking about the
importance of trust hierarchies and maintaining certificates in a secure
place which I think should both be out-of-scope. So how about including
something along the lines of ...

"Support must be provided that enables the sending of messages to be
non-repudiatable"

Would this meet your need?

##

The second thing, which came to mind in reading the message below,
is that, while not stated explicitly, there may be a requirement
for delivering a message once-and-once-only (e.g., you don't want
to send someone an electronic bank draft for one million Euros
twice because of some transmission error).  For this, you really
and a transport which offers once-and-once-only semantics (these
are usually based on two phase commit and there are a number of
them, the oldest probably being IBM's CICS but there are also
BEA's TUXEDO and CORBA's OTS).

## Currently in section 1 Reliable Messaging and Error Handling, it says ...

1) Documents must be capable of being sent to another party so that:
a) delivery occurs once and only once
b) ... 

Does this cover your point?
##
Best regards,
Henry
-------------------------------------
At 08:33 AM 12/07/1999 -0800, David Burdett wrote:
>Juan Carlos
>
>Having read your fuller description below. I find I agree with you
>completely, so I have added in section 2, Reliable Messaging and Error
>Handling a new item 5 as follows ...
>
>"5) There must be method by which a secure acknowledgement of the receipt
of
>a signed message can be generated and sent back to the sender of the
>original message"
>
>Does this answer your point?
>
>Regards
>
>David
>
>-----Original Message-----
>From: Juan Carlos Cruellas [mailto:cruellas@ac.upc.es]
>Sent: Friday, December 03, 1999 9:18 AM
>To: David Burdett; 'Juan Carlos Cruellas'; Rik Drummond
>Cc: ebXML-Transport@lists.oasis-open.org
>Subject: RE: ebxml packaging and transport conference call
>
>
>At 09:43 01/12/99 -0800, David Burdett wrote:
>Hi,
>
>As I told Rik, it was not possible for me to join the meeting
>December the 2ond because I was in Madrid in a conference.
>
>
>I make comments to the comments of David below on the point
>it seems we have some different views marked with #JC# .
>
>>Juan
>>
>>I think there must have been some mix up on the date as it was just Rik
and
>>I on the call this morning at 8AM Pacific Standard Time, which we
abandoned
>>after about 10 minutes.
>>
>>I've also made some comments on your suggestions below, marked with a ##
>...
>>
>>David
>>
>>-----Original Message-----
>>From: Juan Carlos Cruellas [mailto:cruellas@ac.upc.es]
>>Sent: Wednesday, December 01, 1999 9:44 AM
>>To: Rik Drummond
>>Cc: ebXML-Transport@lists.oasis-open.org
>>Subject: Re: ebxml packaging and transport conference call
>>
>>
>>At 13:36 30/11/99 -0600, you wrote:
>>Rik,
>>
>>I have  realized just now that you have fixed the conference call for
>>December 2...
>>As I told you I am not able to attend the meeting as I will be in a
>>conference tomorrow....
>>I initially thougth that you had changed the date of the meeting, but I
see
>>now that
>>you haven't, probably because it is more suitable the 2ond for other
>people.
>>Anyway, perhaps you can send me an email summarising the discussion.
>>As for me, I am specially interested in security, and there is a couple of
>>things
>>that I have to comment:
>>
>>1. In the document circulated in the list by David, and under the Security
>>topic, appear
>>requirements on signatures and confidentiality, but nothing is said on
>>secure acknowledge
>>of reception and non repudiation of receipt. I am talking about something
>>that it is
>>a real requirement in business process:  the
>>sender of a signed document wants to receive a signed document by the
>>receiver saying
>>that he has received the document he sent, and he wants to receive
>>something that can
>>demonstrate that indeed the document was received by the recipient
>>##
>>I agrere so under the security section I have added another bullet
numbered
>>"1.d" that says ...
>>"d) Signatures on digitally signed documents can be used to:
>>      i) verify the authenticity of the sender, and
>>      ii) provide a digitally signed acknowledgment of the receipt of a
>>document"
>>
>>Does this meet your requirement?
>>##
>#JC#
>I agree
>##
>> As I said, this is a real requirement: in Spain we have set up a pilot on
>>use
>>of EDI on internet among EANCOM users, and the  first thing they put on
the
>>table was
>>that they wanted to have something demonstrating that the message had
>>reached the
>>recipient. In EDIFACT a special message has been defined for this purpose,
>>the
>>AUTACK message, that contains references to the messages received and
>>digital
>>signatures of these messages, which provides to the sender with a proof of
>>that
>>the recipient actually received the message. I think that some similar
>>development
>>is needed in XML/EDI: a message, with a defined structure so that the
>>non-repudiation
>>of receipt is provided in the same way always.
>>##
>>I think there is a difference between:
>>1. The ability to digitally sign documents in a message sent over the net,
>>and
>>2. What the digital signature **means**.
>>
>>The first point I think is within scope in that we need to be able to
>>provide the structures required, but I think the second is out of scope
>>since it is an attribute of the certificate used to digitally sign the
>>document. To take a slightly crazy example, suppose, someone used a
>personal
>>digital certificate designed to be used to support the SET payment
protocol
>>and then used it to digitally sign an acknowledgement of a Purchase Order
>>what does it mean? It's clearly an abuse of the use of the SET certificate
>>and therefore any assertions about "non-repudiation" are meaningless. I
>>therfore think that actual "non-repudiation" is out of scope for our work
>>although we facilitate it happening.
>>##
>
>#JC#
>I agree in that there is a difference between the two points you are
>mentioning.
>>From what I have read from your comments, I am not very sure of
>having explained my point correctly.
>My point is, shortly speaking, that we should provide dtds establishing
>how a secure acknowledgement of a signed message received
>should be done in XML/EDI, just as AUTACK message
>in EDIFACT is doing: its use is clear in its intentions, it provides secure
>acknowledge
>by containing signatures on that signed messages arrived.
>Of course, this will serve as non-repudiation only if the private key used
>to
>sign is the one that has to be used there, as happens with the signature
>in the arrived message, but this is general: in order to conclude that
>a security service has been correctly applied the correctness of the
>cryptographic results and the cryptographic material (keys used,
>validity of certificates, etc.)  have to be checked, and I think that
>even saying that we should not consider "meanings" of the digital
>signatures,
>we should take into account that there is a need for a signed message sent
>in
>answer to another as a secure acknowledgment, and that we should provide
>a specific syntax solution for it. In fact it is not so far from one of the
>requirements,
>because it would be a digital signature of other document, only that
>computed
>as a way of acknowledge that one has received a secure message, and at the
>same time, to provide the sender with technical means to counter a risk:
the
>
>denial of having received that message...
>
>My question is, do we agree in looking if there is a specific and well
>defined
>way of doing that? and if not, do we agree in providing one?
>
> #JC#
>
>>2. On my contribution to the work of the group, I would like to focus on
>>security issues mainly.
>>In this way, I think that we should start by doing two things:
>>
>>      a. Agreeing in the security services we would like to see in the
>>XML/EDI
>>messages.
>>##
>>Agreed.
>>##
>>      b. As it seems that the other thing we should do is to carry out a
>>review of
>>      existing security standards, we should agree in a structure of the
>>review
>>documents,
>>      in terms of producing something coherent that facilitates
>>comparisons and
>>summaries,
>>      and not get a set of documents completelly different....
>>
>>      b. Reviewing existing security services and infrastructures
>>documents and
>>standards.
>>      I put on the table the parts 5, 6, 7 and 9 of ISO9735 (EDIFACT
>>syntax),
>>and I can
>>      commit myself to provide a reviewing document on them, but I can
>>also
>>participate in
>>      the review of other security standards and documents (PKCS, OFTP,
>>W3Consortium
>>      document on digital signatures, S-MIME, PKI documents, etc.).
>>##
>>... and I'll do a review of the W3C/IETF working group work and also of
>>S-MIME.
>>##
>>I think that we should arrive in the February meeting with this document
>>produced and a
>>decision taken on what our activity in the security field should be
>>afterwards (whether we
>>will produce additional specifications for other services, etc.)
>>
>>Regards.
>>
>>Juan Carlos.
>>
>>>ebxml conference call for packaging and transport wg on December 2, 1999
>at
>>>8:00 pacific standard time for one hour at most.
>>>
>>>phone number: 212 293-3102 USA
>>>
>>>Rik
>>>
>>>
>>
>>