ETSI TS 102 640-6-3-2011 Electronic Signatures and Infrastructures (ESI) Registered Electronic Mail (REM) Part 6 Interoperability Profiles Sub-part 3 REM-MD SOAP Binding Profile (V_1.pdf

1、 ETSI TS 102 640-6-3 V1.1.1 (2011-09) Electronic Signatures and Infrastructures (ESI); Registered Electronic Mail (REM); Part 6: Interoperability Profiles; Sub-part 3: REM-MD SOAP Binding Profile Technical Specification ETSI ETSI TS 102 640-6-3 V1.1.1 (2011-09) 2Reference DTS/ESI-000069-1 Keywords e

2、-commerce, electronic signature, email, security, trust services ETSI 650 Route des Lucioles F-06921 Sophia Antipolis Cedex - FRANCE Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16 Siret N 348 623 562 00017 - NAF 742 C Association but non lucratif enregistre la Sous-Prfecture de Grasse (06) N 7803/88

3、 Important notice Individual copies of the present document can be downloaded from: http:/www.etsi.org The present document may be made available in more than one electronic version or in print. In any case of existing or perceived difference in contents between such versions, the reference version

4、is the Portable Document Format (PDF). In case of dispute, the reference shall be the printing on ETSI printers of the PDF version kept on a specific network drive within ETSI Secretariat. Users of the present document should be aware that the document may be subject to revision or change of status.

5、 Information on the current status of this and other ETSI documents is available at http:/portal.etsi.org/tb/status/status.asp If you find errors in the present document, please send your comment to one of the following services: http:/portal.etsi.org/chaircor/ETSI_support.asp Copyright Notification

6、 No part may be reproduced except as authorized by written permission. The copyright and the foregoing restriction extend to reproduction in all media. European Telecommunications Standards Institute 2011. All rights reserved. DECTTM, PLUGTESTSTM, UMTSTMand the ETSI logo are Trade Marks of ETSI regi

7、stered for the benefit of its Members. 3GPPTM and LTE are Trade Marks of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners. GSM and the GSM logo are Trade Marks registered and owned by the GSM Association. ETSI ETSI TS 102 640-6-3 V1.1.1 (2011-09) 3Contents Intel

8、lectual Property Rights 5g3Foreword . 5g3Introduction 5g31 Scope 6g32 References 7g32.1 Normative references . 7g32.2 Informative references 8g33 Definitions and abbreviations . 9g33.1 Definitions 9g33.2 Abbreviations . 9g34 XML-based REM-MD Envelope Structure Implementation . 9g34.1 REM Dispatch 10

9、g34.2 REM-MD Message. 10g35 Message Transport between REM-MD using SOAP . 11g35.1 SOAP Version and Binding 11g35.2 SOAP Header . 11g35.2.1 Addressing 11g35.2.2 WS Security header 12g35.2.3 Use of WS-ReliableMessaging . 12g35.3 SOAP Body Format 12g35.4 SOAP Fault Binding . 12g35.4.1 General processin

10、g error . 13g36 REM Web Service Specification 13g36.1 AcceptREMDispatchOperation 13g36.2 AcceptREMMDMessageOperation 14g3Annex A (normative): Specifications for XML-based REM-MD Envelope . 15g3A.1 Namespace for the elements specified in the present document 15g3A.2 Element details . 15g3A.2.1 Elemen

11、t 16g3A.2.1.1 Element . 16g3A.2.1.2 Element . 17g3A.2.1.3 Element 17g3A.2.1.4 Element . 18g3A.2.2 Element . 18g3A.2.3 Element . 19g3A.2.3.1 Element 19g3A.2.3.1.1 Element . 19g3A.2.3.1.2 Element 19g3A.2.3.1.3 Element 20g3A.2.3.2 Element 20g3A.2.3.3 Element 20g3A.2.3.4 Element 20g3A.2.4 Element . 21g3

12、A.2.5 Element 22g3A.3 Element details . 22g3Annex B (normative): WS Addressing specification . 23g3B.1 Element . 23g3ETSI ETSI TS 102 640-6-3 V1.1.1 (2011-09) 4B.2 Element 23g3B.3 Element . 23g3B.4 Element 24g3B.5 Element 24g3Annex C (normative): Web Service specification 25g3C.1 AcceptREMDispatchOp

13、eration Element 25g3C.2 AcceptREMMDMessageOperation Element . 25g3C.3 REM MD SOAP Service WSDL template . 25g3Annex D (informative): Bibliography . 28g3History 30g3ETSI ETSI TS 102 640-6-3 V1.1.1 (2011-09) 5Intellectual Property Rights IPRs essential or potentially essential to the present document

14、may have been declared to ETSI. The information pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found in ETSI SR 000 314: “Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in respect of ETSI

15、 standards“, which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web server (http:/ipr.etsi.org). Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee can be given as to the existence of other IPRs no

16、t referenced in ETSI SR 000 314 (or the updates on the ETSI Web server) which are, or may be, or may become, essential to the present document. Foreword This Technical Specification (TS) has been produced by ETSI Technical Committee Electronic Signatures and Infrastructures (ESI). The present docume

17、nt is part 6, sub-part 3 of a multi-part deliverable. Full details of the entire series can be found in part 1 1. Introduction The summarised scope of each part and sub-part can be found in part 1 1 of this multi-part deliverable. ETSI ETSI TS 102 640-6-3 V1.1.1 (2011-09) 61 Scope The purpose of the

18、 present document is to define specifications on how to carry REM Dispatches and REM-MD Messages between REM-MDs as XML Information Set as defined by the SOAP specification: “for exchanging structured and typed information between peers in a decentralized, distributed environment“ (SOAP Version 1.2,

19、 Part 0: Primer), commonly called “Web Services“. The present document comes as a completion of the current specifications (TS 102 640, especially parts 2 2 and 5 5), which defines S/MIME envelopes as message format to be transported over SMTP protocol. REM over SOAP will prove useful in several con

20、texts, due to the fact that Web Services are largely considered a well established and flexible technology, providing detailed specifications for the different functional building blocks (addressing, security and trust, reliable delivery). Building blocks are combinable and open for extension/profil

21、ing according to the needs of specific application- and communication scenarios. Several initiatives are ongoing pointing in this direction: we remark European projects SPOCS and STORK, which aim at bridging existing eDelivery systems in several European MSs. The necessity to have them all interchan

22、ge trusted messages requires the involvement of “eDelivery Gateways“ based on a “eDelivery meta-protocol“, in order to avoid a non-scalable one-to-one bridging. Requirements for the meta-protocol normally involve the usage of a Web Services based transport (see e.g. STORK D6.4.1 i.2, SPOCS D3.2 i.1)

23、. REM specifications as defined in TS 102 640 would be a natural candidate for the above meta-protocol role, once a proper binding to SOAP is defined. Unlike the protocol stack defined for e-mail, standard Web Service specifications define no general message format to structure the content of more o

24、r less “unbounded“ asynchronous exchange of messages and electronic documents: the SOAP body normally is seen as an opaque object, whose structure and semantics are agreed upon a specific Web Service provider and their respective consumers. Most of mentioned eDelivery solutions based on SOAP/Web Ser

25、vices define their domestic format for such general communication scenarios. To be able to provide interoperable message exchange functionality between such solutions as well as the SMTP/(S)MIME based world, the present document for REM/SOAP binding includes the definition of an XML-based exchange f

26、ormat for message contents, which may be used for mapping between different domestic and/or standardized message structures. A further challenge of bridging the SMTP- and Web Services solutions is having to deal with different schemes of electronic addresses of end-entities (e.g. e-mail addresses as

27、 defined by RFC 5322 11, URLs of http-resources, constructs following ISO/IEC 15459-3 25 for unique identifier schemes). To this purpose, the definition of electronic addresses in REM has been extended to take into account the “addressing schema“. To meet the expectations above, the present document

28、 provides: a) Rules for building a REM-MD Envelope (and, consequently, a REM Dispatch or a REM-MD Message) as well defined XML Information Sets (Infoset). b) Rules for secure transport of the above REM-MD XML Infosets using SOAP, combined with appropriate bricks of the Web Services stack (profiling

29、of WS-Addressing and WS-Security). REM-MD Evidence formats respect TS 102 640-2 2 specifications in xml flavour. The structure of the present document is as follows: Clause 2 contains the list of normative and informative references. Clause 3 includes definitions of the relevant concepts to the pres

