Transglobal Secure Collaboration Program Secure v.1 Technical Specification. Prepared by: TSCP Secure v.

Transcription

1 Transglobal Secure Collaboration Program Secure v.1 Technical Specification Prepared by: TSCP Secure v.1 Project Team Version: Date: 07/16/2012

2 TSCP Secure v.1 Technical Specification Page i

3 Copyright 2012 Transglobal Secure Collaboration Participation, Inc. All rights reserved. Terms and Conditions Transglobal Secure Collaboration Participation, Inc. (TSCP) is a consortium comprising a number of commercial and government members (as further specified at (each a TSCP Member ). This specification was developed and is being released under this open source license by TSCP. Use of this specification is subject to the disclaimers and limitations described below. By using this specification you (the user) agree to and accept the following terms and conditions: 1. This specification may not be modified in any way. In particular, no rights are granted to alter, transform, create derivative works from, or otherwise modify this specification. Redistribution and use of this specification, without modification, is permitted provided that the following conditions are met: Redistributions of this specification must retain the above copyright notice, this list of conditions, and all terms and conditions contained herein. Redistributions in conjunction with any product or service must reproduce the above copyright notice, this list of conditions, and all terms and conditions contained herein in the documentation and/or other materials provided with the distribution of the product or service. TSCP s name may not be used to endorse or promote products or services derived from this specification without specific prior written permission. 2. The use of technology described in or implemented in accordance with this specification may be subject to regulatory controls under the laws and regulations of various jurisdictions. The user bears sole responsibility for the compliance of its products and/or services with any such laws and regulations and for obtaining any and all required authorizations, permits, or licenses for its products and/or services as a result of such laws or regulations. 3. THIS SPECIFICATION IS PROVIDED AS IS AND WITHOUT WARRANTY OF ANY KIND. TSCP AND EACH TSCP MEMBER DISCLAIMS ALL EPRESS, IMPLIED AND STATUTORY WARRANTIES, INCLUDING, WITHOUT LIMITATION, ANY IMPLIED WARRANTIES OF TITLE, NONINFRINGEMENT, MERCHANTABILITY, QUIET ENJOYMENT, ACCURACY, AND FITNESS FOR A PARTICULAR PURPOSE. NEITHER TSCP NOR ANY TSCP MEMBER WARRANTS (A) THAT THIS SPECIFICATION IS COMPLETE OR WITHOUT ERRORS, (B) THE SUITABILITY FOR USE IN ANY JURISDICTION OF ANY PRODUCT OR SERVICE WHOSE DESIGN IS BASED IN WHOLE OR IN PART ON THIS SPECIFICATION, OR (C) THE SUITABILITY OF ANY PRODUCT OR A SERVICE FOR CERTIFICATION UNDER ANY CERTIFICATION PROGRAM OF TSCP OR ANY THIRD PARTY. 4. IN NO EVENT SHALL TSCP OR ANY TSCP MEMBER BE LIABLE TO YOU OR ANY THIRD PARTY FOR ANY CLAIM ARISING FROM OR RELATING TO THE USE OF THIS SPECIFICATION, INCLUDING, WITHOUT LIMITATION, A CLAIM THAT SUCH USE INFRINGES A THIRD PARTY S INTELLECTUAL PROPERTY RIGHTS OR THAT IT FAILS TO COMPLY WITH APPLICABLE LAWS OR REGULATIONS. BY USE OF THIS SPECIFICATION, THE USER WAIVES ANY SUCH CLAIM AGAINST TSCP OR ANY TSCP MEMBER RELATING TO THE USE OF THIS SPECIFICATION. IN NO EVENT SHALL TSCP OR ANY TSCP MEMBER BE LIABLE FOR ANY DIRECT OR INDIRECT DAMAGES OF ANY KIND, INCLUDING CONSEQUENTIAL, INCIDENTAL, SPECIAL, PUNITIVE, OR OTHER DAMAGES WHATSOEVER ARISING OUT OF OR RELATED TO ANY USER OF THIS SPECIFICATION, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. 5. TSCP reserves the right to modify or amend this specification at any time, with or without notice to the user, and in its sole discretion. The user is solely responsible for determining whether this specification has been superseded by a later version or a different specification. 6. These terms and conditions will be interpreted and governed by the laws of the State of Delaware without regard to its conflict of laws and rules. Any party asserting any claims related to this specification irrevocably consents to the personal jurisdiction of the U.S. District Court for the District of Delaware and to any state court located in such district of the State of Delaware and waives any objections to the venue of such court. TSCP Secure v.1 Technical Specification Page ii

4 Table of Contents 1 Introduction and Purpose Feedback TSCP Document Structure Supporting Documents Secure Scope and Requirements TSCP Secure V.1 Scope Secure Business Requirements Business Scenario Secure Design Functions Introduction to High Level Architecture Key Components of the Secure Solution Secure Information Flows Secure Actors Secure Solution Elements Secure Technical Solution The Characteristics of the IT Environment Requirements for Actors and Vendors External Specification Secure Implementation Overall Solution Element Implementation Constraints Certificate Authorities PKI Repositories End-User Certificate Repository Service (EUCRS) Certificate Lookup Services Secure Gateways TSCP Secure v.1 Components Client Appendix A TSCP Secure v.1 Technical Specification Page 3

5 Index of Figures Figure 1. Business Scenario... 7 Figure 2. High-Level Architecture of TSCP Secure v Figure 3. Logical Architecture and Solution Elements Figure 4. Concept of Operation: Certificate Lookup Service Figure 5. End-User Encryption Certificate Lookup: Use Cases Figure 6. Outsource Enterprise Environment with Outbound Border Proxy Index of Tables Table 1. Characteristics of Insource vs. Outsource Enterprises Table 2. Solution Element to Actor Mapping Table 3. Secure v.1 Actor Requirements Table 4. External Specifications Mapping Table Table 5. Overall Functional Constraints Table 6. Certificate Authority Implementation Constraints Table 7. PKI Repository Implementation Constraints Table 8. EUCRS Functional Constraints Table 9. Insourced Enterprise and Outsourced Certificate Lookup Services Table 10. Outbound Border Proxy Functional Constraints Table 11. Overall Gateway Implementation Constraints Table 12. Inspecting Gateway Implementation Constraints Table 13. Secure v.1 Technical Profile Alignment to Business Scenario TSCP Secure v.1 Technical Specification Page 4

6 1 Introduction and Purpose The Internet has changed the way that governments and industries conduct business worldwide, including the use of electronic mail, or , which has become indispensable. Estimates show that daily volume exploded to more than 245 billion in With that increase in Internet and use by virtually every business sector, all have become targets of malicious hacking and what is known as Advanced Persistent Threat (APT), the sophisticated and ongoing Internet-based attacks which includes malware, key-logging, spamming, spoofing and phishing. Within Aerospace and Defense (A&D) sector companies and government organizations, much of the traffic is commercially sensitive or protected by national security or export controls and must be protected against Internet eavesdropping. However, Simple Mail Transfer Protocol (SMTP), the protocol of the Internet, has inherent security weaknesses that make it easy for attackers to intercept, forge (spoof) and modify messages. Mitigation of these risks means assurance that proprietary information is getting to the intended person at the other end, without being intercepted or corrupted. TSCP is addressing those concerns with Secure v.1, which provide the following functions: Sending and Receiving Encrypted - ensures the confidentiality of e- mail content between the sender and the recipient. Sending and Receiving Signed authenticates the identity of the sender and ensures that content arrives in the recipient s mailbox without changes being made to either the text or its attachments while en route. These functions may be combined to enable sending and receiving Signed and Encrypted . Brief animated High Level Functional Overview Demonstrations 2 are available at to introduce the Sending and Receiving Encrypted functionality of two different proprietary clients. 1.1 Feedback TSCP welcomes feedback and comments on this document, which may be sent to the TSCP SEv1 Team via SEv1SEDS@TSCP.org. 1 Studies by Radicati Group: These presentations, each demonstrating a TSCP Secure v.1 function on their respective platform environments, are not intended to endorse, advertise or otherwise promote either platform. Lotus Notes and Microsoft Outlook are registered trademarks of their respective companies. TSCP Secure v.1 Technical Specification Page 1

7 1.2 TSCP The Transglobal Secure Collaboration Program (TSCP) is a cooperative effort by leading A&D companies and various government organizations around the world to develop a framework of standards, specifications, policies, procedures and mechanisms to enable secure international collaboration. TSCP is working to enable a more efficient, effective and secure collaborative environment while mitigating the inherent risks of transmitting data via the Internet. The need for a secure capability for the A&D sector has been firmly established as a key component of this environment. The TSCP framework is usable within the bounds of current multi-jurisdictional export control regimes and applicable national regulations/requirements for collaborative programs. More information about TSCP and its current membership is available at Document Structure This document provides technical specifications, best practices and recommendations for a secure capability to be used by the A&D sector, its customers and its supply chain. The document consists of the following sections: Section 1 - Introduction and Purpose. Section 2 - TSCP Secure v.1 Scope and Requirements: provides an informative description of the scope of TSCP Secure v.1, the business scenarios within that scope, and the business requirements that they address. Section 3 - TSCP Secure v.1 Design: explains the functions supported by TSCP Secure v.1, and defines the high level architecture of the solution. Section 4 - TSCP Secure v.1 Technical Solution: defines the normative 3 elements of the solution. Section 5 - TSCP Secure v.1 Implementation: identifies normative constraints on solution elements for implementation. 3 Normative vs. Informative: In standards terminology, "normative" characterizes that part of a standard that describes actions that shall be performed to achieve compliance, while Informative describes information that is explanatory or provides context rather than action to achieve compliance. TSCP Secure v.1 Technical Specification Page 2

8 1.4 Supporting Documents This specification references additional TSCP and external documents. Each TSCP document is listed below along with a brief description and its associated hyperlink. All TSCP Secure v.1 documents are available for download on External references are listed in Section 4.3 External Specifications. TSCP specifications are available at TSCP Secure v.1 Technical Profile This normative document provides configuration requirements for solution elements and is mandatory for implementing enterprises. It addresses the business requirement to protect information in transit by applying technical constraints and controls to the selected solution elements. TSCP Secure v.1 High Level Design This non-normative document describes the design details of solution elements, high level flows, and an overview of in-source and outsource infrastructures. TSCP Secure v.1 Requirements to Enterprises This document articulates requirements to the enterprises that are using the TSCP Secure v.1 capability. TSCP Secure v.1 Requirements to Services Providers This document defines solution element requirements for Service Providers who may provide diverse services to Outsource Enterprises using TSCP Secure V.1. TSCP Secure v.1 Requirements to Community Service Providers This document outlines the functional and operational requirements of the Community Service Provider (CSP) for TSCP Secure v.1. TSCP Secure v.1 Technical Specification Page 3

9 TSCP Secure v.1 Requirements to Vendors This document articulates requirements to vendors who produce software for Enterprises and Service Providers for TSCP Secure v.1 solution elements: Client, Gateway, End User Certificate Repository, Certificate Lookup Service, Certificate Authority and Certificate Path Discovery and Validation Services. In order to implement Secure v.1, vendors must comply with the specifications set forth in other TSCP documents. TSCP Secure v.1 PKI Trust Framework This document sets forth configuration requirements for PKI solution elements. This document takes the secure business objectives and requirements related to trust fabric, trust model and trust framework, the building blocks that form the foundation for secure collaboration using TSCP Secure v.1. TSCP Secure v.1 Gateway Design Principles This document describes Inbound and Outbound Gateways that will inspect encrypted . TSCP Secure v.1 Glossary This document provides a comprehensive listing of TSCP Secure v.1 terms, acronyms and their definitions. TSCP Secure v.1 Technical Specification Page 4

10 2 Secure Scope and Requirements 2.1 TSCP Secure V.1 Scope The purpose of Secure is to protect the exchange of messages, their contents and their attachments. Secure provides message encryption, message signing, and messaging with both encryption and signing. Typical message content is information that: Is subject to national security controls. Is technology that is export controlled; and/or Belongs to competing and collaborating organizations, and is proprietary. Is highly sensitive. Secure provides a business capability that uses the investment in PKI by the A&D sector. 2.2 Secure Business Requirements Secure satisfies the following business requirements: The capability shall protect information using a mechanism that is of a strength that is commensurate with the level of sensitivity of that information The capability shall be suitable for large-, medium- and small-sized enterprises The capability shall allow the recipient of a message to authenticate the sender of that message The capability shall verify that the message has not been modified in transit The capability shall protect the content of the message so that only the intended recipients are able to read it The capability shall provide organizations a way to inspect the contents of inbound and outbound messages In order to satisfy those requirements, we must have trusted identities Trust shall be established in a way that is not dependent upon a particular technical trust mechanism Each participating organization shall implement Identity Management Procedures that are compliant with required policies such as the CertiPath certificate policy. TSCP Secure v.1 Technical Specification Page 5

11 2.2.9 Trust shall be established in a way that is scalable across all collaboration partners. There shall be support for multiple-bridge environments. Such a setting must be able to cope with naming conflicts and transitive trust, and accept the many possible topologies (peer to-peer, mesh, forest of hierarchies, or a single rooted hierarchy) Trust Fabric shall support the following certificate issuance mechanisms: Certificates issued by the participant s own Certificate Authority (CA) Certificates issued by a delegated Certificate Authority (CA). In order to sustain the capability, it must be periodically accredited and audited: The capability shall be accredited for use by the proper policy authorities for each enterprise Each enterprise shall be subject to a periodic compliance audit of secure implementation based on a commonly agreed upon audit methodology The periodic compliance audit shall be performed by certified auditors. There shall be a formal process to certify auditors. 2.3 Business Scenario The business scenario diagram below, Figure 1, illustrates the flow of the sending and receiving enterprises and the necessary supporting functions to establish trust, in line with the requirements defined above. The requirements are identified in Figure 1 by their associated paragraph numbers above. In order to implement and sustain the capability and establish trust, the enterprise implementations are inspected and audited. TSCP Secure v.1 Technical Specification Page 6

12 Figure 1. Business Scenario TSCP Secure v.1 Technical Specification Page 7

13 3 Secure Design This section: Describes the functions supported by Secure v.1. Defines the high level architecture. Describes the logical architecture. The high level architecture is further decomposed into a logical architecture of information flows, actors and solution elements. 3.1 Functions The four basic functions of Secure that are invoked at run-time are: Sending Encrypted . Receiving Encrypted . Sending Signed . Receiving Signed . The basic functions may be combined to enable sending or receiving signed and encrypted . These functions align to sender authentication, message integrity and message confidentiality identified in Section Sending Encrypted The Sending Encrypted function requires the Client to locate the appropriate End-User Encryption Certificate for each recipient, and encrypts the message 4 using this certificate. The Client contacts the Certificate Lookup Service using solution elements of the End-user Encryption Certificate Lookup Flow. The Certificate Lookup Service routes the request to the appropriate enterprise s End-User Certificate Repository Service unless a copy of the recipient s encryption certificate is available locally. The Certificate Lookup Service is kept up to date with the most recent configuration information using the Configuration Data Flow. If available, the End-user Encryption Certificate is returned to the client; the client encrypts and sends the message using the Message Flow. 4 Since most S/MIME v.3 implementations also encrypt the messages for the sender, the sender should also have access to their own private key. This will allow the sender to read the message in the sent items folder. TSCP Secure v.1 Technical Specification Page 8

14 3.1.2 Receiving Encrypted The Receiving Encrypted function relies on the delivery of the e- mail message using the Message Flow. On receipt of the message, the client decrypts it using the recipient s private key. This may be done using the solution elements outlined in the Path Discovery and Validation Flow and the Trust Flow Sending Signed During the process of sending a signed message, the sending Client creates a hash of the message, and encrypts the hash with the sender s private key. The TSCP Secure v.1 Technical Profile (Section 5.7) mandates that the End-User Signing Certificate must be attached to each digitally signed message. The message is transmitted from sender to recipient using the Message Flow. The Signed function as a whole relies on the solution elements outlined in the Trust Flow Receiving Signed Using solution elements of the Message Flow, during the process of receiving a signed message, the recipient must receive the End-User Signing Certificate as mandated by the Technical Profile in Section 5.7. Upon performing Path Discovery and Validation on the certificate using solution elements of the Path Discovery and Validation Flow, the recipient has assurance of the message integrity and certificate validity from the sender. The Signed function as a whole relies on the solution elements outlined in the Trust Flow. 3.2 Introduction to High Level Architecture This section describes the Secure v.1 high level architecture, and includes Figure 2. High-Level Architecture of TSCP Secure v.1. Each Enterprise is expected to have an Gateway (server) that forwards e- mail to and from Clients in its administrative domain, as well as to and from remote Gateways running at other enterprises. Each Enterprise is expected to set up an End-User Certificate Repository Service (EUCRS) that is available for use by other enterprises. This service supports userto-user encryption based on S/MIME by storing end-user certificates. Commonly in the A&D sector, enterprises need to support encrypted to other enterprises. For this reason, the certificate lookup service provides a scalable mechanism to locate an encryption certificate in the EUCRS of the receiving enterprise. Small and medium businesses may use Service Providers; however, this does not change the architecture of TSCP Secure v.1. TSCP Secure v.1 Technical Specification Page 9

15 Figure 2. High-Level Architecture of TSCP Secure v.1 Legend: = End-User Encryption Certificate request; = forwarding of an message; = dissemination of configuration information to users Figure 2 illustrates the six key collections of data flows in TSCP Secure v.1. Flows are described in more detail within the supporting document, TSCP Secure v.1 High Level Design. 3.3 Key Components of the Secure Solution The high level architecture is further decomposed into a logical architecture of Information Flows (3.4), Actors (3.5) and Solution Elements (3.6). This is illustrated in Figure 3. Logical Architecture and Solution Elements, which also shows the cross-certified PKI infrastructure 5 for encryption and digital signing. The TSCP Secure v.1 High Level Design is a point of reference to the architecture and provides a complete and comprehensive description of components. 5 More information related to a cross-certified PKI infrastructure can be found on the CertiPath PKI Trust Status website, TSCP Secure v.1 Technical Specification Page 10

16 Figure 3. Logical Architecture and Solution Elements TSCP Secure v.1 Technical Specification Page 11

17 Figure 3. Logical Architecture and Solution Elements breaks down into five swim lanes that illustrate the roles of the actors in executing the basic functions of Secure v.1. The top two swim lanes together show the solution elements and flows used by an enterprise to send signed or encrypted . These two swim lanes comprise the solution elements and flows for an Insource Enterprise as shown in Table 1. Characteristics of Insource vs. Outsource Enterprises. o Enterprises may choose to outsource a subset of these solution elements. o The top swim lane corresponds to solution elements that all enterprises must support to send signed or encrypted . o The second swim lane corresponds to solution elements that enterprises may outsource to a Service Provider to support sending signed or encrypted . The CA and PKI repository may be outsourced as part of Managed PKI Services. 6 The third swim lane represents solution elements and flows used by Community Service Provider and PKI bridge authority. o The left side corresponds to PKI bridge authority solution elements. The PKI Bridge is used to facilitate trust decisions. o The right side corresponds to Community Service Provider solution elements. The community registry is used as an authoritative source of certificate lookup service information. The bottom two swim lanes together show the solution elements and flows used by an enterprise to receive signed or encrypted . o The fourth swim lane corresponds to solution elements that enterprises may outsource to a Service Provider to support receiving signed or encrypted . The CA, EUCRS and PKI repository may be outsourced as part of Managed PKI Services. o The fifth swim lane corresponds to solution elements that all enterprises must support to receive signed or encrypted . 6 Enterprises typically outsource all or none of the CA, EUCRS and PKI repository solution elements. This is due to factors such as compliance and that they comprise an overall PKI architecture. TSCP Secure v.1 Technical Specification Page 12

18 3.4 Secure Information Flows At a high level, there are six information flows The Message Flow is the process of sending messages from the sender to the recipient. An gateway may decrypt the contents of messages, perform inspection, and then re-encrypt the contents. This is outside of the scope of the technical specification The Trust Flow reflects trust relationships between participating TSCP Secure v.1 enterprises. At a high level, the trust relationship includes the client-relying party trusting its own Principal Certificate Authority (PCA) Trust Root. Furthermore, the In-Source or Outsource PCAs (or subordinate CA) is cross-certified with the CertiPath Bridge CA (CBCA) or another Bridge CA cross-certified with CBCA (e.g., the Federal Bridge CA) at medium assurance level The Certificate Publication Flow is the process in which the end-user certificate is published to the End-User Certificate Repository Service (EUCRS) The Configuration Data Flow is the distribution of centrally managed information from the Community Service Provider to the Certificate Lookup Proxies of all users of Secure v The End-user Encryption Certificate Lookup Flow is the process of the sending client performing a lookup of an end-user certificate; it precedes the message flow in the user-to-user encryption use case. The sending client uses the target address to issue a certificate lookup request to the appropriate EUCRS, which retrieves the certificate and returns it to the client The Path Discovery and Validation Flow is the process of certificate discovery to construct a certification path from the end-user certificate to a trust anchor and top-down certificate validation. Because the message flow may occur at a different point in time than the path discovery and validation flow, the trust status may be different depending on when this flow is invoked. For example, all certificates have an expiration date beyond which the path discovery and validation flow will fail due to invalid trust status. TSCP Secure v.1 Technical Specification Page 13

19 3.5 Secure Actors Secure involves the following actors, described in more detail in the sections below: Enterprise, which may use a Service Provider 7 Service Provider (SP) o Responsible for hosting services for subscribing Outsource Enterprises. Community Service Provider (CSP) o Responsible for providing configuration information to organizations using TSCP Secure .1. PKI Bridge Authority o Responsible for providing trust between enterprise PKI deployments Characteristics of Enterprises The delineation between Insource and Outsource Enterprises is illustrated below in Table 1. Table 1. Characteristics of Insource vs. Outsource Enterprises Insource Owns one or more domains. Has an identity management program that manages addresses of its users. Has a PKI cross-certified with the CBCA or another CA cross-certified with CBCA or the FBCA. The certificates used by the enterprise s users are issued by that PKI. Uses its own certificate lookup service for End-User Encryption Certificate lookup Outsource Owns an domain that may or may not be shared with other enterprises. Has an identity management program that manages the addresses of its users. Although it may not own the infrastructure, address assignment and maintenance are under its control. Belongs to a PKI cross-certified with the CBCA or another CA cross-certified with CBCA or FBCA. The certificates used by the enterprise s users are issued by that PKI. Uses an outsource certificate lookup service offered by one of the Service Providers affiliated with Secure v.1 7 In-Source Enterprises are those that do not use a Service Provider; Outsourced Enterprises use Service Providers. TSCP Secure v.1 Technical Specification Page 14

20 Table 1. Characteristics of Insource vs. Outsource Enterprises Insource Hosts an end-user certificate repository service (EUCRS) used during the Sending Encrypted function. The EUCRS contains the enterprise s users encryption certificates. Outsource Hosts or outsources an end-user certificate repository service (EUCRS) for use during the Sending Encrypted function. The EUCRS contains the enterprise s users encryption certificates regardless of whether it is outsourced as managed PKI services Characteristics of Service Providers A Service Provider is an entity that is responsible for day-to-day operation, maintenance and management of: Outsourced certificate lookup services. PKI services. infrastructure services. An Outsource Enterprise may outsource only some of the services to an external provider; it may also outsource different services to different providers. The same type of service may be outsourced to multiple providers as the Enterprise sees fit. The TSCP technical implementation of the certificate lookup service is described in Section Characteristics of Community Service Providers (CSP) A Community Service Provider is an entity responsible for providing information on the configuration of certificate lookup services to organizations using Secure v.1 and will operate an industry-wide registry of enterprises. The CSP shall be responsible for providing the following functions: Registration of Enterprises to the service. De-registration of Enterprises from the service. Modification of Enterprises domains. Auditing and Reporting facilities on internal processes of the CSP. Providing notifications of configuration changes. Enterprise s training with respect to processes involving the CSP (registration, de-registration, configuration updates and notifications, etc.) TSCP Secure v.1 Technical Specification Page 15

21 3.5.4 Characteristics of a PKI Bridge Authority A PKI bridge authority is a policy management authority that provides for mutual trust between individual certificate authorities and PKI bridges. A PKI bridge authority operates under a charter to allow for PKI bridge services. The CertiPath policy management authority and the U.S. Federal PKI policy authority are examples of PKI bridge authorities. Due to the importance of trust decisions, PKI Bridges must meet rigorous standards. The CertiPath PKI Bridge and Federal PKI Bridge are examples that have met these standards. The CertiPath PKI Bridge, whose primary focus is the A&D sector, is cross-certified with the U.S. Federal PKI Bridge which supports various government organizations. TSCP Secure v.1 has a business requirement for trust path support that includes: Support for multiple-bridge environments. Accept the many possible topologies (peer to-peer, mesh, forest of hierarchies, or a single rooted hierarchy). Detailed information on supported trust paths, supported constraints and PKI trust is provided in the TSCP Secure v.1 PKI Trust Framework document. TSCP Secure v.1 Technical Specification Page 16

22 3.6 Secure Solution Elements Depending upon the type of enterprise, e.g., Insource Enterprise vs. Outsource Enterprise, solution elements of the logical architecture may exist within or outside of the enterprise boundary. Solution elements are illustrated in Figure 3. Logical Architecture and Solution Elements The Insource and Outsource Enterprise Secure Environment High Level Solution Elements As illustrated in Table 2 below, each solution element that has a relationship with one or more actors: Shall be supported by In-Source Enterprise Shall be supported by Outsource Enterprise May be supported by Outsource Enterprise Shall be supported by a Service Provider Shall be supported by either an Outsource Enterprise or Service Provider Shall be supported by Community Service Provider (CSP) For any solution element in the table below, if an appears for both Outsource Enterprise and Service Provider, only one or the other is required, not both. Solution Elements In-Source Enterprise Table 2. Solution Element to Actor Mapping Outsource Enterprise Service Provider Client Gateway CA EUCRS ECLP OCLP Outbound Border Proxy Optional PKI Repository PKI Bridge Community Registry Community Service Provider PKI Bridge Authority TSCP Secure v.1 Technical Specification Page 17

23 As shown in Figure 3. Logical Architecture and Solution Elements, an enterprise environment consists of the following solution elements: Client: a software program for users to send and receive Secure messages. Gateway: routes secure messages between enterprise users and those outside the enterprise. Certificate Authority (CA): issues.509 certificates, required for encrypting and signing messages, to enterprise users. End-User Certificate Repository Service (EUCRS): a service for external parties to look up End-User Encryption Certificates for enterprise users. Certificate Lookup Service: routes End-User Certificate lookup requests from the enterprise s users to the appropriate external EUCRS and returns a suitable certificate if one exists. An Outsourced Enterprise shall utilize a Service Provider for this service. The Secure technical implementation of the certificate lookup service is explained in Appendix A and is based on proxy technologies. Therefore, the certificate lookup service is renamed into several solution elements to reflect its position with actors and architecture. Enterprises may use other certificate lookup solutions, provided they conform to the technical specification and technical profile. Enterprise Certificate Lookup Proxy (ECLP), or Outsourced Certificate Lookup Proxy (OCLP) Outbound Border Proxy The Outbound Border Proxy is used by an Outsource Enterprise as an interface to an OCLP. An Outsourced Enterprise may include this solution element in its architecture. A Public Key Infrastructure (PKI) Repository stores both path verification (intermediate CA certificates, cross-certificates) and revocation information, against which information is checked and validated, e.g., certificate revocation lists (CRLs), Online Certificate Status Protocol (OCSP) responses). Such a repository may need to be available to relying party applications both internal and external to the enterprise, depending upon the model of Certificate Path Discovery and Validation chosen. 8 8 An enterprise may choose to pre-fetch and propagate certificates and / or revocation status information using out-ofband mechanisms. This document does not preclude such mechanisms. TSCP Secure v.1 Technical Specification Page 18

