kas bank n.v. - certification practice statement (cps) · 2016. 6. 24. · 2.5 compliant audit ......

Certification Practice Statement (CPS) Versie 1.11

Certification Practice Statement (CPS)

1 Oct 2014

Version 1.11

of 29

Document History and Approval

Document History

Name Version Approved Position

KB PKI CPS 1.1, 5 June 2014 Sector Head Information Systems

KAS BANK Legal Department (liability

chapters)

KB PKI CPS 1.11, 1 okt 2014 Key purpose added


1 Oct 2014

Version 1.11

of 29

Date of publication: October 2014

All rights reserved

THIS DOCUMENT CANNOT BE COPIED, DISTRIBUTED, STORED OR INTRODUCED INTO

A RETRIEVAL SYSTEM, OR TRANSMITTED, COMPLETELY OR PARTIALLY, IN ANY FORM

OR BY ANY MEANS (ELECTRONIC, MECHANICAL, PHOTOCOPYING, RECORDING OR

OTHERWISE) WITHOUT THE PRIOR WRITTEN CONSENT OF KAS BANK N.V.


1 Oct 2014

Version 1.11

of 29

Table of Contents 1 INTRODUCTION................................................................................................................................ 8

1.1 Overview ................................................................................................................................. 8

1.2 Identification ........................................................................................................................... 8

1.3 Community and Applicability .................................................................................................... 9

1.3.1 Certification Authority........................................................................................................... 9

1.3.2 Registration Authority/Customer Operator ............................................................................ 9

1.3.3 Subscribers .......................................................................................................................... 9

1.4 Certificate Usage ................................................................................................................... 10

1.4.1 Appropriate Certificate Use ................................................................................................. 10

1.4.2 Prohibited Certificate Use ................................................................................................... 10

2 GENERAL PROVISIONS ................................................................................................................... 11

2.1 Obligations ............................................................................................................................ 11

2.1.1 CA Obligations.................................................................................................................... 11

2.1.2 Registration Authority and Customer Operator Obligations .................................................. 12

2.1.3 Subscriber Obligations........................................................................................................ 12

2.1.4 Repository Obligations........................................................................................................ 13

2.2 Liability.................................................................................................................................. 13

2.2.1 Certification Authority Liability/ Registration Authority/ Customer Operator Liability ............ 13

2.3 Interpretation and enforcement ............................................................................................. 13

2.3.1 Governing law .................................................................................................................... 13

2.3.2 Dispute resolution procedure .............................................................................................. 13

2.4 Publication and repository ...................................................................................................... 13

2.4.1 Publication of CA Information ............................................................................................. 13

2.5 Compliant Audit ..................................................................................................................... 14

2.5.1 Assurance .......................................................................................................................... 14

2.5.2 Frequency of Entity compliance audit.................................................................................. 14

2.5.3 Identity/qualifications of auditor ......................................................................................... 14

2.5.4 Topics covered by audit ...................................................................................................... 14

2.5.5 Action taken as a result of deficiency .................................................................................. 14

2.5.6 Communication of results ................................................................................................... 14

2.6 Confidentiality and data protection ......................................................................................... 14

2.7 Intellectual property rights..................................................................................................... 15


1 Oct 2014

Version 1.11

of 29

3 Identification and Authentication..................................................................................................... 15

3.1 Initial Registration ................................................................................................................. 15

3.1.1 Types of names .................................................................................................................. 15

3.1.2 Need for names to be meaningful ....................................................................................... 15

3.1.3 Uniqueness of Names ......................................................................................................... 15

3.1.4 Proof of possession of Private Key ...................................................................................... 15

3.2 Certificate renewal (rekey)..................................................................................................... 15

3.3 Renewal (rekey) after Revocation........................................................................................... 16

3.4 Revocation request ................................................................................................................ 16

4 Operational Requirements .............................................................................................................. 17

4.1 Certificate Suspension and Revocation ................................................................................... 17

4.1.1 Circumstances for Revocation ............................................................................................. 17

4.1.2 Who can request Revocation? ............................................................................................. 17

4.1.3 Revocation procedure ......................................................................................................... 17

4.1.4 Revocation requests ........................................................................................................... 18

4.2 CERTIFICATE EXPIRATION ..................................................................................................... 18

4.3 Security Audit procedure........................................................................................................ 18

4.3.1 Type of events recorded ..................................................................................................... 18

4.3.2 Frequency and procedures for audit log processing ............................................................. 19

4.3.3 Retention period for audit logs............................................................................................ 19

4.3.4 Protection of audit log ........................................................................................................ 19

4.3.5 Notification to event causing Subject .................................................................................. 19

4.3.6 Vulnerability assessments................................................................................................... 19

4.4 Key update ............................................................................................................................ 19

4.5 Compromise and disaster recovery......................................................................................... 19

4.6 CA Termination ...................................................................................................................... 19

5 Physical, Procedural and Personnel Security Controls ...................................................................... 20

5.1 Physical and environmental security controls.......................................................................... 20

5.1.1 Physical Security Controls for Subscribers ........................................................................... 20

5.2 Procedural Controls................................................................................................................ 20

5.2.1 Trusted Roles ..................................................................................................................... 20

5.3 Personnel Controls ................................................................................................................. 21

6 Technical Security Controls ............................................................................................................. 22

6.1 Key Pair generation and installation ....................................................................................... 22


1 Oct 2014

Version 1.11

of 29

6.1.1 Key Pair generation ............................................................................................................ 22

6.1.2 Private Key delivery to entity.............................................................................................. 22

6.1.3 CA Public Key delivery to users........................................................................................... 22

6.1.4 Key sizes............................................................................................................................ 22

6.1.5 Hardware/software key generation ..................................................................................... 22