30、ent document and abbreviations. Clause 4 contains the specification of REM-MD XML Infosets to be used for enveloping messages. Specific syntax is addressed by annex A. Clause 5 contains the specification of the SOAP messages as exchanged between REM-MDs, which covers the profiling of the standard WS

31、-bricks used. Profiling details are addressed by annex B. Clause 6 deals with the definition of Web Services for interoperability. Annex A provides XML Schema for REM XML Infosets as used inside SOAP messages. Annex B provides a profiling for WS Addressing inside SOAP header. ETSI ETSI TS 102 640-6-

32、3 V1.1.1 (2011-09) 7 Annex C provides WSDL specification, defining the REM-MD Web Service endpoint. 2 References References are either specific (identified by date of publication and/or edition number or version number) or non-specific. For specific references, only the cited version applies. For no

33、n-specific references, the latest version of the reference document (including any amendments) applies. Referenced documents which are not found to be publicly available in the expected location might be found at http:/docbox.etsi.org/Reference. NOTE: While any hyperlinks included in this clause wer

34、e valid at the time of publication ETSI cannot guarantee their long term validity. 2.1 Normative references The following referenced documents are necessary for the application of the present document. 1 ETSI TS 102 640-1: “Electronic Signatures and Infrastructures (ESI); Registered Electronic Mail

