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

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?



-----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 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 ##
>-----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 see
>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 of
>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
>Does this meet your requirement?
I agree
> As I said, this is a real requirement: in Spain we have set up a pilot on
>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,
>AUTACK message, that contains references to the messages received and
>signatures of these messages, which provides to the sender with a proof of
>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 net,
>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 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.

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 secure
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 the
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: the

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?


>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