1201423 - Add 2 HARICA Rollover Root CA Certificates

Status: RESOLVED FIXED

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

Description

[Dimitris Zacharopoulos]

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

CA Name: Hellenic Academic and Research Institutions Certification Authority / Greek Universities Network
Website: https://www.harica.gr/
Organization: Non profit activity operated by the Greek Universities Network (www.gunet.gr).

Audit Type (WebTrust, ETSI etc.): ETSI TS 101 456, ETSI TS 102 042, CA/B Forum Baseline Requirements
Auditor: QMSCERT
Auditor Website: http://www.qmscert.com
Audit Document URL(s): https://www.harica.gr/documents/HARICA-ETSI_CERTIFICATE_AUTH_W_ANNEX.pdf

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

Certificate Name: Hellenic Academic and Research Institutions RootCA 2015
This SHA256 "Hellenic Academic and Research Institutions RootCA 2015" root certificate will eventually replace the SHA-1 "Hellenic Academic and Research Institutions RootCA 2011" root certificate that was included via Bugzilla Bug #581901.

Certificate download URL (on CA website): http://www.harica.gr/certs/HaricaRootCA2015.pem
Version: 3
SHA1 Fingerprint: 01:0C:06:95:A6:98:19:14:FF:BF:5F:C6:B0:B6:95:EA:29:E9:12:A6
Public key length (for RSA, modulus length) in bits: 4096
Valid From (YYYY-MM-DD): 2015-07-07
Valid To (YYYY-MM-DD): 2040-06-30

CRL HTTP URL: http://crlv1.harica.gr/HaricaRootCA2015/crlv1.der.crl
CRL issuing frequency for subordinate end-entity certificates: 1 day
CRL issuing frequency for subordinate CA certificates: 12 months (within 24
hours after revoking a subCA certificate)
OCSP URL: http://ocsp.harica.gr

Class (domain-validated, identity/organizationally-validated or EV): DV, OV
Certificate Policy URL: http://www.harica.gr/documents/CPS-EN.pdf
CPS URL: http://www.harica.gr/documents/CPS-EN.pdf
Requested Trust Indicators (email and/or SSL and/or code signing): Email, SSL, Code Signing
URL of example website using certificate subordinate to this root (if applying for SSL): https://www2.harica.gr


Certificate Name: Hellenic Academic and Research Institutions ECC RootCA 2015
This "Hellenic Academic and Research Institutions ECC RootCA 2015" root certificate is the ECC version of the "Hellenic Academic and Research Institutions RootCA 2015".

Certificate download URL (on CA website): http://www.harica.gr/certs/HaricaECCRootCA2015.pem
Version: 3
SHA1 Fingerprint: 9F:F1:71:8D:92:D5:9A:F3:7D:74:97:B4:BC:6F:84:68:0B:BA:B6:66
Public key length (for RSA, modulus length) in bits: 384
Valid From (YYYY-MM-DD): 2015-07-07
Valid To (YYYY-MM-DD): 2040-06-30

CRL HTTP URL: http://crlv1.harica.gr/HaricaECCRootCA2015/crlv1.der.crl
CRL issuing frequency for subordinate end-entity certificates: 1 day
CRL issuing frequency for subordinate CA certificates: 12 months (within 24
hours after revoking a subCA certificate)
OCSP URL: http://ocsp.harica.gr

Class (domain-validated, identity/organizationally-validated or EV): DV, OV
Certificate Policy URL: http://www.harica.gr/documents/CPS-EN.pdf
CPS URL: http://www.harica.gr/documents/CPS-EN.pdf
Requested Trust Indicators (email and/or SSL and/or code signing): Email, SSL, Code Signing
URL of example website using certificate subordinate to this root (if applying for SSL): https://www3.harica.gr

Comment 1

[Dimitris Zacharopoulos]

Attachment: HARICA2015 RSA 4096 SHA2 Certification Authority root certificate

HARICA2015 RSA 4096 SHA2 Certification Authority root certificate

Comment 2

[Dimitris Zacharopoulos]

Attachment: HARICA2015 ECDSA P384 SHA2 Certification Authority root certificate

Comment 3

[Dimitris Zacharopoulos]

Attachment: HARICA CP-CPS-ENG-3.2.pdf

We are drafting a new CP/CPS which is not published yet. It will incorporate changes that will include recommendations from the public discussion.

Comment 4

