Fuji Xerox Product Certification Authority

Certificate Policy and Certification Practice Statements

October 7, 2005

2

1. INTRODUCTION................................................................................................................8

1.1. Overview ......................................................................................................................8 1.1.1. Product Certification Authority ...............................................................................8 1.1.2. Background of Product CA ....................................................................................8 1.1.3. Overview of the services of Product CA ..............................................................12

1.2. Document name and identification .............................................................................12 1.3. PKI participants ..........................................................................................................12

1.3.1. Certification authorities ........................................................................................12 1.3.2. Registration authorities........................................................................................13 1.3.3. Subscribers .........................................................................................................13 1.3.4. Relying parties.....................................................................................................13 1.3.5. Other participants ................................................................................................13

1.4. Certificate usage ........................................................................................................13 1.4.1. Appropriate certificate uses .................................................................................13 1.4.2. Prohibited certificate uses ...................................................................................14

1.5. Policy administration...................................................................................................14 1.5.1. Organization administering the document ...........................................................14 1.5.2. Contact person ....................................................................................................14 1.5.3. Person determining CPS suitability for the policy ................................................14 1.5.4. CPS approval procedures ...................................................................................14

1.6. Definitions and acronyms ...........................................................................................15 2. PUBLICATION AND REPOSITORY RESPONSIBILITIES ..........................................19

2.1. Repositories ...............................................................................................................19 2.2. Publication of certification information ........................................................................19 2.3. Time and frequency of publication ..............................................................................19 2.4. Access controls on repositories ..................................................................................19

3. Identification and authentication.....................................................................................20 3.1. Naming .......................................................................................................................20

3.1.1. Types of names ...................................................................................................20 3.1.2. Need for names to be meaningful .......................................................................20 3.1.3. Anonymity or pseudonymity of subscribers .........................................................20 3.1.4. Rules for interpreting various name forms...........................................................20 3.1.5. Uniqueness of names..........................................................................................20 3.1.6. Recognition, authentication, and role of trademarks ...........................................20

3.2. Initial identity validation...............................................................................................20 3.2.1. Method to prove possession of private key .........................................................20 3.2.2. Authentication of organization identity.................................................................20 3.2.3. Authentication of individual identity .....................................................................20 3.2.4. Non-verified subscriber information.....................................................................21 3.2.5. Validation of authority ..........................................................................................21 3.2.6. Criteria for interoperation.....................................................................................21

3.3. Identification and authentication for re-key requests ..................................................21 3.3.1. Identification and authentication for routine re-key ..............................................21 3.3.2. Identification and authentication for re-key after revocation ................................21

3.4. Identification and authentication for revocation request..............................................21 4. CERTIFICATE LIFE-CYCLE OPERATIONAL REQUIREMENTS ..............................22

4.1. Certificate Application .................................................................................................22 4.1.1. Who can submit a certificate application .............................................................22 4.1.2. Enrollment process and responsibilities ..............................................................22

4.2. Certificate application processing ...............................................................................23 4.2.1. Performing identification and authentication functions ........................................23

3

4.2.2. Approval or rejection of certificate applications ...................................................23 4.2.3. Time to process certificate applications...............................................................23

4.3. Certificate issuance ....................................................................................................24 4.3.1. CA actions during certificate issuance.................................................................24 4.3.2. Notification to subscriber by the CA of issuance of certificate .............................24

4.4. Certificate acceptance ................................................................................................24 4.4.1. Conduct constituting certificate acceptance ........................................................24 4.4.2. Publication of the certificate by the CA................................................................24 4.4.3. Notification of certificate issuance by the CA to other entities .............................24

4.5. Key pair and certificate usage ....................................................................................24 4.5.1. Subscriber private key and certificate usage .......................................................24 4.5.2. Relying party public key and certificate usage.....................................................25

4.6. Certificate renewal......................................................................................................25 4.6.1. Circumstance for certificate renewal ...................................................................25 4.6.2. Who may request renewal...................................................................................25 4.6.3. Processing certificate renewal requests ..............................................................25 4.6.4. Conduct constituting acceptance of a renewal certificate ....................................25 4.6.5. Publication of the renewal certificate by the CA ..................................................25 4.6.6. Notification of certificate issuance by the CA to other entities .............................26

4.7. Certificate re-key ........................................................................................................26 4.7.1. Circumstance for certificate re-key ......................................................................26 4.7.2. Who may request certification of a new public key..............................................26 4.7.3. Processing certificate re-keying requests ............................................................26 4.7.4. Notification of new certificate issuance to subscriber ..........................................26 4.7.5. Conduct constituting acceptance of a re-keyed certificate ..................................26 4.7.6. Publication of the re-keyed certificate by the CA .................................................26 4.7.7. Notification of certificate issuance by the CA to other entities .............................26

4.8. Certificate modification ...............................................................................................26 4.8.1. Circumstance for certificate modification .............................................................26 4.8.2. Who may request certificate modification ............................................................26 4.8.3. Processing certificate modification requests........................................................26 4.8.4. Notification of new certificate issuance to subscriber ..........................................27 4.8.5. Conduct constituting acceptance of modified certificate ......................................27 4.8.6. Publication of the modified certificate by the CA .................................................27 4.8.7. Notification of certificate issuance by the CA to other entities .............................27

4.9. Certificate revocation and suspension........................................................................27 4.9.1. Circumstances for revocation ..............................................................................27 4.9.2. Who can request revocation................................................................................27 4.9.3. Procedure for revocation request ........................................................................28 4.9.4. Revocation request grace period.........................................................................29 4.9.5. Time within which CA must process the revocation request................................30 4.9.6. Revocation checking requirement for relying parties ...........................................30 4.9.7. CRL/ARL issuance frequency (if applicable) .......................................................30 4.9.8. Maximum latency for CRL/ARLs (if applicable) ...................................................30 4.9.9. On-line revocation/status checking availability ....................................................30 4.9.10. On-line revocation checking requirements ..........................................................30 4.9.11. Other forms of revocation advertisements available............................................30 4.9.12. Special requirements re key compromise............................................................30 4.9.13. Circumstances for suspension ............................................................................31 4.9.14. Who can request suspension ..............................................................................31 4.9.15. Procedure for suspension request.......................................................................31 4.9.16. Limits on suspension period ................................................................................31

4

4.10. Certificate status services...........................................................................................31 4.10.1. Operational characteristics ..................................................................................31 4.10.2. Service availability...............................................................................................31 4.10.3. Optional features .................................................................................................31

4.11. End of subscription .....................................................................................................31 4.12. Key escrow and recovery ...........................................................................................31

4.12.1. Key escrow and recovery policy and practices....................................................31 4.12.2. Session key encapsulation and recovery policy and practices ............................31

5. FACILITY, MANAGEMENT, AND OPERATIONAL CONTROLS.................................32 5.1. Physical controls ........................................................................................................32

5.1.1. Site location and construction .............................................................................32 5.1.2. Physical access...................................................................................................32 5.1.3. Power and air conditioning ..................................................................................32 5.1.4. Water exposures .................................................................................................33 5.1.5. Fire prevention and protection.............................................................................33 5.1.6. Media storage......................................................................................................33 5.1.7. Waste disposal ....................................................................................................33 5.1.8. Off-site backup ....................................................................................................33

5.2. Procedural controls.....................................................................................................33 5.2.1. Trusted roles .......................................................................................................33 5.2.2. Number of persons required per task ..................................................................36 5.2.3. Identification and authentication for each role .....................................................37 5.2.4. Roles requiring separation of duties ....................................................................37

5.3. Personnel controls......................................................................................................37 5.3.1. Qualifications, experience, and clearance requirements .....................................37 5.3.2. Background check procedures ............................................................................38 5.3.3. Training requirements..........................................................................................38 5.3.4. Retraining frequency and requirements ..............................................................38 5.3.5. Job rotation frequency and sequence .................................................................38 5.3.6. Sanctions for unauthorized actions .....................................................................38 5.3.7. Independent contractor requirements..................................................................38 5.3.8. Documentation supplied to personnel .................................................................39

5.4. Audit logging procedures............................................................................................39 5.4.1. Types of events recorded ....................................................................................40 5.4.2. Frequency of processing log ...............................................................................40 5.4.3. Retention period for audit log ..............................................................................40 5.4.4. Protection of audit log..........................................................................................40 5.4.5. Audit log backup procedures ...............................................................................41 5.4.6. Audit collection system (internal vs. external) .....................................................41 5.4.7. Notification to event-causing subject ...................................................................41 5.4.8. Vulnerability assessments ...................................................................................41

5.5. Records archival.........................................................................................................42 5.5.1. Types of records archived ...................................................................................42 5.5.2. Retention period for archive ................................................................................42 5.5.3. Protection of archive............................................................................................43 5.5.4. Archive backup procedures .................................................................................43 5.5.5. Requirements for time-stamping of records.........................................................43 5.5.6. Archive collection system (internal vs. external)..................................................43 5.5.7. Procedures to obtain and verify archive information............................................43

5.6. Key changeover .........................................................................................................43 5.7. Compromise and disaster recovery ............................................................................43

5.7.1. Incident and compromise handling procedures ...................................................43

5

5.7.2. Computing resources, software, and/or data are corrupted.................................44 5.7.3. Entity private key compromise procedures..........................................................44 5.7.4. Business continuity capabilities after a disaster ..................................................44

5.8. CA or RA termination ..................................................................................................44 6. TECHNICAL SECURITY CONTROLS ...........................................................................45

6.1. Key pair generation and installation............................................................................45 6.1.1. Key pair generation .............................................................................................45 6.1.2. Private key delivery to subscriber........................................................................45 6.1.3. Public key delivery to certificate issuer ................................................................45 6.1.4. CA public key delivery to relying parties ..............................................................45 6.1.5. Key sizes .............................................................................................................46 6.1.6. Public key parameters generation and quality checking......................................46 6.1.7. Key usage purposes (as per X.509 v3 key usage field) ......................................46

6.2. Private Key Protection and Cryptographic Module Engineering Controls...................46 6.2.1. Cryptographic module standards and controls ....................................................46 6.2.2. Private key (n out of m) multi-person control .......................................................47 6.2.3. Private key escrow ..............................................................................................47 6.2.4. Private key backup ..............................................................................................47 6.2.5. Private key archival .............................................................................................48 6.2.6. Private key transfer into or from a cryptographic module ....................................48 6.2.7. Private key storage on cryptographic module .....................................................48 6.2.8. Method of activating private key ..........................................................................48 6.2.9. Method of deactivating private key ......................................................................48 6.2.10. Method of destroying private key.........................................................................49 6.2.11. Cryptographic Module Rating ..............................................................................49

6.3. Other aspects of key pair management ......................................................................49 6.3.1. Public key archival...............................................................................................49 6.3.2. Certificate operational periods and key pair usage periods .................................49