6.1.6 Key usage purposes (as per X.509 v3 key usage field)........................................................ 22

6.2 Private Key protection............................................................................................................ 22

6.2.1 Standards for Cryptographic module................................................................................... 22

6.2.2 Private Key (n out of m) multi-person control ..................................................................... 22

6.2.3 Private Key escrow ............................................................................................................. 23

6.2.4 Private Key backup............................................................................................................. 23

6.2.5 Private Key archival............................................................................................................ 23

6.2.6 Private Key entry into cryptographic module ....................................................................... 23

6.2.7 Method of activating Private Key......................................................................................... 23

6.2.8 Method of deactivating Private Key ..................................................................................... 23

6.2.9 Method of destroying Private Key ....................................................................................... 23

6.3 Other Aspects of Key Pair management.................................................................................. 23

6.3.1 Usage periods for the public and Private Keys ..................................................................... 24

6.4 Activation Data ...................................................................................................................... 24

6.4.1 Activation Data generation and installation ......................................................................... 24

6.4.2 Activation Data protection .................................................................................................. 24

6.5 Computer Security Controls ................................................................................................... 24

6.5.1 Specific computer security technical requirements .............................................................. 24

6.6 Life Cycle Technical Controls .................................................................................................. 24

6.6.1 System development controls............................................................................................. 24

6.6.2 Security management controls ........................................................................................... 25

6.6.3 Life cycle security ratings ................................................................................................... 25

6.7 Network Security Controls...................................................................................................... 25

7 Certificate and CRL profiles ............................................................................................................. 26

7.1 Certificate Profile ................................................................................................................... 26

7.1.1 Version number(s) ............................................................................................................. 26

7.1.2 Certificate extensions ......................................................................................................... 26

7.1.3 Algorithm object identifiers................................................................................................. 26

7.1.4 Name forms ....................................................................................................................... 26


1 Oct 2014

Version 1.11

of 29

7.1.5 Name constraints ............................................................................................................... 26

7.2 CRL Profile ............................................................................................................................. 26

7.2.1 Version number(s) ............................................................................................................. 26

8 Specification Administration ............................................................................................................ 27

8.1 Specification change procedures ............................................................................................ 27

8.1.1 Items that can change without notification.......................................................................... 27

8.1.2 Items which change requires a new policy .......................................................................... 27

8.2 Publication and notification policies ........................................................................................ 27

9 Appendix A: KAS BANK Glossary..................................................................................................... 28


1 Oct 2014

Version 1.11

of 29

1 INTRODUCTION

1.1 Overview

This document is the Certification Practice Statement (CPS) of KAS BANK N.V, further to be referred to as

KAS BANK, within it are stated the practices that KAS BANK employs in providing certification services.

This CPS details the practices of KAS BANK in the management of its Public Key Infrastructure (PKI)

environment. The CPS controls the certification process, and includes issuing, managing, using, revoking

and renewing certificates.

Appendix A contains the KAS BANK PKI Glossary.

1.2 Identification

Policy name KAS BANK PKI Certificate Practice Statement

Policy Qualifier KAS BANK N.V. is the issuer of this certificate. Restriction may

Apply to the use. For more information, contact:

http(s)://pki.kasbank.com

Policy version 1.1

Policy status final

Date of issue 2014-5-17

Date of expiry NA

For further information, please contact KAS BANK at:

KAS BANK N.V.

Nieuwezijds Voorburgwal 225

1012 RL Amsterdam

The Netherlands

Tel. 0031 (0)20 557 5911

[email protected]

mailto:[email protected]


1 Oct 2014

Version 1.11

of 29

1.3 Community and Applicability

1.3.1 Certification Authority

KAS BANK acts as a Certification Authority (CA), assigning a public key to a specific person, entity,

device, etc (henceforth to be called Subscriber) through the issuance of a Certificate according to the

terms stated in this CPS.

The KAS BANK CA hierarchy can be seen in Figure 1.

Figure 1: Overview KAS BANK PKI CA environment

1.3.2 Registration Authority/Customer Operator

KAS BANK acts as a Registration Authority for registering Customer Operators and performs the checks

required to ensure the applicant’s identity according to the terms stated in this CPS.

KAS BANK can delegate the confirmation of identity to one or several Customer Operators, who function

as Registration Authority. The Registration Authorities will check the Subscribers (1.3.3) identity

according to the terms stated in this CPS. The relationship with the Registration Authority is based on the

provision of specific services agreements.

1.3.3 Subscribers

A Subscriber is an entity that requests use of services provided by the KAS BANK PKI Infrastructure, this

can be an authorized individual (KAS BANK Customer or KAS BANK employee) or device/program that

accesses an object to accomplish a task.

The Subscriber will comply with the terms of this CPS.

KAS BANK Root CA

KAS BANK

Intermediate CA

KAS BANK

Issuing Customer

CA

KAS BANK

Issuing Internal CA


1 Oct 2014

Version 1.11

of 29

1.4 Certificate Usage

1.4.1 Appropriate Certificate Use

Depending on the type of Certificate issued within the KAS BANK PKI the Subscriber (1.3.3) will be

allowed for example to:

- Be authenticated

- Electronically sign data and let this signature be validated by a person, network, device or

Application

- Encrypt data (messages, files, transactions etc..)

- Decrypt encrypted data (messages, files, transactions etc…)

- Establish secure communication channels with KAS BANK through SSL (Secure Socket Layer)

connections for confidentiality purposes

1.4.2 Prohibited Certificate Use

It is not permitted to use Certificates for securing communications with anyone other than the parties

authorized by KAS BANK. Depending on the type of Certificate and the Applications, KAS BANK reserves

the right to limit or restrict the usage of and/or reliance on certain Certificate functions as described in

1.4.1.


1 Oct 2014

