RE: [ebxml-jc] ebXML security "architecture"

Title: Message

I have 
often wondered if an ebXML architecture document (and perhaps the UN/CEFACT 
Electronic Business Architecture) should fully discuss security across a 
multi-enterprise and multi-party ebXML deployment.

 

Brian

  

  
-----Original Message-----
From: Dale Moberg 
  [mailto:] 
Sent: Wednesday, August 07, 
  2002 2:24 PM
To: 
Subject: 
  [ebxml-jc] ebXML security "architecture"

[draft of information on security in ebXML]

  
The ebXML architecture document, http://www.collaborativedomain.com/standards/documents/eBTWG_Architecture_v0.50.pdf, does not itself have a security section, and refers to security 
  details as part of the technical details configured within the ebXML CPA, 
  which itself can provide configuration information for the ebXML Messaging 
  layer.

The UN/CEFACT Modeling Methodology (UMM) [defined in the N090R10 
  specification, http://www.gefeg.com/tmwg/n090r10.htm ] which is also architectural, defines some security attributes that can be specified for 
  business collaborations.These trickle down eventually into the BPSS [http://www.ebxml.org/specs/ebBPSS.pdf ]as attributes of BusinessActions (the 
  RequestingBusinessActivity and RespondingBusinessActivity), and the CPPA 
  specifies how these security attributes are more concretely 
  implemented.

ebXML 1.0 did issue a Security 
  Risk Assessment document, http://www.ebxml.org/specs/secRISK.pdf,
as 
  part of the Technical Architecture. Sections 14 and  15 on future 
  requirements listed areas where ebXML
specifcations might be improved. CPPA 
  has followed several of these suggestions in producing version 2.0 of 
  its
specification, now under review at OASIS. For example, additions now 
  allow agreement on PKI matters such as trust
anchors; this permits each 
  side to know the other can validate the certificates (even when 
  self-signed)
that are used in the various cryptographic operations over the 
  message.

ebXML itself is more a consumer of security specifications 
  rather than an originator. Because security agreements can be variously 
  implemented, a start at representing security capabilities that can be used in 
  implementing secure collaborations has been made in the CPPA work, and in the 
  ongoing Negotiation protocol work in that area. At present, the security 
  details that can be represented pertain 
  to functional areas such as digital enveloping, digital signatures for use in 
  non repudiation of origin or receipt, transient confidentiality and 
  authentication as found in SSL 3.0 or TLS 1.0, and authentication credentials 
  (mainly basic or digest modes for HTTP). The 
  Oasis ebXML Messaging specification has an appendix outlining various security 
  profiles for use within ebXML that involve combinations of 
  the preceding functions along with some others. The Messaging 
  specification also details a way to sign SOAP with attachments using 
  XMLDsig for the signature technology that has been tested for 
  interoperability.