Re: Microtec CA inclusion request
Nelson Bolyard wrote: Frank Hecker wrote: * OCSP. My understanding is that the Microsec practice of having a separate root for OCSP is very problematic, particularly given the inclusion of AIA extensions with OCSP URLs in end entity certificates. As I understand it, 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. ... after some period of time has elapsed. Certainly the day after they begin to issue certs without the OCSP URL in the AIA extension, 99+% of the existing certs will still have those AIA extensions. Over time that number should decline. Please refresh my memory here: As I understand it, the basic problem was that if the Microsec root were included in Firefox (or other products) and a user surfed to an SSL/TLS-enabled site with an end entity certificate issued by Microsec (a cert with the AIA extension with the OCSP URL), then this would cause an error in Firefox 3, because Firefox 3 does OCSP checking by default and it would get what it considered to be a bad OCSP response. Do I have this right? At what point does it become appropriate to consider the problem to have abated enough to no longer be an issue? Is it when the number of remaining outstanding valid certs that bear that AIA extension is 90%? 50%? 20%? 10%? 5%? 1%? I think it is in Microsec's interest to revoke and reissue certificates for sites that encounter problems with Firefox. I would consider this problem to be effectively addressed after Microsec actively begins an initiative to work with its affected customers to get them new certificates. At that point if customers do not update their sites IMO it is their problem, not Microsec's or Mozilla's. If approved, the Microsec root would not go into Firefox 3 until late this year or early next year. So I think there is plenty of time for Microsec to put together a suitable plan for how to ease the transition for its customers and minimize any errors that might be experienced by Firefox users. Although we haven't tested it with libPKIX, as far as I know, OCSP URLs in root certs will not be a problem for NSS. NSS will never check a self-issued cert for OCSP revocation. Thanks for looking into this. My conclusion is therefore that there is no need for Microsec to reissue its root certificate, at least as far as Mozilla is concerned. However as Rob Stradling noted, I do suggest that Microsec look at what GlobalSign did with its root refresh, in case Microsec wants to do something similar in the future. (I should also note that if Microsec's current root is approved for inclusion, I 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.) One final question: Does anyone know what Thunderbird 3 will be doing in terms of OCSP checks? Will this problem affect end entity certificates issued by Microsec for S/MIME use? Frank -- Frank Hecker [EMAIL PROTECTED] ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Microtec CA inclusion request
Frank Hecker wrote: In accordance with the schedule at https://wiki.mozilla.org/CA:Schedule I am now opening the first public discussion period for a request from Microtec Ltd to add the Microsec e-Szigno Root CA root certificate to Mozilla. This is bug 370505, and Kathleen has produced an information document attached to the bug. https://bugzilla.mozilla.org/show_bug.cgi?id=370505 First, my apologies for the delay in my responding to the public comments. I've messed up the schedule I previously outlined; see below for my proposal to revise the schedule and deal with the Microsec request. I've read through all the public comments. Rather than try to respond to each and every comment, I've written a brief summary of my understanding of the various issues raised. Please feel free to correct my understanding where appropriate. * Translation of the Microsec CPSs. As I noted in my original message, all of the Microsec CPS documents are available in Hungarian only. Our policy does not mandate that CA documents be available in English, so I don't see a justification for requiring that Microsec prepare official English translations. Thus far we've relied on Microsec-provided translations of key CPS sections; the Mozilla Hungarian localization team (in the person of Kálmán Kéménczy) was kind enough to verify the accuracy of the translations. IMO Getting human-created English translations of all the CPSs is going to be too difficult and time-consuming to be feasible, at least in the near term. I've followed up on the tips provided by Eddy Nigg and researched various options for machine translation of Hungarian. It appears that the best online option is the Webforditas.hu site: http://www.webforditas.hu/web-translator.php http://www.webforditas.hu/translation.php The company behind the site also sells a Windows-based translation application (MorphLogic). I'm going to try and see if I can use either the site or (more likely) the application to get rough translations of relevant CPS sections, starting with the tables of contents. * Liability associated with Microsec certificates. There were a number of comments relating to the monetary liability associated with Microsec certificates. The thread was interesting in relation to understanding practices in Hungary and the EU, but I think that ultimately it is not relevant to our consideration of this request. Our policy does not have any requirements relating to monetary liability of CAs, and I am not persuaded that disclaiming liability in certain contexts causes security issues for typical Mozilla users. I'm therefore minded to ignore this issue for purposes of evaluating this request. * OCSP. My understanding is that the Microsec practice of having a separate root for OCSP is very problematic, particularly given the inclusion of AIA extensions with OCSP URLs in end entity certificates. As I understand it, 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. However there still appears to be an open question as to whether having an AIA extension with OCSP URL in the Microsec root certificate will cause a problem with NSS. (Nelson wrote that he was going to investigate this, but I don't recall seeing a followup to this.) Based on the above, my inclination is to postpone consideration of this request for at least two weeks. That will give me time to try to get more of the Microsec CPS content translated, and also to get a final answer on the question of root certificates with AIA extensions with OCSP URLs. Once those two things get done I'll formally start a new public comment period. (You can still comment in the meantime, of course; I'm just setting a formal date for purposes of scheduling CA requests.) I've revised the CA schedule to reflect this delay: https://wiki.mozilla.org/CA:Schedule Frank -- Frank Hecker [EMAIL PROTECTED] ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Microtec CA inclusion request
Frank Hecker wrote: * OCSP. My understanding is that the Microsec practice of having a separate root for OCSP is very problematic, particularly given the inclusion of AIA extensions with OCSP URLs in end entity certificates. As I understand it, 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. ... after some period of time has elapsed. Certainly the day after they begin to issue certs without the OCSP URL in the AIA extension, 99+% of the existing certs will still have those AIA extensions. Over time that number should decline. At what point does it become appropriate to consider the problem to have abated enough to no longer be an issue? Is it when the number of remaining outstanding valid certs that bear that AIA extension is 90%? 50%? 20%? 10%? 5%? 1%? Do we know what the maximum validity period is in the cert they've issued? That would give us a date after which we could be sure it's 0%. However there still appears to be an open question as to whether having an AIA extension with OCSP URL in the Microsec root certificate will cause a problem with NSS. (Nelson wrote that he was going to investigate this, but I don't recall seeing a followup to this.) Sorry, I did get the answer but forgot to write it up. :-/ Although we haven't tested it with libPKIX, as far as I know, OCSP URLs in root certs will not be a problem for NSS. NSS will never check a self-issued cert for OCSP revocation. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Microtec CA inclusion request
the OCSP URI in the CA root IS a problem Nelson, does NSS ever attempt to check the revocation status of a built-in Root Certificate if that Root Certificate contains CRLDP(s) and/or OCSP URI(s) ? On Sunday 12 October 2008 16:40:11 Eddy Nigg wrote: Eddy Nigg: Except if Nelson thinks otherwise, removing the AIA OCSP service URI solves this issue. More specific the Mozilla CA Policy calls for: cRLDistributionPoints or OCSP authorityInfoAccess extensions for which no operational CRL or OCSP service exists. Therefor the OCSP reference MUST NOT appear in the EE certificates of Microsec. I suggest to follow up on this to confirm compliance. 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... - The CA root includes the OCSP service URI in the AIA extension: OCSP: URI: https://rca.e-szigno.hu/ocsp - Upon going to https://srv.e-szigno.hu/ I received an sec_error_unknown_issuer error. Apparently the certificate isn't installed correctly and doesn't present the certificate chain. The later is just an annoyance which can be easily fixed, however the OCSP URI in the CA root IS a problem. Additionally the intermediate CA certificate might also feature the AIA extension (which I couldn't test). As mentioned earlier, the Mozilla CA Policy states: ...might cause technical problems with the operation of our software, for example, with CAs that issue certificates that have... ...cRLDistributionPoints or OCSP authorityInfoAccess extensions for which no operational CRL or OCSP service exists. Micorsec doesn't provide an operational OCSP responder when used in conjunction with AIA service URI. Over to Frank. -- Rob Stradling Senior Research Development Scientist Comodo - Creating Trust Online Office Tel: +44.(0)1274.730505 Fax Europe: +44.(0)1274.730909 www.comodo.com Comodo CA Limited, Registered in England No. 04058690 Registered Office: 3rd Floor, 26 Office Village, Exchange Quay, Trafford Road, Salford, Manchester M5 3EQ This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender by replying to the e-mail containing this attachment. Replies to this email may be monitored by Comodo for operational or business reasons. Whilst every endeavour is taken to ensure that e-mails are free from viruses, no liability can be accepted and the recipient is requested to use their own virus checking software. ___ 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
Rob Stradling wrote, On 2008-10-12 23:01: Nelson, does NSS ever attempt to check the revocation status of a built-in Root Certificate if that Root Certificate contains CRLDP(s) and/or OCSP URI(s) ? Good question. The answer is somewhat complex. :-/ As you may know, NSS has two separate bodies of code for building certification paths and validating them. Firefox uses both implementations at different times. The old one checks OCSP only for EE certs, and does CRL checks for any certs issued by any CA for which it has a CRL, but does not automatically fetch CRLs. So the answer to your question for the old implementation is: no. The new one is capable of checking OCSP and CRLs at every level, and eventually will have the ability to fetch CRLs when a CDP extension is found in a cert. With the new implementation, all this checking is under the application's control, so that application can choose to do revocation checking on CAs, or not, and can choose to do OCSP, or CRLs, or both, or none. I would expect that when the application has told it to use both revocation protocols on all certs (including CA certs) the code would check revocation information for any cert that was both (a) not trusted, and (b) not self-issued. So I would expect that it would not check the revocation status of any root CA cert, whether built in or not. But I am not sure what it does. I will attempt to investigate that. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Microtec CA inclusion request
Rob Stradling: the OCSP URI in the CA root IS a problem Nelson, does NSS ever attempt to check the revocation status of a built-in Root Certificate if that Root Certificate contains CRLDP(s) and/or OCSP URI(s) ? Adding to Nelson's commentCRL is checked at any level if provided (requires manually providing the CRLDP). EV requires CRL and/or OCSP checking at the intermediate CA level, hence I expect it to check those at least. With the root there is always the egg-and-chicken game as you most likely know... -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: [EMAIL PROTECTED] Blog: https://blog.startcom.org ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Microtec CA inclusion request
On Monday 13 October 2008 15:36:02 István Zsolt BERTA wrote: snip - 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. István, Just a thought... If Nelson's investigation does find that the OCSP AIA extension in your Root Certificate is a problem for NSS, is there really anything to stop you from issuing a new Root Certificate? This new Root Certificate could be identical to your current Root Certificate except for i) different serial number, and ii) OCSP AIA removed. As the old and new Root Certificates would have the same Subject Name and Key, they would effectively be interchangeable. 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 -- Rob Stradling Senior Research Development Scientist Comodo - Creating Trust Online Office Tel: +44.(0)1274.730505 Fax Europe: +44.(0)1274.730909 www.comodo.com Comodo CA Limited, Registered in England No. 04058690 Registered Office: 3rd Floor, 26 Office Village, Exchange Quay, Trafford Road, Salford, Manchester M5 3EQ This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender by replying to the e-mail containing this attachment. Replies to this email may be monitored by Comodo for operational or business reasons. Whilst every endeavour is taken to ensure that e-mails are free from viruses, no liability can be accepted and the recipient is requested to use their own virus checking software. ___ 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
István Zsolt BERTA: 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. I think the point Nelson was making that if the certificate issued to the users includes an OCSP URI it's not conforming to the RFC. We shall remove the OCSP URL from the AIA field for webserver certificates. Yes I vote no on this proposal due to OCSP interoperability issues. I think the removal of the OCSP URL should eliminate this problem. Except if Nelson thinks otherwise, removing the AIA OCSP service URI solves this issue. More specific the Mozilla CA Policy calls for: cRLDistributionPoints or OCSP authorityInfoAccess extensions for which no operational CRL or OCSP service exists. Therefor the OCSP reference MUST NOT appear in the EE certificates of Microsec. I suggest to follow up on this to confirm compliance. -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: [EMAIL PROTECTED] Blog: https://blog.startcom.org ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Microtec CA inclusion request
Eddy Nigg: Except if Nelson thinks otherwise, removing the AIA OCSP service URI solves this issue. More specific the Mozilla CA Policy calls for: cRLDistributionPoints or OCSP authorityInfoAccess extensions for which no operational CRL or OCSP service exists. Therefor the OCSP reference MUST NOT appear in the EE certificates of Microsec. I suggest to follow up on this to confirm compliance. 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... - The CA root includes the OCSP service URI in the AIA extension: OCSP: URI: https://rca.e-szigno.hu/ocsp - Upon going to https://srv.e-szigno.hu/ I received an sec_error_unknown_issuer error. Apparently the certificate isn't installed correctly and doesn't present the certificate chain. The later is just an annoyance which can be easily fixed, however the OCSP URI in the CA root IS a problem. Additionally the intermediate CA certificate might also feature the AIA extension (which I couldn't test). As mentioned earlier, the Mozilla CA Policy states: ...might cause technical problems with the operation of our software, for example, with CAs that issue certificates that have... ...cRLDistributionPoints or OCSP authorityInfoAccess extensions for which no operational CRL or OCSP service exists. Micorsec doesn't provide an operational OCSP responder when used in conjunction with AIA service URI. Over to Frank. -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: [EMAIL PROTECTED] Blog: https://blog.startcom.org ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Microtec CA inclusion request
Eddy Nigg: 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... - The CA root includes the OCSP service URI in the AIA extension: OCSP: URI: https://rca.e-szigno.hu/ocsp - Upon going to https://srv.e-szigno.hu/ I received an sec_error_unknown_issuer error. Apparently the certificate isn't installed correctly and doesn't present the certificate chain. The later is just an annoyance which can be easily fixed, however the OCSP URI in the CA root IS a problem. Additionally the intermediate CA certificate might also feature the AIA extension (which I couldn't test). As mentioned earlier, the Mozilla CA Policy states: ...might cause technical problems with the operation of our software, for example, with CAs that issue certificates that have... ...cRLDistributionPoints or OCSP authorityInfoAccess extensions for which no operational CRL or OCSP service exists. Micorsec doesn't provide an operational OCSP responder when used in conjunction with AIA service URI. Over to Frank. More followup's on this issue...I found a correctly installed certificate at https://rca.e-szigno.hu/ and I could examine also the intermediate CA certificate which also features the OCSP AIA extension. This means that all certificates from the root up to the EE certificate include the AIA extension OCSP URI. Additionally the OCSP URI is a HTTPS URL which makes it even more unusable. How can the OCSP responder be accessed by HTTPS if it can't confirm the validity of the connection to the responder itself? IMO this is never going to work. OCSP responses are signed and SHOULD NOT be served over a secure connection. The only workaround would be to have the OCSP HTTPS connection signed by a certificate issued by a different CA. -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: [EMAIL PROTECTED] Blog: https://blog.startcom.org ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Microtec CA inclusion request
On 10/03/2008 12:43 AM, Frank Hecker: I am now opening the first public discussion period for a request from Microtec Ltd to add the Microsec e-Szigno Root CA root certificate to Mozilla. This is bug 370505, and Kathleen has produced an information document attached to the bug. Besides the issue with the OCSP responder and their including of the OCSP URI in the AIA extension with EE certificates, I have not found any issues with this request. 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 must note that a I couldn't read the CP/CSP of Microsec and my information is based solemnly on the bug entries and comments from István, even though István posted a text version of one of their CP/CPS at the bug. I believe that Mozilla should have the basic tools to perform at least machine translations of such documents in case no English version exists. It's important for me to inspect the CP/CPS and browse through the documents provided by the CA. -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: [EMAIL PROTECTED] Blog: https://blog.startcom.org ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Microtec CA inclusion request
István Zsolt BERTA wrote, On 2008-10-07 07:07: As I see we all agree on the fact that a 'trusted responder' can exist according to RFC 2560, and it is possible that an OCSP responder certificate is under a separate root. (There are various scenarios for providing OCSP service, it can be provided by a CA directly or by proxy responders, etc. but RFC 2560 does not deal with such issue.) Thus, I refuse any statement that would claim that our solution is not RFC 2560 conformant. 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. ___ 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 vote no on this proposal due to OCSP interoperability issues. -Kyle H On Sat, Oct 11, 2008 at 1:58 PM, Nelson B Bolyard [EMAIL PROTECTED] wrote: István Zsolt BERTA wrote, On 2008-10-07 07:07: As I see we all agree on the fact that a 'trusted responder' can exist according to RFC 2560, and it is possible that an OCSP responder certificate is under a separate root. (There are various scenarios for providing OCSP service, it can be provided by a CA directly or by proxy responders, etc. but RFC 2560 does not deal with such issue.) Thus, I refuse any statement that would claim that our solution is not RFC 2560 conformant. 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. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto ___ 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
On 10/08/2008 05:07 PM, István Zsolt BERTA: 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. In understand that and didn't requested a complete translation. 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. A plain text version would be extremely helpful. Concerning machine translation, I think I'll be alright ;-) -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: [EMAIL PROTECTED] Blog: https://blog.startcom.org ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Microtec CA inclusion request
On Wed, Oct 8, 2008 at 8:07 AM, István Zsolt BERTA [EMAIL PROTECTED] wrote: 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. 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? 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.) The 'Microsec e-Szigno Root CA' is a different CA name than 'e-Szigno OCSP CA', and thus the OCSP CA does not match the X.509 or OCSP requirements to be able to sign OCSP responses for 'Microsec e-Szigno Root CA'. -Kyle H ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Microtec CA inclusion request
István Zsolt BERTA wrote: [...] 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. How does the Hungarian regulation define the CA ? In X509, a CA is defined by it's Distinguished Name, so can have several certificates with several private key. So according to X509, your CA can have both : - a qualified certificate and associated private key that can only sign end-user certificates and CRLs. - another non-qualified certificate that signs OCSP response If your OCSP Responder cert has the same DN as your CA cert and is also signed by your Root CA, it should be recognized another cert issued for the same CA and trusted according to option 1 of RFC2560. Unfortunatly, I never had the opportunity to check how this specific case is handled by NSS :-) ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Automated Qualified Signatures. Re: Microtec CA inclusion request
According to the Directive, qualified signatures are equivalent with handwritten ones, so only natural persons were meant to have qualified certificates. However, in certain countries, electronic invoices have to be signed with qualified certificates. This led to the situation where - in some countries - automated mechanisms also create qualified signatures. I think this requires a slightly different explanation. In Germany clueless government institutions buy signature devices capable of housing dozens of smart cards in order to with a single manual operation (handwritten) be able to sign multiple invoices in one step using qualified signatures. In Scandinavia and Estonia somewhat less clueless government institutions have raised specific PKIs that issue organization certificates that are similar to EV certs (strict issuance policies), but certify an organization using a VAT, DnB or similar org-id rather than a domain name. These certificates (well the private key if we should be nitpicking..) are automatically signing outgoing messages indicating that they have passed whatever is needed for messages to be authorized for external consumption. These certificates are not called or issued as qualified certificates. Employee signatures essentially never leave the homebase. This is very far away from the original goal. Which is not that surprising since authenticity in the real world is much more important than being able to get money from a CA due to a screw-up. The original EU signature idea that you would be able to do business with anybody because they have a QC, isn't for real because a QC doesn't say if you are a credible person and a CA has no ability bringing bad guys to a court either. In addition, identity schemes tend to be pretty local (my Social Security Number has little value outside of Sweden). If e-mail security had started at that level (domain) instead of S/MIME, the Internet had been a much better place! Anders ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Microtec CA inclusion request
On 10/07/2008 04:07 PM, István Zsolt BERTA: As I read above, it currently does not pose a problem that there is an OCSP URL in the AIA field of the certificate. If you think that this shall become problematic in the future, we can modify the profile of webserver certificates and remove the OCSP URL (as long as the OCSP is not useful for the general public). Yes, I think this is what should be done. OCSP responders are not a requirement currently (so I think it's highly suggested), but using the AIA extension makes the certificates unusable for any relying party which treats OCSP failures as an error. 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: You are not allowed to issue intermediate CA certificates then? Are you issuing directly from the CA root? The CA key used for signing qualified certificates can be used for signing qualified end-user certificates and CRLs. This also means that we cannot issue intermediate CA certificates with that particular key and we cannot issue non-qualified certificates either. 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? 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... What are the checks performed on code-signing certificates? 1. We verify the existence of the company which requests the code- signing certificate using an online connection to the Hungarian registry of businesses. 2. We verify the existence of the documents (driving license, ID card or passport) of the person who requests the code-signing certificate on behalf of that particular company. We perform this verification using an online connection to the Office of the Central Office for Administrative and Electronic Public Services. http://www.nyilvantarto.hu/kekkh/kozos/index.php?k=nyitolap_enb=bal_eng 3. Using a face-to-face registration (as the CP is NCP-based) we verify the identity of the person who requested the certificate on behalf of that company. This person has to meet our registration officer and has to present the document (driving license, ID card or passport) that was verified in step 2. 4. We verify that this person has the authority to sign on behalf of the company. We generally request a notarial deed (issued by a public notary) as a proof. 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? -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: [EMAIL PROTECTED] Blog: https://blog.startcom.org ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Microtec CA inclusion request
Frank Hecker wrote, On 2008-10-02 14:43: In accordance with the schedule at https://wiki.mozilla.org/CA:Schedule I am now opening the first public discussion period for a request from Microtec Ltd to add the Microsec e-Szigno Root CA root certificate to Mozilla. This is bug 370505, and Kathleen has produced an information document attached to the bug. Speaking only for myself ... several things about this application bother me. At least one of them is not entirely clear. The statements below reflect my understanding after reading their statements in bug 370505, and also bug 277797. 1. OCSP issues - a) Their OCSP service reportedly does not conform to the IETF RFCS. The OCSP responder certs are neither i) the CA cert of the issuer of the cert under test, nor ii) a cert issued by the issuer of the cert under test. This means that any OCSP response obtained from their responder will be deemed invalid, with an illegitimate signer. b) They explain that OCSP service is an extra cost service for relying parties. I wonder: do all their certs have AIA extensions with OCSP URLs? What sort of OCSP response do non-paying relying parties receive? I won't go so far as to insist that CAs use OCSP, but I think it is very reasonable to insist that CAs who issue certs with OCSP URLs in AIA extensions MUST make those OCSP responses conform to the RFCs, and work correctly for Mozilla users. Some of us hope someday soon to treat certs for which we receive invalid OCSP responses (as opposed to NO OCSP responses) as revoked. If we have admitted CAs that are known to produce certs that will not work in that case, I think that becomes a strong disincentive to ever institute that stronger interpretation of invalid responses. :( 2. Incentives to be accurate - They have different financial liability limits for each class of cert that they issue, and according to comment 10 in that bug, for one of their classes (class2 non-qualified certificates), that limit is ZERO. For their qualified certs, they include an extension that reports the limit of their liability, as an integer number of Hungarian Forints (HUF). (Tell me, do you know how much money 100K HUF is? Does is surprise you to learn that 1 HUF is about half a penny? 100K HUF is ~500 USD.) Browsers do not show this information to users. Hungarian representatives have requested that Mozilla browsers should do so. See bug 277797. Even if browsers did show this information, users are not likely to know the value of the monetary units of various European nations. They do not claim to include this information in non-qualified certs. Apparently the absence of an explicit liability limit should be understood to mean no liability. 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? I would advise Mozilla against trusting certs from a CA that disclaims liability for the information in any of its cert classes. 3. Inclusion of unrecognized critical certificate extensions When bug 277797 was filed, it was claimed that Hungarian law required Hungarian CAs to include in their qualified certificates a certain extension, marked critical, that is relatively unknown. This meant that those certificates were rejected by Mozilla software, because Mozilla software complies with the IETF RFC that requires relying party software to reject certs with critical extensions that it does not completely understand and honor. IMO, Mozilla definitely should not add a root CA cert for a CA whose certs will be rejected for that reason. Hungary has legislated much of this. Perhaps their legislators thought they could pressure the browsers and other software for relying parties into displaying this liability limit information. In summary, although they may be able to claim that they are in conformance with Hungarian law, given these other issues, I'm not convinced this is really a service of value to typical Mozilla product users. That's my opinion. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Microtec CA inclusion request
Nelson B Bolyard wrote: Frank Hecker wrote, On 2008-10-02 14:43: In accordance with the schedule at https://wiki.mozilla.org/CA:Schedule Hi Nelson, Hi Frank, Having read the EU directive at length, here are some perspectives. I have not looked at the CA's request in question. (I think I agree with the logic expressed on OCSP, but not really my cup of tea.) 2. Incentives to be accurate - They have different financial liability limits for each class of cert that they issue, and according to comment 10 in that bug, for one of their classes (class2 non-qualified certificates), that limit is ZERO. For their qualified certs, they include an extension that reports the limit of their liability, as an integer number of Hungarian Forints (HUF). (Tell me, do you know how much money 100K HUF is? Does is surprise you to learn that 1 HUF is about half a penny? 100K HUF is ~500 USD.) Yup, this is a known criticism of the EU's concept. It should disappear somewhat when/if Hungary adopts the euro. (Yes, this doesn't solve the real problem of how much a Euro is worth, but it can be ignored for now, as there are more important things to worry about. If you are fussed at it, ask them whether they can just change over to including a Euro number.) Browsers do not show this information to users. Hungarian representatives have requested that Mozilla browsers should do so. See bug 277797. This is the bigger issue, yes. Browsers should show more information, as otherwise, the certificate must logically be considered to be valueless (see below). In which case, what is the point? The really big question is what should be shown? Europe, for its part, has said it should be the monetary limit on liabilities. I also think that is a bad idea [1] ... but for now, this is what Europe has said, for qualified certs. Even if browsers did show this information, users are not likely to know the value of the monetary units of various European nations. They do not claim to include this information in non-qualified certs. Apparently the absence of an explicit liability limit should be understood to mean no liability. Correct. This should be the standard default of all certificate-based presentation. If there is nothing presented to the user, then there are only two possible interpretations available for the user: that of unlimited liability, and that of zero liability. All numbers inbetween require to be explained. As they are not presented to the user, nor covered anywhere else in an easy-to-understand fashion [2], and as nobody offers unlimited liability, the only logical conclusion is zero liability. If anyone is telling the users anything else, then they had better be prepared to back up that claim in court [3] ! Any cert for which the issuer has no liability is a cert for which the issuer has no incentive to be accurate. That's overly broad. Firstly, there are other checks balances: reputation, audit, mozo-post-audit, sales, the monitoring of people found on this group, laws, regs and customs in the countries, all these things provide incentives. Secondly, the claim of no liability is made to the wider public, generally. The admissions of liability to other insiders like subscribers or under other laws has the effect of providing an incentive to accuracy that is enjoyed by everyone. That is, it is not possible to have a cert that is accurate to paying subscribers but inaccurate to others (Think of it like SB1386, the california breach notification law that only applies in California. When push came to shove, in _Choicepoint_, it magically also applied to all the other states ) Thirdly, they don't have a choice. If they didn't generally disclaim liability, they would be in trouble, one way or another. Fourthly, the issue of CAs' liability under any form has not to my knowledge ever been tested in court. This means that we cannot assert anything with confidence about the positive value of a liability claim (which in effect means the likely value is zero). If a CA has no liability for doing so, what stops it for issuing lots of certs for paypal.com? As above! I would advise Mozilla against trusting certs from a CA that disclaims liability for the information in any of its cert classes. My reading of the CA industry is that CAs routinely limit the _effective liability_ to zero [4]. This is done by a series of legal tricks, all of which work together to reduce any stated liability down to an effective number of zero [5]. Although we may find this uncomfortable, I would suggest that zero liability is the default. The starting position, the reality. The question is then, not whether this is bad and should not be accepted, but whether the CA then goes on to offer something of general use to the browser users. (This is explicit in the mozo policy, for this very reason.) Indeed, I would go so far as to suggest that Mozilla should consider as a
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
Re: Microtec CA inclusion request
István Zsolt BERTA wrote, On 2008-10-06 06:54: 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 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. A trusted responder is a responder CHOSEN BY THE RELYING PARTY. The model is that the user chooses a single OCSP responder to which all of his OCSP requests will be sent. Those OCSP requests may include information about the OCSP URI that was present in the certificate under test, so that the trusted responder may contact the issuer's responder for more information, but the final response received by the requester MUST be signed by the relying party's trusted responder. This model is used in some corporations where the trusted responder sits on a gateway/firewall system where it can be accessed by the users behind the firewall, and will have access to the issuers' OCSP responders on the internet. One reason to do this is to provide caching of OCSP responses. Mozilla products have the configuration option (a preference) by which the user can choose a single OCSP responder to which ALL of that user's OCSP requests will be sent. There is no particular relationship required between that responder and any issuer. The user must have a certificate for that responder and must select it as being THE SOLE cert that the client will trust for those OCSP responses. Based on the above, we consider our solution RFC 2560 conformant. Now, if your OCSP responder is able to act as such a universal trusted OCSP responder, and its cert is available for your customers to download and trust for OCSP responses, then I would agree that *that responder* could be said to be RFC conformant. But if all your certs give AIA extensions that point to that responder, so that all relying party software for users who have not chosen to trust that responder as their delegated responder will still try to access that responder, then that's a problem, because those other users will get a response that they will be unable to prove comes from the issuer of the cert under test. I would not recommend that all Mozilla users should use a Hungarian responder as their delegated OCSP responder. It may be fine for Hungarian users (and any others who wish) to do so, but if only the users who choose to do so (and to pay for the privilege) will have OCSP service for the Hungarian certs, then I think the roots of the issuers of those certs should only be trusted by the users who choose to do so. In other words, the same users who choose to configure their browsers to trust a Hungarian OCSP responder as their delegated OCSP responder could (and should, IMO) also install and trust the associated root CA cert for the certs that will cite that responder for OCSP requests. (We know of other similar solutions, e.g. openvalidation.org works exactly this way.) Users choose to trust that organization's responder as their universal delegated responder, IINM, irrespective of the OCSP URI in the cert under test. 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. According to Indiana legislation, at one time, the value of pi was 3.2. :) My point is that it is unfortunate if Hungarian law/regulation prohibits Hungarian CAs from using OCSP in a way that is useful for the general populace of the Internet, but the rest of the internet is not likely to change its software to accommodate those unfortunate regulations. 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.)
Re: Microtec CA inclusion request
Concerning translation tools this search brought me to some possibilities: http://www.google.com/search?q=translate+hungarian+englishsourceid=navclient-ffie=UTF-8rlz=1B3GGGL_enIL280IL280aq=t -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: [EMAIL PROTECTED] Blog: https://blog.startcom.org ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Microtec CA inclusion request
On 10/06/2008 03:54 PM, István Zsolt BERTA: 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.) openvalidation.org is to all of my knowledge kind of a proxy responder which provides OCSP service for many different CAs (and acts like a proxy). If I'd set the settings of Firefox to only trust your responder it would maybe validate the certificates issued by your CA, but fail all other CA issued certificates. A trusted responder is to all of my knowledge not meant to be used by CAs directly except in case of internal, corporate-wide CAs and OCSP service. Or in the case of a proxy responder as mentioned above. The correct way doing this for public CAs is via the AIA extensions IMO. In your case it would invalid either your own or those of other CAs issued certificates. 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. You are not allowed to issue intermediate CA certificates then? Are you issuing directly from the CA root? Webserver and code signing certificates are generally non-qualified What are the checks performed on code-signing certificates? -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: [EMAIL PROTECTED] Blog: https://blog.startcom.org ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Microtec CA inclusion request
Eddy Nigg wrote: On 10/03/2008 12:43 AM, Frank Hecker: * This CA is based in Hungary. Though it provides a lot of information in English (including a helpful CA hierarchy diagram) unfortunately all of its CPS documents are currently available in Hungarian only. Frank, I think we should buy some tool that helps us with translating such stuff. Apparently Google doesn't support Hungarian - English yet, but I searched and found some useful tools on the net which can do that. Please get something that can translate the CP/CPS and publish it somewhere so we can read about it. We can consider this in the longer term. In the short term Kálmán Kéménczy of the Mozilla localization team for Hungary has confirmed the accuracy of the translations in the Microsoft bug, and is willing to check further translations as needed. Frank P.S. I was out of the office all day, which is why I haven't been participating in the discussion. I'll read all the comments in this thread tonight and comment tomorrow. Frank -- Frank Hecker [EMAIL PROTECTED] ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Microtec CA inclusion request
On 10/06/2008 11:30 PM, Frank Hecker: We can consider this in the longer term. In the short term Kálmán Kéménczy of the Mozilla localization team for Hungary has confirmed the accuracy of the translations in the Microsoft bug, and is willing to check further translations as needed. Frank, I've found some tools online for approximately US$ 50 - 100. If Mozilla can't afford it, I'm willing to contribute it. I found that Babylon is offering now Hungarian - English for free: http://www.babylon.com/definition/Hungary/English Perhaps somebody with a Windows Box can translate all documents from http://www.mozilla.org/projects/security/certs/pending/#Microsec please? I don't know how you read the documents, but I can't pinpoint to something specific without getting an overview and I guess Kalman can't do all of it...I'm not quite sure what the Microsoft Bug is, but considering the comments this request already drew, I want to get a better understanding about the operations of Microsec before commenting on it. -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: [EMAIL PROTECTED] Blog: https://blog.startcom.org ___ 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'll assume he meant Microsec instead of Microsoft, and work from there. (bug 370505) -Kyle H On Mon, Oct 6, 2008 at 3:26 PM, Eddy Nigg [EMAIL PROTECTED] wrote: On 10/06/2008 11:30 PM, Frank Hecker: We can consider this in the longer term. In the short term Kálmán Kéménczy of the Mozilla localization team for Hungary has confirmed the accuracy of the translations in the Microsoft bug, and is willing to check further translations as needed. Frank, I've found some tools online for approximately US$ 50 - 100. If Mozilla can't afford it, I'm willing to contribute it. I found that Babylon is offering now Hungarian - English for free: http://www.babylon.com/definition/Hungary/English Perhaps somebody with a Windows Box can translate all documents from http://www.mozilla.org/projects/security/certs/pending/#Microsec please? I don't know how you read the documents, but I can't pinpoint to something specific without getting an overview and I guess Kalman can't do all of it...I'm not quite sure what the Microsoft Bug is, but considering the comments this request already drew, I want to get a better understanding about the operations of Microsec before commenting on it. -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: [EMAIL PROTECTED] Blog: https://blog.startcom.org ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Microtec CA inclusion request
On 10/03/2008 12:43 AM, Frank Hecker: * This CA is based in Hungary. Though it provides a lot of information in English (including a helpful CA hierarchy diagram) unfortunately all of its CPS documents are currently available in Hungarian only. Frank, I think we should buy some tool that helps us with translating such stuff. Apparently Google doesn't support Hungarian - English yet, but I searched and found some useful tools on the net which can do that. Please get something that can translate the CP/CPS and publish it somewhere so we can read about it. Additionally I went to http://srv.e-szigno.hu/ and after accepting the security exception when browsing to https://srv.e-szigno.hu:/cgi-bin/editugyvedcsv.cgi I received first received ssl_error_handshake_failure_alert. I realized that I have to add their CA root, so I did that, but then I got sec_error_ocsp_malformed_request. The default settings of FF3 is to use OCSP and as you mentioned, this isn't going to work (as you mentioned already). Can you have a look into both issues above? I really would like to read the CP/CPS and a translation tool for a few bucks would help... -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: [EMAIL PROTECTED] Blog: https://blog.startcom.org ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Microtec CA inclusion request
In accordance with the schedule at https://wiki.mozilla.org/CA:Schedule I am now opening the first public discussion period for a request from Microtec Ltd to add the Microsec e-Szigno Root CA root certificate to Mozilla. This is bug 370505, and Kathleen has produced an information document attached to the bug. https://bugzilla.mozilla.org/show_bug.cgi?id=370505 There's a summary of the information also available at http://www.mozilla.org/projects/security/certs/pending/#Microsec Some points worth mentioning about this request: * This CA is based in Hungary. Though it provides a lot of information in English (including a helpful CA hierarchy diagram) unfortunately all of its CPS documents are currently available in Hungarian only. Microsec has provided translations of the relevant sections in the bug comments, as well as other background information. I've asked András Tímár [1] of the Hungarian localization team to double-check the translations; for now I'm assuming the translations are accurate absent any information to the contrary. * Though a commercial CA, Microsec is audited by an agency of the Hungarian government. (This appears to be a fairly common practice in Europe, especially for CAs issuing so-called qualified certificates, as Microsec does.) The audit is against ETSI TS 101 456 and 102 042 and is annual. Kathleen has verified the relevant information with a government representative. * Microsec has a separate root used for OCSP, and apparently does not offer OCSP as a general public service; please see the comments in the bug. I'd like those of you who are OCSP experts to look at this issue and tell us if you see any potential problems there. This first public comment period will be for one week, and then I'll make a preliminary determination regarding this request. Frank [1] Fun fact: Within Hungary names are normally given in Eastern order (i.e., like China or Japan) with surname first. In this case I've transposed to Western order (I think). -- Frank Hecker [EMAIL PROTECTED] ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
