RE: ebxml packaging and transport conference call

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

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?
##
 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.
##
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
>
>