Version 1.0 Effective Date: Copyright 2013 All rights reserved.

Transcription

1 SITHS Registration Authority Policy Version 1.0 Effective Date: Copyright 2013 All rights reserved.

2 Copyright Notices No part of this publication may be reproduced, stored in or introduced into a retrieval system, or transmitted, in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), without prior written permission of Inera AB. Notwithstanding the above, permission is granted to reproduce and distribute this Registration Authority Policy on a nonexclusive, royalty-free basis, provided that: 1. The foregoing copyright notice and the beginning paragraphs are prominently displayed at the beginning of each copy. 2. This document is accurately reproduced in full, complete with attribution of the document to Inera AB. Requests for any other permission to reproduce this Registration Authority Policy (as well as requests for copies from Inera AB) must be addressed to: Inera AB Box ,, Sweden Attention: SITHS Policy Authority Or: sithspolicyauthority@inera.se Page 2/31

3 Table of contents 1 Introduction Overview Document name and identification PKI participants applicable for the SITHS RA policy Certification authority (CA) Registration authorities (RA) RA obligations Certificates issued by SITHS RAs HCC Person HCC Function Applicability Policy administration Organization administering the document Terms and obligations Obligations RA obligations in relation to CAs Protection of RA private keys Restrictions concerning use of RA private keys RA obligations in relation to xras Subscriber obligations Relying party obligations Rules and routines that shall be part of RAPS Responsibilities RA responsibilities within its operating boundaries RA responsibility disclaimers Financial responsibilities Governing law Fees Compliance audit and other assessments Page 3/31

4 2.7 Confidentiality Intellectual property rights Terms and agreements Agreement with the SITHS Policy Authority Agreement with the organization that RAs belong to Identification and authentication Requirements for physical presence Authentication of functions within organizations Authentication of authorized representative Requests for certificate revocation Operational requirements Certificate application Circumstances for application Who can submit a certificate application? Enrollment process and responsibilities End entity certificate subscribers Certificate Application Processing Performing identification and authentication functions Approval or rejection of certificate applications Time to process certificate applications Certificate issuance CA Actions during certificate issuance Notifications to subscriber by the CA of issuance of certificate Certificate acceptance Conduct constituting certificate acceptance Publication of the certificate by the CA Notification of certificate issuance by the CA to other entities Certificate revokation Circumstances for revocation Who can submit a revocation request Procedure for revocation request Revocation request grace period Page 4/31

5 4.6 Smart card applications Records archival Compromise and disaster recovery RA termination Facility, management, and operational controls Physical controls Procedural controls Personnel controls Qualifications, experience, and clearance requirements Background check procedures Training requirements Retraining frequency requirements Job rotation frequency and sequence Sanctions for unauthorized actions Independent contractor requirements Documentation supplied to personnel Technical security controls Private Key delivery to subscribers Private key protection and cryptographic module engineering controls Private key archival Computer security controls Specific computer security technical requirements Computer security rating Compliance audit and other assessments of RAs Referenced documents Appendix A. Table of acronyms and definitions Acronyms Definitions Version history Version Author Comment 1.0 Conny Balazs Approved by SITHS Policy Authority Page 5/31

6 1 Introduction This document is the principal statement of policy governing SITHS RAs procedures and routines. The SITHS Certificate Policy (CP) sets forth the business, legal, and technical requirements for approving, issuing, managing, using, revoking, and renewing, digital certificates within SITHS and providing associated trust services for all participants within SITHS. These requirements protect the security and integrity of SITHS and comprise a single set of rules that apply consistently across SITHS, thereby providing assurances of uniform trust throughout SITHS. The CP is not a legal agreement between Inera AB and organizations with a SITHS membship; rather, contractual obligations between Inera AB and SITHS participants are established by means of agreements with such participants. This Registration Authority Policy (RAP) is governed by the SITHS CP and all its stipulations. No RA operations within SITHS shall conflict with the regulations of the SITHS CP. Also, all RAs are obligated to ensure that sufficient, monetary and personell, resources are allocated in order to meet the requirements of this RAP and fulfill all its obligations. This document is targeted at: SITHS RAs who have to operate in terms of their own Registration Authority Practices Statement (RAPS) that complies with the requirements laid down by the RAP. SITHS certificate subscribers who need to understand how they are authenticated and what their obligations are as SITHS subscribers and how they are protected under SITHS. Relying parties who need to understand how much trust to place in a SITHS certificate, or a digital signature using a SITHS certificate. This RAP conforms to the Internet Engineering Task Force (IETF): RFC 2119 Key words for use in RFCs to Indicate Requirement Levels. This RAP is owned and maintained by the SITHS Policy Authority. Page 6/31

