Appendix W Commonwealth of Pennsylvania ehealth Collaborative Office. CSS HIE Security Services Security Infrastructure Requirements

Transcription

1 Appendix W Commonwealth of Pennsylvania ehealth Collaborative Office CSS HIE Security Services Security Infrastructure Requirements

2 Table of Contents Introduction... 3 Security Context... 3 A. PKI Model Requirements... 5 Policy Requirements (Functional)... 5 Assessment Framework and Standards Requirements (Functional)... 5 Evaluation and Initial Accreditation Requirements (Functional)... 6 Certificate Trust List and Distribution Requirements (Functional)... 6 Development of Certification Practices for ehco CSS-level CA Requirements (Functional)... 7 CA Initialization and Operations Requirements (Functional)... 7 Trust List Technical Requirements... 9 Bridge CA Technical Requirements... 9 B. Directory Services Requirements Schema Requirements (Functional) Identity Repository Requirements (Functional) Abstraction Layer Requirements (Functional) Administration Requirements (Functional) Hardware and Software Requirements (Technical) General Availability Requirements (Technical) C. Federation Requirements General Requirements for Client Certificates (Functional) General Requirements (Functional) Roadmap to the Future Securing Application Program Interfaces (Functional) Client Certificates (Technical) OAuth Requirements (Technical) SAML Requirements (Technical) Appendix: Certificate Profiles Profile for ehco Bridge CA Certificate (Technical) Profile for Cross Certificate Issued by the ehco Bridge CA (Technical) Profile for Organization Certificates Issued to Identity and Services Providers for the Purpose of Signing SAML Assertions (Technical)

3 Introduction This document contains requirements for ehco CSS security services and related processes to support NwHIN Direct and other health information exchanges (HIEs). These requirements can be broken down into three main areas: Public Key Infrastructure (PKI) Model; Directory Services; and Federation. a) PKI Model The Pennsylvania ehealth Collaborative Office (ehco) PKI is intended primarily to: i. Provide for interoperability between the various Certificate Authorities (CAs) supporting individual Health Information Service Providers (HISPs)/HIEs; ii. Provide a technical basis for trust to support federation among the HISPs/HIEs and ehco. b) Directory Services i. The DIRECT exchange use case for ehco directory services is the familiar Provider Lookup. An individual healthcare provider (a person) queries the lookup service on the basis of information which only partially describes a peer provider. The service returns all identifying information that is consistent with the query. The provider searches the query-response to further identify the peer and obtain an associate DIRECT ( ) address. c) Federation ehco seeks to leverage the security infrastructures and services provided by individual HISPs/HIEs to: i. Provide access to services that exist as community shared services; ii. Share information resources among various HISPs/HIEs. Security Context ehco participants are organized in a specific structure that greatly affects the provisioning of security requirements: 1. Individuals can only gain access to ehco provided health resources or the exchange of Direct messages through their participation in a HISP or an HIE. The HISP/HIE provides a gateway to services that may only be acquired after an individual presents login credentials to that particular HISP/HIE. 2. The HISP/HIE acts as a security trust agent in that it proxies an individual for purposes of authentication, signature, and encryption/decryption. To do so, it caches an individual s private key material and only invokes those keys when required to provide that individual with access to a specific service or information. 3. Management of the use of such private key material is subject to the HISP/HIE security policy, and thus, it is subject to the standards set by the ehco community, state, and Federal regulation. 4. The HISP/HIE exercises autonomy in acquiring security services to control its operations. The HISP/HIE can select (or sponsor ) any source for the digital certificates that it chooses to use to secure Direct and other HIEs. However, those certificates will have limited utility until the certificate source has been properly vetted by the ehco community and included in ehco s 3

