OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-transport message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: RE: ebxml packaging and transport conference call

>>>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

-----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';
Subject: RE: ebxml packaging and transport conference call


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 

At 09:21 AM 12/10/1999 -0800, David Burdett wrote:
>See comments below marked with ## ...
>-----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
>Sent: Wednesday, December 08, 1999 3:04 PM
>To: David Burdett
>Cc: 'Juan Carlos Cruellas'; Rik Drummond;
>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
>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
>## 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,
>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
>>a signed message can be generated and sent back to the sender of the
>>original message"
>>Does this answer your point?
>>-----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:
>>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# .
>>>I think there must have been some mix up on the date as it was just Rik
>>>I on the call this morning at 8AM Pacific Standard Time, which we
>>>after about 10 minutes.
>>>I've also made some comments on your suggestions below, marked with a ##
>>>-----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:
>>>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
>>>now that
>>>you haven't, probably because it is more suitable the 2ond for other
>>>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
>>>that I have to comment:
>>>1. In the document circulated in the list by David, and under the
>>>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
>>>"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
>>>Does this meet your requirement?
>>I agree
>>> As I said, this is a real requirement: in Spain we have set up a pilot
>>>of EDI on internet among EANCOM users, and the  first thing they put on
>>>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
>>>AUTACK message, that contains references to the messages received and
>>>signatures of these messages, which provides to the sender with a proof
>>>the recipient actually received the message. I think that some similar
>>>is needed in XML/EDI: a message, with a defined structure so that the
>>>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
>>>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
>>>digital certificate designed to be used to support the SET payment
>>>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
>>>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.
>>I agree in that there is a difference between the two points you are
>>>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
>>by containing signatures on that signed messages arrived.
>>Of course, this will serve as non-repudiation only if the private key used
>>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
>>we should take into account that there is a need for a signed message sent
>>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
>>because it would be a digital signature of other document, only that
>>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:
>>denial of having received that message...
>>My question is, do we agree in looking if there is a specific and well
>>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
>>>      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
>>>      in terms of producing something coherent that facilitates
>>>comparisons and
>>>      and not get a set of documents completelly different....
>>>      b. Reviewing existing security services and infrastructures
>>>documents and
>>>      I put on the table the parts 5, 6, 7 and 9 of ISO9735 (EDIFACT
>>>and I can
>>>      commit myself to provide a reviewing document on them, but I can
>>>participate in
>>>      the review of other security standards and documents (PKCS, OFTP,
>>>      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
>>>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.)
>>>Juan Carlos.
>>>>ebxml conference call for packaging and transport wg on December 2, 1999
>>>>8:00 pacific standard time for one hour at most.
>>>>phone number: 212 293-3102 USA

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Search: Match: Sort by:
Words: | Help

Powered by eList eXpress LLC