7 1.1 Overview An overview of the SITHS policy structure is shown in diagram 1 below. At the top of the hierarchy is the SITHS Policy Authority that owns and maintains and sets out the policies under which SITHS participants must comply with. Diagram 1 SITHS policy structure Certification Authorities operate under the SITHS CP, issuing certificates. Registration Authorities (RAs) are entities that authenticate certificate requests within SITHS. Inera AB and organizations that are members of SITHS can act as RAs for certificates they issue. Depending on the type of certificate, digital certificates may be used by subscribers in a wide set of services, for example: Secure communication to/from websites Digitally sign code or other content Digitally sign documents and/or s The person who ultimately receives a signed document or communication, or accesses a secured website is referred to as a relying party, i.e., he/she is relying on the certificate and has to make a decision on whether to trust it or not. A relying party must rely on a certificate in terms if the relevant relying party agreement included in the certificate. Page 7/31

8 This RAP describes the procedures and routines that are applied when issuing certificates within SITHS for: Physical persons Functions/services Within SITHS, certificates are issued according to different certificate profiles that govern certificate contents and possible subscribers, these profiles are labeled as HCC. RAs that operate within SITHS must adhere to the SITHS Registration Authority Policy and publish a Registration Authority Practice Statement (RAPS) that is approved by the SITHS Policy Authority. An RA without approved RAPS will not become a part of SITHS. 1.2 Document name and identification This document is the SITHS Registration Authority Policy (RAP). The SITHS Policy Authority, acting as the policy defining authority, has assigned an object identifier for this RAP. The object identifier for this RAP is: Page 8/31

9 1.3 PKI participants applicable for the SITHS RA policy Certification authority (CA) The term Certification Authority (CA) is an umbrella term that refers to all entities authorized to issue public key certificates within SITHS. The CA term encompasses two subcategories of issuers: Root Certification Authorities. The SITHS Root CA acts as root for all subordinate CAs that are part of the SITHS CA hierarchy. A Root CA within SITHS only issue subordinate CA certificates. Subordinate issuing Certification Authorities. The set of SITHS Subordinate Issuing CAs issue end entity certificates based on the approved certificate profiles governed by the SITHS Policy Authority. Each CA that is part of the SITHS PKI must publish a CPS that is approved by the SITHS Policy Authority. Each CPS must also contain a referece to the SITHS Certificate Policy. Each CA is responsible for maintaining sufficient resources in the form of monetary means and insurances to be able to fullfill its duties according to the SITHS Certificate Policy. The SITHS Policy Authority prohibits CAs from SITHS that cannot meet this requirement. Inera AB must have a valid and signed agreement with each organization that certficates are issued to. Each agreement must refer to the SITHS Certificate Policy Registration authorities (RA) A Registration Authority is an entity that performs identification and authentication of certificate applicants for end entity certificates, initiates or passes along revocation requests for certificates for end-entity certificates, and approves applications for renewal or re-keying certificates on behalf of a CA. Inera AB and SITHS member organizations may act as RAs. Each RA must operate in accordance with the SITHS RA Policy and have a RAPS published and approved by the SITHS Policy Authority. The RAPS of an RA shall describe the RA organization, its procedures and routines for implementing the SITHS RAP. Each RA within SITHS shall operate under its own distinct RAPS. Each RA is accountable for that all stipulations of the SITHS RA Policy are fulfilled RA obligations Certificates issued by SITHS RAs RAs within SITHS issues and revokes certificates for the following types of subscribers: Subject type Certifikate profile Certifikate type Person HCC Person Secondary certificate* System or service HCC Function Primary certificate** All attributes contained within certificates issued by RAs within SITHS must be verified in accordance with the SITHS Certificate Policy. Certificate attributes are specified in the SITHS Certificate Policy and the SITHS HCC certificate profiles. Page 9/31

10 HCC Person HCC Person is only issued to physical persons that: 1. Can prove a unique identity whos attributes can be controlled and verified by a trusted third party. 2. Is an employee of, or by a formal agreement is connected to, a SITHS member organization. All attributes of HCC Person issued under the SITHS Certificate Policy must be controlled and verified by a trusted third party. Trusted third parties include the following entities: The Swedish tax authority The HSA directory HCC Person is issued as secondary certificates, by connection to a primary certificate. Primary certificates must only be issued by a CA that is trusted, validated and approved by the SITHS Policy Authority. For HCC Person primary certificates are issued by: Telia e-legitimation EU HW CA v1 o SHA1 thumbprint = 07 cb 51 6e bf a5 e2 7e b3 1f a1 9d Telia Enterprise CA v2 o SHA1 thumbprint = 5a 43 0d 1e df da 3a c2 bc ca e5 88 a0 81 0d c3 c8 ad 61 aa Telia Enterprise CA v3 o SHA1 thumbprint = 34 f4 df c8 bf fd ed f2 5e c2 4d 5b db e5 Telia Card Identifier CA v2 o SHA1 thumbprint = 6e a aa c ac a7 8b 28 7e 24 f1 d8 ee ed 09 5c These CAs also issue cryptographic modules, where the private key is stored and protected. This means that no separate keys are generated for HCC Person in accordance with the SITHS Certificate Policy. The distinguishing factor for HCC Person is that the subject contains the name, which is strongly connected to an organization by means of HSAId***. The HSAId for a person is derived from the HSAId-series of the organization hosting the person in question within the HSA directory. * - Secondary certificates are issued to a subscriber based on a previously issued primary certificate along with associated assymetric keys. The SITHS Policy Authority approves trusted issuers of primary certificates that can be be tied to secondary certificates. ** - Primary certificates are issued to subscribers along with assymetric keys and are not dependent on previously issued certificates. *** - The HSAId is the unique identifier used within the HSA directory for every object within the directory. Page 10/31