4 trust ecosystem. The trust ecosystem will include ehco, the CSS, and all participants (hereafter the trust ecosystem ) and will promote secure, confidential information exchange from one organization to another. 5. ehco anticipates a two phase process by which the various HISP/HIE CAs can interoperate. Initially, and only on an interim basis, the root certificates of qualified and appropriately accredited CAs will be included in the ehco community s store of trust anchors. With more advanced interoperability testing and evaluation, the HISP/HIE sponsored CA will be allowed to cross certify with an ehco Bridge CA. Cross certification with the Bridge CA will be the basis for extended Direct exchange within the ehco community, with the Commonwealth and Federal health agencies, and health providers in other states. The requirements that establish interoperability are the primary topic in the following section below entitled PKI Model Requirements. 6. The HISPs/HIEs generally only maintain directory information about the individuals enrolled in their services. They are not expected to maintain a master directory of all health providers or services. However, Direct was established to support an exchange of information between individual health providers. This requires that individual providers have some mechanism to identify peers and obtain their respective address information. The requirements for that mechanism are identified in the section below entitled Directory Services Requirements. 7. Some health resources will be consolidated and otherwise made available as a Community Shared Service (CSS). However, it is not ehco s intention to consolidate and maintain user databases for the health providers that need access to those services. Instead, ehco intends to rely upon the credentials and access control procedures of the various HISPs/HIEs to limit access to CSS resources. The requirements for the services to accomplish this are described in the section below entitled Federation Requirements. 4

5 A. PKI Model Requirements ehco seeks hardware, software, and services to implement a PKI that supports Direct and other HIEs in its community. ehco intends to implement a phased approach whereby participating HISPs/HIEs include in their stores of trust anchors the self-signed root certificates of a qualifying CA. As technical interoperability is established, reliance upon distributed root certificates will be replaced with a program of cross-certification with an ehco Bridge CA. Below are the requirements for the implementation of the anticipated certification program, as well as the operation of the needed CA services. Policy Requirements (Functional) A-1. Acquire and maintain a Certificate Policy (CP) for entities participating in the trust ecosystem established by the Pennsylvania ehco. A-1.1. A-1.2. A-1.3. Generally conform to the requirements of the current released version of the DirectTrust.org Certificate Policy 1 supporting the Direct exchange. Support the various CAs that issue certificates to the end entities and are operated by independent parties. Support multiple classes of certificates including: Organizational and individual certificates that may be bound to Direct addresses; Organizational certificates issued to servers and services to support a secure web services environment; and Other certificates as required by ehco use cases. Assessment Framework and Standards Requirements (Functional) A-2. Acquire or develop an assessment framework to determine whether the certification practices of HISP/HIE sponsored CAs meet or exceed the requirements of the ehco CP. A-2.1. A-2.2. A-2.3. The framework must include, at a minimum, all topics detailed in the Federal Bridge CA mapping 2 matrix or alternatively the FedPKI Common Policy Working Group Mapping Comparison Matrix 3. The assessment framework must consider the security context in which key pairs are generated and private keys are stored and used. In particular, in the Direct full service HISP models, subscriber private keys are maintained on behalf of individuals by a HISP/HIE. In such models, the security policy of the HISP is relevant to the assurances provided by a given certificate. The assessment framework must consider the effect of any compensating controls implemented by the HISP/HIE to address gaps in the sponsored CA s practices

