Title: Selfaudit report of AIST GRID CA
1Self-audit report ofAIST GRID CA
- Yoshio Tanaka (yoshio.tanaka_at_aist.go.jp)
- Information Technology Research Institute
- AIST, Japan
2Contents
- Overview and organization
- CA Architecture
- Results of self auditing
- 9 B scores
- 4 C scores
3Introduction of AIST
- One of the largest Natl 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
Tsukuba
40km
Narita
50km
Tokyo
50km
4Overview 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
5Issued 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
6Root CA Certificate
Data Version 3 (0x2) Serial
Number 1 (0x1) Signature Algorithm
sha1WithRSAEncryption Issuer CJP,
OAIST, OUGRID, CNCertificate Authority
Validity Not Before Oct 19 102835
2004 GMT Not After Oct 18 102835
2009 GMT Subject CJP, OAIST, OUGRID,
CNCertificate 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 CATRUE
X509v3 Authority Key Identifier ..
X509v3 Subject Key Identifier ..
7Organization
8Organization (contd)
9CA system Online CA NAREGI CA Software
Secure protocol Limited port
Web server (repository)
RA server (dedicated)
CA server (dedicated)
HSM
SafeNet LUNA CA3 FIPS 140-1 Level3
10Physical 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 2nd floor
- To enter the machine room
- To enter the CA room
- Only Security Officers and CA Operators are able
to enter the CA room.
11Physical controls (contd)
12Procedure for certificate enrollment
- Notification bysigned email
RA (user admin)
- Encrypted LICENSE IDby email
- Passphrase by FAX
CA operator
RA server (dedicated)
CA server (dedicated)
HSM
13Results of self-auditing Score B
- 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 - The CP/CPS documents should be structured as
defined in RFC 3647. - CP/CPS is structured based on RFC2527.
14Results of self-auditing Score B
- 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.
15Results of self-auditing Score B
- 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. - 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. - 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.
16Results of self-auditing Score B
- Certificates (and private keys) managed in a
software token should only be re-keyed, not
renewed. - 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. - 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.
17Results of self-auditing Score C
- When the CAs 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. - 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
18Results of self-auditing Score C
- 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. - 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.
19Summary
- 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!