Check List Results of Guidelines for auditing Grid CAs version 1.0-b3
Sangwan Kim (sangwan@kisti.re.kr)
Jun 18 2007
Score of evaluation:
A: No problem
B: Recommendation (minor change)
C: Recommendation (major change)
D: Advice (must change)
X: Could not evaluate (N/A)
Evidence |
Method |
Score |
Memo |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Certification Authority |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
1. CP/CPS |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
(1) Every CA must has a CP/CPS |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
CP/CPS |
Trivial |
A |
CP/CPS available at |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
(2) Every CA must assign its CP/CPS an O.I.D. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
RFC 3647 section 1.2 |
Is OID assigned to the CPS |
A |
1.3.6.1.4.1.14305.1.1.1.2.0 |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
End Entity certificate |
Does EE cert. have PolicyID v3 extension which is set to an OID? |
|
Check a certificate published at: http://ca.gridcenter.or.kr:8080/issued/ |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
X509v3 extensions: ...(skip)... X509v3 Certificate Policies: Policy: 1.3.6.1.4.1.14305.1.1.1.2.0 |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
OID registry (e.g. IANA) |
Is OID correct? |
A |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||
(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. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
RFC 3647 sec. 9.12 |
Does CP/CPS describe the CP/CPS change procedures, publication and notification policies, and approval procedures? |
A |
- Major changes such as changes in policy or technical security controls need to be approved by the APGrid PMA. - New OID will be assigned to the revised document for such major changes would be made. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Interview |
Ask the details of the CP/CPS administration. For example, who makes changes and who makes decision (approval)? |
A |
As section 5.2.1, CAO can make changes of CP/CPS and these changes must be approved by SA(system auditor) and the regional PMA. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
(4) All the CP/CPS under which valid certificates are issued must be available on the web. Evidence Method |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Sections in RFC 3647 2.2, 4.4.2, 4.4.3, 4.6.6, 4.6.7, 4.7.6, 4.7.7, 4.8.6, 4.8.7 |
Does CP/CPS describe that all the CP/CPS under which valid certificates are issued are available on the web? |
A |
See Section 2.2 |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Web repository |
Are all the CP/CPSes available on the web? |
A |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||
(5) The CP/CPS documents should be structured as defined in RFC 3647. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Sections in 3647 1.1 |
Does CP/CPS describe that the CP/CPS is structured as defined in RFC 3647? |
A |
See section 1.1 |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
CP/CPS |
CP/CPS Is the CP/CPS structured as defined in RFC 3647? |
A |
Yes |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Evidence |
Method |
Score |
Memo |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
2. CA System |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
(6) The CA system must be a dedicated machine. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Sections in 3647 6.5.1 |
Is the CA system a dedicated machine? |
A |
Both the public web server and CA signing machine are for dedicated purpose. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Inspect |
CA system |
A |
OK |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
(7) The CA system must be located in a secure environment where access is controlled. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Sections in 3647 5.1.1, 5.1.2 |
Is the CA system located in a secure environment where access is controlled? |
A |
CA servers are located in different restricted machine rooms respectively. Allowed CA managers can access to them. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Interview |
Ask the details of access control to the CA system and its location. For example, who can access to the CA system? How is the access controlled? Is a single person allowed to access to the CA system? How the access log is recorded? |
A |
Public web server is located in a machine room(A). System administrator and certificate authority operators can access to the room(A). The CA signing machine is located is in another machine room(B). The certificate authority operator can access to the room(B), and the system administrator can access to the room(B) after a permission from the certificate authority operator. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Inspection |
Location of the CA system |
A |
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
(8) The CA system must be completely off line or use at least a FIPS 140-2 level 3 Hardware Security Module or equivalent to protect the private key of CA. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Sections in 3647 6.1.1, 6.2.1, 6.7 |
Is the CA system completely off-line or use HSM? |
A |
CA signing machine is completely off-line. The public web server is connected to Internet. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
HSM manual |
Is the HSM at least FIPS 140-2 level 3? |
X |
Not applicable |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Inspection |
CA system |
A |
Okay |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
(9) The secure environment must be documented and approved by the PMA, and that document or an approved audit thereof must be available to the PMA. Can be covered by the auditing item (7). |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Evidence |
Method |
Score |
Memo |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
3. CA Key |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
(10) The CA key must have a minimum length of 2048 bits |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Sections in 3647 6.1.5 |
Is the CA key length 2048 bit? |
A |
The CA key length is 2048 bits. See section 6.1.5. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Certificate Profile |
Is the CA key length 2048 bit? |
A |
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
CA Certificate |
Is the CA key length 2048 bit? |
A |
See the published CA certificate information http://ca.gridcenter.or.kr:8080/certs/certificates/722e5071.0 http://ca.gridcenter.or.kr:8080/certs/certificates/722e5071.txt |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
(11) Software-based private key of the CA must be protected with a pass phrase of at least 15 elements and that is known only by designated personnel of the CA. On-line CAs using an HSM must adopt a similar or better level of security. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Sections in 3647 6.2.8 |
Does the CPS describe the protection of the CA private key? |
A |
See 6.2.8 or 6.4 |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Interview |
Ask CA operators who knows the pass phrase. Recommend CA operators to implement multi-person control. |
A |
2 certificate authority operators know the pass phrase of the CA private key. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
(12) Copies of the encrypted private key must be kept on offline mediums in secure places where access is controlled. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Sections in 3647 6.2.4 |
Is the CA private key backup in offline medium? |
A |
Yes See 6.2.4 |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Inspection |
Backup medium and its place. |
A |
Okay |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
(13) The pass phrase of the encrypted private key must be kept also on an offline medium, separated from the encrypted private keys and guarded in a safe place where only the authorized personnel of the CA have access. Alternatively, another documented procedure that is equally secure may be used. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Sections in 3647 6.2.4, 6.2.5 |
Is the CA private key backup in offline medium? |
A |
OK CD-ROM and memory stick |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Inspection |
Backup medium and its place. |
A |
OK |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
(14) The on-line CA architecture should provide for a (preferably tamper-protected) log of issued certificates and signed revocation lists. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Sections in 3647 5.5.1, 5.5.3 |
Does the on-line CA provide log of issued certificates and signed revocation list? |
A |
See |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Inspection |
Log of issued certificates and signed revocation list. |
A |
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
(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. CAÀÇ ¾ÏÈ£ÇÐÀû µ¥ÀÌÅÍ¿¡ ´ëÇÑ º¯°æÀº °ü¸®µÇ¾î¾ß Çϸç, cryptographic data°¡ distribution µÇ´Â ½ÃÁ¡ºÎÅÍ´Â ÀÎÁõ¼ ¼¸íÀ» À§Çؼ »õ·Î¿î ۸¸ »ç¿ëµÇ¾î¾ß ÇÑ´Ù. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Sections in 3647 3.3.1, 4.6, 4.7, 5.6 |
How does the CPS describes transition of the CA¡¯s cryptographic data? |
A |
See Section 5.6 |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
End entity certificates (if there was a transition of the CA¡¯s cryptographic data) |
Is new EE cert. signed by a new cryptographic data? |
A |
See Section 5.6 |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
(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. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Sections in 3647 3.3.1, 4.6, 4.7, 5.6 |
How does the CPS describe transition of the CA¡¯s cryptographic data? |
A |
See Section 5.6 |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
End entity certificates Older CA certificate and private key (if there was a transition of the CA¡¯s cryptographic data) |
Is new EE cert. signed by a new cryptographic data? Is the older but still valid certificate available if there is still valid certificates signed by the private key? |
A |
See Section 5.6 |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Evidence |
Method |
Score |
Memo |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
4. CA Certificate |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
(17) Lifetime of the CA certificate must be no longer than 20 years. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Sections in 3647 5.6 |
How long is the lifetime of the CA certificate? |
A |
10 years See 6.3.2 |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
CA certificate |
Check the lifetime of the CA certificate. |
A |
10 years Check http://ca.gridcenter.or.kr:8080/certs/certificates/722e5071.crt |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
(18) Lifetime of the CA certificate must be no less than two times of the maximum life time of an end entity certificate. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Sections in 3647 5.6 |
How long are the lifetimes of the CA certificate and end entity certificate? |
A |
CA cert: 10 years EE cert: 1 year See Section 6.3.2 |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
CA certificate and end entity certificate |
Check the lifetime of the CA certificate and end entity certificate. |
A |
Check certificates: |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
(19) The CA certificate must have the extension basicConstraints marked as critical. - Value of x509 Basic Constraints must be - CA:TRUE |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Sections in 3647 7.1.2 |
Is x509 Basic Constraints set and marked as critical? Is x509 Basic Constraints set to CA:TRUE? |
A |
See section 7.1.2 |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
CA certificate |
Check x509 Basic Constraints of the CA certificate. |
A |
See the CA certificate file http://ca.gridcenter.or.kr:8080/certs/certificates/722e5071.0 http://ca.gridcenter.or.kr:8080/certs/certificates/722e5071.txt |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
(20) The CA certificate must have the extension keyUsage and it should be marked as critical. - Value of x509 Key Usage must include at least - keyCertSign, cRLSign |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Sections in 3647 7.1.2 |
Is x509 Key Usage set and marked as critical? If not, the reason must be explained. Is x509 Key Usage includes keyCertSign and cRLSign?? |
A |
See section 7.1.2 |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
CA certificate |
Check x509 Key Usage of the CA certificate. |
A |
See the CA certificate file http://ca.gridcenter.or.kr:8080/certs/certificates/722e5071.0 http://ca.gridcenter.or.kr:8080/certs/certificates/722e5071.txt |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
(21) The profile of the CA certificates must also comply with the current IGTF and OGF certificate profile guidelines before being included in any distribution of certificates. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Sections in 3647 7.1 |
Check profile of the CA certificate (details should be described in the OGF/IGTF document). |
A |
See Section 7.1 |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
CA certificate |
Check profile of the CA certificate (details should be descried in the OGF/IGTF document). |
A |
Yes |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
CA Certificate: X509v3 Basic Constraints: critical, CA:TRUE X509v3 Key Usage: critical, Certificate Sign (keyCertSign), CRL Sign (cRLSign), Digital Signature (digitalSignature), Non Repudiation (nonRepudiation), Key Encipherment (keyEncipherment) X509v3 Subject Alternative Name: email:ca@gridcenter.or.kr, URI:http://ca.gridcenter.or.kr/ X509v3 Issuer Alternative Name: email:ca@gridcenter.or.kr, URI:http://ca.gridcenter.or.kr/ Certificate Policies: 1.3.6.1.4.1.14305.1.1.1.2.0 CRL distibutoin point - removed
User Certificates: X509v3 Basic Constraints: critical, CA:FALSE X509v3 Key Usage: critical, Digital Signature (digitalSignature), Non Repudiation (nonRepudiation), Key Encipherment (keyEncipherment), Data Encipherment (dataEncipherment) X509v3 Extended Key Usage: TLS Web Client Authentication(clientAuth) X509v3 Issuer Alternative Name: email:ca@gridcenter.or.kr, URI:http://ca.gridcenter.or.kr/ X509v3 CRL Distribution Points: URI://ca.gridcenter.or.kr/CRL/ Certificate Policies: 1.3.6.1.4.1.14305.1.1.1.2.0
Host Certificates: X509v3 Basic Constraints: critical, CA:FALSE X509v3 Key Usage: critical, Digital Signature (digitalSignature), Key Encipherment (keyEncipherment), Data Encipherment (dataEncipherment) (non repudation - should not be here) X509v3 Extended Key Usage: TLS Web Server Authentication(serverAuth), TLS Web Client Authentication(clientAuth) X509v3 Issuer Alternative Name: email:ca@gridcenter.or.kr, URI:http://ca.gridcenter.or.kr/ X509v3 Subject Alternative Name: DNS:<FQDN of the host> X509v3 CRL Distribution Points: URI://ca.gridcenter.or.kr/CRL/ Certificate Policies: 1.3.6.1.4.1.14305.1.1.1.2.0 subjectAlternativeName must be included - FQDN
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Evidence |
Method |
Score |
Memo |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
5. Certificate Revocation |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
(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 subscriber is known to have violated his obligations. -- too strong condition --> Modified Section 4.9.1
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Sections in 3647 4.8.2, 4.9.2 |
Who can request revocation? |
A |
See section 4.9.2 KISTI GRID CA will accept a revocation request made by - The certificate subscriber - KISTI GRID CA/RA - Any other entity presenting evidence of circumstances as described in section 4.4.1 |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
(23) End entity must request revocation of its certificate as soon as possible, but within one working day after detection of - he/she lost or compromised the private key pertaining to the certificate, - the data in the certificate are no longer valid. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Sections in 3647 4.9.1 |
Does end entity obligation include requesting revocation if she/he lost or compromised the private key or the data in the certificate are no longer valid? |
A |
section 4.9.1 |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
(24) Revocation requests must be properly authenticated. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Sections in 3647 4.9.3 |
How is a revocation request authenticated? |
A |
section 4.9.3 |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Interview |
Ask the detailed flow of revocation. |
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Evidence |
Method |
Score |
Memo |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
6. Certificate Revocation List (CRL) (25) Every CA must generate CRLs. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Sections in 3647 4.9.7 |
Does the CA issues CRLs? |
A |
Yes Section 4.9.7 |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Web repository |
Are CRLs available on the web? |
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
(26) The CRL lifetime must be no more than 30 days. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Sections in 3647 4.9.9 |
How long is the lifetime of the CRL? |
A |
Yes See 4.9.7 |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Issued CRLs |
Is the lifetime of a CRL less than 30 days? |
A |
Directory: http://ca.gridcenter.or.kr:8080/CRL/ the latest CRL file: |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
(27) Every CA must issue a new CRL at least 7 days before expiration (of CRL). |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Sections in 3647 4.9.9 |
Is a new CRL issued at least 7 days before expiration? |
A |
See Section 4.9.7 |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Issued CRLs |
Is a CRL issued at least 7 days before expiration? |
A |
See Section 4.9.7 |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
(28) Every CA must issue a new CRL immediately after a revocation. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Sections in 3647 4.9.9 |
Is a new CRL issued immediately after a revocation? |
A |
See Section 4.9.7 |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Interview |
How does the CA issue a CRL if it receives multiple revocation requests simultaneously? |
A |
The CA should process the certificate revocation request within 1 working day from the recognition of the request. CA process the multiple revocation request simultaneously and issues and publishes a new single CRL, but the maximum delay does not exceed 1 working day. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Issued CRLs |
Check issued CRL to confirm that a CRL issued immediately after a revocation. |
X |
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
(29) The signed CRL must be published in a repository at least accessible via a Web. Can be covered by the auditing item (25). |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
(30) The repository must be run at least on a best-effort basis, with an intended availability of 24x7. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Sections in 3647 2.1 |
Is the web repository available 24x7 in best effort basis? |
A |
Section 2.4, 9.8 |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Web repository |
Is the web repository available? |
A |
Yes |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
(31) The profile of the CRL must also comply with the current IGTF and OGF certificate profile guidelines before being included in any distribution of certificates. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Sections in 3647 7.2 |
Is the profile of the CRL compliant with the current IGTF and OGF certificate profile? |
A |
Section 7.2.1 |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Issued CRL |
Is the profile of the CRL compliant with the current IGTF and OGF certificate profile? |
A |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||
(32) The CRLs must be compliant with RFC3280, and is recommended to be version 2. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Sections in 3647 7.2.1 |
Is the CRL compliant with RFC 3280? What is the version of the CRL? |
A |
Section 7.2.1 CRL version 2. (RFC 3280) |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Issued CRL |
Is the CRL compliant with RFC 3280? What is the version of the CRL? |
A |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||
(33) The message digests of the certificates and CRLs must be generated by a trustworthy mechanism, like SHA1 (in particular, MD5 must not be used). |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Sections in 3647 7.2 |
How the message digests of the certificate and CRLs generated? |
A |
Section 7.2.2 |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
End entity certificates and issued CRL |
How the message digests of the certificate and CRLs generated? |
A |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||
7. End Entity Certificates and keys (34) The user key and the host key must have a minimum length of 1024 bits. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Sections in 3647 6.1.5 |
Is the length of user/host keys 1024 bit? |
A |
See Section 6.1.5 The minimum key length for user or host/service certificate is 1024 bits. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Certificate Profile |
Is the length of user/host keys 1024 bit? |
A |
Section 7.1.2 |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
User and host Certificate |
Is the length of user/host keys 1024 bit? |
A |
Check certificates published at: |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
(35) Lifetime of the user certificate and the host certificate must be no longer than 13 months. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Sections in 3647 5.6 |
How long is the lifetime of a user and a host certificate? |
A |
Section 6.3.2 |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
CA certificate |
Check the lifetime of a user and a host certificates. |
A |
Check certificates published at: |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
(36) Any user certificates must not be shared. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Sections in 3647 4.5.1 |
Is this described as an end-entity obligation? |
A |
See Section 4.5 User certificates must not be shared between multiple people. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
(37) Each host certificate must be linked to a single network entity. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Sections in 3647 3.1.2, 3.1.3 |
Does CP/CPS describe how each host certificate is linked to a single network entity? |
A |
See section 3.1.2 |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Host certificate |
Does the subject name represent a single network entity? |
A |
See section 3.1.2 |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
(38) The authority shall issue X.509 certificates to end entities based on cryptographic data generated by the applicant, or based on cryptographic data that can be held only by the applicant on a secure hardware token. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Sections in 3647 4.1, 4.2 |
How is an end entity¡¯s key generated? |
A |
KISTI online certificate request web site provide a method to generate user certificate CSR or it can be generated by the user by himself. The CA does not generate or keep any end entity's key. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Users manual |
How is an end entity¡¯s key generated? |
A |
With IE browser or a software(openssl or globus) by a subscriber. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Interview |
Ask CA operators to demonstrate the generation of a CSR. |
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
(39) Every CA should make a reasonable effort to make sure that end-entities realize the importance of properly protecting their private data. When using software tokens, the user must protect user¡¯s private key with a strong pass phrase, i.e., at least 12 characters long and following current best practice in choosing high-quality passwords. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Sections in 3647 6.2.8 |
Is this described as an end-entity obligation? |
A |
See Section 1.3.3 |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
(40) The end-entity certificates must be in X.509v3 format and compliant with RFC3280 unless explicitly stated otherwise. In the certificate extensions: - a Policy Identifier must be included and must contain an OID and an OID only - CRLDistributionPoints must be included and contain at least one http URL - it must - keyUsage must be included and marked as critical - basicConstraints should be included and it must be set to ¡®CA: false¡¯ and marked as critical - if an OCSP responder, operated as a production service by the issuing CA, is available, AuthorityInfoAccess must be included and contain at least one URI - for certificates bound to network entities, a FQDN shall be included as a dnsName in the SubjectAlternativeName - for host certificate |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Sections in 3647 7.1 |
Does the X.509 v3 extensions conform these requirements? |
A |
Section 7.1 |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Certificate Profile (if there is a separate document) |
Does the X.509 v3 extensions conform these requirements? |
A |
Section 7.1 |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
End entity certificates |
Does the X.509 v3 extensions conform these requirements? |
A |
Check the issued certificates |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
(41) The profile of the end entity certificates must also comply with the current IGTF and OGF certificate profile guidelines before being included in any distribution of certificates. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Sections in 3647 7.1 |
Does the X.509 v3 extensions conform these requirements? |
A |
Section 7.1 |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Certificate Profile |
Does the X.509 v3 extensions conform these requirements? |
A |
Section 7.1 |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
End entity certificates |
Check end entity certificates (details should be described in this document). |
A |
Check the issued certificates |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
(42) If a commonName component is used as part of the subject DN, it should contain an appropriate presentation of the actual name of the end-entity. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Sections in 3647 3.1.2, 3.1.3 |
Does the CPS describe need for names to be meaningful? |
A |
Section 3.1.2 |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
End entity certificates |
Check end entity certificates. |
A |
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
(43) Certificates (and private keys) managed in a software token should only be re-keyed, not renewed. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Sections in 3647 |
How are the re-key and re-new processes described? |
A |
Section 4.6, 4.7 |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Users manual |
How are the re-key and re-new processes described? |
A |
Section 4.7.3 |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
(44) Certificates associated with a private key restricted solely to hardware token may be renewed for a period of up to 5 years (for equivalent RSA key lengths of 2048 bits) or 3 years (for equivalent RSA key lengths of 1024 bits).
overlap not allowed - lifecycle management See Section 4.7.2
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Sections in 3647 3.3.1, 4.6, 4.7, 5.6 |
How is the re-new process described? |
X |
KISTI GRID CA does not support certificate renewal. See Section 4.6 |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Users manual |
How is the re-new process described? |
X |
KISTI GRID CA does not support certificate renewal. See Section 4.6 |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
(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. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Sections in 3647 3.3.1, 4.6, 4.7, 5.6 |
How are the re-key and re-new processes described? |
X |
overlap not allowed - lifecycle management See Section 4.7.2
after 3 year, the user required identity vetting procedure See Section 4.7.3 |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Users manual |
How are the re-key and re-new processes described? |
X |
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Evidence |
Method |
Score |
Memo |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
8. Records Archival |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
(46) Every CA must record and archive all requests for certificates, along with all the issued certificates, all the request for revocation, all the issued CRLs and the login/logout/reboot of the issuing machine. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Sections in 3647 5.5.1 |
Does the CA record and archive all requests for certificates, along with the all the issued certificates, all the request for revocation, all the issued CRLs and the login/logout/reboot of the issuing machine? |
A |
Section 5.4.1, 5.5.1 - Certification requests - Revocation requests - Issued certificates - Issued CRLs - shutdown/boot/reboot/login/logout/sudo logs of the CA machine and on-line request web server. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Inspection |
Archived logs |
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
(47) These records must be available to external auditors in the course of their work as auditor. Can be covered by auditing item (46). |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
(48) These records must be kept at least three years, where the identity validation records must be kept at least as long as there are valid certificates based on such a validation. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Sections in 3647 5.5.2 |
Is the archive kept at least three years? Is the identity validation record kept at least as long as there are valid certificates based on such a validation? |
A |
Section 5.5.2 The minimum retention period is 3 years. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Inspection |
Archived logs |
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Evidence |
Method |
Score |
Memo |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
9. Audits |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
(49) Each CA must accept being audited by other accredited CAs to verify its compliance with the rules and procedures specified in its CP/CPS document. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Sections in 3647 8 |
Does the CA accept external auditing? How is the procedure of auditing described in the CP/CPS? |
A |
Section 8.1 |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
(50) Every CA must perform operational audits of the CA/RA staff at least once per year. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Sections in 3647 5.4 |
How does the CA perform operational audits? |
|
See Section 5.4 |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Operational manual |
How does the CA perform operational audits? |
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Interview |
Ask CA operators the details of operational audit. |
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
(51) A list of CA and RA personnel should be maintained and verified at least once per year. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
A list of CA and RA personnel |
Is the list appropriately maintained? |
A |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Evidence |
Method |
Score |
Memo |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
10. Publication and Repository responsibilities |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
(52) The accredited authority must publish a X.509 signing certificate as a root of trust. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Sections in 3647 2.2, 4.4.2 |
Is the CA root certificate published? |
A |
Section 2.2 |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Web repository |
Is the CA root certificate published? |
A |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||
(53) Each authority must publish for their subscribers, relying parties and for the benefit of distribution by the PMA and the federation - a CA root certificate or set of CA root certificates up to a self-signed root; - a http or https URL of the PEM-formatted CA certificate; - a http URL of the PEM or DER formatted CRL; - a http | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||