6 A-3. Acquire or develop the technical criteria necessary to determine the conformance of the certificates and revocation information with the certificate profiles included in the ehco CP, to include, at a minimum, the appropriate: Distinguished Names (DN), subjectaltname, other certificate identifiers, and key usage fields must be used; Name, policy, and basic constraints; Use of policy indicators and mappings; References to certificate status information; and Use of criticality indicators. A-4. Acquire or develop an assessment standard to implement the framework for use, by: HISPs/HIEs and sponsored CAs for purposes of self-assessment; Third party auditors; and An ehco Policy Authority or other authority to determine the appropriate level of trust to be granted to the certificates issued by the applicant CA, as implemented by the HISP. Evaluation and Initial Accreditation Requirements (Functional) A-5. Apply the above assessment framework to documented certification practices and security policies. A-5.1. A-5.2. Determine, in a written accreditation report, that a sponsored CA s certificates provide the level of assurance required by the ehco policies. Determine that a sponsored CA s certificates conform to ehco standards and may be properly used to support Direct exchanges, as well as other ehco approved purposes. Should the CA s certificates not provide the required level of assurance, identify in a written report the gaps in specific areas that prevent the required assurance. A-5.3. Submit documented findings to the ehco Policy Authority or other authority for approval and archive of findings. Certificate Trust List and Distribution Requirements (Functional) A-6. A-7. A-8. Maintain a repository of the trusted self-signed root and intermediate signer certificates for all the sponsored CAs that are accredited through the processes described in Section A-5. Provide a secure means to distribute the certificates in the repository to the participating HISPs/HIEs. As required by ehco, investigate reports of security incidents to determine if the preliminary accreditation is no longer appropriate. If the accreditation is no longer appropriate, remove the relevant certificates from the repository and take further action to help ensure that those certificates are removed from each of the HISP s/hie s store of trust anchors. 6

7 Development of Certification Practices for ehco CSS-level CA Requirements (Functional) A-9. Develop certification practices for an ehco Bridge and any other ehco CA that may be required. A-10. Document these practices in a Certification Practices Statement (CPS) using an ehco CPS shell 4, and include support as noted below. A Support for intermediate signer/cross certificates to qualified CAs supporting HISPs/HIEs participating in ehco. Minimum certificate profile requirements as noted in the appendix of this document. A There must be certificates to support servers and services that are created and maintained as part of the ehco CSS. Minimum certificate profile requirements are included in this appendix. A Documented practices must include the generation and exportation of appropriate PKCS#10 5 formatted certificate signing requests. A Documented practices must include processes for the receipt and investigation of certificate revocation requests and when appropriate, the updating of certificate status information. A Documented practices must include the receipt of PKI related security incidents or adverse audit reports and their respective investigations. The practices must document how the CA will determine what actions are required to remediate any discovered security flaws and the circumstances under which CA will revoke certificates as part of incident response. A An ehco Policy Authority must approve these practice statements prior to initialization and operation of the ehco Bridge or other CA. CA Initialization and Operations Requirements (Functional) A-11. Implement an ehco subscriber CA. A In accordance with the ehco CP and ehco subscriber CA CPS, generate a key pair in a FIPS level 2 (or more) validated cryptographic hardware security module that includes multiparty (N of M) 6 controls over key signing operations. An audit trail of the key generation procedures must be created with sufficient detail to help ensure that appropriate security and role segregation is maintained. A A Create a self-signed (root) certificate for this CA and distribute it to the HISP/HIE for inclusion into their store of trust anchors. Operate the ehco subscriber CA as required by the aforementioned CPS that will be developed. The requirements for this CA are minimal in the initial phases of ehco s development. It is likely that the CA may operate in an offline mode as it will primarily be issuing certificates to authenticate a small number of services operating as ehco CSS. However, the operational requirements for this CA will increase with additional CSS deployment. 4 This shell CPS follows the conventions of IETF RFC PKCS#10, Certification Request Syntax Specification 6 Multi-level N of M control means that out of a group of M officers, at least N must collaborate in order to complete a given operation. No of M control is a protection against administrative error or malfeasance. 7