24 Some solution elements may be represented by multiple software systems and run either inside or outside the enterprise boundaries. Table 4 includes all functional solution elements an Enterprise shall have access to in order to participate in Secure The Community Service Provider Environment High Level Solution Elements A Community Service Provider shall provide the following services for Secure Community Registry, a central repository that contains user information, e.g., location and configuration of their End-User Certificate Repository Service (EUCRS) The PKI Bridge Authority Environment High Level Solution Elements The basic functions of secure (sending encrypted, receiving encrypted, sending signed, and receiving signed) rely on certificates that are delivered from an enterprise PKI. The PKI Bridge is the fundamental mechanism that allows one enterprise s PKI to accurately trust another enterprise s PKI. The PKI Bridge Authority shall provide the following services for Secure E- mail: PKI Bridge, a Certificate Authority cross-certified with the CertiPath CBCA directly or through another cross-certified bridge such as the FBCA. TSCP Secure v.1 Technical Specification Page 19

25 4 Secure Technical Solution This section defines the requirements for the technical solution for Secure , which include: The characteristics of the IT Environment. Operational and implementation requirements on Enterprises, Service Providers and Community Service Providers. Requirements on Vendors and Software Support. Standards and specifications. 4.1 The Characteristics of the IT Environment The following technical environment is required: Client-based systems with support for S/MIME v.3 Bridged-PKI environment Automated retrieval of recipient s encryption certificate 4.2 Requirements for Actors and Vendors Requirements for Actors Operational and implementation requirements for actors are defined in separate documents indexed in Table 3 below. For example, an entity interested in fulfilling the Community Service Provider function as described in this section should download TSCP Secure v.1 Requirements to Community Service Providers. Table 3. Secure v.1 Actor Requirements Requirements to Enterprises Requirements to Service Providers Requirements to Community Service Providers The operational requirements include service metrics associated in many environments with Service Level Agreements (SLA), as well as procedures, policies and rules that are present, for example, in Certificate Practice Statements (CPS) in PKIs Requirements for Vendors and Software Support The requirements for vendors of software systems and hardware devices necessary to support Secure are defined in supporting document TSCP Secure v.1 Requirements to Vendors v Software support and operational requirements are also documented. This TSCP Secure v.1 Technical Specification Page 20