Version 1.11

of 29

2 GENERAL PROVISIONS

2.1 Obligations The Obligations do not constitute the entire obligations for a CA within the KAS BANK PKI, additional

obligations may apply through this CPS or Terms and Conditions.

KAS BANK reserves the right to make such amendments to this CPS, including but not limited to;

technical, procedural and organizational rules, security provisions, user information, user guides and

other written specifications related thereto. These amendments shall be applied from time to time, as and

when KAS BANK considers it necessary or desirable, provided that such amendments do not result in any

material reduction in the functionality of the PKI. KAS BANK shall notify the Subscriber through KAS-Web

of any such amendments, as soon as is practicable, after they have been made.

2.1.1 CA Obligations Each CA within the KAS BANK PKI, including its CA Operator, is obliged to:

- Operate in full accordance with this CPS, as well as with any applicable laws of the governing

jurisdiction

- Publish Certificates in the KAS BANK PKI Repository and maintain Certificate status information

therein in a manner accessible to all Relying Parties

- Use reliable systems and products protected against any alterations that guarantee the technical

and cryptographic security of the certification procedures they support

- Maintain the security of its own private keys by using reliable systems and products to store them

and make them inaccessible to non-authorized people, thereby avoiding their loss or distribution

and guaranteeing their reliability.

- Offer and maintain the necessary infrastructure for certification services, as well as the necessary

physical, procedural and personal security controls for the certification practices

- Approve or reject certificate applications

- Provide copies of their own certificates or of any revocation information to anyone wishing to

verify a digital signature with reference to those certificates. For this purpose, KAS BANK will

publish all necessary information at: http(s)://pki.kasbank.com.

- Publish the certificates issued in accordance with the provisions of current regulations with regard

to data protection

- Protect personal details in accordance with current legislation with regard to personal details

protection

- Store by any secure means all information and documentation related to an issued certificate as

well as the Certification Practices Statements in force at that time, for a period of 10 years after

the issuance of the certificate onwards in time so that the signatures can be verified. For this

purpose, KAS BANK stores, in printed and digital formats, all versions of the CPS already

published. All issued certificates are stored in Public-Key Cryptography Standards - #7 format

(without private key) in order to verify, if necessary, a signature made with any of them

- Comply with the obligations of this CPS, the privacy protection laws and the current regulations.

- Take the necessary steps to avoid certificate falsifications and keep confidential the information

provided during the certificate generation, as well as the handing through a reliable procedure.

- Use reliable systems to store certificates that allow checking their authenticity and preventing

non-authorized people from changing the data. These reliable systems shall detect any change

http://pki.kasbank.com/


1 Oct 2014

Version 1.11

of 29

affecting the security conditions.

- Do not store or copy the signatory’s private key.

2.1.2 Registration Authority and Customer Operator Obligations

The Registration Authority for registering Customer Operators is KAS BANK.

The Registration Authority for registering customer Subscribers is the Customer Operator.

The Registration Authority will comply with the following obligations. The Registration Authority shall:

- Operate in full accordance with this CPS, as well as with any applicable laws of the governing

jurisdiction

- Identify or authenticate the Subscriber, the applicant or the organization that he represents,

according to the terms and conditions of this CPS for each type of certificate, by using any

authorized means.

- Formalize the Certificate Issuance contracts with the Subscriber under the terms and conditions

specified by the Certification Authority.

- Reserves the right to revoke or suspend any of the certificates issued, if it is necessary to protect

the certification system security.

2.1.3 Subscriber Obligations

A Subscriber who is issued a Certificate within the KAS BANK PKI shall:

- Operate in accordance with the CPS

- Operate in accordance with any applicable Code of Conduct or Terms and Conditions, as well as

with any applicable laws of the governing jurisdiction

- Only use his Certificates by himself and on his own behalf

- Provide the Registration Authority or the Customer Operator with the necessary information to

confirm identity

- Confirm the accuracy and truthfulness of the information provided

- Notify any change of the information provided during the validity period of the certificate

- Guard the certificate conscientiously taking all the necessary precautions to avoid its loss,

revelation, modification or non-authorized use

- Request the certificate suspension or revocation when any suppositions specified on the points of

this CPS which refer to certificate suspension or revocation may take place

- Not reveal the private key or the certificate access code

- Make sure that all information contained in the certificate is correct and notify KAS BANK of any

incorrect information that may have been included and that may not correspond to reality. The

subscriber is obliged to immediately inform KAS BANK of any change in the information provided,

even if this information –such as domicile or telephone number– was not included in the

certificate.

- Immediately inform KAS BANK of any situation that may affect the certificate validity.

- Not distribute or transfer the certificate without the prior consent of KAS BANK, except if it is

necessary in accordance with the terms and conditions of this CPS of each type of certificate and

the provision of certification services agreement signed with KAS BANK.

- Destroy the certificate when KAS BANK may demand it by virtue of its property right, when the


1 Oct 2014

Version 1.11

of 29

certificate may expire or be revoked.

- Make good and correct use of the certificate in accordance with the terms and conditions of this

CPS. The Subscriber will be liable for an incorrect use of the certificate.

- Comply with any other obligation specified by the legislation, by this CPS of each type of

certificate and the provision of certification services agreement signed with KAS BANK.

2.1.4 Repository Obligations

All CA’s within KAS BANK (as mentioned in paragraph 1.3.1) shall publish their Certificates issued under

this CPS, as well as relevant Certificate information such as Certificate Revocation List’s (CRL’s) in the

KAS BANK PKI Repository. In doing so, each CA shall use reasonably commercial efforts to maintain and

keep the KAS BANK PKI Repository up-to-date.

2.2 Liability The KAS BANK Customer is bound by all terms and conditions of this CPS and any documentation related

