370505 - Add Microsec Ltd root CA certificate

Status: RESOLVED FIXED

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

Description

[Istvan Zsolt BERTA]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; hu; rv:1.8.1.1) Gecko/20061204 Firefox/2.0.0.1
Build Identifier: 

Our company, Microsec Ltd. is a certificate authority, and we would like to have our root certificate included in the default certificate store of Mozilla.

We operate within the framework of EU Directive 1999/93/EC (on electronic signatures) and the Hungarian law on electronic signatures. We are regularly supervised and audited by the Hungarian Communications Authority (www.nhh.hu), who has registered us as a CA entitled to issue both qualified and non-qualified certificates.
Our website is www.e-szigno.hu, there is a minimal English version at
http://www.e-szigno.hu/index_en.html

We have studied the Mozilla CA Certificate Policy (Version 1.0) and we hereby submit the information required in paragraph 14.

Our root certificate is available at
http://www.e-szigno.hu/RootCA.crt
The subject and issuer DN of our root certificate contains:
CN = Microsec e-Szigno Root CA
OU = e-Szigno CA
O = Microsec Ltd.
L = Budapest
C = HU
The SHA-1 fingerprint of the root certificate is:
23 88 c9 d3 71 cc 9e 96 3d ff 7d 3c a7 ce fc d6 25 ec 19 0d

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

We issue our certificates based on the following public certificate policies and certificate practice statements. (Our legislation requires us to maintain three different CPSs.) These documents are in Hungarian.

1. The CPS for our qualified certificates is available at
http://www.e-szigno.hu/docs/szsz--hsz--minositett--v4.1.pdf
Using this CPS we support the following qualified certificate policies:
http://www.e-szigno.hu/docs/hitelesitesiRend--v3.1.pdf
and
http://www.e-szigno.hu/docs/mhr_v14_e.pdf
Both of these document contain qualified certificate policies based on ETSI TS 101456, QCP public + SSCD. (They are more or less equivalent with each other, but we are required to support both.)
When issuing qualified certificates based on these two CPs we perform a face-to-face registration of the end-user, verify his or her identity based on an official ID card or a passport or a driving license, and we also verify the data in these documents using a Hungarian central database of personal information.

2. The CPS for our non-qualified certificates for creating electronic signatures is available at:
http://www.e-szigno.hu/docs/szsz--hsz--fokozott--v1.1.pdf
Using this CPS we support the following non-qualified certificate policies:
http://www.e-szigno.hu/docs/ehr+_v14_e.pdf
(This one contains policies based on ETSI TS 102 042, NCP+.)
http://www.e-szigno.hu/docs/ehr_v14_e.pdf
(This one contains policies based on ETSI TS 102 042, NCP.)
http://www.e-szigno.hu/docs/hrf--v1.2.pdf
(This one contains policies based on ETSI TS 102 042, NCP and ETSI TS 102 042, LCP)
In case of policies based on ETSI TS 102 042, NCP+ and ETSI TS 102 042, NCP, we verify certificate signing requests and identify end-users exactly the same way as we do in case of qualified certificates (face-to-face registration, ID card and verification in a central database).

In case of our policy based on ETSI TS 102 042, LCP, we require a photocopy of the ID card of the end-user and we verify that the end-user controls the email address that is to appear in the certificate. 

3. The CPS for our non-qualified certificates for purposes other than creating electronic signatures (e.g. for encryption, authentication or even code signing) is available at:
http://www.e-szigno.hu/docs/szsz--hsz--altalanos--v1.0.pdf
Using this CPS we issue certificate based on the same policies as we support in case of certificates for creating electronic signatures. (For some obscure reason, or Communications Authority required us to separate the CPS but not the policies.)

Certificates for code signing and SSL servers are only issued using policies based on NCP or NCP+, which means that e.g. a face-to-face registration is required in these cases. In case of SSL servers we verify on the official .hu registration site (www.domain.hu) that the owner of the domain name that is to appear in the certificate is the one who requests the certificate (or that the owner of the domain name authorized the person to request a certificate for that domain). In case of certificate for code signing we require that the one who request the certificate is authorized by the entity that is to appear in the certificate.


The Hungarian Communications Authority audits us every year to verify that we comply with the above criteria. Their audit is based on Hungarian laws and regulations that rely on European and international standards and recommendations, including ETSI specifications such as ETSI TS 101 456 and ETSI TS 102. 
We have a written statement from the Communications Authority confirming that we fulfill their audit criteria and that they perform the audit every year. They also claim that the criteria of audit we have passed are equivalent with the criteria of the AICPA/CICA WebTrust Program for CAs.
I shall attach the scanned version of their statement to this bug report (or at least, I shall try to, as this is the first bug report I submit) and I can provide an original one on request.

Please let me know if you need any further information.
Thanks,

István



Reproducible: Always

Comment 1

[Istvan Zsolt BERTA]

Attachment: A statement of the Hungarian National Communications Authority claiming that it audits our CA according to ETSI specifications.

Comment 2

[Gervase Markham [:gerv]]

Istvan:

Does the National Communications Authority have a website? Is this document available from their website?

Do you offer CRLs or OCSP? Please give HTTP URLs.

Thanks,

Gerv

Comment 3

[Istvan Zsolt BERTA]

The website of the Hungarian National Communications Authority is at 
http://www.nhh.hu
(Their name is Nemzeti Hírközlési Hatóság in Hungarian.)
Their website has an English version, but the information on registered CAs is available there in Hungarian only. The document I attached is not available on their website. 

They have a list of Hungarian CAs issuing qualified certificates
http://oldweb.nhh.hu:7777/pls/portal30/ESIGN_PORTAL.DYN_MI_ALL.SHOW
and another list of Hungarian CAs issuing non-qualified certificates 
http://oldweb.nhh.hu:7777/pls/portal30/ESIGN_PORTAL.DYN_FB_ALL.SHOW

The information on Microsec Ltd. as a qualified CA is available at
http://oldweb.nhh.hu:7777/pls/portal30/ESIGN_PORTAL.DYN_MI_RESZLET.SHOW?p_arg_names=sz_szazon&p_arg_values=10589605-2-41
and as a non-qualified CA at
http://oldweb.nhh.hu:7777/pls/portal30/ESIGN_PORTAL.DYN_FB_RESZLET.SHOW?p_arg_names=sz_szazon&p_arg_values=10589605-2-41
These pages also contain our CPs and CPSs.