26 document, along with all Secure technical support and guidance documents, is available for download from External Specification The Secure specification incorporates and cross-references external specifications, i.e., Internet Engineering Task Force (IETF). Table 4 below provides a context for this relationship to the Secure in the following manner: TSCP Secure v.1 Technical Specification Page 21

27 1 Table 4. External Specifications Mapping Table TS = Technical Specifications TP = Technical Profile ENT = Requirements to Enterprises VEND = Requirements to Vendors KEY FOR TABLE 4 ACRONYMS HLD = High Level Design CSP = Community Service Provider GDP = Gateway Design Principles External Specification (First reference is most current; subsequent references are obsoleted or updated.) Context to Technical Specification TS TP ENT CSP VEND HLD GDP FIPS140-3, Federal Information Processing Standards Publication 140-3, Security Requirements For Cryptographic Modules, December FIPS140-2, Federal Information Processing Standards Publication 140-2, Security Requirements For Cryptographic Modules, December Client Solution Element - Cryptographic Module support FIPS140-1, Federal Information Processing Standards Publication 140-1, Security Requirements For Cryptographic Modules, January FIPS 180-2, Federal Information Processing Standards Publication 180-2, Secure Hash Standard, August FIPS 180-1, Federal Information Processing Standards Publication 180-1, Secure Hash Standard, April Client Solution Element Used to support sender authentication and message integrity digital signature algorithm Federal Certificate Policy Certificate Policy For The Federal Bridge Certification Authority (FBCA) CA Solution Element, Path Discovery and Validation Flow TSCP Secure v.1 Technical Specification Page 23

