Re: DSV/S-TRUST root inclusion request
Eddy Nigg wrote: Update: One of the CA roots requested for inclusion is valid until 2030: S-TRUST Authentication and Encryption Root CA 2005:PN Valid until: 06/22/2030 02:59:59 The above mentioned issue does not apply to this root. Incidentally this root was also included at Microsoft, the others not. There is no objection to include the Authentication and Encryption root from S-Trust as far as I can see. I agree on the inclusion of S-TRUST Authentication and Encryption Root CA 2005:PN, and so I'm going to go ahead and formally approve that. On the inclusion of the other roots, there is nothing in our policy that addresses the issue of short-lived roots. However the consensus seems to be that this practice is not actually legally-required, and it does pose a burden on us. I'm therefore OK with not including the other roots for now, and encouraging S-TRUST to move to a scheme where they use a longer-lived root for these certs. Kathleen, could you post a summary to bug 370627, and then ping me for final approval? 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 01/22/2009 08:35 PM, Eddy Nigg: I've received answers from the representative of S-Trust at the bug. As suspect right from the beginning, there is no such law or requirement as claimed initially that justifies the issuing of new roots every year for a life-time of only five years. For further reference see bug 370627 from comment 47 onwards: https://bugzilla.mozilla.org/show_bug.cgi?id=370627#c47 According to comments made by Nelson and others, I suggest to refrain from including this CA at this time. Their model is hardly sustainable, unnecessary complicated for no apparent benefit. Some of the documents I reviewed from the Bundesnetzagentur even explicitly discourages their implementation. Update: One of the CA roots requested for inclusion is valid until 2030: S-TRUST Authentication and Encryption Root CA 2005:PN Valid until: 06/22/2030 02:59:59 The above mentioned issue does not apply to this root. Incidentally this root was also included at Microsoft, the others not. There is no objection to include the Authentication and Encryption root from S-Trust as far as I can see. -- 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 16.12.2008 18:43, Frank Hecker wrote: S-TRUST is operated by Deutscher Sparkassenverlag (DSV) Just a little background on this: Sparkasse is a mutual savings bank. They are fairly popular in Germany: Every region has its own (and their geographical coverage usually does not overlap much), and combined they have a decent market share (40% +/-10 % I'd guess). They are non-profit. They have a shared company which does some of the IT for them. Given that banks have to authenticate their customers by identity card, by money laundering laws, the verification is about as strong as it gets in practice. (Some of them have Internet banks, though, which may authenticate using the post office using a special scheme called PostIdent - but even that requires the ID card and an in-person signature). A weakness may be that the customer keys are stored on a chip on the bank debit card (like credit card, just without credit), and the cards may be sent by normal postal mail, normal letters, so there's a way to intercept them. The PIN code (to use ATM machines, not sure if needed to access the PKI keys) is sent as normal postal mail as well, but in a separate letter on a different day, in a special envelope protecting against shine through. Of course, people wear these cards in their purse all the time, so that may be stolen. All of what I wrote is from memory, so there might be slight incorrectness. I have only glanced over their CPS, not read it. HTH anyways. Ben -- 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 01/27/2009 10:36 PM, Ben Bucksch: On 16.12.2008 23:04, Frank Hecker wrote: 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. Even if so, such a law wouldn't preclude a root *specifically for us* that just signs all the others. Given that only browsers trust that root, the law wouldn't care about it. First of all there is no such law as claimed in the CP/CPS of S/Trust. Please see the bug entries and conclusive reporting here in relation to that. Second, I've proposed to them to issue such a root and sign their short-living CAs from that root. This would most likely allow them to have this root included here and other vendors as well. Of course this requires some changes at their side including CP/CPS and auditing, but it should be entirely possible to achieve it within less than a year. In the meantime I propose to have their long-living root included in NSS (if no other concerns should be raised). -- 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
(OT: Just culture) On 17.12.2008 13:11, Ian G wrote: Have they legislated that pi is 3 again? Welcome to Europe, we hope you enjoyed your flight, and will travel on pi airlines around the globe again :) For the record, it was the US - Indiana specifically - which legislated pi, see a quick google legislating pi. In Germany, the politicians and bureaucrats bought into the PKI thing in a big way, and proceeded to make it part of their business. True. Now, in Germany, unlike in other places, they tend to do things only when there is a law to back them up. Also true, when it comes to bureaucracy, because said bureaucracy is heavily determined by the most complex tax laws in the world, and other regulations. In general, things are more regulated, and yes, that's cultural - which has good and bad parts. For example, the windows actually keep the warm in, because the house builder is *forced* to use good isolation. But, as the later posts said, there is *no such law* or regulation which forced a new root each year. You see a lot of hot air about laws, regulations and courts, both in US and Germany. -- 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 22/1/09 20:53, Kyle Hamilton wrote: (sorry for the late response.) On Wed, Dec 17, 2008 at 4:20 AM, Ian Gi...@iang.org wrote: On 17/12/08 12:42, Kyle Hamilton wrote: But... ... and would also violate the archival principle (that signatures of archived documents can be verified via the presence of a timestamp from a reputable timestamping authority and a trust anchor which still needs to be available). Yes, to recall an unpopular claim of mine: digital signing where it attempts to mimic human signing should be deprecated in poorly architectured applications like S/MIME. For reasons just like these. (BTW, where is this archival principle documented?) Aside from audits, Thanks for the answer! As I read it, WebTrust 8,11 requires that documentation cover any publication. I do not recall any archival *requirement*. There is however section 2 of the Chokhani et al RFC layout for CPSs which is basically document your archives. It is true that DRC B.2.h says A list of subscriber certificates is available to subscribers and the general public including... however this is somewhat troubling, from both business perspectives and privacy perspectives, and I for one am not pushing this particular criteria. it's also basically required by US Federal Court Rules of Civil Procedure 26 and 34, as effective 12/2006. Any court may require that any evidence submitted be authenticated. Without the root available to authenticate... Well, ok, so this is a general principle of evidence in court. If one intended to present evidence, then archiving it properly would be a mighty fine idea. However: * I don't think I've come across any *general expression* of how to present evidence in the CA world, listed for the benefit of subscribers or relying parties. It doesn't seem as though one of the selling points for certificates is that you can present this as evidence in a court. * A CA could respond that a certificate is not intended for that purpose. I would see this as likely, but I guess we would have to ask CAs what they thought. * (CAs typically maintain a private repository, but that is for the benefit of the CA, generally.) * Not to mention in any depth the jurisdiction issues here. 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
(sorry for the late response.) On Wed, Dec 17, 2008 at 4:20 AM, Ian G i...@iang.org wrote: On 17/12/08 12:42, Kyle Hamilton wrote: But... ... and would also violate the archival principle (that signatures of archived documents can be verified via the presence of a timestamp from a reputable timestamping authority and a trust anchor which still needs to be available). Yes, to recall an unpopular claim of mine: digital signing where it attempts to mimic human signing should be deprecated in poorly architectured applications like S/MIME. For reasons just like these. (BTW, where is this archival principle documented?) Aside from audits, it's also basically required by US Federal Court Rules of Civil Procedure 26 and 34, as effective 12/2006. Any court may require that any evidence submitted be authenticated. Without the root available to authenticate... Remember that it's not 'mimicing human signing'. It's preventing modification of what was originally sent. (It's rather like the process of committing logs -- if the logs need to be verifiable that nothing has been retroactively added or removed or changed, they need to have some means of chaining the IV from the prior log entry.) It is perhaps fun to laugh about the silly Germans ... but consider: their digital signature project is very serious, it is strongly supported by the tax authorities and they fully intend for tax submissions to be signed. They have already passed or attempted to pass the legislation to make this so. Also, Germany is heartland for Mozilla. There are more supporters there than other places, in general. That's because in the US, Firefox is coming to be viewed as an evil lesser than but akin to IE. -Kyle H -- 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 19/12/08 03:45, Nelson B Bolyard wrote: According to my mail client, Ian G wrote on 2008-12-17 04:11 PST: [paraphrasing liberally: Europeans let their legislatures do their engineering.] A fair comment, but it isn't as one sided as all that. Lot of countries have created their own legislation or regulation for security software, and then sat back and waited for others to implement their designs ... and waited ... and waited ... and waited ... Governments indeed have discovered that they are just players in the market when it comes to Internet. Sometimes weak, sometimes powerful. This may well be just another case. It may well be, granted. The point I would make is that if QC is going to succeed, then the place to watch is Germany. Just an opinion. They are the ones who care the most *and* have the most weight. (It is actually further along in some other places, like Estonia, but they have no weight.) But, I agree with you that it is still an if not a when. Now, what do you do about it? Mozo is in a difficult position. No, not a bit. The governments in most countries are accustomed to being obeyed unquestioningly. They act astonished when NONE of the popular browsers implement the requirements they try to impose. Tsk tsk. It isn't about being obeyed, so much as getting changes and bug fixes done at the architectural level and above. If you go to the CAs there, they will likely not appreciate your perspective on the problem. Their perspective on the problem for them comes from their regulations. They've spent the last N years building up to get that done. They only come to the browsers as a last step. Mozilla (indeed, all browsers) have successfully ignored lots of silly regulations from individual countries. A good example of that is regulation that requires the CAs in one country to put into their certs a monetary limit on the financial value of the transactions done that use those certs, a limit using the nation's own monetary units, and to require any software that uses those certs to dishonor those certs until they are prepared to enfore those limits. Mozilla software happily dishonors all those certs. There are other examples as well. Sure. Easy one. Were they marked as critical extentions? As we have discussed in this group before, Mozo's principle is to pass these questions across to the standards committee. For sake of argument, this would be the PKIX committee. Wrong, but nice try. If we agree to disagree that could be as far as it goes. On the other hand, you could state what it is that you feel that is wrong in the above description ... and we could explore and learn. I'll go first: when we had a debate about revocation of the root, you finalised that debate by accepting that there was a problem, and that PKIX was the place for it to be fixed. It wasn't up to Mozo. Hence, I mention it above. In the mission of Mozilla, it states that we follow the standards process. And, this includes security. With respect, which part do you believe is wrong? However, national law trumps standards committees. LOL. You may laugh, but the CA in question is not enjoying the joke. I wish it were different. But, it isn't. So, some country says our citizens must use browsers that do this, and no browsers do this, and eventually the country realizes that they must relent or else have their citizens live in the dark ages. Yes, that is what happens. In China, Skype has to ship a special version with some secret MITM in it (speculation, I don't know what it is). Likewise in ebay and yahoo, they both had to make global changes because of the French. If you look at Paypal and SL there are similar problems, caused by governments. Probably you recall the old days where Netscape had to ship in two different versions because of the USA government. Please don't interpret my words personally, I play the other side to explain things, not to start arguments. I also don't like the fact that Skype has to breach the security of users. I also don't like qualified certificates, and have written elsewhere much against them. What to do about these things is a much more complex problem. Eventually they relent. That's what happened to the requirement about the monetary limits in certs. The monetary limits are still there, but are now marked as saying that the software that uses those certs is now free to honor those certs even if it ignores those limits, and browsers all do so. Yes, that was an easy one, the design was borked from the start, like that RFC that Anders posted. Mozilla doesn't seem to have had to deal with the hard choices here, but the CAs in question do. Getting back to the only issue I can recall, from Frank's original mail: * 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
Re: DSV/S-TRUST root inclusion request
According to my mail client, Ian G wrote on 2008-12-17 04:11 PST: [paraphrasing liberally: Europeans let their legislatures do their engineering.] Lot of countries have created their own legislation or regulation for security software, and then sat back and waited for others to implement their designs ... and waited ... and waited ... and waited ... This may well be just another case. Now, what do you do about it? Mozo is in a difficult position. No, not a bit. The governments in most countries are accustomed to being obeyed unquestioningly. They act astonished when NONE of the popular browsers implement the requirements they try to impose. Tsk tsk. Mozilla (indeed, all browsers) have successfully ignored lots of silly regulations from individual countries. A good example of that is regulation that requires the CAs in one country to put into their certs a monetary limit on the financial value of the transactions done that use those certs, a limit using the nation's own monetary units, and to require any software that uses those certs to dishonor those certs until they are prepared to enfore those limits. Mozilla software happily dishonors all those certs. There are other examples as well. As we have discussed in this group before, Mozo's principle is to pass these questions across to the standards committee. For sake of argument, this would be the PKIX committee. Wrong, but nice try. However, national law trumps standards committees. LOL. I wish it were different. But, it isn't. So, some country says our citizens must use browsers that do this, and no browsers do this, and eventually the country realizes that they must relent or else have their citizens live in the dark ages. Eventually they relent. That's what happened to the requirement about the monetary limits in certs. The monetary limits are still there, but are now marked as saying that the software that uses those certs is now free to honor those certs even if it ignores those limits, and browsers all do so. ___ 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 17/12/08 02:42, Nelson B Bolyard wrote: Frank Hecker wrote: * 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? Welcome to Europe, we hope you enjoyed your flight, and will travel on pi airlines around the globe again :) 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? Certainly, these questions I would like answered too, and I wonder if we can get them, and the answers onto the wiki? This whole thing makes little sense, and is a pretty big concern. This is partly a cultural thing, and partly a case of be careful what you wished for. In Germany, the politicians and bureaucrats bought into the PKI thing in a big way, and proceeded to make it part of their business. Now, in Germany, unlike in other places, they tend to do things only when there is a law to back them up. In (say) America, they tend to do things when there is no law saying you can't. It's a cultural thing. The law was created in typical European style: EU directive = enacting local law = regulator and regulations = private market controls, that last step being somewhat familiar as audits, etc. Now, as we know, a lot of the stuff that PKI people said was hopeful, written down in advance of any large scale real world implementation. There are many gaps. When the Germans (or anyone else) came along and tried to regulate it, they had to fill in the gaps, because in their view, there should be no gaps, there should a law plus regulation. The obvious happened: they filled in some gaps, but their solution was different to anyone else's. Consider above, that the EU directive is 6 pages long. That means there are substantial gaps in how to do things, and therefore there are differences in the interpretations of the national perspectives. One final gotcha to make it all the more delicious: in the EU directive (and therefore in the national laws) it says that all qualified implementations from other countries have to be accepted without question in your local country. Which means that which is explicitly banned in one country can be acquired from neighbouring country, and must be accepted, even if banned in national law. Yes, this has cause wonderful clashes. Now, what do you do about it? Mozo is in a difficult position. As we have discussed in this group before, Mozo's principle is to pass these questions across to the standards committee. For sake of argument, this would be the PKIX committee. However, national law trumps standards committees. I wish it were different. But, it isn't. 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
Nelson B Bolyard wrote: 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. Understood, but these certificates are also usable for email, even if it's a secondary use, and hence having the root embedded is relevant for Thunderbird, SeaMonkey, et.al. (And of course, just because email is a secondary use now doesn't mean it will always be so.) 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
I would request PDF. (Then again, I'd also request a signed PDF; maybe Kathleen can get a PDF signing cert from StartCom? ;)) -Kyle H On Wed, Dec 17, 2008 at 2:31 AM, Eddy Nigg eddy_n...@startcom.org wrote: On 12/17/2008 08:54 AM, Nelson B Bolyard: One of the reasons I asked the question is that MS Word files present a problem for me. I use OpenOffice, and you? Kathleen could have published those files as ODT, but I suspect that for the benefit of all users, she preferred to publish DOC files so everybody could read them, also those which DO use MS software for this purpose. Perhaps she should publish them as PDF in the future. 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. As suspected and indicated in the document. 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. As indicated earlier, I think it unreasonable as well. And this is really unfortunate, since it could have done a lot of good for S/MIME, specially when considering the high usage/market share of Mozilla products in Germany and the chance to have some 40 million potential users encrypting mail. I will wait for their response at the bug and examine the regulation of the law they referred to. But most likely it won't change anything in the end. It's hard to serve two masters in this case... -- 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 ___ 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 17/12/08 11:31, Eddy Nigg wrote: On 12/17/2008 08:54 AM, Nelson B Bolyard: One of the reasons I asked the question is that MS Word files present a problem for me. I use OpenOffice, and you? Me too on both. MS Word or ODT files are a pain. I just want read the stuff, not have to fire up NeoOffice and fight my way through the million editing options. Perhaps she should publish them as PDF in the future. Agreed! Wordprocessing formats in all their guises are for preparation and editing, not for publication. The documents posted on the wiki are published, there isn't a sense where I download the documents and then patch them up a bit and send them back. PDF seems to be a reasonably common form for publication. Perhaps add a comment in the Checklist that PDF is preferred rather than word processing formats (e.g., Word). 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
On 17/12/08 12:29, Kyle Hamilton wrote: ... (Then again, I'd also request a signed PDF; maybe Kathleen can get a PDF signing cert from StartCom? ;)) LOL... what happens when a CA puts up a signed document? Well, you can't trust it because the CA isn't yet in the root list. In general, it is good to eat ones own dogfood. However this should not be mixed up with *the production* of the same. Here, we are producing the dogfood, so we must not also consume it. If we also consume it, we are entering into the mad cow production chain. iang PS: American expression to mean, use ones own product. ___ 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 17/12/08 12:42, Kyle Hamilton wrote: I would very much like to see the implementing regulations that they think causes them to need a new root rekey every year. Yes, worthwhile to ask for that, because it will prepare the ground for the other German CAs. But... ... and would also violate the archival principle (that signatures of archived documents can be verified via the presence of a timestamp from a reputable timestamping authority and a trust anchor which still needs to be available). Yes, to recall an unpopular claim of mine: digital signing where it attempts to mimic human signing should be deprecated in poorly architectured applications like S/MIME. For reasons just like these. (BTW, where is this archival principle documented?) To make matters worse, even if you wanted to follow my unpopular advice there, the European experiment is designed precisely for this market: digital human signing by qualified certificates. Hence, if you enter this area, you should do things *their way*; the signatures will be contested in European courts by European lawyers under European laws. If Mozilla doesn't work within the framework, then there could be problems... And to recall another unpopular suggestion: Mozilla should clarify the agreement it has with end-users, and with CAs, so as to set the liabilities in advance, in preparation for these cases. Until the regulations are produced, I am STRONGLY AGAINST these roots' inclusion. Even after the regulations are produced, I'm still very likely going to be against it, though I am not stating absolutely no at this time. (They may actually have a reason that I'll accept. I doubt it, but I'll hold out hope... if for no other reason than to point and laugh at the German government when they express a completely unfounded fear.) It is perhaps fun to laugh about the silly Germans ... but consider: their digital signature project is very serious, it is strongly supported by the tax authorities and they fully intend for tax submissions to be signed. They have already passed or attempted to pass the legislation to make this so. Also, Germany is heartland for Mozilla. There are more supporters there than other places, in general. If I were able to commit Mozilla to any future action, what I'd do: Refuse their request and inform them to tell their regulatory agency to get in touch with Mozilla and other browser vendors to understand why it's an unacceptable burden. Those regulatory agencies need to get input on best current practices, and help to figure out how to rewrite the regulations so that they don't impose such a burden on the browsers. Law trumps standards committees, best current practices, help from browser vendors, etc. Also, bear in mind that Mozilla has expressely and deliberately outsourced this question to their standards committees. It is in the mission statement. Mozilla has already declined a role at this table. This is why I say be careful what you wish for... 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
snip Eddy Nigg wrote: 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. As indicated earlier, I think it unreasonable as well. And this is really unfortunate, since it could have done a lot of good for S/MIME, specially when considering the high usage/market share of Mozilla products in Germany and the chance to have some 40 million potential users encrypting mail. Although Swedish authorities have done a lot of strange things in PKI, I am happy that their broken scheme doesn't allow verification by clients [*], since that could have caused major help-desk issues if people believed that encrypted mail actually is a working application :-) Anders *] Root is secret and OCSP calls require a contract + requester certificate ___ 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
I would very much like to see the implementing regulations that they think causes them to need a new root rekey every year. A new CA issued by a root, sure... but a new root? That's outlandish and a substantial burden on the browser vendors. I agree with the cross-certification aspect of Nelson's suggestion. If it's to enable TLS client authentication (and not S/MIME), there's absolutely no reason for the client to have this, since the client's PKCS#12 file will include the issuing root anyway. If it is for S/MIME, email-bit is appropriate on the client side, and the root should be present. But... expecting browser vendors to update their certificate lists every year for a single organization would mean that the browser vendors would have to expect to update the certificate list every year for ALL organizations, and would also violate the archival principle (that signatures of archived documents can be verified via the presence of a timestamp from a reputable timestamping authority and a trust anchor which still needs to be available). Until the regulations are produced, I am STRONGLY AGAINST these roots' inclusion. Even after the regulations are produced, I'm still very likely going to be against it, though I am not stating absolutely no at this time. (They may actually have a reason that I'll accept. I doubt it, but I'll hold out hope... if for no other reason than to point and laugh at the German government when they express a completely unfounded fear.) If I were able to commit Mozilla to any future action, what I'd do: Refuse their request and inform them to tell their regulatory agency to get in touch with Mozilla and other browser vendors to understand why it's an unacceptable burden. Those regulatory agencies need to get input on best current practices, and help to figure out how to rewrite the regulations so that they don't impose such a burden on the browsers. -Kyle H On Tue, Dec 16, 2008 at 10:54 PM, Nelson B Bolyard nel...@bolyard.me wrote: 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 ___ 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