11 HCC Function HCC Function is only issued to named functions or services that can be: 1. An organizational function 2. A technical service or funtion within an organization A HCC Function is never issued to a physical person. A function or service in this context is always subordinate to an organization. All organizations that apply for HCC Function under the SITHS Certificate Policy must be controlled and verified by a trusted third party. Trusted third parties include the following entities: The Swedish companies registrations office The HSA directory Swedish public organizations that are not registered with the Swedish companies registrations office are verified by a combination of: A formal signature from an individual that is authorized to sign agreements for the organization Verifying that the individual is listed in the organizations list of individuals that are authorized to sign for the organization, this is verified by contacting the administrative management of the organization. HCC Function is issued as primary certificates. Before issuance a key pair is generated in accordance with section 6.1 in the SITHS Certificate Policy. The distinguishing factor for HCC Function is that the subject contains the name of a funtion, which is strongly connected to an organization by means of HSAId, but does not contain any information about any physical person. The HSAId for a function is derived from the HSAId-series of the organization hosting the function in question within the HSA directory. 1.4 Applicability This RAP is relevant for: CAs that operate within SITHS RAs approved by the SITHS Policy Authority ORAs appointed by SITHS RAs LRAs appointed by SITHS RAs CRAs appointed by SITHS RAs Auditors Relying parties Subscribers Contracted vendors and/or suppliers of system components for any part of the technical SITHS infrastructure Page 11/31

12 1.5 Policy administration Organization administering the document This RAP is administered by the SITHS Policy Authority that can be reached on the following address: Inera AB Box ,, Sweden The SITHS Policy Authority can also be contacted by on the following address: Approvals of this RAP and instances of RAPS are managed according to the SITHS Certificate Policy. Page 12/31

13 2 Terms and obligations 2.1 Obligations RA obligations in relation to CAs RAs in accordance with this RAP must: 1. Operate within the obligations stipulated by the SITHS Certificate Policy 2. Conduct audits in accordance with the SITHS Certificate Policy and the SITHS Registration Authority Policy stipulations for internal and external audits 3. Conduct subject identification in accordance with the SITHS Certificate Policy 4. Revoke certificates in accordance with the SITHS Certificate Policy 5. Gather and verify information that are part of certificates 6. Request certificates from the appropriate CA 7. Deliver private keys to the subscriber when applicable in accordance with the SITHS Certificate Policy 8. Archive information in accordance with the SITHS Certificate Policy and this RAP 9. Verify that certificates only contain information as regulated by the SITHS certificate profiles 10. Ensure that rules for certificate applications are enforced as specified in the SITHS Certificate Policy 11. Meet operational requirements as specified by the SITHS Certificate Policy Protection of RA private keys RA private keys are stored on smart cards protected by PIN-codes. Each RA is obligated to protect its smart card and PIN-codes in accordance with the SITHS Certificate Policy and the associated assurance level(s) that SITHS implements Restrictions concerning use of RA private keys Each RA is bound by an agreement with every CA it interfaces with, by means the SITHS Certificate Policy. This regulates the use of private keys described in the SITHS Certificate Policy RA obligations in relation to xras RAs in accordance with this RAP must: 1. Establish and follow routines for xras, in accordance with the requirements specified in the SITHS Certificate Policy 2. Designate xras within the RA operating boundary. RAs can also delegate designation of CRAs and LRAs to appointed ORAs as needed. ORAs shall always be appointed by RAs. 3. Renew and revoke xras as needed. 4. Ensure that xras have adequate qualifications and time allocated for xra operations. Page 13/31