28 TS = Technical Specifications TP = Technical Profile Table 4. External Specifications Mapping Table ENT = Requirements to Enterprises VEND = Requirements to Vendors KEY FOR TABLE 4 ACRONYMS HLD = High Level Design CSP = Community Service Provider GDP = Gateway Design Principles External Specification (First reference is most current; subsequent references are obsoleted or updated.) Context to Technical Specification TS TP ENT CSP VEND HLD GDP Trust Flow, Path Discovery and Validation Flow CertiPath Certificate Policy Client Solution Element, CA, PKI Bridge and Community Registry Solution Element All Basic Functions used to support certificate compliance CertiPath Key Recovery Policy Trust Flow, CA Solution Element Overall Solution Element Functional Requirement, RFC 3851, Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification. July RFC 2633, S/MIME Version 3 Message Specification, June Client Solution Element Used to describe cryptographic algorithm support, All Basic Functions (RFC 3851) Client Solution Element Used to support sender authentication and message integrity digital signature, message confidentiality (RFC 2633/3851) TSCP Secure v.1 Technical Specification Page 24

29 TS = Technical Specifications TP = Technical Profile Table 4. External Specifications Mapping Table ENT = Requirements to Enterprises VEND = Requirements to Vendors KEY FOR TABLE 4 ACRONYMS HLD = High Level Design CSP = Community Service Provider GDP = Gateway Design Principles External Specification (First reference is most current; subsequent references are obsoleted or updated.) Context to Technical Specification TS TP ENT CSP VEND HLD GDP RFC 4524, COSINE LDAP/.500 Schema, June RFC 1274, The COSINE and Internet.500 Schema, November CLP Solution Element - Used to describe address attribute in context of LDAP based search request of certificate RFC 5652, Cryptographic Message Syntax (CMS), September RFC 3852, Cryptographic Message Syntax (CMS), July Overall Solution Element Functional Requirement Client Solution Element - Used to support Sender Authentication and Message Integrity requirement to attach certificate RFC 4511, Lightweight Directory Access Protocol (LDAP): The Protocol, June EUCRS, ECLP, and CLP Solution Elements Used to describe LDAP search request support RFC 4514, Lightweight Directory Access Protocol (LDAP): String Representation of Distinguished Names ECLP and CLP Solution Elements Used to support LDAP fetch request with distinguished names RFC 4522, Lightweight Directory Access Protocol (LDAP): The Binary Encoding Option, June 2006 ECLP and CLP Solution Elements Used to support LDAP option binary TSCP Secure v.1 Technical Specification Page 25

