ETSI TR 103 071-2011 Electronic Signatures and Infrastructures (ESI) Registered Electronic Mail (REM) Test suite for future REM interoperability test events (V1 1 1)《电子签名和基础结构(ESI)_1.pdf

1、 ETSI TR 103 071 V1.1.1 (2011-09) Electronic Signatures and Infrastructures (ESI); Registered Electronic Mail (REM); Test suite for future REM interoperability test events Technical Report ETSI ETSI TR 103 071 V1.1.1 (2011-09) 2Reference DTR/ESI-000070 Keywords email, interoperability, testing, trus

2、t 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 Important notice Individual copies of the present doc

3、ument 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 is the Portable Document Format (PDF). In case of disp

4、ute, 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. Information on the current status of this and other E

5、TSI 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 No part may be reproduced except as authorized by wri

6、tten 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 registered for the benefit of its Members. 3GPPTM and LTE

7、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 TR 103 071 V1.1.1 (2011-09) 3Contents Intellectual Property Rights 4g3Foreword . 4g31 Scope 5g32 Refe

8、rences 6g32.1 Normative references . 6g32.2 Informative references 6g33 Abbreviations . 6g34 Testing Evidence Formats 6g34.1 Testing senderAuthenticationDetails component . 8g34.2 Testing recipientAuthenticationDetails component . 8g34.3 Testing SubmissionAcceptanceRejection evidence 9g34.4 Testing

9、RelayREMMDAcceptanceRejection evidence 10g34.5 Testing RelayREMMFailure evidence . 11g34.6 Testing DeliveryNonDeliveryToRecipient evidence 12g34.7 Testing DownloadNonDownloadByRecipient evidence 14g34.8 Testing RetrievalNonRetrievalByRecipient evidence 16g34.9 Testing AcceptanceRejectionByRecipient

10、evidence 17g34.10 Testing RelayToNonREMSystem evidence . 18g34.11 Testing ReceivedFromNonREMSystem evidence . 18g35 Testing REM-MD Envelope Formats 19g35.1 REM-MDs using S/MIME on SMTP . 19g35.1.1 Testing REM-MD Envelope with REM-MD Introduction section . 21g35.1.2 Testing REM-MD Envelope with REM-M

11、D Evidence 21g35.1.3 Testing REM-MD Envelope with Original Message 23g35.1.4 Testing REM-MD Envelope with parts of different types 23g35.1.4.1 Testing REM-MD Envelope with Original Message and Evidence sections 23g35.1.4.2 Testing REM-MD Envelope with Introduction and Evidence sections 24g35.2 REM-M

12、Ds using SOAP on HTTP . 25g35.2.1 Testing without Evidence list 26g35.2.2 Testing with Evidence list . 28g35.2.3 Testing with Evidence list 28g36 Testing REM-MD Signatures . 29g36.1 Testing REM-MD Signatures on individual REM-MD Evidence 30g36.2 Testing REM-MD S/MIME Signatures 30g36.3 Testing XAdES

13、 signatures on SOAP based REM-MD Envelope 31g37 Testing REM Objects flows . 33g37.1 Testing intra REM-MD REM Objects flows 35g37.1.1 Testing Store and Forward Mode of Operation 35g37.1.1.1 Testing flows with mandatory set of evidence 36g37.1.1.2 Testing flows with mandatory and optional sets of evid

14、ence 42g37.1.2 Testing Store and Notify Mode of Operation . 45g37.1.2.1 Testing flows with mandatory set of evidence 45g37.1.2.2 Testing flows with mandatory and optional sets of evidence 51g37.2 Testing Object flows between REM-MD and Non REM System 53g37.3 Testing cross REM-MD REM Objects flows .

15、54g37.3.1 Senders and Recipients REM-MDs under Store and Forward Mode of Operation . 56g37.3.2 Recipients REM-MD under Store and Notify Mode of Operation 64g37.3.3 Senders REM-MD under Store and Notify Mode of Operation . 74g36 Test Suite for REM-MD UPU PReM Interoperability Profile . 84g36.1 Test c

