1. National Institute of Advanced Industrial Science and Technology Self-audit report of AIST GRID CA Yoshio Tanaka (yoshio.tanaka@aist.go.jp) Information Technology Research Institute AIST, Japan

2. Contents Overview and organization CA Architecture Results of self auditing 9 B scores 4 C scores

3. Introduction of AIST One of the largest Nat ’ l Labs in Japan Research topics include Environment Material Bio/Life science Standards (JIS/OSI) Geographical survey Semiconductor device Computer Science etc. 3,500+ employees AIST Tsukuba Main Campus 7 other campuses across Japan Narita Tokyo Tsukuba 50km 40km 50km

4. Overview of AIST Grid CA Identification AIST: 1.3.6.1.4.1.18936 GRID: 1.3.6.1.4.1.18936.1 AIST GRID CA: 1.3.6.1.4.1.18936.1.11 AIST GRID CA CP: 1.3.6.1.4.1.18936.1.11.2 Community and Applicability Issue certificates for Researchers in AIST Researchers in out side of AIST who have research collaboration with AIST Issue certificates for Grid authentication

5. Issued certificates User certificates: 136 Valid: 31 Invalid (revoked or expired): 105 Host certificates: 1706 Valid: 509 Invalid (revoked or expired): 1197 LDAP certificates: 262 Valid: 33 Invalid (revoked or expired): 229

6. Root CA Certificate Data: Version: 3 (0x2) Serial Number: 1 (0x1) Signature Algorithm: sha1WithRSAEncryption Issuer: C=JP, O=AIST, OU=GRID, CN=Certificate Authority Validity Not Before: Oct 19 10:28:35 2004 GMT Not After : Oct 18 10:28:35 2009 GMT Subject: C=JP, O=AIST, OU=GRID, CN=Certificate Authority Subject Public Key Info: Public Key Algorithm: rsaEncryption RSA Public Key: (2048 bit) Modulus (2048 bit): ….. X509v3 extensions: X509v3 Key Usage: critical Certificate Sign, CRL Sign X509v3 Basic Constraints: critical CA:TRUE X509v3 Authority Key Identifier: ….. X509v3 Subject Key Identifier: …..

7. Organization

8. Organization (cont’d) Main role Security Officer (2 officers) Administrates all tasks on the CA system including the CA private key Akihiro Iijima, Motokuni Tsushima CA Operator (3 operators) Administrates RA and CA servers Generates LICENSE IDs and deliver them to subscribers Maintains the CA system Mototsune Oomura, Takahiro Hamanishi, Jin Ishii Help Desk Contact point for users about CA operation Akihiro Iijima, Mototsune Oomura, Jin Ishi Takahiro Hamanishi, Yoshio Tanaka User Administrator (1 admin) Accepts user enrollment Examines user information and approve the user Yoshio Tanaka

9. CA system: Online CA + NAREGI CA Software RA server (dedicated) CA server (dedicated) HSM Web server (repository) Secure protocol Limited port SafeNet LUNA CA 3 FIPS 140-1 Level3

10. Physical controls CA system is located in AIST Tsukuba Center. A dedicated CA room inside the machine room. Multiple-levels of authentication for access to the CA room To enter the building To enter the 2 nd floor To enter the machine room To enter the CA room Only Security Officers and CA Operators are able to enter the CA room.

11. Physical controls (cont’d)

12. Procedure for certificate enrollment RA server (dedicated) CA server (dedicated) HSM RA (user admin) CA operator 1.Application by email 2.F2F vetting 3.Notification by signed email 4.Encrypted LICENSE ID by email 5.Passphrase by FAX

13. Results of self-auditing: Score B (3)Whenever there is a change in the CP/CPS the O.I.D. of the document must change and the major changes must be announced to the responsible PMA and approved before signing any certificates under the new CP/CPS. New OID is not assigned for minor (editorial) changes (5)The CP/CPS documents should be structured as defined in RFC 3647. CP/CPS is structured based on RFC2527.

14. Results of self-auditing: Score B (13)The pass phrase of the encrypted private key must also be kept on offline media, separated from the encrypted private keys and guarded in a secure location where only the authorized personnel of the CA have access. Alternatively, another documented procedure that is equally secure may be used. We do keep the pass phrase on offline media and stored in a safe place where separated from the encrypted private keys, but no description in CP/CPS.

15. Results of self-auditing: Score B (22)Certificate revocation can be requested by users, the registration authorities, and the CA. Others can request revocation if they can sufficiently prove compromise or exposure of the associated private key. The CP/CPS does not describe that “others can request revocation.” (23)The CA must react as soon as possible, but within one working day, to any revocation request received. The CP/CPS does not describe “but within one working day.” (24)An end entity must request revocation of its certificate as soon as possible, but within one working day after detection of… The CP/CPS does not describe “but within one working day.”

16. Results of self-auditing: Score B (43)Certificates (and private keys) managed in a software token should only be re-keyed, not renewed. (45)Certificates may be renewed or re-keyed for more than 5 years without a form of identity and eligibility verification, and this procedure must be described in the CP/CPS. The CP/CPS does not clearly distinguish re-key and renew. (57)The CA shall provide their trust anchor to a trust anchor repository, specified by the accrediting PMA, via the method specified in the policy of the trust anchor repository. Currently, AIST GRID CA does not provide its trust anchor to a trust anchor repository.

17. Results of self-auditing: Score C (15)When the CA’s cryptographic data needs to be changed, such a transition shall be managed; from the time of distribution of the new cryptographic data, only the new key will be used for certificate signing purposes. (16)The overlap of the old and new key must be at least the longest time an end-entity certificate can be valid. The older but still valid certificate must be available to verify old signatures – and the secret key to sign CRLs – until all the certificates signed using the associated private key have also expired. The CP/CPS does not describe the transition procedure

18. Results of self-auditing: Score C (25)Revocation requests must be properly authenticated. Authentication of revocation requests descried in the CP/CPS is applicable only for the following case: A user, who has a valid certificate and corresponding private key, requests revocation of her/his/host certificate. (6)Over the entire lifetime of the CA it must not be linked to any other entity. Currently, not yet implemented. Need to consider how to implement.

19. Summary Revision of the CP/CPS and operation will be made in 2 months Our Root CA certificate will be expired in October next year. Need to establish the transition procedure by this Spetember!