We (are required to) have several different CA keypairs, so we have several CRLs. A list of CRL URLs required for using our qualified services is available at
http://www.e-szigno.hu/minositett_crl.html
and the CRL URLs required for using our non-qualified services are available at
http://www.e-szigno.hu/fokozott_crl.html

Each end-user certificate we issue also includes the corresponding CRL distribution point.


We also offer OCSP, but our OCSP responders are issued under a separate dedicated root (e-Szigno OCSP CA). This CA issues OCSP responder certificates only, with a validity period of 10 minutes. We do not provide OCSP is a free service (ro relying parties), we provide it to our clients for a fee.

I did not request the inclusion of our OCSP root, because
-I don't think Mozilla supports OCSP under a separate root,
-it is not publicly available, so it would be of no use for Mozilla user relying parties.

Thanks,

István

Comment 4

[Gervase Markham [:gerv]]

Istvan: I'm sorry for the delay in getting back to you.

If it's not possible to have it available from the auditor's website, please could you make that audit letter available from your website? Once you've done that, I have all the information I need to add you to the review queue.

Gerv

Comment 5

[Istvan Zsolt BERTA]

OK, now the document is available from our website at
http://www.e-szigno.hu/docs/NhhCertification.pdf

Thanks,

István

Comment 6

[Gervase Markham [:gerv]]

Reassign all open CA bugs to me. Apologies for the bugspam.

Gerv

Comment 7

[Gervase Markham [:gerv]]

I have gathered together all the information you have provided, and placed it
in the "pending" CA root certificate request list, which is here:
http://www.mozilla.org/projects/security/certs/pending/

Please confirm that the information for your CA is correct, and add a comment
to this bug to that effect. Once you have done that, your application will turn
"green" and be ready for consideration.

If your CA or certificate does not have a summary paragraph, please feel free
to provide one. Note: these paragraphs are not supposed to be marketing
statements :-)

Gerv

Comment 8

[Istvan Zsolt BERTA]

I verified the information on our CA, it is correct.
Thanks,

István

Comment 9

[Gervase Markham [:gerv]]

I have begun this evaluation. Some questions:

- I am concerned that the list of accredited CAs is only available on a machine called "oldweb". That might imply that it is not current. Is the list available on the current NHH website?

- Do you have a certificate hierarchy diagram for your roots?

- How frequently do you reissue your CRLs for end entity certificates?

Also, your CP/CPS and/or other documents are not in English. Assuming they are not available in English (please let me know if they are), then I have to have particular parts translated. As having documents translated and reading approximate translations is a tedious task, I hope you will be able to help me in narrowing down which parts to read.

When I read a CP/CPS, I am looking to see if the practices of the CA satisfy the criteria in our CA Certificate Policy:
http://www.mozilla.org/projects/security/certs/policy/

Specifically, I look for:

- Which exact section contains an undertaking to confirm that the applicant has control of the email address before issuing them an email certificate?

- Which exact section contains an undertaking to confirm that the application has control of a domain name before issuing them an SSL certificate?

- (If applicable) Which exact section contains an undertaking that the applicant's identity is strongly validated before issuing them a code signing certificate?

Can you point me at the correct sections for each of these cases?

I realise you have a large number of CP and CPS documents. It would help to get some understanding of how they relate, and whether we would need to look for this information in every document/issuance policy or not.

Gerv

Comment 10

[Istvan Zsolt BERTA]

1. Website of the National Communications Authority

The National Communications Authority used to have a website with a different design that included the database. The old design has been changed and the current lists now come from a machine called 'oldweb'.
I understand your concerns, the address is really awkward, but the lists I provided are the current ones.

On how to get there: The website of the National Communications Authority is www.nhh.hu. In order to obtain e.g. the list of Hungarian CAs issuing qualified certificates, you have to click on "Elektronikus aláírás, elektronikus hirdetés" (e-signature, e-advertisement) in the menu on the left, then select "Elektronikus aláírás - nyilvántartások" (e-signature - registry), then click "Szolgáltatók, termékek, tanúsítók, szakértők" (service providers, products, experts) in the main area, and finally "Minősített szolgáltatók" (qualified service providers) on the new menu on the left.


2. Our CA hierarchy

I shall attach our current CA hierarchy to this bug. This hierarchy contains all or our CA and TSA certificates that can be verified using Microsec e-Szigno Root CA.


3. Language of our CPs and CPSs and correspondence to RFC 3647

Our CP/CPS is available in Hungarian only. All of our CPs and CPSs follow the structure of RFC 3647. We had to demonstrate it during our audit, so we prepared a table for this purpose. We have decided not upload it to this bugzilla, but we uploaded it to our web server, and we would like to remove it after this procedure is over if possible.
This table is temporarily available at:
https://srv.e-szigno.hu/MicrosecCPs--RFC3647.pdf

Our CAs issuing end-user certificates issue a CRL every day (i.e. in every 24 hours). In case of a revocation they also issue an extra CRL in an hour.

Our root (Microsec e-Szigno Root CA) issues a CRL every month (i.e. in 30 or 31 days). An extra CRL is issued in case of a revocation.

(We also have another root (e-Szigno OCSP CA) that we do not wish to have included in Mozilla, it issues OCSP responder certificates only. These certificates have a very short lifetime of 10 minutes, and they contain OCSP-nocheck, so this CA does not issue CRLs.)


4. Why are there so many CPs and CPSs?

The National Communications Authority requires us to have a separate documentation on:
1. certificates for qualified electronic signatures,
2. certificates for non-qualified electronic signatures,
3. certificates for purposes other than electronic signatures (e.g. for encryption, authentication, for web servers, etc.)

Thus, we have a separate CPS for each. We were allowed to have a common CP for (2) and (3) but we needed a separate CP for (1). These documentation are very similar (they are around 80% the same) and have a similar structure.
The CPSs contain all statements and criteria in the CPs.
The three CPS are:
-qualified: http://www.e-szigno.hu/docs/szsz--hsz--minositett--v4.1.pdf
-non-qualified: http://www.e-szigno.hu/docs/szsz--hsz--fokozott--v1.1.pdf
-other than signature: http://www.e-szigno.hu/docs/szsz--hsz--altalanos--v1.0.pdf

The Hungarian public administration has recently elaborated a set of specifications for using PKI within the Hungarian public administration. This set of specifications includes certain CPs that CAs need to support.
These documentation are not 'our' CPs, they are third party CPs that we support using our CPSs. 
http://www.e-szigno.hu/docs/mhr_v14_e.pdf
http://www.e-szigno.hu/docs/ehr+_v14_e.pdf
http://www.e-szigno.hu/docs/ehr_v14_e.pdf