thereto when using a Certificate. The KAS BANK Customer warrants that each CA, RA, employee and any

other person or body which will be involved in this CPS on behalf of the KAS BANK Customer w ill comply

with the terms and conditions provided herein. In the absence of an executed agreement between the

KAS BANK Customer and KAS BANK covering this CPS, the terms and conditions of KAS BANK’s standard

agreement shall apply.

2.2.1 Certification Authority Liability/ Registration Authority/ Customer Operator Liability

In the event of any conflict between this CPS and an agreement concluded between the KAS BANK

Customer and KAS BANK, the provisions of that Agreement shall prevail. No provision in this CPS shall be

interpreted as imposing obligations on the KAS BANK which exceed its duty to exercise due care in the

performance of its duties under that Agreement.

2.3 Interpretation and enforcement

2.3.1 Governing law

The documentation for each type of certificate will be governed by Dutch law, in accordance with which

should its content be interpreted, excluding its conflict of laws rules and excluding the applicability of the

UN-Convention on Contracts for the International Sale of Goods (CISG).

2.3.2 Dispute resolution procedure

In order to resolve any dispute that may arise in connection to this CPS, the parties will refer to the

Dutch Court of Arbitration, resigning any other jurisdiction.

2.4 Publication and repository

2.4.1 Publication of CA Information

The content of this CPS will be available at: http(s)://pki.kasbank.com. The original documents will be

kept in the office of the Certification Authority.

Each CA shall store its Certificates and CRL in the KAS BANK PKI Repository. KAS BANK will ensure

unrestricted access to Certificate status information for all applicable Relying Parties.

https://pki.kasbank.com/


1 Oct 2014

Version 1.11

of 29

2.5 Compliant Audit

2.5.1 Assurance

The KAS BANK PKI infrastructure is witnessed by an external auditor during the setup and installation. An

Assurance report is available on request.

2.5.2 Frequency of Entity compliance audit

Frequently, with a minimum of every other year, KAS BANK shall conduct an internal audit of the KAS

BANK PKI. All audits shall be performed in compliance with this CPS.

2.5.3 Identity/qualifications of auditor

Internal auditors must have a minimum of two years of previous IT auditing experience and must be

employed by KAS BANK.

2.5.4 Topics covered by audit

Each audit will include, but is not limited to, compliance with:

- KAS BANK PKI CPS.

Topics covered by each audit will include but are not limited to:

- CA and RA physical security controls

- Key management controls

- Certificate life cycle management controls

- CA and RA infrastructure/administrative controls

2.5.5 Action taken as a result of deficiency

In case one or more significant deficiencies are identified by an internal or external auditor, they have to

be formally reported to responsible KAS BANK management.

Where a deficiency poses an immediate threat to the security or integrity of the KAS BANK PKI, a solution

shall be developed and implemented by KAS BANK within the shortest term possible. In case of a less

threatening deficiency, appropriate steps must be initiated and executed within a reasonable timeframe.

After it has been implemented, each solution shall be evaluated by the initial auditor for compliance.

2.5.6 Communication of results

KAS BANK shall treat audit results as sensitive commercial information and thus as confidential, meaning

they will not be publicly available.

2.6 Confidentiality and data protection Personal data that is collected or processed within the KAS BANK PKI shall be kept confidential and

handled in full compliance with applicable data protection legislation.

Certificate status information is not regarded as confidential and therefor public available via CRL.


1 Oct 2014

Version 1.11

of 29

2.7 Intellectual property rights KAS BANK has exclusive control to all intellectual property rights that may derive from the certification

system regulated by this CPS. It is therefore forbidden to reproduce, distribute, publicly communicate or

transform any element belonging to the Certification Authority without its prior consent. Nevertheless,

the consent of KAS BANK is not necessary to reproduce the certificate when the legitimate user may need

to use it in accordance with the certificates’ purpose and the terms and conditions of this CPS of each

type of certificate and the provision of services agreement signed with KAS BANK.

3 Identification and Authentication

3.1 Initial Registration

3.1.1 Types of names

CA’s, RA’s and Subscribers will be certified using a recognizable and unique X.500 Distinguished Name

(DN) in the Certificate “Subject name” field, in accordance with RFC2459. The DN will be in form of a

“printableString” or “utf8String” and is never to be left blank.

Each DN will contain a combination of at least the following attributes:

- Organizational Unit Name (OU)

- Common Name (CN)

- O KAS BANK N.V.

- L Amsterdam

- C NL

- Validity Period 25 Years

3.1.2 Need for names to be meaningful

All names assigned in Certificates shall be derived from Directories. This includes the need for names for

Technical Certificates to be meaningful.

3.1.3 Uniqueness of Names

The Subject name appearing in each Certificate will be unique at the time of Certificate issuance and

unambiguous across the KAS BANK PKI. If necessary, additional unique identifiers may be appended to

the distinguished name to ensure the name’s uniqueness within the KAS BANK PKI.

3.1.4 Proof of possession of Private Key

Insofar applicable, all Subscribers must demonstrate possession of the Private Key associated with a

requested Public Key during the Certificate request procedure. This may be done through a method

consistent with the key transfer protocol described in the PKIX Certificate Management Protocol

(RFC2510). Whenever Key Pairs are generated by KAS BANK, the above proof-of possession procedure

does not apply.

3.2 Certificate renewal (rekey) This procedure is used when a certificate is going to expire and the Subscriber desires to continue using a

certificate with the same characteristics as the previous one.


1 Oct 2014

Version 1.11

of 29

For this purpose, the Customer Operator will issue a new smartcard and new keys will be generated. This

time the verification measures will be minimal; the old certificate is still valid and there is no reason to

believe that the information provided has changed or that the certificate is no longer reliable, except if

the Subscriber confirms it.