14 5. Conduct personell controls of xras, Each RA must have approval by the SITHS Policy Auhtority regarding the actual controls that are used. The SITHS Policy Authority will not accept unauthorized controls Subscriber obligations Subscriber obligations are stipulated by the SITHS Certificate Policy Relying party obligations Relying party obligations are stipulated by the SITHS Certificate Policy Rules and routines that shall be part of RAPS The following rules and routines shall be documented and goverened for each RA by means of its RAPS. Note that each RAPS within SITHS must be approved by the SITHS Policy Authority before an RA is allowed to operate within SITHS. 1. Routines for issuance and subscriber acceptance of certificates, including temporary replacement smart cards and associated certificates 2. Backup routines for PIN codes associated with HCC Function certificates 3. Rules for verification of subscriber information 4. Rules and routines for information management, quality and history within the HSA directory in relation to the entity that is responsible for the enforcement of the HSA Policy. 5. Background checks of xras 6. Archiving of information according to the stipulations of the SITHS Certificate Policy 7. Internal compliance audits in accordance with the SITHS Certificate Policy 8. Local disaster recovery plans 2.2 Responsibilities RA responsibilities within its operating boundaries RAs are responsible for the following within its operating boundaries: 1. That the requirements and specifications of the SITHS Certificate Policy are fulfilled 2. That the requirements and specifications of the SITHS Registration Authority Policy are fulfilled 3. That xras are available to sufficient extent to allow local knowledge of the persons that act as subscribers within the local RA operational boundary 4. That sufficient economic resources are available for issuance of SITHS certificates 5. That all information security requirements that apply to RA operations within the SITHS Certificate Policy are fulfilled 6. That periodic controls and audits are conducted, regarding proper issuance and usage of issued SITHS certificates Page 14/31

15 7. That archiving is conducted in accordance with the SITHS Certificate Policy 8. That all information within issued certificates are verified and correct in accordance with the SITHS Certificate Policy RA responsibility disclaimers RAs are not responsible for consequenses or damage due to: 1. That keys are used in violation to the SITHS Certificate Policy 2. That keys are changed in violation to the SITHS Certificate Policy 3. That subscribers use certificates in violation to the SITHS Certificate Policy 4. Errors caused by CAs 5. Errors caused by other RAs 2.3 Financial responsibilities No stipulations. 2.4 Governing law Subject to any limits appearing in applicable law, the laws of Sweden shall govern the enforceability, construction, interpretation, and validity of this RAP. 2.5 Fees No stipulations. 2.6 Compliance audit and other assessments RAs shall continuously conduct audit reviews in order to make sure that this RAP is correctly implemented. Such audits shall at least occur once on a yearly basis or when suspicios activities are detected within a RA operating boundary. When flaws or a need for change in the local implementation of the RAP arise, RAs shall take appropriate action in order to remediate such situations by changing routines and or initiate changes to this RAP. Changes to this RAP are managed by the SITHS Policy Authority. If changes to this RAP affect the security level of SITHS RA operations, a new policy with a new OID is to be established to reflect this change in security level. 2.7 Confidentiality Confidentiality concerning information for subscribers that are physical persons is stipulated by the following Swedish laws: Personuppgiftslagen Sekretesslagen All RA operations must meet the requirements of Swedish law and the stipulations within the SITHS Certificate Policy. Page 15/31

16 2.8 Intellectual property rights The allocation of intellectual property rights among SITHS participants other than subscribers and relying parties shall be governed by the applicable agreements between such SITHS participants. 2.9 Terms and agreements Agreement with the SITHS Policy Authority All RAs operating within SITHS shall sign a formal agreement, in the form of a SITHS membership agreement, with the SITHS Policy Authority that dictates RA operating responsibilities and requirements. Such agreements also dictate that RAs shall abide under the stipulations of the SITHS Certificate Policy. To every such agreement a RAPS shall also be appended, that describes the local implementation of this RAP Agreement with the organization that RAs belong to The following formal and documented agreements shall extist within the organization that RAs and xras belong to, in regards to RA operations: Agreement regarding requirements and responsibilities for RA Agreement regarding requirements and responsibilities for ORA Agreement regarding requirements and responsibilities for LRA Agreement regarding requirements and responsibilities for CRA Agreement with xras organizational manager regarding requirements and responsibilities for xra operations Agreement with the responsibles for the directory services used by SITHS within the organization Agreement with the archival responsible within the organization Such organizational agreements shall also define the organizations assignment of: Register responsibles Information security responsibles 3 Identification and authentication All identification and authentication of subscribers shall adhere to the SITHS Certificate Policy stipulations. Requirements for identification are described in the SITHS Certificate Policy. RAs shall make sure that there are routines implemented regarding: Control of auhtorized individuals when applying for certificates Establishment of formal information regarding certificate applications Archiving of certificate applications Archiving of requests for certificates Archiving of requests for smart cards Issuance and revocation of certificates Archiving of subject validations Archiving of results of certificate applications These routines shall be described in the RAPS of RAs. Page 16/31