5. Verification of the information and financial liability

We have the following generic statement in Section 4.2 (where the steps of the processing of a certificate request are described) of all our CPSs: 

	-The subject/signatory notifies the CA that a certificate is requested, and provides his or her data to the CA, and authorizes the CA for handling his or her data for the purpose of issuing the certificate.
	-The CA verifies the information provided by the Subject/Signatory, especially those pieces of information that are to appear in the certificate.

In Hungarian:
	"-Az Alany/Aláíró jelzi a Szolgáltatónak, hogy tanúsítványt szeretne, eljuttatja adatait a Szolgáltató ügyfélszolgálati irodájának, és felhatalmazza a Szolgáltatót, hogy adatait a tanúsítvány kibocsátásának céljából kezelje.
	-A Szolgáltató ellenőrzi a megadott információkat, különösen azokat, amelyeket a tanúsítványban is szerepeltetnie kell."
	
The detailed steps of the verification of this information is not detailed in our public documents, except for the name of the subject/signatory and that of the organization of the subject/signatory, because these are especially critical points in the legislation.

In case of qualified certificates, we are legally obliged to perform a face-to-face registration of the Subject/Signatory.

In case of non-qualified certificates, we offer class2 and class3 certificates.
In case of class3 non-qualified certificates, the registration procedure is exactly the same as in case of qualified certificates (i.e. a face-to-face registration is performed).
In case of class2 non-qualified certificates, a remote registration is performed, where the e-mail address of the subject/signatory is verified.

We issue secure-email certificates as both class2 and class3.
We issue web server certificates and code signing certificates as class3 only. 

Web server and code-signing certificates are covered in 
http://www.e-szigno.hu/docs/szsz--hsz--altalanos--v1.0.pdf
The procedure of identity validation is described in Section 3.2.


According to Hungarian (and European) regulations, we are financially responsible for the certificates we issue. If we commit a mistake concerning a certificate (e.g. we represent wrong information in it or we do not revoke it according to our CPS) we have to cover the resulting damage at any relying party.
We are allowed to limit this responsibility. In case of qualified certificates, the limit of our financial responsibility appears in the certificate, it can have a maximum value of 200 million HUF (~ 1 million USD). In case of class3 non-qualified certificates, this limit is 100 000 HUF (~500 USD). In case of class2 non-qualified certificates, this limit is zero.
If multiple relying parties suffer damage within these limits, we have to cover the damage multiple times.

Liability issues are covered in Sections 1.4 and 9.2.7 of our CPSs.

Thus, we have undertaken not to issue certificates 
-with e-mail addresses that do not belong to the subject/signatory,
-with web addresses that do not belong to the subscriber, 
-for code signing without registering the subscriber,
-etc.
And we are financially responsible if we still do so.


I think I have touched all the points you requested, please let me know if I left something out.

István

Comment 11

[Istvan Zsolt BERTA]

Attachment: CA hierarchy of Microsec Ltd. (with respect to Microsec Root CA) as of 2007-06-08

Comment 12

[Gervase Markham [:gerv]]

> The detailed steps of the verification of this information is not detailed in
> our public documents, except for the name of the subject/signatory and that 
> of the organization of the subject/signatory, because these are especially
> critical points in the legislation.

So, to be absolutely clear: you are saying that your CPSes do not include sufficient detail to allow me to confirm by reading it that you do the policy section 7 checks I referred to in comment 9?

Can you confirm unambiguously that you do do such checks, with reference to email certificates and SSL certificates? (You have stated that you do for class 2 NQ certificates, and it seems that you do for the rest, but I want to be clear.)

If you can confirm that, would it be possible to update the CPSes to state this explicitly?

Are you able to provide an English translation of section 3.2 of
http://www.e-szigno.hu/docs/szsz--hsz--altalanos--v1.0.pdf
?

Gerv

Comment 13

[Istvan Zsolt BERTA]

> So, to be absolutely clear: you are saying that your CPSes do not include
> sufficient detail to allow me to confirm by reading it that you do the policy
> section 7 checks I referred to in comment 9?

I agree that we could have been more specific on the details of the verification.

> Can you confirm unambiguously that you do do such checks, with reference to
> email certificates and SSL certificates? (You have stated that you do for 
> class 2 NQ certificates, and it seems that you do for the rest, but I want to 
> be clear.)

Yes, I confirm that 
	-in case of email certificates we check that the applicant controls the email address;
	-in case of SSL server certificates we check that the applicant is the owner of (or is propery authorized by the owner of) the corresponding domain;
	-in case of code signing certificates, we thoroughly verify the identity of the applicant, we verify the identity of both the person and the organization
before we issue the certificate. We do the above for all certificates we issue.

We are ready to sign an official letter confirming the above.

> If you can confirm that, would it be possible to update the CPSes to state 
> this explicitly?

Yes, we shall also include these in our CPSes. Unfortunately, the procedures for modifying our CPSes are long and bureaucratic. We have a scheduled update around October, I do not think we could perform the update earlier.

Do you think it would be possible to proceed now based on a confirmation letter?



The English translation of section 3.2 of
http://www.e-szigno.hu/docs/szsz--hsz--altalanos--v1.0.pdf
is as follows. (I apologize, because the translation is sometimes very awkward, just like the original text.)


3.2. Initial verification

3.2.1 Possession of the private key

In case of class 3 certificates, there are two possibilities:
- If the certificate is issued on a smart card, the CA generates the private key for the certificate, and gives it to the subject together with the smart card.
- If the CA does not provide a smart card for the certificate then the private key is generated by the subject. The subject provides the public key to the CA along with a password. The subject has to provide the same password at the time of registration, this password proves that he or she was the one who submitted the public key. 
[This is a one-time password, it is not used ever again.]

In case of class 2 certificates, a remote registration takes place. The subject has to send a copy of his or her id cards to the CA, and thus proves that he or she was the one who submitted the public key [along with the registration information].


3.2.2. Authentication of organization identity

In case of organizational certificates, the organization of the subject is also represented in the end-user certificate. In these cases the CA issues the certificate with the approval of the represented organization only. (Later, the CA suspends or revokes these certificates on the request of the represented organization.)

During the process of the registration or the later replacement of a certificate, the client [i.e. the subscriber and the subject] needs to provide information and evidence on the following:

- name and address of the organization,
- name of an organization unit if an organization unit is requested to appear in the certificate,
- the role of the subject within the organization [i.e. the title field, if any],
- the official id information of the organization [e.g. the registry number of a company within the Hungarian firm registry database]
- an official certification claiming that the one signing the contract with the CA on behalf of the subscriber is authorized for doing so,
[In Hungary, notaries can provide such statements.]
- if the represented organization is member of the Hungarian public administration, and if it is required by a CP that applies to the certificate, 
than the natural person representing the public body has to provide an official certification. This certification needs to be in form of a 'public document' [this has the highest probative force in the Hungarian jurisdiction], it needs to contain the name of the public body, and it needs to authorize this natural person for representing the public body at the CA.
- if the represented organization is not a member of the Hungarian public administration, but [the client] would like to have a certificate usable in the context of the Hungarian public administration, than it needs to provide a certification signed by a person who is allowed to sign on behalf of the organization. This certification needs to cotain the name of this organization, and needs to authorize the applicant for representing this organization at the CA.
- a certification proving that the represented organization is a real, existing organization.

A notarial deed (or an equivalent document) confirming the name and handwritten signature of the person who signs on behalf of the represented organization needs to be provided too. A document authenticating the organization needs to be attached too. In case of companies registered at the registry courts, the above documents can be obtained by the CA too.

The CA verifies the validity of the collected documents, and verifies their validity in public databases. The CA denies the issuance of the certificate, if:
- some information is missing,
- there is any doubt concerning the originality or validity of the provided documents,
- there is any doubt concerning the subjects association with the represented organization,
- the identity of the organization cannot be verified without doubt,
- any doubt arises concerning the above documents when verifying their validity in public databases,
- the authorization of the represented organization is not unambigous, 
or the applicant did not provide any missing or incorrect documents within the deadline provided by the CA.


3.2.3 Authentication of individual identity

In case of class 3 certificates and certificates conforming to public administration CPs, the subject needs to appear personally before the registration officer of the CA. This requirement can also be fulfilled by a notary certifying the identity of the subject. If the identity of the subject is verified by the registration officer of the CA, then this verification generally takes place in the registration office of the CA, but may also takes place in front of a mobile registration unit. The CA consideres registration at the registration office and at a mobile registration unit equivalent in all cases.

The CA accepts the following documents for the verification of subject identity:
-Hungarian ID card,
-passport,
-driving license.

The subject needs to prove his or her identity with at least one of these documents. If an applying [public administration] CP requires additional documents (e.g. an ID card proving the address of the subject), then the CA also asks for these documents.

The presented documents needs to be original, real and valid. These documents are verified by the registration officer of the CA who is trained for verifying these types of documents. The registration officers also verifies the validity of these documents in the Registry of Persons and Addresses, Registry of Passports or Registry of Driving Licenses.

At registration, the subject verifies the correctness of the registered data with his or her handwritten signatures. The registration officer also signs that the photograph of the subject on the provided ID card corresnponds to the face of the subject and the signature of the subject corresponds to the signature on the ID card.

The CA provides 'reverse identification' service (see Section 4.13) with respect to the certificate , if a corresponding [public administration] CP requires it. 
['Reverse identification' is a procedure for linking a certificate with a natural person in the context of the Hungarian public administration.]
In case of certificates for representing public bodies, the CA notifies the represented organization of the fact that the certificate was issued, but does not provide the personal information of the subject.


In case of class 2 certificates, the subject needs to send a photocopy of his or her documents to the CA. (If the subject does not want the CA to possess a copy of his or her documents, he/she can also prove his/her identity using the procedures of class 3 certificates.) The CA accepts the following id cards:
-Hungarian ID card,
-passport,
-driving license.
In case of class 2 certificates the CA reserves the right to accept other types of id cards too.

The CA verifies the identity of foreign [i.e. non-Hungarian] citizens using a passport or other id document suitable for personal identification [(this term refers to a certain regulation)], and also verifies data based on a database of the corresponding country. Additional information may be neccessary for the thorough verification of a foreign passport or for connecting to a database in a foreign country. The procedure may require cooperation with the embassy of the foreign country or the diplomatic certification of the passport. Guidelines for aquiring such information are discussed in the internal policies of the CA.
The CA refuses to issue the certificate if based on its internal policies it decides it cannot verify the ID document issued outside Hungary or it cannot verify the data of the foreign person.

3.3. Renewal of a valid certificate

The CA renews a certificate if the subject claims in writing that the information in his currently valid certificate are still valid, and would like to have his or her certificate renewed.

3.4. Replacement of an invalid certificate

It is not possible to renew an invalid certificate in a remote (or purely electronic) way. Invalid certificates can be replaced with a procedure similar to that of requesting a new certificate.

3.5. Request for revocation or suspension

Authentication of such requests is discussed in Section 4.9.

Comment 14

[Gervase Markham [:gerv]]

Istvan: thank you very much for your lengthy reply. 

If you are committing to update your public CPS to contain the necessary information, and will do so in October, then I would be happy to proceed on the basis of an interim confirmation letter. It is important that this information is eventually public, but I don't want to let the difficulty of updating CPSes (which I can see, in your complex and regulated case, might take a while) block the process.

Please prepare the official letter. It would probably be best if you emailed me a draft of the text so I can make sure it's OK. Then, you can attach a scanned copy here and send the original to my postal address, which I will give you during our email conversation. Once the letter is done, I should be able to approve your application.

Again, thank you for your cooperation.

Gerv

Comment 15

[Gervase Markham [:gerv]]

Istvan: have you had any success getting the interim letter prepared?

Gerv

Comment 16

[Istvan Zsolt BERTA]

Yes, I have prepared the letter and sent it to your e-mail address [e-mail] on the 6th of July. (I sent it from [e-mail].)

I have resent it right now.

Please let me know if it arrived.

István

Comment 17

[Istvan Zsolt BERTA]

Attachment: commitment of Microsec Ltd.

Comment 18

[Istvan Zsolt BERTA]

I have attached a scanned copy of our letter. I have sent the original letter to the address you provided.

István

Comment 19

[Gervase Markham [:gerv]]