The certificates issued by KAS BANK have a validity period which is stated in the certificate. This period

will always comply with current legislation. The previous requirements, the way of requiring revocation

and the certificate renewal procedure are the ones stated in the Certification Policies of each type of

certificate.

Once a Certificate has expired, the above procedure shall no longer be an option. As a result, a request

for renewal is then authenticated in the same manner as an initial registration as described in section 3.1

3.3 Renewal (rekey) after Revocation Revoked or expired Certificates shall not be renewed. Subscribers with an expired Certificate shall be re-

authenticated in the same manner as the initial registration as described in section 3.1

3.4 Revocation request Authentication of a Subscriber requesting Revocation of its Certificate may be accomplished by

demonstrating possession of the Private Key corresponding to the Public Key of the Certificate that is to

be revoked. Proof of possession shall be accomplished in the same manner as described in section 3.1.4

If an authorized party other than the Subscriber, as defined in section 4.1.2, requests Revocation of a

Certificate, authentication shall be done via a valid formal consent of a legal representative of that party,

or one formally appointed by him for such purpose.


1 Oct 2014

Version 1.11

of 29

4 Operational Requirements

4.1 Certificate Suspension and Revocation The certificate revocation process is used if the certificate is no longer reliable, or required, before its

validity period expires, this is does in accordance with the terms and conditions of this CPS.

4.1.1 Circumstances for Revocation

Certificates should be revoked in the event of the following circumstances:

Subscriber’s voluntary request.

Loss or irretrievable damage of the certificate’s software.

Death of the signatory or of his client, total or partial disability of any of them, representation

termination or expiry of the legal entity represented.

Serious inaccuracies in the data provided by the signatory to obtain the certificate, as well as the

circumstances that may do that the data originally included in the certificate do not correspond to

reality.

If the subscriber’s private keys have been threatened, either because of loss, theft, robbery,

modification, spreading or revelation of the private keys or due to other circumstances, including the

accidental, which may indicate that the keys have been used by other person different from the

holder.

If the Registration Authority, the Certification Authority or the Subscriber does not comply with their

obligations stated in this CPS.

If there are reasons to believe that the certification service has been threatened to the extent that

the certificate may be unreliable.

Court’s decision or administrative order.

Concurrence of other circumstances stated in this CPS or in the corresponding Certification Practices

of each type of certificate.

Regarding Business Certificates, the dismissal of the representative of the legal entity represented is

also circumstance for revocation.

4.1.2 Who can request Revocation?

A CA may revoke a Certificate issued by it:

- On its’ own initiative

- At the request of the Customer, the Registrar, the Subscriber

o Subscribers can only request the revocation of their own certificate

4.1.3 Revocation procedure

4.1.3.1 Active authentication

The following people should request the revocation of the certificate if any of the circumstances

previously stated arise:

The certificates’ Subscriber as well as the individual or legal entity represented by him.

The Registration Authority, with regard to the certificates in which issuance they have participated.

The legal entity stated in the certificate.

Likewise, suspension or revocation could be requested by any third-party with a legitimate interest if he

is aware of any of the following circumstances:


1 Oct 2014

Version 1.11

of 29

Loss of the certificates ’ software.

Death of the signatory.

Total or partial disability.

Inaccuracies in the certificate.

If the certificates’ reliability is threatened.

If the keys are threatened.

Dismissal of the representative in the cases of business certificates.

Extinction of the legal entity represented.

Revocation of the entity’s authorization stated in the certificate in the case of business certificates

where the owner has no rights to represent the entity.

The Certification Authority is able to start the certificate suspension/revocation procedure in any of the

circumstances previously stated.

The judicial or administrative authority could urge KAS BANK to suspend/revoke the certificate according

to the provisions of the Dutch Law on Telecommunications about electronic signatures.

4.1.4 Revocation requests

Certificate revocation requests could be addressed to KAS BANK contact address (1.2)

4.2 CERTIFICATE EXPIRATION Certificates will expire at the end of their operational period.

After the expiration, the certificate will not be valid, provoking the permanent cessation of the

certificate’s operational ability according to its uses and, consequently, the cessation of the provision of

certification services.

The certificate expiration does not allow the Subscriber to use the certificate.

4.3 Security Audit procedure KAS BANK shall maintain adequate records and archives of information pertaining to the operation of the

KAS BANK PKI. For this purpose, the software used by KAS BANK automatically preserves an audit trail

for the three primary states in the Certificate lifecycle, i.e. generation, operational use and expiry.

4.3.1 Type of events recorded

The minimum records to be kept by KAS BANK to enable auditing of the CA Systems shall include:

- Key life cycle management events, including

o Cryptographic device life cycle management events

o Key generation processes

o Key renewal and Key recovery

o Key backup, storage and archival

- Certificate life cycle management events, including:

o Certificate application, revocation requests (successful and unsuccessful)

o Registration records

o Generation, revocation and renewal of certificates

o Generation and issuance of CRL’s

- Security related events, including

o PKI (security) system actions performed by KAS BANK PKI staff

o Attempts to create, remove, set passwords or change the system privileges of KAS BANK


1 Oct 2014

Version 1.11

of 29

PKI system administrators or security administrators

o Security related incidents like PKI system access attempts (successful and unsuccessful)

o System crashes, hardware failures and other anomalies

All logs, whether electronic or manual, contain the date and time of the event, and the identity of the

Entity which caused the event.

4.3.2 Frequency and procedures for audit log processing

Audit logs will be processed on at least a weekly basis. Any action taken will be documented. Backups will

be made on a daily basis.

4.3.3 Retention period for audit logs

KAS BANK shall retain all audit logs related to the PKI environment for a maximum period of two years.

4.3.4 Protection of audit log

Access to audit logs shall be restricted to qualified personnel only and protected by a combination of

