510506 - Add Microsec e-Szigno Root CA 2009 certificate

Status: RESOLVED FIXED

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

Description

[Istvan Zsolt BERTA]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; hu; rv:1.9.1.2) Gecko/20090729 Firefox/3.5.2 (.NET CLR 3.5.30729)
Build Identifier: 

I am writing this bug, because Microsec would like to request the inclusion of a new root certificate. We started this new root because we promised to solve an OCSP-issue that was raised during the inclusion of our currently included root certificate.


In Bug 370505 , we have requested the inclusion of the Microsec root certificate into the default certificate store of Mozilla.
Our request was approved and our root was included recently (in 2009).

However, there was an issue about our OCSP service during the public discussion: We had a separate root for OCSP, but we had OCSP URLs in our end-entity and CA certificates, and our OCSP service required authentication. We accepted that this made it problematic for the Mozilla community to use our OCSP.
http://groups.google.com/group/mozilla.dev.tech.crypto/browse_thread/thread/416427a350db11a9#

We removed the OCSP URL from webserver end-entity certificates, we also removed it from our intermediate CA certificate used for issuing webserver certificates. (Unfortunately, we could not remove it from our root easily. Our root certificate does still contain an above OCSP URL.)
Thus, our current root was approved and included without our OCSP service.

As a long-term solution, we promised to come up with a solution for providing an OCSP service usable for the Mozilla community, that does not require authentication and works using the 'authorized responder' concept.
http://groups.google.com/group/mozilla.dev.tech.crypto/msg/71ff5be3141529a8?dmode=source


We have chosen the following solution: 
We have introduced a new root, and under this root we issue certificates with an OCSP service  usable for the general public. Certificates of these OCSP responders are issued under the same root (according to the 'authorized responder' concept), and this OCSP service does not require authentication.

The new root has a new DN and a new key. Our plan is to operate the two roots simultaneously for some years, and the old one shall be phased out afterwards. (Our hierarchy under our old root is based on SHA-1, the one under our new root is based on SHA-256. Hungarian and European specifications/regulations will soon require us to phase out SHA-1.)


We would like to request the inclusion of our new root into the Mozilla certificate store.


The subject DN and issuer DN of our new root certificate is:
E = [e-mail]
CN = Microsec e-Szigno Root CA 2009
O = Microsec Ltd.
L = Budapest
C = HU

The SHA-1 fingerprint of the root certificate is:
a65cb4733d94a5c865a864647c2c01272c89b143
The SHA-256 fingerprint of the root certificate is:
8e8c6ebf77dc73db3e38e93f4803e62b6b5933beb51ee4152f68d7aa14426b31

The new root certificate is available here:
http://www.e-szigno.hu/rootca2009.crt

This is an X509 v3 certificate. The signature is based on SHA-256 and 1024-bit-RSA. It is valid from 2009-06-16 to 2029-12-30.

The hierarchy under our new root is available here (the diagram also includes OCSP responders and CRL URLs): 
http://srv.e-szigno.hu/menu/index.php?lap=english_ca_hierarchy#rootca2009

There are no subordinate CAs operated by third parties. It has not issued any cross-certificates for other roots, and was not cross-certified by other roots either.

The following website can be used for testing a webserver certificate in our new hierarchy:
https://pca.e-szigno.hu/





Apart from the new root certificate, our service did not change. 

The name of our company is: Microsec Ltd.
Website: http://www.e-szigno.hu/?lap=english
We are a private corporation, we primarily operate in Hungary, we provide services for the Hungarian general public.


Using this new root certificate we issue end-user certificates for 
-SSL enabled servers, and
-digitally signed and encrypted email, and
-code signing.

Our CA is audited by the Hungarian National Communications Authority. An audit is performed every year, according to cirteria that include ETSI TS 101 456 and ETSI TS 102 042. The freshest audit statement we have in English is this one:
http://srv.e-szigno.hu/menu/docs/NhhSupervision2008.pdf

All SSL certificates we issue are OV certificates.
In case of certificates for e-mails, we verify both the e-mail address and the identity of the subscriber.
In case of code-signing certificates, we verify the identity of the subscriber.

Our CPS for webserver certificates is available here:
http://www.e-szigno.hu/docs/szsz--hsz--altalanos--v2.0.pdf
Although the above document is in Hungarian, we have previously submitted an English translation of v1.6 of this CPS, it is available here:
http://www.e-szigno.hu/docs/szsz--hsz--altalanos--v1.6--EN.doc
The new root and the new hierarchy are the main difference between v2.0 and v1.6.


During the public discussion, Frank wrote that he "would give expedited approval to any future refresh of the root, as long as nothing had changed in terms of Microsec's operations and there were no technical problems with the new root".
http://groups.google.com/group/mozilla.dev.tech.crypto/msg/a6df3d5dbdce5ec6?dmode=source
I hope we qualify for this with the solution we chose (as we would like to keep both roots during the rollover period).


Please let me know if you need any further information.

Regards,

István

Reproducible: Always

Comment 1

[Kathleen Wilson]

Attachment: Initial Information Gathering Document