[Kathleen Wilson]

Attachment: 1201423-CAInformation.pdf

I have entered the information for this request into Salesforce.

Please review the attached document to make sure it is accurate and complete, and comment in this bug to provide corrections and the additional requested information.

Comment 5

[Dimitris Zacharopoulos]

Concerning "Mozilla Applied Constraints" field: HARICA already constrains and will constrain subCAs to certain domains so there is no reason for this to be done by Mozilla.

Regarding the OCSP response for www3.harica.gr, we believe that our OCSP server is working correctly. We have tested it using the openssl client from the command line and we have successfully verified the response: 

<code>
$ openssl ocsp -url http://ocsp.harica.gr -CAfile HaricaECCChain.pem -issuer HaricaECCAdministrationCAR1.pem -cert www3.harica.gr.pem -header Host ocsp.harica.gr 

cert1.pem: good
        This Update: Sep 16 10:07:59 2015 GMT
        Next Update: Sep 18 10:07:59 2015 GMT
</code>

As you can see, both "This Update" and "Next Update" fields are correct. We suspect that https://certificate.revocationcheck.com cannot verify responses signed using the ecdsa algorithm, since it also fails checking the certificate for usertrustecccertificationauthority-ev.comodoca.com, which is issued from the COMODO ECC CA, a CA already installed in the Mozilla Certificate Store.

Comment 6

[Kathleen Wilson]

Attachment: 1201423-CompleteCAInformation.pdf

Comment 7

[Kathleen Wilson]

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

Comment 8

[Kathleen Wilson]

Here's the response regarding https://certificate.revocationcheck.com/www3.harica.gr
--
The problem was that the server is sending the certificates in the wrong order (configuration issue on www3.harica.gr). I added some functionality that will automatically correct this configuration error or return an error when it's unable to.
Certificate chain (1<>2)
 0 s:/C=GR/O=Greek Academic Network/CN=PKI of Greek Academic Network
   i:/C=GR/O=Hellenic Academic and Research Institutions Cert. Authority/CN=Greek Academic Network CA R1
 1 s:/C=GR/O=Hellenic Academic and Research Institutions Cert. Authority/CN=Hellenic Academic and Research Institutions RootCA 2011
   i:/C=GR/O=Hellenic Academic and Research Institutions Cert. Authority/CN=Hellenic Academic and Research Institutions RootCA 2011
 2 s:/C=GR/O=Hellenic Academic and Research Institutions Cert. Authority/CN=Greek Academic Network CA R1
   i:/C=GR/O=Hellenic Academic and Research Institutions Cert. Authority/CN=Hellenic Academic and Research Institutions RootCA 2011
--

Comment 9

[Dimitris Zacharopoulos]

www3.harica.gr is served through SNI.

The information you posted on the previous comment is probably from a client that doesn't seem to support SNI and this is why it tries to verify a certificate through a subCA under HARICA RootCA 2011 instead of the actual www3.harica.gr under the new Root.

As far as the order of certificates, we have corrected the ocsp responder to send the correct certificate order. https://certificate.revocationcheck.com/www3.harica.gr (which correctly supports SNI) passes the tests and displays the correct responses.

Comment 10

[Dimitris Zacharopoulos]

Correction on:

> As far as the order of certificates, we have corrected the ocsp responder to
> send the correct certificate order.

We changed the order of certificates on our *web server*, not the ocsp responder.

Comment 11

[Kathleen Wilson]

Attachment: 1201423-CompleteCAInformation.pdf

Updated to reflect that Mozilla is no longer enabling the Code Signing trust bit for root certs, because we are planning to remove that trust bit from Mozilla policy.
Reference: https://wiki.mozilla.org/CA:CertificatePolicyV2.3#Changes_Made_to_DRAFT_Version_2.3

Comment 12

[Kathleen Wilson]

I am now opening the public discussion period for this request from HARICA to include the “Hellenic Academic and Research Institutions RootCA 2015” and “Hellenic Academic and Research Institutions ECC RootCA 2015” root certificates, and enable the Websites and Email trust bits for both roots.

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 forum.
https://www.mozilla.org/en-US/about/forums/#dev-security-policy

The discussion thread is called "HARICA Root Renewal 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 13

[Dimitris Zacharopoulos]

Attachment: HARICA CP-CPS-ENG-3.3 [e-mail]

This is the latest DRAFT version of HARICA CP/CPS version 3.3 which is subject to changes.