physical and logical security controls.

4.3.5 Notification to event causing Subject

Where an event is logged by the audit collection system, no notice will be given to the individual,

organization, device or Application, which caused the event.

4.3.6 Vulnerability assessments

Each CA within KAS BANK will frequently be scanned for vulnerabilities. Following an examination of all

monitored events, appropriate action will be taken when required.

4.4 Key update KAS BANK PKI supports a process to update the Key Pair associated with the Certificate prior to the end

of the Certificate’s Validity period, so as to avoid a disruption in security services as a result of an expired

Certificate.

4.5 Compromise and disaster recovery Procedures have been established to enable system or service recovery in case of a compromise or

disaster disruption. Such procedures are considered highly confidential by KAS BANK and are not publicly

available. KAS BANK will take all appropriate measures to minimize disruptions of the KAS BANK PKI

services.

4.6 CA Termination In order to cause as little harm as possible to subscribers and users of the certification system in case of

a hypothetical CA termination, the following measures are established:

- KAS BANK will communicate the termination by sending a registered e-mail addressed to all

subscribers whose certificates are in force. The communication aforementioned will be carried out

two months in advance before the CA termination.

- KAS BANK will carry out any other obligation established by current legislation.


1 Oct 2014

Version 1.11

of 29

5 Physical, Procedural and Personnel Security Controls

5.1 Physical and environmental security controls KAS BANK makes all efforts to verify that the physical access to critical services and the physical risks of

these elements are minimized. All procedures surrounding these security aspects are KAS BANK

confidential, and therefore not written in this CPS.

5.1.1 Physical Security Controls for Subscribers

Subscribers should treat all Activation Data that allows entry to a Private Key as confidential and protect

it as such. Activation Data should be memorized as much as possible, with all paper versions being

destroyed and may not be transferred to other persons or made public in any other way.

Subscribers shall not leave their computers unattended when the Private Key is in an activated state (i.e.

when the password/pin code has been entered) but must close all active sessions before doing so.

5.2 Procedural Controls

5.2.1 Trusted Roles

All KAS BANK personnel that have access to or control over cryptographic operations that may materially

influence the operation of the KAS BANK PKI with respect to Certificate issuance, Use or Revocation,

including access to restricted operations of the KAS BANK PKI, shall, for purposes of this CPS, be

considered as serving in a Trusted Role. Such personnel includes, but is not limited to, CA Operators, RA

Operators, system administration personnel, engineering personnel, security management and managers

who are designated to oversee the operations of the KAS BANK PKI.

5.2.1.1 Trusted Roles for CA’s

Within the KAS BANK PKI, duties with regards to critical functions of CA Systems are separated to

prevent one person from maliciously using a CA System without detection. System access for each

Trusted Role is limited to those actions that are required to perform certain responsibilities. At least three

distinct Trusted Roles will be distinguished for each CA:

1. Day-to-day operations of a CA System, and

2. Management and audit of CA operations, and

3. Management of changes to system requirements including its policies, procedure, or personnel.

5.2.1.2 Trusted Roles for RA’s

All RA Operators within the KAS BANK PKI (KAS BANK or Customer Operator) are considered to be acting

in a trusted Role. Each RA Operator must perform its function in a secure and trustworthy manner and

must be qualified to do so, in compliance with 5.3

In case a Customer Operator operates as an RA, it is the Customer’s responsibility and liability to ensure

that all Registrars perform their function in a secure and trustworthy manner and are qualified to do so in

compliance with 5.3

5.2.1.3 Identification and authentication for each role

All Trusted Roles for CA’s have their identity and authorization verified before they are:

- Included in the access list for the CA site

- Included in the access list for physical access to the CA System

- Given a Certificate for the performance of their CA role, and

- Given an account on the PKI system


1 Oct 2014

Version 1.11

of 29

5.3 Personnel Controls Individuals assuming Trusted Roles shall be of unquestionable loyalty, trustworthiness and integrity.

Individuals assigned to a trusted Role for a CA shall:

- Not be assigned other duties that may conflict with the duties defined for the Trusted Role

- Be a permanent employee or other authorized individual and not subject to frequent re -

assignment or extended periods of absence

- Not have been previously relieved of a past assignment for reasons of negligence or non-

performance of duties

- Have sufficient expertise and knowledge required for the performance of their duties


1 Oct 2014

Version 1.11

of 29

6 Technical Security Controls

6.1 Key Pair generation and installation

6.1.1 Key Pair generation

All Key Pairs will be securely generated on a Hardware Security Module (HSM) or on Smartcards with the

exception of a Soft Certificate. In case of a Soft Certificate the Key Pairs are generated on the device of

the Requester. All Technical Key Pairs will be generated by the Requester/Component Owner; the public

key will be signed off by the appropriate KAS BANK PKI CA.

6.1.2 Private Key delivery to entity

Smartcards containing Private Keys may be delivered to the Subscriber in person or may be securely

delivered via standard or signed mail as long as they are distributed separately from any Activation Data

required to access the Private Keys.

6.1.3 CA Public Key delivery to users

Not stipulated

6.1.4 Key sizes

All Subscriber Key Pairs shall have a minimum size of 1024 bit RSA.

All Key Pairs for CA’s will have a minimum size of 2048 bit RSA.

The minimum key sizes will be periodically reviewed, with a minimum of every two years, to judge their

appropriateness for securing communications.

6.1.5 Hardware/software key generation

All Key Pairs are generated in a hardware cryptographic module.

6.1.6 Key usage purposes (as per X.509 v3 key usage field)

Key usage purposes are specified using the X.509 Certificate key usage extension, which is marked

critical and used in accordance with RFC2459. Usage for specific types of Certificates that may be issued

under this CPS is in accordance with section 7 .