8 A-12. Implement an ehco Bridge CA. A In accordance with the ehco CP and Bridge CPS, generate a key pair in a FIPS level 2 (or more) validated cryptographic hardware security module that includes multiparty (N of M) controls over key signing operations. A-13. Issue cross-certificates to accredited CAs. An audit trail of the key generation procedures must be created with sufficient detail to help ensure that appropriate security and role segregation is maintained. A Receive an appropriate audit report that details the conformance of the accredited CA s practices and documented CPS. Under some ehco determined circumstances (e.g., the CA is operated by a HIPAA covered entity) the audit report may be a self-assessment. A Using documented and ehco approved test procedures, complete a technical evaluation of previously accredited CA to include the following: Demonstration of the accredited CA s ability to create intermediate signer/crosscertificates that conform to ehco s policies; Demonstration that the HISP/HIE sponsoring 8 the accredited CA can import the intermediate signer/cross-certificate issued by the accredited CA to the ehco Bridge and appropriately use it to form a certificate validation path; Demonstration that the accredited CA and sponsoring HISP can include the intermediate signer/cross-certificate issued to it by the ehco Bridge CA in the certificate collections that it publishes; and Demonstration that the sponsoring HISP/HIE can appropriately process authority revocation lists when validating certificate chains. A Receive, from the accredited CA, a PKCS#10 certificate signing request accompanied by appropriate verification 9 of its ownership. A Format, sign, and issue an intermediate signer/cross-certificate to the accredited CA that meets the requirements of the attached certificate profile. A Provide the accredited CA with the appropriately formatted PKCS#10 certificate signing request for the CA s use in issuing a cross-certificate to the ehco Bridge. A-14. Maintain the intermediate signer/cross-certificates. A Maintain a repository of intermediate certificates issued to the accredited CAs. A As required by ehco, investigate reports of security incidents or business disruptions to determine if the certification of an accredited CA is no longer appropriate. If the cross certificate is no longer appropriate, include the cross certificate in the Bridge CA s authority revocation list. A Maintain the authority revocation list as required by the ehco CP and Bridge CA CPS A HISP/HIE is said to sponsor a CA, if it acquires, from this CA,certificates for its DIRECT accounts, members or services. 9 Per the CPS for this Bridge CA. 8

9 A-15. Maintain documentation of CA practices and operations sufficient to apply for crosscertification with the Federal Bridge CA and other intermediate authorities. Trust List Technical Requirements A-16. HISP/HIE affiliated CAs need to be able to cache and use multiple trust anchors. Bridge CA Technical Requirements A-17. Hardware Requirements A Hardware to store, protect, and use the ehco Bridge CA s private signer key. A Hardware/software to export PKCS#10. A Hardware and software integration that signs the certificate and publishes the certificate to memory or disk. A Hardware and software integration that signs revocation data. A Disk or other memory type to store copies of certificates issued by ehco CA. A-18. Software Requirements A Software that takes PKCS#10 as input and writes an appropriately formatted certificate body. Capability includes: Ability to write certificates without restriction on name space; Ability to write certificates with the keycertsign and crlsign bit of the KeyUsage extension set to TRUE; Ability to write certificates that include a critical BasicConstraints extension values with the CA bit set to TRUE and pathlenconstraint = 0. A A Software and process that sends the certificate to HISP/HIE affiliated CA. Software that receives revocation request and writes revocation list or other revocation report. 9

10 B. Directory Services Requirements The Lightweight Directory Access Protocol (LDAP) enables advanced lookup services using known attributes regarding a provider or other resources across the trust ecosystem. The purpose of the information presented in this section is to promote the use of Directory Services to enhance queries across the ehco trust ecosystem such that a provider can search for another provider and gain secure access to the appropriate credentials to transport pertinent clinical payloads between both parties. ehco selected Virtual Directory Services (VDS) as its directory service solution. The term provider is defined as an individual or an organization that performs health care services. Schema Requirements (Functional) B-1. Adherence to schema standards specific to promoting health care provider lookup must be considered and include the following: IHE Health Care Provider Directory (HPD) 10 ; ISO/TS Directory Services for Security and Identification of Professionals and Patients 11 ; LDAPv3 12 ; and ASC X (109 Provider Directory) 13. B-2. As part of the basic provider lookup service, the VDS must return the following: Full name; Provider Direct address; and Encryption Certificate [optional] 14. B-3. As part of provider lookup service, the VDS must return all available information related to: B-3.1. B-3.2. B-3.3. B-3.4. Professional certifications, such as physician and specialties; Provider identifiers, such as National Provider Index (NPI), Universal Physician Identification Numbers (UPIN), active/participating Hospital Identification Number; Physical addresses; and Practice affiliations, such as hospitals, medical groups, and health plans Under the Direct Project specification certificates are also published in DNS and maybe through other LDAP resources. 10

