End User Certificate Management

Document Sample
End User Certificate Management Powered By Docstoc
					Technical PKI interoperability in the European energy sector                                    1




                 PKI Certificate Policy (CP)


            Recommendations to market participants
                                             &
    Sample document for the external publication of a
   Certificate Policy or Certification Practice Statement
    (CPS) in accordance with ebIX recommendations


                                             Status:            Request for comments
                                             Version/release:   0.3
                                             Revision:          none
                                             Date:              May 16, 2006




ebIX                                                                             May 16, 2006
Technical PKI interoperability in the European energy sector                                                                                        2


                                                             CONTENTS

0      MANAGEMENT SUMMARY .................................................................................................... 8
    0.1       BACKGROUND ......................................................................................................................... 8
    0.2       KEY RECOMMENDATIONS ........................................................................................................ 8
1      INTRODUCTION ....................................................................................................................... 10
    1.1       ABOUT THIS DOCUMENT ........................................................................................................ 10
    1.2       SCOPE OF PROJECT ................................................................................................................. 10
    1.3       PARTICIPANTS IN THE PROJECT ............................................................................................. 10
    1.4       REFERENCES .......................................................................................................................... 11
    1.5       CHANGE LOG ......................................................................................................................... 11
2      CERTIFICATE POLICY INTRODUCTION (CP) ................................................................. 12
    2.1    OVERVIEW (CP)..................................................................................................................... 13
    2.2    NAME AND DESIGNATION OF THE DOCUMENT (CP) ............................................................. 13
    2.3    PKI PARTICIPANTS (CP) ........................................................................................................ 13
      2.3.1    Certification Authorities (CP) ....................................................................................... 14
      2.3.2    Registration Authorities (CP) ........................................................................................ 14
      2.3.3    Certificate Holders (CP) ............................................................................................... 14
      2.3.4    Certificate Users (CP) ................................................................................................... 14
      2.3.5    Other Participants ......................................................................................................... 14
    2.4    CERTIFICATE USAGE (CP) ..................................................................................................... 14
      2.4.1    Permissible Certificate Usage (CP) .............................................................................. 14
      2.4.2    Impermissible Certificate Usage (CP) .......................................................................... 15
    2.5    POLICY MAINTENANCE (CP) ................................................................................................. 15
      2.5.1    Responsibility for the Document (CP) ........................................................................... 15
      2.5.2    Contact Person (CP) ..................................................................................................... 15
      2.5.3    Person Responsible for Accepting a CPS with Regard to this CP (CP) ....................... 15
      2.5.4    CPS Admission Procedure (CP) .................................................................................... 15
    2.6    TERMS AND ABBREVIATIONS (CP) ........................................................................................ 15
      2.6.1    Local Language Terms .................................................................................................. 15
      2.6.2    English Terms ................................................................................................................ 16
      2.6.3    Abbreviations................................................................................................................. 16
      2.6.4    References ..................................................................................................................... 16
3      RESPONSIBILITY FOR DIRECTORIES AND PUBLICATIONS (CP) ............................. 17
    3.1       DIRECTORIES (CP) ................................................................................................................. 17
    3.2       PUBLISHING INFORMATION AND CREATING CERTIFICATES (CP) ......................................... 17
    3.3       TIME AND FREQUENCY OF PUBLICATIONS (CP) .................................................................... 17
    3.4       ACCESS CONTROL FOR DIRECTORIES (CP) ........................................................................... 17
4      IDENTIFICATION AND AUTHENTICATION (CP) ............................................................ 19
    4.1    NAMING RULES ..................................................................................................................... 19
      4.1.1     Types of Name (CP) ...................................................................................................... 19
      4.1.2     Necessity of Meaningful Names (CP) ............................................................................ 19
      4.1.3     Anonymity or Pseudonyms of Certificate Holders (CP) ................................................ 19
      4.1.4     Rules for Interpreting Various Forms of Name (CP) .................................................... 19
      4.1.5     Uniqueness of Names (CP)............................................................................................ 20
      4.1.6     Acceptance, Authentication and the Role of Proprietary Names .................................. 20
    4.2    INITIAL IDENTITY CHECK (CP) .............................................................................................. 20
      4.2.1     Methods for Checking Ownership of the Private Key ................................................... 20
      4.2.2     Authentication of Organization Affiliation .................................................................... 21
      4.2.3     Requirements for Identifying and Authenticating the Certificate Applicant (CP)......... 21
      4.2.4     Unchecked Information on the Certificate Holder ........................................................ 21


ebIX                                                                                                                           May 16, 2006
Technical PKI interoperability in the European energy sector                                                                                3


      4.2.5    Checking Authorization for Submitting an Application ................................................ 21
      4.2.6    Criteria for Deploying Interoperating Systems/Units ................................................... 21
    4.3    IDENTIFYING AND AUTHENTICATING REKEYING APPLICATIONS ......................................... 21
      4.3.1    Identifying and Authenticating Routine Rekeying Applications .................................... 22
      4.3.2    Identification and Authentication for Rekeying after Revocation (CP)......................... 22
    4.4    IDENTIFYING AND AUTHENTICATING REVOCATION APPLICATIONS (CP) ............................ 22
5      OPERATING REQUIREMENTS ............................................................................................. 23
    5.1     CERTIFICATE APPLICATION ................................................................................................... 23
      5.1.1      Who Can Submit a Certificate Application? ................................................................. 23
      5.1.2      Registration Process and Responsibilities (CP) ............................................................ 23
    5.2     PROCESSING THE CERTIFICATE APPLICATION....................................................................... 23
      5.2.1      Identification and Authentication .................................................................................. 23
      5.2.2      Accepting or Rejecting Certificate Applications ........................................................... 23
      5.2.3      Intervals for Processing Certificate Applications ......................................................... 24
    5.3     ISSUING CERTIFICATES .......................................................................................................... 24
      5.3.1      Activities Carried out by the Certification Service Provider when Certificates are
      Issued 24
      5.3.2      Informing the Certificate Holder that the Certificate is Ready for Issue ...................... 24
    5.4     ACCEPTING THE CERTIFICATE ............................................................................................... 24
      5.4.1      Procedure for Accepting a Certificate .......................................................................... 24
      5.4.2      Publication of the Certificate by the CA/Secure Distribution by the Trust Center ....... 25
      5.4.3      Informing Other PKI Participants that the Certificate is Ready for Issue .................... 25
    5.5     USING THE KEY PAIR AND CERTIFICATE............................................................................... 25
      5.5.1      Usage of the Private Key and Certificate by the Certificate Holder ............................. 25
      5.5.2      Usage of the Public Key and Certificate by the Certificate User; Certificate Renewal 25
    5.6     CERTIFICATE RENEWAL ........................................................................................................ 26
      5.6.1      Conditions for Renewing a Certificate .......................................................................... 26
      5.6.2      Who May Renew a Certificate? ..................................................................................... 26
      5.6.3      Processing an Application for Certificate Renewal ...................................................... 26
      5.6.4      Informing the Certificate Holder that a New Certificate is Ready for Issue ................. 26
      5.6.5      Procedure for Accepting a Renewed Certificate ........................................................... 26
      5.6.6      Publication of the Renewed Certificate by the CA ........................................................ 27
      5.6.7      Informing Other PKI Participants that a Certificate has been Renewed ...................... 27
    5.7     CERTIFICATE FOR KEY RENEWAL ......................................................................................... 27
      5.7.1      Conditions for Certificates for Key Renewal................................................................. 27
      5.7.2      Who May Apply for Certificates for Key Renewal ........................................................ 27
      5.7.3      Processing Certificate Applications for Key Renewal .................................................. 27
      5.7.4      Informing the Certificate Holder that the Follow-On Certificate is Ready for Issue .... 27
      5.7.5      Procedure for Accepting Certificates for Key Renewal ................................................ 27
      5.7.6      Publication of Certificates for Key Renewal by the CA ................................................ 27
      5.7.7      Informing Other PKI Participants that the Follow-On Certificate is Ready for Issue.. 27
    5.8     CHANGING CERTIFICATES ..................................................................................................... 28
      5.8.1      Conditions for Changing a Certificate .......................................................................... 28
      5.8.2      Who May Apply for a Certificate Change? ................................................................... 28
      5.8.3      Processing an Application for Changing a Certificate ................................................. 28
      5.8.4      Informing the Certificate Holder that a New Certificate is Ready for Issue ................. 28
      5.8.5      Procedure for Accepting a Certificate Change ............................................................. 28
      5.8.6      Publication of the Certificate Change by the CA .......................................................... 28
      5.8.7      Informing Other PKI Participants that a New Certificate is Ready for Issue ............... 28
    5.9     REVOKING AND SUSPENDING CERTIFICATES ........................................................................ 28
      5.9.1      Conditions for Revoking a Certificate ........................................................................... 28
      5.9.2      Who May Apply for a Revocation? ................................................................................ 29
      5.9.3      Procedure for Revocation Applications ........................................................................ 29
      5.9.4      Intervals for Revocation Applications ........................................................................... 29


ebIX                                                                                                                    May 16, 2006
Technical PKI interoperability in the European energy sector                                                                                        4


      5.9.5  Interval for Processing the Revocation Application (by the CA) .................................. 29
      5.9.6  Methods Available for Checking Revocation Information ............................................ 29
      5.9.7  Frequency with which CRLs are Published (CP) .......................................................... 29
      5.9.8  Maximum Latency for CRLs (CP) ................................................................................. 29
      5.9.9  Online Availability of Revocation Information (CP) ..................................................... 30
      5.9.10 Requirements for Checking Revocation Information Online (CP) ................................ 30
      5.9.11 Others Ways of Displaying Revocation Information (CP) ............................................ 30
      5.9.12 Special Requirements if the Private Key is Compromised ............................................ 30
      5.9.13 Conditions for Suspension ............................................................................................. 30
      5.9.14 Who May Apply for a Suspension? ................................................................................ 30
      5.9.15 Procedure for Suspension Applications ........................................................................ 30
      5.9.16 Limiting the Duration of Suspensions ........................................................................... 30
    5.10 STATUS QUERY SERVICE FOR CERTIFICATES (CP) ............................................................... 30
      5.10.1 Functional Description of the Status Query Service ..................................................... 31
      5.10.2 Availability of the Status Query Service (CP) ............................................................... 31
      5.10.3 Optional Services .......................................................................................................... 31
    5.11 CANCELLATION BY THE CERTIFICATE HOLDER .................................................................... 31
    5.12 KEY ESCROW AND RECOVERY .............................................................................................. 31
      5.12.1 Conditions and Procedure for Private Key Escrow and Recovery ............................... 31
      5.12.2 Conditions and Procedure for Session Key Escrow and Recovery ............................... 31
6      NON-TECHNICAL SECURITY MEASURES (CP) ............................................................... 32
    6.1     CONSTRUCTIONAL SECURITY MEASURES ............................................................................. 32
      6.1.1     Location and Building ................................................................................................... 32
      6.1.2     Access ............................................................................................................................ 32
      6.1.3     Electricity, Heating and Air Conditioning .................................................................... 32
      6.1.4     Hazard Through Water ................................................................................................. 32
      6.1.5     Fire Protection .............................................................................................................. 32
      6.1.6     Warehouse and Archive................................................................................................. 32
      6.1.7     Waste Disposal .............................................................................................................. 32
      6.1.8     Disaster Backup ............................................................................................................ 32
    6.2     PROCESS REGULATIONS ........................................................................................................ 32
      6.2.1     Role Concept ................................................................................................................. 33
      6.2.2     Principle of Control Requiring at Least Two Persons .................................................. 33
      6.2.3     Identification and Authentication for Individual Roles ................................................. 33
      6.2.4     Role Exclusions ............................................................................................................. 33
    6.3     PERSONNEL CONTROL ........................................................................................................... 33
      6.3.1     Requirements Regarding Qualification, Experience and Reliability ............................ 33
      6.3.2     Methods for Verifying General Conditions ................................................................... 33
      6.3.3     Requirements Regarding Training ................................................................................ 33
      6.3.4     Frequency of Training and Briefing .............................................................................. 33
      6.3.5     Frequency and Sequence of Job Rotation ..................................................................... 33
      6.3.6     Measures for Unauthorized Actions .............................................................................. 33
      6.3.7     Requirements Regarding Freelance Personnel ............................................................. 33
      6.3.8     Documents that Must be Made Available to Personnel ................................................ 34
    6.4     MONITORING MEASURES ...................................................................................................... 34
      6.4.1     Types of Recorded Event ............................................................................................... 34
      6.4.2     Frequency of Processing Records ................................................................................. 34
      6.4.3     Retention Period for Records ........................................................................................ 34
      6.4.4     Medium-Term Storage of Records................................................................................. 34
      6.4.5     Record Backup .............................................................................................................. 34
      6.4.6     Short-Term Storage of Records (Internal / External) .................................................... 34
      6.4.7     Informing the Parties that Triggered the Event............................................................. 34
      6.4.8     Assessment of Vulnerability........................................................................................... 34
    6.5     ARCHIVING RECORDS ............................................................................................................ 34