Key Pairs issued to CA’s may only be used to sign CRL’s and Certificates.

6.2 Private Key protection Private Keys must be stored on a Smartcard or, in case of a Soft Certificate, a protected network location

owned and managed by the owner. Access to Private Keys is restricted and requires Activation Data only

submitted to the associated Subscriber.

6.2.1 Standards for Cryptographic module

All cryptographic operations of CA’s are performed in a hardware security module (HSM) rated to at least

FIPS 140-1 Level 3 or otherwise verified to an equivalent level of functionality and assurance.

All Subscriber Smart Cards are rated to at least FIPS 140-1 Level 2 or otherwise verified to an equivalent

level of functionality and assurance. All Subscriber software tokens are rated to at least FIPS 140-1 Level

1 or otherwise verified to an equivalent level of functionality and assurance.

6.2.2 Private Key (n out of m) multi-person control

Three (3) person control is required for access to the KAS BANK PKI Root. Two (2) person control is


1 Oct 2014

Version 1.11

of 29

required for access to all CA signing keys. One (1) person control is permitted for all other keys.

6.2.3 Private Key escrow

KAS BANK PKI doesn’t supports escrow of private decryption keys.

6.2.4 Private Key backup

All CA Key Pairs will be backed-up. Backed-up keys are stored in encrypted form and protected at a level

similar to or higher than the level stipulated for the primary vers ion of the key.

All Root and subordinate-CA’s keys will be backed-up.

6.2.5 Private Key archival

Private Key Pairs won’t be archived.

6.2.6 Private Key entry into cryptographic module

Private Keys in cryptographic modules shall be stored in such way that they can be used inside the

module but never be retrieved from the cryptographic module.

The Private Key is generated inside the cryptographic module; it shall remain there without ever leaving

that module, apart from when copied to backup media.

The key generation environment must have controls in place to ensure that no person can access a

generated Private Key without detection. The private keys, created for CA’s and smartcards, are

generated and stored on secure devices.

6.2.7 Method of activating Private Key

The Private Key shall be protected from exposure and unauthorized usage by Subscriber specific

Activation Data. Each invocation of an algorithmic function requires insertion of the Activation Data

associated with the Key Pair.

Subscriber cryptographic modules shall lock themselves after three consecutive failed attempts at

inserting the correct Activation Data. In such case, the cryptographic module can only be unblocked by

KAS BANK upon a formal request of the Subscriber. For authentication of such a request, the same

procedure applies as that used for Revocation.

6.2.8 Method of deactivating Private Key

The cryptographic module automatically deactivates all active Private Keys once the module itself is

deactivated. In addition, the cryptographic module contains means of deactivating a Private Key after

each use.

6.2.9 Method of destroying Private Key

Upon termination of the usage of a CA’s Key Pair, all copies of the Private Key shall be securely

destroyed.

6.3 Other Aspects of Key Pair management Cryptographic token initialization, key loading, and personalization shall be performed in a secure area,

with physical and procedural controls in accordance with section 5. The log of the personalization system

shall contain a reference to the order, and list the corresponding chip numbers, Smartcard numbers, and

Certificates.


1 Oct 2014

Version 1.11

of 29

6.3.1 Usage periods for the public and Private Keys

• Key Pairs used to perform CA functions have a maximum validity of twenty (20) years

• Key Pairs for Subscribers have a maximum validity of (2) years

Key Pairs are not to be used beyond their validity period. In case it is decided by KAS BANK that updating

CA Key Pairs would be good practice or required to ensure the trustworthiness of the KAS BANK PKI, they

may be revoked and reissued at any time before their expiry.

6.4 Activation Data A PIN protecting the usage of Key Pairs contains at least four (4) digits and will be delivered to

Subscribers out of band.

6.4.1 Activation Data generation and installation

All Activation Data is unique and unpredictable and offers a security level appropriate to that of the

protected Key Pair.

6.4.2 Activation Data protection

Data used for Key Pair activation must be protected from unauthorized use by a combination of

cryptographic and physical access control mechanisms. The level of protection must be adequate to deter

a motivated attacker with substantial resources. If a reusable password scheme is used, the mechanism

shall include a facility to temporarily lock the account after a predetermined number of login attempts.

6.5 Computer Security Controls

6.5.1 Specific computer security technical requirements

In general, each CA System provides computer security controls sufficient to support the requirements

for the definition of Trusted Roles and separation of duties in accordance with section 5 and the use of

Key Pairs in accordance with section 6. The controls also support the audit log and archive requirements

in accordance with section 4.

Specifically, each CA utilizes a CA System that provides the following minimum functionalities:

• Access control to CA services and Trusted Roles

• Enforced separation of duties for Trusted Roles

• Identification and authentication of Trusted Roles and associated identities

• Use of cryptography for session communication and database security

• Archival of CA and Subscriber history and audit data

• Audit of security-related events

• Self-test of security-related CA services

• Trusted path for identification of Trusted Roles and associated identities, and

• Recovery mechanisms for keys and the CA System.

This functionality may be provided by the operating system, or through a combination of the operating

system, the CA System software, and physical safeguards.

6.6 Life Cycle Technical Controls

6.6.1 System development controls

The development of the CA System is performed in a controlled environment that provides protection


1 Oct 2014

Version 1.11

of 29

against the insertion of malicious logic. The software vendor has a quality system that has been certified

as compliant with international standards or must make its quality system available for inspection upon

request.

6.6.2 Security management controls

A formal configuration management methodology is used for installation and ongoing maintenance of a

CA System.

The CA System software, when first loaded provides a method for the CA to verify that the software on

the system:

• Originated from the software developer

• Has not been modified prior to installation, and

• Is the version intended for use.

6.6.3 Life cycle security ratings