I'm afraid I'm on holiday for the next two weeks, so no more will happen here until after that. My apologies :-(

Gerv

Comment 20

[Gervase Markham [:gerv]]

I can confirm that I have received the hard copy of the Microsec commitment letter. 

Unfortunately, there is a further problem. Your audit document:
http://www.e-szigno.hu/docs/NhhCertification.pdf is now a 404. Also, since we discussed the audit requirement, we have had some difficulty with vagueness about audits in the case of some other CAs. So we are now absolutely insisting that the audit statement be presented by the auditor in a way which makes it possible to verify that it's a true statement definitely from the auditor. Consequently, we are not generally accepting self-hosted audit statements.

Please can you look into asking the National Communications Authority to put the audit document up on their website?

Gerv

Comment 21

[Istvan Zsolt BERTA]

We had our website restructured, and the document was not available for a few days. This was an error, we had no intention to remove it.
We had this problem fixed, the document is available again.


We have absolutely no control over the website of the National Communications Authority. If they have not published this document on their website, we cannot make them do so. 
They are obliged to maintain and publish a registry of Hungarian CAs, and are also obliged to audit and supervise them. 
The list of Qualified CAs is available at:
http://webold.nhh.hu/esign/szolgParams/main.do
and the list of non-qualified CAs is available at:
http://webold.nhh.hu/esign/szolgParams/main.do
These pages are currently in English. 
(They also had their website restructured recently.)
Some additional information is available in English at:
http://webold.nhh.hu/esign/
The above registry contains the information the law requires this authority to  publish, and I do not think that they could include anything else in this registry.

I can offer you the following:
-I can send you the original document by post.
-You can verify this document by independently contacting Dr. Nóra Sylvester, Director of Informatics Regulation at the National Communications Authority, who issued it.

Unfortunately, we cannot help you by changing the website of our supervisory authority.

István

Comment 22

[Gervase Markham [:gerv]]

(In reply to comment #21)
> We have absolutely no control over the website of the National Communications
> Authority. If they have not published this document on their website, we cannot
> make them do so. 
> They are obliged to maintain and publish a registry of Hungarian CAs, and are
> also obliged to audit and supervise them. 

But surely they are also required to confirm the names of those CAs who have passed the audits (and those who have failed) to anyone who wants to know? Otherwise, there seems no point in doing an audit. How do they do this, if it's not by posting the audit report on their website?

> The list of Qualified CAs is available at:
> http://webold.nhh.hu/esign/szolgParams/main.do
> and the list of non-qualified CAs is available at:
> http://webold.nhh.hu/esign/szolgParams/main.do
> These pages are currently in English. 

Unless I have misread that page, this is a list of people or organisations who have notified them that they have started issuing certificates (i.e. a register). It doesn't say anything about audits.

> I can offer you the following:
> -I can send you the original document by post.
> -You can verify this document by independently contacting Dr. Nóra Sylvester,
> Director of Informatics Regulation at the National Communications Authority,
> who issued it.

Can you give me contact details for Dr Sylvester?

Gerv

Comment 23

[Istvan Zsolt BERTA]

(In reply to comment #22)
> Unless I have misread that page, this is a list of people or organisations who
> have notified them that they have started issuing certificates (i.e. a
> register). It doesn't say anything about audits.

The procedure for registering a qualified CA is basicly the following:
The CA notifies NHH of starting the new service, and submits a set of documentation supporting the fact that the CA fulfils the corresponding requirements. This documentation includes an audit report from a registered electronic signature expert. (This registry is also maintained by NHH.)
NHH registers the CA based on the submitted documentation, but NHH is required to perform an audit of the CA within 30 days, and this audit has to be repeated every year. NHH has the right to remove the CA from registry.


> Can you give me contact details for Dr Sylvester?

I have sent you her e-mail address by e-mail. (I have decided not to post it into the bugzilla.)

István

Comment 24

[Istvan Zsolt BERTA]

We have updated our CPS-s as we promised in our commitment letter. The required update is in Section 4.2 of the documents. For example, our CPS at
http://srv.e-szigno.hu/menu/docs/szsz--hsz--altalanos.pdf
contains the required statements on page 37, bullets 7, 8 and 9. 
The rest of our CPS-s do not deal with webserver and code signing certificates, they contain the statement on the verification of e-mail addresses only.

I would like to ask you if you had any success in contacting Dr Sylvester at NHH based on the contact I have sent you in e-mail.

István

Comment 25

[Gervase Markham [:gerv]]

Reassigning all open CA certificate inclusion request bugs to Frank Hecker, who is currently running the root program.

Gerv

Comment 26

[Istvan Zsolt BERTA]

Dear Frank, Dear Gerv,

I would like to ask you of the status of our request and if you are expecting any further information from us.

We have provided you with a letter from our supervisory authority - the National Communication Authority of Hungary - certifying that they have audited us according to the criteria of ETSI TS 101 456 and they repeat this audit on a yearly basis.
We have published the letter of the authority on our own website.
As our auditor is an authority, we cannot make them publish this letter on their website. In fact, we cannot make them publish (or do) anything more than what is stated in legal regulations (e.g. the Hungarian act on electronic signatures).
We have provided you with contact (via personal e-mail) to Dr. Nóra Sylvester of the National Communications Authority to verify the validity of this letter.

We have provided you with the required information on our policies and practices, and we have updated our certificate practice statements to explicitly include necessary statements e.g. on the verification of e-mail addresses.

Please let us know if you are waiting for additional information. In case you decide to reject our request, please state it, so that we can make our plans accordingly.

Thanks,

István

Comment 27

[Nelson Bolyard (seldom reads bugmail)]

According to http://www.mozilla.org/projects/security/certs/pending/ 
as of this date, the status of this request is: Information confirmed complete	

Comment 28

[Istvan Zsolt BERTA]

Thank you very much for the information, we are glad to hear that everything is allright.

Could you provide any information on the date of the inclusion of our root in the Mozilla certificate repository? We need this information for planning our future movements.

Thanks,

István

Comment 29

[Istvan Zsolt BERTA]

We have updated our English website, now many pages are available in English too. The urls I provided before still work, but they point to Hungarian pages. Now we have better ones.

A chart of our CA hierarchy and our CA certificates are available here:
http://srv.e-szigno.hu/menu/index.php?lap=english_ca_hierarchy

A page containing links to our CRLs is available here:
http://srv.e-szigno.hu/menu/index.php?lap=english_crl

Our CPs and CPSs can be downloaded from here:
http://srv.e-szigno.hu/menu/index.php?lap=english_dokszab
(unfortunately, the documents are still in Hungarian only)

Could you provide any information on when our roots could be included in Mozilla?

István

Comment 30

[Frank Hecker]

I'm assigning this bug to Kathleen Wilson, who will be collecting any other needed information relating to this request.

Comment 31

[Kathleen Wilson]

Attachment: Summary of Info Gathered as of 6/12/2008

As per Frank’s note, I have been asked to complete the info-gathering/verification phase of this request.  As such, I follow a template for gathering and summarizing the necessary information. The attached document shows the current status, and provides background for my questions.

1) Are the SSL certificates that chain up to this root both DV and OV?  By DV I mean that the domain name referenced in the certificate is verified to be owned/controlled by the certificate subscriber. OV means that the Organization attribute is verified to be that associated with the certificate subscriber.

2) Please provide the url to a website whose ssl certificate chains up to this root (can be either a test or live site).

3) Could you please provide the English translation for the sections that were added to the CPS in regards to Comment #24: “We have updated our CPS-s as we promised in our commitment letter. The required update is in Section 4.2 of the documents. For example, our CPS at http://srv.e-szigno.hu/menu/docs/szsz--hsz--altalanos.pdf contains the required statements on page 37, bullets 7, 8 and 9.”