16、ases for scenario where sender is subscribed to REM-MD . 84g36.2 Test cases for scenario where sender is subscribed to a UPU DO 89g3History 93 ETSI ETSI TR 103 071 V1.1.1 (2011-09) 4Intellectual Property Rights IPRs essential or potentially essential to the present document may have been declared to

17、 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 standards“, which is ava

18、ilable 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 not referenced in ETSI SR 0

19、00 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 Report (TR) has been produced by ETSI Technical Committee Electronic Signatures and Infrastructures (ESI). ETSI ETSI TR 103 071 V1.1.1 (2011-09) 51 Scope The

20、 present document defines a number of test suites for supporting interoperability tests within the field of Registered Electronic Mail as specified in TS 102 640 parts 1 to 6 i.1, i.2, i.3, i.4, i.5 and i.6. A layering approach has been adopted for defining the test suite as described below: First a

21、 number of tests cases on evidences are defined so that entities testing interoperability may concentrate in identifying potential problems caused only by evidences. These tests do not depend on the type of format and transport binding expected (i.e. they are common to REM-MDs using S/MIME on SMTP a

22、nd to REM-MDs using SOAP on HTTP). Secondly, a number of tests cases have been defined for testing interoperability regarding the REM-MD Envelope format and contents. Some of these test cases (specifically those that include an evidence set within the REM-MD Envelope), are built on already defined t

23、est cases on individual evidence. It has to be mentioned that two sets of test cases are defined at this layer: one for REM-MDs using S/MIME on SMTP as specified in TS 102 640-2 i.2, and another for REM-MDs that use SOAP on HTTP binding as specified in TS 102 640 SOAP binding profile. Finally, a num

24、ber of tests cases have been defined on complete flows of REM Objects so that entities testing interoperability may check several complete flows, including successful and unsuccessful by (well defined reasons) cycles. For each of the three layers, both positive and negative test cases have been defi

25、ned. The present document defines interoperability tests for covering the following scenarios: 1) Scenarios where both sender and recipient are subscribed to the same REM-MD, be it operating under Store and Forward or Store and Notify mode of operation, and be it using S/MIME on SMTP or SOAP on HTTP

26、. 2) Scenarios where sender and recipient are subscribed to a different REM-MD. This set assumes that both REM-MD use the same format and transport mechanisms (i.e. both use S/MIME on SMTP or SOAP on HTTP). As for the style of operation, this set includes test cases for scenarios where both REM-MDs

27、operate under Store and Forward; test cases for scenarios where the senders REM-MD operates under Store and Notify; and test cases for scenarios where the recipients REM-MD operates under Store and Notify. 3) Scenarios where sender and recipient are subscribed one to a REM-MD as specified in TS 102

28、640 i.1 to i.6 and the other is subscribed to a UPUs Designated Operator. This set includes test cases for the REM-MD/UPU gateway as specified in TS 102 640 i.1 to i.6 REM-MD UPU Interoperability Profile. Readers of the present document are entirely free to select the subset of test cases that best

29、suits their purposes and their convenience. In no way they should infer that they are required to test all the test cases specified in the present document. Additionally, readers of the present document are noticed that for the test cases on complete flows of REM objects, certain decisions were made

30、 on the inclusion or not of certain objects within one REM-MD Envelope, as the TS 102 640 i.1 to i.6 does provide certain degree of freedom for doing that. They should, in consequence, feel free to alter the definitions of the test cases as best suits their purposes and their convenience as long as

31、these changes do not lead to situations that are not compliant with the TS 102 640 specifications i.1 to i.6. Clause 4 of the present document defines test cases on all the different types of evidence specified in TS 102 640-2 i.2. Clause 5 defines the test cases for testing REM-MD envelope formats

