SSL Certificates Certificate Policy (CP)

Transcription

1 SSL Certificates Last Revision Date: February 26, 2015 Version 1.0

2 Revisions Version Date Description of changes Author s Name Draft 17 Jan 2011 Initial Release (Draft) Ivo Vitorino Feb 2015 Full review and changed as per procedures. Ivo Vitorino ABB Page 1 26/02/2015

3 1. INTRODUCTION This document constitutes the for Security Sockets Layer (SSL) certificates issued by a Certificate Authority (CA). 1.1 Overview This CP is valid for SSL server authentication certificates issued by the ABB Issuing CA 6 to Web and application servers operated by ABB or on behalf of and authorized by an ABB Group company. 1.2 Document Name and Identification The most recent version of this document and links to related documents can be found at: The latest version of the Certificate Practice Statement (CPS) of ABB Issuing CA 6 can be found at: The name of this document is "ABB SSL Certificates - Certificate Policy". The following Object Identifier (OID) is assigned to this policy: PKI Participants The following Public Key Infrastructure (PKI) participants are involved in certificate management and validation processes: Certification Authorities Registration Authorities Theses certificates are issued by a CA to which a security level of 2 has been assigned; no certificates of other security levels are issued by this CA. Registration Officer The Registration Officer (RO) for SSL certificates visible on the Internet are ABB employee or contractor who is entitled and authorized by the PKI Service Manager to approve SSL server certificate requests at the appropriate CA A RO as described in this section cannot be the same person as a subscriber as described in the following section. The CA's Registration Authority (RA) enforces criteria for certificate attributes in a technical way Subscribers Subscribers are persons with the authorization to enroll for a certificate on behalf of a server. Since this requires adequate local administrator permissions in the operating system of the server, they are also denoted as "Server Administrators" in this CP. A subscriber as defined above cannot be the same person as the RO as described in the previous section Relying Parties Relying parties are users using SSL clients (e.g. HTTPS clients) and applications needing to verify the authenticity of an SSL certificate. These parties are accessing ABB SSL servers either internally via the ABB network or externally via the Internet Other Participants Revocation Officers (RevO) are entitled by the PKI Service Manager. A single person may be entitled as both, Registration and Revocation Officer. Details of the authorization process and the assurance of separation of duties are described in the ABB PKI Governance Framework (an ABB internal document). 1.4 Certificate Usage Certificate usage is defined as follows. ABB Page 2 26/02/2015

4 Appropriate Certificate Uses Prohibited Certificate Uses 1.5 Policy Administration Organization Administering the Document Certificates are used for authentication of servers on the intranet or via the Internet to relying parties and to encrypt session keys. Any other usage is prohibited. This CP is administered by ABB Information Systems Ltd Affolternstrasse 44, CH-8055 Zurich, Switzerland Contact Person Contact for detailed inquiries: Person Determining CPS Suitability for the Policy CPS Approval Procedures The ABB PKI Service Manager is determining the suitability of this CP. This CP document is approved by the PKI Board. To manage and control the generation of CPs, building blocks are maintained in tabular format. 1.6 Definitions and Acronyms 2. PUBLICATION AND REPOSITORY RESPONSIBILITIES This CP is reviewed by the PKI Service Manager on annual basis. The following acronyms are used in this document: - AIA: Authority Information Access (Repository for CA certificates) - Base64: Cert. encoding, positional notation using a base of 64 - CA: Certification Authority - CDP: CRL Distribution Point - CN: Common Name - CP: Certificate Policy - CPS: Certificate Practice Statement - CRL: Certificate Revocation List - CSP: Cryptographic Service Provider - DER: Distinguished encoding rules, cert. encoding using digital signatures. - DN: Distinguished Name - DNS: Domain Name System - HTTP: Hypertext Protocol - HTTPS: Hypertext Protocol with SSL - LDAP: Lightweight Directory Access Protocol - OCSP: Online Certificate Status Protocol - OID: Object Identifier - PKCS: Public Key Cryptography Standards - PKI: Public Key Infrastructure - RA: Registration Authority - RevO: Revocation Officer - RO: Registration Officer - SSL: Secure Sockets Layer - URL: Uniform Resource Locator The repositories as described below are used to publish different types of signed information. ABB Page 3 26/02/2015

