581901 - Add HARICA root certificate

Status: RESOLVED FIXED

(CA Program :: CA Certificate Root Program, task)

Description

[Dimitris Zacharopoulos]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.2.6) Gecko/20100625 Firefox/3.6.6 (.NET CLR 3.5.30729)
Build Identifier: 


    * Product: mozilla.org
    * Component: CA Certificates
    * Version: Other
    * Severity: enhancement
    * Platform: All
    * OS: All
    * Summary: Add Hellenic Academic and Research Institutions Certification Authority (HARICA) root certificate
    * Description:

CA Details
----------

CA Company/Organization Name: Hellenic Academic and Research Institutions Certification Authority / Greek Universities Network
Website: http://www.harica.gr/

The Hellenic Academic and Research Institutions Certification Authority (HARICA) is a non profit activity operated by the Greek Universities Network (www.gunet.gr).
Our main web site is www.harica.gr and has been operating since 2006. All of our certificates have a clear mark indicating that "This certificate is subject to Greek
laws and our CPS. This Certificate must only be used for academic, research or educational purposes". This is also included in the comments and policy fields
of each certificate.

The main goal of HARICA is the deployment of an infrastructure for secure communication between the collaborating members of the Greek Academic and Research Institutions.

The HARICA PKI :

    * Implements a Public Key Hierarchy having as root authority the HARICA Root Certification Authority, which collaborates with the other parties' Certification
      Authorities in Greece and abroad aiming to widening the network of trust.
    * Issues -on behalf of its members- digital certificates for servers, in order to secure the data exchanged with the network users.
    * Issues -on behalf of its members- digital certificates for users, which can be used to prove their identity when accessing network services, to secure e-mail communication and to sign documents/code/etc.

Currently the subordinate CAs are the following:
    * HaricaAdministrationCAR2
    * HaricaEKTCAR2
    * HaricaTeiCreteCAR2
    * HaricaTeiEpirusCAR2
    * HaricaTeiKalamataCAR2
    * HaricaTeiLamiaCAR2
    * HaricaTeiLarissaCAR2
    * HaricaTeiMessolonghiCAR2
    * HaricaTeiSerresCAR2
    * HaricaUcgCAR2
    * HaricaUocCAR2
    * HaricaUopCAR2
    * HaricaUthCAR2
    * AuthCentralCAR2
        * AuthNocCAR3
        * AuthUsersCAR3
        * AuthServersCAR3

Currently, we haven't audited our Certification Authority. However, we have an offer from a Greek Auditors Company which includes 1 CISSP and 2 CISA certified auditors.
Some of their previous work includes auditing other Government sectors and major IT companies. We are planning to do an audit as soon as possible.

Certificate Details
-------------------

Certificate Name: Hellenic Academic and Research Institutions RootCA 2006

The root certificate authority is used to sign only subordinate certification authority certificates. No end user or server certificates will be issued by this CA.

Currently there are 13 subordinate CAs operated internally by HARICA Administration:
    * HaricaAdministrationCAR2
    * HaricaEKTCAR2
    * HaricaTeiCreteCAR2
    * HaricaTeiEpirusCAR2
    * HaricaTeiKalamataCAR2
    * HaricaTeiLamiaCAR2
    * HaricaTeiLarissaCAR2
    * HaricaTeiMessolonghiCAR2
    * HaricaTeiSerresCAR2
    * HaricaUcgCAR2
    * HaricaUocCAR2
    * HaricaUopCAR2
    * HaricaUthCAR2

All these CAs belong to different Academic or Research Institutions and are used to issue both user and server certificates.

The following CAs are operated by Aristotle University of Thessaloniki Network Operations Center:
    * AuthCentralCAR2
        * AuthNocCAR3
        * AuthUsersCAR3
        * AuthServersCAR3

The AuthCentralCAR2 CA is used only to issue subordinate CAs. The AuthNocCAR3 CA is used to issue user and server certificates
for the needs of the Network Operations Center of the University. AuthUsersCAR3 and AuthServersCAR3
are used to issue user and server certificates respectively for the rest of the University.