30 TS = Technical Specifications TP = Technical Profile Table 4. External Specifications Mapping Table ENT = Requirements to Enterprises VEND = Requirements to Vendors KEY FOR TABLE 4 ACRONYMS HLD = High Level Design CSP = Community Service Provider GDP = Gateway Design Principles External Specification (First reference is most current; subsequent references are obsoleted or updated.) Context to Technical Specification TS TP ENT CSP VEND HLD GDP RFC 4522, Lightweight Directory Access Protocol (LDAP): The Binary Encoding Option, June 2006 ECLP and CLP Solution Elements Used to support LDAP option binary RFC 5750, Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Certificate Handling, January RFC 3850, Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Certificate Handling, July RFC 2632, S/MIME Version 3 Certificate Handling, June Client Solution Element Used to support sender authentication and message integrity digital signature algorithm. (RFC 2632/3850/5750) All Basic Functions (RFC 3850/5750) RFC 3565, Use of the Advanced Encryption Standard (AES) Encryption Algorithm in Cryptographic Message Syntax (CMS), July 2003 Sending Encrypted Function and Receiving Encrypted Function RFC 5754, Using SHA2 Algorithms with Cryptographic Message Syntax, January RFC 3370, Cryptographic Message Syntax (CMS) Algorithms, August Sending Encrypted Function and Receiving Encrypted Function RFC 5035, Enhanced Security Services (ESS) Update: Adding CertID Algorithm Agility, August RFC 2634, Enhanced Security Services for S/MIME, June All Basic Functions used to support additional functionality of message receipts in miscellaneous section TSCP Secure v.1 Technical Specification Page 26

31 TS = Technical Specifications TP = Technical Profile Table 4. External Specifications Mapping Table ENT = Requirements to Enterprises VEND = Requirements to Vendors KEY FOR TABLE 4 ACRONYMS HLD = High Level Design CSP = Community Service Provider GDP = Gateway Design Principles External Specification (First reference is most current; subsequent references are obsoleted or updated.) Context to Technical Specification TS TP ENT CSP VEND HLD GDP RFC5280, Internet.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile, May RFC3280, Internet.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile, April Client Solution Element - used to support acceptable certificate policies, Path Discovery and Validation Flow RFC2560,.509 Internet Public Key Infrastructure Online Certificate Status Protocol OCSP. June CA Solution Element, Path Discovery and Validation Flow used to support OCSP revocation checking RFC 4262,.509 Certificate Extension for Secure/Multipurpose Internet Mail Extensions (S/MIME) Capabilities. December Client Solution Element used to support S/MIME capability information RFC 4513 Lightweight Directory Access Protocol (LDAP): Authentication Methods and Security Mechanisms, June Client, EUCRS, ECLP and CLP Solution Elements used to support LDAP over TLS RFC 5246, The Transport Layer Security (TLS) Protocol Version 1.2, August RFC 4346, The Transport Layer Security (TLS) Protocol Version 1.1, April 2006 RFC 2246, The TLS Protocol, Version 1.0., IETF, January Gateway Solution Element used to support Organization-to- Organization Secure TSCP Secure v.1 Technical Specification Page 27

32 TS = Technical Specifications TP = Technical Profile Table 4. External Specifications Mapping Table ENT = Requirements to Enterprises VEND = Requirements to Vendors KEY FOR TABLE 4 ACRONYMS HLD = High Level Design CSP = Community Service Provider GDP = Gateway Design Principles External Specification (First reference is most current; subsequent references are obsoleted or updated.) Context to Technical Specification TS TP ENT CSP VEND HLD GDP RFC 4301, Security Architecture for the Internet Protocol, December 2005 RFC 2401, Security Architecture for the Internet Protocol, IETF, November Gateway Solution Element used to support Organization-to- Organization Secure RFC 4306, Internet Key Exchange (IKEv2) Protocol, December 2005 RFC 2409, The Internet Key Exchange (IKE), IETF, November Gateway Solution Element used to support Organization-to- Organization Secure RFC3207, SMTP Service Extension for Secure SMTP over Transport Layer Security, IETF, February Gateway Solution Element used to support Organization-to- Organization Secure Information Technology Open Systems Interconnection The Directory: Public-Key and Attribute Certificate Frameworks. ITU-T Recommendation.509 (2000), ITU, EUCRS Solution Element TSCP Secure v.1 Technical Specification Page 28

