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 criteria that every CA has a limitation of liability to all Mozilla users (e.g., the general public). And that the number should be strongly recommended by Mozilla to be zero, or there is a serious audit requirement to show how this number can be met. To not set general liability to zero begs the question of just how we differentiate this amount from fantasy, and as it is a legally significant claim, and one that is intended to be believed by Mozilla users, it should be seriously checked. And, I would suggest that Mozilla do the same, by limiting its own liability to zero (and, it appears, thankfully, that Mozilla is doing exactly that in the new terms & conditions for Firefox). > 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. This is the EU directive, which is implemented in law in most states. Consider a directive to be similar level to federal US law. The difference is that in Europe, first the "federal body" writes the directive (as a committee of states' representatives), then the states write the compatible law, following the directive. So, from the EU directive (at least one old copy): ================== 5. Member States shall ensure that notwithstanding paragraph 1, a certification service provider may, *in the qualified certificate*, limit the value of transactions for which the certificate is valid. The certification service provider shall not be held liable for damages in excess of that value limit. ================== (my emphasis) Now, bearing in mind that the whole digital signing thing in Europe is *complex*, we can suggest that *if* an issuer wishes to put in a monetary limit of liability, it *must* put that limit in the certificate. If it does not, then likely it has unlimited liability (within other restrictions), because it is explicitly offered the option to disclaim in the law. Now, no issuer nor business in its right mind accepts unlimited liability [6]. So some number must be put in. So, I for one would concur with their claim that they must put that number in by law. This raises several conundrums: 1. for users, they will inspect the cert (to the extent that they can) and will see either nothing or a number. This might be a good number (they can sue) or it might be a suspect number (other legal tools reduce the effective liability to zero). That will not be showable in the cert, IMO, so it raises the issue of how we show whether the number is effective or not. 2. if the users don't see the number, and the number is strong in law (as it most surely is because of the directive) then they are not being given the information they need to understand the cert, and are thus having their rights interfered by. It would be an extraordinary step for software to hide the number by policy ... as opposed to technical difficulties. 3. for CAs, there should be a convention on where to put this number. Which field in x.509? E.g., you could just simply knock up a certificatePolicies variant that stated the number, with an OID, mark it critical (?) unless the Europeans have already figured it out. 4. For software developers, as the number has legal significance, there should be a convention as to how to show this value. It should be shown when available, and easily so. I would suggest this puts it in the "first click" display. Which means, adding that field to the current O/CN/OU set, and show it in Tbird if it is present. 5. There then needs to be an agreement of what number should be proposed to the user in the absence of a proper cert claim. Obviously, I'm proposing that should be zero, but let's hear what others think as a number. > 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. I would suggest that we think in terms of the EU directive, not Hungary. The requirements for qualified certs covers some 30 or so countries in Europe. Although we may not like it [1], the law has been passed in most countries in Europe, and qualified certificates are pushed by a few governments [7] to the extent that various ordinary documents *must* be signed by qualified certificates, or you lose your money [8]. So, think about Europe, not Hungary. Do you want the software to be accepted in Europe? Are Europeans of typical value to Mozilla? Bearing in mind that (by law/directive) any European can be a relying party to a qualified certificate! An analogue is to also think in terms of security profiles. EV is a security profile for mostly North American websites. Then, we can think of the EU directive and the "qualified certificates" as a profile for mostly European communications / p2b and b2b business. (Also bear in mind that qualified certs are intended to be client signing certs, so this is more an issue for Thunderbird than Firefox. This may significantly help the implementation and legal questions.) iang [1] Don't get me started on what is disastrous about the EU directive ;) [2] Yes, I exclude the CPS from "easy to understand." Consider a judge who thinks in terms of consumer rights, and strikes down a contract that deliberately seeks to obfuscate what is going on. [3] Has Mozilla's general counsel been asked for an opinion on this? [4] I use the term _effective liability_ as like the term _expected liability_ from the financial world, as distinct from the monetary number posted as a headline somewhere. That is, after calculating the probabilities and the reduction effects of various tools, one can arrive at an estimate of how much real liability will come from business. The general strategy of the CA is to set the expected liability to zero, for various good business reasons. [5] There are a few motives for this. One can be found in some simple mathematics: Calculate the amount of phishing losses, and imagine a class action suit in California court that declared that the failure of the site authentication was to be pinned on the CA, pro rata with the number of clients. It's a big number. So the only sensible thing from the maths pov is to disclaim liability to the general public to the extent possible. [6] These days! In the good old days, reliable banking was built on the concept of unlimited liability, and it showed the best and most stable banking. Only these days with the apparent musical chairs system of liabilities is banking a suspect concept. [7] Not all; some countries disagree with the concept, but some significant countries push it enough to make it serious. [8] Germany and other countries intend that VAT declarations (similar to US sales tax) have to be signed by qualified certs, or you will lose your VAT value. It's a ticking timebomb, it's the nuclear option.
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