ebIX                                                                                                                           May 16, 2006
Technical PKI interoperability in the European energy sector                                                                                           5


      6.5.1    Types of Archived Record.............................................................................................. 35
      6.5.2    Retention Periods for Archived Data ............................................................................ 35
      6.5.3    Medium-Term Storage of Archives................................................................................ 35
      6.5.4    Archive Backup.............................................................................................................. 35
      6.5.5    Requirements for Time Stamping Records .................................................................... 35
      6.5.6    Archiving (Internal / External) ...................................................................................... 35
      6.5.7    Procedure for Obtaining and Verifying Archive Information ....................................... 35
    6.6    KEY CHANGES AT THE CSP (CP) .......................................................................................... 35
    6.7    SECURITY COMPROMISED AND MAINTAINING BUSINESS OPERATIONS AT THE CSP (CP) ... 35
      6.7.1    Handling Incidents and Cases of Security Being Compromised ................................... 35
      6.7.2    Cases in which Computer Resources, Software and/or Data are Compromised .......... 35
      6.7.3    Private Key of the CSP Compromised (CP) .................................................................. 35
      6.7.4    Options for Continuing Business Operations after Security has been Compromised ... 36
    6.8    CLOSING A CSP OR REGISTRATION AUTHORITY (CP) .......................................................... 36
7      TECHNICAL SECURITY MEASURES .................................................................................. 37
    7.1    CREATING AND INSTALLING KEY PAIRS ............................................................................... 37
      7.1.1    Creating Key Pairs ........................................................................................................ 37
      7.1.2    Delivering Private Keys to the Certificate Holder ........................................................ 37
      7.1.3    Delivering Public Keys to the Certificate Issuer ........................................................... 37
      7.1.4    Delivering CSP Public Keys to the Certificate User ..................................................... 37
      7.1.5    Key Lengths (CP) .......................................................................................................... 37
      7.1.6    Defining Parameters for Public Keys and Quality Control (CP).................................. 37
      7.1.7    Key Usage (CP) ............................................................................................................. 37
    7.2    MEDIUM-TERM STORAGE OF PRIVATE KEYS AND REQUIREMENTS FOR CRYPTOGRAPHIC
    MODULES .......................................................................................................................................... 38
      7.2.1    Standards and Security Measures for Cryptographic Modules .................................... 38
      7.2.2    Safeguarding Private Keys Against Multiple Access (n of m) ....................................... 38
      7.2.3    Storing Private Keys ...................................................................................................... 38
      7.2.4    Medium-Term Storage of Private Keys ......................................................................... 38
      7.2.5    Archiving Private Keys .................................................................................................. 38
      7.2.6    Transferring Private Keys to or from Cryptographic Modules ..................................... 38
      7.2.7    Short-Term Storage of Private Keys in Cryptographic Modules .................................. 38
      7.2.8    Activating Private Keys ................................................................................................. 39
      7.2.9    Deactivating Private Keys ............................................................................................. 39
      7.2.10 Destroying Private Keys ................................................................................................ 39
      7.2.11 Assessing Cryptographic Modules ................................................................................ 39
    7.3    OTHER ASPECTS OF KEY PAIR MANAGEMENT...................................................................... 39
      7.3.1    Archiving Public Keys ................................................................................................... 39
      7.3.2    Validity Periods of Certificates and Key Pairs (CP) ..................................................... 39
    7.4    ACTIVATION DATA ................................................................................................................ 39
      7.4.1    Activation Data.............................................................................................................. 39
      7.4.2    Protecting Activation Data ............................................................................................ 39
      7.4.3    Other Aspects of Activating Data .................................................................................. 39
    7.5    SECURITY MEASURES IN COMPUTER SYSTEMS .................................................................... 40
      7.5.1    Specific Technical Security Requirements in Computer Systems .................................. 40
      7.5.2    Assessing Computer Security ........................................................................................ 40
    7.6    TECHNICAL MEASURES DURING THE LIFE CYCLE ................................................................ 40
      7.6.1    Security Measures During Development ....................................................................... 40
      7.6.2    Security Measures for Computer Management ............................................................. 40
      7.6.3    Security Measures During the Life Cycle ...................................................................... 40
    7.7    SECURITY MEASURES FOR NETWORKS ................................................................................. 40
    7.8    TIME STAMPS......................................................................................................................... 40
8      PROFILES OF CERTIFICATES, CRLS AND OCSP (CP)................................................... 41



ebIX                                                                                                                              May 16, 2006
Technical PKI interoperability in the European energy sector                                                                                     6


    8.1    CERTIFICATE PROFILES ......................................................................................................... 41
      8.1.1    Version Numbers (CP) .................................................................................................. 41
      8.1.2    Certificate Extensions (CP) ........................................................................................... 41
      8.1.3    Algorithm OIDs ............................................................................................................. 41
      8.1.4    Name Formats (CP) ...................................................................................................... 41
      8.1.5    Name Restrictions.......................................................................................................... 41
      8.1.6    OIDs of the Certificate Guidelines ................................................................................ 41
      8.1.7    Using the “Policy Constraints” Extension.................................................................... 41
      8.1.8    Syntax and Semantics of “Policy Qualifiers” ............................................................... 42
      8.1.9    Processing the Semantics of the Critical Extension “Certificate Policy” .................... 42
    8.2    CRL PROFILES (CP)............................................................................................................... 42
      8.2.1    Version Number(s) (CP) ................................................................................................ 42
      8.2.2    Extending CRLs and CRL Entries ................................................................................. 42
    8.3    PROFILES OF THE STATUS QUERY SERVICE (OCSP) (CP)..................................................... 42
      8.3.1    Version Number(s) (CP) ................................................................................................ 42
      8.3.2    OCSP Extensions (CP) .................................................................................................. 42
9      AUDITS AND OTHER ASSESSMENTS ................................................................................. 43
    9.1       FREQUENCY OF AND CONDITIONS FOR AUDITS .................................................................... 43
    9.2       AUDITOR IDENTITY/QUALIFICATIONS................................................................................... 43
    9.3       RATING SCALE OF AUDITOR FOR EVALUATION .................................................................... 43
    9.4       TOPICS COVERED BY AUDITS ................................................................................................ 43
    9.5       RESPONSE TO INADEQUACIES................................................................................................ 43
10         OTHER FINANCIAL AND LEGAL CONCERNS ............................................................. 44
    10.1 CHARGES ............................................................................................................................... 44
      10.1.1 Charges for Certificates or Certificate Renewals ......................................................... 44
      10.1.2 Charges for Accessing Certificates ............................................................................... 44
      10.1.3 Charges for Revocations or Status Information ............................................................ 44
      10.1.4 Charges for Other Services ........................................................................................... 44
      10.1.5 Rules for Cost Reimbursements ..................................................................................... 44
    10.2 FINANCIAL RESPONSIBILITIES ............................................................................................... 44
      10.2.1 Insurance Coverage ...................................................................................................... 44
      10.2.2 Other Items .................................................................................................................... 44
      10.2.3 Insurance or Guarantee for the End User ..................................................................... 44
    10.3 DEGREE OF CONFIDENTIALITY OF BUSINESS DATA .............................................................. 44
      10.3.1 Definition of Confidential Information .......................................................................... 44
      10.3.2 Information that is not Confidential .............................................................................. 44
      10.3.3 Responsibilities for Protecting Confidential Information ............................................. 45
    10.4 DATA PROTECTION FOR PERSONAL DATA ............................................................................ 45
      10.4.1 Data Protection Concept ............................................................................................... 45
      10.4.2 Data Handled as Personal Data ................................................................................... 45
      10.4.3 Data not Handled as Personal Data ............................................................................. 45
      10.4.4 Responsibilities for Data Protection ............................................................................. 45
      10.4.5 Note and Consent Regarding the User of Personal Data ............................................. 45
      10.4.6 Information Regarding Legal or Governmental Regulations........................................ 45
      10.4.7 Other Conditions Regarding Information ..................................................................... 45
    10.5 INTELLECTUAL PROPERTY RIGHT ......................................................................................... 45
    10.6 ASSURANCES AND GUARANTEES .......................................................................................... 46
      10.6.1 Assurances and Guarantees of the CA .......................................................................... 46
      10.6.2 Assurances and Guarantees of the RA .......................................................................... 46
      10.6.3 Assurances and Guarantees of the Certificate Holder .................................................. 46
      10.6.4 Assurances and Guarantees of the Certificate User ..................................................... 46
      10.6.5 Assurances and Guarantees of Other PKI Participants ................................................ 46
    10.7 EXCLUSION OF LIABILITY...................................................................................................... 46


ebIX                                                                                                                         May 16, 2006
Technical PKI interoperability in the European energy sector                                                                                  7


  10.8 LIMITATION OF LIABILITY ..................................................................................................... 46
  10.9 DAMAGES .............................................................................................................................. 46
  10.10    VALIDITY PERIOD AND TERMINATION .............................................................................. 46
    10.10.1    Validity Period .......................................................................................................... 46
    10.10.2    Termination ............................................................................................................... 46
    10.10.3    Effects of Termination and Continuity ...................................................................... 46
  10.11    INDIVIDUAL NOTIFICATIONS AND AGREEMENTS WITH PARTICIPANTS (CP) ................... 46
  10.12    SUPPLEMENTS .................................................................................................................... 47
    10.12.1    Procedure for Supplements ....................................................................................... 47
    10.12.2    Notification Mechanisms and Intervals ..................................................................... 47
    10.12.3    Conditions for OID Changes ..................................................................................... 47
  10.13    PROVISIONS FOR ARBITRATION AND DISPUTES ................................................................ 47
  10.14    UNDERLYING LAW (CP) .................................................................................................... 47
  10.15    COMPLIANCE WITH APPLICABLE LAW .............................................................................. 47
  10.16    OTHER STIPULATIONS ....................................................................................................... 47
    10.16.1    Declaration of Completeness .................................................................................... 47
    10.16.2    Delimitations ............................................................................................................. 47
    10.16.3    Severability Clause .................................................................................................... 47
    10.16.4    Enforcement (Lawyer’s Fees and Waiver to File an Appeal) ................................... 48
    10.16.5    Force Majeure ........................................................................................................... 48
  10.17    OTHER STIPULATIONS ....................................................................................................... 48
APPENDIX A                KEY TERMS IN A PUBLIC KEY INFRASTRUCTURE .............................. 49




ebIX                                                                                                                      May 16, 2006
Technical PKI interoperability in the European energy sector                                             8


0 MANAGEMENT SUMMARY
This document is the seventh in a series of publications from the ebIX project “DigSig” regarding the
use of encryption and digital signatures within the European energy sector. Being defined in a general
manner, the organizational parts aim at ensuring a uniform organizational security level with regard to
electronic signature and encryption of transactions between market participants across company
boundaries.

The technical parts of the documents, defined as well in a general manner, are to ensure interoper-
ability at a technical level even where different products or services are utilized. The political,
organizational and technical statements represent recommendations which are to enable a reliable
trustworthy infrastructure to be set up among market participants along the lines of solidarity.

These measures shall serve as a guide for implementation within companies and for subsequent
application at market interfaces. However, procedures other than proposed in the recommendations
need to be justifiable and must not impair the general level of security.

For economic reasons, market participants should be interested in making sure that the infrastructure
of confidence is not undermined. This is the only way to guarantee secure handling of electronic
business in the medium term, and to ensure that further automation steps can be managed in the light
of future developments.

0.1    Background

A contractual relationship between the relevant partners is recommended for cross-organizational
Electronic Data Interchange (EDI) and is, in fact, prescribed for electronic invoice exchange. The
contract must in this case be based on EU recommendation 94/820/EC e.g. in accordance with
Turnover Tax Law. The contract must contain appropriate passages that guarantee the “authenticity of
origin” and “integrity of the content”.

The aim here at association level is to provide a ready-made document that acts as a point of reference
for partners between which a bilateral contractual relationship exists. This document contains
requirements and information regarding general security conditions that should be accepted by the
contracting parties. In the interests of simplicity, this should take the form of a separate document; the
content of which has been amended accordingly, which then serves as an appendix to the contract.

The contractual basis of an EDI relationship is provided by 3 documents:

