RE: ebxml packaging and transport conference call

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

>>>requirements are supposed to be implementation independent.<<<

A good point,  so I've included the following in section 2 Reliable
Messaging and Error Handling.

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

David
-----Original Message-----
From: Henry Lowe [mailto:hlowe@omg.org]
Sent: Friday, December 10, 1999 10:39 AM
To: David Burdett
Cc: 'Rik Drummond'; 'Juan Carlos Cruellas';
ebXML-Transport@lists.oasis-open.org
Subject: RE: ebxml packaging and transport conference call


David,

The requirements I can agree with as below.

On the certificates thing, as I'm not a sucurity guru, I don't 
want to go any further without advice from our security folk. 
There may be other ways to meet the requirement other than 
with certificates -- requirements are supposed to be implementation 
independent.

Henry
-----------------------
At 09:21 AM 12/10/1999 -0800, David Burdett wrote:
>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
>>>>
>>>>
>>>
>>>
>