11 Identity Repository Requirements (Functional) B-4. The VDS will work with existing identity repositories in their current format as an authoritative source for provider lookup services, such as: B-4.1. B-4.2. B-4.3. LDAPv3 compliant directories; Relational Database Management System (RDMS); and Unstructured file sources (such as spreadsheets). B-5. The VDS will work with identity repositories, including all repositories managed by: B-5.1. B-5.2. B-5.3. B-5.4. HISPs; HIEs; Commonwealth of Pennsylvania shared directories; and External provider lookup services. B-6. The VDS must determine a path to find all HISPs user directories to leverage the investments made by the trust ecosystem to find Direct addresses and corresponding certificates. Abstraction Layer Requirements (Functional) B-7. B-8. The VDS must act as a layer of identity abstraction by aggregating provider identities into one view to support federated access controls across the ehco trust ecosystems. The VDS must support a roadmap to correlate and integrate identities. B-8.1. The VDS must support a hybrid model whereby the CSS can be the authoritative source on the following. Establish a LDAP repository of providers for the Commonwealth; Optimize lookup services; and Correlate provider identities with known Direct addresses and credentials. Example: If ASC X provider lookup is a service offered by the CSS for yellow pages functionality available via health plans, the current model does NOT return an address, but enough information is returned to correlate known providers across the ehco trust ecosystem Administration Requirements (Functional) B-9. The VDS must provide administrative services to centrally administer or administer from anywhere with web access and setup the CSS VDS to: Define the attributes required for a provider; Configure rules in cases where users are found in more than one identity source; Optimize performance of the VDS (such as caching); and Allow for auditing and reporting. 11

12 Hardware and Software Requirements (Technical) B-10. The VDS must support mapping across diverse platforms and protocols, including the following: Windows, Linux, Solaris or other 64 bit platforms; COTS Directory Services such as Microsoft AD, SunOne, Novell edirectory, Oracle Internet Directory, and any LDAPv3 compliant directory services; Database servers, such as Oracle, Microsoft SQL, IBM DB2, and any JDBC/ODBC accessible databases; and Other services, such as Web services. General Availability Requirements (Technical) B-11. VDS must be highly available. B The VDS must address latency through caching or a similar functionality. B When the identity source is down (i.e., at a regional HISP), views must still be partially available. B Queries must be optimized by forwarding them only to relevant identity sources. B Repositories must be appropriately backed up, as needed. 12

13 C. Federation Requirements ehco seeks to control access to information and services available from CSS through the federation with applications and services provided by HISPs and HIEs. ehco seeks to initially employ client certificates with Transport Layer Security (TLS) for federated access control. As federal regulations and standards evolve, as well as technical capabilities and adoption by HISPs/HIEs, this model is expected to transition to expand and include the use of OAuth and SAML. While the use of OAuth and SAML will be initially focused on access controls for a provider lookup service, it is the intent of the CSS to expose additional Web services to the ehco provider community. OAuth is widely used today due to the consumer demand and the convergence of social media sites. On those sites, OAuth is used to allow delegated authorization of credentials from one service to another. Currently, the use of OAuth has not been widely adopted in the HIE/HISP community. The CSS and associated service providers should be required to prove that the concept of such a pairing of standards and protocols will enhance interoperability across the trust ecosystem. The vendor(s) must demonstrate compatibility with a variety of devices that are becoming ubiquitous methods for access applications. Vendors must demonstrate a roadmap to support securing APIs to get an access token as a means of authentication and authorization to the CSS layer services (including, but not limited to, cross domain provider lookup services). General Requirements For Client Certificates (Functional) C-1. Functional requirements are based on the following: C-1.1. Participant authenticates to the HISP/HIE using HISP/HIE-provided login and requests CSS layer service. C-1.2. HISP/HIE requests service on behalf of the Participant. HISP/HIE agent authenticates to the server using the Participant s x.509 certificate in a TLS handshake. C-1.3. The service parses the x.509 to obtain Subject DN and other Subject attributes. C-1.4. The server passes these attributes to a policy server and requests authorization. C-1.5. The policy server authorizes some level of access to application data. C-1.6. The server provides application data to the HISP/HIE. The HISP/HIE decrypts using the TLS negotiated encryption parameters and forwards plaintext to the Participant (most likely over an encrypted channel). General Requirements (Functional) 13