Comment 14

[Kathleen Wilson]

We recently added two tests that CAs must perform and resolve errors for...

Test 1) Browse to https://crt.sh/ and enter the SHA-1 Fingerprint for the root certificate. Then click on the 'Search' button. Then click on the 'Run cablint' link. All errors must be resolved/fixed. Warnings should also be either resolved or explained.

Output for Test1:
no errors (certificate not found via CT)

Test 2) Browse to http://cert-checker.allizom.org:3001/ and enter the test website and click on the 'Browse' button to provide the PEM file for the root certificate. Then click on 'run certlint'. All errors must be resolved/fixed. Warnings should also be either resolved or explained. 

Output for Test 2:
Using certificate chain from 'https://www2.harica.gr/'

Using certificate from local file 'HellenicAcademicandResearchInstitutionsRootCA2015.cert'

    /C=GR/L=Athens/O=Hellenic Academic and Research Institutions Cert. Authority/CN=www2.harica.gr
        Warning
            Extension should be critical for KeyUsage
            Certificate Policies should not contain notice references
        Informational
            TLS Server certificate identified

    /C=GR/O=Hellenic Academic and Research Institutions Cert. Authority/CN=Hellenic Academic and Research Institutions AdminCA R5
        Warning
            Certificate Policies should not contain notice references
            CA certificates should include Digital Signature to allow signing OCSP responses
        Error
            RFC822Name without @
            RFC822Name without @
~~

Please add a comment in this bug when the errors have been resolved.

Comment 15

[Kathleen Wilson]

(In reply to Kathleen Wilson from comment #14)
> Test 2) Browse to http://cert-checker.allizom.org:3001/ and enter the test

Test 2 moved to https://cert-checker.allizom.org/

Comment 16

[Fotis Loukos]

We have run the certlint tests against the certificates of both https://www2.harica.gr and https://www3.harica.gr. The results with inline responses are the following:

> Using certificate chain from 'https://www3.harica.gr'
> 
> Using certificate from local file 'HaricaECCRootCA2015.cer'
> 
>   * /C=GR/L=Athens/O=Hellenic Academic and Research Institutions Cert. Authority/CN=www3.harica.gr
>       o Warning
>           + Extension should be critical for KeyUsage

According to CA/B Forum BR section 7.1.2.3, for subscriber certificates the key usage is optional and if present, keycertsign and crlsign must not be set. Section 7.1.2.1 and section 7.1.2.2 state that the extension should be present and marked as critical for Root CA and Sub CA certificates only. RFC5280 section 4.2.1.3, also mentions regarding the KU that "conforming CAs SHOULD mark this extension as critical". However, we will update our certificate profiles to set the "critical" bit for KU in subscriber certificates.

>           + Certificate Policies should not contain notice references

CA/B Forum BR section 7.1.2.3 states that the policyQualifierId and cPSuri extensions may be present, but does not disallow notice references. RFC5280 states that conforming CAs should not (and not must not) use the noticeref. Either way, we have removed the notice references from future certificates.

>       o Error
>           + Unallowed key usage for DSA public key

This is an ECDSA and not a DSA key.

>           + Certificate Policy explict text must not be VisibleString or BMPString

This is due to a bug in OpenSSL. As you can see at https://github.com/openssl/openssl/blob/master/crypto/x509v3/v3_cpols.c#L313, by default openssl assumes that the correct encoding for the explicit text is VisibleString. There is a pull request that updates the code in order to add support for other encodings (https://github.com/openssl/openssl/pull/576). We have added our own patch to openssl, and now we use the correct UTF8String encoding.
We believe that this is not a major issue, and should not stop the inclusion processes. Our tests have showed us that most CAs suffer from the same problem.

>       o Informational
>           + TLS Server certificate identified
> 
>   * /C=GR/O=Hellenic Academic and Research Institutions Cert. Authority/CN=Hellenic Academic and Research Institutions ECC AdminCA R1
>       o Warning
>           + Certificate Policies should not contain notice references

Please see above.

>           + CA certificates should include Digital Signature to allow signing OCSP responses

According to CA/B Forum BR section 7.1.2.2, the digitalSignature bit should only be set when the SubCA private key is used for signing OCSP responses. However, we do not use the SubCA private key for signing responses. Thus, including the Digital Signature key usage would be a violation of the CA/B Forum BR.