During installation and at periodic intervals, the integrity of the CA System software and configuration is

validated by an auditor.

6.7 Network Security Controls The CA System is protected from attacks through any open or general purpose network with which it is

connected.


1 Oct 2014

Version 1.11

of 29

7 Certificate and CRL profiles

7.1 Certificate Profile Certificates issued under this CPS are constructed according to X.509 and the PKIX Certificate profile

(RFC2459).

7.1.1 Version number(s)

The version field shall be set to 2, indicating that the version is X.509v3.

7.1.2 Certificate extensions

Certificate extensions are processed in accordance with RFC2459.

7.1.3 Algorithm object identifiers

For signatures, the RSA algorithm with SHA-1 hashing is being used.

For encryption, the RSA algorithm is being used.

7.1.4 Name forms

The use of name fields is in accordance with section 3.1.

7.1.5 Name constraints

Each distinguished name (DN) of a KAS BANK PKI Certificate Subject includes “O = KASBANK N.V.”.

7.2 CRL Profile

7.2.1 Version number(s)

Each KAS BANK PKI Issuing CA shall support X.509 version 3.


1 Oct 2014

Version 1.11

of 29

8 Specification Administration

8.1 Specification change procedures

8.1.1 Items that can change without notification

Typographical corrections may be made to this CPS, the CP’s and the KAS BANK PKI Glossary without

prior notification of Subscribers and without creating a new version.

Editorial changes may be made to this CPS and the KAS BANK PKI Glossary without notification of

Subscribers and with creating a new version, insofar the changes don’t materially affect the contents of

this CPS.

8.1.2 Items which change requires a new policy

All changes that are not covered by 8.1.1 are considered to materially affect the contents of the CPS and

the KAS BANK PKI Glossary and will require a new version as well as notification to Subscribers prior to

replacing the original version.

8.2 Publication and notification policies All changes as referred to in 8.1.2 shall only be made with the explicit approval of the PAA. Such changes

shall undergo a maximum review and comment period of thirty (30) days, after which the proposed

modifications will be inserted and a new version published, insofar the changes are not amended or

rejected by the PAA.

All changes as referred to in 8.1.1. may be made without the implicit or explicit approval of the PAA.

When required, according to section 8.1 of this policy, all Subscribers will be notified of the changes

either electronically or in writing. Notice of change will include the date of issuance of the new version,

which will be at least one (1) week after the notification date.


1 Oct 2014

Version 1.11

of 29

9 Appendix A: KAS BANK Glossary

Term and/or abbreviation Description

1024/2048 RSA Amount of bits used to generated the Key Pair

Activation data Data send to recipient, out of band, to activate the certificate/smartcard

CA Certificate Authority, an entity that issues digital certificates

CA Operator Certificate Authority Operator

Certificate type, purpose The purpose, type of a certificate determines for what functions it can be used

CN Common Name

CP

Certificate Policy, as defined in X.509, is a named set of rules that indicates the applicability of a certificate to a particular community and/or class of application with common security requirements

CPS Certification Practice Statement. is a statement of the practices that a CA employs in managing the certificates that it issues.

CRL

Customer Revocation List, is a list of certificates (or more specifically, a list of serial numbers for certificates) that have been revoked, and therefore, entities presenting those (revoked) certificates should no longer be trusted

Customer Operator The RA, Registration Authority, at de customer location for registering Customer Subscribers

Decrypt The conversion of a cipher text into a form, that can be understood

Digital Certificate Is an electronic document that uses a digital signature to bind a public key with an identity

Encrypt The conversion of data into a form, called a cipher text, that cannot be easily understood by unauthorized people

ETSI 102.042 European Telecommunications Standards Institute

Expiring of the Certificate The end of life date of a certificate

FIPS 140

Federal Information Processing Standards are U.S. government computer security standards that specify requirements for cryptography modules (HSM, Smartcards, Soft certificates)

HSM Hardware Security Module

Issuance of the Certificate Process to create a new certificate

KAS BANK PKI CA The Certificate Authority of the KAS BANK’s Private Key Infrastructure

KAS BANK PKI Repository All issued Certificates are stored centrally in the PKI Repository

Non-repudiation refers to a state of affairs where the purported maker of a statement will not be able to successfully challenge the validity of the statement

OU Organizational Unit Name

PAA Policy Approval Authority

Pin code Unique, personal keyword

PKCS#7 format Cryptographic Message Syntax Standard (used to sign and/or encrypt messages under a PKI)

Private Key One part of a key pair is a private key for encryption/decryption known only to the party or parties that exchange secret messages


1 Oct 2014

Version 1.11

of 29

Public Key

The Public key is mathematical linked with the Private Key and is used to encrypt plaintext or to verify a digital signature. A Public key can be publicly published

RA Registration Authority

Revocation of the Certificate Process to revoke a certificate by placing the corresponding serial number on de CRL

RFC2459 Internet X.509 PKI Certificate and CRL Profile

RFC2510 PKI Certificate Management Protocols

Signing data A mathematical scheme for demonstrating the authenticity of a digital message or document (non–repudiation)

Smartcard Plastic card about the size of a credit card, with an embedded microchip where the private/public key are stored/generated

Soft Certificate Soft Certificate is a file which contains certificates which are similar to those on a smart card but which are not stored on or secured by the chip of a smart card

SSL Secure Socket Layer

Subscriber

A subscriber is an applicant for the services of KAS BANK PKI Infrastructure. This can be an authorized individual (KAS BANK Customer or KAS BANK employee) or device/program that accesses an object to accomplish a task.

Terms and Conditions Terms and Conditions of the KAS BANK

X.509 An standard for a PKI

kas bank n.v. - certification practice statement (cps) · 2016. 6. 24. · 2.5 compliant audit ......

Documents