35、(REM); Part 1: Architecture“. 2 ETSI TS 102 640-2: “Electronic Signatures and Infrastructures (ESI); Registered Electronic Mail (REM); Part 2: Data requirements, Formats and Signatures for REM“. 3 ETSI TS 102 640-3: “Electronic Signatures and Infrastructures (ESI); Registered Electronic Mail (REM);

36、Part 3: Information Security Policy Requirements for REM Management Domains“. 4 ETSI TS 102 640-4: “Electronic Signatures and Infrastructures (ESI); Registered Electronic Mail (REM); Part 4: REM-MD Conformance Profiles“. 5 ETSI TS 102 640-5: “Electronic Signatures and Infrastructures (ESI); Register

37、ed Electronic Mail (REM); Part 5: REM-MD Interoperability Profiles“. 6 IETF RFC 2616: “Hypertext Transfer Protocol - HTTP/1.1“. NOTE: Available at http:/www.rfc-editor.org/rfc/rfc2616.txt. 7 IETF RFC 2817: “Upgrading to TLS Within HTTP/1.1“. NOTE: Available at http:/tools.ietf.org/html/rfc2817. 8 IE

38、TF RFC 3061 (2001): “A URN Namespace of Object Identifiers“. 9 IETF RFC 3986: “Uniform Resource Identifier (URI): Generic Syntax“. 10 IETF RFC 4122 (2005): “A Universally Unique Identifier (UUID) URN Namespace“. NOTE: Available at http:/www.ietf.org/rfc/rfc4122.txt. 11 IETF RFC 5322: “Internet Messa

39、ge Format“. NOTE: Available at http:/tools.ietf.org/html/rfc5322. 12 OASIS Standard Specification: “OASIS Web Services Security (WSS) TC“. NOTE: Available at http:/www.oasis-open.org/specs/index.php#wssv1.1. 13 OASIS Standard Specification: “Web Services Reliable Messaging (WS-ReliableMessaging) Ver