4) This question is for Gerv or Frank: Has the NHH audit been verified?

5) I’m supposed to review the CP/CPS for potentially problematic practices, as per http://wiki.mozilla.org/CA:Problematic_Practices. Since the CPS is not in English, would you please comment as to whether any of these are relevant. If relevant, please provide further info:
•	Long-Lived Domain-Validated SSL certs 
•	Wildcard DV SSL certs
•	Issuing end entity certs directly from root rather than using an offline root and issuing certs through a subordinate CA 
•	Allowing external entities to operate subordinate CAs – in this case need to demonstrate that the external entities are required to follow the CPS and are audited as such.

Thanks,
Kathleen

Comment 32

[Istvan Zsolt BERTA]

> 1) Are the SSL certificates that chain up to this root both DV and OV?  By DV 
> I mean that the domain name referenced in the certificate is verified to be
> owned/controlled by the certificate subscriber. OV means that the Organization
> attribute is verified to be that associated with the certificate subscriber.

Yes, we verify both the domain name and the organization before we issue the certificate.


> 2) Please provide the url to a website whose ssl certificate chains up to this
> root (can be either a test or live site).

For instance:
https://www.magyarorszag.hu/
and our own website
https://www.e-szigno.hu/


> 3) Could you please provide the English translation for the sections that were
> added to the CPS in regards to Comment #24: “We have updated our CPS-s as we
> promised in our commitment letter. The required update is in Section 4.2 of 
> the documents. For example, our CPS at
> http://srv.e-szigno.hu/menu/docs/szsz--hsz--altalanos.pdf contains the 
> required statements on page 37, bullets 7, 8 and 9.”


Bullets 7, 8 and 9 on page 37 have been added, they can be translated as follows:

"
* In case the Subjects requests a certificate containing an e-mail address, the CA verifies this e-mail address before the certificate is issued. The CA verifies that the address is indeed an existing e-mail address, and also verifies that the e-mail address is indeed the e-mail address of the Subject.

* In case of SSL certificates for servers (webserver certificates), before issuing the certificate the CA verifies that the address or domain to appear in the server certificate is indeed owned by the Subject, or the Subject possesses a written statement that entitles the Subject for requesting an SSL certificate for the given address or domain.

* Certificates suitable for signing computer programs (known as code signing certificates) are issued as Class 3 only, this means the CA verifies using a face-to-face registration both the identity of the Subject and/or represented organization and the fact that the public key to appear in the certificate is controlled by the Subject. 
"

> 4) This question is for Gerv or Frank: Has the NHH audit been verified?

Just in case, I shall send you the e-mail address of Dr. Nóra Sylvester of NHH to you by e-mail. I would like to avoid posting it on a public website if possible.


> 5) I’m supposed to review the CP/CPS for potentially problematic practices,
> as per http://wiki.mozilla.org/CA:Problematic_Practices. Since the CPS is not
> in English, would you please comment as to whether any of these are relevant.
> If relevant, please provide further info:
> •     Long-Lived Domain-Validated SSL certs 
> •     Wildcard DV SSL certs
> •     Issuing end entity certs directly from root rather than using an
> offline root and issuing certs through a subordinate CA 
> •     Allowing external entities to operate subordinate CAs – in this case
> need to demonstrate that the external entities are required to follow the CPS
> and are audited as such.


* Long-Lived Domain-Validated SSL certs

We issue certificates for 2 years, and if the Subject requests the renewal of the certificate (with a procedure similar to the first registration) we renew the certificate for the same keypair for another 2 years. Any further certificates are issued for another keypair.

This is regulated in Section 6.3.2. of our CPS at
http://srv.e-szigno.hu/menu/docs/szsz--hsz--altalanos.pdf
This says that the overall validity of all certificates issued to a given keypair cannot be more than 4 years. Theoretically we could issue certificates for 4 years, but we would prefer not to do so.
Our DV certificates are also OV.


* Wildcard DV SSL certs

We do issue wildcard DV certificates. We do not have  regulations specific to wildcard certificates.
Our DV certificates are OV too.


* Issuing end entity certs directly from root rather than using an offline root and issuing certs through a subordinate CA

Not applicable, we do not issue end entity certificates with our root. We have a figure on our website illustrating which CA issues what kind of certificates in our hierarchy:
http://srv.e-szigno.hu/menu/index.php?lap=english_ca_hierarchy
This is regulated in Section 1.3.1 of our CPSs.


* Allowing external entities to operate subordinate CAs

Currently there are no external entities who operate CAs subordinated to us.

Section 1.3.2 of our CPS at 
http://srv.e-szigno.hu/menu/docs/szsz--hsz--altalanos.pdf
allows us to have some in the future, and describes some general guidelines:
- There needs to be a contract between us and the subordinated CA that regulates the conditions of subordination. 
- We are responsible for the activities of any subordinated CA.
- The subordinated CA may issue certificates for the community defined in the contract.
- The subordinated CA must publish its CP, and operate accordingly. We audit their activity.
- We revoke the certificate of the subordinated CA if the subordinated CA does not operate according to its own CP or if we learn that its key was compromised.
- The subordinated CA may not issue certificates that are to be used in context of the Hungarian public administration.

