Re: SECOM Trust EV root inclusion request
Are you saying that your OCSP is (going to be) operating now as expected? Yes. According to this thread http://groups.google.com/group/mozilla.dev.tech.crypto/browse_thread/thread/416427a350db11a9 We have already removed the problematic OCSP URL from our SSL certificates, and also removed the problematic OCSP URL from CA certificates that are used for the validation of SSL certificates. Our root does contain an OCSP URL, but according to the thread it does not cause a problem in Mozilla, as the revocation status of the root cannot and shall not be checked via OCSP. This means, there are not any problems even on the short run. As we promised, we shall also address the problem on the long run by introducing an OCSP service that is usable for the general public, i.e. that does not require authentication and works using the 'authorized responder' concept. http://groups.google.com/group/mozilla.dev.tech.crypto/msg/71ff5be3141529a8? On the long run, we shall be required to phase out SHA-1 from our systems so we shall have to introduce a new hierarchy. The new hierarchy shall have an OCSP usable for the general public, and its' root certificate shall not contain an OCSP URL. However, the whole process of migration to the new hierarchy and the phasing out the current one will be long. I may accept this statement, but if there is such a requirement, it should be stated in advance. I agree with you. If there is no such requirement, it should not hinder the process, but there should be defined ways to resolve this issue. Apparently it does hinder the process (not intentional, just by the fact that it's hard to get to the information). We were requested to submit further documentation on the audit in English. We had the detailed report of our auditor translated and we sent it to Microsoft. (This is a non-public document that describes our systems in depth similar to our CPS.) So there is a disadvantage to Mozilla as you aren't willing to provide the same information as you did to Microsoft. We are willing to provide information but nobody asked it :). It was not stated among the requirements for inclusion to submit a CSP in English. I was requested to submit translations of relevant sections of our CPS, and I did so. Mozilla has also asked a Hungarian person to double check my translation. I was also asked to send our CPS in RTF format so that you can perform a machine translation, and I did so. (I also expressed my skepticism about machine translation to and from Hungarian.) We have provided what you asked. Why would we submit something you did not ask for? was going to happen at what time, what was examined, what the exact criteria was, and when they wanted us to submit some documentation, they asked us to do so. Yes, I guess Mozilla can make such a request too. If such a formal request is made, we shall have no problem with it. (We shall prefer to submit a translation of our CPS and not of the detailed audit report, as Mozilla discusses these materials on a public forum, and the detailed audit report may contain non-public information too.) However, the translation of a 100-page-long CPS has a major cost, and I can only justify this cost if I can demonstrate that it is either necessary or if I can clearly show what benefits it would bring (e.g. to what extent it speeds the process up). Still, if we need to submit a translation, I think we could have been asked to do it two years ago when the whole process started. I do not see why it took Mozilla two years to come to this conclusion... And sorry for the late reply, your message almost drowned at the list (but I marked it to respond to you later). I also apologize for my late reply, we were also flooded with mails after the holidays. Regards, István ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: SECOM Trust EV root inclusion request
István, even though I understand your frustration and agree with the basic understanding that requirements should be published accordingly, I also must state there has been at least one issue (notably with your OCSP responder I think) in addition to our I think the OCSP issue has been resolved: As I recall, on the short run it does not cause problems with the current release of Firefox. However, we accepted your arguments, we made some changes in our systems and promised further changes in the future, so that it shall not cause problems on the long run either. inability simply not to be able to read the CP/CPS. As more and more CAs from Non-English speaking countries are applying for inclusion, Mozilla will have to find a solution (in this or the other way). Please note that many CAs from such countries publish their CP/CPS in English, sometimes in addition to their native language. This is in my opinion expected behavior and practice in this industry - specially if the CA is supposed to be included in a product used to be world-wide and hence the relying parties. I may accept this statement, but if there is such a requirement, it should be stated in advance. If there is no such requirement, it should not hinder the process, but there should be defined ways to resolve this issue. Being a long-term Mozilla fan, I am really sorry to say that the same procedure at Microsoft was faster, much better defined, less ad hoc, and a lot more transparent. Agreed, Microsoft is a professional company which doesn't involve any input from a community as with Mozilla. But how did they verify and understand your CP/CPS? Did they rely solemnly on the audit report? Does your OCSP responder not present a problem to them? We were requested to submit further documentation on the audit in English. We had the detailed report of our auditor translated and we sent it to Microsoft. (This is a non-public document that describes our systems in depth similar to our CPS.) They did not examine our CPS. (If we had been asked to submit a translation of the current CPSs, we would have done so.) They relied on the audit statement and on the detailed report of our auditor. We were asked a set of questions that were public before the process, we had some discussion concerning some of them (especially about the extended key usages). At that time, Microsoft stated that OCSP responders under a separate root are not supported, so our OCSP root was not included in Windows. However, the OCSP URL in the AIA field was not raised as a problem. Other issues were not raised during the process. Whatever I criticized was not the scrunity of the process at Mozilla, but its transparency and the way we can make our plans concerning it. I mentioned Microsoft, because there we had a much better idea of what was going to happen at what time, what was examined, what the exact criteria was, and when they wanted us to submit some documentation, they asked us to do so. On to István's comments: Perhaps, making such (discriminatory) criteria mandatory could still be better than enforcing it without stating it clearly. I don't think this criteria exists. I for one would not like it. But, there is, IMO, a need for something, and something short and simple was what I was exploring. I would point out that all my comments are aimed at the future. I wouldn't want to slow down any current contender. You seem to meet the rules and practices, so no need to dwell on this. Being a long-term Mozilla fan, I am really sorry to say that the same procedure at Microsoft was faster, much better defined, less ad hoc, and a lot more transparent. OK! I think I for one would really like to hear a summary of that. I'm not trying to stir the pot, just wondering whether there is any way to improve the current Mozilla process, either up or down. OK, thanks, I tried to summarize the main points above. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: SECOM Trust EV root inclusion request
Ian G wrote re CPSs not available in English: Which leads to the first easy fix: insist that all non-english CAs translate all their docs. Then I can read the CPS! I personally am unsatisfied at that, I see flaws. 1. Frank has made the case for regional and local CAs. The web is wide, and CPSs are very long documents. So I think translating *all* important documents to english is not only impractical but also discriminatory, as non-english cultures (most of them) will then face a barrier that the english do not do not. I'll differ from you somewhat here. As a practical matter browser vendors are a major audience for a CA's CPS, along with the CA's auditor, possibly government agencies concerned with the CA's operations, and whoever else might care to read it. I can understand a CA issuing its CPS in the native language of the country in which it operates; that's probably the best strategy to make sure the document is properly understood by relevant government agencies and by its auditors (if they're local). However if a CA doesn't offer an English translation of its CPS and other relevant documents then it disadvantages browser vendors and other application software vendors who might be interested in supporting use of the CA's certificates. I don't support making it mandatory that CAs provide an English version of the CPS, but I have no problem with telling CAs that not having an English version will likely cause delays with their application. Perhaps, making such (discriminatory) criteria mandatory could still be better than enforcing it without stating it clearly. Our CA (Microsec Ltd, a leading CA in Hungary) submitted its inclusion request February 2007. https://bugzilla.mozilla.org/show_bug.cgi?id=370505 Our first public discussion phase was opened October 2008, http://groups.google.com/group/mozilla.dev.tech.crypto/browse_thread/thread/416427a350db11a9# this public discussion has been postponed, scheduled again and it seem to be postponed again. I think, only the language of our documentation remains the only open issue today. Had we known that in order to be accepted to Mozilla, we MUST/SHOULD submit either an English translation of our CPS/CPSs or we need to maintain our complete documentation in English, perhaps we would have made different decisions in the past two years. Our primary focus are electronic signatures; browsers and SSL certificates are a marginal issue for us. While submitting the English translation of a snapshot of our documentation may be impractical and costly, maintaining a complete documentation both in English and in Hungarian is a major investment that shall perhaps never be justified. Had we known that English documentation is a requirement, we could have chosen to fulfill it by submitting a translation, we could have sought other way to sell certificates accepted by Mozilla, or we could have decided to forget about the Mozilla-inclusion-issue and to advise the Hungarian public to use Explorer instead. Mozilla has the right to determine the requirements for including CAs, but if this is a requirement, then why it is not stated, why it is not public? Being a long-term Mozilla fan, I am really sorry to say that the same procedure at Microsoft was faster, much better defined, less ad hoc, and a lot more transparent. Regards, István ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Microtec CA inclusion request
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.) - The CA root includes the OCSP service URI in the AIA extension: We accept that it is awkward that our root certificate includes the OCSP AIA extension, it was a bad idea for us to include it. Unfortunately our root certificate is not something we can change on the short run. We don't quite understand why anyone would check the revocation status of a trust anchor via CRL or OCSP. Regards, István ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Microtec CA inclusion request
It is conformant IF and only IF the user (not the CA) chooses to trust that responder. If the CERTIFICATE issued by the issuer says to go to that responder for OCSP, but the responder's cert is not either a) the the issuer's cert, or b) a cert issued by the same issuer as the cert under test, then it is not conformant. The RFC is very clear about that. I still disagree. RFC 2560 does allow the responder to be under a separate root as a 'trusted responder'. Naturally, no responder is trusted by everyone, there are users who accept a certain responder and there are users who do not accept it. I don't think that a responder is not conformant according to RFC 2560 just because there are users who do not trust it. My recommendation for Microsec is to refrain from including the OCSP service URI if and until they can provide an OCSP responder which is usable with Firefox and other browsers (when relying on AIA extension). I agree, our responder is not useful for most Mozilla users. We shall remove the OCSP URL from the AIA field for webserver certificates. I vote no on this proposal due to OCSP interoperability issues. I think the removal of the OCSP URL should eliminate this problem. Regards, István ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Microtec CA inclusion request
A plain text version would be extremely helpful. Concerning machine translation, I think I'll be alright ;-) I have attached a plain text version to Bug 370505, it is available here: https://bugzilla.mozilla.org/attachment.cgi?id=342436 I still don't think a machine translation will be of any help. Okay, I'm a bit confused. The Root CA itself does not sign qualified certificates, but it authenticates the private key used to sign qualified certificates? Yes. In our system, qualified certificates are signed by intermediate CAs only. 'Qualified' does not necessarily mean that its more secure, it means that more regulations apply, and a qualified signature (based on a qualified certificate and created using a secure signature creation device) can be considered equivalent with a handwritten one according to the EU Directive. A non-qualified signature created in a secure environment can sometimes be considered more secure than a qualified one. Many regulations apply to the CA used for signing qualified certificates, but a lot less regulations apply to the root who signs the certificate for the key that is used for signing qualified certificates. I agree that this is not necessarily logical. István ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Microtec CA inclusion request
Well, I don't get it. Your diagram at http://srv.e-szigno.hu/menu/index.php?lap=english_ca_hierarchy shows clearly that you are issuing intermediate CA certificates from the root, but in the previous comment you claimed that the CA is only allowed to use * signing qualified end-user certificates and * signing CRLs. Does this apply to the intermediate CA certificates but not the CA root? It applies to the private key used for signing qualified certificates (end-entity certificates issued to natural persons) only, so it does not apply to roots that sign CA certificates. We have a root, which does not issue end-user certificates, but issues CA certificates for our own CAs only. Which root is that? I understand there is only one root up for inclusion... We requested the inclusion of one root, 'Microsec e-Szigno Root CA' only. (The root 'e-Szigno OCSP CA' is our OCSP root. The root 'Közigazgatási Gyökér Hitelesítés Szolgáltató' is a Hungarian governmental root operated by the Hungarian government that cross-certififes certain commercial CAs (like Microsec), it does not belong to us. The gray ones below are our test roots for testing purposes, they do not belong to our official system.) Thanks for that! I still would like to read your CP/CPS in English (even if only machine translated). Is it somehow possible to facilitate that? We would like to avoid having to translate these documents if possible, as our CPS is over 100 pages long. I doubt that any Hungarian to English machine translation could provide a quality good enough (that allows you to figure out that the original document was in fact a CP/CPS of a CA). If you have trouble feeding the PDF into a machine translator, I can provide our documents in some other format: in TXT or in RTF, etc. Regards, István ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Microtec CA inclusion request
Dear All, Let me reflect to some of the above points. First of all, our public website is www.e-szigno.hu. The webpage at https://srv.e-szigno.hu:/cgi-bin/editugyvedcsv.cgi is a restricted page, it requires a client-side SSL certificate (with certain values in the subject DN), so you should not be able to access it. I do not know of any (useful) tool capable of translating from Hungarian to English. Please let me know if you find one. OCSP: - According to section 2 of RFC 2560, there are three ways to operate an OCSP responder: All definitive response messages SHALL be digitally signed. The key used to sign the response MUST belong to one of the following: -- the CA who issued the certificate in question -- a Trusted Responder whose public key is trusted by the requester -- a CA Designated Responder (Authorized Responder) who holds a specially marked certificate issued directly by the CA, indicating that the responder may issue OCSP responses for that CA Later, in section 4.2.2.2 Authorized Responders, RFC 2560 gives more requirements on using the third option, CA designated or authorized responders. We do not use this third option. We support the second option (Trusted Responder), where the requester explicitly trusts the OCSP responder. (In our case the link of trust is established by our CPS stating the the separate root can be trusted for signing relevant OCSP responses.) I do not know of any statement in RFC 2560 that requires the responder to be under the same root. Based on the above, we consider our solution RFC 2560 conformant. (We know of other similar solutions, e.g. openvalidation.org works exactly this way.) We had good reasons to choose this solution. According to Hungarian regulations, a qualified CA is allowed to use its private key for the following two purposes only: * signing qualified end-user certificates and * signing CRLs. As neither 'signing OCSP responses', nor 'singing OCSP responder certificates' is listed here, we were not allowed to support options 1 and 3 marked in RFC 2560, so only option 2 remained. Our OCSP is used by our own customers for creating so-called 'archive signatures' e.g. according to ETSI TS 101 903. (An archive signature is timestamped and the necessary revocation information is also attached to the signature. Certain signature policies require that the revocation information needs to be issued _after_ the time of signing, i.e. the point of time marked in the timestamp on the signature.) We understand that our OCSP is not useful for the general public, so we did not wish to include our OCSP root (and support for our OCSP) in Mozilla. If you consider that the OCSP URL in the AIA field poses a problem, we can modify the profile of the SSL server certifictes so the AIA field will not be included. Unrecognized extensions: Our regulations require us to comply with European ETSI specifications. Qualified certificates are one of the key concepts of European PKI regulations and ETSI TS 101 862 defines the QCStatement extension for marking a certificate to be qualified. According to ETSI TS 101 862 this extension is mandatory. This is not a Microsec-specific problem, it affects most of the other European CAs who issue qualified certificates. The QCStatement extension is *NOT* critical in our certificates. Webserver and code signing certificates are generally non-qualified, so they are not affected by this issue. Liability: -- In our qualified certificates, the liability limit is included in the certificate. The minimum value is ~5400 USD, the maximum value is ~1 million USD. They do not claim to include this information in non-qualified certs. Our law does not allow us to do so. We can include it in our CPS only. Apparently the absence of an explicit liability limit should be understood to mean no liability. In our country this is exactly vice versa. If you do not state any limit, your liability is unlimited. (This is a general and not a CA- specific rule.) In fact, the liability is unlimited anyway as you can limit it per relying party only. If you limit your liability at $1, you may still need to pay $1million for one million relying parties. In case of class 3 non-qualified certificates this limit is ~$500. Any cert for which the issuer has no liability is a cert for which the issuer has no incentive to be accurate. If a CA has no liability for doing so, what stops it for issuing lots of certs for paypal.com? In fact, we agree that a CA should be responsible for certificates it issues. Still, due to various reasons (mostly because other CAs limit their liability to zero too), we need to offer class2 certificates with zero liability too. Fortunately, we issue very few of these. However, we refuse to issue webserver and code signing certificates as class2, and we require them to be at least class3 (where the CP is based on NCP or NCP+ and thus a face-to-face