40、sion 1.2“, 2 February 2009. NOTE: Available at http:/docs.oasis-open.org/ws-rx/wsrm/v1.2/wsrm.pdf. ETSI ETSI TS 102 640-6-3 V1.1.1 (2011-09) 814 OASIS Standard Specification: “Web Services Reliable Messaging Policy Assertion (WS-RM Policy) Version 1.1“, 7 January 2008. NOTE: Available at http:/docs.

41、oasis-open.org/ws-rx/wsrmp/v1.1/wsrmp.pdf. 15 W3C Recommendation: “SOAP Message Transmission Optimization Mechanism“ 25 January 2005. NOTE: Available at http:/www.w3.org/TR/soap12-mtom/. 16 W3C Recommendation: “SOAP Version 1.2 Part 1: Messaging Framework (Second Edition)“ 27 April 2007. NOTE: Avail

42、able at http:/www.w3.org/TR/soap12-part1/. 17 W3C Recommendation: “Web Services Addressing 1.0 - SOAP Binding“ 9 May 2006. NOTE: Available at http:/www.w3.org/TR/2006/REC-ws-addr-soap-20060509/. 18 W3C Note: “Web Services Description Language (WSDL) 1.1“ 15 March 2001. NOTE: Available at http:/www.w

43、3.org/TR/wsdl/. 19 W3C Recommendation: “Web Services Policy 1.5 - Framework“ 04 September 2007. NOTE: Available at http:/www.w3.org/TR/ws-policy/. 20 W3C Working Draft: “MTOM Serialization Policy Assertion 1.1“ 18 September 2007. NOTE: Available at http:/www.w3.org/TR/soap12-mtom-policy/. 21 Web Ser

44、vices Interoperability Organization Working Group Draft WS-I: “Basic Profile 2.0“ 2007-10-25. NOTE: Available at http:/www.ws-i.org/Profiles/BasicProfile-2_0(WGD).html. 22 ISO 3166-1 (2006): “Codes for the representation of names of countries and their subdivisions - Part 1: Country codes“. NOTE: Up

45、dates available at http:/www.iso.org/iso/country_codes/updates_on_iso_3166.htm. 23 ETSI TS 102 640-6-1: “Electronic Signatures and Infrastructures (ESI); Registered Electronic Mail (REM); Part 6: Interoperability Profiles; Sub-part 1: REM-MD UPU PReM Interoperability Profile“. 24 ETSI TS 102 640-6-2

46、: “Electronic Signatures and Infrastructures (ESI); Registered Electronic Mail (REM); Part 6: Interoperability Profiles; Sub-part 2: REM-MD BUSDOX Interoperability Profile“. 25 ISO/IEC 15459-3:2006: “Information technology - Unique identifiers - Part 3: Common rules for unique identifiers“. 2.2 Info

47、rmative references The following referenced documents are not necessary for the application of the present document but they assist the user with regard to a particular subject area. i.1 SPOCS D3.2 Functional Specification, Architecture and Trust Model. In particular Appendix 3: eDelivery Interconne

48、ct Protocol and Gateway Specification. NOTE: Available at http:/www.eu-spocs.eu/index.php?option=com_processes both objects are defined in annex A. The request (REM Dispatch) contains the original message (possibly in addition to normalized form) plus REM-MD Evidence objects (in the normal case a Su

49、bmissionAcceptanceRejection evidence is expected - this is for the recipient to have a proof of the message submission by the sender). The backchannel response will normally contain a RelayToREMMDAcceptanceRejection evidence - this is for the senders REM-MD to have a proof of the take in charge by the recipients REM-MD. ETSI ETSI TS 102 640-6-3 V1.1.1 (2011-09) 14Therefore, to send a Dispatch to a user on a different REM-MD, the senders REM-MD shall call the