Attached you can find a PNG image of the HARICA PKI hierarchy.

Certificate HTTP download URL (on CA website):
    http://www.harica.gr/certs/HaricaRootCA2006.pem (PEM format)
    http://www.harica.gr/certs/HaricaRootCA2006.der (DER format)
Version: Version 3
SHA1 Fingerprint: EF:BE:64:58:33:41:8D:95:82:21:4F:35:00:C2:3B:A6:62:C6:25:77
Public key length (for RSA, modulus length) in bits: 2048 bit
Valid From (YYYY-MM-DD): 2006-07-25
Valid To (YYYY-MM-DD): 2026-07-20
CRL HTTP URL: http://crlv1.harica.gr/HaricaRootCA2006/crlv1.der.crl
CRL issuing frequency for end-entity certificates: 1 month
OCSP URL: http://ocsp.harica.gr
Class (domain-validated, identity/organisationally-validated or EV): identity/organisationally-validated
EV policy OID(s) (if applicable): not applicable
Certificate Policy URL: http://www.harica.gr/documents/CPS.php (Greek), http://www.harica.gr/documents/CPS-en.php (English)
CPS URL:  http://www.harica.gr/documents/CPS.php (Greek), http://www.harica.gr/documents/CPS-en.php (English)

List one or more Trust Bits to enable, choices are Websites (SSL/TLS), Email (S/MIME), and/or Code (code/document signing): Websites, Email and Code
URL of website whose SSL certificate chains to this root (if applying for SSL): https://www.harica.gr/

CA Contact Information: Dimitris Zacharopoulos (jimmy at ccf.auth.gr), Panagiotis Tzounakis (pj at ccf.auth.gr), Fotis Loukos (fotisl at ccf.auth.gr)
CA Email Alias: [e-mail]
CA Phone Number: [phone], [phone]
Title/Department: AUTH Network Operations Center, Harica Administration

Reproducible: Always

Comment 1

[Dimitris Zacharopoulos]

Attachment: HARICA PKI Hierarchy

Comment 2

[Kathleen Wilson]

Accepting this bug.  I will start the Information Gathering and Verification
phase as per https://wiki.mozilla.org/CA:How_to_apply.

Comment 3

[Kathleen Wilson]

Attachment: Initial Information Gathering Document

The attached document summarizes the information that has been gathered and
verified.

The items highlighted in yellow indicate where further information or
clarification is needed. Please review the full document for accuracy and
completeness.

Comment 4

[Dimitris Zacharopoulos]

Attachment: Reply to initial Information Gathering

Our next generation Root CA can be downloaded in the following versions:
http://www.harica.gr/certs/HaricaRootCA2010.pem
http://www.harica.gr/certs/HaricaRootCA2010.der
http://www.harica.gr/certs/HaricaRootCA2010.txt

It will eventually have the same hierarchy as the current MD5 root, and similar CRL and OCSP support.

Our next version of CP/CPS will incorporate the changes mentioned in this document.

Comment 5

[Dimitris Zacharopoulos]