33 5 Secure Implementation Many of the solution components provide a range of options to allow for flexibility to implementers. The PKI Bridge has no implementation constraints defined by TSCP and is subject to controls identified in the PKI Bridge Authority s CP and KRP. The Community Registry implementation constraints are defined in the TSCP Requirements to Community Service Providers. Secure mandates use of specific options as described in the sections below: 5.1 Overall Solution Element Implementation Constraints User-to-user secure delivery provides user-to-user confidentiality, authenticity and integrity of messages. Table 5 below illustrates the implementation constraints applied by Secure based on the solutions characteristics. Table 5. Overall Functional Constraints Characteristics of Solutions Digital signature S/MIME compliance Encryption S/MIME compliance Encryption certificate usage Enterprise recovery of content of encrypted Domains Service Provider Selection Implementation Constraints The sending and receiving client shall support S/MIME v.3.x-based digital signing of messages to guarantee message authenticity and integrity. The user-to-user delivery option shall support S/MIME v.3.x-compliant encryption by the sender and decryption by the recipient at their respective clients. The sending Client shall be able to locate the appropriate End-User Encryption Certificates for each recipient and use them to encrypt their respective messages. Enterprise recovery of content of encrypted (belonging to enterprise subscribers) may be implemented by authorized personnel in accordance with CertiPath Key Recovery Policy. An Enterprise may register one or more domains to participate in Secure v.1, and withdraw or add domains as required. An Enterprise that outsources Certificate Lookup Services to a Service Provider shall do so only with a Service Provider registered with a Community Service Provider. TSCP Secure v.1 Technical Specification Page 27

34 5.2 Certificate Authorities Table 6. Certificate Authority Implementation Constraints Implementation Constraints An Enterprise shall use a PKI implementation compliant with x.509v3 which is used to issue credentials An Enterprise shall belong to a PKI which is cross-certified with the CBCA PKI Bridge or a PKI Bridge that is cross-certified with the CBCA such as the FBCA An Enterprise shall ensure equivalence with CertiPath Certificate Policies at Technical, Management and Operational levels An Enterprise shall ensure operational compliance with PKI Compliance Audits An Enterprise shall restrict the number of policy mappings to a maximum of three A Service Provider shall be able to issue identity, signing and encryption certificates to end users A Service Provider shall operate a Key Recovery Service (if it issues End-User Encryption Certificates) compliant with the CertiPath Key Recovery Policy A Service Provider shall publish CA certificates and Certificate Revocation Lists (CRLs) consistent with CertiPath.509 Certificate Profile A Service Provider may operate one or more responders for online certificate status verification using the Online Certificate Status Protocol (OCSP) A Service Provider shall provide issuance, renewal and revocation of end-user certificates consistent with the CertiPath Policy.509 Certificate Profile An Enterprise s users shall have access to facilities for issuance, renewal and revocation of end-user certificates An Enterprise s users shall be provisioned RFC 822-compliant addresses. TSCP Secure v.1 Technical Specification Page 28

35 5.3 PKI Repositories This section illustrates implementation constraints specific to PKI repositories for Enterprises and Service Providers. Table 7. PKI Repository Implementation Constraints Implementation Constraints An Enterprise shall ensure equivalence with CertiPath Certificate Policies at Technical, Management and Operational levels An Enterprise shall ensure operational compliance with PKI Compliance Audits A Service Provider shall publish CA certificates and Certificate Revocation Lists (CRLs) consistent with CertiPath.509 Certificate Profile A Service Provider may operate one or more responders for online certificate status verification using the Online Certificate Status Protocol (OCSP). TSCP Secure v.1 Technical Specification Page 29

36 5.4 End-User Certificate Repository Service (EUCRS) An End-User Certificate Repository Service (EUCRS) provides one or more End- User Encryption Certificates upon request. Every End-User Encryption Certificate discussed in this document shall be available from at least one EUCRS. Although two implementation approaches are informally discussed, this document does not specify implementation parameters for such a Service, but only defines the Service s externally-observable behavior. The same Service may be used by clients located inside the hosting enterprise. Alternatively, the Enterprise may set up a different service for internal purposes. Such services are outside the scope of this document and will not be discussed further. Table 8 below lists implementation constraints for the EUCRS solution element. Table 8. EUCRS Functional Constraints Characteristics of Solutions EUCRS Implementation Constraints Number of End-User EUCRS should return all available encryption certificates for Encryption Certificates the requested user subject to the hosting enterprise s returned policies processing EUCRS shall return only.509 v3 certificates [509] Internet access EUCRS shall be accessible from the Internet LDAP version EUCRS shall support LDAPv LDAP search optional base name LDAP search optional scope flag LDAP search address attribute LDAP search directory attribute name EUCRS shall support LDAP requests that specify a base name. (A NULL base name may be supported but such support is not required.) EUCRS shall support LDAP requests that specify a scope flag. EUCRS shall support LDAP requests that specify a filter in the form address attribute= address value. EUCRS shall support LDAP requests that specify an optional name or names of directory attribute(s) holding End-User Encryption Certificates LDAP distinguished name follow-up fetch End-User Encryption Certificate validity Some Clients may submit a search request, receive the distinguished name of the object satisfying the query, and follow up with a fetch request for that distinguished name. EUCRS shall support such fetch requests. [RFC 4511] EUCRS shall return well-formed.509 v3 encryption certificates that are (a) issued by a PKI cross-certified with the CertiPath Bridge CA (CBCA) or a PKI Bridge crosscertified with CBCA, (b) time-valid, and (c) not revoked. TSCP Secure v.1 Technical Specification Page 30

37 Table 8. EUCRS Functional Constraints Characteristics of Solutions EUCRS Implementation Constraints LDAP referrals EUCRS shall not use LDAP referrals Authentication Private Channel Support Certificate Profiles EUCRS may (a) require its clients to use password-based authentication or (b) support anonymous LDAP binding. It shall not require any other authentication mechanisms. End-User Certificate Repository Services should support establishment of private channels with their clients; establishment of encrypted sessions using LDAP over TLS should be supported. End-User Certificate Repository Services should allow administrators to configure profiles of certificates being returned. For example, they may define key usage, the name of the issuer, acceptable certificate policies. TSCP Secure v.1 Technical Specification Page 31

38 5.5 Certificate Lookup Services Certificate Lookup Services may be undertaken within an Enterprise (ECLP) or by a Service Provider (OCLP). While many of the technical constraints of these cases are identical, there are key differences to be recognized. Table 9 below identifies where ECLP and OCLP technical constraints are the same by noting it within a common cell. However, their differences are also clearly identified in separate columns within the table Table 9. Insourced Enterprise and Outsourced Certificate Lookup Services Characteristics of Solution Number of End- User Encryption Certificates returned Client / server communication Scope of EUCRS support ECLP Implementation Constraints ECLP should return a single qualifying End-User Encryption Certificate for the requested user if such a certificate is available. Individual users may allow more than one certificate returned to the OCLP Implementation Constraints The OCLP shall return a single End-User Encryption Certificate for the requested user if such a certificate is available from the corresponding EUCRS. Client. Shall be able to communicate as a server to support End- User Encryption Certificate lookup requests with all users as clients. N/A LDAP version Shall support LDAPv3 [RFC 4511] LDAP search optional base name LDAP search optional scope flag LDAP search address attribute LDAP search directory attribute name LDAP distinguished name follow-up fetch The OCLP, for an Enterprise, shall support the lookup of all end-user certificates within that same Outsource Enterprise. Shall support LDAP search requests that specify an optional base name. [RFC 4511] Shall support LDAP search requests that specify an optional scope flag. [RFC 4511] Shall support LDAP search requests that specify: A filter in the form address attribute= address value. The only attribute name ECLP or OCLP shall support is mail as defined in RFC 4524 and its predecessor, RFC [RFC 4511] Shall support LDAP search requests that specify: An optional name or names of directory attribute(s) holding End-User Encryption Certificates. [RFC 4511] Shall support such fetch requests that meet the following scenario: [RFC 4511] Some Clients may submit a search request, receive the distinguished name of the object satisfying the query, and follow up with a fetch request for TSCP Secure v.1 Technical Specification Page 32