Section 1.3.2 of our CPS that are used for certificates suitable for creating electronic signatures defines additional criteria:
- We need to notify our supervisory authority, NHH if we issue a CA certificate.
- The subordinated CA must become a CA registered by NHH. (And thus must undergo the same audit and must fulfill the same criteria that we fulfill.)

Please let me know if you need any further information.

Thanks,

István

Comment 33

[Gervase Markham [:gerv]]

> 4) This question is for Gerv or Frank: Has the NHH audit been verified?

I don't remember doing it, and I think Frank would have said if he had. Probably best to re-contact NHH in any case.

Gerv

Comment 34

[Kathleen Wilson]

I have recieved inquiries about the status of this request via email, so I will post a status update here.

All of the information has been confirmed to be complete, with the exception of the verification of the authenticity of the audit report. I have not been able to get response from the auditor, Dr. Nóra Sylvester of NHH. István, please let me know if you think I should try to contact someone else at NHH, and email the contact info to me.

Thanks,
Kathleen

Comment 35

[Istvan Zsolt BERTA]

> the verification of the authenticity of the audit report. I have not been able
> to get response from the auditor, Dr. Nóra Sylvester of NHH. István, please
> let me know if you think I should try to contact someone else at NHH, and email

She is the right person. My colleagues were unable to contact her either yet, the only possible reason for this can be the various holidays both at us and at NHH. I shall write you as soon as I learn something.
I apologize for this delay.

István

Comment 36

[Kathleen Wilson]

Attachment: Completed Information Gathering Document

The audit has been confirmed, thus completing the information gathering phase.

Comment 37

[Kathleen Wilson]

Assigning to Frank so he can proceed with the public discussion phase in processing this request.

Comment 38

[Istvan Zsolt BERTA]

I would like to ask you when and how the public discussion phase shall take place.
Thanks,

István

Comment 39

[Istvan Zsolt BERTA]

I would like to ask you if there had been any progress concerning the public discussion phase of our inclusion request.
Thanks,

István

Comment 40

[Frank Hecker]

I'm sorry for the delay. I have been working to transition some of my job responsibilities to the new executive director of the Mozilla Foundation. In the next week or two we will begin a schedule of public comment periods for CAs. Since Microsec's request is so old, it will be among the first CAs considered.

Prior to beginning the public comment period, I have a question and a comment:

First, the statement from NNH attached to this bug dated December 2006. Is there a more recent statement that you have and can provide to us? As I understand it, this audit is done annually; since Microsec is still listed on the NHH site, and Kathleen corresponded with NNH on this issue recently, I presume that the audit was successfully completed. However if you have the actual statement that would be useful.

Second, in comment #32 you mentioned "We do issue wildcard DV certificates. We do not have  regulations specific to wildcard certificates. Our DV certificates are OV too." We use the term "DV" to refer to SSL certificates for which *only* control of the domain is verified; in other words, the CA does not verify the actual identity of the domain owner. Based on your comment I suspect that your wildcard certificates are actually for OV certificates, i.e., certificates for which the identity of the certificate applicant is verified.

Comment 41

[Istvan Zsolt BERTA]