14 C-2. During the implementation of the ehco CSS, identify the specific manner in which SAML and/or OAuth will provide appropriate access controls, taking into account resource-specific ehco access control policy(ies). C-2.1. Perform a risk assessment to help ensure that the proposed access control method is appropriate to the sensitivity of the protected resource and reasonably anticipated threats. C-3. Obtain consensus among ehco participants regarding the OAuth and SAML profiles that will be used to support ehco s access control requirements. C-3.1. These profiles should be consistent with existing health care standards, such as the OASIS Cross enterprise Privacy and Security Authorization 15 and, as appropriate, conform to recommendations of the HHS ONC Health IT advisory committees, specifically the Privacy and Security Policy 16 and Privacy and Security Policy Standards 17 Committees. C-3.2. These profiles should allow for interoperation with other state and Federal initiatives, as specified by ehco. C-4. Provide each HISP and HIE with necessary consulting and software support to implement a SAML Identity Provider. C-4.1. C-4.2. C-4.3. Support ehco s SAML Profile. Include globally unique identifiers (i.e., medical license numbers, UPIN, or DEA number) wherever they are available. Utilize the ehco trust ecosystem to help ensure appropriate security, including mechanisms such as digitally signed assertions. C-5. Implement an Access Control Service for the ehco CSS based on SAML2.0. C-5.1. Conform to ehco access control policy. Provide protection for CSS resources. Control access to patient information and identity, as required by state and Federal laws and regulations. C-5.2. C-5.3. Makes use of HISP and HIE identity providers. Support multiple CSS resources. C-6. Provide each HISP and HIE with necessary consulting and software support to appropriately implement OAuth 2.0 clients, including the following: OAuth handshake; Validation of OAuth tokens, discover, and create API requests; OAuth library support; and Audit logging hi_userid=10741&cached=true 14

15 C-7. For ehco uses cases where application delegation is appropriate, implement a CSS access control service based on OAuth that includes: C-7.1. CSS provisioned authorization and policy servers, including the providing the following: COTS or standards based software for client access to Resource and Authorization Servers hosted or outsourced by the CSS; OAuth Protected Resource Server; and Published SOAP Web service. C-8. Vendor(s) must provide support for the following: Platforms, such as Linux variants, Windows; Browsers, such as HTTP compliant (vendor(s) to stipulate browser for administrative console); Federation, such as SAML 2.0, WS-Federation, WS-Trust, OAuth 2.0; Attribute Sources, such as LDAP; and COTS or standards-based software for client access to Resource and Authorization Servers hosted or outsourced by the CSS. C-9. All software or hardware is required to be minimally disruptive to the current HISP/HIE authentication processes. Roadmap to the Future Securing Application Program Interfaces (Functional) C-10. The OAuth implementation requires the support of multiple client types for access controls to CSS exposed applications. C OAuth implementation must support protocols common to mobile computing devices which access REST APIs. The vendor solution must extend the trust ecosystem to secure the API using REST (for example) to access applications, such as the provider lookup service before allowing such access. Client Certificates (Technical) C-11. Configure proxy and reverse proxy functions on HISP/HIE and ehco CSS technical infrastructure. C-12. TLS supports transmission of a single client certificate. Server must have cached or otherwise access to root or intermediate signer certificates needed to form appropriate certificate chain to trust anchor. C-13. TLS server must parse the certificate to obtain the subscribers Distinguished Name (DN) and other subject attributes that may be in the certificate. C-14. Subscriber attributes need to be mapped to access control information in order to determine the level of authorized access. OAuth Requirements (Technical) C-15. Software required to run the OAuth protocol includes: 15