5 2.1 Repositories 2.2 Publication of Certification Information All SSL certificates are published to the CA database accessible to ROs. Publicly available HTTP and LDAP sites operated by ABB are used to public CA certificates and revocation lists: CRLs: file name> ldap://crl.pki.abb.com/cn=<ca-specific object>,cn=cdp,cn=pki CA Certificates: file name> ldap://aia.pki.abb.com/cn=<ca-specific object>,cn=cdp,cn=pki These links are also embedded in each certificate. Repositories operated by ABB are used to publish this CP. A link to this document can be found in the overview section of this document. 2.3 Time or Frequency of Publication SSL certificates are published immediately after the SSL certificate has been issued or renewed. 2.4 Access Controls on Repositories 3. IDENTIFICATION AND AUTHENTICATION The HTTP and LDAP repository are available to anonymous Internet users and internal ABB users. Identification and authentication requirements are as described in the following sections. 3.1 Naming Naming details are as defined below Types of Names SSL server distinguished name (DN) consists of the following mandatory components: - Common name (CN): Fully Qualified Domain Name (FQDN), as used by end users. The domain has to be one of the domains registered by ABB (checked and approved by the RO). - Organization: ABB or ABB Information Systems Ltd. - Location: Zurich or Baden - Country: CH Need for Names to Be Meaningful Anonymity or Pseudonymity of Subscribers Rules for Interpreting Various Name Forms Uniqueness of Names SSL server distinguished names and the business justification for the respective certificates must be validated on a regular basis, at least on renewal of the certificates. SSL server names must correspond to existing FQDNs. Subscribers have to be non-anonymous Server Administrators, known by their name. This has to be adequately verified by the RO. CNs has to follow DNS standards. CN and DNS names must be unique on the network. Exceptions must be approved by the PKI Service Manager. Note: A single certificate with a unique CN may need to be used on multiple physical servers in a load-balancing environment. ABB Page 4 26/02/2015

6 3.1.6 Recognition, Authentication, and Role of Trademarks 3.2 Initial Identity Validation Method to Prove Possession of Private Key Authentication of Organization Identity Authentication of Individual Identity Non-verified Subscriber Information Validation of Authority Criteria for Interoperation 3.3 Identification and Authentication for Re-Key Requests 3.4 Identification and Authentication for Revocation Request 4. CERTIFICATE LIFE- CYCLE OPERATIONAL REQUIREMENTS 4.1 Certificate Application Who Can Submit a Certificate Application Enrollment Process and Responsibilities 4.2 Certificate Application Processing Time to Process Certificate Applications 4.3 Certificate Issuance Only domains managed by ABB must be used in CNs. Server Administrators have to present a valid DNS record. Web Server Administrators supply a request in a PKI software. The name in the request is checked by the RO. The certificate request must be submitted in PKCS#10 format. Permission has to be sought from Corp. Communications (operated by Group IS). No stipulation. All information provided by the subscriber is verified by an RO. No stipulation. Requests have to be submitted in PKCS#10 format, certificates are provided in DER, Base64, and p7b or p7c format. Same requirements as for initial enrollment. Revocation requires authorization as a member of a Revocation Officers group. Revocation requests are validated and decided upon by the respective Revocation Officer, taking reasonable factors for revocation into consideration. The enrollment for SSL certificates involves manual steps that depend on the software implementation on the server system. In general, this includes: 1. A Server Administrator determines the business need for a server certificate and creates a certificate request. 2. The RO assures formal correctness, adequately validates the request and approves it when all requirements are met. 4. Upon approval, the CA issues the certificate based on the certificate request. 5. The RO retrieves the certificate from the CA and forwards it to the requesting Server Administrator. 6. The Server Administrator installs the certificate on the server. 7. The SSL certificate is ready to be used. Certificate applications are submitted by the administrator of the server and forwarded to the CA by a RO upon approval. Server Administrators are responsible to create the private key in a secure hardware or software location at the server. Certificate applications are checked manually by ROs for compliance with this CP. Server Administrators are informed within 10 business days if their request has either been approved or rejected. ABB Page 5 26/02/2015

7 4.3.1 CA Actions During Certificate Issuance Notification to Subscriber by the CA of Issuance of Certificate 4.4 Certificate Acceptance Conduct Constituting Certificate Acceptance Publication of the Certificate by the CA Notification of Certificate Issuance by the CA to Other Entities 4.5 Key Pair and Certificate Usage Subscriber Private Key and Certificate Usage Relying Party Public Key and Certificate Usage 4.6 Certificate Renewal Circumstance for Certificate Renewal Who May Request Renewal Processing Certificate Renewal Requests Certificate policies are defined at the CA, which are compliant with this CP. Server Administrators are informed by if a certificate request is approved or rejected and if the certificate is going to expire or if it has been revoked. Server Administrators are provided with an attached with the issued certificate. Certificates have to be installed manually at the server. The Server Administrator accepts a certificate by installing it on the server manually. SSL certificates are not published to any publicly available repositories. No stipulation. Keys must only be used for server authentication purposes at the machine which has been used to generate the request. Export of private keys to other machines is prohibited except for the purpose of securing multiple systems sharing the same DNS name in load-balanced installations. Relying parties must not accept these certificates for any other purpose than indicated in this CP, even if applications would permit usage in a technical sense. Certificates are always renewed with a new key. Renewal of SSL certificates is not different from a new request. Server Administrators may request renewal. Renewal requests are processed in the same way as initial requests. 4.7 Certificate Re-Key Every renewal constitutes re-keying. 4.8 Certificate Modification Circumstance for Certificate Modification Who May Request Certificate Modification Processing Certificate Modification Requests 4.9 Certificate Revocation and Suspension Server certificates have to be replaced if the DNS name of the server is changed. Certificate modification can be requested by the Server Administrator or by a DNS administrator (Network Operations Management). Modification requests can be generated in an automated manner. Since modification requests are approved by the same entities as initial requests, they are processed in the same way. ABB Page 6 26/02/2015