17 3.1 Requirements for physical presence Requirements for physical presence of subscribers shall adhere to the SITHS Certificate Policy stipulations. The implementation of the requirements stated in the SITHS Certificate Policy shall be described in the RAPS of RAs. 3.2 Authentication of functions within organizations Requirements for authentication of functions shall adhere to the SITHS Certificate Policy stipulations. The implementation of the requirements stated in the SITHS Certificate Policy shall be described in the RAPS of RAs. 3.3 Authentication of authorized representative Requirements for authentication of authorized representatives shall adhere to the SITHS Certificate Policy stipulations. The implementation of the requirements stated in the SITHS Certificate Policy shall be described in the RAPS of RAs. 3.4 Requests for certificate revocation Reqests for certificate revoction shall adhere to the SITHS Certificate Policy stipulations. The implementation of the requirements stated in the SITHS Certificate Policy shall be described in the RAPS of RAs. 4 Operational requirements Operational requirements dictate the following: Certificate and smart card applications Issuance of certificates, smart cards, keys and codes Revocation of certificates and smart cards These operational requirements shall adhere to the SITHS Certficate Policy stipulations. The implementation of the requirements stated in the SITHS Certificate Policy shall be described in the RAPS of RAs. 4.1 Certificate application Circumstances for application A CA or RA shall issue certificates under the following circumstances: If a valid subscriber submits a valid certificate application If the subscriber information can be validated in accordance with the SITHS Certificate Policy If not suspecting that a private key associated with a certificate will be compromised or used by some entity that is not the subscriber If the subscriber is in exclusive control of an approved cryptographic module for certificates that require such cryptographic modules If not suspecting that the subscriber will violate the SITHS Certificate Policy. If a CA issues a certificate in accordance with one of the above circumstances under a mistake of fact the CAs responsibilities are determined by the SITHS Policy Authority from case to case. Page 17/31

18 4.1.2 Who can submit a certificate application? Below is a list of entities that may submit certificate applications: Individual who is the subject of the certificate and who is an employee of, or by a formal agreement is connected to, a SITHS member organization. Certificate applications from such entities shall be approved by administrative management functions within the SITHS member organization in accordance to local regulations. Authorized representatives of an organization Authorized representatives of a CA RAs or authorized representatives of an RA o RAs or representatives of RAs are not allowed to request certificates that represent their own identities Enrollment process and responsibilities End entity certificate subscribers All end entity certificate subscribers shall manifest assent to the relevant subscriber and undergo an enrollment process consisting of: Completing a certificate application and providing true and correct information Generating, or arranging to have generated, a key pair Delivering his, her, or its public key, directly or through an RA, to the SITHS processing centers Demonstrating possession and/or exclusive control of the private key corresponding to the public key delivered to the SITHS processing centers Page 18/31

19 4.2 Certificate Application Processing Performing identification and authentication functions An RA, or xra, shall perform identification and authentication of all required subscriber information according to the requirements in chapter 3 of the SITHS Certificate Policy. A certificate application must fulfill the following procedures: 1. RA or other authorized representative for RA fills out application forms and signs the application ensuring that all applicable terms and conditions are accepted. In this procedure the subscriber declares all relevant subscriber information according to chapter 3 in the SITHS Certificate Policy. 2. The subscriber is identified and authenticated according to chapter 3 in the SITHS Certificate Policy. All subscriber information is also verified according to chapter 3 in the SITHS Certificate Policy. 3. Application forms are archived according to the SITHS Certificate Policy Approval or rejection of certificate applications An RA will approve an application for a certificate if the following criteria are met: Successful identification and authentication of all required subscriber information in terms of chapter 3 in the SITHS Certificate Policy. An RA will reject a certificate application if: Identification and authentication of all required subscriber information in terms of chapter 3 in the SITHS Certificate Policy cannot be completed The subscriber fails to furnish supporting documentation upon request The subscriber fails to respond to notices within a specified time The RA believes that issuing a certificate to the subscriber may bring SITHS into disrepute Time to process certificate applications CAs and RAs begin processing certificate applications within a reasonable time of receipt. There is no time stipulation to complete the processing of an application unless otherwise indicated in the relevant subscriber agreement, CPS or other agreement between SITHS participants. A certificate application remains active until rejected. Page 19/31