>       o Error
>           + Certificate Policy explict text must not be VisibleString or BMPString

Please see above.

>           + RFC822Name without @
>           + RFC822Name without @

The two RFC822Names are from the name constraints that HARICA uses. According to RFC5280 section 4.2.1.10:

   A name constraint for Internet mail addresses MAY specify a
   particular mailbox, all addresses at a particular host, or all
   mailboxes in a domain.  To indicate a particular mailbox, the
   constraint is the complete mail address.  For example,
   "[e-mail]" indicates the root mailbox on the host
   "example.com".  To indicate all Internet mail addresses on a
   particular host, the constraint is specified as the host name.  For
   example, the constraint "example.com" is satisfied by any mail
   address at the host "example.com".  To specify any address within a
   domain, the constraint is specified with a leading period (as with
   URIs).  For example, ".example.com" indicates all the Internet mail
   addresses in the domain "example.com", but not Internet mail
   addresses on the host "example.com".

Thus, we consider it valid to include an RFC822Name without a '@' as a name constraint.

>       o Informational
>           + CA certificate identified
> 
>   * /C=GR/L=Athens/O=Hellenic Academic and Research Institutions Cert. Authority/CN=Hellenic Academic and Research Institutions ECC RootCA 2015
>       o Warning
>           + Serial number must be positive
>           + Serial numbers should have at least 20 bits of entropy

Our Root CAs use the serial number 00. It is a practice used by many other CAs. The requirement for serial numbers with high entropy is a response to the 2008 Sotirov MD5 pre-image attack. We believe that it should apply only to end certificates requested by the subscribers and not to Root CA certificates.

>           + CA certificates should include Digital Signature to allow signing OCSP responses

Please see above.

>       o Informational
>           + CA certificate identified
> 
> Using certificate chain from 'https://www2.harica.gr'
> 
> Using certificate from local file 'HaricaRootCA2015.cer'
> 
>   * /C=GR/L=Athens/O=Hellenic Academic and Research Institutions Cert. Authority/CN=www2.harica.gr
>       o Warning
>           + Extension should be critical for KeyUsage

Please see above.

>           + Certificate Policies should not contain notice references

Please see above.

>       o Error
>           + Certificate Policy explict text must not be VisibleString or BMPString

Please see above.

>       o Informational
>           + TLS Server certificate identified
> 
>   * /C=GR/O=Hellenic Academic and Research Institutions Cert. Authority/CN=Hellenic Academic and Research Institutions AdminCA R5
>       o Warning
>           + Certificate Policies should not contain notice references

Please see above.

>           + CA certificates should include Digital Signature to allow signing OCSP responses

Please see above.

>       o Error
>           + Certificate Policy explict text must not be VisibleString or BMPString

Please see above.

>           + RFC822Name without @
>           + RFC822Name without @

Please see above.

>       o Informational
>           + CA certificate identified
> 
>   * /C=GR/L=Athens/O=Hellenic Academic and Research Institutions Cert. Authority/CN=Hellenic Academic and Research Institutions RootCA 2015
>       o Warning
>           + Serial number must be positive
>           + Serial numbers should have at least 20 bits of entropy

Please see above.

>           + CA certificates should include Digital Signature to allow signing OCSP responses

Please see above.

We are going to submit patches for what we have identified as bugs to certlint itself.

Comment 17

[Dana Keeler (she/her) (use needinfo) [:keeler] (on leave)]

The certlint tool has been updated.

