Re: [ebxml-cppa] Schema and examples illustrating SecurityDetails andSender/Receiver clarification

[Martin W Sachs <mwsachs@us.ibm.com>]

Peter,

This is an excellent approach.

As to client-authenticated SSL, I am not familiar enough with SSL to have a
strong opinion on hwat has to be specified.  However, I understand that it
has 3 or 4 authentication modes and that it has a negotiation process by
which the two parties can agree on how to authenticate.  If so, it might
not be necesary to name the authentication mode explicitly.  However
different modes may require different properties in the transport element
and this would have to be explained.  I guess that one example is whether
neither, one, or both parties have to supply certificates.

I agree that specialization of Transport and DocExchange into sender and
receiver flavors is useful both from an understanding viewpoint and from
the viewpoint of whether the schema can enforce certain things if there are
sender and receiver flavors.

Regards,
Marty

*************************************************************************************

Martin W. Sachs
IBM T. J. Watson Research Center
P. O. B. 704
Yorktown Hts, NY 10598
914-784-7287;  IBM tie line 863-7287
Notes address:  Martin W Sachs/Watson/IBM
Internet address:  mwsachs @ us.ibm.com
*************************************************************************************



Peter Ogden <pogden@cyclonecommerce.com> on 01/03/2002 06:34:22 PM

To:    "ebXML-CPPA (E-mail)" <ebxml-cppa@lists.oasis-open.org>
cc:
Subject:    [ebxml-cppa] Schema and examples illustrating SecurityDetails
       and Sender/Receiver clarification




Attached is an updated CPPA schema that incorporates  SecurityDetails and
illustrates one way we might be able to clarify  whether certain Transport
and DocExchange properties are  sender-related or receiver-related. Here
are the main things to look  at:

1. There is a new global SecurityDetails element  that contains 0 or more
sets of TrustAnchors. A trust anchor is just an IDREF to  a root
certificate (or certificate chain) that resides in the
PartyInfo/CertificateRef collection. The PartyInfo now contains 1 or more
of  these new SecurityDetails elements.

2. In the CPA a DeliveryChannel is sort  of "directional" in that it
currently defines the sending and receiving  properties needed to establish
a one-way connection between a sending party and  a receiving party. But in
the CPP, each party specifies one "end" of a DC. That  is, you specify the
sending properties for the DC over which you will send  requests/responses
to your partner, and the receiving properties for the DC over  which you
will receive requests/responses from your partner. ActionBindings for
messages you send would point to one of your send-side DC elements,
ActionBindings for messages you receive would point to one of your
receiver-side DC elements.
     Thus, under the PartyInfo/Transport element there is a
TransportReceiver element and aTransportSenderelement. The receiver differs
from the sender in that it has an Endpoint.  Both types have a
TransportSecurity element. For the receiver, you would specify  a
server-side authentication certificate and an optional set of
SecurityDetails  (trust anchors) governing the certificates you are willing
to accept from the  client. For the sender, you would specify a client-side
authentication  certificate and an optional set of SecurityDetails
governing the certificates  you are willing to accept from the server.
    Dale and Arvola exchanged email before the holidays discussing how to
go about  requesting (requiring) client-authenticated SSL. I haven't done
anything with  that yet - I'm still thinking about whether we need anything
explicit in  TransportSecurity or whether just the presence/absence of that
element is  enough.Any  thoughts?

3. Similar to Transport, the DocExchange element  contains an
ebXMLSenderBinding element and an ebXMLReceiverBinding element. On  the
sender side, the NonRepudiation element contains a SigningCertificateRef
pointing to the cert the sender wants to use for NRO and an
AckSecurityDetailsRef pointing to the policy and trust anchors that govern
the  certificate the sender is willing to let the receiver use for signing
acknowledgments. The sender-side DigitalEnvelope element contains an
EncryptionSecurityDetailsRef element which points to the policy and trust
anchors that govern the certificate the sender needs to obtain from the
receiver  for digital envelope key exchange. The ebXMLReceiverBinding
element contains  complementary elements.

Arvola commented  earlier that specialization of Transport and DocExchange
into Sender and  Receiver flavors is not really necessary. I agree, but I
think that doing  sogives us the opportunity to make things  a bit more
obvious and less confusing. It  also allows the schema to enforce, for
example, that a TransportSender element  contains a ClientCertificateRef
and not a ServerCertificateRef. If after  review we decide against this
approach, reverting to the nonspecialized approach  should be easy.

Respectfully,

Peter  Ogden