20 4.3 Certificate issuance CA Actions during certificate issuance A certificate is created and issued following the approval of a certificate application by a CA or following receipt of an RA request to issue the certificate. The CA creates and issues to a certificate applicant a certificate based on the information in a certificate application following approval of such certificate application. The issuance of a certificate means that the issuing CA accepts the subscriber application and the subscriber information that the subscriber has declared. The electronic registration by RAs is conducted in a system and in an environment that is secured from integrity flaws and follows routines that prevent faulty mixtures of keys and subscriber information. Certificates are generated when an authorized representative for a CA or RA or other authorized representative for RA has ascertained that all application and control routines have been fulfilled. Every certificate application from an authorized representative for a CA or RA or other authorized representative for RA can be traced back to the individual that signed the certificate application Notifications to subscriber by the CA of issuance of certificate CAs issuing certificates to end entity subscribers shall, either directly or through an RA, notify subscribers that they have created such certificates, and provide subscribers with access to the certificates by notifying them that their certificates are available and the means for obtaining them. Certificates shall be made available to end entity subscribers, either by means of an RA-operator, allowing them to download them from a web site or via a message sent to the subscriber containing the certificate. 4.4 Certificate acceptance Conduct constituting certificate acceptance The following conduct constitutes certificate acceptance: Downloading a certificate or installing a certificate from a message attaching it constitutes the subscribers acceptance of the certificate. Failure of the subscriber to object to the certificate or its content constitutes certificate acceptance Publication of the certificate by the CA CAs publish the certificates they issue in the HSA directory as an attribute of the directory object that represents the certificate subject. Page 20/31

21 4.4.3 Notification of certificate issuance by the CA to other entities RAs shall receive notification of the issuance of certificates they approve. 4.5 Certificate revokation Circumstances for revocation A CA or RA shall revoke issued certificates under the following circumstances: If any of the information contained within a certficate is changed If recieving a revocation request according to section 3.4 in the SITHS Certificate Policy. If suspecting that a private key associated with a certificate is compromised or used by some entity that is not the subscriber If suspecting that the smart card or equivalent cryptographic module that contains the private key is no longer in use or possessed by the subscriber If suspecting that the subscriber violates the SITHS Certificate Policy. If a used CA-key is suspected of compromise If a CA ends its duties as a CA If an RA, or xra, ends its duties as RA or xra their certificates shall only be revoked if the personal smart card will also be revoked. If the smart card is not to be revoked only the RA och xra permissions shall be revoked within SITHS. RAs and xras have the ability to revoke smart cards and certificates outside its own RA boundary if: 1 The subscriber have an existing smart card and certificates issued from another SITHS RA boundary, and 2 The RA or xra will issued a new smart card with certificates that replace the previously issued smart card and certificates If a CA revokes a certificate in accordance with one of the above circumstances under a mistake of fact the CAs responsibilities are determined by the SITHS Policy Authority from case to case Who can submit a revocation request Revokation requests can be made by: RA xra authorized by RA Authorized representative for SITHS member organization Certificate subscriber A CA can however decide to revoke a certificate based on information gathered from other part if this is in alignment with section 3.4 of the SITHS Certificate Policy Procedure for revocation request A revocation service connected to every SITHS CA that issue certificates recieve the request for revocation. The request must be signed by an authorized individual according to section 3.4 of the SITHS Certificate Policy. All revokation requests are archived along with the following information: Page 21/31

22 How the request was recieved When the request was received The reason for revocation The result of successful revocation request The time of publication in revocation list A unique log-id for the revocation request Revocation request grace period Revocation requests shall be submitted as promptly as possible within a commercially reasonable time. 4.6 Smart card applications Routines and procedures for smart card applications shall be described in the RAPS of RAs. 5 Records archival Records archival shall adhere to the SITHS Certificate Policy stipulations. The implementation of the requirements stated in the SITHS Certificate Policy shall be described in the RAPS of RAs. The following specific archival requirements apply for each RA boundary: Smart card and certificate applications that are not archived by CAs Issuance and revocation of certificates Archiving of subject validations Archiving of results of certificate applications RAs have the right to be granted acess to information that is archived by CAs, however only information that correspond to the local RA boundary 6 Compromise and disaster recovery Compromise of CA keys is handled according to the stipulations of the SITHS Certificate Policy. Every RA within SITHS is responsible for developing and implementing its local compromise and disaster recovery plans in accordance to the requirements of the SITHS Certificate Policy and the local requirements from within the RA boundary. The RAPS of each RA shall contain a reference to such compromise and disaster recovery plans. 7 RA termination In the event a RA is terminated from SITHS, the RA is obligated to fulfill the following procedures: Inform subscribers and other parties, that the RA has a relation with, at least 3 months before termination Terminate all permissions that are held by RA operators within the RA operating boundary Ensure that all archived information and logs are kept for the entire duration of the archival period An RA within SITHS must provide gurarantees and insurances that the necessary means are available to fulfill the above requirements in a termination situation. Page 22/31

