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

[Arvola Chan <arvola@tibco.com>]

Peter:

 

Here are some comments on the schema and examples illustrating SecurityDetails and Sender/Receiver clarification:

1. Either the ##any wildcard element in SecurityPolicy needs to have a minOccurs of "0" or the examples should be modified to omit the empty SecurityPolicy element. Currently, the examples fail schema validation.
2. The WillInitiate and WillRespond elements (under ServiceBinding) each has a REQUIRED ThisPartyActionBinding and an OPTIONAL OtherPartyActionBinding. The intent is that OtherPartyActionBinding is not used in a CPP but is required in a CPA. In the latter case, we want to show that the sender's half of the delivery channel is matched up correctly to the receiver's half of the delivery channel (e.g., both the sender and the receiver specify the same communication protocol, the sender's signing certificate is compatible with the receiver's security details, etc.) This simplifies the logic that a MSH has to use at run time to determine the complete characteristics (including certificate references and security details) just by examining its own CollaborationRole element in the CPA.
3. I think the AckSecurityDetailsRef under SenderNonRepudiation and the AckCertificateRef under ReceiverNonRepudiation may be unnecessary. The sending of ReceiptAcknowledgment as a business signal will have its own ActionBinding to indicate the delivery channel characteristics and CertificateRef/SecurityDetailsRef.
4. Currently, there is an Endpoint element under TransportReceiver but not TransportSender. I wonder if an Endpoint will be necessary when SSL Client/Server mutual authentication is performed. I believe the server's URL is embodied in the server's certificate. Do we need to capture the sender's URL in the client's certificate? When SMTP is used, will we need to capture the sender's email address?
5. I agree with your earlier comments that we should probably recommend that the IDs used within CPPs be prefixed with the party's name so that there are no ID clashes when two CPPs are merged to form a CPA.

Regards,

-Arvola

----- Original Message -----

From: Peter Ogden

To: ebXML-CPPA (E-mail)

Sent: Thursday, January 03, 2002 3:34 PM

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 aTransportSender element. 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 so gives 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