After reviewing the list of Potentially Problematic Practices  (http://wiki.mozilla.org/CA:Problematic_Practices), here is the completed list:

- Long-lived DV certificates

End certificates (for hosts and users) have a 2-year maximum validity period. Furthermore, since there is a limit on the allowed domains (only academic and research institutions in Greece can participate in HARICA), it is rather impossible for the domain ownership to change.


- Wildcard DV SSL certificates

HARICA doesn't allow the creation of wildcard certificates.


- Email Address Prefixes for DV Certs

In order to request an SSL certificate the user must own an S/MIME one in order to be authenticated. The e-mail address prefix is not used.


- Delegation of Domain / Email validation to third parties

The main RA and CA is run by the HARICA Administration Team. In case an institution -within the HARICA constituency- wants to run its own RA, it must provide an official audit according to the mozilla CA requirements.


- Issuing end entity certificates directly from roots

HARICA ROOT CA is used only to issue SubCA certificates.


- Allowing external entities to operate subordinate CAs

As in the case of an external RA, an institution -within the HARICA constituency- that wants to run its own CA must provide an official audit according to the mozilla CA requirements.


- Distributing generated private keys in PKCS#12 files

The CP/CPS discoureges key-pair generation on behalf of users and strongly advises only end user to be able to generate private keys. Section 6.1.2 of our CP/CPS mentions that there might be cases for batch key generation under a very strict procedure.


- Certificates referencing hostnames or private IP addresses

Host certificates are only allowed to have FQDNs. Hostnames or IP addresses are not allowed. This is described in section 3.1.1.2. Our next CP/CPS revision will specifically mention that hostsnames or private IP Addresses are not allowed.


- Issuing SSL Certificates for Internal Domains

Use of internal domains is not allowed. Only internet domains belonging to HARICA academic institutions are allowed.


- OCSP Responses signed by a certificate under a different root

The OCSP responses are signed by the certificate of the Harica Administration SubCA, which is in turn signed by the Harica Root CA.


- CRL with critical CIDP Extension

CRLs don't have a critical CIDP extension.


- Generic names for CAs

The names of the CAs are very specific. For example: 'Hellenic Academic and Research Institutions AdminCA R2', 'University of Central Greece CA R2' etc.


- Lack of Communication With End Users

Harica Administration uses e-mail and telephone support for end-users. Telephone support works 8 hours/day, working days. Furthermore, specific institutions, such as the Aristotle University of Thessaloniki, provide helpdesk visiting facilities for end users and on-site support at faculty members offices/computers.

Comment 6

[Kathleen Wilson]

Attachment: Updated Information Gathering Document

Thank you for the information.

Please post a comment in this bug when the CP/CPS has been updated.

Comment 7

[Dimitris Zacharopoulos]

Attachment: Reply to Updated Information Gathering Document

Comment 8

[Kathleen Wilson]

Attachment: Completed Information Gathering Document

Comment 9

[Kathleen Wilson]

This request has been added to the queue for public discussion:
https://wiki.mozilla.org/CA:Schedule#Queue_for_Public_Discussion

Now that you have a request in the Queue for Public Discussion, you are
directly impacted by the time it takes to work through the queue. The goal is
to have each discussion take about one to two weeks. However, that time varies
dramatically depending on the number of reviewers contributing to the
discussion, and the types of concerns that are raised. If no one reviews and
contributes to a discussion, then a request may be in the discussion for
several weeks. When there are not enough people contributing to the discussions ahead of yours, then your request will sit in the queue longer.

How can you help reduce the time that your request sits in the queue?

You can help by reviewing and providing your feedback in the public discussions
of root inclusion requests, or by asking a knowledgeable colleague to do so.

Participating in other discussions is a great way to learn the expectations and be prepared for the discussion of your request.

Please see: https://wiki.mozilla.org/CA:How_to_apply#Public_discussion

Comment 10

[Dimitris Zacharopoulos]

We have completed our Audit according to the ETSI TS 101 456 standard. It is available at http://www.harica.gr/documents/Harica.Audit-report.2011.03.18.Rev1.2.ENG.pdf or at an independent location (http://www.trust-it.gr/userfiles/Harica.2011.03.18.Rev1.2.ENG.pdf). Our CP/CPS has also been modified and is currently in version 2.2 (http://www.harica.gr/documents/CPS-EN.pdf).

Comment 11

[Kathleen Wilson]

Thanks for the update.

Has CRL and OCSP support been implemented for the new root?

Comment 12

[Dimitris Zacharopoulos]

Thank you for the fast processing.

The currently used URLs (ocsp.harica.gr, crlv1.harica.gr) are serving the currently used MD5 root. We plan to enable www2.harica.gr under the new root and its new subCA for testing. It will point to a new CRL link (the URL crlv1.harica.gr will remain the same). The OCSP is a bit more tricky if we want the same URL to serve under two different ROOT CAs. Switching the OCSP to the new root only, is trivial. Is it necessary to implement ocsp support for the new root before the public discussion?

We also noticed that the audit statements at http://www.mozilla.org/projects/security/certs/pending/#HARICA (although marked as completed) are unlinked and still TBD.

Best regards.

Comment 13

[Dimitris Zacharopoulos]

We have enabled OCSP support for https://www2.harica.gr under the new SHA1 ROOT CA.

Best regards,
Dimitris Zacharopoulos.

Comment 14

[Kathleen Wilson]

Attachment: Completed Information Gathering Document

Comment 15

[Dimitris Zacharopoulos]

There are some changes to the audit report that reflect minor changes of our CP/CPS (mostly changed couple of "should" to "must" in the translated document). 

The latest audit report is available at the following URLs:
- http://www.harica.gr/documents/HARICA.Audit.Report.EN.pdf 
- http://www.trust-it.gr/userfiles/Harica.2011.03.18.Rev1.2.ENG.pdf

Our CP/CPS has also been modified and is currently in version 2.3 (http://www.harica.gr/documents/CPS-EN.pdf).

This comment obsoletes comment #10.

Comment 16

[Kathleen Wilson]

Attachment: Completed Information Gathering Document

Comment 17

[Dimitris Zacharopoulos]

We would like to inform you that the sub CAs operated for Aristotle University of Thessaloniki (http://www.pki.auth.gr), have completed a separate audit from an independent auditor according to the ETSI TS 101 456 standard. 

The report is available at http://www.pki.auth.gr/documents/AUTH.Audit.Report.EN.pdf and at an independent location (http://www.trust-it.gr/userfiles/AUTH.2011.03.18.Rev1.7.English.pdf). 

AUTH's CP/CPS has also been modified and is currently in version 3.1 (http://www.pki.auth.gr/documents/CPS.pdf.en).

Comment 18

[Kathleen Wilson]

Attachment: Completed Information Gathering Document

Comment 19

[Kathleen Wilson]

This request is next in line for public discussion:
https://wiki.mozilla.org/CA:Schedule#Queue_for_Public_Discussion

I will post a comment in this bug when I start the discussion -- hopefully the week of September 6.

Comment 20

[Dimitris Zacharopoulos]

We recently discovered that our proposed ROOT CA had a problem with the AuthorityKeyIdentifier extension and the certificate policy OID which is now fixed.

Our next generation Root CA can be downloaded in the following versions:
http://www.harica.gr/certs/HaricaRootCA2011.pem
http://www.harica.gr/certs/HaricaRootCA2011.der
http://www.harica.gr/certs/HaricaRootCA2011.txt

Fingerprints: 
SHA1 is B2:49:E1:BE:68:B9:00:44:22:A5:4D:EA:A3:82:A9:19:BC:0A:5B:47 and
MD5 is F6:DB:22:B0:75:19:53:F6:C7:C8:34:F1:B6:39:3B:1D.

It will eventually have the same hierarchy as the current MD5 root, and similar CRL and OCSP support.

The test certificate under https://www2.harica.gr is also replaced by the new hierarchy and is OCSP ready.

Finally, we must inform you that the transition from the "Hellenic Academic and Research Institutions RootCA 2010" root cert to the new cert, has no impact on existing certificates (since no certificates were issued to end users/servers), produces no updates on our CP/CPS and has no effect on our recent Audit.

Comment 21

[Kathleen Wilson]

Attachment: Completed Information Gathering Document

Comment 22

[Dimitris Zacharopoulos]

We have included answers to the latest communication to the CAs with root certificates in NSS. Please read below.

==
Dear Certification Authority,
[...]

Please confirm completion of the following actions or state when these actions will be completed, and provide the requested information no later than September 16, 2011:

1) Audit your PKI and review your systems to check for intrusion or compromise. This includes all third party CAs and RAs.

** HARICA has recently (Apr 2011) passed a security audit at the same time as the ETSI TS 101 456 audit.

2) Send a complete list of CA certificates from other roots in our program that your roots (including third party CAs and RAs) have cross-signed. A listing of all root certificates in Mozilla's products is here: http://www.mozilla.org/projects/security/certs/included

** HARICA does not allow cross-signed certificates

3) Confirm that multi-factor authentication is required for all accounts capable of directly causing certificate issuance.

