Check List Results of Guidelines for auditing Grid CAs version 1.0-b3
Sangwan Kim (sangwan@kisti.re.kr)
May 28 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: X509v3 Basic Constraints: critical CA:FALSE X509v3 Key Usage: critical Digital Signature, Non Repudiation, Key Encipherment, Data Encipherment X509v3 Subject Key Identifier: 3C:A2:99:A4:33:92:1B:33:14:C0:04:5B:FF:F1:A7:AA:0F:43:A3:CB X509v3 Authority Key Identifier: keyid:2A:51:DC:55:6C:68:C9:FF:5B:22:FC:26:DD:AD:AF:F1:F4:50:36:19 DirName:/C=KR/O=KISTI/O=GRID/CN=KISTI Grid Certificate Authority serial:00 X509v3 CRL Distribution Points: URI:http://ca.gridcenter.or.kr/CRL/ X509v3 Issuer Alternative Name: email:ca@gridcenter.or.kr, URI:http://ca.gridcenter.or.kr/ 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. |
|||
Sections in 3647 3.3.1, 4.6, 4.7, 5.6 |
How does the CPS describes transition of the CA??s cryptographic data? |
X |
KISTI GRID CA does not support certificate renewal |
End entity certificates (if there was a transition of the CA??s cryptographic data) |
Is new EE cert. signed by a new cryptographic data? |
X |
KISTI GRID CA does not support certificate renewal |
(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? |
X |
KISTI GRID CA does not support certificate renewal |
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? |
X |
KISTI GRID CA does not support certificate renewal |
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 Certificates: X509v3 Basic Constraints: critical, CA:TRUE X509v3 Key Usage: critical, Certificate Sign (keyCertSign), CRL Sign (cRLSign) 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/
User Certificates: X509v3 Basic Constraints: critical, CA:FALSE X509v3 Key Usage: critical, Digital Signature, Non Repudiation, Key Encipherment, Data Encipherment, 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, Key Encipherment, Data Encipherment, Server Authentication, Client Authentication 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 |
|||
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. |
|||
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. |
|||
Sections in 3647 4.9.9 |
Is a new CRL issued at least 7 days before expiration? |
A |
Yes |
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 - 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 |
|||
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 |
|
X509v3 extensions: X509v3 Basic Constraints: critical CA:FALSE X509v3 Key Usage: critical Digital Signature, Non Repudiation, Key Encipherment, Data Encipherment X509v3 Extended Key Usage: TLS Web Client Authentication X509v3 Subject Key Identifier: 3C:A2:99:A4:33:92:1B:33:14:C0:04:5B:FF:F1:A7:AA:0F:43:A3:CB X509v3 Authority Key Identifier: keyid:2A:51:DC:55:6C:68:C9:FF:5B:22:FC:26:DD:AD:AF:F1:F4:50:36:19 DirName:/C=KR/O=KISTI/O=GRID/CN=KISTI Grid Certificate Authority serial:00
X509v3 CRL Distribution Points: URI:http://ca.gridcenter.or.kr/CRL/
X509v3 Issuer Alternative Name: email:ca@gridcenter.or.kr, URI:http://ca.gridcenter.or.kr/ X509v3 Certificate Policies: Policy: 1.3.6.1.4.1.14305.1.1.1.2.0
|
|||
(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 |
|
Certificate: Data: Version: 3 (0x2) Serial Number: 1 (0x1) Signature Algorithm: sha1WithRSAEncryption Issuer: C=KR, O=KISTI, O=GRID, CN=KISTI Grid Certificate Authority Validity Not Before: May 28 08:42:49 2007 GMT Not After : May 27 08:42:49 2008 GMT Subject: C=KR, O=KISTI, O=GRID, O=KISTI, CN=Sangwan Kim
|
|||
(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). |
|||
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. |
Users manual |
How is the re-new process described? |
X |
KISTI GRID CA does not support certificate renewal. |
(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 |
|
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? |
|
|
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 or https URL of the web page of the CA for general information; - the CP and/or CPS documents; - an official contact email address for inquiries and fault reporting - a physical or postal contact address |
|||
Sections in 3647 2.2, 4.4.2, 4.6.6, 4.7.6, 4.8.6 |
Is this information published? |
A |
|
Web repository |
Is this information published? |
A |
|
(54) The originating authority must grant to the PMA and the Federation - by virtue of its accreditation - the right of unlimited re-distribution of this information. |
|||
Re-distribution sites |
Is this information re-distributed? |
|
|
(55) The CA should provide a means to validate the integrity of its root of trust. |
|||
Web repository |
Does the CA provide a means to validate the integrity of its root of trust? |
|
|
(56) 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. |
|||
Trust anchor repository |
Does the CA provide their trust anchor? |
|
|
Evidence |
Method |
Score |
Memo |
11. Privacy and confidentiality |
|||
(57) Accredited CAs must define a privacy and data release policy compliant with the relevant national legislation. The CA is responsible for recording, at the time of validation, sufficient information regarding the subscribers to identify the subscriber. The CA is not required to release such information unless provided by a valid legal request according to national laws applicable to that CA. |
|||
Sections in 3647 9.3, 9.4 |
How are privacy and confidentiality described? |
A |
Section 9.4 |
12. Compromise and disaster recovery (58) The CA must have an adequate compromise and disaster recovery procedure, and we willing to discuss this procedure in the PMA. The procedure need not be disclosed in the policy and practice statements. |
|||
Sections in 3647 5.7, 5.7.1 |
How are procedures of compromise and disaster recovery described? |
A |
Section 5.7 Recover the system by using backup hardware, software, or data as quickly as possible. |
Interview |
Ask CA operators the detailed procedures of compromise and disaster recovery. |
|
|
Evidence |
Method |
Score |
Memo |
Registration Authority |
|||
1. Entity Identification |
|||
(1) A PKI CA must define the role of registration authority (RA), and these RAs are responsible for the identity vetting of all end entities. |
|||
Sections in 3647 4.1, 4.2, 4.6, 4.7 |
What is the role of RA? |
A |
Section 4.1 |
(2) In order for an RA to validate the identity of a person, the subject should contact the RA face-to-face and present photo-id and/or valid official documents showing that the subject is an acceptable end entity as defined in the CP/CPS document of the CA. |
|||
Sections in 3647 4.1, 4.2, 4.6, 4.7 |
How the RA implement identity vetting? |
A |
A user who requests a user certificate must have a face-to-face meeting with the RA and present a user application form to the RA |
Operational manual |
How the RA identify a person? |
A |
face-to-face meeting |
Interview |
Ask RA operators the detailed procedure of identity vetting. |
|
|
(3) In case of host or service certificate requests, the RA should validate the identity of the person in charge of the specific entities using a secure method. |
|||
Sections in 3647 4.1, 4.2, 4.6, 4.7 |
How the RA validate the identity of a person requesting a host/service certificate? |
A |
Yes, only permitted and authorized subscribers can request host/service cer |
Operational manual |
How the RA identify a person requesting a host/service certificate? |
|
|
Interview |
Ask RA operators the detailed procedure of identity vetting for host/service certificate requests. |
|
|
(4) The RA should ensure that the requestor is appropriately authorized by the owner of the FQDN or the responsible administrator of the machine to use the FQDN identifiers asserted in the certificate. |
|||
Sections in 3647 4.1, 4.2, 4.6, 4.7 |
How the RA ensure that the requestor is appropriately authorized by the owner of the FQDN? |
|
|
Operational manual |
How the RA ensure that the requestor is appropriately authorized by the owner of the FQDN? |
|
|
Interview |
Ask RA operators the detailed procedure of identity vetting. |
|
|
2. Name Uniqueness |
|||
(5) Any single subject distinguished name must be linked to one and only one entity. |
|||
Sections in 3647 3.1.5 |
How the CA guarantee the uniqueness of the subject name? |
A |
See Section 3.1.5 |
Interview |
How the CA guarantee the uniqueness of the subject name? What happens if there are two persons whose names are the same in the same organization? |
|
If subject distinguished names conflict, the CA arbitrate among the subscribers. The CA approves the DN of the request with a 'first-come, first-approve' policy. The later requester must change the DN of the request, but the DN should imply the subscriber's real name judged by common sense. |
(6) Over the entire lifetime of the CA it must not be linked to any other entity. |
|||
Sections in 3647 3.1.5 |
How the CA guarantee this requirement? |
|
|
Interview |
Ask the details of the method to guarantee this requirement. |
|
|
3. RA to CA communications |
|||
(7) The RA must communicate with the CA with secure methods that are clearly defined in the CP/CPS. (e.g. signed emails, voice conversations with a known person, or some other acceptable method) |
|||
Sections in 3647 4.1, 4.2 |
How the CA communicate with the RA? |
A |
Section 4.1 e-mail or telephone |
Operational manual |
How the CA communicate with the RA? |
|
|
Interview |
Ask the details of how the CA communicate with the RA (e.g. how the CSR is sent to the CA and the signed certificate is sent to the RA). |
|
|
(8) The CP/CPS should describe how the RA or CA is informed of changes that may affect the status of the certificate. |
|||
Sections in 3647 4.8, 4.9 |
How the CA or the RA is informed of changes? |
A |
Section 4.9 |
Interview |
Ask the details of how the CA or the RA is informed of change. |
|
|
4. Records and Archival |
|||
(9) The RA must record and archive all requests and confirmations. |
|||
Sections in 3647 5.5.1 |
Does the RA record and archive all requests and confirmations? |
A |
Section 5.5.1 |
Inspection |
Archives of all requests and confirmations. |
|
|
(10) The CA is responsible for maintaining an archive of these records in an auditable form. |
|||
Sections in 3647 5.5.1 |
Does the RA maintain the archive of these records in an auditable form? |
A |
Section 5.5.1 |
Inspection |
Archives of these records archival. |
|
|