Re: New EU requirement to display monetary limits for SSL pages
Jean-Marc Desperrier wrote: Ian G wrote: [...] OK, that's good to know that there is no number involved. That just leaves us with determining what information *is* in this cert, and how it is that it needs to be presented to the user, and what the legal and contractual ramifications of all this information is. We should refer directly to the documentation about that : http://portal.etsi.org/docbox/EC_Files/EC_Files/ts_101862v010201p.pdf (also http://www.ietf.org/rfc/rfc3039.txt for more generic qualified certificate information) (Thanks for the reference. I should read that, but won't have time, unfortunately.) The fact that it might be easy to parse doesn't make it easy to present. How do you envisage presenting this information? [...] What are the contractual ramifications for the parties? What happens if it goes wrong? (And, I don't think the answer to the above is "nothing" as if it was, there would be no need for a law and no need for a critical bit.) In the case of the hungarian CA, I'm not sure "nothing" is such a bad answer. To be more precise, the qualified CA cert is just one step toward producing a qualified signature, which would be present only if all components were qualified. So as long as Mozilla is not qualified, it's not a qualified signature, and the use of a qualified CA changes very little. What would seem to me adequate to present this information would be a text saying "this certificates claims to be a qualified certicate" in the certificat details. Nothing more. (OK, my wording is wrong, as the certificate is not a living being and can't claim anything) So, would we be agreed that it is certainly not obvious nor clear what Mozilla should do? Actually, for the monetary limit, I'd just add another text at the same place : "this certificate can be used as a qualified certificate for transactions restricted to a maximum value of _Amount_ _CurrencyCode_". That would open the way for Mozilla to have that liability. Now, this is tempered by for example the lack of a contract between Mozilla and the user. But, this is an open question, and the Florida bank case is being looked on to decide this issue; so until things like that are cleared up, I'd say that Mozilla should play that one cautiously. http://searchsecurity.techtarget.com/columnitem/0,294698,sid14_gci1062440,00.html About the can of worms, the one opened by those extensions does not really makes the situation worse for X509 certificates. We've had the "Non Repudiation" usage bit for a long time, and nobody agrees on what it means exactly to assert it. Right. My own view is to ignore them. Especially non-repudation as that is actually a legal nonsense. But, crits as well should probably be ignored as a first approximation; as they have no clear meaning, the system should not then try and impute their meaning, as to do so results in taking an active part. If you concerns were fully justified, the current Mozilla could already be considered liable by not showing in a very visible way that this flag is asserted. I believe that to be the case. Mozilla follows the docs, so it has raised the possibility of it being liable. It tries to do the right thing. So a relying party can say, "Mozilla set the standard of doing the right thing, and I relied up on that." Whereas IE raises no liability, simply because it doesn't do the right thing. It just prints out the info and lets the user do whatever it likes. It simply declines to do the right thing and thus specifically says "Not my problem, here's the info, you deal with it." This is a case of "doing the right thing" being "the wrong thing to do." iang -- News and views on what matters in finance+crypto: http://financialcryptography.com/ ___ Mozilla-security mailing list Mozilla-security@mozilla.org http://mail.mozilla.org/listinfo/mozilla-security
Re: New EU requirement to display monetary limits for SSL pages
Ian G wrote: [...] OK, that's good to know that there is no number involved. That just leaves us with determining what information *is* in this cert, and how it is that it needs to be presented to the user, and what the legal and contractual ramifications of all this information is. We should refer directly to the documentation about that : http://portal.etsi.org/docbox/EC_Files/EC_Files/ts_101862v010201p.pdf (also http://www.ietf.org/rfc/rfc3039.txt for more generic qualified certificate information) The fact that it might be easy to parse doesn't make it easy to present. How do you envisage presenting this information? [...] What are the contractual ramifications for the parties? What happens if it goes wrong? (And, I don't think the answer to the above is "nothing" as if it was, there would be no need for a law and no need for a critical bit.) In the case of the hungarian CA, I'm not sure "nothing" is such a bad answer. To be more precise, the qualified CA cert is just one step toward producing a qualified signature, which would be present only if all components were qualified. So as long as Mozilla is not qualified, it's not a qualified signature, and the use of a qualified CA changes very little. What would seem to me adequate to present this information would be a text saying "this certificates claims to be a qualified certicate" in the certificat details. Nothing more. (OK, my wording is wrong, as the certificate is not a living being and can't claim anything) Actually, for the monetary limit, I'd just add another text at the same place : "this certificate can be used as a qualified certificate for transactions restricted to a maximum value of _Amount_ _CurrencyCode_". You're not giving an acurate representation of things. [...] Let me repeat what I said: "It certainly opens a can of worms." That statement is as I see it, and I'd dearly love to be corrected on that. My "not acurate" was refering the following kind of statements you did : ">> What happens if IangInsidiousIssues sells >> certs with the crit in it saying $100,000 but >> inside the crit text, there is a caveat saying >> that the limit only applies if spent in my >> shop buying my goods?" "what is inside the extension packets is open, *by definition*, and they may or may not be marked with a critical bit." About the can of worms, the one opened by those extensions does not really makes the situation worse for X509 certificates. We've had the "Non Repudiation" usage bit for a long time, and nobody agrees on what it means exactly to assert it. If you concerns were fully justified, the current Mozilla could already be considered liable by not showing in a very visible way that this flag is asserted. ___ Mozilla-security mailing list Mozilla-security@mozilla.org http://mail.mozilla.org/listinfo/mozilla-security
Re: New EU requirement to display monetary limits for SSL pages
Jean-Marc Desperrier wrote: Ian, I have not much time now, but the hungarian cert in question is *not* using the monetary limit extension, only the extension to say it is a qualified certificate, which consists just of an OID and is therefore easy to parse. OK, that's good to know that there is no number involved. That just leaves us with determining what information *is* in this cert, and how it is that it needs to be presented to the user, and what the legal and contractual ramifications of all this information is. The fact that it might be easy to parse doesn't make it easy to present. How do you envisage presenting this information? Could you give us an example? What are the contractual ramifications for the parties? What happens if it goes wrong? (And, I don't think the answer to the above is "nothing" as if it was, there would be no need for a law and no need for a critical bit.) Here's why it is important. If the information requires "special processing" then the mere fact that the code in Mozilla goes on to do that special processing creates a liability. By doing so - providing that processing - Mozilla has accepted the contractual and legal ramifications as presented by the cert and the EU directive. If the information is of monetary important (and this is the case AFAIK) then it becomes monetary ramifications - liability. So, if the code gets it wrong, there may be an action against Mozilla. As Mozilla seems to be out on a limb on this (IE and Opera do not process the crits) this could get messy, as by signalling willingness to follow the contractual position provided by the crits, when others have not, this opens the door to some strange results. This is probably one reason IE doesn't follow the RFC on this: they don't want to accept the responsibility. A second reason is that they probably couldn't be bothered writing the code to deal with it, because this opens the door for any Tom,Dick,Harry CA to start asking for special code. Also the monetary extension is *not* as you say arbitrary text, it's a perfectly defined format, and even if there might text for the monetary unit, it is restricted to the value defined in an ANSI norm for the representation of currencies. OK, so as you say that right now the monetary extension is not being used, I guess we can skip that debate for now. Unless that is the Hungarians or anyone is thinking of using this, in which case it might be a good idea to see some examples of this. You're not giving an acurate representation of things. Let me repeat what I said: "It certainly opens a can of worms." That statement is as I see it, and I'd dearly love to be corrected on that. In the law that asks for these process to be done of the CAs, what is the legal requirement on the software manufacturer? What is the liability? Is there any disclaimer in the law that says that the software manufacturer is not a party to this, or not liable? iang -- News and views on what matters in finance+crypto: http://financialcryptography.com/ ___ Mozilla-security mailing list Mozilla-security@mozilla.org http://mail.mozilla.org/listinfo/mozilla-security
Re: New EU requirement to display monetary limits for SSL pages
Ian G wrote: [...] So the task for the Euro cert in question [...] [...] What planet are these guys on? What are we supposed to do, run it through a web translation engine? It certainly opens a can of worms. I asked around for any experience of these things, but got no answers on the cryptography group. Ian, I have not much time now, but the hungarian cert in question is *not* using the monetary limit extension, only the extension to say it is a qualified certificate, which consists just of an OID and is therefore easy to parse. Also the monetary extension is *not* as you say arbitrary text, it's a perfectly defined format, and even if there might text for the monetary unit, it is restricted to the value defined in an ANSI norm for the representation of currencies. You're not giving an acurate representation of things. ___ Mozilla-security mailing list Mozilla-security@mozilla.org http://mail.mozilla.org/listinfo/mozilla-security
Re: New EU requirement to display monetary limits for SSL pages
Gervase Markham wrote: Ian G wrote: What happens if IangInsidiousIssues sells certs with the crit in it saying $100,000 but inside the crit text, there is a caveat saying that the limit only applies if spent in my shop buying my goods? There's crit text too? It's not just a monetary value? As far as I understand it, what is inside the extension packets is open, *by definition*, and they may or may not be marked with a critical bit. The crit indicates that this additional extension packet must be understood by the code or the entire cert should be rejected. That means the packet is a code+data extension; there can be data, there could be text, numbers, logos, there could also be code in there that is extracted and run. Conceptually, at least. So the task for the Euro cert in question is that someone has to write some *code* to interpret the extension packet. Then, Mozilla can "legally" interpret the packet, and present it to the user. Otherwise it should reject. Which it does now, so according to the writing of the RFCs, Mozilla is following the letter of them; whereas other browsers are not. What planet are these guys on? What are we supposed to do, run it through a web translation engine? It certainly opens a can of worms. I asked around for any experience of these things, but got no answers on the cryptography group. iang -- News and views on what matters in finance+crypto: http://financialcryptography.com/ ___ Mozilla-security mailing list Mozilla-security@mozilla.org http://mail.mozilla.org/listinfo/mozilla-security
Re: New EU requirement to display monetary limits for SSL pages
Ian G wrote: What happens if IangInsidiousIssues sells certs with the crit in it saying $100,000 but inside the crit text, there is a caveat saying that the limit only applies if spent in my shop buying my goods? There's crit text too? It's not just a monetary value? What planet are these guys on? What are we supposed to do, run it through a web translation engine? Gerv ___ Mozilla-security mailing list Mozilla-security@mozilla.org http://mail.mozilla.org/listinfo/mozilla-security
Re: New EU requirement to display monetary limits for SSL pages
Gervase Markham wrote: Ian G wrote: What is it you are going to put next to the lock? It seems to me that the statement is potentially large and bulky... The amount: www.paypal.com ($1000) [8] (where 8 represents a closed lock) OK. Now, the first issue there would be that PayPal is not guarunteeing the $1000, so it would need to have the CA listed there as well, to avoid confusion. (No bad thing!) You could do half of what I suggested earlier (and I think it was suggested that IE/Opera do this) and put a Warning icon next to the lock that was the same formfactor. Clicking would then bring up (any) critical display in a generic form. But if this practice becomes widespread, many sites would have warning icons. And an icon which signified "warning" would be unnecessarily scary. If somebody is using a 'critical bit' then I think we might be wise not to hide that. To me, it's pretty darn scary - as a security guy, I can't think of anyway to ring fence it. It's like saying that any CA can issue a protocol-change without review by the protocol people. Also, any such icon wouldn't be much smaller than printing the limit. If it is just the number, then fine. This would then leave us with the second issue, being the cost of extracting the number and printing it. But, can you draw the line in the sand? What happens if IangInsidiousIssues sells certs with the crit in it saying $100,000 but inside the crit text, there is a caveat saying that the limit only applies if spent in my shop buying my goods? iang -- News and views on what matters in finance+crypto: http://financialcryptography.com/ ___ Mozilla-security mailing list Mozilla-security@mozilla.org http://mail.mozilla.org/listinfo/mozilla-security
Re: New EU requirement to display monetary limits for SSL pages
Ian G wrote: What is it you are going to put next to the lock? It seems to me that the statement is potentially large and bulky... The amount: www.paypal.com ($1000) [8] (where 8 represents a closed lock) You could do half of what I suggested earlier (and I think it was suggested that IE/Opera do this) and put a Warning icon next to the lock that was the same formfactor. Clicking would then bring up (any) critical display in a generic form. But if this practice becomes widespread, many sites would have warning icons. And an icon which signified "warning" would be unnecessarily scary. Also, any such icon wouldn't be much smaller than printing the limit. Gerv ___ Mozilla-security mailing list Mozilla-security@mozilla.org http://mail.mozilla.org/listinfo/mozilla-security
Re: New EU requirement to display monetary limits for SSL pages
Gervase Markham wrote: Both of these are very difficult. I know that, as a user, if I want to buy £205 of books from Amazon, the fact that my browser has a little £200 displayed somewhere would make no difference whatsoever. Yes. Bear in mind that the requirement is imposed on the CA, nobody else. This is the same convention I saw in cheque cards, where the number 50 was often used to support transactions up to maybe 200, etc. It's the choice of the merchant and consumer as to what they do with the additional information they have available to them. The merchant is not "required" to pay attention. Also, what if the value is in euros, for example, and I'm in the UK, and the site accepts either currency? We may need to contact a currency conversion web service in order to make the UI meaningful. Or have the converted value as a tooltip. Point. People have tried this in the digital currency world, and generally gone over to a static conversion. Dynamics cause too many problems. Unfortunately, a static conversion makes no sense here as the cert was created at least days ago... For Firefox and Mozilla, it seems that the only sensible place to put it would be next to the lock in the status bar. What is it you are going to put next to the lock? It seems to me that the statement is potentially large and bulky... You could do half of what I suggested earlier (and I think it was suggested that IE/Opera do this) and put a Warning icon next to the lock that was the same formfactor. Clicking would then bring up (any) critical display in a generic form. iang -- News and views on what matters in finance+crypto: http://financialcryptography.com/ ___ Mozilla-security mailing list Mozilla-security@mozilla.org http://mail.mozilla.org/listinfo/mozilla-security
Re: New EU requirement to display monetary limits for SSL pages
Nelson Bolyard wrote: And, BTW, this applies to any use of these certs, not just https. It also applies to POP, IMAP, SMTP, IMAP and whatever, when run over SSL. So the UI challenge is greater than merely for the browser's chrome. You're not kidding. This is a really nasty UI problem. As there is no technical way of enforcing the limit, for enforcement to mean anything, we have to present the limit in the UI in a way which: - allows the user to work out what it means - convinces the user that they should not perform transactions greater than it Both of these are very difficult. I know that, as a user, if I want to buy £205 of books from Amazon, the fact that my browser has a little £200 displayed somewhere would make no difference whatsoever. Also, what if the value is in euros, for example, and I'm in the UK, and the site accepts either currency? We may need to contact a currency conversion web service in order to make the UI meaningful. Or have the converted value as a tooltip. For Firefox and Mozilla, it seems that the only sensible place to put it would be next to the lock in the status bar. Gerv ___ Mozilla-security mailing list Mozilla-security@mozilla.org http://mail.mozilla.org/listinfo/mozilla-security
Re: New EU requirement to display monetary limits for SSL pages
Ian The handling of critical extensions is an international standard. I'm not asking you to tell me whether or not you think it is a good idea for mozilla to follow that standard, though you seem eager to opine on that subject. I am asking the *UI czars* to consider dealing with standardized security issues in the UI. -- Nelson B ___ Mozilla-security mailing list Mozilla-security@mozilla.org http://mail.mozilla.org/listinfo/mozilla-security
Re: New EU requirement to display monetary limits for SSL pages
Nelson B wrote: b) what should each application do about them? (this is obviously a set of questions, one per application.) ... The question then is, what will the application(s) do with the info in this extension, if anything? Now, recall that MoFo has no "security director" who decides how crypto security policy affects UI. And worse, it has no developer who is actively working on the crypto UI (PSM is an orphan). So, I am raising the question that might otherwise be decided by that director or PSM owner, if one existed. OK. I am hoping that the FireFox and ThunderBird UI czars will read this thread in this group, and engage in discussion of this issue. Ian, you've championed the idea of making crypto security less "binary" in the UI, so I'd expect you to also like this idea, making a stated limit of liability clear to the user whose money (and "security") is on the line. Well! Many thoughts are bubbling away, and I might be weeks away from feeling certain on this issue. But, here's some thoughts: 1. The crypto layer really should be clean and sweet. Taking responsibility for an open ended-policy feature in certs would not seem to be in accord with that. 2. The notion that someone can create a cert that has a "break if you don't understand this" setting - the critical bit - raises a whole host of security questions that I for one do not see as answered. Pausing for a moment here ... are these viewpoints that the NSS team has already reached, and can be used as "current viewpoints" ... or is there further debate? 3. The policy question that is being asked - please show the user this statement - seems to be quite a reasonable one. It is in line with current security thinking that any security system has to consider the user as an essential component in it. What the policy statement indicates fits well with that. 4. In fact, the policy statement has simply been lifted from standard european practice with cheque guaruntee cards, I would guess. There, to combat cheque fraud, banks would issue plastic cards that had a value on them that would guaruntee any transaction to that amount as long as the shop copied the number onto the cheque. (I say European, I've only seen it in Britain). 5. Giving the CA an ability to show some statement to the user seems like a worthwhile goal. 6. How this request comes about - the European legal environment - raises some really interesting questions. I'm hoping that any solution devised can be as neutral as possible here. 7. I read comment #17 in the bug report to say that Opera and IE both take no action on the certs, other than displaying the information if the user knows how to dig that far. iang -- News and views on what matters in finance+crypto: http://financialcryptography.com/ ___ Mozilla-security mailing list Mozilla-security@mozilla.org http://mail.mozilla.org/listinfo/mozilla-security
Re: New EU requirement to display monetary limits for SSL pages
Nelson B wrote: There are two sets of questions before us regarding this new extension and the "qualified statements" it contains. they are: a) what should NSS do about them? ... In the cited bug, I have proposed to implement this extension in NSS in a way that makes the support for this extension conditional on the application that uses NSS. As proposed, if the application that uses NSS says to NSS, "Trust me, I handle this, you treat it as recognized and supported", then NSS would do so. I can't see that NSS can really do much more than reveal the information. As the critical bit reaches well into the "policy & politics" layer (shades of those old ISO 9 layer t-shirts) already, most if not all of the action has to happen in the application. One possibility is that there is some static flag that is set by the application that says, if a critical bit is set, then throw an exception. The problem with this is that even then, it has no meaning, as the code that interprets the crit is almost certainly in the application layer, and NSS does not know what is up there. One could talk about installing crit handlers into NSS, but what are they to do? What do they have access to? Drawing from my remarks on the security implications of the critical bit being used against the code, I suspect trying to define the semantics of these handlers would be a bit of a nightmare - shades of the Java sandbox approach, which is vaguely workable if you spend a lot of time on it, but nobody in the serious security world that I know of thinks it qualifies as security. (I see that you are talking about just that in the Bug posting...) So if your API makes that information available on request to the application, then that seems about the right thing to do ... to me. The alternate that NSS should treat the crit as its _responsibility_ in terms of making decisions is troubling. The question then is, what will the application(s) do with the info in this extension, if anything? Which leaves open the question of what the apps do. iang PS: I seem to have shortened "critical bit" to "crit" in the above... -- News and views on what matters in finance+crypto: http://financialcryptography.com/ ___ Mozilla-security mailing list Mozilla-security@mozilla.org http://mail.mozilla.org/listinfo/mozilla-security
Re: New EU requirement to display monetary limits for SSL pages
There are two sets of questions before us regarding this new extension and the "qualified statements" it contains. they are: a) what should NSS do about them? b) what should each application do about them? (this is obviously a set of questions, one per application.) In the cited bug, I have proposed to implement this extension in NSS in a way that makes the support for this extension conditional on the application that uses NSS. As proposed, if the application that uses NSS says to NSS, "Trust me, I handle this, you treat it as recognized and supported", then NSS would do so. The question then is, what will the application(s) do with the info in this extension, if anything? Now, recall that MoFo has no "security director" who decides how crypto security policy affects UI. And worse, it has no developer who is actively working on the crypto UI (PSM is an orphan). So, I am raising the question that might otherwise be decided by that director or PSM owner, if one existed. I am hoping that the FireFox and ThunderBird UI czars will read this thread in this group, and engage in discussion of this issue. Ian, you've championed the idea of making crypto security less "binary" in the UI, so I'd expect you to also like this idea, making a stated limit of liability clear to the user whose money (and "security") is on the line. Please don't scare those UI czars away from this issue, or convince them (by use of a dismissive attitude) that this isn't worth their consideration. Thank you. -- Nelson B ___ Mozilla-security mailing list Mozilla-security@mozilla.org http://mail.mozilla.org/listinfo/mozilla-security
Re: New EU requirement to display monetary limits for SSL pages
Trying to accommodate the legal idiosyncrasy of one country or one group of countries is an exercise in futility. You can never conform to all legislation everywhere, especially since different jurisdictions will often have conflicting legislation. Security should concentrate on keeping the product secure, not on catering to every arbitrary legislative mandate made by every jurisdiction in which the product might happen to be used. I hope no effort will be wasted trying to please EU legislators. -- Anthony ___ Mozilla-security mailing list Mozilla-security@mozilla.org http://mail.mozilla.org/listinfo/mozilla-security
Re: New EU requirement to display monetary limits for SSL pages
Nelson, That is a doozy! Some points. I don't really feel I've fully got to the bottom of this issue, in the brief scanning, so these are all highly debatable points. Just to warn in advance, they are primarily negative in direction. 1. Critical bits are a can of worms. They introduce complexities that may be used against the software. From my pov as a security guy, I see them as an option to break security in the future. I view them distrust. (All I really know about them is the debate years back in the OpenPGP group where they decided to discuss adding them, and there were no good answers to concerns then.) 2. Legislated crypto is probably bad law. I'm not really inclined to jump on the Larry Lessig "code is law" bandwaggon here, but that's sort of where this goes. One has to establish that the law writers knew what they were doing, and that's really hard. And one has to establish that what they wrote made sense, and that's even harder. Not to mention, if it made sense, why didn't we do it anyway, without them making it law? Anglo countries quite rightly (IMO) ignored all the digsig laws, but the European tradition is ... less humourous. 3. If one country writes a law, this critical bit then "becomes code." That's the starting proposition. But what happens if another country writes a law? And another and another? Can critical bits interfere with each other? Not only do critical bits allow anyone who issues certs to raise all sorts of dilemmas, they at a minimum raise a complexity issue that probably isn't justified by their benefit to users. 4. Some examples, ranging in ludicrosity (!): 4. a. What happens if the FBI asks and Congress passes a law that says that all certs now have to be escrowed, and the critical bit set for all new escrowed certs? 4. b. What happens if Verisign decides that it is going to reissue all its certs according to some law it found that said it should be paid extra? 4. c. Does this mean that CACert can go trawling thru aussie law and find something to justify a critical bit? 4. d. Does this mean I can become a CA, and issue certs with critical bits that insist that my certs not be used unless the user is shown the logo? Obviously ludicrous examples! But ... that's where this thing might head. 5. If you take *any* action at all .. that means you are following the protocol or attempting to follow the protocol. If you get it wrong, you are now negligent. Alternatively, if you take no action at all, then you are not negligent, you just don't accept the contract. As this involves money, and as the liability is clearly present, this could get messy. If a browser mucks it up, and the CA gets sued, it could pass that across to the browser manufacturer. Having said all that, I'd say that you seriously think about putting the "null" option on the table. And some variants of that. The null option is to do nothing. Leave it as it is. So this cert with its critical bit gets rejected. That's actually the safest thing to do until all the angles are analysed. I think given the "Frank Hecker" sized project here of figuring out all the angles here, that might be the sensible short term course of action. The near-null option would be to accept the cert, and ignore totally the critical bits. The rational for this is that users want to see these certs, and the law writers simply haven't paid you to write the code. As a *thought* excercise by me, I might integrate the critical bits into my branding CA notions this way: the cert is accepted, and the CA logo is shown on the chrome. Along side the CA logo is a hard red warning sign like an (X). Clicking on that brings up a dialog (or changes the logo) to show the critical bit markings. No special code, just a read out of what the critical bits are. No active action, just a hard red warning button beside the logo that the user can click to see what it says. I don't envy you guys on this one! iang -- News and views on what matters in finance+crypto: http://financialcryptography.com/ ___ Mozilla-security mailing list Mozilla-security@mozilla.org http://mail.mozilla.org/listinfo/mozilla-security