** We confirm multi-factor authentication for server certificates, and multi-factor authentication to access the RA and CA engines.

4) Confirm that you have automatic blocks in place for high-profile domain names (including those targeted in the DigiNotar and Comodo attacks this year). Please further confirm your process for manually verifying such requests, when blocked.

** HARICA has implemented technical restrictions (at the RA and CA level) allowing only specific domains affiliated with our constituency to be included in certificates. Each server certificate is manually verified.

5) For each external third party (CAs and RAs) that issues certificates or can directly cause the issuance of certificates within the hierarchy of the root certificate(s) that you have included in Mozilla products, either:

a) Implement technical controls to restrict issuance to a specific set of domain names which you have confirmed that the third party has registered or has been authorized to act for (e.g. RFC5280 x509 dNSName name constraints, marked critical)

** HARICA has implemented technical controls to restrict issuance to a specific set of domain names which have been confirmed. These controls check the dNSName, E-mail and the CN of the certificate requests.

OR

b) Send a complete list of all third parties along with links to each of their corresponding Certificate Policy and/or Certification Practice Statement and provide public attestation of their conformance to the stated verification requirements and other operational criteria by a competent independent party or parties with access to details of the subordinate CA's internal operations.

Each action requested above applies both to your root and to these third parties.

Participation in Mozilla's root program is at our sole discretion, and we will take whatever steps are necessary to keep our users safe. Nevertheless, we believe that the best approach to safeguard that security is to work with CAs as partners, to foster open and frank communication, and to be diligent in looking for ways to improve. Thank you for your participation in this pursuit.