23 8 Facility, management, and operational controls 8.1 Physical controls Physical controls refer to the physical protection of sites, equipment and information that are related to CAs and RAs. The goals of physical controls are to prevent unauthorized physical access, damage and disruptions. These controls must be related to the risks and threats that CAs and RAs within SITHS are subject to. RAs and associated xras shall fulfill the requirements stipulated in chapter 5 of the SITHS Certificate Policy. Some RA functions can occur outside of the centrally controlled physical environment, these are: 1 Identification of subscribers when applying for a certificate by physical presence 2 Distribution of keys and codes associated with keys 3 Identification of subscribers and its possession of the correct private key when applying for a certificate electronically 4 Electronic registration of subscribers 5 Revokation registration for revoking of certificates Function 1 and 2 does not provide any access to a CA, these functions does therefore not regulate any specific physical security controls. Functions 3-5 are only allowed to be executed in a controlled office environment. Keys or codes must never be left unattended. RA operating credentials that give access to a CA are personal and must not be left behind when the RA operator leaves the environment. The controlled office environment must also include lockable storage units for storage of archive materials. 8.2 Procedural controls RAs are responsible for all procedures and conditions that concern subscriber applications, issuance, revocation and associated administrative functions. RAs can choose to delegate its responsibilities for these procedures by creating an RA organization. An RA organization can consist of: One RA o RAs have the ultimate authority and responsibility of RA operations within its RA operating boundary. RAs can also appoint xras to allow for certain delegated RA operations One or more ORAs o ORAs are responsible for delegated RA operations within designated parts of an RA operating boundary. ORAs can also appoint LRAs and CRAs within its part of the RA operating boundary. ORAs can also issue and revoke subscriber certificates within its RA operating boundary. One or more LRAs o LRAs are responsible for issuing HCC Person certificates for subscribers with smart cards, including temporary replacement cards. One or more CRAs o CRAs are responsible for issuing smart cards for subscribers, excluding temporary replacement cards One information security responsible o Informations security responsibles are responsible for evaluating conformance with the RA organizations RAPS Page 23/31

24 One register responsible o Register responsibles are responsible for archiving smart card subscriber receipts One or more audit officers o Have read only acess to smart card and certificate information within the local RA operating boundary 8.3 Personnel controls The SITHS Policy Authority has documented detailed personnel control and security policies for RAs to adhere to and be audited against. These personell controls contain sensitive information and are only available to SITHS member organizations after explicit agreement with the SITHS Policy Authority. An overview of the requirements is described in the subsections following Qualifications, experience, and clearance requirements RAs shall require that personnel seeking to become xras present proof of the requisite background, qualifications, and experience needed to perform their prospective job responsibilities competently and satisfactorily. A person within an RA organization shall not have other roles that can be in conflict with the assignment in the RA organization, in accordance with the SITHS Certificate Policy. Within SITHS it is not considered as a conflict to be responsible for a directory service used by SITHS while having an xra assignment Background check procedures RAs shall designate xras that meet the requirements of the RAs local background check procedures. These procedures shall be documented in the RAPS of RAs. The SITHS Policy Authority shall conduct background checks of RAs according to the stipulations of the SITHS Certificate Policy. This includes: A confirmation of previous employments A check of professional references A confirmation of the highest or most relevant educational degree obtained A search of criminal records (local, state or provincial, and national) Drug tests and/or financial status checks Training requirements RAs shall provide their personnel with the requisite training needed for their personnel to perform their job responsibilities relating to RA operations competently and satisfactorily. They shall also periodically review their training programs, and their training shall address the elements relevant to functions performed by their personnel. Training programs must address the elements relevant to the particular environment of the person being trained, including: Security principles and mechanisms of SITHS Hardware and software versions in use All duties the person is expected to perform Incident and compromise reporting and handling Disaster recovery and business continuity procedures Page 24/31

25 8.3.4 Retraining frequency requirements RAs shall provide refresher training and updates to their personnel to the extent and frequency required to ensure that such personnel maintain the required level of proficiency to perform their job responsibilities competently and satisfactorily Job rotation frequency and sequence No stipulations Sanctions for unauthorized actions No stipulations Independent contractor requirements RAs may permit independent contractors or consultants to become trusted persons only to the extent necessary to accommodate clearly defined outsourcing relationships and only under the following conditions: The entity using the independent contractors or consultants as xras does not have suitable employees available to fill the roles of trusted persons, and The contractors or consultants are trusted by the entity to the same extent as if they were employees. Otherwise, independent contractors and consultants shall have access to secure facilities used by SITHS only to the extent they are escorted and directly supervised by trusted persons Documentation supplied to personnel Inera AB, processing centers and SITHS member organizations shall provide their personnel with the requisite training and access to other documentation needed to perform their job responsibilities competently and satisfactorily. 9 Technical security controls Private Key delivery to subscribers For HCC Person subscribers, keys and its associated smart card are delivered by secure postal service to the RA-function that approved the certificate request. Forwarding of such mail is not permitted. To be noted is that internal forwarding such mail is considered as new mail, thereby allowing such forwarding within an RA boundary. Smart cards that are completed for delivery but are not delivered to its recipient are locked in a controlled storage until it is sent. PIN/PUK-codes assossicated with smart cards are sent by regular postal service and is delivered to the suject address registered with the Swedish tax authority. In the case of smart cards that are issued to persons without a social security number, PIN/PUK codes can be delivered to addresses specified by the local RA organization. Keys associated with HCC Function certificates is only distrubuted to authorized representatives that have been identified and authenticated in accordance with chapter 3 in the SITHS Certificate Policy. Keys associated with HCC Function are only delivered to authorized representatives after they have been signed for in a formal recipient form, however codes associated with PKCS#12 objects are Page 25/31

