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. Frank -- Frank Hecker hec...@mozillafoundation.org ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
DSV/S-TRUST root inclusion request
I've decided to make S-TRUST the next CA to enter the public discussion period. (I need to do a little more work for KISA, T-Systems, and Microsec, the other CAs near the top of the list.) S-TRUST is operated by Deutscher Sparkassenverlag (DSV), which has applied to add four new root CA certificates to the Mozilla root store, as documented in the following bug: https://bugzilla.mozilla.org/show_bug.cgi?id=370627 and in the pending certificates list here: http://www.mozilla.org/projects/security/certs/pending/#S-TRUST Some quick comments regarding noteworthy points: * S-TRUST issues certificates to individuals for use in SSL client authentication and email. Since they don't issue certificates to SSL servers, right now I've got them marked as requesting that only the email "trust bit" be enabled. However, does the SSL trust bit need to be enabled for S-TRUST client certificates to be properly recognized at either the client or server end? I can't remember the answer for this, and would appreciate advice. * Per German law S-TRUST issues one new root CA certificate for every year, with each root cert having a 5-year lifetime. Thus they are currently requesting inclusion of four root certificates, for 2005 through 2008. Starting in 2010 the older root certs will begin to expire and we can remove them. * The CPS documents are in German (sorry Eddy!), but as far as I know we have English translations of the relevant sections, and can do further translations as needed. * S-TRUST has undergone audits per the ETSI TS 101 456 and 102 042 criteria. The relevant audit certificates are still current. I suggest reading Kathleen's summary document to get an overview of this request; thanks again to Kathleen for preparing these! As we did with SECOM Trust, I'm planning to have a single one-week discussion period. After that week, if there are no outstanding issues relating to the request then I am going to go ahead and officially approve it. (Otherwise we'll postpone further discussion until the issues are resolved.) Frank -- Frank Hecker hec...@mozillafoundation.org ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: DSV/S-TRUST root inclusion request
On 12/16/2008 07:43 PM, Frank Hecker: However, does the SSL trust bit need to be enabled for S-TRUST client certificates to be properly recognized at either the client or server end? Absolutely not. Email is sufficient for S/MIME and authentication. * Per German law S-TRUST issues one new root CA certificate for every year, with each root cert having a 5-year lifetime. Thus they are currently requesting inclusion of four root certificates, for 2005 through 2008. Starting in 2010 the older root certs will begin to expire and we can remove them. This is unfortunate and seems to me problematic. I'd suggest that they create a root from which they'd issue those as intermediate. I'm almost certain that other vendors will not include them for the same reason (so it's not an argument in itself, it just shows the limits of reason for inclusion - some vendors do have specific requirements in this regard which we don't). However I want to think more about it (if it's reasonable). * The CPS documents are in German (sorry Eddy!), Why sorry? I speak fluently Germangoing to have a look at it if the above isn't an issue. I suggest reading Kathleen's summary document to get an overview of this request; thanks again to Kathleen for preparing these! Yes, they are always excellent! I really love the work Kathleen performs, it speeds everything so much up! -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: start...@startcom.org 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: DSV/S-TRUST root inclusion request
Eddy Nigg wrote re S-TRUST issuing new root certificates annually: This is unfortunate and seems to me problematic. I'd suggest that they create a root from which they'd issue those as intermediate. I'm almost certain that other vendors will not include them for the same reason (so it's not an argument in itself, it just shows the limits of reason for inclusion - some vendors do have specific requirements in this regard which we don't). However I want to think more about it (if it's reasonable). Please feel free to mention this issue in the bug. However I suspect that S-TRUST is constrained in its practices by the relevant German laws and/or EU directives. Unfortunately I couldn't find any references that address this particular issue. (Incidentally, when I was trying to find out more information about this issue, one of my Google searches returned this as one of the top results: http://www.springerlink.com/content/b586573164k873p4/ I'm sure many of you will find the title of this book quite apropos.) Why sorry? I speak fluently Germangoing to have a look at it if the above isn't an issue. Excellent. I'm glad that after a diet of Hungarian and Japanese we have something more to your taste :-) Frank -- Frank Hecker hec...@mozillafoundation.org ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: DSV/S-TRUST root inclusion request
On 12/17/2008 12:04 AM, Frank Hecker: Please feel free to mention this issue in the bug. However I suspect that S-TRUST is constrained in its practices by the relevant German laws and/or EU directives. I'm not aware of such an EU directive (and we would have known by now from other inclusion requests). It might be some specific German law and if proved correct would just show, that they haven't thought it through. How can the law makers expect to have software vendors update and add and remove roots in that manner. That's fine for one CA, but there are potentially tens if not hundreds. Incidentally I think it unreasonable to include a root which will have to be removed in less than a year or two. Anyway, I'll ask for more information on this subject. (Incidentally, when I was trying to find out more information about this issue, one of my Google searches returned this as one of the top results: http://www.springerlink.com/content/b586573164k873p4/ Ha, just don't let them to make it one :-) Why sorry? I speak fluently Germangoing to have a look at it if the above isn't an issue. Excellent. I'm glad that after a diet of Hungarian and Japanese we have something more to your taste :-) Well, they are all very nice people, but in the end of the day I can't read it :S Considering the various issues I found so far during the last two years? or so...I don't feel really comfortable with those. Somehow it's expected that such documents are (also) published in English, specially since other will have to rely on the issued certificates without having a chance to understand what they are about. I think you just mentioned about the same somewhere else... -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: start...@startcom.org 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: DSV/S-TRUST root inclusion request
On 12/17/2008 01:26 AM, Frank Hecker: That's a good idea, I'll do that. I'd like to get a definitive answer on this question, since I know I've seen this practice with other CAs, including I think at least one not in Germany. Frank, I asked about it at the bug already earlier. Once I get the information I'll be glad to provide information about it, including translation about the important parts (if this suits us). -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: start...@startcom.org 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: DSV/S-TRUST root inclusion request
Ian G wrote re creating new root certificates annually for CAs issuing qualified certificates: It is most likely in the regulations that are created by the regulating agency; that is the way these things work. I think that is the telecommunications regulator. Likely, these things are not translated into English. (The simplification of "law" is often meant to include these things.) I suspect you are right about this. (I couldn't find anything about this practice in EU documents I found.) If you really wanted to do see it, the thing to do would be to ask for the specific regulations, and get them translated. That's a good idea, I'll do that. I'd like to get a definitive answer on this question, since I know I've seen this practice with other CAs, including I think at least one not in Germany. Frank -- Frank Hecker hec...@mozillafoundation.org ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: DSV/S-TRUST root inclusion request
On 16/12/08 23:04, Frank Hecker wrote: Eddy Nigg wrote re S-TRUST issuing new root certificates annually: Please feel free to mention this issue in the bug. However I suspect that S-TRUST is constrained in its practices by the relevant German laws and/or EU directives. Unfortunately I couldn't find any references that address this particular issue. I don't see it in Annex II of DIRECTIVE 1999/93/EC, which would be the technical place if it was in the Directive. It is also not in the SigG which is the German implementation of the directive. (The way it works is that the EU directive binds the governments, which have to pass laws to bind the people. So the directive does not bind the people, or in this case the CA.) It is most likely in the regulations that are created by the regulating agency; that is the way these things work. I think that is the telecommunications regulator. Likely, these things are not translated into English. (The simplification of "law" is often meant to include these things.) If you really wanted to do see it, the thing to do would be to ask for the specific regulations, and get them translated. Just some thoughts! iang ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: DSV/S-TRUST root inclusion request
Frank Hecker wrote: I've decided to make S-TRUST the next CA to enter the public discussion period. (I need to do a little more work for KISA, T-Systems, and Microsec, the other CAs near the top of the list.) S-TRUST is operated by Deutscher Sparkassenverlag (DSV), which has applied to add four new root CA certificates to the Mozilla root store, as documented in the following bug: https://bugzilla.mozilla.org/show_bug.cgi?id=370627 and in the pending certificates list here: http://www.mozilla.org/projects/security/certs/pending/#S-TRUST Some quick comments regarding noteworthy points: * S-TRUST issues certificates to individuals for use in SSL client authentication and email. Since they don't issue certificates to SSL servers, right now I've got them marked as requesting that only the email "trust bit" be enabled. However, does the SSL trust bit need to be enabled for S-TRUST client certificates to be properly recognized at either the client or server end? I can't remember the answer for this, and would appreciate advice. In the presently released versions of Firefox, (or other NSS SSL clients) no trust flag is necessary for a cert to be used for client authentication. This is because the server tells the client which CAs are trusted by the server, and the client picks a cert that is issued by one of the CAs named by the server. In an NSS server, the list of CA names sent out to remote clients when asking them for client authentication is determined from the set of certs that have the special SSL client auth CA trust flag. By default NO CA certs ever have that flag set. Server admins must set that flag explicitly. * Per German law S-TRUST issues one new root CA certificate for every year, with each root cert having a 5-year lifetime. Have they legislated that pi is 3 again? New ROOT CA certificate? really? Root? Is the requirement for a new cert? or for a new key? That is, can each of the certs issued one year apart have the same key? Thus they are currently requesting inclusion of four root certificates, for 2005 through 2008. Starting in 2010 the older root certs will begin to expire and we can remove them. Do the new certs for S-TRUST have the same key, or do they have different keys? If they have different keys, do they also have different subject names? Do they have different Subject Key ID (SKID) extension values? Do the certs they issue have Authority Key ID (AKID) extensions? This whole thing makes little sense, and is a pretty big concern. Remember that unlike SSL server and client authentication, signatures on emails and other types of files should be long lasting, and should be verifiable for a long time. You don't want all the encrypted emails in your mail folders to suddenly become unreadable because the signatures on those messages can no longer be verified, because a CA cert has expired and has not been renewed. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: DSV/S-TRUST root inclusion request
On 12/17/2008 03:42 AM, Nelson B Bolyard: Do the new certs for S-TRUST have the same key, or do they have different keys? If they have different keys, do they also have different subject names? Do they have different Subject Key ID (SKID) extension values? Do the certs they issue have Authority Key ID (AKID) extensions? Nelson, see this attachment from Kathleen: https://bugzilla.mozilla.org/attachment.cgi?id=337729 scroll to page two and come to your own conclusions. -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: start...@startcom.org 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: DSV/S-TRUST root inclusion request
Eddy Nigg wrote: Frank, I asked about it at the bug already earlier. Once I get the information I'll be glad to provide information about it, including translation about the important parts (if this suits us). Thank you. I also sent an email message to the representatives of DSV, alerting them to the start of the public discussion period and asking them to respond to this question. Frank -- Frank Hecker hec...@mozillafoundation.org ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: DSV/S-TRUST root inclusion request
Eddy Nigg wrote, On 2008-12-16 18:20: > On 12/17/2008 03:42 AM, Nelson B Bolyard: >> Do the new certs for S-TRUST have the same key, or do they have >> different keys? If they have different keys, do they also have different >> subject names? >> Do they have different Subject Key ID (SKID) extension values? >> Do the certs they issue have Authority Key ID (AKID) extensions? > > Nelson, see this attachment from Kathleen: > https://bugzilla.mozilla.org/attachment.cgi?id=337729 scroll to page two > and come to your own conclusions. One of the reasons I asked the question is that MS Word files present a problem for me. But I did dig up the URLs for the 4 CA certs, and examined those certs. Each of them has a separate subject name, public key, subject key ID, authority key ID, and of course validity period. To be honest, I think this is a burden that Mozilla ought not to bear. Mozilla should not put itself into a position of needing to add a new root CA cert for this CA every year, and then keep them for a long time thereafter. Further, if (as the bug suggests) the REAL PRIMARY purpose of this CA is to provide German citizens with SSL client certificates, and it is not used to issue SSL server certs, then it is (or should be) unnecessary for their browsers to have this CA cert AT ALL. For SSL client auth purposes, it's quite sufficient for the browser to just have the user's cert and private key and no CA cert at all. The server sends down a message saying "if you have a cert issued by this CA, send it". The browser examines the certs it possesses to find ones that have the desired string in the issuer name, and for which the browser has the private key. Having the CA cert is unnecessary. While some German law or regulation may require them to issue new roots annually, I doubt that it prevents them from also issuing intermediate CA certs with the same subject name, key, subject key ID, etc, but issued by some single common root that changes infrequently (these are so-called cross signed CA certs). With such a scheme, that root that issues the cross signed certs can be the one to get put into Mozilla with email trust. So, My advice is: just say no. Don't take on the burden of adding a new root CA cert every year when there is no good need. Please consider this an objection to including those roots in the root CA list. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