1) Standard EDI contract according to 94/820/EC

2) Appendix 1: Interoperability
   Note regarding the EDI message formats used in accordance with the ebIX specifications and their
   required general technical conditions.

3) Appendix 2: Security
   Relevant Certificate Policy or comparable documents of the contracting parties with reference to
   the ebIX recommendations for general security conditions.

A sound contractual basis can thereby be provided with the minimum of effort, which is both desirable
and, for the purpose of network usage billing, is prescribed by law.

0.2    Key recommendations




ebIX                                                                                      May 16, 2006
Technical PKI interoperability in the European energy sector                                                 9


This document contains general, binding requirements, for publishing a Certificate Policy (CP), for
operation of the PKI by the relevant market participants. An individual company CP can be published
in part or in its entirety (see restrictions below) and, therefore, characterize the security level of the
PKI. It is strongly recommended that the CP is published on the Web site of the market participant.
The CP must comply with the requirements of the ebIX CP and the basic recommendations in the
technical and organizational policy documents that have already been published.

A PKI Disclosure Statement (PDS) can be used if a contract is to be based on a less extensive
document. The PDS contains those parts of a CP that the market participant wishes to exchange with
other parties in order to allow these other parties to reach a decision regarding the reliability of the
PKI. It is the minimum amount of information required to be able to assess the security level of the
PKI.

This document is suitable for and cited expressly as confirmation in bilateral contracts for data
exchange with business partners regarding how certificate-based general security conditions are put
into practice. The contract must contain clearly-defined provisions that guarantee the “authenticity of
origin” and “integrity of the content” of the invoice data exchanged. This is what this document
achieves.

The recommendations were originally defined in RFC 2527. This was replaced by RFC 3647 on
December 1, 2003. Accordingly, this document is structured in accordance with RFC 3647 and
contains all of the sections specified in it. (CP) in the headings indicates the points that are CP relevant
and which must, therefore, be regarded as obligatory. Prioritizing information in this way complies
with the practices of the European Bridge CA and the general ebIX recommendations. As no
distinction is made by RFC 3647, all sections are included here as specified in RFC 3647 even if
information is not available on all the individual points in this document.




ebIX                                                                                       May 16, 2006
Technical PKI interoperability in the European energy sector                                            10


1 INTRODUCTION
1.1    About this document

Within the European energy sector, electronic data interchange (EDI) using a variety of methods has
become a core business enabler over the last few years. It is no longer possible to imagine how
liberalised energy markets would function without EDI; rapid and automatic interchange and
processing of business transactions, as far as possible without human intervention, is organisationally
and economically necessary for all participants at all levels. Whether the transactions contain metering
data, invoices, customer switching information or schedules: automation brings benefits through
process optimisation. Nevertheless, there are further, fundamental considerations – political,
organisational and technical – to bear in mind, which influence implementation.

Core processes with a high-volume character require supporting processes within the organisation.
Securing EDI transactions is one such supporting process, especially in connection with transparency
and integrity of the data involved. Just as a signature gives a piece of paper legal character – e. g. from
an offer to a contract – EDI requires the same legal status for security and non-repudiation. To this
end, it is essential that a secure business partner network be established, within which electronic
business transactions for all participants are made possible. Therefore we need to promote an
infrastructure which can be trusted both by larger corporations (with their own certification
authorities) and smaller companies (who buy-in from service providers).

This can only be guaranteed by verification and confidentiality mechanisms directly associated with
the information exchanged. These mechanisms need to cover the whole range of the logical
transactions consistently. This is necessary to be able to carry out transactions in the new deregulated
market between market participants in a legally correct and clear-cut manner in terms of liability law,
and not least in an inexpensive way under technical and organisational aspects.

1.2    Scope of project

In the light of these requirements, a small project (“DigSig”) was established within the ebIX structure
to generate appropriate documentation which can then be used as a basis for implementation scenarios
on a national and/or international level. The intention is to describe the overall harmonisation
requirements for the use of encryption and digital signatures for electronic transactions within the
European energy sector; also being compatible with the following overall ebIX objectives:

1) Make recommendations of common procedures that facilitate the common open European energy
   market
2) Make common standards for secure data interchange that can automate the process to reduce the
   costs for the parties involved.

1.3    Participants in the project

The project is based on documents produced within the German national group (under the able
tutoring of Dr. Willi Kafitz, Siemens AG, Frankfurt) and has been coordinated for ebIX by Carl W.
Major. The following participants provided intellectual and/or financial support to the project:




ebIX                                                                                       May 16, 2006
Technical PKI interoperability in the European energy sector                             11



Country         Name                                       Company
DE              Carl W. Major                              E.ON Netz
DE              Dr. Konstantin Staschus                    VDN
DK              Erik Hartwell                              Energinet.dk
BE              Hugo Dekeyser                              Eandis
SE              Joachim Abrahmsén                          Steria
NL              Lodewijk ter Haar                          Tennet
FI              Matti Vasara                               Fingrid
NO              Per M. Breistein                           Statkraft
NO              Ole Jacob Høyland                          Statnett
SE              Oscar Ludwigs                              Svenska Kraftnät
SE              Robert Lundin                              Steria
CH              Rudolf Baumann                             ETRANS

1.4     References

[1] Original project proposal, see http://www.ebix.org/

1.5     Change log

 Ver.    Rel.   Rev.   Date               Changes
 0       1      none   2006-01-26         Document generated
 0       2      none   2006-02-28         Comments incorporated
 0       3      none   2006-05-16         Publication as ebIX RFC




ebIX                                                                          May 16, 2006
Technical PKI interoperability in the European energy sector                                               12



2 CERTIFICATE POLICY INTRODUCTION (CP)
This is the recommendation for a Certificate Policy (CP) for the parties involved in secure electronic
data exchange in the electricity industry.

On account of the special role of data exchange as a sphere of trust that extends across organizations,
both technical and organizational requirements regarding conformity are formulated as part of the
DigSig project.

Participants must focus on the two basic criteria:

1) Technical conformity
2) Adequate and comparable security levels

Technical conformity for achieving interoperability is described in the document “Technical PKI-
Interoperability”. The information in this document is based originally on the stipulations of the
German Signature Alliance.

This document addresses the 2nd criterion.

In future, participants must create their own CP (which can also be implemented as a CPS) which
conforms to this structure in accordance with RFC 3647.

The objective here is to increase the level of trust between the parties involved in secure data exchange
participants through transparency.

A further objective is to define minimum requirements (“must”) for participating PKIs and their
architectures that are to be part of the contractual documents of bilateral contracts (in particular EDI
contracts).

With regard to electronic signatures, one specific aim is to achieve a sufficiently high level of security
to allow advanced signatures that are generated in this environment to be classified as adequately
secure.

The aim of the formal structure according to RFC 3647 is to provide greater transparency and
comparability than has been the case to date. The purpose of the document is to achieve a discernable
comparability between the policies and, as a result, the security levels.

It should be possible to use this document and its member-specific variants as a reference document
for contractual provisions between participants of the EB CA (suitable as a reference for bilateral
contracts).

This should be implemented by the end of 2007.

This CP only considers certificates issued to persons (end entity). Certificate usage (KeyUsage)
includes the following:

    Electronic signature (ContentCommitment, previously: NonRepudiation),
    Authentication (DigitalSignature) and
    Encryption (DataEncipherment, KeyEncipherment).

Other KeyUsages for end-entity certificates are not considered in this CP.




ebIX                                                                                       May 16, 2006
Technical PKI interoperability in the European energy sector                                             13


An additional requirement is that these certificates can only be used for secure e-mail communication
based on the S/MIME format.

Note: According to an international standardization agreement, the following applies when
interpreting the KeyUsage bits: the term "NonRepudiation” is replaced by the term
“ContentCommitment" in order to avoid misunderstandings with regard to the KeyUsage
DigitalSignature and NonRepudiation.

2.1    Overview (CP)

This document provides details of the following (irrespective of the recommendatory nature of
association documents):

     Requirements, which from the point of view of the association, are not open to discussion
      (required)
     Desirable recommendations (desired) and
     Optional information (optional)

It is used to establish cross-organizational confidential relationships. Public key infrastructures
specific to the company or infrastructures available on the market should be used in order to map
secure electronic business processes.

Market participants should use this document as a basis for creating their own internal and external
documents which have the same structure (chapters).

1) In the external document, the market participant should confirm these general requirements and
   publish these without disclosing any technical or organizational details (CP).
2) In the internal document, all stipulations should be documented in accordance with auditing
   requirements (CPS). The individual points in this document will also contain confidential
   company information.

The CP should be part of the contract in bilateral communication relationships; the valid version of
the CP is always published.

The CPS should be incorporated in the procedural documentation according to Fiscal Code and is not
generally published.

When a PKI is set up in accordance with the ebIX DigSig recommendations, an infrastructure of
confidence is created for the workstations in question which makes technical and organizational
demands on and impacts the communications structures outside the company.

The requirements concerning the security level shall be fulfilled by all participants. The extent to
which they are fulfilled affects the credibility of the infrastructure and the confidence placed in it and
its processes by the communication partners.

2.2    Name and Designation of the Document (CP)

This Certificate Policy is entitled:
“ebIX PKI Certificate Policy”.
Version: 0,3
Object Identifier (OID): see Appendix 1, Key Terms

2.3    PKI Participants (CP)




ebIX                                                                                       May 16, 2006
Technical PKI interoperability in the European energy sector                                               14


Participants are organizations that operate their own Public Key Infrastructures or who request
certification service providers to issue certificates.

2.3.1    Certification Authorities (CP)

Certification authorities (CAs) issue certificates within or on behalf of the participant organizations,
which fulfill the obligations of this CP.

This CP refers to the CA, which is run on behalf of the market participant (Issuer) or in its own name,
and refers to further CAs that are compliant with this CP.

2.3.2    Registration Authorities (CP)

Registration authorities (RA) are entities that provide processes for issuing end user certificates.

Registration authorities (RAs) carry out registrations within or on behalf of the participant
organizations, which fulfill the obligations of this CP.

The operators of registration authorities shall ensure that the applicant has been identified uniquely
before the end user certificate is issued.

RA and CA must communicate by means of adequately secure transportation channels.

2.3.3    Certificate Holders (CP)

Description of the entities that can be personal or institutional certificate holders:

Certificate holders are natural persons only who belong to the participant organization or its majority
holdings or who act on their behalf. In line with the security requirements that partners or external
personnel have to fulfill, PKI participants can also be certificate owners providing they have a
business or contractual relationship with the market participant or a subsidiary.

2.3.4    Certificate Users (CP)

Certificate users are all entities that use PKI certificates. Examples of certificate users include market
participants who use certificates for secure e-mail communication.

2.3.5    Other Participants

Participants who have not entered into any commitments with regard to this CP are not part of this
Policy and are not considered here.

2.4     Certificate Usage (CP)

Only personal certificates are used within the PKI.

The use of non-personal certificates is not considered here.

2.4.1    Permissible Certificate Usage (CP)

Certificates can be used by certificate holders for secure applications for authentication purposes,
electronic signatures and message decryption. Certificate users can use certificates for validating
authentication and electronic signatures, as well as for encrypting messages.




ebIX                                                                                       May 16, 2006
Technical PKI interoperability in the European energy sector                                           15


2.4.2    Impermissible Certificate Usage (CP)

The signature certificate must not be used for encryption purposes and vice versa.

The certificates of natural persons must not be issuer certificates.

2.5     Policy Maintenance (CP)

Changes to CP-relevant parts must be updated and published within a reasonable period of time. The
authors recommend 2 weeks.

2.5.1    Responsibility for the Document (CP)

Responsibility for this document is held by:
ebIX
c/o VDN
Robert Koch Platz 4
10115 Berlin
Germany

The issuer name on the certificate is the organizational unit responsible of the market participant.

2.5.2    Contact Person (CP)

VDN
Dr. Konstantin Staschus
Robert Koch Platz 4
10115 Berlin
Germany

(Name of the person responsible at the MARKET PARTICIPANT).

2.5.3    Person Responsible for Accepting a CPS with Regard to this CP (CP)

CPS documents shall be checked within a company by an authorized entity (in accordance with 2.5.1)
to ensure that they comply with CP specifications. An accepted CPS can be regarded as being CP
compliant.

2.5.4    CPS Admission Procedure (CP)

A defined committee shall be responsible for accepting the CPS.

Association recommendations state that this committee should include at least one representative in
accordance with 1.5.1 and one representative of the area responsible for the CPS.

2.6     Terms and Abbreviations (CP)

See preliminary remarks and Appendix 1 ”Key Terms and Definitions in a PKI”