6.4. Activation data ............................................................................................................49 6.4.1. Activation data generation and installation ..........................................................49 6.4.2. Activation data protection ....................................................................................49 6.4.3. Other aspects of activation data ..........................................................................49

6.5. Computer security controls.........................................................................................50 6.5.1. Specific computer security technical requirements..............................................50 6.5.2. Computer security rating .....................................................................................50

6.6. Life cycle technical controls........................................................................................50 6.6.1. System development controls .............................................................................50 6.6.2. Security management controls ............................................................................51 6.6.3. Life cycle security controls ..................................................................................51

6.7. Network security controls ...........................................................................................51 6.8. Time-stamping ............................................................................................................51

7. CERTIFICATE, CRL/ARL, AND OCSP PROFILES .......................................................52 7.1. Certificate profile ........................................................................................................52

7.1.1. Version number(s) ...............................................................................................52 7.1.2. Certificate extensions ..........................................................................................52 7.1.3. Algorithm object identifiers ..................................................................................52 7.1.4. Name forms.........................................................................................................52 7.1.5. Name constraints ................................................................................................52 7.1.6. Certificate policy object identifier .........................................................................52 7.1.7. Usage of Policy Constraints extension ................................................................52 7.1.8. Policy qualifiers syntax and semantics ................................................................52 7.1.9. Processing semantics for the critical Certificate Policies extension.....................52

6

7.2. CRL/ARL profile..........................................................................................................52 7.2.1. Version number(s) ...............................................................................................52 7.2.2. CRL/ARL and CRL/ARL entry extensions ...........................................................52

7.3. OCSP profile...............................................................................................................53 7.3.1. Version number(s) ...............................................................................................53 7.3.2. OCSP extensions ................................................................................................53

8. COMPLIANCE AUDIT AND OTHER ASSESSMENTS .................................................54 8.1. Frequency or circumstances of assessment ..............................................................54 8.2. Identity/qualifications of assessor ...............................................................................54 8.3. Assessor’s relationship to assessed entity .................................................................54 8.4. Topics covered by assessment...................................................................................54 8.5. Actions taken as a result of deficiency........................................................................54 8.6. Communication of results ...........................................................................................55

9. OTHER BUSINESS AND LEGAL MATTERS ................................................................56 9.1. Fees ...........................................................................................................................56

9.1.1. Certificate issuance or renewal fees....................................................................56 9.1.2. Certificate access fees ........................................................................................56 9.1.3. Revocation or status information access fees .....................................................56 9.1.4. Fees for other services ........................................................................................56 9.1.5. Refund policy.......................................................................................................56

9.2. Financial responsibility ...............................................................................................56 9.2.1. Insurance coverage.............................................................................................56 9.2.2. Other assets ........................................................................................................56 9.2.3. Insurance or warranty coverage for end-entities .................................................56

9.3. Confidentiality of business information .......................................................................56 9.3.1. Scope of confidential information ........................................................................56 9.3.2. Information not within the scope of confidential information ................................56 9.3.3. Responsibility to protect confidential information.................................................56

9.4. Privacy of personal information ..................................................................................56 9.4.1. Privacy plan.........................................................................................................57 9.4.2. Information treated as private..............................................................................57 9.4.3. Information not deemed private...........................................................................57 9.4.4. Responsibility to protect private information ........................................................57 9.4.5. Notice and consent to use private information ....................................................57 9.4.6. Disclosure pursuant to judicial or administrative process ....................................57 9.4.7. Other information disclosure circumstances........................................................57

9.5. Intellectual property rights ..........................................................................................57 9.6. Representations and warranties .................................................................................57

9.6.1. CA representations and warranties .....................................................................57 9.6.2. RA representations and warranties .....................................................................57 9.6.3. Subscriber representations and warranties .........................................................57 9.6.4. Relying party representations and warranties .....................................................57 9.6.5. Representations and warranties of other participants..........................................57

9.7. Disclaimers of warranties ...........................................................................................57 9.8. Limitations of liability...................................................................................................57 9.9. Indemnities .................................................................................................................58 9.10. Term and termination..................................................................................................58

9.10.1. Term ....................................................................................................................58 9.10.2. Termination..........................................................................................................58 9.10.3. Effect of termination and survival ........................................................................58

9.11. Individual notices and communications with participants............................................58 9.12. Amendments ..............................................................................................................58

7

9.12.1. Procedure for amendment...................................................................................58 9.12.2. Notification mechanism and period .....................................................................58 9.12.3. Circumstances under which OID must be changed.............................................58

9.13. Dispute resolution provisions......................................................................................58 9.14. Governing law ............................................................................................................58 9.15. Compliance with applicable law..................................................................................58 9.16. Miscellaneous provisions............................................................................................59

9.16.1. Entire agreement.................................................................................................59 9.16.2. Assignment .........................................................................................................59 9.16.3. Severability..........................................................................................................59 9.16.4. Enforcement (attorneys’ fees and waiver of rights)..............................................59 9.16.5. Force Majeure .....................................................................................................59

9.17. Other provisions .........................................................................................................59

8

1. INTRODUCTION

This document specifies the certification procedures of Fuji Xerox (FX) Product Certification

Authority (Product CA) and includes two sort of contents: Certificate Policy and Certification

Practices Statements.

Certificate Policy gives declaration of the purpose, direction, environment, restriction, risks

and methods of Product CA for each item comprising the operation of Product CA.

Certification Practices Statements specifies concrete procedures to implement Certificate

Policy.

This document is organized in conformity to RFC 3647 issued by IETF (Internet Engineering

Task Force), which is an international standardization organization for technologies to be used in

the Internet.

The formal title and the acquisition point of RFC 3647 are given as follows.

RFC 3647. (2003) Internet X.509 Public Key Infrastructure: Certificate Policy and Certification

Practices Framework, Internet Engineering Task Force, Network Working Group,

ftp://ftp.rfc-editor.org/in-notes/rfc3647.txt

A PDF file for the document can be acquired from http://www.faqs.org/rfcs/rfc3647 (24.09.04).

The organization of this document conforms to the specification set forth in RFC 3647.

1.1. Overview 1.1.1. Product Certification Authority In this document, Product denotes an arbitrary business equipment or business software that

has capability of being a subscriber of certificates that Product CA issues.

Certificates issued to Product are used for the purpose of performing functions implemented in

the Product.

1.1.2. Background of Product CA The rapidly developing Internet technologies enable equipment to cooperate with each other

over networks such as LAN (Local Area Network) and WAN (Wide Area Network).

Mutually connected equipment are capable to render more advanced functionality by

cooperating with each other than when they didn't have communication capability.For example,

an equipment may perform a particular function receiving a command from a remote terminal.

For another example, a multi-functional copying machine may attach a scanned image to e-mail

9

to send it to a remote PC.

This current trend of utilization of networked equipment is characterized by the wide deployment

of the Internet technologies. In other words, the current advantages of networked equipment

are due to the open architecture design of Internet.The open architecture design of the Internet

accelerates competition of development of new products that deploy more advanced protocols,

render higher performance or provide richer functionality at a lower price. Thus, it is easier for

administrators to keep their network environment state of the art relying on the Internet

technologies.

However, we should recognize that the Internet technologies would cut two ways. Hence, the

open architecture design could enlarge the threat towards the network security.For example, in

the Internet, secured communication protocols such as SSL (Secure Socket Layer) and TLS

(Transport Layer Security), which provide enhanced security functions based on cryptography,

are widely deployed.Also, the functionality of digital signature and encryption is eventually a

mandatory building block of Basic Resident Register Card and the electronic payment. These

facts consistently indicate the intrinsic threat of the security of Internet.

Equipments (e.g. multi-functional copying machinery) and software (e.g. print server software)

running in offices cannot escape from the same threat as Internet is suffering from.This is

because they rely on the same set of technologies as Internet does.Although LAN and WAN are

not as public as Internet, it is reported that more than 80% of information leakage incidents were

caused by employees. Therefore, the less public nature of LAN and WAN will not relax the

threat.

However, we should recognize that the Internet technologies would cut two ways. Hence, the

open architecture design could enlarge the threat towards the network security.For example, in

the Internet, secured communication protocols such as SSL (Secure Socket Layer) and TLS

(Transport Layer Security), which provide enhanced security functions based on cryptography,

are widely deployed.Also, the functionality of digital signature and encryption is eventually a

mandatory building block of Basic Resident Register Card and the electronic payment. These

facts consistently indicate the intrinsic threat of the security of Internet.

On the other hand, five threats to the security of the network communication are identified:

impersonation, eavesdropping, tampering, repudiation and denial of services.Prevention of all

the threats except the denial of service requires the authentication functionality.In the sense, the

authentication functionality is the most fundamental for the security of the network

communication.

Table1: Threats of network communication

10

Threats Explanation

Impersonation An attacker impersonates an authorized user to access a confidential message.

Eavesdropping An attacker steals a confidential message on the way from the originator to the recipient.

Tampering An attacker modifies a message on the way from the originator to the recipient.

Repudiation An malicious originator of a message denies the fact of having sent the message.

Denial of services An attacker abuses the resources of networks to block communication.

Also, in networking Products, the authentication functionality should be a basis for the entire

security, and PKI (Public Key Infrastructure) must be a mandatory technological building block to

implement the functionality.This is because PKI is a standardized method to implement the

authentication functionality on Internet and provides overwhelming advantages for the

interconnectivity.

Compliance of Product to PKI requires the manufacturers of Product to equip Product with

capabilities to support the protocols that are widely deployed in PKI (e.g. HTTPS, SSL/TLS and

S/MIME) and to securely retain the secret keys that are mandatory to perform the protocols.

However, compliance of Product does not enable operation of PKI by itself.Trust infrastructure to

issue public key certificates to Products and certify the certificates will be necessary.For this

reason, FX provides services to issue public key certificates to the office equipment and software

that FX manufactures, vends and rents.

11

FX Certification Authority FX Endorsement CA

ProductAuthority

Specific Service CA's

Issuances of Sight Certificate

Issuances of CA Authority

FX CAPOperating Group

CertificateIssue

SiteAuthenti-

cation

Issuances of Membership Certificate

Figure 1 Logic structures of Certification Authority

Figure 1 depicts the logical structure of the certificate authorities that FX operates.

Product CA accepts two kinds of certificates, which FX Certification Authority and FX

Endorsement Certification Authority respectively issue to Product CA.

FX Certification Authority (FX CA) issues certificates to Specific Service CAs including Product

CA and FX Endorsement Certification Authority (FX ECA). The certificates issued by FX CA are

to be used to verify signatures included by certificates that Specific Service CA and FX ECA

issue. A certificate for signature verification of certification is called a CA certificate.