(In reply to comment #40)
> CAs. Since Microsec's request is so old, it will be among the first CAs
> considered.

Thank you very much, we are looking forward to continuing the process. We are under heavy pressure from our clients and also from the general public in Hungary to support Mozilla products. We issued the SSL certificate from the Hungarian governmental portal magyarorszag.hu, and there are a lot of complaints saying that Mozilla browsers pop up warning messages.

Please let us know if there is any progress in this matter.

> Prior to beginning the public comment period, I have a question and a comment:
> 
> First, the statement from NNH attached to this bug dated December 2006. Is
> there a more recent statement that you have and can provide to us? As I

Yes, there is. It is available on our website at:
http://www.e-szigno.hu/docs/NhhSupervision2008.pdf

> Second, in comment #32 you mentioned "We do issue wildcard DV certificates. We
> do not have  regulations specific to wildcard certificates. Our DV certificates
> are OV too." We use the term "DV" to refer to SSL certificates for which *only*
> control of the domain is verified; in other words, the CA does not verify the
> actual identity of the domain owner. Based on your comment I suspect that your
> wildcard certificates are actually for OV certificates, i.e., certificates for
> which the identity of the certificate applicant is verified.

OK, I understand. Thank you.

Please let me know if you need any further information.
Thanks,

István

Comment 42

[Frank Hecker]

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

Public discussion will be in the mozilla.dev.tech.crypto newsgroup and the corresponding [e-mail] mailing list:

http://www.mozilla.org/community/developer-forums.html
https://lists.mozilla.org/listinfo/dev-tech-crypto

This first public comment period will be for one week, and then I'll make a preliminary determination regarding this request.

P.S. My apologies for misspelling "Microsec" as "Microtec" in the subject line of my newsgroup post.

Comment 43

[Istvan Zsolt BERTA]

Attachment: our CPS for non-qualified certificates for purposes other than creating electronic signatures (e.g. for encryption, authentication, web servers, code signing) in TXT format

I am attaching a txt version of one of our CPSs, as I promised in the public discussion at
http://groups.google.com/group/mozilla.dev.tech.crypto/browse_thread/thread/416427a350db11a9#

(I still have strong doubts about the usefulness of a machine translation.)

Comment 44

[Istvan Zsolt BERTA]

Dear Frank,

I would like to ask you when our public discussion period is going to be restarted.

As I see, we have reached an agreement in the open questions, including the OCSP issue.

Have you had any success in the machine translation of the CPSs I provided?

Thanks,

István

Comment 45

[Istvan Zsolt BERTA]

Dear Frank,

I would like to ask you if you have any information on the time of the restarting of our public discussion period.
Thanks,

István

Comment 46

[Istvan Zsolt BERTA]

Dear Frank,

We had a discussion with Eddy here
http://groups.google.com/group/mozilla.dev.tech.crypto/browse_thread/thread/26279214cda375a7/9fc91a0802831988
and I also read the updated schedule for evaluations
https://wiki.mozilla.org/CA:Schedule

Do we need to submit an English translation of our CPS?
(If yes, we have no problem with it, and we can initiate the translation process, but please say so.)

Thanks,

István

Comment 47

[Istvan Zsolt BERTA]

Dear Kathleen,

According to your request, we have prepared the translation of our CPS, please find it at
http://www.e-szigno.hu/docs/szsz--hsz--altalanos--v1.6--EN.doc
This is the translation of the CPS we use for web server certificates, code signing certificates, e-mail encryption certificates and SSL client certificates. Our other CPSs - that we use for qualified and non-qualified electronic signature certificates - have very similar contents, but we were required to create separate CPSs for them. Our CPS is currently being modified, this is the translation of version 1.6 that will come into effect on the 9th of March, 2009. 

Please note that the translation was created by translators, and not by PKI professionals. The translation was created by KFI Translations Office (http://www.kfi.hu).

The procedure for the verification of the subscriber identity/organization is discussed in Sections 3.2 and 4.2. The issuing frequency of CRLs is discussed in Section 4.10.

Regards,

István

Comment 48

[Kathleen Wilson]

I am now opening the second public discussion period for this request from Microsec to add the Microsec e-Szigno Root CA root certificate to Mozilla.

http://groups.google.com/group/mozilla.dev.tech.crypto/browse_thread/thread/a61cf6986dd16b6e#

The discussion topic is: Microsec Root Inclusion Request Round 2

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

Comment 49

[Eddy Nigg (StartCom)]

Attachment: PDF Version

Comment 50

[Frank Hecker]

Re-assigning this bug to Kathleen Wilson, since she's the person actively working on it.

Comment 51

[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 a new root CA certificate for Microsec e-Szigno Root CA. 

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.  This document has been translated into 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]. 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 e-Signatures register. Additionally, the Directorate of Informatics Regulation of the National Communication Authority has provided an audit statement.

Section 13 [Certificate Hierarchy]. This root, Microsec e-Szigno Root CA, has internally-operated subordinate CAs based on the different classes and types of end-entity certificates. There are three subordinate CAs for different types of Qualified certificates, including a Microsec e-Szigno Server CA. There are also subordinate CAs for authentication certificates for the public administration, encryption certificates for the public administration, non-qualified signature certificates, and non-qualified timestamp certificates. The request is to enable all three trust bits.

Other: Microsec issues its CRL every 24 hours.

Potentially problematic practices: 
* There was a concern about the Microsec practice of having a separate root for OCSP, particularly given the inclusion of AIA extensions with OCSP URLs in end entity certificates. Microsec is removing AIA extensions with OCSP URLs from end entity certificates and from intermediate CA certificates, and this should address this problem going forward. Microsec’s long-term plan is to introduce an OCSP service that is usable for the general public, such that it does not require authentication and works using the 'authorized responder' concept. They already had a discussion with the National Communications Authority, so they will be able to issue OCSP responder certificates with their CAs, even with CAs that sign qualified certificates.

Based on this assessment I recommend that Mozilla approve this request to add the Microsec e-Szigno Root CA Certificate Authority root certificate to NSS.

Comment 52

[Frank Hecker]

To Kathleen: Thank you for your work on this request.

To Mr. Berta and other representatives of Microsec: Thank you for your cooperation and your patience.

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

I have reviewed the summary and recommendation in comment #51, and on behalf of
the Mozilla project I approve this request from Microsec to add the following root certificate to NSS, with trust bits set as indicated:

* Microsec e-Szigno Root CA (email, SSL, code signing)

Kathleen, could you please do the following:

1. File the necessary bug against NSS.
2. Mark this bug as dependent on the NSS bug.
4. When that bug is RESOLVED FIXED, change the status of this bug to RESOLVED
FIXED as well.

Thanks in advance!

Comment 53

[Nelson Bolyard (seldom reads bugmail)]

As a test, I downloaded the root CA cert from 
http://www.e-szigno.hu/RootCA.crt (per comment 0) and tried to visit 
https://www.magyarorszag.hu/      (per comment 32).
I got an error page saying:

> Secure Connection Failed
> 
> An error occurred during a connection to www.magyarorszag.hu.
> 
> The OCSP server found the request to be corrupted or improperly formed.
> 
> (Error code: sec_error_ocsp_malformed_request)
> 
> The page you are trying to view can not be shown because the authenticity
> of the received data could not be verified.
> 
> * Please contact the web site owners to inform them of this problem.

If this is typical of what FF users can expect for https sites with certs 
from this issuer, does Mozilla really want to OK that root at this time?

Comment 54

[Eddy Nigg (StartCom)]

This is very unfortunate and I confirm seeing the same error.

Comment 55

[Kathleen Wilson]

I believe the problem has been resolved, but the ssl certificate for that website hasn’t been updated.

In the discussion
http://groups.google.com/group/mozilla.dev.tech.crypto/browse_thread/thread/416427a350db11a9#
On October 13, 2008, István wrote:
---
> I think we have a problem here! I wanted to make sure that the CA root 
> and intermediate CA certificates don't include OCSP AIA extensions and I 
> noticed the following when importing and examining the CA root... 
In fact, our intermediate CA certificates also included an OCSP AIA 
extension. 
As we promised, we have updated the profile of our webserver 
certificates, so now we do not include an OCSP URL in the AIA field. 
We have also updated our CA certificate we use for issuing webserver 
certificates, so now it does not include an OCSP URL either. 
See https://www.e-szigno.hu as an example. 
(Now this server also presents the certificate chain.) 
---

I have tried https://www.e-szigno.hu with OCSP enforced, and it works for me.  I can also see that the ssl cert was issued on 10/13/2008, and that it does not contain the OCSP URI in the AIA field.

The ssl cert for https://www.magyarorszag.hu/ was issued on 3/18/2008, which was before the problem was identified and the solution determined.  This site doesn’t load correctly when OCSP is enforced, and the ssl cert does indeed have the OCSP URI in the AIA field.

So I think the issue that you are seeing is websites whose ssl certs haven’t been updated since 10/13/2008 will result in this error when OCSP is enforced in the browser. However, as they expire and the new certs are generated, this problem will go away.

I propose that we move forward with inclusion in NSS, with the understanding that Microsec has shown that they have removed the OCSP URI from the AIA field for newly issued ssl certs.

Comment 56

[Eddy Nigg (StartCom)]

(In reply to comment #55)
> See https://www.e-szigno.hu as an example. 

Correct, this site doesn't have this problem anymore.

Comment 57

[Kathleen Wilson]

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

Comment 58

[Istvan Zsolt BERTA]

(In reply to comment #55)
> I believe the problem has been resolved, but the ssl certificate for that
> website hasn’t been updated.

Yes, exactly. This is an old certificate, that has been issued before we removed the URL from the AIA field. The operator of magyarorszag.hu is our client, we do not have direct control over their system to update their certificates.
We shall contact our clients to have their certificates updated.