Readers who are not sufficiently familiar with PKI terminology are urgently recommended to study
these definitions before reading any further.

2.6.1    Local Language Terms




ebIX                                                                                      May 16, 2006
Technical PKI interoperability in the European energy sector              16


2.6.2   English Terms

2.6.3   Abbreviations

2.6.4   References




ebIX                                                           May 16, 2006
Technical PKI interoperability in the European energy sector                                              17



3 RESPONSIBILITY FOR DIRECTORIES AND PUBLICATIONS (CP)
The certification service provider is the executive entity for making certificates and revocation lists
available. In the case of sensitive directory information, the necessary quality of the data must be
ensured. Sensitive data includes names, certificates, e-mail addresses and revocation lists.

3.1    Directories (CP)

The participant must provide access to revoked data.

The participant ensures that the directory services are provided accordingly within the scope of his
security policy and in line with the current state-of-the-art.

Certificates should be made available in an externally accessible directory for external certificate
users. Access should be fully qualified, for example, by means of the e-mail address via LDAP and/or
http. A wildcard search will not produce any results or cannot be carried out. Synchronization methods
can be used to publish certificates in other repositories.

CRLs must be published at:
http://www.xxx.yyy/pki/crl or at
ldap://xxx.yyy.zzz

3.2    Publishing Information and Creating Certificates (CP)

The participant agrees to make those parts of his security policy that concern operation of the PKI
available to the other participants involved in the procedure.

Responsible for content:
Area, department, where appropriate name (unique identification)
Following the appropriate approval, the CP is published externally at
xxx.yyy.zzz/pki/cp (suggestion).

3.3    Time and Frequency of Publications (CP)

Directory information and other critical information regarding termination of operations or
deregistration, for example, must be published and made available to the participants involved in the
procedure.

Policies, as well as changes to the participating PKI and its architecture must be published and made
available in good time to the participants involved in the procedure.

Certificates should be published in the external directory service once they have been created. A CRL
should not be valid for more than one month and must be renewed immediately when a new entry is
made.

New versions of a CP are published within 2 weeks of them being approved.

3.4    Access Control for Directories (CP)

Only authorized entities are granted write access. External read access is fully qualified, for example,
by means of the e-mail address via LDAP and/or http. A wildcard search will not produce any results
or cannot be carried out.




ebIX                                                                                      May 16, 2006
Technical PKI interoperability in the European energy sector                                             18


The operator of the directory services must ensure that access control for the relevant directories is
properly implemented.




ebIX                                                                                      May 16, 2006
Technical PKI interoperability in the European energy sector                                             19



4 IDENTIFICATION AND AUTHENTICATION (CP)
CA, RA and natural persons are considered.

4.1      Naming Rules

Natural persons can have pseudonyms (for example, Head of Accounting). The assignment of a
pseudonym to a natural person must be documented. If requested by both parties, the identity must be
disclosed.

4.1.1     Types of Name (CP)

In the case of the CA, RA and certificate holder, names are assigned as DistinguishedNames in
accordance with standard [X.501].

Standard [X.501] is authoritative for assigning names for certificates. The attribute
DistinguishedName is obligatory for assigning names.

If the certificates contain e-mail addresses, it is recommended that these are stored under the X.509
extension SubjectAltName in the format defined in RFC 822.

4.1.2     Necessity of Meaningful Names (CP)

Personal certificates are issued within the PKI. The type of certificate (server, role, organizational
certificates) must be clearly identifiable for the recipient.

The names used in certificates, that is, the technical name specified in the field for the certificate
holder (subject) should be meaningful. It must always be apparent whether a name is real or whether it
is a pseudonym.

4.1.3     Anonymity or Pseudonyms of Certificate Holders (CP)

A certificate that is issued under a pseudonym or anonymously must also be recognizable as such.
Pseudonyms are preferred because of the fact that the certificates are intended for a specific purpose
and not because of the anonymity of the person involved. This can affect the following:

     Signature (for example, Head of Accounting)
     Encryption (for example, info@xxx.com)
     Authentication (for example, Corporate Directory Administrator)

Even when certificates are created with pseudonyms, the real identity of the certificate holder must be
documented by the RA or CA.

4.1.4     Rules for Interpreting Various Forms of Name (CP)

Name assignments according to X.500 / RFC 822.

The attributes of names (DistinguishedName to [X.501]) can be interpreted as follows:

    G                   First name(s) of the natural person in accordance with the document submitted
                        for identification.
    SN                  Last name of the natural person in accordance with the document submitted for


ebIX                                                                                       May 16, 2006
Technical PKI interoperability in the European energy sector                                            20


                      identification.
  CN                  Usual name: In the case of natural persons without a pseudonym, this is the
                      combination of "last name, first name“; in the case of persons with a
                      pseudonym, this is the combination of “pseudonym:PN“; in the case of legal
                      persons, this is the official name of the company or authority. In the case of
                      technical components (server), this is the name of the server, service or
                      application that uses the certificate.
  PSEUDO              Pseudonym is identical to CN in the case of persons with a pseudonym.
  SER                 Serial number that ensures the uniqueness of the name in the PKI.
  O                   Name of the company or authority to which the certificate holder belongs or is
                      associated with, or by which the technical component is operated. The affiliation
                      of a certificate holder to a company or authority must be verified by means of an
                      employee identity card or equivalent document when identification is carried
                      out. The organization name O must be the complete name of the company or
                      authority from the Commercial Register or another familiar short name. The
                      certificate holder must provide credible evidence that a short name applies to
                      organization concerned.
  OU                  Organizational unit (department, area or other subdivision) of the company or
                      authority. An organizational unit (OU) can only be defined if an organization
                      (O) has been defined. The affiliation of a certificate holder to an organizational
                      unit must be verified by the organization by means of an employee identity card
                      or equivalent document when identification is carried out.
  C                   The country to be specified in the ISO 3166 code is determined as follows: If the
                      name contains an organization O, the head office of the organization is in
                      country C. If the name does not contain an organization O, the certificate holder
                      has identified himself with a document from country C.

In the case of encryption and authentication certificates, the e-mail address of the certificate holder
should be entered (in the SubjectAltName in RFC822 format or within the DistinguishedName). It is
recommended that the e-mail address of the certificate holder is entered in the signature certificate
(SubjectAltName or DN).

4.1.5    Uniqueness of Names (CP)

When names are assigned (user or PKI certificates), it is important to ensure that the selected
DistinguishedName of the certificate holder is unique within the issuing CA. The name of the issuer
certificate must be unique within the participating PKI.

4.1.6    Acceptance, Authentication and the Role of Proprietary Names

No requirements.

4.2     Initial Identity Check (CP)

The process chain for applying for and creating a certificate must, both from a technical and
organizational point of view, exclude the possibility of the application process being misused with a
view to acquiring a certificate with the associated public and private keys using a false identity or
other incorrect information.

(ebIX DigSig requirement: unique identification)

4.2.1    Methods for Checking Ownership of the Private Key




ebIX                                                                                     May 16, 2006
Technical PKI interoperability in the European energy sector                                               21


The registration authority must define processes and requirements in accordance with its security
policy that allow checks to be carried out to determine that the certificate holder is the holder of the
private key.

4.2.2    Authentication of Organization Affiliation

It is indispensable that the applicant is obliged to complete an application form containing, among
other things, information on affiliation to the organization. The correctness of this information must be
checked as part of the registration process when the application is made.

4.2.3    Requirements for Identifying and Authenticating the Certificate Applicant (CP)

Personal identification, for example, by presenting an official photo ID.

This can have taken place at an earlier stage, for example, when the employee was hired.

The registration authority must ensure that identification is carried out reliably and that the application
data is checked thoroughly in line with its security policy, which is based for example on the current
baseline IT security as defined by BSI (Bonn).

4.2.4    Unchecked Information on the Certificate Holder

The registration authority must check the information on the certificate holder by comparing the
applicant data on the application form with the data on the ID and the entries in the central directory
service or other reliable databases. Verification excludes errors regarding the way in which names and
organizational data are written and inconsistent entries are recognized. The registration authority must
ensure that unchecked information does not concern the link between the person and the key pair, key
activation data, name or e-mail address.

4.2.5    Checking Authorization for Submitting an Application

A check must be carried out to determine whether employees are authorized to take part in electronic
business, for example. This should be carried out as part of an internal process for defining roles and
rights.

4.2.6    Criteria for Deploying Interoperating Systems/Units

Criteria must be defined for the interoperation of key services, for example, registration and
certification, which do not affect the result of unique identification, for example, in the form of unique
registration data. This applies to all operational processes affected by 3.2. This applies in particular
when certification is carried out by an external service provider while other PKI operational processes
take place either entirely or in part within the organization. (For example, umlauts (ä, ö, ü) not
converted consistently).

4.3     Identifying and Authenticating Rekeying Applications

Identification and authentication on account of a key or certificate being renewed for the CA, RA and
end entities must not have a negative effect on unique identification.

The requirements regarding the amount of documentary evidence verifying identity can, however, be
less stringent than for initial registration because the RA has already archived documentary evidence.

Cancellation of a suspension must be carried out reliably.




ebIX                                                                                       May 16, 2006
Technical PKI interoperability in the European energy sector                                               22


4.3.1     Identifying and Authenticating Routine Rekeying Applications

Management of the Public Key Infrastructure users takes place at the registration authorities and
includes, for example, monitoring the life cycle of the certificates. Recertification (on the basis of the
old key) can be carried out with a valid certificate by means of the self service method; this also
applies to rekeying (on the basis of a new key).

4.3.2     Identification and Authentication for Rekeying after Revocation (CP)

No requirements, providing those in 4.2.3 are fulfilled.

A revoked certificate cannot be renewed by means of the self service method. The personalization
process is then carried out by the registration authority in the same way as initial personalization.

4.4     Identifying and Authenticating Revocation Applications (CP)

Applications for revoking a user certificate shall be submitted by the following persons:

     User
     Disciplinary supervisor of the user
     Personnel department
     Person responsible at CA
     IT security officer

The certificate is revoked after the user has been identified and authenticated accordingly.

If a user certificate is to be revoked by other persons, a written or authenticated application shall be
submitted to the registration authority stating the reasons for this. The registration authority
authenticates the identity of the applicant and determines whether the applicant has the appropriate
authorization. The process must be documented by the registration authority.




ebIX                                                                                       May 16, 2006
Technical PKI interoperability in the European energy sector                                             23



5 OPERATING REQUIREMENTS
All natural persons who are employees of the market participant or majority holdings or who act on
their behalf and who, according to their job descriptions, are users of the IT infrastructure are
authorized to submit an application to the registration authority for a user certificate. According to the
CP of the PKI, the corresponding roles are as follows:

     User (internal)
     Where appropriate, trustee (for externals)

5.1     Certificate Application

The certificate application shall help identify the applicant uniquely and must document the result of
the application process.

The application shall contain the appropriate fields for this:
Information that must be provided includes the last name, first name, e-mail address, unique internal
ID such as the personnel number, and the signature.

5.1.1     Who Can Submit a Certificate Application?

Users or other persons may only apply for certificates in their own name.

5.1.2     Registration Process and Responsibilities (CP)

Generally speaking, it must be possible to audit the process in order to verify that unique identification
has been carried out in accordance with the requirements in 3.2.
The certificate application must contain information that allows the certificate holder to be identified
uniquely.

5.2     Processing the Certificate Application

The following sequence must be adhered to:

     Application
     Registration
     Certification
     Certificate publication

A process step that has not been completed impedes the steps that follow. It is not possible to submit
information or complete a process step subsequently.

5.2.1     Identification and Authentication

An application that has been completed in full and, where appropriate, signed (electronically) by the
trustee is used as a basis for the mandatory identification and authentication of the person applying for
a user certificate. During the application process for user certificates, the identity of the applicant is
then verified by means of legitimization, identification or by the applicant being known personally.

5.2.2     Accepting or Rejecting Certificate Applications

The decision regarding the acceptance or rejection of an application for a user certificate is made by
the employee responsible at the registration authority for certifying user certificates.


ebIX                                                                                       May 16, 2006
Technical PKI interoperability in the European energy sector                                              24



The following requirements must be fulfilled for an application to be accepted:

     Application form that has been completed in full
     Positive identity check
     Positive verification of the application data

Reasons for rejecting an application for a user certificate include:

     Information not complete
     No signature provided
     Discrepancies when verifying the user data

The applicant is informed as to whether the application has been accepted or rejected.

5.2.3     Intervals for Processing Certificate Applications

No requirements in the CP.

5.3     Issuing of Certificates/Key Material