16 C C Web server; Develop or use existing OpenID server application. C-16. OAuth 2.0 requires all protocol messages to be transferred over HTTPS. C-17. OAuth 2.0 requires the use of URI or XRI to communicate with any of the actors (HISP(s), HIE(s), ehco, ehco Participant). SAML Requirements (Technical) C-18. COTS or Open Source software to support SAML authentication and authorization, as well as: C C C C Other COTS software to support Web services; SOAP to support transport framework; Translation services between transport types: SMTP and SOAP; and Software to assure general availability (e.g., HA, DR, load balancing). C-19. Servers and supporting network infrastructure. 16

17 Appendix: Certificate Profiles The profiles below include minimum capabilities of the required CA. With the approval of ehco, stronger signature and encryption algorithms may be substituted. Various parameters may be changed to conform to ehco CP and CPS. Profile for ehco Bridge CA Certificate (Technical) Field Criticality Value Comment Certificate Version V3 (2) Serial Number INTEGER Unique positive integer Issuer Signature Algorithm sha256withrsaencryption Issuer Distinguished Name Validity Period notbefore notafter Subject Distinguished Name Subject Public Key Information X500 DN YYMMDDHHMMSSZ YYMMDDHHMMSSZ TBD with O=Pennsylvania ehealth Collaborative unless otherwise specified by ehco Validity period should equal 20 years Will match the Issuer DN AlgorithimIdentifier rsaencryption RSA modulus should be at least 2048 bits subjectpublickey Issuer s Signature BIT STRING sha256withrsaencryption Required Extensions subject key identifier subjectinfoaccess accessmethod OCTET STRING id-ad-carepository ( ) 20 byte SHA-256 hash of the binary DER encoding of the subject s public key information Consists of access method and access location pair and only one access method should be defined accesslocation key usage 1 digitalsignature 0 nonrepudiation 0 keyencipherment 0 dataencipherment 0 keyagreement 0 keycertsign 1 crlsign 1 encipheronly 0 decipheronly 0 ldap:// or URI should point to a location where the signer (cross) certificates issued by this Bridge may be found 17

18 Field Criticality Value Comment certificatepolicies PolicyInformation policyidentifier policyqualifier Name Constraints Basic Constraints 1 ca Optional Extensions subject Alternate Name GeneralName Rfc822Name OID TRUE IA5String Must be able to assert a sequence of certificate policies to include the ehco CP and as appropriate the DirectTrust CP Must NOT appear Must NOT appear address of the Bridge Administration s domain component should be paehealthcollab.com unless otherwise specified by ehco Profile for Cross Certificate Issued by the ehco Bridge CA (Technical) Field Criticality Value Comment Certificate Version V3 (2) CROSS CERTIFICATE Serial Number INTEGER Unique positive integer Issuer Signature Algorithm sha256withrsaencryp tion Issuer Distinguished Name DN of the ehco Bridge CA Validity Period notbefore notafter YYMMDDHHMMSSZ YYMMDDHHMMSSZ Subject Distinguished Name Subject Public Key Information CN=Name of GROUP DN of the CA being certified and should be encoded exactly as it is in the issuer field of the certificates written by the CA being certified AlgorithimIdentifier rsaencryption RSA modulus should be at least 2048 bits subjectpublickey Issuer s Signature Required Extensions authority key identifier BIT STRING sha- 1WithRSAEncryption OCTET STRING 20 byte SHA-1 hash of the binary DER encoding of the signing CA s 18