On the other hand, FX ECA issues site certificates to be used for operation of Specific Service

CAs. Users of specific services use the site certificates that FX ECA issues to authenticate

Specific Service CAs over Internet.For example, when a multi-functional copying machine

requests issuance of a certificate to Product CA over Internet, it establishes an SSL/TLS session

based on the site certificate that FX ECA issued to Product CA.

12

1.1.3. Overview of the services of Product CA In this clause, the services of Product CA will be overviewed.

The aim of this clause is only to help the reader to understand the services of Product CA and

does not include Certificate Policy and Certification Practices Statements of Product CA.

(1) Receipt of Certificate Issuance Request

Product CA recognizes a request of certificate issuance by Product when it receives an

electronic message of Certificate Issuance Request.Product generates and issues

Certificate Issuance Request, when an operator manipulates Product to run a certificate

acquisition utility program, for example.

(2) Processing received Certificate Issuance Request

Product CA verifies that the received Certificate Issuance Request was generated by a valid

Product manufactured by FX, identifies the model and serial number of the Product and

decides whether it should issue the requested certificate taking other information (e.g. the

contract with the client and the functional design of the Product) into account.

(3) Issuance of certificate

When Product CA decides the certificate issuance, it generates and issues the requested

certificate to Product.

(4) Acceptance of certification

Product stores the received certificate in its storage devices.

1.2. Document name and identification This document is entitled “Fuji Xerox Product Certification Authority: Certificate Policy and

Certification Practice Statement”.

The object identifier (OID) of this document is defined as follows:

1.3.6.1.4.1.297.1.5.1.3

1.3. PKI participants 1.3.1. Certification authorities This PKI is comprised of the single certification authority of Product CA.

The subscribers of certificates that Product CA issues are Products that FX manufactures.A

certificate that Product CA issues to Product is referred to as a Product certificate.

Product certificates are used for the purpose of performing functions implemented in the Product.

The following are examples of purposes of usage of Product certificates.

Provision of the functionality of authentication of Product and encryption, tamper detection

and non-repudiation of messages exchanged during communication between Product and

13

an arbitrary equipment or a user.

Encryption of data input to Product.

Verification of signed data output by Product.

1.3.2. Registration authorities Product CA does not include the functionality of Registration Authority.

Product CA issues Product certificate to Products which FX manufactures. FX has product

liability in that Product fulfills requisite conditions with respect to the functionality and

performance as a subscriber of certificates that Product CA issues. For example, Product shall

be equipped with secure means to retain secret keys.

1.3.3. Subscribers The subscriber of certificates that Product CA issues is office equipments and software (totally

referred to as Product) that FX manufactures.

1.3.4. Relying parties The relying party of a Product certificate is an entity that inputs documents or data to Product and

utilizes output from Product.

The entity stated above includes a user who directly or indirectly utilizes Product and an

equipment, server or terminal that communicates with Product in performing its functions.

1.3.5. Other participants No stipulation.

1.4. Certificate usage 1.4.1. Appropriate certificate uses Product utilizes a Product certificate issued to it to perform its functions that FX designed and

implemented.

For example, Product establishes secure communication (e.g. HTTPS, SSL/TLS, S/MIME)

based on a Product certificate and consequently takes advantage of the PKI functionality in

cooperating with an equipment, server or user over networks.A Product certificate can be used

for any purpose of authentication, confidentiality, integrity and non-repudiation since it is

applicable to an arbitrary communication protocol in principle, while the implementation of

Product CA may support only limited algorithms and parameters of Public Key Cryptography.In

addition, the certificate can be used for encrypting data to be input to Product or verifying signed

output from Product.

14

1.4.2. Prohibited certificate uses The certificates that Product CA issues is prohibited to be used for any other purpose than

specified in 1.4.1.

1.5. Policy administration 1.5.1. Organization administering the document FX CAP Committee is responsible for the repeal, amendment and approval of this document.

1.5.2. Contact person Questions regarding this CP and CPS should be directed to the contact person defined below.

FX CAP Committee Contact Desk, Fuji Xerox Co., Ltd. E-Mail: fxca-contact@fujixerox.co.jp

1.5.3. Person determining CPS suitability for the policy FX CAP Committee shall approve CPS, which is a part of this document.

1.5.4. CPS approval procedures FX CAP Committee shall be responsible for the content of CPS and the Chair of FX CAP

Committee shall approve it.

The scope of the responsibility of FX CAP Committee and the Chair includes amendment, repeal

and approval of this document.

15

1.6. Definitions and acronyms Terms Definition

Chair of FX CAP Committee

Supervisor of FX CAP Committee.

FX Certification Authority Platform Operating Group

Organization responsible for operation of FX Certification Authority.

FX CAP Operating Group Abbreviation of FX Certification Authority Platform Operating Group.

FX CAP Operating Manager

Supervisor of FX CAP Operating Group.

Customer side administrator

Administrator responsible for administration of Product where Product is installed. In particular, the customer side administrator is the only person who is qualified to request issuance and revocation of certificates.

Repositories Database to record information necessary of performance of the operations of Product CA.

Certificate revocation Revoking a certificate.Identifier of a revoked certificate is specified in a Certificate Revocation List.

Certificate issuance To issue a certificate to its subscriber.

Re-issue certification To renew a certificate.A renewed certificate includes the same name, key and other information as the old one except the particular items (e.g. a new serial number) that Certificate Policy specifies to be changed.

Certificate re-key To change the public key pair of a certificate. A new certificate specifying the public key of a new public key pair is issued to the same subscriber.

Certificate modification The function issued a new certificate which changes a part or all of substances without a public key stated to the certificate after issue

Self-signing certification A certificate including a public key and a signature generated using the private signing key paired with the public key. CA issues a self-signed certificate to publish its public key to the users.

Link certification A certificate issued when a CA’s private signing key is changed. A link certificate includes either a pair of the new public key and a signature generated using the old private signing key or a pair of the old public key and a signature generated using the new private key.

Certificate Revocation List Data object that includes a list of revoked certificates, signed using the CA’s private signing key.

Authority revocation list Data object that includes a list of revoked CA Certificates, signed using the CA’s private signing key.

16

Terms Definition

Hardware Cryptographic Module

A hardware module for the protection of CA’s private signing keys.The functionality of the hardware cryptographic module includes generation, maintenance, usage and destruction of the private signing keys.The operation of the hardware cryptographic modules shall be performed under strict control by means of physical or electronic methods or both.

CA’s public key pair A pair of CA’s private signing key and the public key paired with the private signing key.

CA’s public key A public key that is used to verify the signature of a certificate, which CA generates using the CA’s private signing key paired with it.

CA's private signing key A private signing key that CA uses to sign certificates that it issues.

Product public key pair A pair of a public key and a private key that a Product generates.

Product public key The public key of a Product public key pair, which is specified in a Product Certificate.

Product private key The private key of a Product public key pair, which is securely stored in the relevant Product.

Audit logs A log recording the history of events, used to verify the validity of the activities of CA.

Audit collection system The system that collects audit logs relating to the activities of Product CA, which is a part of the Product CA system.

Public key pair A pair of a public key and a private key of the public key cryptographic system.

Public key The private component of a public key pair that its owner securely retains.

A public key of a CA’s public key pair is used for verification of the signature of a certificate.

Private key The private component of a public key pair that its owner securely retains.

A private key of a CA’s public key pair is used for generation of a signature for a certificate, and therefore it may be called a private signing key.

Private signing key A private key whose usage is restricted to generation of signatures.

Signature verification keys A public key whose usage is restricted to verification of signatures.

17

Terms Definition

Certificate A data object comprised of a public key and other information, which asserts that the owner of the public key has passed the registration process specified by the relevant certificate policy. The relevant CA signs it using its private signing key.

Product certificates A certificate that Product CA issues to a Product.Product uses the issued Product certificate in order to perform its implemented functions.

CA certificate A certificate that a CA issues to a subordinate CA, usage of which is restricted to verification of the signature of certificates that the subordinate CA issues.

Site certificate A certificate used to authenticate a site over networks.For example, when a SSL/TLS communication is established between a client and a server, the client authenticates the server based on a site certificate of the server.

Issuer The CA that issued the relevant certificate.It is the entity whose name appears as the issuer in the certificate.

Subscriber The owner of the public key that is specified in the relevant certificate.It is the entity whose name appears as the subject in the certificate.

Relying party The entity that authenticates the subscriber of a certificate based on the public key specified in the certificate.For example, when a SSL/TLS connection is established between a client and a server, the client is a relying party of the site certificate that has been used for the establish of the connection.

Certificate Issuance Request

A message to request issuance of a Product certificate to Product CA.A Product generates a Certificate Revocation Request and signs it.

Certificate Revocation Request

A message to request revocation of a Product certificate to Product CA.A Product generates a Certificate Revocation Request and signs it.

Certificate Policy and Certification Practice Statement

A set of documents that describe policies and rules concerning the functions and operations of a CA. A relying party of a certificate may refer to the Certificate Policy and Certification Practice Statement to which the certificate is pursuant.It is recommended that documents of Certificate Policy and Certification Practice Statement is compliant to RFC 3647.

Certificate Policy and Certification Practice Statement is abbreviated to CP/CPS.

18

Terms Definition

Activation To make an object such as a private key and a hardware cryptographic module ready for use.

For example, a private signing key can be used to generate a signature only when it is activated.

As another example, the operations to a hardware cryptographic module, including generation, destruction and use of a private key confined within the module, require prior activation of the module.

Inactivation To inactivate an object such as a private key and a hardware cryptographic module that has been activated.

FX Certification Authority The certification authority that issues CA certificates to its subordinate CA’s including FX ECA and Specific Service CA’s.

FX Endorsement Certification Authority

The certification authority that issues certificates necessary for the operation of the CA’s that FX operates.FX ECA issues the site certificates of Product CA.

Specific Service Certification Authority

A certification authority that provides trust to the users of a particular service that FX operates.Division of FX that performs the operation of the relevant service also operates the corresponding Specific Service CA.

CP/CPS Abbreviation of Certificate Policy and Certification Practice Statement.