The process of issuing user certificates is performed exclusively by an authorized employee of the
registration authority.

The entire process must be documented. Verification must be provided indicating that the applicant is
in possession of the private key. The certificate is issued by means of the personalized medium
carrying the key material being collected personally by the employee at the registration authority or by
means of a similar process that prevents abuse (e.g. certificate handed over by supervisor,
representative or a designated trustworthy person, for example for field employees). The employee
confirms that he has received the key material carrier, the certificates and the keys by signing the form
used beforehand. This may be carried out electronically.

5.3.1     Activities Carried out by the Certification Service Provider when Certificates are Issued

The CA sends confirmation to the RA (as far as possible in PKCS#10 format) that the application has
been successful.

Certificates may only be issued for certificate applications that have been accepted. The activities
involved in issuing the certificate must be carried out in line with documented processes. It must be
ensured that the certificate holder and private key are uniquely linked.

5.3.2     Informing the Certificate Holder that the Certificate is Ready for Issue

The certificate holder is notified in writing that the certificate is ready to be issued. E-mail may be
used for this purpose.

5.4     Accepting the Certificate

The user certificate is accepted personally by the user at the registration authority or by means of a
similar, secure process.

5.4.1     Procedure for Accepting a Certificate




ebIX                                                                                       May 16, 2006
Technical PKI interoperability in the European energy sector                                                25


The issuing authority must use documented processes to describe the secure handover and conditions
under which the certificate is accepted.

The certificate recipient provides written confirmation that the certificate has been received and that
the applicable processes and guidelines have been taken note of. When the key material carrier is
handed over, the user is also provided with a PIN for the carrier. This is handed over or sent to the user
separately. This PIN protects the private key, for example, on the carrier. The user must provide
adequate protection against any form of compromise. This PIN acts as a transport PIN. Before the
certificate is used for the first time, this PIN must be changed by the certificate holder only and must
not be disclosed to anyone else.

5.4.2     Publication of the Certificate by the CA/Secure Distribution by the Trust Center

The certificates are published in accordance with the directory service concept and are generated at
regular intervals following a plausibility check. The intervals are defined.

If the certificates are not to be published, it must at least be possible to validate them using the CRL.

5.4.3     Informing Other PKI Participants that the Certificate is Ready for Issue

No personal notification is provided.

5.5     Using the Key Pair and Certificate

The ebIX document “Management of key material” applies here correspondingly.

5.5.1     Usage of the Private Key and Certificate by the Certificate Holder

The token provided by the market participant for the individual applications must be used as a carrier
for user certificates and keys. This can be a diskette/soft token, smart card or USB token.

The private key of the PKI user must be used for all applications that match the usage types specified
in the end user certificate. The following basic usage types are possible:

     Authentication of user and application data (usage type: digital signature)
     Decryption of user or application data or of symmetric keys used for encrypting such data with the
      hybrid method (usage types: dataEncryption and KeyEncryption)
     Indication of the liability (usage type: non-repudiation) of an electronic signature by the certificate
      holder.

5.5.2     Usage of the Public Key and Certificate by the Certificate User; Certificate Renewal

The public key of the PKI user must be used for all applications that match the usage types specified
in the end user certificate. The following basic usage types are possible:

     Check authentication of user and application data (usage type: digital signature)
     Encryption of user or application data or of symmetric keys used for encrypting such data with the
      hybrid method (usage types: dataEncryption and KeyEncryption)
     Liability (usage type: non-repudiation) of an electronic signature checked by the certificate holder.

Note: According to an international standardization agreement, the following applies when
interpreting the KeyUsage bits: the term "NonRepudiation” is replaced by the term
“ContentCommitment" in order to avoid misunderstandings with regard to the KeyUsage
DigitalSignature and NonRepudiation.


ebIX                                                                                         May 16, 2006
Technical PKI interoperability in the European energy sector                                             26



5.6     Certificate Renewal

5.6.1     Conditions for Renewing a Certificate

Conditions for user certificates:

     Certificates must be renewed in good time before the period of validity expires.
     Certificates can only be revoked if an appropriate reason is given (see 5.9).

The following requirements must also be fulfilled for the renewal procedure:

     The certificate holder continues to be a user of the IT infrastructure.
     Positive application procedure (self service method with valid certificate and adequate general
      organizational and/or technical conditions, for example, secure messaging).
     Positive verification of the user data with the data in the directory service.
     Positive identity check at the registration authority.
     Availability of the functional user token.

From an organizational point of view, it may be necessary for written notification to be issued
beforehand by the registration authority.

5.6.2     Who May Renew a Certificate?

An application for a certificate renewal can be made by the holder of a user certificate.

5.6.3     Processing an Application for Certificate Renewal

Processing an application for certificate renewal must be a well-documented procedure that fulfills the
requirements for identification as specified in 3.3.2.

As in 4.2.2, the following sequence must be adhered to:

     Application
     Registration
     Certification
     Certificate publication

A process step that has not been completed impedes the steps that follow. It is not possible to submit
information or complete a process step subsequently.

In contrast to 5.2.2, self service processes are possible by means of a valid certificate and secure
applications because unique identification can be carried out electronically.

5.6.4     Informing the Certificate Holder that a New Certificate is Ready for Issue

The certificate holder is informed in accordance with documented processes.

See 5.3.2.

5.6.5     Procedure for Accepting a Renewed Certificate

See 5.4.1.




ebIX                                                                                        May 16, 2006
Technical PKI interoperability in the European energy sector                                                 27


5.6.6     Publication of the Renewed Certificate by the CA

See 5.4.2.

5.6.7     Informing Other PKI Participants that a Certificate has been Renewed

See 5.4.3.

5.7     Certificate for Key Renewal

5.7.1     Conditions for Certificates for Key Renewal

The conditions for private and public user keys are as follows:

     Key renewal is required as part of certificate renewal if the key length is regarded as insufficient
      by the CA or
     The key has been revoked as a result of an appropriate reason being given (see 4.9).

Similar requirements to those specified in 4.6.1 must also be fulfilled for the renewal procedure:

5.7.2     Who May Apply for Certificates for Key Renewal

See 5.6.2.

5.7.3     Processing Certificate Applications for Key Renewal

See 5.6.3 for certificate holders.

The process steps between the RA and CA must also be carried out as with an initial application
because key generation, importing the data to the PSE, and secure transportation are required here too.

5.7.4     Informing the Certificate Holder that the Follow-On Certificate is Ready for Issue

Certificate users for whom the renewal process is due to be performed as a result of the fact that the
validity period of the certificate is about to expire (for example, 80%) are informed in writing by the
registration authorities of the planned renewal. E-mail may be used for this purpose.

5.7.5     Procedure for Accepting Certificates for Key Renewal

Due to the key pairs being regenerated, the process as described in 4.4.1 must be carried out by the
services (RA, CA, Chip Card Management, and so on).

Registration and briefing are not required for the end user.

5.7.6     Publication of Certificates for Key Renewal by the CA

5.7.7     Informing Other PKI Participants that the Follow-On Certificate is Ready for Issue

No requirements.

If extensions to the key length are planned (for example, to 2048-bit RSA key length), the external
organizations with the most certificate users must be informed in good time because problems can
occur with interoperability.




ebIX                                                                                        May 16, 2006
Technical PKI interoperability in the European energy sector                                             28


5.8     Changing Certificates

5.8.1     Conditions for Changing a Certificate

No conditions; from a technical point of view, this means that a new certificate is issued.

5.8.2     Who May Apply for a Certificate Change?

This process is handled by the company in question.

5.8.3     Processing an Application for Changing a Certificate

This process is handled by the company in question.

5.8.4     Informing the Certificate Holder that a New Certificate is Ready for Issue

This process is handled by the company in question.

5.8.5     Procedure for Accepting a Certificate Change

See processes in 5.4 for general aspects.

5.8.6     Publication of the Certificate Change by the CA

A modified CA certificate must be published immediately for the members involved in the procedure.
See processes in 4.4 for general aspects.

5.8.7     Informing Other PKI Participants that a New Certificate is Ready for Issue

The members involved in the procedure must be informed immediately that a CA certificate has been
changed.

See processes in 5.4 for general aspects.

5.9     Revoking and Suspending Certificates

5.9.1     Conditions for Revoking a Certificate

The certification authority must specify the conditions under which a certificate is revoked. A
certificate must be revoked when:

     the key is compromised,
     the unique assignment between the certificate and its superordinate certificate can no longer be
      ensured,
     the unique link between the certificate and key can no longer be ensured.


The following reasons can result in a user certificate being revoked:

     An employment relationship is terminated
     Release from work/leave of absence (for example, for military service)
     Change of name, for example as a result of marriage or reorganizational measures (DN changed)
     The private key is misused
     General suspicion of security being compromised or misuse



ebIX                                                                                      May 16, 2006
Technical PKI interoperability in the European energy sector                                             29


   Situation has occurred in which security has been compromised or misuse has been established
   A carrier with key material (token) is found
   A higher-level certificate is revoked
   The carrier with the key material is damaged or lost

5.9.2   Who May Apply for a Revocation?

The following persons, for example, can apply for a user certificate to be revoked:

   The employee himself
   The disciplinary supervisor of the employee
   A manager in the personnel department (user certificates)
   An employee of central security services
   An employee of the registration authority
   An employee of the certification authority

5.9.3   Procedure for Revocation Applications

There are three possible ways of revoking a certificate:

1) The certificate is revoked by the certificate holder who presents himself in person to the
   registration authority
2) The certificate is revoked by the certificate holder who submits an application to the registration
   authority either by telephone or in writing
3) The certificate is revoked by a person from one of the groups specified in 5.9.2 safeguarding the
   security interests of the market participant or other organizations in the infrastructure of trust.

5.9.4   Intervals for Revocation Applications

All users of the PKI are obliged to initiate a revocation either themselves or with the help of an
authorized employee as soon as one of the reasons specified in 5.9.1 is established.

5.9.5   Interval for Processing the Revocation Application (by the CA)

The period of time from the point at which the application is received by the registration authority
responsible and the point at which the revocation becomes effective when the CRL is published with
the revoked certificate must be as short as possible (latency).

5.9.6   Methods Available for Checking Revocation Information

The authorized employee checks that reasons for the certificate being revoked (see 5.9.1) have been
given.

5.9.7   Frequency with which CRLs are Published (CP)

The frequency with which certificate revocation lists are published must be documented by the
certification authority.

The interval within which a new CRL is made available must be as short as possible.

5.9.8   Maximum Latency for CRLs (CP)

The maximum latency for certificate revocation lists must be documented by the certification
authority.



ebIX                                                                                      May 16, 2006
Technical PKI interoperability in the European energy sector                                           30



A maximum latency of 24 hours is recommended.

5.9.9   Online Availability of Revocation Information (CP)

The certification authority must make revocation information available online. Availability of this
online service must be documented.

The CRL is published on the Internet at http://xxx.yyy.zzz/pki/crl or ldap://xxx.yyy.zzz within one
day.

5.9.10 Requirements for Checking Revocation Information Online (CP)

External certificate users can also check revocation information online at http://xxx.yyy.zzz/pki/crl or
ldap://xxx.yyy.zzz. Online checks via a separate OCSP responder are not yet possible.

5.9.11 Others Ways of Displaying Revocation Information (CP)

Revocation information can also be provided by means of a positive list (“white list”). All certificates
currently available in directory services are valid. Certificates that have been revoked are removed
from the directory services within as short a space of time as possible.

No delta CRL should be used initially, however, because they are not supported generally.

5.9.12 Special Requirements if the Private Key is Compromised

The time intervals specified above must be taken into account when revocation information is
published after a certificate has been revoked if the private key is compromised.

5.9.13 Conditions for Suspension

A certificate can only be suspended in situations that have proven to be uncritical, in other words,
there is no suspicion of the key material being corrupt or the token being misused. Otherwise a
revocation must be performed.

5.9.14 Who May Apply for a Suspension?

See 5.9.2.

5.9.15 Procedure for Suspension Applications

See 5.9.3.

5.9.16 Limiting the Duration of Suspensions

The suspension can, if requested, be canceled within a reasonable period of time. A revocation must
then be performed.

5.10 Status Query Service for Certificates (CP)

Manual status queries use LDAP or http.

An automatic service uses LDAP or OCSP (to be implemented).




ebIX                                                                                     May 16, 2006
Technical PKI interoperability in the European energy sector                                          31


5.10.1 Functional Description of the Status Query Service

An online status query service is not planned for the first project phase.

5.10.2 Availability of the Status Query Service (CP)

The availability of the status query service must be documented. Current status information must be
made available within as short a space of time as possible.

5.10.3 Optional Services