19 Field Criticality Value Comment subject key identifier OCTET STRING 20 byte SHA-1 hash of the binary DER encoding of the subject s public key information subjectinfoaccess accessmethod accesslocation id-ad-carepository ( ) ldap:// or Consists of access method and access location pair and only one access method should be defined. URI should point to a location where the signer (cross) certificates issued by this Bridge may be found key usage 1 digitalsignature 0 nonrepudiation 0 keyencipherment 0 dataencipherment 0 keyagreement 0 keycertsign 1 crlsign 1 encipheronly 0 decipheronly 0 certificatepolicies On more policies may be included policyidentifier OID OID of the relevant ehco policy policyconstraint Should not appear Name Constraints Should not appear in most cross-certificates issued by the ehco bridge and only appear where the CA being certified is an enterprise CA issuing certificates only within its namespace Basic Constraints 1 ca TRUE pathlenconstraint INTEGER Per ehco CP and ehco Bridge CPS this limits the ability to construct chains through other CAs with which the other CA might crosscertify crldistributionpoints ldap:// or Location of CRL distribution point Authority Information Access AccessDescription accessmethod id-ad-ocsp If there is an OCSP responder for this ( ) certificate accesslodation ldap:// or Location of OCSP responder AccessDescription accessmethod id-ad-caissuers Repository of certificates of this type by this ( ) CA accesslodation ldap:// or Location of repository Optional Extensions policymappings This extension will appear in certificates issued to HISP/HIE sponsored CA issuerdomainpolicy OID of the ehco CP or DirectTrust CP, as appropriate certpolicyid OID subjectdomainpoli cy certpolicyid OID of the CP of the to be certified CA 19

20 Profile for Organization Certificates Issued to Identity and Services Providers for the Purpose of Signing SAML Assertions (Technical) Field Criticality Value Comment Certificate Server / Service Version V3 (2) Serial Number INTEGER Unique positive integer Issuer Signature Algorithm sha256withrsaencryption Issuer Distinguished Name Validity Period notbefore notafter Subject Distinguished Name Subject Public Key Information AlgorithimIdentifier subjectpublickey Issuer s Signature Required Extensions authority key identifier subject key identifier X500 DN YYMMDDHHMMSSZ YYMMDDHHMMSSZ CN=[Server /Service URI]. O=Pennsylvania ehealth Collaborative rsaencryption BIT STRING sha256withrsaencryption OCTET STRING OCTET STRING TBD O=Pennsylvania ehealth Collaborative unless otherwise specified by ehco TBD but typically 2 years Server /Service URI and ehco organization name unless otherwise specified by ehco CP and/or CPS RSA modulus should be at least 2048 bits 20 byte SHA-1 hash of the binary DER encoding of the signing CA s public key information 20 byte SHA-1 hash of the binary DER encoding of the subject s public key information key usage 1 digitalsignature 1 nonrepudiation 0 keyencipherment 0 dataencipherment 0 keyagreement 0 keycertsign 0 crlsign 0 encipheronly 0 decipheronly 0 certificatepolicies OID of the relevant ehco policy Issuer Alternate Name Name Constraints Basic Constraints 1 ca 0 extkeyusage serverauth clientauth crldistributionpoints ldap:// or Location of CRL distribution point Authority Information Access AccessDescription accessmethod id-ad-ocsp If there is an OCSP responder for this ( ) certificate accesslodation ldap:// or Location of OCSP responder 20

21 Field Criticality Value Comment AccessDescription accessmethod id-ad-caissuers Repository of certificates of this type ( ) by this CA accesslodation ldap:// or Location of repository Optional Extensions subject Alternate Name GeneralName dnsname IA5String dns name of the server providing the named service 21