Regards,
Kathleen Wilson
Module Owner of Mozilla's CA Certificates Module

Comment 23

[Kathleen Wilson]

Attachment: Completed Information Gathering Document

Comment 24

[Kathleen Wilson]

(In reply to Kathleen Wilson from comment #23)
> Created attachment 561318 [details]
> Completed Information Gathering Document


Dimitris, Please confirm that the information in this document is current and correct. If there are any errors, or anything is out of date, please post correction.

Comment 25

[Kathleen Wilson]

Also, when I try to browse to https://www2.harica.gr I get 
Error code: sec_error_ocsp_try_server_later

Comment 26

[Dimitris Zacharopoulos]

We needed to reload the OCSP daemon after an upgrade which took place last week. Our production site https://www.harica.gr was ok. https://www2.harica.gr is now ok as well. 

We also added extra monitoring code to warn us in case the service fails for https://www2.harica.gr

Thank you for the notification.

I also confirm that the information in the Gathering Document is current and correct. Just one small correction for the CP/CPS URL for AUTH-PKI. The direct  link is http://www.pki.auth.gr/documents/CPS-EN.pdf. The current link automatically detects the browser language and presents the greek/english version accordingly.

Best regards,
Dimitris Zacharopoulos.

Comment 27

[Kathleen Wilson]

Attachment: Completed Information Gathering Document

Comment 28

[Kathleen Wilson]

I am now opening the first public discussion period for this request from HARICA to add the “Hellenic Academic and Research Institutions RootCA 2011” root certificate, and enable all three trust bits. 

For a description of the public discussion phase, see https://wiki.mozilla.org/CA:How_to_apply#Public_discussion

Public discussion will be in the mozilla.dev.security.policy newsgroup and the corresponding [e-mail] mailing list.

http://www.mozilla.org/community/developer-forums.html
https://lists.mozilla.org/listinfo/dev-security-policy
news://news.mozilla.org/mozilla.dev.security.policy

The discussion thread is called “HARICA Root Inclusion Request”

Please actively review, respond, and contribute to the discussion.

A representative of HARICA must promptly respond directly in the discussion thread to all questions that are posted.

Comment 29

[Dimitris Zacharopoulos]

Attachment: Representative list of elegible domain names for HARICA

This is a representative list of eligible domain names of Greek Academic and Research institutions under HARICA. This list is not comprehensive because each of these institutions may have other affiliated sub-divisions under the same legal entity with different domain names.

Comment 30

[Dimitris Zacharopoulos]

HARICA has now implemented the name constraints extension as discussed
in the m.d.s mailing list.

The next generation Root CA can be downloaded in the following versions:
http://www.harica.gr/certs/HaricaRootCA2011.pem
http://www.harica.gr/certs/HaricaRootCA2011.der
http://www.harica.gr/certs/HaricaRootCA2011.txt

Fingerprints:
SHA1 is 41:CB:5B:99:D6:EC:E6:8C:29:70:95:EB:5D:9C:89:EC:6C:80:93:32 and
MD5 is 14:99:76:B4:34:BC:58:D7:34:02:8F:B6:AD:2F:E6:5F.

It will eventually have the same hierarchy as the current MD5 root, and
similar CRL and OCSP support.

The test certificate under https://www2.harica.gr is also replaced by
the new hierarchy with the name constraints and is OCSP ready.

The updated CP/CPS is available at
https://www.harica.gr/documents/CPS-EN.pdf and the name constraints
section is 7.1.5.

Comment 31

[Dimitris Zacharopoulos]

This post obsoletes Comment #30.

HARICA has now implemented the name constraints extension without the critical bit as discussed in the m.d.s mailing list.

The next generation Root CA can be downloaded in the following versions:
http://www.harica.gr/certs/HaricaRootCA2011.pem
http://www.harica.gr/certs/HaricaRootCA2011.der
http://www.harica.gr/certs/HaricaRootCA2011.txt

Fingerprints:
SHA1 is fe:45:65:9b:79:03:5b:98:a1:61:b5:51:2e:ac:da:58:09:48:22:4d and
MD5 is 73:9f:4c:4b:73:5b:79:e9:fa:ba:1c:ef:6e:cb:d5:c9.

It will eventually have the same hierarchy as the current MD5 root, and
similar CRL and OCSP support.

The test certificate under https://www2.harica.gr is also replaced by
the new hierarchy with the name constraints and is OCSP ready.

The updated CP/CPS (version 2.5) is available at
http://www.harica.gr/documents/CPS-EN.pdf and the name constraints
section is 7.1.5.

Comment 32

[Kathleen Wilson]

Attachment: Completed Information Gathering Document

Comment 33

[Kathleen Wilson]

The public comment period for this request is now over. 

This request has been evaluated as per Mozilla’s CA Certificate Policy at

 http://www.mozilla.org/projects/security/certs/policy/

Here follows a summary of the assessment. If anyone sees any factual errors, please point them out.

To summarize, this assessment is for the request to add the “Hellenic Academic and Research Institutions RootCA 2011” root certificate and turn on all three trust bits.

Section 4 [Technical]. I am not aware of instances where HARICA has knowingly issued certificates for fraudulent use. If anyone knows of any such issues or instances, please note them in this bug report.

Section 6 [Relevancy and Policy]. HARICA appears to provide a service relevant to Mozilla users:  It is a non-profit organization with the goal of deploying an infrastructure for secure communication between the collaborating members of the Greek Academic and Research Institutions.

Policies are documented in the documents published on their website and listed in the entry on the pending applications list; the main document of interest is the CPS. The documents are provided in English.

Document Repository: http://www.harica.gr/procedures.php
CPS: http://www.harica.gr/documents/CPS-EN.pdf

Section 7 [Validation]. HARICA appears to meet the minimum requirements for subscriber verification, as follows:

* SSL: According to CPA section 7.1.5, name constraints are required for all subCAs, so that each subCA will be constrained to the Institution’s domain name that the subCA signs for. According to CPS section 3.2.3.2, issuance of an SSL/TLS certificate is only allowed for domains belonging to each institution. Additionally, verification e-mail is sent to an institution's network operations center designated administrator who verifies the validity of the FQDN of the certificate request and checks that the person who applied for the certificate is the rightful owner of the FQDN according to the institution's database of users and servers.

* Email: According to CPS section 3.2.3.1, HARICA uses two methods for e-mail ownership and control verification. In the first method, a verification e-mail is sent to the user with a link to a unique web page. After following this link, an e-mail is sent to the institution's network operation center mail administrator that requires an approval based on the full name entered by the user and the user's email. This approval requires the identification of the user with his/her physical presence and an acceptable official document. The second method uses an LDAP server. The user enters the personal e-mail address at the initial certificate request form and the corresponding password. This information is verified against the institution's LDAP server. If the verification is successful, the RA queries the real name of the user and creates the certificate request. In order for a user to be listed in the Institutional Directory server, the institution must have verified the user with his/her physical presence and an acceptable official photo-id document.

* Code: According to CPS sections 3.2.2 and 3.2.3 the identity and authority of the certificate subscriber are checked by performing physical identity verification, ensuring the subscriber is registered in the official directory services of the Institution, and confirming the request with the administration of the Institution.

Section 15 [Certificate Hierarchy]. This new root will eventually have the same intermediate CAs as HARICA’s MD5 root; the CA hierarchy diagram is here: https://bugzilla.mozilla.org/attachment.cgi?id=460450
* The hierarchy that will be transitioned to this root currently consists of several internally-operated subordinate CAs and one externally-operated subordinate CA. Each subordinate CA is used for a different academic or research institution.
** HARICA has implemented technical restrictions (at the RA and CA level) allowing only specific domains affiliated with their constituency to be included in certificates.
** HARICA provided the CPS and audit statement for the externally-operated subCA.

* Both CRL and OCSP are provided under this root
** CPS section 4.9.7: The CRL must be updated and published at least every five (5) days.

Section 8-10 [Audit]. Annual audits are performed according to the ETSI TS 101 456 criteria. The most recent audit was performed by Deventum (http://deventum.com), and posted on the Trust-IT website: 
http://www.trust-it.gr/userfiles/Harica.2011.03.18.Rev1.2.ENG.pdf 
** Note that this new root was created after the last audit, and will need to be included in the next audit. 
** A network security audit was performed at the same time as the ETSI audit.

Based on this assessment I intend to approve this request to add the “Hellenic Academic and Research Institutions RootCA 2011” root certificate and turn on all three trust bits.

Comment 34

[Kathleen Wilson]

To the representatives of HARICA: Thank you for your cooperation and your patience.

To all others who have commented on this bug or participated in the public discussion: Thank you for volunteering your time to assist in reviewing this CA request.

As per the summary in Comment #33, and on behalf of Mozilla I approve this request from HARICA to include the following root certificate in Mozilla products:

* Hellenic Academic and Research Institutions RootCA 2011 (websites, email, code)

I will file the NSS bug for the actual changes.

Comment 35

[Kathleen Wilson]

I have filed bug #711594 for the actual changes in NSS.

Comment 36

[Kathleen Wilson]

The "Hellenic Academic and Research Institutions RootCA 2011" root certificate is a Builtin Object Token in FF 11.

Comment 37

[Kathleen Wilson]

http://www.harica.gr/documents/HARICA-2012.04.20.Audit2012-ENG.pdf
http://www.harica.gr/documents/CPS-EN-2.6.pdf

Comment 38

[Kathleen Wilson]

The recent audit statement is also available from the Trust-IT website:
http://www.trust-it.gr/UserFiles/HARICA-2012.04.20.Audit.pdf