No information currently available.

5.11 Cancellation by the Certificate Holder

Organizational changes that render the use of certificates inappropriate are described in 4.9.1 and
inevitably result in certificates being revoked.

5.12 Key Escrow and Recovery

No provision is made for a key escrow in Germany. Key recovery must not be used for signature keys
or authentication keys. Key recovery is permitted for encryption keys. Other countries need to define
their own requirements.

If a key is escrowed, the certification service provider must document the associated processes. These
must conform with the service provider's own security policy and the current state-of-the-art.

5.12.1 Conditions and Procedure for Private Key Escrow and Recovery

No information provided in the CP.

5.12.2 Conditions and Procedure for Session Key Escrow and Recovery

No information provided in the CP.




ebIX                                                                                     May 16, 2006
Technical PKI interoperability in the European energy sector                                           32



6 NON-TECHNICAL SECURITY MEASURES (CP)
In line with the current state-of-the-art (for example, IT basic protection manual or BS 7799).

6.1     Constructional Security Measures

The central components of the Public Key Infrastructure must, on account of their importance for
corporate communication, be provided with special protection against failure and attacks.

6.1.1    Location and Building

In internal documents (CPS), the physical location is documented and any changes that occur are
included as quickly as possible.

6.1.2    Access

See Constructional Safety Measures.

6.1.3    Electricity, Heating and Air Conditioning

Suitable measures (for example, UPS) ensure that no transactions between the RA and CA are lost as a
result of interference in this area.

6.1.4    Hazard Through Water

See Constructional Safety Measures.

6.1.5    Fire Protection

See Constructional Safety Measures.

6.1.6    Warehouse and Archive

Documents and logging lists are archived in accordance with the requirements for archiving personal
documents. Write access to these documents must be prevented once they have been archived. The
key material (encryption keys) is archived in such a way that only authorized persons (for example, in
accordance with the principle of dual control) are permitted to perform a key recovery (if requested).

6.1.7    Waste Disposal

Confidential documentation is disposed of under the supervision of suitably authorized employees.

6.1.8    Disaster Backup

Measures for providing information and rectifying damage in the event of a breach of security at the
CA or in the event of damage or loss must be documented in accordance with audit requirements.

6.2     Process Regulations

A role concept must be implemented for operational purposes. Detailed documentation must be
provided for the role concept, the relevant sections of which can be inspected by a board of arbitration
should the need arise.




ebIX                                                                                     May 16, 2006
Technical PKI interoperability in the European energy sector                                        33


Role Concept

The role concept must make a distinction between operative, administrative and cross-sectional roles.
The role exclusions defined in the role concept must ensure that individual employees cannot modify
the systems of the Trust Center or other security-critical components of the PKI without this being
noticed, or inspect, create or manipulate certificates, key material or PINs/revocation passwords.

6.2.1    Role Concept

No further information provided in the CP.

6.2.2    Principle of Control Requiring at Least Two Persons

Shall be ensured.

6.2.3    Identification and Authentication for Individual Roles

No information provided in the CP.

6.2.4    Role Exclusions

No information provided in the CP.

6.3     Personnel Control

Shall be ensured.

6.3.1    Requirements Regarding Qualification, Experience and Reliability

Shall be ensured.

6.3.2    Methods for Verifying General Conditions

Shall be ensured.

6.3.3    Requirements Regarding Training

Ensured.

6.3.4    Frequency of Training and Briefing

Ensured.

6.3.5    Frequency and Sequence of Job Rotation

Provisions for this must be defined within the company.

6.3.6    Measures for Unauthorized Actions

Employees who are deemed unreliable in accordance with the criteria of the personnel department are
not allowed to work in security-critical areas.

6.3.7    Requirements Regarding Freelance Personnel




ebIX                                                                                   May 16, 2006
Technical PKI interoperability in the European energy sector                                              34


Freelance personnel deemed unreliable in accordance with the criteria of the personnel department are
not allowed to work in security-critical areas.

6.3.8    Documents that Must be Made Available to Personnel

No information provided in the CP.

6.4     Monitoring Measures

No information provided in the CP.

6.4.1    Types of Recorded Event

All transactions between the CA, RA and Directory with results of plausibility checks at record level
must be recorded in logs.

6.4.2    Frequency of Processing Records

The auditor carries out regular checks to ensure that the systems are functioning correctly.

6.4.3    Retention Period for Records

10 years.

6.4.4    Medium-Term Storage of Records

Records are stored at least in accordance with the requirements of commercial and tax law.

6.4.5    Record Backup

Records are backed up at least in accordance with the requirements of commercial and tax law.

6.4.6    Short-Term Storage of Records (Internal / External)

Records are stored at least in accordance with the requirements of commercial and tax law.

6.4.7    Informing the Parties that Triggered the Event

All those involved in the process must check and ensure that operations run smoothly both from a
technical and operational point of view at any given time.

The checks carried out by the auditor to ensure that operations run smoothly from a technical point of
view will trigger technical inspections at the very latest when irregularities occur, the results of which
must documented.

6.4.8    Assessment of Vulnerability

The PKI is part of the enterprise-critical infrastructure and must be attended to either in its entirety or
in part by those responsible.

6.5     Archiving Records

Archiving is carried out at least in accordance with the requirements of commercial and tax law.




ebIX                                                                                        May 16, 2006
Technical PKI interoperability in the European energy sector                                            35


6.5.1    Types of Archived Record

The following in particular are archived at least in accordance with the requirements of commercial
law: the application form together with the issue logs for the certificates and keys for the validity
period of the certificates including the period of limitation.

6.5.2    Retention Periods for Archived Data

At least 10 years (see 6.5.1).

6.5.3    Medium-Term Storage of Archives

Archives are stored at least in accordance with the requirements of commercial and tax law.

6.5.4    Archive Backup

Archives are backed up at least in accordance with the requirements of commercial and tax law.

6.5.5    Requirements for Time Stamping Records

Time stamps are provided at least in accordance with the requirements of commercial and tax law.

6.5.6    Archiving (Internal / External)

Must be ensured; details regarding implementation can be defined within the company.

6.5.7    Procedure for Obtaining and Verifying Archive Information

Must be ensured; details regarding implementation can be defined within the company.

6.6     Key Changes at the CSP (CP)

Key changes at the certification service provider must be carried out on the basis of documented
processes that conform with the security policy for infrastructure keys of the party in question.

6.7     Security Compromised and Maintaining Business Operations at the CSP (CP)

In the event of security being compromised or if a disaster occurs, the certification service provider
must document processes that conform with the security policy for infrastructure keys of the party in
question.

6.7.1    Handling Incidents and Cases of Security Being Compromised

Incidents must be assessed by the certification service provider and handled in accordance with the
documentation.

6.7.2    Cases in which Computer Resources, Software and/or Data are Compromised

Incidents must be assessed by the certification service provider and handled in accordance with the
documentation.

6.7.3    Private Key of the CSP Compromised (CP)

This scenario must result in all certificates issued by this CA being revoked.



ebIX                                                                                    May 16, 2006
Technical PKI interoperability in the European energy sector                                            36


Notification of the certificates being revoked must be given immediately both within the company and
externally.

This is the scenario that is most likely to occur.

6.7.4    Options for Continuing Business Operations after Security has been Compromised

Not specified; depend on the damage or loss involved.

6.8     Closing a CSP or Registration Authority (CP)

Closing a certification or registration authority must be documented in the form of a process. The
participant must inform the other participants involved in the procedure in good time that he is
terminating his certification services.

Closing the CSP: In this case, the customer ensures, by way of contract, that operations continue
where appropriate under the supervision of a different party until alternative solutions can be found
without causing extensive disruptions to business operations.

Change of perspective:
Closure of an RA that falls in the area of responsibility of an enterprise division/majority holding must
be reported to the CIO. When a registration authority is closed, the certificates are revoked by
employees of this registration authority.




ebIX                                                                                     May 16, 2006
Technical PKI interoperability in the European energy sector                                           37



7 TECHNICAL SECURITY MEASURES
Main objectives: Protection of cryptographic keys, particularly in the Trust Center, and the data for
activating them (PINs, passwords) for the purpose of creating, storing, transporting and using the keys;
concerns the life cycle of keys and certificates, as well as all entities (CA and repositories, RA and end
entities).

The specifications must also include the security checks for development environments and the
development methodology for reliable software.

Provisions for this must be defined within the company.

The technical security measures must be implemented within the scope of the security policy of the
certification authority and in line with the current state-of-the-art.


7.1     Creating and Installing Key Pairs

7.1.1     Creating Key Pairs

Provisions for this must be defined within the company.

7.1.2     Delivering Private Keys to the Certificate Holder

The PSE is issued personally to the user. Receipt must be acknowledged.

7.1.3     Delivering Public Keys to the Certificate Issuer

Public keys are delivered in the form of a file.

7.1.4     Delivering CSP Public Keys to the Certificate User

Public keys are delivered in the form of a file.

7.1.5     Key Lengths (CP)

Key lengths must be in line with the current state-of-the-art and conform with cryptographic methods.

7.1.6     Defining Parameters for Public Keys and Quality Control (CP)

Provisions for this must be defined within the company.
These parameters must comply with ebIX DigSig conformity requirements in line with the document
“Technical PKI-Interoperability“.

7.1.7     Key Usage (CP)

Key usage must be set to

     Digital Signature, and/or
     Encryption

Other usages can be defined by the individual participants.




ebIX                                                                                      May 16, 2006
Technical PKI interoperability in the European energy sector                                                38


Key usage shall be specified by the certification service provider.

7.2     Medium-Term Storage of Private Keys and Requirements for Cryptographic Modules

Provisions for this must be defined within the company.

The certification service provider must ensure that the private key is stored properly and define the
requirements for cryptographic modules in line with his security policy and the current state-of-the-art.

7.2.1    Standards and Security Measures for Cryptographic Modules

The cryptographic modules deployed must use recognized standards.

7.2.2    Safeguarding Private Keys Against Multiple Access (n of m)

Provisions for this must be defined within the company.

7.2.3    Storing Private Keys

Provisions for this must be defined within the company.

It is not permissible to store the private signature key of a participant of the certification authority.

7.2.4    Medium-Term Storage of Private Keys

Provisions for this must be defined within the company.

For the RA, repository, and so on, in accordance with special directives for this particular group of
employees.

For end users in accordance with company guidelines.

7.2.5    Archiving Private Keys

Certification authority keys are not archived.

During the pre-personalization processes for the user, the private encryption key is archived at the
registration authority.

Process Description:
Once the public and private keys have been generated with the certificate at the registration authority,
a PKCS#12 file is made available. Key archiving is activated in the security guidelines of the
certification authority. The PKCS#12 file is then exported by the employees of the registration
authority to the employee token. Once this procedure has been successfully completed, the PKCS#12
file is automatically deleted at the certification authority and is then only located in the secure archive
of the certification authority.

7.2.6    Transferring Private Keys to or from Cryptographic Modules

The technical security measures must be implemented within the scope of the security policy of the
certification authority and in line with the current state-of-the-art.

7.2.7    Short-Term Storage of Private Keys in Cryptographic Modules




ebIX                                                                                         May 16, 2006
Technical PKI interoperability in the European energy sector                                            39


The technical security measures must be implemented within the scope of the security policy of the
certification authority and in line with the current state-of-the-art.

7.2.8    Activating Private Keys

The signature key is activated using a 4-8 digit PIN. The user is informed accordingly that the
Personal Security Environment is being accessed.

The PIN does not have to be entered each time for mass signatures.

7.2.9    Deactivating Private Keys

Deactivation of private keys is time controlled and takes place at least at the end of each session.

7.2.10 Destroying Private Keys

Not relevant.

7.2.11 Assessing Cryptographic Modules

Not relevant.

7.3     Other Aspects of Key Pair Management

Not relevant.

7.3.1    Archiving Public Keys

Not relevant.

7.3.2    Validity Periods of Certificates and Key Pairs (CP)

The key lengths of certificates and key pairs should be extended periodically in order to maintain an
adequate level of security.

E. g.: The recommendations of the Federal Office for Information Security (BSI) apply.

7.4     Activation Data

The certification authority must define suitable processes for transferring activation data securely.

Specifications that are identical to the regulations for employee identity cards are recommended.

7.4.1    Activation Data

Provisions for this must be defined in detail within the company.

7.4.2    Protecting Activation Data

Provisions for this must be defined within the company.

7.4.3    Other Aspects of Activating Data

No requirements.



ebIX                                                                                      May 16, 2006
Technical PKI interoperability in the European energy sector                                        40


7.5     Security Measures in Computer Systems