8 4.9.1 Circumstances for Revocation Who Can Request Revocation Procedure for Revocation Request Time within which CA Must Process the Revocation Request Revocation Checking Requirement for Relying Parties CRL Issuance Frequency (If Applicable) Maximum Latency for CRLs (If Applicable) On-line Revocation/Status Checking Availability Special Requirements Re-Key Compromise Circumstances for Suspension 4.10 Certificate Status Services Server certificates are revoked, - when the corresponding service or application is terminated. - when the private key is not available any more on the machine, e.g. due to deletion of the profile or a hardware crash of the machine. - when servers are stolen. - when there is indication that private keys are misused or compromised. SSL certificates are never suspended. Requests can be made by: - ABB InfoSec (compromise) - Server Administrator (deleted profiles, hardware failures) - Infrastructure Operations, Corporate Communications (DNS name issues) - Respective service or application owner Requests to be sent by to Revocation Officers who are going to submit the revocation request to the CA. Revocation Officers must process the request within one business day. The CA processes the request and immediately creates and publishes a new CRL. Relying parties have to check the revocation status by evaluation a valid CRL provided at the publication point(s) listed in the certificate. CRLs are issued every 48 hours with an overlap / grace period of 24 hours. The maximum latency of CRL publication to the repositories operated by ABB is about 5 minutes. Online Certificate Status Protocol (OCSP) is available. The end identity certificates include the OCSP URL repository under AIA property. Revocation requests have to be processed within 12 working hours within business days by the Revocation Officer. Certificates for SSL servers are never suspended. Certificate status can be checked using standard path validation and revocation checking mechanisms. There are no other tools available End of Subscription Subscription ends when the server (in terms of physical machine and/or application) is not available any longer. If the certificate has to be revoked for any reason but the server / application this is not considered end of subscription as long as the server is provided with a replacement certificate Key Escrow and Recovery 5. FACILITY, MANAGEMENT, AND OPERATIONAL CONTROLS (11) SSL keys are not escrowed by the CA and cannot be recovered. 5.1 Physical Controls SSL servers must be physically protected in accordance with the applicable provisions in the ABB Information Security Handbook. 5.2 Procedural Controls Server Administrators cannot directly submit requests to the CA. The request is validated and approved by ROs. ABB Page 7 26/02/2015

