本文是两篇有关ebxml安全性的文章中的第一篇，主要讨论消息层。如果需要了解对ebxml概念的一般性介绍，以及研究一些基于功能阶段实现普通ebxml交互的全部用例，请参看ebxml简介。本文将重点解释消息级别的安全性和ebxml消息传送（ebms）的安全策略机制。
　　
　　本文开头综述了消息层安全性的优势。文中简要讨论了消息层安全性和瞬时套接层安全性之间的区别。在摘要中提出的概念对于理解有关ebms消息层安全性方面内容的其他部分极为重要。接下来将深入研究如何使用协作协议轮廓（collaboration protocol profile，cpp）和协作协议协定（collaboration protocol agreement，cpa）来为ebxml消息层描述安全性策略。
　　
　　什么是消息层安全性？
　　
　　在实际情况中，大多数ebxml消息都有基于独有xml的消息层安全性需求，包括数字签名、认证、数据私密性、以及内容产生的威胁保护。这些消息层机制提供了超过和在瞬时应用程序层安全性（例如ssl/tls）之上的保护。实际的ebxml部署利用应用程序层安全性机制和套接层传输机制。
　　
　　ebxml提供的消息层安全性标准依赖于昂贵的xml安全性操作，例如xml签名和xml加密。尽管两种标准都使用了昂贵的加密处理，但是在这些标准中执行xml处理所需的时间远远超过了执行加密操作所需的时间，因为综合xml解析、转换、模式验证和消息标准化的费用昂贵。本文认为通过将xml处理和加密处理分离到一个安全的、加固的xml网关设施中（xml防火墙），可以实现显著的性能提升并具有安全性优势。
　　
　　根据普遍存在的价格经济的和受信的传输层机制（例如ssl/tls或vpn技术）而产生的消息层安全性需求常常使初学者感到困惑。术语消息层安全性是指稳定的安全特性，它适用于任何类型的基于协议的消息交换，不管是通过http、smtp、ftp或是其他协议。
　　
　　在消息层安全性的情况中，无论消息单位是xml文件还是二进制附件，它都是经过加密或签名的，或者既经过加密又包含签名的。对于xml文档来说，由于xml的结构化特性，具体的操作可能具有高度的颗粒性。
　　
　　将消息层安全性应用于有效负荷可以解决传输层机制不能很好处理的安全性问题，例如安全特性的持久性。举例来说，在ssl连接中，安全特性应用于套接字，并且任何写入或者从套接字中读出的数据都是经过加密和验证的。但是，如果将套接字拆开，那么就没有办法辨别来自套接字的部分数据是否应用了安全特性。此外，在多次反射通道的情况中，数据在已经中止ssl连接的任何地方都是清楚地。这种情况称做ssl安全性“鸿沟”，如图1所示：
　　　
　　图1：ssl安全性鸿沟
　　
　　消息层安全性机制在ebxml和其他基于xml的web服务协议中使用广泛。他们帮助为长时间运行的事务或者以多次反射方式涵盖多种域的事务提供持久性认证、数据加密和发送方验证。消息层安全性的用途包括剩余数据保护，即数据经过签名和加密之后再插入到数据库中。
　　
　　cpp安全策略
　　
　　为了理解cpp如何描述安全策略，有必要首先检查cpp实例的外部结构。一个cpp实例由五个直接子元素定义，如清单1所示。元素的基数用一个简单的bnf语法描述。加（+）号表示一个或多个，问号（？）表示0或1，星号（*）表示0个或多个，没有符号则表示只能是1个。
　　
　　清单1：协作协议轮廓（cpp）xml结构
　　
　　<collaborationprotocolprofile>
　　(<partyinfo>)　+
　　(<simplepart>) +
　　(<packaging>)　+
　　(<signature>)　?
　　(<comment>)　　*
　　</collaborationprotocolprofile>　　不需要考虑清单1中的全部元素。有关ebms消息层安全性的大部分安全策略信息位于<partyinfo>元素和<packaging>元素之中。读者可能注意到清单1的例子中有一个<signature>元素。这是一个可选的w3c xml signature，cpp的创建者可以提供它用于验证机制。对cpp来说，通常只有一个签名者，但是cpa如果进行派生则可能有其他签名者。就验证这个目的而言，ebms对cpp自身和实际的交换信息都利用了xml signature，认识到这一点很重要。接下来两段将叙述<partyinfo>元素和<packaging>元素中所内嵌的策略信息。
　　
　　<partyinfo>元素
　　
　　<partyinfo>元素描述了适用于特定贸易合作伙伴的实现细节。一个cpp可以拥有多个<partyinfo>元素，因为大型企业可能需要从多个方面以不同的角色和业务来进行描述。<partyinfo>元素的结构如清单2所示。
　　
　　清单2 <partyinfo>的结构。
　　
　　<partyinfo>
　　(<partyid>)　+
　　(<partyref>) +
　　(<collaborationrole>) +
　　(<certificate>) +
　　(<securitydetails>) +
　　(<deliverychannel>) +
　　(<transport>) +
　　(<docexchange>) +
　　(<overridemshactionbinding>) *
　　</partyinfo>　　 用来描绘ebxml事务的安全策略的三个重要子元素是：<certificate>元素、<collaborationrole>元素和<docexchange>元素。目前，<securitydetails>元素被用作一个扩展点，不传递直接策略。<certificate>元素是cpp的中心内容，它是一个包含ebxml事务所用的公钥的x.509认证清单。这种结构很普通，可以在 cpp 里的其他地方引用。<collaborationrole>元素带有子元素，用于描述原有消息层之外的安全策略项。它可以映射为特定的pki实现，用于ebxml会话中非透明的（例如：非xml的）有效载荷。
　　
　　最后，<docexchange>元素为实际运行时ebxml安全策略奠定基础。这个元素包含了对发送者和接收者的安全策略都很重要的信息。特别值得注意的是，它定义了三个重要的子元素：<sendernonrepudiation>、<senderdigitalenvelope>和<namespacesupported>。清单3直观地展示了这些内容的层次。
　　
　　清单3 <docexchange>层次结构
　　
　　<partyinfo>
　　<docexchange>
　　<ebxmlsenderbinding>
　　<sendernonrepudiation>
　　<senderdigitalenvelope>
　　<namespacesupported>
　　<sendernonrepudiation>元素定义了计算xml签名时要用到的参数，其中包括协议（协议通常就是w3c xml签名）、用来排列摘要信息的哈希函数（如sha-1）、具体的签名算法（如rsa或dsa）、以及一个指向签名所用的x.509证书的引用。以这里，引用可以指向<certificate>，<partyinfo>元素的一个直接子元素。
　　
　　<senderdigitalenvelope>参考所使用的加密机制。术语数字信封（digital envelope）源于消息层安全性事实，如ebxml里所用，一般来讲，使用快速的对称密钥（symmetric key）来加密有效载荷，然后依靠接收者的公钥来加密对称密钥，这样更有效率。从这个意义上来讲，原始对称密钥就是被另一个密钥给封住了。对于ebxml，数字信封的推荐机制是xml加密，但也可以被使用二进制机制如s/mime和pgp/mime。<senderdigitalenvelope>元素指定了协议类型、版本以及所用的加密算法。
　　
　　最后一个元素，<namespacesupported>，可以用来消除xml安全规范的不同版本之间的歧义，如xml签名和saml。<namespacesupported>元素的作用是直接指定相应安全规范的名称空间（因而也指定了版本）。清单4给出了<sendernonrepudiation>元素和<senderdigitalenvelope>元素的一个例子。
　　
　　清单4 安全策略元素示例
　　
　　<sendernonrepudiation>
　　<nonrepudiationprotocol>
　　http://www.w3.org/2000/09/xmldsig#
　　</nonrepudiationprotocol>
　　
　　<hashfunction>
　　http://www.w3.org/2000/09/xmldsig#sha1
　　</hashfunction>
　　
　　<signaturealgorithm>
　　http://www.w3.org/2000/09/xmldsig#dsa-sha1
　　</signaturealgorithm>
　　
　　<signingcertificateref certid="companya_signingcert"/>
　　</sendernonrepudiation>
　　
　　<senderdigitalenvelope>
　　<digitalenvelopeprotocol version="2.0">
　　s/mime
　　</digitalenvelopeprotocol>
　　
　　<encryptionalgorithm>
　　des-cbc
　　</encryptionalgorithm>
　　<senderdigitalenvelope>
　　在清单4中的例子中,发送者支持消息层鉴权的xml签名,使用dsa算法和sha-1哈希函数进行。对于数据私密性，则使用s/mime v2.0机制,带有56位cbc模式的des键。
　　
　　在这时看来，好像消息层安全机制所有必需信息都已经被指明了，但还有个问题，那就是如何把这些操作应用到ebms消息。ebms规范使用了一个含有几个组成部分的mime信封。驱动程序包括一些场景，在其中ebms消息的各个部分被加密或签名。这正是<packaging>元素的工作。<packaging>元素描述了需要被签名或被加密的ebms消息部件，以及无需加密的应该留给别人去修改、更新或改变的部件。
　　
　　<packaging>元素
　　
　　<packaging>元素描述了ebms消息的哪些部分要签名和加密，哪些部分不需要。
　　
　　查看<packaging>元素是如何工作的。首先请查看ebms消息的消息结构，它是根据带附件的soap协议(swa)定义的。swa的结构则是根据一套名为soap消息包的mime包来定义的。每条swa消息都是一个消息包的集合，主要soap有效载荷位于第一个mime容器里。图2直观地展示了ebms消息与应用层之间其他部分的关系。
　　　
　　图2 ebms消