7.5.1    Specific Technical Security Requirements in Computer Systems

All IT components in the PKI are subject to the security requirements of the existing IT security
guidelines.

7.5.2    Assessing Computer Security

Assessments should be carried out as part of internal audits.

7.6     Technical Measures During the Life Cycle

7.6.1    Security Measures During Development

Assessments should be carried out as part of internal audits.

7.6.2    Security Measures for Computer Management

All IT components in the PKI are subject to the security requirements of the existing IT security
guidelines.

7.6.3    Security Measures During the Life Cycle

Not applicable.

7.7     Security Measures for Networks

All IT components in the PKI are subject to the security requirements of the existing IT security
guidelines.

7.8     Time Stamps

Archiving is carried out in accordance with the basic requirements of Digital Signature legislation
regarding long-term archiving of digitally signed documents. The time stamp service does not have to
provide qualified time stamps.




ebIX                                                                                    May 16, 2006
Technical PKI interoperability in the European energy sector                                         41



8 PROFILES OF CERTIFICATES, CRLS AND OCSP (CP)
The e-mail address should appear in the certificate either

     in the SubjectAltName (rfc822Name, preferred) or
     within the DN (E=)

8.1     Certificate Profiles

8.1.1    Version Numbers (CP)

Certificates conform to standard X.509 v3 (type 0x2).

8.1.2    Certificate Extensions (CP)

The following certificate extensions must be regarded as critical:
- KeyUsage,
- BasicConstraints (only obligatory if a CA certificate is involved)

For KeyUsage and BasicConstraints (of CA certificates), the requirements of ISIS-MTT profiling
must be fulfilled (see [ISIS/MTT] ISIS/MTT Version 1.1, Part 1. Table 12: KeyUsage).

It is generally recommended that as few certificate extensions as possible are set to “critical”.
Exceptions:

The e-mail address shall appear in the certificate either

     in the SubjectAltName (rfc822Name, preferred) or
     within the DN (E=)

8.1.3    Algorithm OIDs

No requirements but should be based on the BSI recommendations.

8.1.4    Name Formats (CP)

Name formats must be documented by the CA. The conformity criteria of the EB CA shall be fulfilled.
The following requirements also apply.

The CommonName (CN) must be specified in the DistinguishedName (DN).
The DN in the end entity certificate must be unique within the issuing CA.
Non-personal certificates must be identifiable as such (in the DN or elsewhere).

8.1.5    Name Restrictions

No requirements.

8.1.6    OIDs of the Certificate Guidelines

No requirements.

8.1.7    Using the “Policy Constraints” Extension



ebIX                                                                                      May 16, 2006
Technical PKI interoperability in the European energy sector                                       42


No requirements.

8.1.8    Syntax and Semantics of “Policy Qualifiers”

No requirements.

8.1.9    Processing the Semantics of the Critical Extension “Certificate Policy”

No requirements.

8.2     CRL Profiles (CP)

A CRL contains the version, signature, issuer name, date issued, issue date for next update, and
revoked certificates.

The CRL reason is not published externally.

8.2.1    Version Number(s) (CP)

Version 1 (or higher) CRLs must be used.

In the interests of interoperability, however, version 2 CRLs (type 0x1) should be used.

8.2.2    Extending CRLs and CRL Entries

No requirements.

8.3     Profiles of the Status Query Service (OCSP) (CP)

Not applicable for the time being.

8.3.1    Version Number(s) (CP)

Not applicable for the time being.

8.3.2    OCSP Extensions (CP)

The certification authority must document OCSP extensions.




ebIX                                                                                    May 16, 2006
Technical PKI interoperability in the European energy sector                                     43



9 AUDITS AND OTHER ASSESSMENTS
9.1    Frequency of and Conditions for Audits

Provisions for this must be agreed upon bilaterally between the companies involved.

9.2    Auditor Identity/Qualifications

Provisions for this must be agreed upon bilaterally between the companies involved.

9.3    Rating Scale of Auditor for Evaluation

Provisions for this must be agreed upon bilaterally between the companies involved.

9.4    Topics Covered by Audits

Provisions for this must be agreed upon bilaterally between the companies involved.

9.5    Response to Inadequacies

Provisions for this must be agreed upon bilaterally between the companies involved.




ebIX                                                                                  May 16, 2006
Technical PKI interoperability in the European energy sector                                         44



10 OTHER FINANCIAL AND LEGAL CONCERNS
10.1 Charges

10.1.1 Charges for Certificates or Certificate Renewals

10.1.2 Charges for Accessing Certificates

10.1.3 Charges for Revocations or Status Information

10.1.4 Charges for Other Services

10.1.5 Rules for Cost Reimbursements

10.2 Financial Responsibilities

10.2.1 Insurance Coverage

10.2.2 Other Items

10.2.3 Insurance or Guarantee for the End User

The issuer ensures that the infrastructure made available via the PKI is suitable, and guarantees the
authenticity of origin and integrity of the content. This means that the infrastructure is particularly
suitable for exchanging invoice data by means of Electronic Data Interchange e.g. in accordance with
section 14, paragraph 3 of the German Turnover Tax Law and other formalized documents. For this
purpose, end users require a bilateral EDI contract in accordance with the requirements of EC
recommendation 94/820/EC with reference to this CP.

10.3 Degree of Confidentiality of Business Data

The participants involved in the procedure ensure that data made accessible to them (for example, CPS
documents from other participants) shall, if requested, be handled in confidence.

The PKI does not define what confidential data is nor does it specify any particular requirements for
handling such data. Provisions for this are, where appropriate, made in other policy documents. It
“merely” provides an infrastructure via which confidential data can be exchanged securely. Provisions
must be agreed upon bilaterally between the partners involved for defining and handling confidential
business data.

10.3.1 Definition of Confidential Information

Confidential information is data that is only made accessible within the scope of the procedure and is
not intended for the general public.

The CPS, which covers the requirements of this CP and which is handled in strictest confidence,
specifies the operational and technical requirements within the PKI for the unit in question.

10.3.2 Information that is not Confidential

Change of perspective:
The CP of the participant involved in the procedure (for example, the market participant) is a subset of
statements from the CPS that can be made publically available.



ebIX                                                                                    May 16, 2006
Technical PKI interoperability in the European energy sector                                             45



10.3.3 Responsibilities for Protecting Confidential Information

Change of perspective:
If proposed by the area responsible of the participant involved in the procedure (for example, the
market participant), the CPS and CP are revised should there be a suitable reason for this.

10.4 Data Protection for Personal Data

The participants ensure that data protection is provided in accordance with the specifications of Data
Protection legislation.

The participants involved in the procedure post certificate information and other personal data in
external (LDAP) directories at their own risk.

The external directory service only responds to fully-qualified queries via a complete and
unambiguous e-mail address.

10.4.1 Data Protection Concept

Provisions for this must be defined in detail within the company.

10.4.2 Data Handled as Personal Data

Provisions for this must be defined in detail within the company.

10.4.3 Data not Handled as Personal Data

Provisions for this must be defined in detail within the company.

10.4.4 Responsibilities for Data Protection

Provisions for this must be defined in detail within the company.

10.4.5 Note and Consent Regarding the User of Personal Data

Within the scope of the provisions for industrial codetermination, it is ensured, as far as possible, that
certificate information may be published externally. It must at least be possible to publish certificate
revocation lists.

10.4.6 Information Regarding Legal or Governmental Regulations

Possible.

10.4.7 Other Conditions Regarding Information

Information is provided to third parties only within the scope of the provisions for the external
directory services and technical access to these.

The CP is published on the Internet at xxx.yyy.zzz. The CP is created in all good conscience and is
maintained regularly. No guarantee of correctness must be provided.

10.5 Intellectual Property Right

Provisions for this must, where appropriate, be defined bilaterally.


ebIX                                                                                       May 16, 2006
Technical PKI interoperability in the European energy sector                                            46



10.6 Assurances and Guarantees

All those involved ensure that a consistently high level of quality is provided with regard to data,
organizational aspects and technical services.

10.6.1 Assurances and Guarantees of the CA

Provisions for this must be agreed upon bilaterally between the companies involved.

10.6.2 Assurances and Guarantees of the RA

The RA is aware of the fact that the registration process and, in particular, unique identification of the
certificate holder are crucial and must, therefore, be afforded the greatest possible care and attention.

10.6.3 Assurances and Guarantees of the Certificate Holder

Agreements and directives that are binding in terms of labor law illustrate the significance and
consequences of using cryptographic keys. This applies in particular to electronic signatures and
identity management.

10.6.4 Assurances and Guarantees of the Certificate User

Certificates are used only for the purpose of the security procedures and can, therefore, be stored
locally via the infrastructure. Further extrinsic purposes, such as collecting e-mail addresses, are
excluded by the certificate user.

10.6.5 Assurances and Guarantees of Other PKI Participants

Not applicable.

10.7 Exclusion of Liability

Provisions for this must be agreed upon bilaterally between the companies involved.

10.8 Limitation of Liability

Provisions for this must be agreed upon bilaterally between the companies involved.

10.9 Damages

Provisions for this must be agreed upon bilaterally between the companies involved.

10.10 Validity Period and Termination

This CP is valid until it is replaced by a different one.

10.10.1 Validity Period

10.10.2 Termination

10.10.3 Effects of Termination and Continuity

10.11 Individual Notifications and Agreements with Participants (CP)



ebIX                                                                                       May 16, 2006
Technical PKI interoperability in the European energy sector                                              47


These must be disclosed if they affect the general security level.

10.12 Supplements

Supplements to the CP must be provided in writing, or if accessed electronically, must be added in
such a way that they can be immediately identified as supplements by the person accessing them.

10.12.1 Procedure for Supplements

In accordance with 10.12.

10.12.2 Notification Mechanisms and Intervals

In accordance with 10.12.

10.12.3 Conditions for OID Changes

An OID for the CP should be assigned and be below (in the certificate hierarchy) the company OID
applied for.

10.13 Provisions for Arbitration and Disputes

Must be agreed upon bilaterally between the companies involved.

10.14 Underlying Law (CP)

Local legislation.

10.15 Compliance with Applicable Law

Ensured.

10.16 Other Stipulations

Must be agreed upon bilaterally between the companies involved.

These must be disclosed if they affect the general security level.

10.16.1 Declaration of Completeness

This document describes basic organizational and technical provisions that must be observed so that a
comparable and guaranteed level of security can be maintained between the market participants during
electronic data exchange.

10.16.2 Delimitations

Not clarified.

10.16.3 Severability Clause

Proposal for bilateral contracts with reference to a CPS based on this CP:
If stipulations in this policy are or become ineffective, or if a loophole is detected in the contract, the
validity of the other stipulations shall not be affected by this. Instead of the ineffective stipulations or
in order to eliminate the loophole, provisions shall apply that – as far as possible from a legal point of



ebIX                                                                                        May 16, 2006
Technical PKI interoperability in the European energy sector                                          48


view – best fulfill the intention of the contractual partners or what they would have intended within the
meaning and purpose of the contract insofar as the point in question had been considered.

10.16.4 Enforcement (Lawyer’s Fees and Waiver to File an Appeal)

Provisions for this must be defined within the company.

10.16.5 Force Majeure

Not clarified.

10.17 Other Stipulations

Not clarified.




ebIX                                                                                     May 16, 2006
Technical PKI interoperability in the European energy sector                                       49



KEY TERMS IN A PUBLIC KEY INFRASTRUCTURE


Advanced signature            In contrast to a simple, electronic signature (for example, a signature
                              that has been cut and pasted), an advanced signature is:
                              a) assigned to the signature key holder only
                              b) enables the signature key holder to be identified
                              c) is created using tools over which the signature key holder has full
                              control, and
                              d) linked to the data (to which it refers) in such a way that it is
                              possible to determine whether the data was changed subsequently.
                              The sphere of confidence in which AS are valid must be defined
                              from an organizational and technical point of view. VEDIS aims to
                              achieve a sound, organizational level of security so that advanced
                              signatures can be accepted both economically and with a minimum
                              of technical outlay.
Asymmetric cryptography       A mathematical data encryption procedure in which two different
                              mathematically related keys are used to encrypt and decrypt data.
Authentication                User authentication
                              Users authenticate themselves vis-à-vis an application on the basis
                              of a certificate using their PSE instead of a user ID and password.
                              The standard used as a basis for this is RFC 3281. A profile has
                              been submitted by ISIS-MTT. VEDIS only uses the PUSH variant
                              of the profile.
Certificate user, relying     These are persons, organizations, processes or devices that use the
party, recipient, verifier,   certificate or the public key it contains for encryption (before the
validator                     data is sent) or verification (after the signed data has been received)
                              purposes.