39 Table 9. Insourced Enterprise and Outsourced Certificate Lookup Services Characteristics of Solution ECLP Implementation Constraints that distinguished name. OCLP Implementation Constraints LDAP distinguished name compliance End-User Encryption Certificate integrity LDAP option binary LDAP referrals Mutual authentication EUCRS local configuration Domain name 9 EUCRS host name / IP Shall return distinguished names in compliance with RFC Likewise, it shall be able to process fetch requests with distinguished names in all forms supported by RFC [RFC 4514] N/A ECLP should use the LDAP option binary when requesting (and expecting) DER-formatted End-User Encryption Certificates from target End-User Certificate Repository Services. [RFC 4522] The OCLP shall maintain the integrity of the End-User Encryption Certificates it receives from corresponding EUCRS. The OCLP should use the LDAP option binary when requesting End-User Encryption Certificates from target EUCRS. [RFC 4522] Shall not provide LDAP referrals to its callers in lieu of regular responses. No Specification This document does not define mechanisms for mutual authentication between the OCLP and its clients. Participating Service Providers may define such mechanisms. Shall support local configuration for target End-User Certificate Repository Services. The following parameters shall be supported: The target s E- mail Domain name (Note: The ECLP shall use the most specific domain name in its configuration: e.g., if domains xyz.com and abc.xyz.com have been configured, the addresses foo@bar.abc.xyz.com and foo@abc.xyz.com will match the abc.xyz.com entry, but the address foo@xyz.com will match xyz.com.) The following parameters shall be supported: The host name or the IP address of the target s LDAPv3-based End- User Certificate Repository Service. 9 An domain may be supported by more than one entry in the OCLP or ECLP when an enterprise has user certificates stored in a number of different EUCRS's, possibly as a result of procuring certificates from more than one Service Provider. TSCP Secure v.1 Technical Specification Page 33

40 Table 9. Insourced Enterprise and Outsourced Certificate Lookup Services Characteristics of Solution EUCRS port number EUCRS base DN LDAP address attribute LDAP person name attribute LDAP encryption certificate attribute EUCRS user ID / password Multiple LDAP encryption certificate attributes EUCRS anonymous and user ID / password bind Mode of operation ECLP Implementation Constraints OCLP Implementation Constraints The following parameter shall be supported: the port number of the target s LDAPv3-based End-User Certificate Repository Service. The following parameter shall be supported: the base DN (may be NULL; if so, the target End-User Certificate Repository Service must allow queries with NULL base distinguished names). The following parameter shall be supported: the name of the LDAP attribute containing users addresses. The following parameter shall be supported: the name of the LDAP attribute containing users person names. The following parameter shall be supported: the names of the LDAP attributes containing users encryption certificates. The following parameters The following parameter shall shall be supported if be supported: the optional required by the target user ID and password used for EUCRS: The optional user authentication to the target ID and password used for End-User Certificate authentication to the target Repository Service. End-User Certificate Repository Service. The following parameter shall be supported: multiple LDAP attribute names for End-User Encryption Certificates shall be supported. ECLP shall be able to bind to the target EUCRS anonymously or by using a target-specific user ID/password combination. No Specification The OCLP shall be able to bind to the target EUCRS anonymously or using a targetspecific user ID/password combination if required by the target EUCRS. The following parameter shall be supported: The OCLP must be able to operate in two modes: (a) Normal Mode and (b) Troubleshooting Mode. 10 As specified in RFC 4511 and requirement 5.4.8, LDAP attribute names for End User Encryption Certificates correspond to names of directory attribute(s) holding End-User Encryption Certificates. TSCP Secure v.1 Technical Specification Page 34

41 Table 9. Insourced Enterprise and Outsourced Certificate Lookup Services Characteristics of Solution Normal mode of operation Troubleshooting mode of operation Certificate Lookup Service Registration CSP Registration Outsourcing Certificate Lookup Service Support Certificate Lookup Service Filtering Private Channel Support ECLP Implementation Constraints No Specification No Specification An Enterprise shall register with a Community Service Provider (CSP). An Enterprise may register with a CSP through a Service Provider if the latter offers such services. N/A N/A OCLP Implementation Constraints The following parameter shall be supported: when in Normal Mode, The OCLP shall not log any information tracing callers to target addresses. The following parameter shall be supported: when in Troubleshooting Mode, the OCLP may log information tracing callers to target addresses. Such information shall be securely removed (e.g., degaussed) when the OCLP switches back to Normal Mode. A Service Provider offering a Certificate Lookup Service shall be registered with the Community Service Provider (CSP). A Service Provider may provide registration services to its subscribing Enterprises to register them and their Domains with the Community Service Provider (CSP) and maintain the necessary configuration at the CSP on their behalf. A Service Provider shall have facilities, software, hardware, and personnel to receive new versions of the configuration from the CSP. A Service Provider may limit the list of End-User Certificate Repository Services available for lookup, either across the board for all its customers or on per customer basis. Certificate Lookup Services should support establishment of private channels with their clients; establishment of encrypted sessions using LDAP over TLS should be supported. TSCP Secure v.1 Technical Specification Page 35

42 The Outbound Border Proxy, which is optional, allows Outsourced Enterprise users access to their Service Provider-hosted OCLP. A typical use case is to allow certificate lookup service access for selected users within an enterprise. This configuration is explained in further detail in Appendix A and illustrated in Figure 4. Concept of Operation: Certificate Lookup Service. An Outbound Border Proxy may be implemented with clients configured to use it as a source of recipients End-User Encryption Certificates. Table 10 below identifies the requirements for Outbound Border Proxies: Table 10. Outbound Border Proxy Functional Constraints Characteristics of Solution Implementation Constraints OCLP Compatibility An Enterprise s Outbound Border Proxy shall be compatible with the OCLP used by the User s Service Provider Client Compatibility An Enterprise s Outbound Border Proxy shall be compatible with the Clients used by the Users. These constraints apply to Enterprises that choose to employ the Outbound Border Proxy. TSCP Secure v.1 Technical Specification Page 36

43 5.6 Secure Gateways Secure Gateways may be implemented as inspecting gateways, which decrypt, inspect and re-encrypt content before passing it on, or passthrough gateways, which forward on encrypted content without inspection. Pass-through gateways are out-of-scope for this section. The following information explains inspecting gateways only, that are in-scope for this section. Inspecting gateways may be implemented as inbound or outbound. Inbound Gateways will inspect message content destined to an client within its enterprise. Outbound Gateways will inspect message content sourcing from an client within its Enterprise. Table 11. Overall Gateway Implementation Constraints An Enterprise Infrastructure shall be available to the public via SMTP gateways An Enterprise shall have an SMTP-based infrastructure An Enterprise may have any internal infrastructure, for example, SMTP or An Enterprise s internal infrastructure may contain multiple edge and intermediate mail servers An Enterprise s infrastructure may be partitioned according to geographic location, organizational structure and operational characteristics An Enterprise may use contractors to operate and maintain its entire infrastructure or some of its components and subsystems. Table 12. Inspecting Gateway Implementation Constraints Inbound Implementation Constraints Receiving enterprises may inspect incoming encrypted using key recovery mechanisms in accordance with CertiPath Key Recovery Policy. 11 Outbound Implementation Constraints Sending enterprises may inspect outgoing encrypted using mechanisms that maintain the confidentiality of the message in transit. 11 CertiPath KRP version 1.4 states in section 1.1: Some Organizations require that the contents of incoming and/or outgoing be examined for compliance with the Organization Policy. This Key Recovery Policy (KRP) provides guidance to ensure that encrypted data is recovered expeditiously when appropriate. The purpose of this document is to describe the security and authentication requirements to implement key recovery operations. TSCP Secure v.1 Technical Specification Page 37