26 delivered to authorized representatives when the CA issues the certificate. Recipient forms are archived for at least 10 years plus the certificate lifetime. 9.2 Private key protection and cryptographic module engineering controls The procedures dictated by the SITHS Certificate Policy regarding generation, storage and distribution of private keys is intended to provide protection for private keys in a way that minimize the risk that keys are inappropriately or maliciously exposed or used. It is the responsibility of RAs that sufficient security controls are implemented in the local environments where subscriber certificates are used. However it is the responsibility of individual subscribers that certificates are used in accordance with the SITHS subscriber agreement. Subscribers are obligated to only use private keys in situations, applications and devices where it cannot be suspected that private keys can be misused or abused Private key archival No centrally generated keys for subscribers or RAs are allowed to be archived by CAs. However, private keys associated with HCC Function certificates can be allowed to be archived for backup purposes. If such private key archiving is implemented within an RA boundary, this shall be documented within the RAPS of such RAs. Page 26/31

27 9.3 Computer security controls Specific computer security technical requirements RA functions take place on trustworthy systems in accordance with the standards documented in the contractual agreements with processing centers. Processing centers shall ensure that the systems maintaining RA software and data files are secure from unauthorized access, which can be demonstrated by compliance with the SITHS Certificate Policy. In addition, processing centers limit access to production servers to those individuals with a valid business reason for access. General users shall not have accounts on the production servers. Processing centers shall have production networks logically separated from other components. This separation prevents network access except through defined application processes. Processing centers shall use firewalls to protect the production network from internal and external intrusion and limit the nature and source of network activities that may access production systems. Processing centers shall require the use of passwords with a minimum character length and a combination of alphanumeric and special characters, and shall require that passwords be changed on a periodic basis and whenever necessary. Direct access to a processing center database maintaining the processing centers repository shall be limited to trusted persons in the processing centers operations group having a valid business reason for such access. RAs shall ensure that the systems maintaining RA software and data files are trustworthy systems secure from unauthorized access, which can be demonstrated by compliance with the SITHS Certificate Policy. RAs shall logically separate access to these systems and this information from other components. This separation prevents access except through defined processes. RAs shall use firewalls to protect the network from internal and external intrusion and limit the nature and source of activities that may access such systems and information. RAs shall require the use of SITHS certificates for all operations. Direct access to RAs database maintaining subscriber information shall be limited to trusted persons in the RA operations group having a valid business reason for such access. Processing centers shall also have mechanisms and/or policies in place to control and monitor the configuration of RA systems. Upon installation, and at least once a day, processing centers shall validate the integrity of the RA system. RA functions are performed using networks secured in accordance with the standards documented in the contractual agreements with processing centers to prevent unauthorized access, tampering, and denial-of-service attacks. Communications of sensitive information shall be protected using point-topoint encryption for confidentiality and digital signatures for non-repudiation and authentication. Only communication that is required for appropriate RA operation shall be allowed, other communication is to be blocked at the network layer. Software and hardware features that are not used by RAs shall be deactivated Computer security rating No stipulations. Page 27/31

28 10 Compliance audit and other assessments of RAs Compliance audit and other assessments of RAs shall adhere to the SITHS Certificate Policy stipulations. Two kinds of RA audits are implemented: External audit Audits the implementation of the requirements stated in the SITHS Certificate Policy and the SITHS Registration Authority Policy and is performed by the SITHS Policy Authority or an entity designated by the SITHS Policy Authority in accordance with the stipulations in the SITHS Certificate Policy. Internal audit The implementation of the RAPS associated with an RA operating boundary and the compliance with the SITHS RAP and is performed by information security responsibles associated with the RA organization. Each RA shall describe how such audits are handled and conducted within its Ra boundary. 11 Referenced documents The following documents are referenced in this RAP: The SITHS HCC Profile, version 3.0 The HSA Policy, version 3.5 The SITHS Certificate Policy, version 1.0 The SITHS Registration Authority Policy Statement template, version 1.0 Page 28/31