9 5.3 Personnel Controls SSL servers have to be administered by trained and trusted personnel. 5.4 Audit Logging Procedures Audit logging is performed according to best practices in order to provide seamless and transparent operations of PKI services for SSL certificate subscribers and to detect events which would trigger certificate revocation. 5.5 Records Archival Records archival are performed in accordance with the applicable provisions in the ABB Information Security Handbook. 5.6 Key Changeover New CA public keys are published to the Authority Information Access (AIA) locations listed in the SSL certificates. 5.7 Compromise and Disaster Recovery Incident and Compromise Handling Procedures Computing Resources, Software, and/or Data Are Corrupted Entity Private Key Compromise Procedures Business Continuity Capabilities after a Disaster 6. TECHNICAL SECURITY CONTROLS 6.1 Key Pair Generation and Installation Suspected key compromise may be indicated by the Server Administrator or any holder of a trusted PKI role. Standard ABB incident response procedures apply for the investigation and handling. If an SSL certificate becomes unusable due to corruption, it is revoked with reason code "Cessation of Operation" and a replacement certificate is issued to this server. The Server Administrator is responsible for indicating corruption to PKI operations. If an SSL server private key is suspected to have been compromised, it is revoked with reason code "Key Compromise" and a replacement certificate must be requested and issued to this server. A security incident is triggered in order to investigate the compromise. SSL certificates and keys may be backed up and restored as part of the operating system, according to standard server backup and restore procedures Key Pair Generation The private key is generated in software or hardware security modules at the server using all required security precautions set forth by the ABB Information Security Handbook and as recommended by the particular software and/or hardware vendor. If software key stores are used the key has to be protected by encryption, following vendor recommendations for key protection Private Key Delivery to Subscriber Public Key Delivery to Certificate Issuer CA Public Key Delivery to Relying Parties The private key is generated on the server. Only for load-balanced Web servers or other solutions which required the same key to be available on multiple different machines may the private key be exported and delivered to other machines via password-protected files (PFX, PSE, and PKCS #12). The public key is delivered to the issuer as part of a DER, Base64, p7b or p7c encoded certificate request via . Server Administrators do not have direct access to the CA. Issuing CA certificates are available at AIA HTTP and LDAP sites indicated in SSL certificates. The PKI Service Manager may be contacted to provide out-of-band confirmation of the hash value Key Sizes SSL server keys shall be 2048 bits long. The minimum length is 2048 bits. ABB Page 8 26/02/2015

10 6.1.6 Public Key Parameters Generation and Quality Checking Key Usage Purposes (as per X.509 v3 Key Usage Field) 6.2 Private Key Protection and Cryptographic Module Engineering Controls 6.3 Other Aspects of Key Pair Management Keys shall be generated by software or hardware cryptographic service providers using well-known using the RSA algorithms. Digital Signature, Non-Repudiation, Key Encipherment, Data Encipherment. Hardware modules may be chosen by server administrators, but software modules may be used by default. Cryptographic Service Provider (CSP) and Key Storage Provider (KSP) has to be capable of handling 2048-bit keys. Hardware and software modules shall be common industry products or must be approved by the PKI Service Manager. Private keys must not be exportable, except temporarily for the use of the same key and certificate on multiple physical systems in load-balance environments. 6.4 Activation Data No activation data (PIN) are required to use the private key. 6.5 Computer Security Controls 6.6 Life Cycle Technical Controls 7. CERTIFICATE, CRL, AND OCSP PROFILES Servers have to be protected by adequate physical and logical controls. Server must only be operated by authorized personnel. SSL certificates must only be used on systems which are owned by or operated under authorized control of ABB. Server administrators are responsible for keeping the system compliant with ABB's Information Security Handbook. 7.1 Certificate Profile SSL certificates are compliant with the X.509 version 3 standard Version Number(s) The certificate version number is 'v3' Certificate Extensions Algorithm Object Identifiers The following certificate extensions are used: - Netscape Cert Type - Authority Information Access: Two Alternative URLs and one for OCSP - Certificate Policies Extensions: OID, URL - Enhanced Key Usage - Authority Key Identifier - CRL Distribution Point: Two alternative URLs - Subject Key Identifier - Basic Constraints (Critical) - Key Usage (Critical) No stipulation Name Forms Subject Name: X Name Constraints The CN components has to comply with an existing DNS record (see also 3.1, Naming) Certificate Policy Object Identifier Usage of Policy Constraints Extension Policy OIDs are built according to ABB OID naming convention. Please use the address given in the contacts section (1.5.2) to seek more detailed information. The CP OID is given in section 1.2. Standard CRLs are published to CDPs referenced in SSL certificates. 7.2 CRL Profile Standard CRLs are published to CDPs referenced in SSL certificates Version Number(s) CRL are compliant with the X.509 version 2 standard. ABB Page 9 26/02/2015

11 7.2.2 CRL and CRL Entry Extensions 7.3 OCSP Profile Reserved for future use. 8. COMPLIANCE AUDIT AND OTHER ASSESSMENTS 9. OTHER BUSINESS AND LEGAL MATTERS The following non-mandatory CRL extensions are used: - Authority Key Identifier Issuer Distribution Points are not used. Server Administrators and Web servers may be audited to check for compliance with this CP. ABB warrants that the person designated to act on behalf of ABB is duly authorized by ABB to act on behalf of ABB. This warranty is exclusive and in lieu of all other warranties, whether express, implied or statutory. Notwithstanding anything stated in this document, related documents or agreements to the contrary any other warranties and/or remedies and/or liability of ABB than expressly stated in this clause with regard to the authorization of persons acting on behalf of ABB or the use of or reliance on this certificate shall be excluded. In no event shall ABB be liable for any direct, indirect, incidental, special or consequential damages, including without limitation to damages for loss of profits, data or use, incurred by the persons or any third party acting on behalf of ABB or resulting from the use of or reliance on this certificate, whether based on contract, tort, under statute, in equity, at law, or otherwise, even if ABB has been advised of the possibility of such damages. 10. AMENDMENTS Any change of this CP is subject to approval by the PKI Service Manager. ABB publishes this CP on the HTTP location given in the Overview section. The certificate service provider and service owners of PKI enabled services are notified on changes per immediately. Changed versions include indications of all changes made. The OID must be changed if a different security level is assigned to certificates. Any other OID change would be considered creating a new policy for a new type of certificate. ABB Page 10 26/02/2015