Please review the attached Initial Information Gathering document for accuracy and completeness.  The items highlighted in yellow indicate where further information or clarification is needed.  The list of potentially problematic practices (http://wiki.mozilla.org/CA:Problematic_Practices) has grown since your previous root inclusion, so please be sure to scroll all the way to the end of the attached document to see the highlighted sections there.

Comment 2

[Istvan Zsolt BERTA]

Dear Kathleen,

I have reviewed the Initial Information Gathering document, I have two remarks:
The CRL at http://crl.e-szigno.hu/a3ca2009.crl is not the CRL of the root, it is the CRL of an intermediate CA (that issued the certificate for the test website). The CRL issued by our root is at: http://crl.e-szigno.hu/rootca2009.crl
We issue CRLs every 24 hours, but the difference between the nextUpdate and thisUpdate is 25 hours (so our CRLs overlap).


Our next audit is going to happen in October 2009, it shall include our new root.
The new root is operated in the same (legal, technical and administrative) environment as the old one.

Delegation of Domain / Email validation to third parties:
We do not delegate domain or e-mail validation (or any operation related to registration) to third parties.
If we shall do so in the future, there shall be a contractual agreement between Microsec and the RA. The RA shall adhere to our CP/CPS, and Microsec shall be liable for the activities of the RA.

Distributing generated private keys in PKCS#12 files:
If we generate the private key, it is distributed with a smart card.
In case of webserver certificates, we do not generate private keys, we receive PKCS#10 requests only.

Certificates referencing hostnames or private IP addresses:
Public addresses are referenced in our certificates only. 

Regards,

István

Comment 3

[Kathleen Wilson]

Thank you for the information and clarifications.

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

As soon as I get Subversion working on my system (this may take a week or so), I will add this request to the pending page:
http://www.mozilla.org/projects/security/certs/pending/#Microsec

Please provide the new audit statement when it becomes available.

Comment 4

[Nelson Bolyard (seldom reads bugmail)]

I might suggest migrating pages from www.mozilla.org to wiki.mozilla.org

Comment 5

[Istvan Zsolt BERTA]

Attachment: NHH audit statement

(In reply to comment #3)
> Please provide the new audit statement when it becomes available.

Our audit took place in October, we have just received the English audit statement. Please find it attached.

It is also available on our website at:
http://srv.e-szigno.hu/menu/docs/NhhSupervision2009.pdf

Thanks,

István

Comment 6

[Kathleen Wilson]

Attachment: Completed Information Gathering Document

Comment 7

[Kathleen Wilson]

I have re-reviewed the information in this request in preparation for the upcoming public discussion. I do not have any further questions at this time.  I will post a note here in this bug when I start the public discussion for this request.

Comment 8

[Kathleen Wilson]

I am now opening the first public discussion period for this request from Microsec to add the “Microsec e-Szigno Root CA 2009” root certificate.

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 “Microsec Root Inclusion Request”

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

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

Comment 9

[Kathleen Wilson]

The public comment period for this request is now over. 

This request has been evaluated as per sections 1, 5 and 15 of the official CA 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 “Microsec e-Szigno Root CA 2009” root certificate, and to enable all three trust bits.

Section 4 [Technical]. I am not aware of any technical issues with certificates issued by Microsec, or of instances where they have 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]. Microsec appears to provide a service relevant to Mozilla users:  It is a Hungarian certificate authority and is the IT service provider of the Hungarian Ministry of Justice.

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 Certificate Practice for web server certificates, code signing certificates, e-mail encryption certificates and SSL client certificates. CPS version 1.6 was translated into English. CPS version 2.0 added information for the new root, but is in only in Hungarian. 

CPS V2.0 (Hungarian): http://www.e-szigno.hu/docs/szsz--hsz--altalanos--v2.0.pdf 
CPS V1.6 (English): http://www.e-szigno.hu/docs/szsz--hsz--altalanos--v1.6--EN.doc

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

* Email: When the requested certificate contains an email address, Microsec verifies that the email address is that of the certificate Subject. Email addresses are verified by sending an email to that address, and the contents of this email are needed at registration.

* SSL: For SSL certificates, Microsec verifies the Subscriber Organization and verifies that the address or domain to be indicated within the certificate of the server is actually held by the Subject, or whether the Subject is in possession of an authorization according to which it has the right to request an SSL certificate for the given address or domain. Domain names are verified using the online registry for appropriate 
domains, e.g. http://www.domain.hu for the .hu top level domains.  If the subscriber is not the registered owner of the domain, Microsec requests an official letter from the owner confirming that the subscriber is 
allowed to request the certificate.

* Code: Certificates serving the purpose of signing of computer programs (code signing) and Web server certificates are only issued by Microsec according to certificate class III. The identity of the Subject and the Represented Organization, as well as whether the private key belonging to the public key within the certificate are verified accordingly prior to the issuing of the certificate.

Section 8-10 [Audit]. Microsec is audited annually by the Hungarian Government National Communications Authority to ensure it meets the criteria as outlined in the Hungarian Act on Electronic Signatures, ETSI 101.456, and ETSI 102.042. Microsec is listed in the National Communications Authority’s website as a Registered Provider of both Qualified certificates and Non-Qualified certificates: http://webold.nhh.hu/esign/szolgParams/main.do

Section 13 [Certificate Hierarchy]. This new root signs internally-operated subordinate CAs based on the different classes and types of end-entity certificates. A CA Hierarchy diagram for both roots is available here: http://srv.e-szigno.hu/menu/index.php?lap=english_ca_hierarchy#rootca2009

Other: 
* Next Update for end-entity CRLs is 25 hours. 
* Under this new root OCSP is available to the general public.

Based on this assessment I intend to approve this request to add the “Microsec e-Szigno Root CA 2009” root certificate to NSS, and to enable all three trust bits.

Comment 10

[Kathleen Wilson]

To the representatives of Microsec: 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 #9, and on behalf of the Mozilla project I
approve this request from Microsec to include the following root certificate in
Mozilla, with trust bits set as indicated:

* Microsec e-Szigno Root CA 2009 (web sites, email, code signing)

I will file the NSS bug to effect the approved changes.

Comment 11

[Kathleen Wilson]

I have filed bug 557904 against NSS for the actual changes.

Comment 12

[Istvan Zsolt BERTA]

Dear Kathleen,

Thank you very much for your help.

István

Comment 13

[Istvan Zsolt BERTA]

Dear Kathleen,

Recently, we have noticed a potential issue concerning our root certificate to be included.

In the root certificate 'Microsec e-Szigno Root CA 2009' at http://www.e-szigno.hu/rootca2009.crt there is a certificate policies extension. Moreover, the CP OID in this root certificate is different from the CP OID in our end-user certificates. This might cause a problem when validating our certification path against a policy OID.

The certification path validation algorithm in Setion 6 of RFC 5280 does not deal with the contents of the root certificate (in fact, it does not need a root certificate at all, just a public key and a DN of a 'trust anchor'). However, according to Section 6.2, an appication may decide to use the CP OID in the root certificate for validating the certification path.
Until recently, we were not aware of any applications using this option.

We have recently learned of applications/cases where a CP OID in a root certificate does pose a problem. For instance, CP OID validation is done regularly in the EV world, and we are planning to go EV in the future, so we feel it would be safer to solve this problem now when there are very few relying parties using this certificate yet. Our root is just being distributed to various browsers/applications, and we have decided to distribute a different certificate that does not have a certificate policies extension.
Thus we have come to the conclusion to update our root certificate.


We would like to have the new certificate included into the NSS and the Mozilla certificate repository instead of the old one.

There are the following differences between the old and the new 'Microsec e-Szigno Root CA 2009' root certificates:
* the new root certificate does not contain a certificate policies extension,
* the new root certificate has a different serial number,
* the signature on the new root certificate is different.
All other information in the new root certificate remains the same as in the old one - including the DN and the public key.
We also use the same policies and procedures for this root certificate.

This new root certificate is available at:
http://www.e-szigno.hu/rootca2009_02.crt
SHA-1 fingerprint: 89 df 74 fe 5c f4 0f 4a 80 f9 e3 37 7d 54 da 91 e1 01 31 8e

We have set up a test SSL website chained to this root at: https://pca.e-szigno.hu/


We apologize for this complication, and we understand that this might change the inclusion process. Still, we thought it would be better to perform this change now rather than after the inclusion. We feel we have resolved a problem, and we have not made a material modification in the operation of our CA.

Thank you very much for your help.

Best regards,

István

Comment 14

[Kathleen Wilson]

I am not aware of any issues with this request to update the root certificate as stated. However, I think that I should re-open the public discussion to inform the Mozilla community of the change in the root certificate that had been approved for inclusion.

Comment 15

[Kathleen Wilson]

I am now re-opening the public discussion for this request from Microsec to add the “Microsec e-Szigno Root CA 2009” root certificate.

The purpose of this additional round of discussion is to make sure there are no concerns in regards to changes in the root certificate, which was previously approved for inclusion.

Old Root Cert: https://bugzilla.mozilla.org/attachment.cgi?id=437659
SHA1: a6:5c:b4:73:3d:94:a5:c8:65:a8:64:64:7c:2c:01:27:2c:89:b1:43

New Root Cert: http://www.e-szigno.hu/rootca2009_02.crt
SHA1: 89:DF:74:FE:5C:F4:0F:4A:80:F9:E3:37:7D:54:DA:91:E1:01:31:8E

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 “Microsec Root Inclusion Request”. 

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

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

Comment 16

[Kathleen Wilson]

I am now closing the public discussion for the request to modify the root certificate before including it in NSS. There were no action items resulting from the discussion.

I will update bug 557904 with the new root certificate.

Comment 17

[Kathleen Wilson]

Attachment: Completed Information Gathering Document

Updated the "Completed Information Gathering Document" to point to the updated root certificate and have the correct SHA1 fingerprint.

Comment 18

[Kathleen Wilson]

I have confirmed that the following root cert is a Builtin Object Token in Firefox 3.6.12.

CN = Microsec e-Szigno Root CA 2009
SHA1: 89:DF:74:FE:5C:F4:0F:4A:80:F9:E3:37:7D:54:DA:91:E1:01:31:8E