(In reply to Fotis Loukos from comment #16)
> >       o Error
> >           + Unallowed key usage for DSA public key
> 
> This is an ECDSA and not a DSA key.

This was a bug in certlint. The tool now correctly identifies the key as EC and maintains that there is an unallowed key usage for it. I believe the usage in question is "keyEncipherment", which should be used for RSA keys. I think "keyAgreement" should be used instead.

> >           + Certificate Policy explict text must not be VisibleString or BMPString

I believe this has been fixed in certlint.

> >           + CA certificates should include Digital Signature to allow signing OCSP responses

I believe this has been fixed in certlint.

> >           + RFC822Name without @
> >           + RFC822Name without @

I believe this has been fixed in certlint.

> >       o Warning
> >           + Serial number must be positive
> >           + Serial numbers should have at least 20 bits of entropy
> 
> Our Root CAs use the serial number 00. It is a practice used by many other
> CAs. The requirement for serial numbers with high entropy is a response to
> the 2008 Sotirov MD5 pre-image attack. We believe that it should apply only
> to end certificates requested by the subscribers and not to Root CA
> certificates.

0 is not a positive number. RFC 5280 section 4.1.2.2 states "The serial number MUST be a positive integer assigned by the CA to each certificate."

Regarding entropy, the Baseline Requirements do not appear to differentiate between subscriber certificates and root CA certificates. Section 9.6 simply says "CAs SHOULD generate non-sequential Certificate serial numbers that exhibit at least 20 bits of entropy."

Comment 18

[Dana Keeler (she/her) (use needinfo) [:keeler] (on leave)]

(In reply to David Keeler [:keeler] (use needinfo?) from comment #17)
> Regarding entropy, the Baseline Requirements do not appear to differentiate
> between subscriber certificates and root CA certificates. Section 9.6 simply
> says "CAs SHOULD generate non-sequential Certificate serial numbers that
> exhibit at least 20 bits of entropy."

Whoops - wrong version of the BRs. That should be section 7.1.

Comment 19

[Fotis Loukos]

(In reply to David Keeler [:keeler] (use needinfo?) from comment #17)
> The certlint tool has been updated.
> 
> (In reply to Fotis Loukos from comment #16)
> > >       o Error
> > >           + Unallowed key usage for DSA public key
> > 
> > This is an ECDSA and not a DSA key.
> 
> This was a bug in certlint. The tool now correctly identifies the key as EC
> and maintains that there is an unallowed key usage for it. I believe the
> usage in question is "keyEncipherment", which should be used for RSA keys. I
> think "keyAgreement" should be used instead.

The keyAgreement bit should not be set for ECDSA certificates. Please see the paper by Hlauschek et al at Usenix woot 15 on Key Compromise Impersonation attacks against TLS. The keyEncipherment is not an unallowed key usage, but it is ignored for ECDSA certificates. We are going to remove it and update our CP/CPS regarding the key usages for ECDSA certificates.

> 
> > >           + Certificate Policy explict text must not be VisibleString or BMPString
> 
> I believe this has been fixed in certlint.
> 

This is not a bug in certlint, RFC5280 indeed states that the explicit text must not be VisibleString or BMPString. However, VisibleString is hardcoded in openssl, and possibly other TLS/CA software. At an internal survey, we found out that many CAs suffer from the same problem. We believe that this is not serious, still we have patched our version of openssl and new certificates use UTF8String encoding.


> > >           + CA certificates should include Digital Signature to allow signing OCSP responses
> 
> I believe this has been fixed in certlint.
> 
> > >           + RFC822Name without @
> > >           + RFC822Name without @
> 
> I believe this has been fixed in certlint.
> 
> > >       o Warning
> > >           + Serial number must be positive
> > >           + Serial numbers should have at least 20 bits of entropy
> > 
> > Our Root CAs use the serial number 00. It is a practice used by many other
> > CAs. The requirement for serial numbers with high entropy is a response to
> > the 2008 Sotirov MD5 pre-image attack. We believe that it should apply only
> > to end certificates requested by the subscribers and not to Root CA
> > certificates.
> 
> 0 is not a positive number. RFC 5280 section 4.1.2.2 states "The serial
> number MUST be a positive integer assigned by the CA to each certificate."
> 

The whole RFC5280 section 4.1 refers to the information associated with the subject of the certificate and the CA that issued it. This is not a certificate issued by a CA, it is a self-signed certificate, which is the trust-anchor itself. Assigning the serial number 0 to the Root CA is a practice used by many CAs already included in the Mozilla Root Program. It presents no risk to the public and according to the RFC, certificate users should be prepared to gracefully handle such certificates.

> Regarding entropy, the Baseline Requirements do not appear to differentiate
> between subscriber certificates and root CA certificates. Section 9.6 simply
> says "CAs SHOULD generate non-sequential Certificate serial numbers that
> exhibit at least 20 bits of entropy."

You are correct that section 7.1 of the CA/B Forum BR does not differentiate between subscriber, root and subordinate CA certificates regarding entropy. However, these rules were created to protect against hash collision attacks and they were meant for subscriber certificates. These rules (regarding the serial number) generally do not apply to Trust anchors since (according to RFC5280 6.1.1) "The trust anchor information is trusted because it was delivered to the path processing procedure by some trustworthy out-of-band procedure". Excluding the serial number test against trust anchor certificates on certlint does not pose any threat whatsoever.

Comment 20

[Peter Bowen]

(In reply to Fotis Loukos from comment #19)
> (In reply to David Keeler [:keeler] (use needinfo?) from comment #17)
> > The certlint tool has been updated.
> > 
> > (In reply to Fotis Loukos from comment #16)
> > > >       o Error
> > > >           + Unallowed key usage for DSA public key
> > > 
> > > This is an ECDSA and not a DSA key.
> > 
> > This was a bug in certlint. The tool now correctly identifies the key as EC
> > and maintains that there is an unallowed key usage for it. I believe the
> > usage in question is "keyEncipherment", which should be used for RSA keys. I
> > think "keyAgreement" should be used instead.
> 
> The keyAgreement bit should not be set for ECDSA certificates. Please see
> the paper by Hlauschek et al at Usenix woot 15 on Key Compromise
> Impersonation attacks against TLS. The keyEncipherment is not an unallowed
> key usage, but it is ignored for ECDSA certificates. We are going to remove
> it and update our CP/CPS regarding the key usages for ECDSA certificates.

Section 3 of RFC 5480 (https://tools.ietf.org/html/rfc5480#section-3) defines the keyUsage bits allowed with Elliptic Curve Cryptography Subject Public Key Information.  keyEncipherment is not on the list.

Additionally I agree with Fotis Loukos that keyAgreement is not correct when the key is expected to be used with ECDSA.

Comment 21

[Kathleen Wilson]

(In reply to Fotis Loukos from comment #19)
>>> Our Root CAs use the serial number 00. It is a practice used by many other
>>> CAs. 

Already-included CA certificates are grandfathered in, but all new CA certificates need to meet the BRs and pass the certlint tests without error before they can be included. However, we are open to updating the certlint tests, as long as the updates are in line with the BRs.

>> 0 is not a positive number. RFC 5280 section 4.1.2.2 states "The serial
>> number MUST be a positive integer assigned by the CA to each certificate."

RFC 5280 is not ambiguous as to whether zero is positive or not.
https://tools.ietf.org/html/rfc5280#section-4.2.1.10
   Note: Non-conforming CAs may issue certificates with serial numbers
   that are negative or zero.  Certificate users SHOULD be prepared to
   gracefully handle such certificates.
So zero is clearly non-conforming.

> The whole RFC5280 section 4.1 refers to the information associated with the
> subject of the certificate and the CA that issued it. This is not a
> certificate issued by a CA, it is a self-signed certificate, which is the
> trust-anchor itself. 


Are you saying that this part of the RFC does not apply to root certificates?

Comment 22

[Fotis Loukos]

(In reply to Kathleen Wilson from comment #21)
> (In reply to Fotis Loukos from comment #19)
> >>> Our Root CAs use the serial number 00. It is a practice used by many other
> >>> CAs. 
> 
> Already-included CA certificates are grandfathered in, but all new CA
> certificates need to meet the BRs and pass the certlint tests without error
> before they can be included. However, we are open to updating the certlint
> tests, as long as the updates are in line with the BRs.
> 
> >> 0 is not a positive number. RFC 5280 section 4.1.2.2 states "The serial
> >> number MUST be a positive integer assigned by the CA to each certificate."
> 
> RFC 5280 is not ambiguous as to whether zero is positive or not.
> https://tools.ietf.org/html/rfc5280#section-4.2.1.10
>    Note: Non-conforming CAs may issue certificates with serial numbers
>    that are negative or zero.  Certificate users SHOULD be prepared to
>    gracefully handle such certificates.
> So zero is clearly non-conforming.
> 
> > The whole RFC5280 section 4.1 refers to the information associated with the
> > subject of the certificate and the CA that issued it. This is not a
> > certificate issued by a CA, it is a self-signed certificate, which is the
> > trust-anchor itself. 
> 
> 
> Are you saying that this part of the RFC does not apply to root certificates?

Correct. We believe that this section applies to issued certificates.
Quoting the beginning of the section:

   The sequence TBSCertificate contains information associated with the
   subject of the certificate and the CA that issued it.

Thus, it only applies to certificates issued by a CA, and not to the CA
itself.

Comment 23

[Kathleen Wilson]

Note that I started a discussion about these certlint tests in mozilla.dev.security.policy:
https://groups.google.com/d/msg/mozilla.dev.security.policy/3avqmSF4MVU/yzbAbgjvAAAJ
Issues that require further discussion should be moved there, so that others may contribute to the discussion/decision, I will be able to refer people to the decisions later, and the results will benefit everyone who is now required to run these tests.

I will move the 00 serial number discussion there.

Comment 24

[Kathleen Wilson]

(In reply to Kathleen Wilson from comment #23)
> 
> I will move the 00 serial number discussion there.

The 00 serial number discussion happened in mozilla.dev.security.policy.
https://groups.google.com/d/msg/mozilla.dev.security.policy/3avqmSF4MVU/ZPFE0rIuAQAJ
It sparked discussion in the CAB Forum, which I think will address this moving forward. I believe this is not a show stopper for this particular root inclusion request.

Comment 25

[Kathleen Wilson]

The public comment period for this request is now over.

This request has been evaluated as per Mozilla’s CA Certificate Inclusion Policy at
https://www.mozilla.org/about/governance/policies/security-group/certs/policy/inclusion/

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

Inclusion Policy 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.

Inclusion Policy Section 6 [Relevance and Policy].
HARICA appears to provide a service relevant to Mozilla users. It is a non-profit organization serving the Greek Academic and Research Community; operated by the Greek Universities Network (www.gunet.gr).

Root Certificate Name: Hellenic Academic and Research Institutions RootCA 2015
O From Issuer Field: Hellenic Academic and Research Institutions Cert. Authority
Trust Bits: Email; Websites
EV Policy OID: Not EV
Root Certificate Download URL: http://www.harica.gr/certs/HaricaRootCA2015.der

Root Certificate Name: Hellenic Academic and Research Institutions ECC RootCA 2015
O From Issuer Field: Hellenic Academic and Research Institutions Cert. Authority
Trust Bits: Email; Websites
EV Policy OID: Not EV
Root Certificate Download URL: http://www.harica.gr/certs/HaricaECCRootCA2015.der

* The primary document is the CPS; provided in Greek and English 

Document Repository: http://www.harica.gr/procedures
CPS: http://www.harica.gr/documents/CPS-EN.pdf
Qualified Certificates (under GUnet): http://www.eett.gr/opencms/opencms/EETT_EN/Electronic_Communications/DigitalSignatures/EsignProviders.html

Certificate Revocation
CRL URLs:
http://crlv1.harica.gr/HaricaRootCA2015/crlv1.der.crl
http://crlv1.harica.gr/HaricaAdministrationCAR5/crlv1.der.crl
http://crlv1.harica.gr/HaricaECCRootCA2015/crlv1.der.crl
http://crlv1.harica.gr/HaricaECCAdministrationCAR1/crlv1.der.crl
CPS section 4.9.7: For end-user/device certificates ... the CRL will be in effect for a maximum time of ten days.
OCSP URL: http://ocsp.harica.gr
For Subscriber Certificates: OCSP responses have a maximum expiration time of two days.

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

* SSL Verification: CPS section 3.2.3.2 lists the ways in which the CA shall confirm that the applicant either is the Domain Name Registrant or has control over the FQDN. The procedures correspond with the methods of domain verification listed in version 1.3 of the CAB Forum Baseline Requirements. Each server certificate is manually verified.

* Email Verification: CPS section 3.2.3.1 lists three methods for e-mail ownership and control verification: The first method uses an e-mail verification involving a unique web page and approval of the institution's network operation center mail administrator. The second method verifies the email address against the institution's LDAP server, and in order for a user to be listed in the Institutional Directory server, the institution must have verified the user. The third method uses a Single Sign On (SSO) architecture based on the SAML specification, in which the user enters the personal e-mail address at the initial request form and is then redirected to the appropriate web page of the Identity Provider who verifies the user and returns the real name and the email address.

Inclusion Policy Sections 11-14 [Audit]. 
Annual audits are performed by QMSCERT, according to the ETSI TS 102 042 criteria.
http://www.qmscert.com/share/HARICA-ETSI_CERTIFICATE_AUTH_W_ANNEX.pdf

Inclusion Policy Section 18 [Certificate Hierarchy]
The new roots will be cross-signed by “Hellenic Academic and Research Institutions RootCA 2011” to assist the rollover.
 “Hellenic Academic and Research Institutions RootCA 2011” currently has 20 internally operated and technically-constrained subCAs.
There is currently one externally-operated subordinate CA:
- Aristotle University of Thessaloniki
- http://www.auth.gr, http://it.auth.gr
- http://www.pki.auth.gr/certs/AuthCentralCAR3.pem, (to be decommissioned by Sep 2015)
- http://www.pki.auth.gr/certs/AuthCentralCAR4.pem
- http://www.pki.auth.gr/certs/AuthCentralCAR5.pem
- AuthCentralCAR4 and AuthCentralCAR5 issue sub-CAs and end user/server certificates
- http://www.pki.auth.gr/documents/CPS-EN.pdf
- Sections in CP/CPS demonstrating the measures to verify:
-- Ownership of domain name: 3.2.2, 3.2.3.2 and 3.2.5
-- Ownership of e-mail: 3.2.2, 3.2.3.1 and 3.2.5
- For all certificates chaining up to these Sub-CA, both the organization and the ownership/control of the domain are verified.
- This CA is currently operated by the same administration team as the HARICA Root CA.
- OCSP: http://ocsp.pki.auth.gr
- Audit: http://pki.auth.gr/documents/AUTH-ETSI_CERTIFICATE_AUTH_W_ANNEX

“Hellenic Academic and Research Institutions ECC RootCA 2015” currently has the following internally-operated subCAs:
- Hellenic Academic and Research Institutions ECC AdminCA R1
We plan to issue the following internally operated subCAs for specific usages:
- ECC Client Authentication and SecureEmail
- ECC Code Signing
- ECC SSL (DV/OV) Server Certificates
There are currently no externally operated subCAs issued from this root. According to our CP/CPS, in case of externally operated CAs, they will either be technically constrained or publicly disclosed and audited.

Based on this assessment I intend to approve this request from HARICA to include the “Hellenic Academic and Research Institutions RootCA 2015” and “Hellenic Academic and Research Institutions ECC RootCA 2015” root certificates, and enable the Websites and Email trust bits for both roots.

The following action item will be tracked in this bug, in parallel with the inclusion process.

ACTION ITEM: Update the CPS to resolve the issue about the keyAgreement bit being set in an ECDSA certificate per Comment #19, and to resolve the concerns that were raised in the discussion:
https://groups.google.com/d/msg/mozilla.dev.security.policy/dYoQcI0e1qA/1YbRiOcxAAAJ

Comment 26

[Dimitris Zacharopoulos]

Regarding the Action Item for the keyAgreement bit, according to current security practices per Comment #19 and Comment #20, we will not use the keyAgreement bit for ECDSA. We plan to remove the keyEncipherment bit which is ignored in ECDSA certificates.

Comment 27

[Kathleen Wilson]

As per the summary in Comment #25, and on behalf of Mozilla I approve this request from Hellenic Academic and Research Institutions Certification Authority (HARICA) to include the following root certificates:

** "Hellenic Academic and Research Institutions RootCA 2015" (websites, email)
** "Hellenic Academic and Research Institutions ECC RootCA 2015" (websites, email)

I will file the NSS bug for the approved changes.

Comment 28

[Kathleen Wilson]

I have filed bug #1256494 against NSS for the actual changes.

Comment 29

[Dimitris Zacharopoulos]

The final version 3.3 CP/CPS has been approved and published at http://www.harica.gr/documents/CPS-EN.pdf.

Comment 30

[Dimitris Zacharopoulos]

Attachment: HARICA CP-CPS-ENG-3.3 [e-mail]

Comment 31

[Dimitris Zacharopoulos]

According to the public discussion (https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/dYoQcI0e1qA) the action items that should be addressed in HARICA's CP/CPS are the following:

1. Make definitions more clear in the existing language
2. Update Section 3.2.3.1 to make the identity validation more clear
3. Correct a typo in 3.3.2 "initial cert" (will be fixed along with the "keyAgreement bit" of ECDSA certificates)
4. Update 6.1.6 to add specific information about duplicate keys for user certificates
5. Change the language in section 7.1.5 for "created upon first request" statement.

We have currently addressed only the 3rd item from the list above. The rest of the items are language clarifications which have been addressed and discussed during the public discussion. These changes will be made into the CP/CPS during our upcoming audit.

Comment 32

[Dimitris Zacharopoulos]

Attachment: HARICA CP-CPS-ENG-3.4 [e-mail]

Updated CP/CPS to improve language for the terms TSP/CA