Certification Authority, CA   Certification Authority: entity, which establishes a link between a
“Trust Center”                public key and a user in the form of a certificate and certifies this
                              with its own digital signature.
Chain model                   According to the chain model validity rule, a certificate chain is
                              technically valid if each certificate in the chain was issued within
                              the validity period of the higher-level certificate.
                              According to section 19, paragraph 5 of the Digital Signature Act,
                              the “validity of….qualified certificates….shall not be affected by a
                              ban on his operations and cessation of operations or by withdrawal
                              and revocation of an accreditation”. According to the German
                              Signature Act, the chain model is, therefore, permitted as a
                              validation model for electronic signatures. (See also shell model)

Chip card                     Credit-card format card with an embedded microchip accessed
                              externally as defined in ISO 7816. If this microchip is equipped with
                              a programmable controller (CPU), the card is called a smart card. In
                              a PKI, highly secure chips with a crypto coprocessor are deployed in
                              virtually all cases if smart cards are used.
Corporate directory,          The corporate directory is a list containing employee-related
directory service             information that is available throughout the company. It is also used
                              to publish certificates and make these available throughout the
                              company or to make part of the information (for example, last name,
                              first name, e-mail address and certificate) available externally by
                              means of suitable mirroring mechanisms.
Crypto algorithm              Set of mathematical rules for carrying out cryptographic operations


ebIX                                                                                 May 16, 2006
Technical PKI interoperability in the European energy sector                                         50


                               (such as encryption and hashing) recursively on the basis of
                               elementary mathematical functions (such as shift, multiplication,
                               calculate remainder) using keys and parameters.
Digital signature (now         An electronic signature cryptographically converts data so that it
referred to as an electronic   cannot be tampered with unnoticeably (protecting the integrity of
signature)                     the data).
                               Digital signature is usually associated with the process of digital
                               signing, which can be subject to regional laws and regulations. The
                               meaning here is more general, that is, it does not correspond to the
                               Digital Signature Act.
Encryption                     Encryption prevents unauthorized persons or third parties from
                               making use of the electronic data transferred. Mathematical methods
                               are used for this purpose that convert (encrypt) the data to a readable
                               yet unusable form. Conversion back to the original form
                               (decryption) can only be performed by authorized persons,
                               organizations, processes or devices.
Hash algorithms                When a document is hashed, a 160-bit number, for example, is first
                               created (one-way function). It is extremely unlikely that the same
                               hash value exists for different documents (collision resistant). The
                               hash value is then signed with the private signature key, that is, it is
                               encrypted so that it can be decrypted with the public key from the
                               certificate.
                               When the document arrives at the recipient, it is validated by means
                               of an independently generated hash value. This hash value is then
                               compared with the hash value that was transferred with the
                               document and encrypted by means of the public signature key. If the
                               two values match, no changes were made to the document after it
                               was signed.
Holder, key holder             The holder of a key is the end user who is assigned a private key (in
                               the form of a Personal Security Environment, or PSE) and is
                               responsible for its correct use.
                               In the case of a personal key pair, the owner is also the holder
                               because it is forbidden to make the personal key available to anyone
                               else.
ISIS-MTT                       Workable profile of the international PKI standards.
                               Conformity can be verified with the test bed.
                               Accepted throughout Germany and gaining ground internationally.
Key backup                     “Key backup” is an entity in the enterprise PKI organization
                               responsible for backing up private keys with which data, of which
                               the non-encrypted original version is no longer available, is to be
                               decrypted. This component of the PKI accepts, stores and provides
                               access to private keys and enables the requirement for recovering
                               original data to be fulfilled. Only the company in question is
                               responsible for key backup.
Key certificate                A certificate is an accreditation confirming that a public key is
                               linked to information that identifies a person, organization, process
                               or device as the user of the associated private key. In the case of a
                               certificate for a personal key, this information basically comprises
                               the identity data of the key owner. In the case of a certificate for a
                               key that is not linked to a person, this information identifies a
                               department, a function, a server, an IT system, or a process that is
                               authorized to use the associated key. This is not discussed here.
Key material                   Personal key material (Personal Security Environment) and the
                               associated (public) key certificate.



ebIX                                                                                   May 16, 2006
Technical PKI interoperability in the European energy sector                                         51


Key, key pair                 Two keys comprising a private and a public key required for the
                              purpose of asymmetric cryptography are referred to here as a key
                              pair, or key for short.
LDAP                          Lightweight Directory Access Protocol
                              LDAP is a TCP/IP-based directory access protocol which has
                              become a standard solution on the Internet and in company intranets
                              for secure directory services.
LRA                           Local Registration Authority;
                              Authorized, user-oriented authority, which identifies and
                              authenticates users and which manages and hands the key material
                              over to the users.
Owner, key owner              The owner of a key pair is the end user who is responsible for
                              ensuring that the private key is used correctly and that its integrity is
                              protected. The owner or issuer (CA) is also responsible for revoking
                              the key pair.
Personal key                  An asymmetric key pair is a personal key pair when the holder and
                              owner of the associated Personal Security Environment have to be
                              the same person, and the name of that person is certified in the
                              certificate.
Personal key, private key     The private key is the secret part of the key pair (of a personal key
                              or function key) that is used in asymmetric cryptography.
Personal Security             PSE
Environment                   The key material in its entirety: in particular the private key,
                              certificates and other information used to identify a user.
                              The main components of the Personal Security Environment (PSE)
                              are the private key and other information belonging to the user who
                              has sole access to the private key. For this reason, the PSE must be
                              protected against unauthorized access. Smart cards, chip cards and
                              diskettes are data carriers on which the PSE is stored.
Personalization               Personal data consolidated to form card data.
PIN, Personal Identity        The PIN is a password with which an end user authenticates himself
Number                        when he accesses the Personal Security Environment. The PIN is
                              used to protect the PSE, in particular the private key it contains.
Policy, PKI                   A security concept comprises organizational and technical measures
                              and is generally stipulated in a security policy.
                              The Public Key Infrastructure is stipulated in a PKI policy and
                              describes the organizational rules and technical components and
                              explains how they interact. The PKI Policy is the central document
                              of a PKI and defines the security level of the PKI. Depending on the
                              target group, statements in the PKI Policy often appear in several
                              other policy documents. The Certificate Policy is the declaration to
                              the business partner which is often contractually binding. The
                              Certificate Practice Statement documents the policies, practices and
                              procedures employed. In customer/contractor relationships, it forms
                              the basis of SLAs.
Private key                   Symmetric cryptography is based on a secret key which is owned by
                              both communication partners.
                              In asymmetric cryptography, each participant has a public key and a
                              private key.
                              The private key is used to sign the document and the public key to
                              check (validate) the signature.
                              Using the private key, the recipient can decrypt the message
                              encrypted with the public key of the recipient (see also public key
                              cryptography).



ebIX                                                                                   May 16, 2006
Technical PKI interoperability in the European energy sector                                      52


Public key                    The public key is the generally accessible part of a key pair that is
                              used in asymmetric cryptography.
Public key cryptography       Encryption method in which 2 different keys are used to encrypt and
                              decrypt a message (this explains the term asymmetric
                              cryptography).
                              In practice, one of these keys is published with the identification
                              data of the holder (= public key); the other key is made available to
                              the holder using a secure means (usually on a smart card) or is
                              generated on the smart card itself.
                              An important application of public key cryptography is the
                              electronic signature where a document is signed with the private key
                              after which the recipient then checks the signature with the public
                              key.
Public Key Infrastructure     PKI
                              The PKI groups together all the entities and processes that are
                              necessary for using public key cryptography.
                              They are usually described in a policy.
Qualified signature           According to section 2 of the Digital Signature Act of May 22,
                              2001:
                              “qualified electronic signatures” are electronic signatures as in 2
                              that
                              a) are based on a qualified certificate valid at the time of their
                              creation and
                              b) have been produced with a secure signature creation device
                              Extensive requirements must be fulfilled in line with the Digital
                              Signature Ordinance in order to issue qualified certificates.
                              In order to make a distinction from qualified electronic signatures
                              with provider accreditation (or qualified accredited signatures for
                              short), this usually refers to the disclosure duty of the ZDA and not
                              voluntary accreditation. From a technical point of view, this means
                              that the registered CA and not the root CA of the Bundesnetzagentur
                              is the uppermost root entity in the validation chain.
                              This avoids any deviations from international standards because, at
                              the time this document went to press, the root CA of the
                              Bundesnetzagentur required RIPEMD and not the usual SHA-1 as a
                              hash algorithm, as well as the chain model and not the usual shell
                              model as a validation model. Only one ZDA currently offers purely
                              qualified certificates (in addition to accredited certificates). Other
                              projects are currently being conducted by the relevant authorities.
Registration                  Establishing the identity of a user in the personalization process at
                              an (L)RA and passing on the data (signed) to the Trust Center by
                              means of a secure channel. An application must have been
                              submitted for this purpose.
                              The participant involved in the procedure for digital signatures is
                              assigned a suitable and, as far as possible, unique name.
Registration authority        Registration authority, also called Local Registration Authority
                              (LRA)
                              Authority responsible for uniquely identifying the end user and
                              issuing the key material.
Revocation                    Certificates can or must in certain cases be revoked by the owner,
                              holder or a third party before the period of validity comes to an end.
                              Possible reasons that necessitate revocation of a certificate include
                              disclosure of the Personal Security Environment (PSE), theft or loss
                              of the PSE or all cases in which misuse of a PSE must be suspected.
                              When a certificate is revoked, use of the certificate and the


ebIX                                                                                May 16, 2006
Technical PKI interoperability in the European energy sector                                       53


                              associated PSE is permanently prevented because it is not possible
                              to reinstate a revoked certificate.
Revoking (a signature         Process used to identify the certificate as invalid (online) when the
certificate)                  signature is checked/validated by the CA or replicated information
                              services.
                              The participant or his representative can have the certificate
                              revoked. The card-issuing entity or the CA as the certificate-issuing
                              entity must act as a representative here. The revocation must contain
                              the time at which it was carried out and must not be retroactive.
                              Information is obligatory.
                              Further requirements regarding revocation management are defined
                              in the Digital Signature Act.
S/MIME                        Secure Multipurpose Internet Mail Extensions
                              Enable e-mails to be sent and received securely.
Security policy               Binding document that describes the security policy of a company.
                              Potential business risks are assessed and, where appropriate, suitable
                              measures are defined. Risks are unexpected negative events and
                              business opportunities that have not been realized. IT security is part
                              of the security policy; the PKI Policy is part of the Security Policy.
                              This document, therefore, supplements the security policy of the
                              company in question.
Shell model                   According to the shell model validity rule, a certificate chain is
                              technically valid if each certificate in the chain is covered by the
                              validity period of the higher-level certificate.
                              According to the first amending law (passed on November 12,
                              2004), section 8 of the Digital Signature Act was modified to allow
                              further reasons for invalidating certificates to be agreed upon
                              contractually. This means that a modified shell model is possible.
Smart card                    Minicomputer the size of a credit card. The card is equipped with a
                              chip (mounted on a module) containing a processor, data memory
                              (file system) and an operating system. One important feature of the
                              operating system is the integrated access protection for data in the
                              file system. The user must enter a correct pin or authenticate himself
                              in order to achieve the appropriate access status so that the data in
                              file can be made accessible to the outside world. The processor also
                              performs cryptographic arithmetic operations autonomously.
Trust Center                  Entity entrusted with the possible tasks of generating key pairs, the
                              safekeeping of key material, as well as issuing, publishing and
                              withdrawing public key certificates. See also Certification
                              Authority, CA.
User, cryptographic            Person (also: end user): Employee, student trainee, apprentice,
methods in the PKI            consultant (working in a company or for a business partner)
                               Organization: Project group (within or outside the company),
                              administrative department, business partner company, and so on.
                               Process: Service, client, server, certification authority, LRA, and
                              so on.
                               Equipment: Computer, router, firewall, and so on.
                               A user such as this is either the user of a Personal Security
                              Environment (PSE) or a certificate, or is himself the purpose for
                              which certificates are used.
Verify, verification,         When a digital signature is verified, a check is carried out to
validation                    determine whether the signed data has been falsified and to establish
                              that it originates from the person, organization, process or device
                              that created the digital signature. See also hash value.


ebIX                                                                                 May 16, 2006
Technical PKI interoperability in the European energy sector              54




ebIX                                                           May 16, 2006

				
DOCUMENT INFO
Shared By:
Categories:
Stats:
views:192
posted:1/31/2011
language:English
pages:54
Description: End User Certificate Management document sample