32、and contents. Two sets of test cases are defined: one for entities using S/MIME on SMTP (clause 5.1) and other for entities using SOAP on HTTP (clause 5.2). Clause 6 defines test cases for testing signatures generated by REM-MD. Clause 7 defines test cases for testing complete flows of REM objects.

33、Clause 8 defines test cases for testing seamless exchange of messages and evidence between subscribers of REM-MDs and subscribers of UPUs Designated Operator (DO henceforth). ETSI ETSI TR 103 071 V1.1.1 (2011-09) 62 References References are either specific (identified by date of publication and/or

34、edition number or version number) or non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the referenced document (including any amendments) applies. Referenced documents which are not found to be publicly available in the expected

35、 location might be found at http:/docbox.etsi.org/Reference. NOTE: While any hyperlinks included in this clause were 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 p

36、resent document. Not applicable. 2.2 Informative 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 ETSI TS 102 640-1: “Electronic Signatures and Infrastructures (ESI); Reg

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

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

39、 Infrastructures (ESI); Registered Electronic Mail (REM); Part 5: REM-MD Interoperability Profiles“. i.6 ETSI TS 102 640-6: “Electronic Signatures and Infrastructures (ESI); Registered Electronic Mail (REM); Part 6: Interoperability Profiles“. 3 Abbreviations For the purposes of the present document

40、, the following abbreviations apply: DO Designated Operator QES Qualified Electronic Signature REM-MD Registered Electronic Mail Management Domain SAML Security Assertion Markup Language SMTP Simple Mail Transfer Protocol 4 Testing Evidence Formats The present clause specifies a number of tests on e

41、vidence formats. Each sub-clause clearly indicates what specific aspects of the evidence format are tested. ETSI ETSI TR 103 071 V1.1.1 (2011-09) 7Evidence, as specified in TS 102 640-2 i.2, include mandatory components, optional components that the issuer REM-MD may decide to include or not and con

42、ditional components that the issuer REM-MD includes or not depending on certain conditions. The test suite is specified using a tabular form. Each row of the tables specifies one test case. For each test case, the table incorporates mechanisms for indicating: 1) Those optional and/or conditional ele

43、ments that are present or absent (mandatory elements will be present anyway). This is done including one column per each optional/conditional component in the evidence. 2) This is done including one column per each optional/conditional component in the evidence. 3) Additional remarks on optional/con

44、ditional elements that are present. 4) Additional remarks on mandatory elements. Conditional and/or optional elements that are not mentioned in the tables, are absent for the all the test cases specified in the table. The following acronyms for the conditional/optional components are used in the tab

45、les: evR: eventReasons. evIsPolID: evidenceIssuerPolicyID senAuthDet: senderAuthenticationDetails recAuthDet: recipientAuthenticationDetails recDelDet: recipientsDelegateDetails TrLog: TransactionLogInformation Ext: Extensions Sig: Signature NotTag: Notification tag Below follows an example of a tab

46、le providing details on eventReason, evidenceIssuerPolicyId, senderAuthentication and replyTo. Other optional/conditional components are absent of the evidence. Table 1: Example of table for specifying test cases on Evidence formats Test identifier Trigger Event evR evIsPolID senAuthDet Purpose of t

47、est case Column Test identifier indicates the identifier code for the test case specified in the row. The test identifiers for all these tests will follow the following pattern: EVF-EvidenceTypeAcronym-number, where EVF stands for “Evidence Format“. Column Trigger Event indicates what event has trig

48、gered the issuance of the evidence whose format is tested. Columns evR, evIsPolID, senAuthDet include indications of presence/absence of the component indicated by the header. If the component is absent, the cell will be empty. If the component is present in the test case and no additional remarks a

49、re required, the cell will contain the symbol checkbld. If the component is present in the test case and some additional remarks are required, the cell will contain a number referencing additional remarks that appear numbered below the table. Column Purpose of test case provides details on the main purpose for defining the corresponding test case. ETSI ETSI TR 103 071 V1.1.1 (2011-09) 84.1 Testing senderAuthenticationDetails component The present clause specifies test cases for testing inclusion