44 Table 12. Inspecting Gateway Implementation Constraints Inbound Implementation Constraints An Inbound Gateway shall forward the original message to the intended recipient if it complies with the receiving enterprise s policies An Inbound Gateway shall take action if content does not comply with the receiving enterprise s policies Operation of an Inbound Gateway shall have no impact on the senders of encrypted messages The presence of a gateway shall not impose any additional requirements on the sender, the sender s Client or the e- mail infrastructure of the sender s enterprise with the exception of those necessary for inspection. Outbound Implementation Constraints An Outbound Gateway shall forward the original message to the intended recipient if it complies with the sending enterprise s policies. An Outbound Gateway shall take action if content does not comply with the sending enterprise s policies. Operation of an Outbound Gateway shall have no impact on the recipients of encrypted messages from the hosting enterprise. The presence of a Gateway shall not impose any additional requirements on the recipient, the recipient s Client or the infrastructure of the recipient s enterprise with the exception of those necessary for inspection An Inbound or Outbound Gateway should not add any significant delays to the delivery time of encrypted messages An Inbound Gateway should not serve as a source of decrypted messages to any other system, including archiving systems N/A An Outbound Gateway should not serve as a source of decrypted messages to any other system in the enterprise. An Enterprise should not feed decrypted messages from the Outbound Gateway to the archiving system if it has a policy of archiving all messages sent by its users An Enterprise shall notify all enterprises from which it receives or plans to receive encrypted if an Inbound Gateway feeds decrypted messages from the gateway to its archiving system Based on its enterprise s policies, if an Inbound Gateway forwards an message to the intended recipient, it should forward the original encrypted (and possibly, signed) message. An Enterprise shall notify all enterprises to which it sends or plans to send encrypted e- mail if it feeds decrypted messages from the Outbound Gateway to the archiving system. N/A TSCP Secure v.1 Technical Specification Page 38

45 Table 12. Inspecting Gateway Implementation Constraints Inbound Implementation Constraints The Inbound Gateway should decrypt the inbound message, verify its content, and forward it in its original encrypted form to the recipient If an Enterprise does not forward an encrypted message in its original encrypted form to the recipient, e.g., if it is necessary to re-encrypt a message or to transmit it within the enterprise in the clear, it shall notify the sending enterprise Enterprises operating an Inbound Gateway shall notify all potential sending enterprises about the use of the Gateway, provide the necessary (mutually agreed-to) information to them and, possibly, sign an authorization agreement to this effect An Enterprise on whose behalf an Inbound Gateway is operated may notify the sending enterprise when an encrypted e- mail message from one of its users has been blocked An Inbound Gateway may be operated by an Enterprise or a contractor on behalf of an Enterprise. Outbound Implementation Constraints N/A N/A An Enterprise operating an Outbound Gateway may notify potential receiving enterprises about the use of the Gateway subject to its own and the other enterprises policies. An Enterprise operating an encrypting Outbound Gateway should notify potential receiving enterprises about the use of the Gateway and its functionality, subject to policy. An Outbound Gateway may be operated by an Enterprise or a contractor on behalf of an Enterprise An Inbound Gateway may use additional services (such as a Key Escrow Database or Session Key Recovery Service) operated by the Enterprise or by contractors in support of the Enterprise The Enterprise shall be responsible for compliance of its Inbound or Outbound Gateway. An Inbound Gateway shall be used only for inspection of incoming messages. N/A An Outbound Gateway shall be used only for inspection of outgoing messages An Inbound or Outbound Gateway may be responsible for inspecting both encrypted and unencrypted messages. TSCP Secure v.1 Technical Specification Page 39

46 Table 12. Inspecting Gateway Implementation Constraints Inbound Implementation Constraints An Inbound Gateway shall have appropriate technical, physical, procedural, personnel and other controls in place that will prevent private keys, session keys and decrypted messages from exposure to personnel messages shall exist in their decrypted state for the least possible time Encrypted shall be deleted immediately after inspection if it is not archived. Outbound Implementation Constraints An Outbound Gateway shall have appropriate technical, physical, procedural, personnel and other controls in place that will prevent clear-text messages from exposure to personnel. N/A N/A Private keys and session keys shall be safely deleted immediately after use in accordance with stipulations of the CertiPath Key Recovery Policy The Inbound or Outbound Gateway should log the following types of events: Receipt of an message. Decryption of an message. Outcome of the inspection of an message. Forwarding of an approved message to the recipient. Deletion or forwarding of a blocked message to the exception/quarantine facility. N/A N/A N/A Messages shall be signed by the senders only. The Outbound Gateway should preserve the sender s signature N/A N/A If an Outbound Gateway blocks a message, it should notify the sender of the message. Protection of the unencrypted flow from Clients to an Outbound Gateway shall be at least as secure as protection afforded by S/MIME-based encryption compliant with the TSCP Secure v.1 Technical Profile. TSCP Secure v.1 Technical Specification Page 40

47 5.7 TSCP Secure v.1 Components Client The implementation constraints specific to the Client are illustrated in the TSCP Secure v.1 Technical Profile. The Technical Profile also provides constraints to the solution elements to support particular functions within Secure , and defines constraints commensurate with the sensitivity of the messages being transmitted. Table 13 indicates the sections of the technical profile that are relevant to each function. Table 13. Secure v.1 Technical Profile Alignment to Business Scenario Secure v.1 Functions Section Technical Profile Section 3.1 The Enterprise Environment Basic Functions General and Miscellaneous Sending Encrypted Function Receiving Encrypted Function Sending Signed Function Receiving Signed Function Message Confidentiality Sender Authentication and Message Integrity TSCP Secure v.1 Technical Specification Page 41

48 6 Appendix A Enterprise Certificate Lookup Proxy, the Outsourced Certificate Lookup Proxy and Outbound Border Proxy Solution Elements This section provides an additional level of detail and context to ECLP, CLP and Outbound Border Proxy solution elements. The ECLP (Insource Enterprise) and the OCLP (Outsource Enterprise) are illustrated as one solution element in Figure 3. Logical Architecture and Solution Elements. When a user intends to send an encrypted S/MIME message to another user, that sender needs the intended recipient s End-User Encryption Certificate. Such certificates may be available locally, at the sender s desktop, through manual configuration. Enterprises increasingly participate in collaborative projects that require communication among the participating suppliers, partners, customers and contractors. However, manual procurement of other users End-User Encryption Certificates does not scale to support these new realities. In addition, enterprises require more control in setting what certificates may be acceptable for communication. On the other hand, certificate publishers customarily make end-user certificates public through what Secure v.1 refers to as End-User Certificate Repository Services (EUCRS). Specialized LDAP proxy technologies have been created that are capable of fetching End-User Encryption Certificates and automating their discovery in clients. This capability is completely standards-based, ensuring that any off-the-shelf client supporting the LDAP protocol may communicate with the proxy and fetch End-User Encryption Certificates through it. The certificate lookup architecture proposed in this section is based on TSCP s experience with this software. The Concept of Operation of a Certificate Lookup Service is illustrated in Figure 4. When it receives a lookup request from an Client, the Proxy separates the Domain part of the recipient s address, consults its lookup table mapping Domain names to locations of the End-User Certificate Repository Services, and upon finding a match, forwards the request to the corresponding EUCRS. The response received from the EUCRS is forwarded back to the Client. TSCP Secure v.1 Technical Specification Page 42

49 Figure 4. Concept of Operation: Certificate Lookup Service Figure 4 illustrates three principal approaches to End-User Encryption Certificate lookup. An Insource Enterprise will most likely use its own Enterprise Certificate Lookup Service as shown in Figure 3. Logical Architecture and Solution Elements. This aligns to the trust flow documented in paragraph Small and medium businesses will use one of the Certificate Lookup Services hosted by Service Providers. This is illustrated by Figure 5. End-User Encryption Certificate Lookup: Use Cases, that aligns to the trust flow documented in paragraph The first diagram illustrates how an Outsource Enterprise allows Clients from within its enterprise to directly connect to external LDAP directories (or proxies); the second diagram illustrates the case in which an Outsource Enterprise does not allow direct connection but requires mediation via an enterprise-wide Outbound Border Proxy. The Outbound Border Proxy area is highlighted in Figure 3. Logical Architecture and Solution Elements without illustrating the actual solution element in detail. The Outsource Enterprise Environment with an Outbound Border Proxy and Service Provider Core Environment are shown for clarity in Figure 6 and illustrates the actual solution element in detail. All other interactions are unchanged from Figure 3. TSCP Secure v.1 Technical Specification Page 43

50 (c) Figure 5. End-User Encryption Certificate Lookup: Use Cases TSCP Secure v.1 Technical Specification Page 44

51 Figure 6. Outsource Enterprise Environment with Outbound Border Proxy TSCP Secure v.1 Technical Specification Page 45