CSR Abbreviation of Certificate Signing Request.CSR includes information of the identity of the subject of the request and the public key to be specified in a requested certificate.CSR is compliant to a format standardized for usage in Internet (e.g. PKCS #10).

CRL Abbreviation of Certificate Revocation List.

ARL Abbreviation of Authority Revocation List.

S/MIME A specification of a format and protocol for the electronic mail, which provides the security functionality of encryption, integrity verification and non-repudiation of messages.

SSL Abbreviation of Secure Socket Layer.

A protocol of the network communication, that provides the security functionality of entity authentication, message encryption and prevention of unauthorized modification of messages.

TLS Abbreviation of Transport Layer Security.

TLS is an enhancement of SSL 3.0.

19

2. PUBLICATION AND REPOSITORY RESPONSIBILITIES

2.1. Repositories Repositories of Product CA shall retain at least the following information items.

(1) Link certificates:

A certificate generated in association with an event of changeover of the Product CA’s

private signing key.A certificate specifying the old private signing key signed using the new

private signing key, and a certificate specifying the new private signing key signed using the

old private signing key.

(2) Product certificate

A public key certificate.

(3) Certificate invalidation list

A list of revoked Product certificates.

(4) CA certificate

Certificate which FX CA issues to Product CA.

2.2. Publication of certification information Product CA shall publish information concerning its activities including the following.

(1) The link certificates retained by the Product CA’s repositories.

(2) The CRL’s retained by Product CA’s repositories.

(3) The CA certificates retained by Product CA’s repositories.

(4) Information concerning compromise of Product CA’s private signing keys.

(5) Certificate Policy and Certification Practice Statement specified by this document.

The publication shall be accessed by the following means.

http://www.fujixerox.co.jp/product/cap/fxprdca.html

2.3. Time and frequency of publication Product CA shall publish any update to the information specified in 2.2 as quickly as the update

is made.

2.4. Access controls on repositories Access to information stored in the repositories, including addition, deletion and modification of

stored information, shall be restricted to the personnel who have access rights.

However, the access control shall not apply to the public dissemination of the information

specified in 2.2 to be published.

20

3. Identification and authentication

3.1. Naming 3.1.1. Types of names The name item to be specified in the issuer and subject fields of the certificates that Product CA

issues shall be an X.500 Distinguished Name (DN).

3.1.2. Need for names to be meaningful Names used in the certificates issued pursuant to this CP and CPS shall identify the person and

object in a meaningful way.

3.1.3. Anonymity or pseudonymity of subscribers Anonymity or pseudonymity of subscribers are not allowed in the certificates issued pursuant to

this CP and CPS.

3.1.4. Rules for interpreting various name forms No stipulation.

3.1.5. Uniqueness of names Names used in the certificates issued pursuant to this document shall uniquely identify the

person or object.

3.1.6. Recognition, authentication, and role of trademarks No stipulation.

3.2. Initial identity validation 3.2.1. Method to prove possession of private key A Product submits a Certificate Issuance Request to Product CA and requests Product CA to

issue a certificate in which the name of the Product appears as the subject.

Product CA verifies the validity of the received Certificate Issuance Request and consequently

recognizes that the relevant Product actually retains the private key whose paired public key is

requested to be certified.

3.2.2. Authentication of organization identity Product CA verifies the validity of Certificate Issuance Request and consequently recognizes that

the relevant Product is an authorized product of FX.

3.2.3. Authentication of individual identity Product CA identifies the relevant Product based on the model number, the serial number and

other identifying information specified in Certification Issuance Request.

21

In addition, Product CA retains a list of authorized to which Products is allowed to issue

certificates, and looks up the identifying information of the relevant Product in the list to make a

decision of issuance of the requested certificate.

Thus, Product CA authenticates a Product by verifying the validity of a Certificate Issuance

Request.

3.2.4. Non-verified subscriber information No stipulation.

3.2.5. Validation of authority No stipulation.

3.2.6. Criteria for interoperation No stipulation.

3.3. Identification and authentication for re-key requests 3.3.1. Identification and authentication for routine re-key The same as the specification of 3.2 applies.

3.3.2. Identification and authentication for re-key after revocation The same as the specification of 3.2 applies.

3.4. Identification and authentication for revocation request The same as the specification of 3.2 applies.

22

4. CERTIFICATE LIFE-CYCLE OPERATIONAL REQUIREMENTS

4.1. Certificate Application 4.1.1. Who can submit a certificate application A Product submits a Certificate Issuance Request to Product CA and requests Product CA to

issue a certificate in which the name of the Product appears as the subject.

The public key specified in a Product certificate is the public key of a public key pair that Product

generates.This public key pair is referred to as a Product public key pair, while the public key and

the private key are referred to as a Product public key and a Product private key respectively.

4.1.2. Enrollment process and responsibilities Registration of a Product shall be performed in advance that a Product issues a Certificate

Issuance Request.

FX CAP Committee is responsible for the determination of the registration of the Product.On the

other hand, FX is responsible for maintaining the security of the Product so that the compromise

of the security of the Product does not harm the functions of Product CA.

FX shall inspect at least the following items for the registration of a Product.

(1) The security of Product's functions to request certificate issuance and revocation:

- The Product is equipped with methods to prevent unauthorized use of the functions.

- In particular, access to the function shall be restricted, for example by means of a

password, so that only client-side administrators are available to perform the functions.

(2) The security of the implementation of the functions to request issuance and revocation of

certificates:

- The program to generate the messages of Certificate Issuance Request and Certificate

Revocation Request shall be protected by appropriate means.

– The secret information to be used to generate signatures to Certificate Issuance Request

and Certificate Revocation Request shall be protected by appropriate means.

(3) The security of the implementation of the functions to generate, retain and use a Product

private key:

– The program to generate the Product private key shall be protected by appropriate means.

– The Product private key shall be protected by appropriate means.

– The functions to utilize the Product private key shall be protected by appropriate means.–

In particular, the Product private key shall not be exposed to the outside during the

performance of the programs.

23

(4) Security of the development environment:

– The disclosure of confidential information that may cause compromise of the security of

the Product shall be restricted to the requisite minimum.

– The disclosed confidential information shall be administrated by appropriate means.

– The developers shall receive education programs prepared to prevent leak of information.

In a typical example, a Product model is enrolled.If a model is enrolled, Product CA issues

Product certificates on request from any Product belonging to the model.

4.2. Certificate application processing The systems of Product CA automatically process a received Certificate Issuance Request

without manual operations by operators.

4.2.1. Performing identification and authentication functions Product CA identifies and authenticates a Product by verifying the validity of the Certificate

Issuance Request that the Product has issued.

Product CA shall identify a Product based on the descriptions of its mode, serial number and

other identifying information specified the Certificate Issuance Request.At the same time,

Product CA shall verify the enrollment of the relevant Product.

4.2.2. Approval or rejection of certificate applications Product CA may issue a Product certificate to a Product only when it has successfully identified

and authenticated the Product.

However, the above does not exclude the cases where the issuance of the Product certificate is

restricted due to the content of a contract between FX and its client user. In addition, the

functional specification of the Product may not allow the issuance.

For example, the following factors may restrict the issuance of the Product certificate.

The validity period of the contract.

Support period of the Product.

The uppermost limit of the number of certificates to be issued to the Product.

4.2.3. Time to process certificate applications With a fundamental implementation of a Product, the client-side administrator sends Certification

Issuance Request to Product CA over networks receives the requested certificate and verifies

installation of the certificate in the Product during performing a single operation.

For example, the client-side administrator may select an iconic symbol on the display of a

Product to run a certificate acquisition utility program and may recognize the termination of the

24

program by seeing a statement such as “The requested certificate has been installed

successfully.” on the same display.

Request of certificate issuance and installation of the issued certification shall be performed

within a sufficiently short time period such that an operator can instruct the performance and can

recognize its result by a single operation of Product.

4.3. Certificate issuance The Product CA system shall automatically issue requested certificates after processing relating

Certificate Issuance Request.

4.3.1. CA actions during certificate issuance Product CA shall send a Product certificate to Product.

The primary means of sending Product certificates is via networks including the Internet.

4.3.2. Notification to subscriber by the CA of issuance of certificate Product CA does not assume the obligation of notifying the issuance of a certificate.

4.4. Certificate acceptance 4.4.1. Conduct constituting certificate acceptance Product CA assumes acceptance of a certificate by the recipient Product at the moment when

sending it to the Product.

4.4.2. Publication of the certificate by the CA No stipulation.

4.4.3. Notification of certificate issuance by the CA to other entities No stipulation.

4.5. Key pair and certificate usage 4.5.1. Subscriber private key and certificate usage Product private keys shall be used in performing Product’s functions designed and implemented

by FX.

The following is a possible example of usage of a Product private key by Product.

A Product private key may be used by the Product to establish secured communication

sessions with entities (e.g. users, equipments, servers, terminals) mutually connected by

means of networks pursuant to standardized protocol specifications (e.g. SSL/TLS, HTTPS).

Such a secured session protects massages exchanged in the session by providing the

functions of encryption, tamper detection and non-repudiation.

25

Product private keys shall be securely generated inside the Product and shall be securely stored

within the Product thereafter only in order to be served for performing Product’s functions. In

addition, Product shall have a capability to prevent the stored private keys being peeked at or

being stolen by anyone including the client-side administrator, developers or service engineers of

FX.

A Product private key shall not be used for any purpose earlier than the product accepts a

certificate into which the private key is bound.

Product shall have a capability to enforce the rules regarding usage of Product private keys.

4.5.2. Relying party public key and certificate usage Public keys that are bound into Product certificates shall be certified for use in performing

Product’s functions designed and implemented by FX.

The following is a possible example of usage of a Product public key.

A Product public key may be used by entities (e.g. users, equipments, servers, terminals)

mutually connected by means of networks to establish secured communication sessions with

the Product pursuant to standardized protocol specifications (e.g. SSL/TLS, HTTPS). Such

a secured session protects messages exchanged in the session by providing the functions of

encryption, tamper detection and non-repudiation.

A Relying Party is responsible for determining whether to rely upon a certificate.

4.6. Certificate renewal Product CA does not assume the obligation of responding to requests for certificate renewal.

Product does not distinguish between certificate renewal and certificate issuance based on

ordinary Certificate Issuance Request.

4.6.1. Circumstance for certificate renewal No stipulation.

4.6.2. Who may request renewal No stipulation.

4.6.3. Processing certificate renewal requests No stipulation.

4.6.4. Conduct constituting acceptance of a renewal certificate No stipulation.

4.6.5. Publication of the renewal certificate by the CA No stipulation.

26

4.6.6. Notification of certificate issuance by the CA to other entities No stipulation.

4.7. Certificate re-key Product CA does not assume the obligation of responding to requests for certificate re-key.

Product does not distinguish between certificate re-key and certificate issuance based on

ordinary Certificate Issuance Request.

4.7.1. Circumstance for certificate re-key No stipulation.

4.7.2. Who may request certification of a new public key No stipulation.

4.7.3. Processing certificate re-keying requests No stipulation.

4.7.4. Notification of new certificate issuance to subscriber No stipulation.

4.7.5. Conduct constituting acceptance of a re-keyed certificate No stipulation.

4.7.6. Publication of the re-keyed certificate by the CA No stipulation.

4.7.7. Notification of certificate issuance by the CA to other entities No stipulation.

4.8. Certificate modification Product CA does not assume the obligation of responding to requests for certificate modification.

Product does not distinguish between certificate modification and certificate issuance based on

ordinary Certificate Issuance Request.

4.8.1. Circumstance for certificate modification No stipulation.

4.8.2. Who may request certificate modification No stipulation.

4.8.3. Processing certificate modification requests No stipulation.

27

4.8.4. Notification of new certificate issuance to subscriber No stipulation.

4.8.5. Conduct constituting acceptance of modified certificate No stipulation.

4.8.6. Publication of the modified certificate by the CA No stipulation.

4.8.7. Notification of certificate issuance by the CA to other entities No stipulation.

4.9. Certificate revocation and suspension Product CA shall not support the function of certificate suspension.

4.9.1. Circumstances for revocation There is following circumstances under which certificate issued by Product CA will be revoked.

(1) When the Product CA private signing keys are compromised.

(2) When Product is compromised, for example, when the generation method of Product

Authentication Code and/or the retention method of Product private keys are

compromised.This circumstance includes the cases where significant defects were found for

the design and/or implementation of Product, where reverse engineering was performed

against Product and where confidential information regarding the design of Product was

leaked.

(3) When new certificates are issued for the purpose of renewal, re-key or modification of

existing certificates. Product may request revocation of Product certificates to Product CA

for the purpose of renewal, re-key or modification of the certificates.

(4) When Product CA receives an authenticated request from the client-side administrator. The

client-side administrator may request revocation of certificates for which he or she is

responsible based on rational reasons.However, Product CA shall retain the rights to reject a

revocation request by the client-side administrator after the request was carefully examined

on a bona fide basis.

4.9.2. Who can request revocation The personnel who can request revocation are determined as follows dependent on

circumstances under which certificates will be revoked.

4.9.2.1. When the Product CA private signing keys are compromised FX CAP Committee Chair shall request revocation.

28

Operating Group and Auditor Group shall undertake the obligation of consistently monitoring the

security of Product CA private signing keys and of reporting facts or possibility of their

compromise to FX CAP Committee Chair as quickly as possible.

4.9.2.2. When Product is compromised FX CAP Committee Chair shall request revocation.

Operating Group shall undertake the obligation of consistently monitoring communication

between Product CA and Product and of reporting facts or possibility of compromise of Product

to FX CAP Committee Chair as quickly as possible.

Divisions of FX that are responsible for development, sales and/or supporting of Product shall

undertake the obligation of consistently monitoring quality inspection, information leakage during

development and claims by clients and of reporting facts or possibility of compromise of Product

to FX CAP Committee Chair as quickly as possible.

4.9.2.3. When new certificates are issued for the purpose of renewal, re-key or modification of existing certificates The client-side administrator of Product shall request revocation. Product shall have a

capability to issue Revocation Request.

4.9.2.4. When Product CA receives an authenticated request from the client-side administrator The client-side administrator shall request revocation. Product shall have a capability to issue

Revocation Request.

4.9.3. Procedure for revocation request The procedures for revocation request are determined as follows dependent on circumstances

under which certificates will be revoked.

4.9.3.1. When the Product CA private signing keys are compromised Product CA shall report the facts of the compromise of Product CA private signing keys to FX

CAP Committee Chair and shall revoke all the certificates signed using the compromised signing

keys following instructions by FX CAP Committee Chair.

4.9.3.2. When Product is compromised Product CA shall report the facts of the compromise of Product to FX CAP Committee Chair and

shall revoke all the compromised certificates following instructions by FX CAP Committee Chair.

29

4.9.3.3. When new certificates are issued for the purpose of renewal, re-key or modification of existing certificates Product shall request revocation by one of the two methods stated below.

(1) Product may specify the identifiers of the Product certificates to be revoked in Certificate

Issuance Request that Product issues for the purpose of renewal, re-key or modification of

certificates.

(2) Product may specify the identifiers of the Product certificates to be revoked in Revocation

Request.In principle, the message, Certificate Issuance Request, is delivered over the

networks.

Product CA shall verify the validity of Certificate Issuance Request or Revocation Request and

shall revoke the requested certificates only when the Request is signed using a secret signing

key that only the relevant Product is able to access.

4.9.3.4. When Product CA receives an authenticated request from the client-side administrator The client-side administrator shall request revocation to Product CA.No stipulation is given for

the methods to request revocation.

However, Product CA shall retain the rights to reject a revocation request by the client-side

administrator after the request was carefully examined on a bona fide basis.

4.9.4. Revocation request grace period The claimant shall request revocation within the time frame as set forth in the following reckoning

from the point of time when the claimant recognized the circumstance under which certificates

are to be revoked.

4.9.4.1. When the Product CA private signing keys are compromised Operating Group of Product CA shall request revocation as quickly as possible after it recognized

the fact or the possibility of the compromise of Product CA private signing keys.

4.9.4.2. When Product is compromised Responsible divisions of FX or Operating Group of Product CA shall request revocation as

quickly as possible after it recognized the fact or the possibility of the compromise of Product.

4.9.4.3. When new certificates are issued for the purpose of renewal, re-key or modification of existing certificates Revocation request shall be no later than the delivery of Certificate Issuance Request of the

certificates to be renewed, re-keyed or modified.

30

4.9.4.4. When Product CA receives an authenticated request from the client-side administrator No stipulation.

4.9.5. Time within which CA must process the revocation request 4.9.5.1. When the Product CA private signing keys are compromised Product CA shall have completed the required revocation within a single operation day.

4.9.5.2. When Product is compromised Product CA shall have completed the required revocation within a single operation day.

4.9.5.3. When new certificates are issued for the purpose of renewal, re-key or modification of existing certificates Product CA shall have completed the requested revocation by the issuance of the new

certificates.

4.9.5.4. When Product CA receives an authenticated request from the client-side administrator Product CA shall have completed the requested revocation within a single operation day

reckoning from the point of time when it approved the request after careful examination.

4.9.6. Revocation checking requirement for relying parties Relying parties shall confirm certificate revocation by conferring CRL that Product CA disclosed.

4.9.7. CRL/ARL issuance frequency (if applicable) Product CA shall issue CRL with the validity period of 48 hours every 24 hours.

4.9.8. Maximum latency for CRL/ARLs (if applicable) No stipulation.

4.9.9. On-line revocation/status checking availability CRL shall be accessible by an arbitrary individual 24 hours a day, every day.

The methods to access CRL shall be set forth in 2.2.

4.9.10. On-line revocation checking requirements No stipulation.

4.9.11. Other forms of revocation advertisements available No stipulation.

4.9.12. Special requirements re key compromise

4.9.2、4.9.3、0、0In addition to the stipulation of 1.9.5, Product CA may make necessary measures

including the following in case of compromise of Product CA private signing keys.

31

Termination of Product CA.

Changeover of Product CA private signing keys.

Issuance of new certificates.

Product CA shall disclose the fact of the compromise of its private signing keys and the

measures that it took in response to the emergency.

4.9.13. Circumstances for suspension No stipulation.

4.9.14. Who can request suspension No stipulation.

4.9.15. Procedure for suspension request No stipulation.

4.9.16. Limits on suspension period No stipulation.

4.10. Certificate status services Product CA shall not assume the obligation to provide certificate status services except

disclosure of CRL.

4.10.1. Operational characteristics No stipulation.

4.10.2. Service availability No stipulation.

4.10.3. Optional features No stipulation.

4.11. End of subscription No stipulation.

4.12. Key escrow and recovery Product CA shall not perform key escrow and recovery.

4.12.1. Key escrow and recovery policy and practices No stipulation.

4.12.2. Session key encapsulation and recovery policy and practices No stipulation.

32

5. FACILITY, MANAGEMENT, AND OPERATIONAL CONTROLS

5.1. Physical controls 5.1.1. Site location and construction The site location and construction, combined with other physical security protection

mechanisms, shall provide robust protection to minimize the damages by flood, earthquake, fire

and other disasters.

5.1.2. Physical access The Product CA equipment shall always be protected from unauthorized access, and entering

and leaving the facility housing the Product CA equipment shall be appropriately restricted.

Access to each chamber that houses the whole and a part of the Product CA equipment as well

as each hardware of the Product CA equipment shall be restricted by appropriate means

including multi-person control.

In particular, Product CA Manager shall permit requisite minimum personnel to access the

Product CA equipment and the facility housing it, and shall always have clear recognition of the

personnel.

The facility that houses the Product CA equipment shall be monitored for unauthorized intrusion

by means of 24 hour, 365 day per year monitoring methods.In case of suspension of the

monitoring methods for maintenance or other similar reasons, appropriate alternative methods

shall be provided.

5.1.3. Power and air conditioning Product CA shall have the capability to provide electric power sufficient for the operation of its

equipment and have tolerance to momentary and temporary blackouts, ground leakage and

fluctuation of voltage and frequency.

In particular, Product CA shall take measures, such as those exemplified below, to continue its

operation during a blackout.

At least a part of the Product CA equipment shall be duplicated and installed remote from

each other so that blackouts shall not suspend the functions of the whole equipment.

Product CA shall have capability to provide electric power even during blackouts, for

example by means of in-house generators.

In addition, Product CA shall install air-conditioning systems so that environment for the

operation of the equipment and the operating personnel shall be kept appropriate when the

temperature and the humidity outside the facility of Product CA change due to extreme weather.

33

5.1.4. Water exposures The facility that houses the Product CA equipment shall be located so that it is safe from deluge,

typhoon and so forth. For example, the facility may be located at the higher stories of a

building.

In addition, the Product C shall isolate the equipment from water supply facility and shall be

protect it against water exposure by additional waterproofing means.

5.1.5. Fire prevention and protection The facility housing the Product CA equipment shall be equipped with fire resistant construction,

compartments, fire detecting devices and fire control equipment.

In addition, Product CA shall isolate its equipment from any fire-relating facility such as gas pipes

and hot water apparatus, and shall prohibit any action causing fire including smoking in the

vicinity of its equipment.

5.1.6. Media storage Media that contains audit, archive or backup information shall be stored in locked cabinets so as

to protect it from accidental damage such as water and fire. In addition, the cabinets shall be

installed in rooms access to which is restricted so that it is practically impossible to carry them

out.

The unlocking of the cabinets and access to the media shall be performed pursuant to authorized

stipulation under multi-person control.

5.1.7. Waste disposal Documents and media that contain confidential information shall be disposed by means such

that retrieval of the information from the disposed documents and media is practically impossible

(electromagnetic erasure and physical fracture).

5.1.8. Off-site backup No stipulation.

5.2. Procedural controls 5.2.1. Trusted roles In the following, description of FX CAP Committee, Operating Group and Auditor Group, which

supervise, operate and audit the CA, respectively.

34

FX CAP CommitteeChair

FX CAP Operating ManagerLiaisons from:

Division operating specific servicesDivision responsible for quality control

Legal section

FX CAP Operating GroupOperating Manager

Private Key AdministratorsOperators

Auditor GroupAuditors

Operation auditCompliance audit

Operation assignment check

Auditresultsreport

Figure 2:Organization

5.2.1.1. FX CAP Committee FX CAP Committee is responsible for supervising the operation of Product CA pursuant to the

specification of this document and other documents derived from this document.

FX CAP Committee shall have the right to make final decision regarding the following issues and

shall be externally responsible for the decision.

1. Issues regarding the opening and termination of Product CA.

2. Issues relating approval, lapse and update of this document and other documents derived from this document.

3. Issues regarding mutual authentication of other CA’s, in particular issues regarding approval

of CP/CPS of other CA’s.

4. Issues regarding personnel affairs of Product CA.

5. Issues regarding information to be externally publicized.

6. Issues regarding personnel education including approval of the material, program and

schedule.

35

7. Other important issues relating the operation of Product CA.

8. Issues relating compromise of Root CA’s private signing keys.

9. Issues regarding approval of the results of audits of Root CA.

10. Issues regarding approval of the result of CA audits for policy compliance pursuant to this

document and other documents derived from this document.

11. Other important issues relating the security of Product CA.

The organization of FX CAP Committee shall at least fulfill the following requisite conditions.

The chair of FX CAP Committee shall be either the operating officer who is responsible for

FX's information policies or one to whom authority is transferred from the officer.

FX CAP Committee shall include the managers of Operating Group and Auditor Group.

FX CAP Committee shall include liaisons from divisions that operate specific services.

FX CAP Committee shall include liaisons from divisions that are responsible for quality

control of subordinate CA’s.

FX CAP Committee shall include liaisons from the FX’s legal section.

5.2.1.2. FX CAP Operating Group The scope of the responsibility of FX CAP Operating Group shall include the following issues.

1. Administration and maintenance of the Product CA equipment.

2. Activities relating to certificate issuance based on instructions by FX CAP Committee.

3. Other tasks based on instructions by FX CAP Committee.

FX CAP Operating Manager

FX CAP Operating Manager is the personnel who supervises the activities of FX CAP Operating

Group and shall be responsible for the following issues.

Call of FX CAP Operating Group meetings.

Final decision on issues discussed in FX CAP Operating Group meetings.

Decision of actions against emergencies and supervision of performing them.

Operation to enroll, change and delete access rights of operating personnel.

Instructions and supervision of other activities relating to the operation of Product CA.

FX CAP Committee Chair shall take the responsibility of assignment of FX CAP Operating

Manager.

Private Key Administrator

36

The private key administrators shall be responsible for maintenance and usage of the Product

CA’s private signing keys and shall perform the following.

Administration and usage of the physical keys to unlock the cabinets that contain hardware

cryptographic modules.

Operation of hardware cryptographic modules including generation, changeover, activation,

deactivation, backup and restoring Product CA’s private signing keys.

In particular, access to the physical keys to unlock the cabinets that contain hardware

cryptographic modules shall be strictly restricted to Private Key Administrators.

Operator

Operators shall engage in actual operation of the systems of the Product CA equipment including

the following.

Operation of the systems of the Product CA equipment except for activation, suspension and

configuration change of the systems.

Maintenance of the systems of the Product CA equipment.

Maintenance of the environment of the operation of Product CA.

Generation of archival.

5.2.1.3. Auditor group Auditor Group is independent of Operating Group. Auditors shall engage in audit activities

including the following.

Maintaining audit logs and performing internal audits of Product CA.

Performing internal compliance audits to ensure that Product CA is operating in accordance

with CP/CPS that this document specifies.

Auditor Group shall perform internal audit at fixed intervals and shall report the results to FX CAP

Committee.

5.2.2. Number of persons required per task The numbers of personnel belonging to FX CAP Operating Group and Auditor Group shall fulfill

the following requisite conditions.

37

Table 2:Number of personnel and role separation

Role Number of personnel Roles not to be combined

Operating Officer 1 Auditor

Private Key

Administrator

No less than 2 Auditor

Operator No less than 2 Auditor

Auditor group No less than 2 Operating Officer, Private Key

Administrator, Operator

5.2.3. Identification and authentication for each role Access to the Product CA equipment and the facility housing it shall be permitted or denied per

role.In addition, the access shall be based on authentication of individual personnel.

5.2.4. Roles requiring separation of duties Personnel shall not combine any other roles in FX CAP Operating Group with Auditor so as to

ensure the neutrality of the role of Auditor.

The number of personnel assigned as Auditor shall be no less than two, and any operation of this

role shall be performed under two-person control.

The number of personnel assigned as Private Key Administrator shall be no less than two, and

any operation of this role shall be performed under two-person control.

5.3. Personnel controls 5.3.1. Qualifications, experience, and clearance requirements Personnel assigned to each role of FX CAP Operating Group and Auditor Group shall fulfill the

following requisite conditions.

Operating Manager and Auditor shall have a detailed knowledge of the contents of this

document and other documents derived from this document and shall maintain high moral

values as a member of the industry.

Private Key Administrator shall understand the social responsibility posed on CA, shall have

a detailed knowledge of the contents of this document and other documents derived from

this document and shall maintain high moral values as a member of the industry.In addition,

Auditor shall have a knowledge, at least in principle, of the technologies relating to the

activities of CA.

38

Operator shall have a detailed knowledge of the part of the contents of this document and

other documents derived from this document that specifies or is related to the operations by

Operator.In addition, Operator shall have a detailed knowledge of the technologies

necessary for the operation of the Product CA equipment.

FX CAP Committee shall appoint personnel for the roles of Operating Manager and Auditor, and

FX CAP Committee Chair shall authorize the appointment. Also, Operating Manager shall

appoint personnel for the roles of Private Key Administrator and Operator, and FX CAP

Committee Chair shall authorize the appointment.

5.3.2. Background check procedures Background check procedures, in particular procedures to check criminal records, shall be

pursuant to the corresponding stipulations specified by FX.

5.3.3. Training requirements All personnel performing duties with respect to the operation of the Product CA shall receive

comprehensive training based on programs authorized by FX CAP Committee.Training shall be

conducted in the following areas.

A. Social responsibilities of Certification Authority.

B. Stipulations specified by this document and other documents derived from this document.

C. Technologies relating to the operations of Certification Authorities.

5.3.4. Retraining frequency and requirements All the personnel performing duties with respect to the operation of Product CA shall receive

training before initially starting to perform those duties, and will receive training at least once per

year.

All the personnel belonging to Operating Group or Auditor Group shall be informed of any

authorized changes to the contents of this document and other documents derived from this

document as quickly as possible.

5.3.5. Job rotation frequency and sequence No stipulation.

5.3.6. Sanctions for unauthorized actions No stipulation.

5.3.7. Independent contractor requirements Requirements relating to an event of consignment of business activities shall be written in a

contract that the FX legal division authorizes.

39

The contract shall include at least stipulations specifying confidentiality obligation, compliance to

FX bylaws and sanction for unauthorized activities.

5.3.8. Documentation supplied to personnel No stipulation.

5.4. Audit logging procedures Auditors shall perform audits of the activities of Product CA in order to verify the following issues.

Any performed operation shall be pursuant to the related stipulations and subject to the

related instructions, in particular, any operation shall be performed by Operating Officer,

Private Key Administrator, or Operator, who has authorized right to perform such operations.

Any authorized instruction shall be executed so that its expected effect is realized in

operations of Product CA.

The scope of the audits by Auditor Group shall include all the operations that Operating Group

performs.

The Product CA equipment shall include an audit log collection system that automatically records

logs of all events relating to the security of Product CA..The recorded logs are referred to as

audit logs.

In parallel, Private Key Administrator and Operator shall write at least the following items on

logbooks when the person performs any operation relating to the Product CA equipment.

The identity of the operator who performed the operation.

The date and time when the operation was performed.

The type of the operation.

The results of the operation.

The instructions causing the operation.

Auditor shall at least cross-check the electronic logs and the non-electronic logs recorded on the

logbooks.

The supervisor of Auditor Group shall present the result of audits on document basis to FX CAP

Committee.

FX CAP Committee may, if it is necessary, disclose audit reports to outside organization such as

Certification Authorities that issues certificates to Product CA.

40

5.4.1. Types of events recorded Among a wide variety of events that occurs during the activities of Product CA, all the events that

may have an important impact to the operation of Product CA shall be recorded as audit logs.As

a result, the audit logs shall include, at a minimum, the following.

Events of generation, destruction and use of Product CA’s private signing keys.

Events relating to the lifecycle of certificates that Product issues.

At a minimum, each audit record shall include the following.

The type of the event.

The date and time when the event occurred.

The results of the event.

The identity of the entity and/or operator that caused the event.

5.4.2. Frequency of processing log Auditor Group shall review audit logs with the frequency as set forth in Table 3.

5.4.3. Retention period for audit log Audit logs may be retained in storages of the Product CA equipment and/or in external storage

media such as CD-R.

Audit logs shall be automatically recorded in storages of the Product CA equipment at the

moment when the event to be recorded occurred.Audit logs that are retained in storage of the

Product CA equipment are referred to as onsite logs. In addition, Auditor shall retain audit logs

onsite for at least the duration specified in Table 3 and shall copy them to external storage media

in cycles of the same duration.The audit logs to be copied shall include the audit logs that were

recorded after the time point when copies of audit logs had been made last time.The audit logs

retained on external storage media are referred to as offsite logs.

Table 3 specifies the retention periods for the onsite and offsite logs.

5.4.4. Protection of audit log Product CA shall take measures so that audit logs shall not be lost for any reasons such as

disaster and theft or shall not be modified.

In particular, onsite audit logs, which are retained in storage of the Product CA equipment, shall

be put under the following control.

The systems of Product CA that control access to audit logs shall be implemented to prohibit

modification or deletion of audit logs.

41

The storages that retain audit logs shall be located in rooms access to which is strictly

restricted.

In particular, offsite audit logs, which are retained in external storage media, shall be put under

the following control.

The format of the storage media that store audit logs shall not allow modification, deletion or

addition of data recorded on them.

The media that store audit logs shall be kept in a locked cabinet located in a room access to

which is strictly restricted.Access to the storage media that retain audit logs shall require in

the presence of multiple persons including at least one Auditor.

5.4.5. Audit log backup procedures Backup of audit logs shall be performed in the presence of at least two Auditors.

Backup of audit logs shall be performed at the same time as generation of offsite audit logs and

the audit logs shall be stored in external storage media different from those for the offsite audit

logs.In addition, backup of audit logs shall be put under the following control for protection.

The format of the storage media that store audit logs shall not allow modification, deletion or

addition of data recorded on them.

The storage media that retain audit logs shall be kept in a locked cabinet.

Table 2 Time control relating to audits specifies the retention period of backup of audit logs.

5.4.6. Audit collection system (internal vs. external) The audit collection system shall be a part of the Product CA equipment.

5.4.7. Notification to event-causing subject The notice that an event was audited shall not provide to the operator who caused the event.

5.4.8. Vulnerability assessments The audit procedures shall include vulnerability assessments regarding the operation of Product

CA. In addition, Product CA shall take measures to prevent damages caused by vulnerabilities

of hardware and software based on the latest information regarding the vulnerabilities.

42

Table 3: Time control relating to audits

Issues Time controls

Review of audit logs Auditor shall review audit logs once a month on a

predetermined day.If the day is not an operating day, Auditor

shall perform the review on the nearest operating day.

Retention period of onsite

audit logs

No shorter than a month.

Retention period of offsite

audit logs

No shorter than 3 years.

Retention period of backup

of audit logs

No shorter than 3 years.

5.5. Records archival Operator shall archive the data hereinafter set forth on a routine basis for the following purposes.

To retroactively check the operation history in response to an inquiry or a claim by a

customer or others.

To re-issue the certificates and CRL that are valid at the moment when the data necessary

for the operations of Product CA are lost due to a disaster, or accident.

5.5.1. Types of records archived At a minimum, the following type of information shall be archived to achieve the purposes stated

in the above.

Product certificates

CRL’s

Audit logs

The Product CA private signing keys shall not be archived.

5.5.2. Retention period for archive The table specifies the minimum retention period of archive data, which is stored in external

storage media such as CD-R.

43

Table 4: Time control relating to archive records

Issues Time controls

Generation of archives Operator shall archive the data set forth in this document once a

month on a predetermined day.If the day is not an operating day,

Auditor shall perform the review on the nearest operating day.

Inspection of archives Archive records shall be inspected on the first operating day of the

second week of January every year.

Retention of archives No shorter than 10 years.

5.5.3. Protection of archive Product CA shall take measures so that archive records shall not be lost for any reasons such as

disaster and theft or shall not be modified.

The format of the storage media that store archive records shall not allow modification,

deletion or addition of data recorded on them.

The storage media that retain archive records shall be kept in a locked cabinet.

5.5.4. Archive backup procedures No stipulation.

5.5.5. Requirements for time-stamping of records No stipulation.

5.5.6. Archive collection system (internal vs. external) No stipulation.

5.5.7. Procedures to obtain and verify archive information Table 4 specifies the frequencies of the inspection of loss and modification of archive records.

5.6. Key changeover Product CA’s private signing keys shall be changed with the frequency hereinafter set forth so

that no Product certificate shall not be valid after the expiration day of the related Product CA’s

private signing key.

5.7. Compromise and disaster recovery 5.7.1. Incident and compromise handling procedures FX CAP Chair shall recognize the facts of incident and compromise and shall order Product CA

to take necessary measures.

44

5.7.2. Computing resources, software, and/or data are corrupted Product CA shall retain spares of equipments and machineries as well as backup of software and

data, and shall reestablish its operation using the spares and backup as quickly as possible in

case that the equipments, machineries, software or data are destroyed.

5.7.3. Entity private key compromise procedures In case of compromise of Product CA’s private signing keys, FX CAP Committee Chair shall

recognize the fact of the compromise and shall identify necessary measures to be taken.FX CAP

Committee may take measures including the following.

Termination of Product CA.

Changeover of Product CA’s private signing keys.

Revocation of related certificates

Issue of new certificate.

Product CA shall disclose the fact of the compromise of its private signing keys and the

measures that Product CA took.

5.7.4. Business continuity capabilities after a disaster Product CA shall reestablish its operation as quickly as possible using spare equipment and

machines and backup of software and data.

5.8. CA or RA termination FX CAP Committee retains the right to make final decision regarding the termination of Product

CA.

Operating Group shall perform the following tasks in response to the decision of the termination.

Backup software and data.

Reposit backup and archive records.

In addition, FX CAP Committee shall specify the following.

Organization that performs administration of backup and archive records and responds to

inquiries and claims.

45

6. TECHNICAL SECURITY CONTROLS

6.1. Key pair generation and installation 6.1.1. Key pair generation Private Key Administrator of Operating Group shall generate Product CA’s public key pairs

utilizing functions of cryptographic modules.

The generation of Product CA’s public key pairs shall be under the multiple-person control, and

hence it shall be performed in the presence of plural Private Key Administrators.

The private signing keys of the key pairs shall be confined within the cryptographic modules

except for their backup generated in accordance with the authorized procedures.

In contrast, the client-side administrator shall generate Product public key pairs utilizing functions

of Product.

Product shall be equipped with the function for generation of Product public key pair, which is

implemented as hardware, software or their combination compliant to the specification of the

Product.

Product private key shall be retained inside Product.The specification of the Product shall

determine whether or not backup of the Product private keys are allowed.

Also, Product shall be implemented so that the function of generation of Product public key pairs

and the generated Product private keys shall be protected at an appropriate level.FX owes the

product liability with respect to the safety of the function and the Product private keys.

6.1.2. Private key delivery to subscriber No private key delivery of Product private keys shall not be performed, since the receiver of a

Product private key generates it utilizing functions of Product.

6.1.3. Public key delivery to certificate issuer Product that generated a Product public key pair shall send the public key of the pair to Product

CA specifying it in a message in accordance with CSR.

In principle, the message, Certificate Issuance Request, is delivered over the networks.

6.1.4. CA public key delivery to relying parties Product CA’s public keys shall be disclosed via the repositories of Product CA by appropriate

means with functions to prevent unauthorized modification and replacement of the keys.In

addition, Product CA shall verify the validity of the public keys disclosed via the repositories on a

regular basis.

46

Product may provide functions to deliver Product CA’s public keys to some other points. In the

case, Product shall provide functions to prevent unauthorized modification and replacement of

the keys as well.

6.1.5. Key sizes A CA’s public key pair of Product CA shall comply fully with the RSA public key algorithm

identified by the following algorithm identifier and shall include a 2048-bit-long modulus.

sha-1WithRSAEncryption {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 5}

On the other hand, a Product public key pair shall comply fully with the RSA public key algorithm

identified by the following algorithm identifier and shall include a modulus whose bit length is no

shorter than 1024.

RSAEncryption {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 1}sha-1WithRSAEncryption {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 5}

6.1.6. Public key parameters generation and quality checking The modulus of an RSA public key pair shall be generated using a pseudo-random number

generating algorithm whose output clears high-level criteria of randomness, and further shall not

be subject to known attacks that take advantage of vulnerability of moduli such as those attacks

based on the Fermat method of factoring numbers.

6.1.7. Key usage purposes (as per X.509 v3 key usage field) The purposes of usage of Product CA’s public key pairs shall be restricted to the following.

Generation and verification of signatures associated with Product certificates.

Generation and verification of signatures associated with CRL’s of Product certificates.

6.2. Private Key Protection and Cryptographic Module Engineering Controls

6.2.1. Cryptographic module standards and controls All of generation, backup, restoring, destruction and changeover of Product CA’s private signing

keys shall be performed by functions of cryptographic modules.

The cryptographic modules that Product CA deploys shall fulfill the requisites stated below.

The processes of generation and use of private keys shall be throughout confined within the

modules.

In particular, the private keys shall be protect to unauthorized accesses by means such as

encryption and tamper-resistant techniques.

47

The functions of the modules, except for backup and restore of the private keys, shall not

require output of the private keys to the outside of the modules or input of the private keys

into the modules.

The Product CA equipment shall be equipped with means to restrict access to the operations

performance of which necessarily involves access to Product CA’s private signing key, and

the restriction of the access shall be performed based on authentication of identity and

rights.

The modules shall be validated in accordance with the FIPS 140 Level 3 requirements.

Product CA shall verify that the manufacturers of the modules performed appropriate quality

management including the document-based process management when they manufactured

the modules.

Product CA shall select trusted traders for purchase and transportation of the cryptographic

modules.

The cryptographic modules shall be installed in locked cabinets placed in rooms access to which

is restricted based on authentication of identity and rights.

In case of disposal, the cryptographic modules shall be destroyed by means of electromagnetic

erasure, physical fracture and so forth so that the stored data including private keys shall not be

retrieved any longer.

Personnel of Operating Group shall supervise the events of purchase, transportation, installation

and disposal of cryptographic modules, and shall generate records of the processes and results

of the events.Auditor shall review the records as a part of the compliance audits.

6.2.2. Private key (n out of m) multi-person control Any operation to Product CA’s private signing keys shall be performed in the presence of plural

Private Key Administrators.

6.2.3. Private key escrow Private key escrow shall not be performed.

6.2.4. Private key backup Backup of Product CA’s private signing keys shall be generated and shall be stored in external

storage media in case where the keys stored in the cryptographic modules are lost or

damaged.The backup of Product CA’s private signing keys stored in external storage media shall

be protected by means including the following.

The keys shall be encrypted.

48

The format of the storage media shall not allow modification, deletion or addition of data

recorded on them

Decryption (restoring) of the encrypted keys shall be performed inside the cryptographic

modules.

At least a single set of the storage media that store the backup of private keys shall be kept in a

locked safe such that it is opened in the presence of multiple personnel including at least one

Private Key Administrator.

6.2.5. Private key archival Private key archival shall not be performed.

6.2.6. Private key transfer into or from a cryptographic module Product CA’s private signing keys shall be generated inside the cryptographic modules only

using functions of the modules, and hence input of private keys into the modules shall be

restricted to the case of restoring the keys from backup in case of loss of the private key stored in

the modules.

In the same way, output of the private key from the cryptographic modules shall be restricted to

the case of generating backup of the keys.

Input and output of Product CA’s private signing keys to and from the cryptographic modules

shall require the presence of multiple Private Key Administrators.

6.2.7. Private key storage on cryptographic module Product CA’s private signing keys shall be stored inside the cryptographic modules.

6.2.8. Method of activating private key Activation of Product CA’s private signing keys requires an operation of the cryptographic

modules, and none other than Private Key Administrator shall not perform the operation

necessary to activate the keys.

The operation of the cryptographic modules to activate Product CA’s private keys shall require

the presence of multiple Private Key Administrators.

Once a Product CA’s private signing key is activated, it shall continue to be active until it is

explicitly deactivated.

6.2.9. Method of deactivating private key None other than Private Key Administrator shall not perform the operation of the cryptographic

modules necessary to deactivate the keys.

49

6.2.10. Method of destroying private key Destruction of Product CA’s private signing keys shall require the presence of multiple Private

Key Administrators operating the cryptographic modules.

In case of disposal of storage media storing backup of Product CA’s private signing keys, the

media shall be destroyed by means such as electromagnetic erasure, physical fracture and so

forth so that the keys shall not be retrieved from the disposed media.

6.2.11. Cryptographic Module Rating The cryptographic modules that Product CA deploys shall meet or exceed Security Level 3

specified by FIPS 140-2.

6.3. Other aspects of key pair management 6.3.1. Public key archival No stipulation.

6.3.2. Certificate operational periods and key pair usage periods The expiration date of a Product certificate shall not exceed that of the Product CA’s public key

pair that Product CA used to sign the certificate.

The validity period of Product CA’s public key pairs shall be 10 years, while that of Product

certificates shall not exceed 5 years.

6.4. Activation data 6.4.1. Activation data generation and installation Access to the Product CA equipment shall require authentication of identity implemented using

both the smartcard and PKI, and activation of the smartcard shall require input of predetermined

passwords.

6.4.2. Activation data protection The private keys stored in a smartcard shall be protected by means of the access control

function and the tamper-resistant characteristics that the smartcard provides.

The password to activate the smartcard shall have sufficient length and sufficient variety in

characters so that it shall not be subject to attacks of guessing it (e.g. the dictionary attack).Also,

the password shall be changed with an appropriate period.The length, character variety, validity

period and other administrative factors of the password shall be pursuant to written stipulations,

which may be in conformance with standards such as FIPS 112.

6.4.3. Other aspects of activation data No stipulation.

50

6.5. Computer security controls 6.5.1. Specific computer security technical requirements The following computer security functions may be provided by the operating system, or through a

combination of operating system, software and hardware. The computers used to perform

duties with respect to the operation of Product CA and its ancillary parts shall include the

following functionality.

Require authenticated logins.

Provide Discretionary Access Control.

Provide a security audit capability.

Restrict access control to Product CA services.

Enforce separation of duties for roles.

Require use of cryptography for session communication and database security.

Provide a capability for audits of the operation of Product CA.

6.5.2. Computer security rating No stipulation.

6.6. Life cycle technical controls 6.6.1. System development controls System development for services of Product CA and its ancillary parts shall fulfill the requisites

stated below.

Use software and equipments that have been designed and developed with appropriate

quality management based on, for example, a formal, documented development

methodology

Hardware and software developed specifically for Product CA shall be developed under

control with respect to personnel, organization and environment (e.g. network, software and

equipments for development, physical environment) aspects, and the development process

shall be defined and documented.In particular, to prevent leak of confidential information

relating to the development, Product CA shall assign trusted developers, enforce training to

them, restrict access to documents and restrict entering and leaving of the development

spaces.

51

Product CA shall select trusted traders for purchase and transportation of hardware

equipments.

Software and hardware equipments of Product CA and its ancillary parts shall not be used for

purposes other than their initially planned ones.

Proper care shall be taken to prevent malicious software from being installed. For example,

Product CA shall assign trusted vender for purchase of software and shall scan purchased

software for malicious code.

The same stipulations as the above shall apply to the operation of maintenance and update of

the systems of Product CA and its ancillary parts.

6.6.2. Security management controls The configuration of the Product CA system and any modification and upgrades shall be

documented and stored for a predetermined time period.

The Product CA software, when first installed, shall be verified as being the version intended for

use and being that supplied from the vender with no modifications.

Personnel of Operating Group shall continuously check warnings, recommendations and

correction programs published regarding vulnerability and security of the installed software.In

addition, the personnel shall at least weekly verify conformance of the Product CA system to the

configuration and reflection of the latest warnings, recommendations and correction programs to

the current configuration.

6.6.3. Life cycle security controls No stipulation.

6.7. Network security controls The Product CA system shall be logically located in networks isolated from the outside by means

such as the firewall.The latest reports regarding vulnerability of hardware and software shall be

always evaluated, and security measures against the reported vulnerability (e.g. correction

programs) shall be contantly employed.

6.8. Time-stamping No stipulation.

52

7. CERTIFICATE, CRL/ARL, AND OCSP PROFILES

7.1. Certificate profile 7.1.1. Version number(s) Product CA shall issue X.509 v3 certificates.

7.1.2. Certificate extensions No stipulation.

7.1.3. Algorithm object identifiers Product CA shall generate signatures to the certificates that it issues in accordance with the

algorithm identified by the following OID.

sha-1WithRSAEncryption {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 5}

7.1.4. Name forms The issuer and subject fields shall be populated with an X.500 Distinguished Name.

7.1.5. Name constraints No stipulation.

7.1.6. Certificate policy object identifier The certificates that Product CA issues shall assert the following certificate policy object

identifier.

CP and CPS for Product CA 1.3.6.1.4.1.297.1.5.1.3

7.1.7. Usage of Policy Constraints extension No stipulation.

7.1.8. Policy qualifiers syntax and semantics No stipulation.

7.1.9. Processing semantics for the critical Certificate Policies extension No stipulation.

7.2. CRL/ARL profile 7.2.1. Version number(s) Product CA shall issue X.509 v2 CRL’s.

7.2.2. CRL/ARL and CRL/ARL entry extensions No stipulation.

53

7.3. OCSP profile Product CA does not support the service of OCSP.

7.3.1. Version number(s) No stipulation.

7.3.2. OCSP extensions No stipulation.

54

8. COMPLIANCE AUDIT AND OTHER ASSESSMENTS

8.1. Frequency or circumstances of assessment Audit Group shall perform compliance audits to ensure that the requirements of this CP and CPS

is being implemented and enforced in the operation of Product CA and its ancillary parts, and the

audits shall be performed at the following points of time.

Once a year on a predetermined date.

Whenever serious violation of this CP and CPS is found.

Whenever FX CAP Committee recognizes necessity of the performance.

8.2. Identity/qualifications of assessor Auditor who belongs to Auditor Group shall perform the compliance audit.

8.3. Assessor’s relationship to assessed entity Auditor shall be sufficiently organizationally separated from any of the operation of Product CA

except for the audit activities.

8.4. Topics covered by assessment All the operation of Product CA specified in this document, except for the audit activities, shall be

in the scope of the compliance audit.

8.5. Actions taken as a result of deficiency Auditor Group shall present the result of the compliance audits to FX CAP Committee.

On receipt of the report, FX CAP Committee shall review the report, and in a case where it

recognize the deficiency, shall take appropriate measures to correct the reported deficiency as

quickly as possible.

FX CAP Committee may take the following measures to correct the deficiency.

Termination of Product CA.

Limited-term or unlimited-term suspension of a part or the whole of the operation of Product

CA.

Questioning to Operating Manager or responsible individuals.

Replacement of Operating Manager or responsible individuals.

Further assessment by a committee comprised of individuals who are fully independent of

the operation of Product CA.

55

8.6. Communication of results Audit Group shall generate document to report the result of the audits and shall submit it to FX

CAP Committee Chair.In addition, the submission of the written report and where necessary, oral

report by Auditors shall be performed directly to FX CAP Committee Chair.

On receipt of the report, FX CAP Committee Chair shall summon a meeting of FX CAP

Committee to evaluate the contents of the report.

FX CAP Committee, if it recognized no deficiency, authorizes the report.

On the contrary, if it recognized any discrepancy between this CP/CPS and the implementation

of Product CA, it shall take measures to resolve the discrepancy.

In case of emergency, FX CAP Committee Chair may order to take temporary measures prior to

holding of the FX CAP Committee meeting.Even in such case, FX CAP Committee Chair does

not gain immunity from holding of an FX CAP Committee meeting, and final measures to resolve

the recognized discrepancy shall be agreed by FX CAP Committee.

56

9. OTHER BUSINESS AND LEGAL MATTERS

9.1. Fees 9.1.1. Certificate issuance or renewal fees No stipulation.

9.1.2. Certificate access fees No stipulation.

9.1.3. Revocation or status information access fees No stipulation.

9.1.4. Fees for other services No stipulation.

9.1.5. Refund policy No stipulation.

9.2. Financial responsibility 9.2.1. Insurance coverage No stipulation.

9.2.2. Other assets No stipulation.

9.2.3. Insurance or warranty coverage for end-entities No stipulation.

9.3. Confidentiality of business information Since Product CA does not acquire business information from any entities other than FX, no

stipulation is given to this issue.

9.3.1. Scope of confidential information No stipulation.

9.3.2. Information not within the scope of confidential information No stipulation.

9.3.3. Responsibility to protect confidential information No stipulation.

9.4. Privacy of personal information Since Product CA does not acquire any personal information, no stipulation is given to this issue.

57

9.4.1. Privacy plan No stipulation.

9.4.2. Information treated as private No stipulation.

9.4.3. Information not deemed private No stipulation.

9.4.4. Responsibility to protect private information No stipulation.

9.4.5. Notice and consent to use private information No stipulation.

9.4.6. Disclosure pursuant to judicial or administrative process No stipulation.

9.4.7. Other information disclosure circumstances No stipulation.

9.5. Intellectual property rights No stipulation.

9.6. Representations and warranties 9.6.1. CA representations and warranties No stipulation.

9.6.2. RA representations and warranties No stipulation.

9.6.3. Subscriber representations and warranties No stipulation.

9.6.4. Relying party representations and warranties No stipulation.

9.6.5. Representations and warranties of other participants No stipulation.

9.7. Disclaimers of warranties No stipulation.

9.8. Limitations of liability No stipulation.

58

9.9. Indemnities No stipulation.

9.10. Term and termination 9.10.1. Term No stipulation.

9.10.2. Termination No stipulation.

9.10.3. Effect of termination and survival No stipulation.

9.11. Individual notices and communications with participants No stipulation.

9.12. Amendments 9.12.1. Procedure for amendment FX CAP Committee retains rights to amend this document.

After FX CAP Committee authorizes amendment of this document, the amended version shall be

disclosed by means specified 2.2 of this document. Moreover, the amended version becomes

valid at the moment of the disclosure.

9.12.2. Notification mechanism and period In principle, amendment of this document need not to be notified to clients of FX prior to its

disclosure as specified in 2.2 of this document.

However, if FX CAP Committee recognizes that the amendment would have a significant impact

to existing clients of FX, FX CAP Committee may notify the amendment prior to its disclosure by

any means.

9.12.3. Circumstances under which OID must be changed No stipulation.

9.13. Dispute resolution provisions No stipulation.

9.14. Governing law No stipulation.

9.15. Compliance with applicable law No stipulation.

59

9.16. Miscellaneous provisions 9.16.1. Entire agreement No stipulation.

9.16.2. Assignment No stipulation.

9.16.3. Severability No stipulation.

9.16.4. Enforcement (attorneys’ fees and waiver of rights) No stipulation.

9.16.5. Force Majeure No stipulation.

9.17. Other provisions No stipulation.