Re: Security-Critical Information (i.e. Private Key) transmitted by Firefox to CA (i.e. Thawte) during X.509 key/cert generation
Kaspar Brand wrote, On 2008-12-27 03:21: Michael Ströder wrote: I personally don't know whether the current Mozilla implementation of crypto.generateCRMFRequest includes the private key of an encryption cert. Only if you tell it do so, and only if it's a key-exchange-only key. [1] Additionally, an Encryption Key Copy warning dialog will be presented when key escrow is attempted - try the attached demo. [2] [1] https://developer.mozilla.org/en/GenerateCRMFRequest [2] Caveat: may leave you (or your cert DB, more precisely) with a lot of orphan keys, if used generously - i.e. it's probably better to use it with a separate profile. Kaspar, Thanks for this information and demo. I had been told that this dialog exists, but I had never seen it before your demo. I'd like to see this demo go into a page on a mozilla web site, such as (say) developer.mozilla.org. I also think we need a page or two on developer.mozilla.org that fully documents both the keygen tag and the crypto.generateCRMFRequest method. The existing documentation is very incomplete. The keygen tag, for example, accepts many more arguments than are now publicly documented. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Security-Critical Information (i.e. Private Key) transmitted by Firefox to CA (i.e. Thawte) during X.509 key/cert generation
Fost1954 wrote, On 2008-12-27 06:54: *_With other words (adapted from N. Bolyard):_* b) Is there any way for a Firefox user to detect that his CA has requested [the] private key [to be transmitted] ? _Possible Answer by Kaspar Band: _ ...an Encryption Key Copy warning dialog will be presented. My personal question: Is this warning dialog really ALWAYS the case ? I think the question is: is there any way for a web site to suppress that dialog? c) When requesting a certificate from a CA, what can a Firefox user do to prevent [transmission] of the newly generated private key? Possible Answer by kaspar Band: Not too difficult to achieve, actually. Just add this line to your prefs.js:[...] I think Kaspar's suggestion will disable the use of crypto.generateCRMFRequest entirely, not just for the case where key escrow has been requested. Is that right Kaspar? In any case, as long as the warning dialog cannot be suppressed, then I think it is both necessary and sufficient to address Fost's concerns. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: [Fwd: Follow-Up on www.verisign.com SSL Order]
Reed Loden wrote: On Sat, 27 Dec 2008 13:55:45 +0100 Michael Ströder mich...@stroeder.com wrote: Patricia, we saw several strange things from Certstar during the last days, not just one mistake: 1. Spam e-mail to StartCom customers showing dubious business practices Spam wasn't just sent to StartCom customers... So that's even worse. 3. Strange from address with another famous trademark as local part used in another posting here I'm sure Patricia was just submitting to the newsgroups via Google Groups, and I bet her google account is the address used in the post to which you're referring. She probably just forgot to change it to her work address before sending. I wouldn't fault her or her company for this mistake in any way. Do you really think so? Please re-read my text above about local part of the from address in question. Typically when using a Google account the local part is a name chosen by the user and the domain part belongs to Google. In this case I wouldn't have said anything because it's obviously normal. But that was not the case. The from address used was: goo...@servage.net Ciao, Michael. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
CAs and external entities (resellers, outsourcing)
After having read the posts related to the unbelievable event, I understand the event involved an approved CA and an external entity they work with. From my perspective, it's a CA's job to ensure competent verification of certificate requests. The auditing required for CAs is supposed to prove it. The verification task is the most important task. All people and processes involved should be part of the assuring audit. The current Mozilla CA Certificate Policy says: 6. We require that all CAs whose certificates are distributed with our software products: ... provide attestation of their conformance to the stated verification requirements ... In my opinion, it means, a CA must do this job themselves. The policy currently does not appear to handle the scenario where a CA delegates the verification job to an external entity. So it's unclear whether it's forbidden or allowed if the external entity has received equivalent attestation of their conformance. In my personal opinion, a CA violates the Mozilla CA Certificate Policy if they delegate the verification job to an external entity not owning attestation of their conformance to the stated verification requirements. If we'd like to be strict, we could remove CAs from our approved list if they have shown to be non-conforming in the above way. In any case, the CA policy should get clarified about involving external entities in the verification and issueing process. All existing CAs should be required to make a statement about their current business practices with regards to external entities. After a grace period all CAs must either stop using external entities, or get conformance attestation for all involved entities. Kai 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
Re: Security-Critical Information (i.e. Private Key) transmitted by Firefox to CA (i.e. Thawte) during X.509 key/cert generation
On 12/28/2008 12:50 PM, Nelson B Bolyard: I also think we need a page or two on developer.mozilla.org that fully documents both thekeygen tag and the crypto.generateCRMFRequest method. The existing documentation is very incomplete. Thekeygen tag, for example, accepts many more arguments than are now publicly documented. Now that's interesting. What are those additional arguments? -- 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: Security-Critical Information (i.e. Private Key) transmitted by Firefox to CA (i.e. Thawte) during X.509 key/cert generation
Nelson B Bolyard wrote: I also think we need a page or two on developer.mozilla.org that fully documents both the keygen tag and the crypto.generateCRMFRequest method. +1 The existing documentation is very incomplete. The keygen tag, for example, accepts many more arguments than are now publicly documented. Which arguments are that? Ciao, Michael. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
dropping the root is useless
On 28/12/08 12:13, Kai Engert wrote: If we'd like to be strict, we could remove CAs from our approved list if they have shown to be non-conforming in the above way. Yes, we could! But this is what we call a blunt weapon. It is also a dangerous weapon. Consider (all) the consequences in the current case. First, losses we will incur, regardless: 1. Certs: All end-users who rely on these certs will lose. That probably numbers in the millions. All subscribers will lose, probably in the thousands. The CA will lose; potentially it will lose its revenue stream, or have it sliced in half (say), which is what we would call in business circles a plausible bankrupcy event. 2. Mozo: Mozilla will lose because of all the undelivered security (all those good certs and subscribers and end-users). It may be sued by the CA and the CA's investors and/or the receiver/liquidator for a bad decision. 3. Industry: All other CAs will lose because they will now have to include in their business plans the possibility of a root being dropped by a bad decision. 4. Security will go down, because less certs are delivered and in use. (It's hard to calculate the secondary losses here, but not impossible.) Second, the losses we seek to stop: 1. Against that you can weigh the damages done so far and the harm to protect against. We know it is down to 11 or so certs, all revoked. Therefore, we know that the damage is stopped now, and there is only an unknown window of 11 certs from their issuance to last week. In practice, this calculates as zero damages, because the likely scenario is that no harmful certs were issued [1]. 2. There is the possible benefit to the other CAs as a punishment tool, in the case where the decision is good (see 3. above). There could be a knock-on effect in convincing CAs to tighten their game. However, this needs to be balanced against other costs and loss of certs, and in practice, the dominant factor is this: more certs is more security, less certs is less security. Until we get new info, this is the estimate on the table. Therefore dropping the root will cause large losses, and will stop nothing, in the current case. The wider policy problem here for Mozilla, for this forum, and for the whole PKI is that no matter which way you analyse, it, we've got nothing in the way of a punishment. Stick any numbers you like in the above example, and watch what happens. Removing the root is useless as a punishment. It only has downside, for all. It will likely never happen, and we should stop talking about it. iang [1] no harmful certs == unreliable certs issued to people to do bad things. E.g., we ignore false certs that are already controlled. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Can you rely on an Audit?
On 28/12/08 12:13, Kai Engert wrote: From my perspective, it's a CA's job to ensure competent [stuff]. OK. The auditing required for CAs is supposed to prove it. This might be a bit too strong. Let's look at that. What audits do is confirm criteria, and provide an opinion that the criteria are met, according to the opinion of the Auditor [1]. Now let's look at some of the limitations or caveats or bugs in that process: 1. It is up to you to read the criteria and decide if they are appropriate to your needs. 2. It is also up to you to decide whether the opinion letter is good enough whatever that means. 2.b. And, it is also up to you to investigate and understand the various languages and procedures that an Auditor uses, customarily, to weaken an apparently strong claim. 3. It is also up to you to check that the Audit verifies the Mozilla policy. I don't know, but my understanding was that Audits are generally done to WebTrust or ETSI criteria, and not to the policy. There would need to be a specific comment from the Auditor to say that the policy was included in scope. Has anyone here read the opinions and confirmed inclusion of the policy in the audit opinions? 4. It is also up to you to decide whether the Auditor has characteristics that speak highly of the opinion. Without getting into that debate, suffice to say, the singularity of the process is a weakness in and of itself. Where does this get us? It should be clear that Audits don't prove anything. At all. If you take an audit to prove something then *you have made a mistake* ; although we might agree that that this is a mistake that many people are comfortable for you to make, and they are unlikely to correct you in. The question is more likely placed as whether you can rely on an Audit. If you get through all the above, your answer is probably maybe. If you have a friend in the business, feel free to pose this question to them. Ask around, get some opinions. (And, if we accept the above, if you don't get through all of your above checks, how can your answer be any better than maybe ?) Perhaps more broadly, we could ask whether we as a community get any benefit from an audit at all, given the rather drastic nature of an individual maybe. I think the answer is yes, cautiously: it probably ensures that a CA is up to a known and reasonable level of practices [2]. So, at least we know where a CA is likely at, once they've passed their audit. Whereas before, we would be simply relying on advertising, which is hopeless. The good news is that we can actually cover a lot of these weaknesses by moving to more open disclosures. The Internet has given us wonderful opportunities to move more information more reliably, something that is not factored into current Audit thinking. So it may not be a huge issue that classical Audits have flaws (c.f., they are not perfect, nor prove what you want) as long as we look at where the flaws are found in practice and identify ways to use the open source approach to overcome those flaws [3]. iang [1] disclosure, I work as an auditor [2] I am ignoring costs analysis here, so it may be that the benefit described does not return on investment. [3] we sometimes call this open governance. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: dropping the root is useless
On 12/28/2008 02:46 PM, Ian G: 1. Certs: All end-users who rely on these certs will lose. That probably numbers in the millions. All subscribers will lose, probably in the thousands. The CA will lose; potentially it will lose its revenue stream, or have it sliced in half (say), which is what we would call in business circles a plausible bankrupcy event. Not relevant. 2. Mozo: Mozilla will lose because of all the undelivered security (all those good certs and subscribers and end-users). It may be sued by the CA and the CA's investors and/or the receiver/liquidator for a bad decision. I suggest to you refrain from now on to give legal advice on these matters, Mozilla has a legal department and lawyers for that. But if we are at it, Mozilla has no legal or any other requirement (as far as I know) to include or keep a root. The Mozilla CA Policy clearly reserves the right to remove any of the roots (including all of them) at any time. If this isn't the case we all should know about it. Additionally it's Mozilla which also has the right to sue the CA and not the other way around. Just for your knowledge, Microsoft and other vendors reserve the same right. 3. Industry: All other CAs will lose because they will now have to include in their business plans the possibility of a root being dropped by a bad decision. Very good! Even though I'm not the proponent of the proposal to remove Comodo's root (instead work towards a real improvement, with the removal as a stick), this is exactly what possible removal should achieve. Refrain CAs from making bad decisions. More than that, some CAs are on disadvantage when competing with CAs which are willing to take high risks. This must be clearly recognized and I'm all in favor of having to compete on equal footing. This isn't the case today. 4. Security will go down, because less certs are delivered and in use. (It's hard to calculate the secondary losses here, but not impossible.) That's easy to revert, I'm certain there are a bunch of CAs ready to issue new certs to them. 1. Against that you can weigh the damages done so far and the harm to protect against. We know it is down to 11 or so certs, all revoked. That's absolutely not correct. Right now nobody knows - including Comodo - how many certs are really unvalidated because of the lack thereof. This is what I know at the moment and it would be good if Comodo could dispute that claim and advice differently or confirm it. 2. There is the possible benefit to the other CAs as a punishment tool, in the case where the decision is good (see 3. above). There could be a knock-on effect in convincing CAs to tighten their game. Right! I'm all in favor of that, lets go for it! However, this needs to be balanced against other costs and loss of certs, and in practice, the dominant factor is this: more certs is more security, less certs is less security. Less unvalidated certs is more security, not less. An unknown number of unvalidated certs is no security at all. -- 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: Can you rely on an Audit?
On 12/28/2008 03:23 PM, Ian G: [1] disclosure, I work as an auditor Since you are making a claim here of being an auditor - and specially in the context of WebTrust or similar criteria, can you please also disclose which formal training and titles you have? For which audit firm are you working currently and/or have you worked in the past? Thanks. -- 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: dropping the root is useless
(following is just for the record so as to deal with the response. No new info is in here for other readers.) On 28/12/08 14:21, Eddy Nigg wrote: On 12/28/2008 02:46 PM, Ian G: 1. Certs: All end-users who rely on these certs will lose. That probably numbers in the millions. All subscribers will lose, probably in the thousands. The CA will lose; potentially it will lose its revenue stream, or have it sliced in half (say), which is what we would call in business circles a plausible bankrupcy event. Not relevant. Well! If they are not relevant, then perhaps we can turn SSL off, with no consequences? I suggest to you refrain from now on to give legal advice on these matters, Mozilla has a legal department and lawyers for that. But if we are at it, Let's deal with this self-contradictory statement. To ignore the obvious legal ramifications (agreements in RPAs, disclaimers to end-users, potential lawsuits ...) would be negligence, IMHO. We know the ramifications exist. We know they may be serious. We know that assertations of security are being made to end-users. Hence to continue making these assertations, and not treat them seriously would be negligence. I personally choose not to follow that path into negligence, and will continue to consider the legal ramifications, which leads to the question of how we consider them. We could simply refer them to the legal department, as you suggest. Mozilla has a legal department, as you kindly point out, but they are silent. They may have entirely good reasons for being silent, but that makes them more or less useless for the work of this forum. So referring them to that legal department is not an option for now. We could simply refer them to our own legal department. But, we are all here as volunteers, and while some of the businesses may like to put their counsel at the service of this group, this won't work because of conflicts of interest. This is therefore not an option. Which leaves the final option: we have to deal with it, ourselves, and we have to work with the known and understood caveats that none of us are lawyers. Others may have other views, but I would suggest that in this forum, we have to consider the legal ramifications. Mozilla has no legal or any other requirement (as far as I know) to include or keep a root. No, I'm afraid there is an agreement to list the root, under a policy. Once listed, Mozilla has to operate according to its side of the bargain. This is a general consequence of business, there is nothing special about it. Ask any experienced business person. The Mozilla CA Policy clearly reserves the right to remove any of the roots (including all of them) at any time. If this isn't the case we all should know about it. The problem being, that even if it reserves the right to make a choice for any reason, this does not give Mozilla carte blanche. If it makes a bad choice, a judge can imply a reasonableness test. This is one of those areas where we really do need lawyers in the conversation, but I will short circuit that with a prediction of mine, only: the lawyers will likely say, we will find out in court. Great answer, huh? It sure keeps the lawyers in work, and it provides little help for us. See earlier analysis. Additionally it's Mozilla which also has the right to sue the CA and not the other way around. Just for your knowledge, Microsoft and other vendors reserve the same right. Everyone has the right to walk into court. That point is empty of practical value. 3. Industry: All other CAs will lose because they will now have to include in their business plans the possibility of a root being dropped by a bad decision. Very good! Even though I'm not the proponent of the proposal to remove Comodo's root (instead work towards a real improvement, with the removal as a stick), this is exactly what possible removal should achieve. Please read it carefully. a root being dropped by a BAD decision. Refrain CAs from making bad decisions. Oh, ok. No, I meant MOZILLA making a bad decision. E.g., a mistake. More than that, some CAs are on disadvantage when competing with CAs which are willing to take high risks. This must be clearly recognized and I'm all in favor of having to compete on equal footing. This isn't the case today. Indeed. You won't achieve it by dropping a root, and you won't achieve it by _threatening_ to drop a root. I suggest you will achieve precisely the reverse, because some CAs will have an advantage in that negotiation, and they will overcome any positive benefit in a way that has little bearing on security for the users. Standard business stuff, really. 4. Security will go down, because less certs are delivered and in use. (It's hard to calculate the secondary losses here, but not impossible.) That's easy to revert, I'm certain there are a bunch of CAs ready to issue new certs to them.
Re: Can you rely on an Audit?
On 28/12/08 14:57, Eddy Nigg wrote: On 12/28/2008 03:23 PM, Ian G: [1] disclosure, I work as an auditor Since you are making a claim here of being an auditor - and specially in the context of WebTrust or similar criteria, OK, to answer the implied question here, the criteria are those written by David Ross, and are known sometimes as DRC. They are listed here: http://rossde.com/CA_review/ For the interested readers: DRC were developed following a review of WebTrust by David Ross, and his criteria cross-reference to WebTrust for ease of comparison. Those are my words, see the link for his own words. can you please also disclose which formal training and titles you have? BSc(hons) Computer Science, University of NSW. MBA, London Business School. For which audit firm are you working currently and/or have you worked in the past? Thanks. None. Interested readers might now relate this to point 9, 10 of the policy. http://www.mozilla.org/projects/security/certs/policy/ iang ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: dropping the root is useless
On 12/28/2008 04:24 PM, Ian G: 1. Certs: All end-users who rely on these certs will lose. That probably numbers in the millions. All subscribers will lose, probably in the thousands. The CA will lose; potentially it will lose its revenue stream, or have it sliced in half (say), which is what we would call in business circles a plausible bankrupcy event. Not relevant. Well! If they are not relevant, then perhaps we can turn SSL off, with no consequences? I was clearly replying to the later part: The CA will lose; potentially it will lose its revenue stream, or have it sliced in half (say), which is what we would call in business circles a plausible bankrupcy event. It's not relevant. No, I'm afraid there is an agreement to list the root, under a policy. Once listed, Mozilla has to operate according to its side of the bargain. Apparently you are reading something I haven't. The problem being, that even if it reserves the right to make a choice for any reason, this does not give Mozilla carte blanche. Mozilla can make a bad decision, no doubt. This case is most likely not one of those you are referring to. Please read it carefully. a root being dropped by a BAD decision. A root isn't removed before careful considerations. A bad decision doesn't warrant not to remove any roots at all if necessary. Mozilla can also reinstate a root. They stated how many, IIRC. I recall it was something like 111 certs issued and 11 outstanding that had not been re-verified within around 48 hours (these numbers are not accurate, but indicative) and were therefore revoked. That's for the specific certstar case. Domain validation isn't performed by Comodo on a wide scale apparently and perhaps no validation is performed at all. -- 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: Security-Critical Information (i.e. Private Key) transmittedby Firefox to CA (i.e. Thawte) during X.509 key/cert generation
I wouldn't spend much work on keygen and crypto.generateCRMFRequest because they don't match today's needs anyway. You cannot even as an issuer control PIN code settings (policy) unless you have a pre-configured crypto container, i.e. these mechanisms are tools for toy PKIs. Serious PKIs use smart cards and physical card/key/certificate distribution because the on-line alternatives are more or less useless in addition to being completely non-standard. The coming HTML5 standards work does not even *try* to address this mess. I think they did the right thing; PKI standards in browsers reached an all-time-high already 10 years ago. PKIX are not aware of the problem because PKIX don't do browsers, they do ASN.1. Anders - Original Message - From: Michael Ströder mich...@stroeder.com Newsgroups: mozilla.dev.tech.crypto To: dev-tech-crypto@lists.mozilla.org Sent: Sunday, December 28, 2008 13:38 Subject: Re: Security-Critical Information (i.e. Private Key) transmittedby Firefox to CA (i.e. Thawte) during X.509 key/cert generation Nelson B Bolyard wrote: I also think we need a page or two on developer.mozilla.org that fully documents both the keygen tag and the crypto.generateCRMFRequest method. +1 The existing documentation is very incomplete. The keygen tag, for example, accepts many more arguments than are now publicly documented. Which arguments are that? Ciao, Michael. ___ 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: Security-Critical Information (i.e. Private Key) transmitted by Firefox to CA (i.e. Thawte) during X.509 key/cert generation
2008/12/28 Nelson B Bolyard nel...@bolyard.me I think the question is: is there any way for a web site to suppress that [private key transmission warning-] dialog? Yes: this should be the point. Having the certainty, that a warning dialog cannot be suppressed when a private key is to be transferred, Firefox Users would feel (and be) on the safe side. ___ 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
problem with JSS-based custom RMI factory
I'm trying to create a simple Java RMI application with a custom factory that uses JSS SSL classes. So I created a simple server and client factories that create SSLServerSocket and SSLSocket instances correspondingly. But when my client tries to lookup in the registry, the following happens: 1) the client factory is called and it creates an instance of SSLSocket 2) write() method is called on the socket 3) then it's supposed to call socketWrite() native method - but for some reason the native method lookup fails and I grab the ClassNotFound exception Now, I'm pretty sure that my envrionment (LD_LIBRARY_PATH and CLASSPATH) are set correctly and JSS is properly initialized - 'cause see it listed in current providers and I have a sample code that generates a key inside the NSS token, right before the RMI lookup code, and it works just fine. May be it has something to do with the fact that the SSLSocket code is called from RMI, and native calls can't be resolved from there? Any idea on how this can be worked around? ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: CAs and external entities (resellers, outsourcing)
Hi Kai, long reply, I appreciate the grounding in actual policies and practices! This allows us to explore what we really can and cannot do. (I've cut two of your comments out to other posts where they might be generally intersting for the wider audience.) On 28/12/08 12:13, Kai Engert wrote: After having read the posts related to the unbelievable event, I understand the event involved an approved CA and an external entity they work with. Seems about right. From my perspective, it's a CA's job to ensure competent verification of certificate requests. The auditing required for CAs is supposed to prove it. [see other post] The verification task is the most important task. All people and processes involved should be part of the assuring audit. The current Mozilla CA Certificate Policy says: 6. We require that all CAs whose certificates are distributed with our software products: ... provide attestation of their conformance to the stated verification requirements ... OK! And, we can reasonably suggest that pt 7 covers verification, as per the above. In my opinion, it means, a CA must do this job themselves. No, to me, it means the CA must provide attestation of conformance by an independent party. That means they must show how they meet the things that Mozilla lists in pt 7. Which language suggests they have to do verification *themselves* ? BTW, it would be quite problematic to insist that the CAs do this job themselves. CAs are not generally experts on the issues raised. Traditionally, CAs outsource the processess within verification to a range of different organisations: government registries, commercial credit agencies, credit card companies, passport offices, birth registries, etc. That is, to insist they do it themselves would mean that they would have to develop skills that might be better handled elsewhere, and might in the end reduce to moving the deckchairs around. The policy currently does not appear to handle the scenario where a CA delegates the verification job to an external entity. So it's unclear whether it's forbidden or allowed if the external entity has received equivalent attestation of their conformance. I conclude it is allowed. However, whichever way it is done, the policy still insists that conformance to pt 7 is required. So, following that policy, a reasonable investigation to pursue in the current case is what that form of the attestation was, and how precise it was, etc. In my personal opinion, a CA violates the Mozilla CA Certificate Policy if they delegate the verification job to an external entity not owning attestation of their conformance to the stated verification requirements. I'm not sure I parse that, but I think you mean: If the CA delegates, and does not own the conformance requirement, then they have violated the policy. If so, ok. I see the following simplification: If the CA does not own the conformance to verification requirement, then they have violated the policy. If we'd like to be strict, we could remove CAs from our approved list if they have shown to be non-conforming in the above way. [see other post] In any case, the CA policy should get clarified about involving external entities in the verification and issueing process. There are normal business and PKI assumptions in operation here: The CA will involve external entities for as many things as possible. The CA will document the external entities. The CA will take responsibility for the result. (The CA will express its liability and warranty in its RPA.) It may be that you want to surface and state these assumptions. However, to turn it into a criteria or policy point, you would need to much more clearly refine your point, *and* you should clearly relate it to how this will improve security. I suggest this is much tougher than it sounds. E.g., Which external entities are OK? Why? How are they checked? Is it ok to accept an audit? Which audit? Where is the line drawn? Is a passport an outsourcing? If not, is a credit card? Is a website? Why consider external entities when we don't describe documents? If we care to regulate external entities, shouldn't we also regulate use of credit cards, which are known to be poor identity documents? Is one check enough? Two? Correlated? Serial or parallel? And add a thousand other questions. It gets complex! It is for this reason of complexity that we normally apply a reasonableness test. It is reasonable to use external entities, and as long as it is stated in the CPS, then it is up to each party to decide whether they accept that for their individual circumstances. (Those parties include: the CA, auditor(s), vendors, downstream vendors, relying parties, and ultimately end-users.) All existing CAs should be required to make a statement about their current business practices with regards to external
Re: dropping the root is useless
On 28/12/08 15:42, Eddy Nigg wrote: On 12/28/2008 04:24 PM, Ian G: I was clearly replying to the later part: The CA will lose; potentially it will lose its revenue stream, or have it sliced in half (say), which is what we would call in business circles a plausible bankrupcy event. It's not relevant. Well, that part may not be a loss that effects a security discussion. But I've made the point before that economic interests are much more important and may be dominant. See below the discussion of lawyers. So perhaps you won't mind if I keep bringing them up. We might simply disagree as to their practical relevance to the real world discussion. No, I'm afraid there is an agreement to list the root, under a policy. Once listed, Mozilla has to operate according to its side of the bargain. Apparently you are reading something I haven't. Statements (policy, etc) plus actions gives rise to an agreement. The agreement doesn't have to be written in one document to exist, it can exist without anything to read, or with many things to read. The problem being, that even if it reserves the right to make a choice for any reason, this does not give Mozilla carte blanche. Mozilla can make a bad decision, no doubt. This case is most likely not one of those you are referring to. Well, who is going to warrant that for Mozilla? Please read it carefully. a root being dropped by a BAD decision. A root isn't removed before careful considerations. A bad decision doesn't warrant not to remove any roots at all if necessary. Mozilla can also reinstate a root. If in court, we can be sure that the CA will argue that the decision is bad. The judge will bend over backwards to let the CA make that case; that's what the court is there for. (This then turns on who has the burden, and what question has to be answered. Er, now we need the lawyers.) What I'm about here is that: in any wider business analysis, the answer is that, short of total collapse, do not remove the root. And if there is total collapse, you will be wrong regardless, so it doesn't really matter what you do. I am not saying I *like* it. In fact, I don't like it. I'm saying the tool is bankrupt. Think of other tools, this one will not work for you. Let me put it another way: one phone call from the CA's lawyer to Mozo's lawyer is probably sufficient to solve this problem *for the CA*. Ask yourself whether you have a lawyer. Ask your lawyer whether he can make the phone call. Ask your lawyer how the phone call will go (he doesn't need to make it). Let us know what he says, for the education of us all. They stated how many, IIRC. I recall it was something like 111 certs issued and 11 outstanding that had not been re-verified within around 48 hours (these numbers are not accurate, but indicative) and were therefore revoked. That's for the specific certstar case. Domain validation isn't performed by Comodo on a wide scale apparently and perhaps no validation is performed at all. Oh, that's a new claim, beyond this reseller. Is there any evidence? If so, then maybe there should likely be a new investigation, and widespread revocations by the CA of the non-verified certs. OK, as discussed earlier, actual investigations are outside scope of here (which begs the important question of where it is in scope of!) so let's not speculate further on Comodo's exact position. Back to the damages estimate: we still need to form an estimate of how many certificates were issued to people of malintent. Without that, we are still left with a damages estimate of zero, albeit one multiplied by a much larger number of users, with a much greater range of possible error. iang ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Security-Critical Information (i.e. Private Key) transmittedby Firefox to CA (i.e. Thawte) during X.509 key/cert generation
On 28/12/08 15:47, Anders Rundgren wrote: PKIX are not aware of the problem because PKIX don't do browsers, they do ASN.1. Who does browsers? iang ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Security-Critical Information (i.e. Private Key) transmittedby Firefox to CA (i.e. Thawte) during X.509 key/cert generation
Anders Rundgren wrote: I wouldn't spend much work on keygen and crypto.generateCRMFRequest because they don't match today's needs anyway. Anders, does the word keygen trigger an automatic response in your news bot? ;-} Your comment is not relevant in this context. Off course the *existing* implementation of keygen and crypto.generateCRMFRequest should be fully *documented* as Nelson suggested. Ciao, Michael. - Original Message - From: Michael Ströder mich...@stroeder.com Newsgroups: mozilla.dev.tech.crypto To: dev-tech-crypto@lists.mozilla.org Sent: Sunday, December 28, 2008 13:38 Subject: Re: Security-Critical Information (i.e. Private Key) transmittedby Firefox to CA (i.e. Thawte) during X.509 key/cert generation Nelson B Bolyard wrote: I also think we need a page or two on developer.mozilla.org that fully documents both the keygen tag and the crypto.generateCRMFRequest method. +1 The existing documentation is very incomplete. The keygen tag, for example, accepts many more arguments than are now publicly documented. Which arguments are that? Ciao, Michael. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Security-Critical Information (i.e. Private Key) transmittedbyFirefox to CA (i.e. Thawte) during X.509 key/cert generation
Michael Ströder wrote: Anders Rundgren wrote: I wouldn't spend much work on keygen and crypto.generateCRMFRequest because they don't match today's needs anyway. Anders, does the word keygen trigger an automatic response in your news bot? ;-} Well, some 1000h into its successor have left some traces :-) :-) Your comment is not relevant in this context. Off course the *existing* implementation of keygen and crypto.generateCRMFRequest should be fully *documented* as Nelson suggested. Maybe, maybe not. I assume that private key transfer is only allowed (if possible at all) for encryption keys. It seems to me that this is a rather useless function since most organizations are more concerned about sent data than received ditto. I.e. key escrow doesn't work very well for organizations which is why Outlook has an entirely different approach to message escrow which actually works (clear-text message logging in parallell to encrypted messaging). If the fear is rather that the CA could impersonate a user, it can do that without notifying the user with warning dialogs. If the goal is rather providing encryption key backup for consumers, I guess we are back to the question if S/MIME encryption is for real or not. Based on actual usage by consumers this issue is already settled. That is, if private key transfer actually is enabled the correct solution [IMO] is not to dicument it, but to disable it. Anders - Original Message - From: Michael Ströder mich...@stroeder.com Newsgroups: mozilla.dev.tech.crypto To: dev-tech-crypto@lists.mozilla.org Sent: Sunday, December 28, 2008 13:38 Subject: Re: Security-Critical Information (i.e. Private Key) transmittedby Firefox to CA (i.e. Thawte) during X.509 key/cert generation Nelson B Bolyard wrote: I also think we need a page or two on developer.mozilla.org that fully documents both the keygen tag and the crypto.generateCRMFRequest method. +1 The existing documentation is very incomplete. The keygen tag, for example, accepts many more arguments than are now publicly documented. Which arguments are that? Ciao, Michael. ___ 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: CAs and external entities (resellers, outsourcing)
On 12/28/2008 01:13 PM, Kai Engert: The current Mozilla CA Certificate Policy says: 6. We require that all CAs whose certificates are distributed with our software products: ... provide attestation of their conformance to the stated verification requirements ... Kai, just to counter Ian's reply: The objective of the Mozilla CA policy is to provide sound, reliable and in this context reasonable security for its users. This is anchored clearly in the Mozilla Manifesto as a principal and further described and defined in the Mozilla CA Policy what PKI and CAs concerns. The Mozilla CA Policy is clear in its requirements, *intend* and what it is meant to achieve. All the rest is just throwing sand into ones eyes. In this respect section 7 of said policy clearly states what the requirements are. CAs may find different ways to achieve and conform to those requirements, however it should not lead to a compromise of those requirements. Personally I wouldn't outsource domain control validation but incorporate it into the general process of certificate issuance. In case it is delegated, the third party must provide attestation of their conformance. I think this is what you were proposing... -- 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: dropping the root is useless
On 12/28/2008 4:46 AM, Ian G wrote [in part]: On 28/12/08 12:13, Kai Engert wrote: If we'd like to be strict, we could remove CAs from our approved list if they have shown to be non-conforming in the above way. Yes, we could! But this is what we call a blunt weapon. It is also a dangerous weapon. Consider (all) the consequences in the current case. First, losses we will incur, regardless: 1. Certs: All end-users who rely on these certs will lose. That probably numbers in the millions. All subscribers will lose, probably in the thousands. The CA will lose; potentially it will lose its revenue stream, or have it sliced in half (say), which is what we would call in business circles a plausible bankrupcy event. So when a CA behaves badly, we should still be concerned that the CA might lose money? Because a CA might go bankrupt, we should do nothing? How about the users of Mozilla products who might lose money or even go bankrupt because they trusted a root certificate from such a CA? No, such losses are not known (yet). What did happen, however, indicates that such losses are indeed possible and not only through Certstar. -- David E. Ross http://www.rossde.com/ Go to Mozdev at http://www.mozdev.org/ for quick access to extensions for Firefox, Thunderbird, SeaMonkey, and other Mozilla-related applications. You can access Mozdev much more quickly than you can Mozilla Add-Ons. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: [Fwd: Follow-Up on www.verisign.com SSL Order]
On 12/28/2008 09:45 PM, Reed Loden: You can use any e-mail address as a Google Account, so yes, I really think so. Patricia's reply confirms this, too. Reed, Servage is a hosting company, their MX record isn't that of Google, but their own. This email account is not hosted with Google. You can't just use any email address you like, you must set the DNS zone accordingly. -- 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: Security-Critical Information (i.e. Private Key) transmittedbyFirefox to CA (i.e. Thawte) during X.509 key/cert generation
Anders Rundgren wrote, On 2008-12-28 07:52: [...] most organizations are more concerned about sent data than received [...] This is one reason (out of many) that Mozilla's S/MIME mail clients require that the sender be an implicit recipient of any encrypted messages sent. It ensures that the sender's private key is also able to decrypt the messages he sends. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Security-Critical Information (i.e. Private Key) transmittedby Firefox to CA (i.e. Thawte) during X.509 key/cert generation
(Note: this is almost completely off-topic as relates to the OP's message.) REAL programmers do everything they can to point out flaws of things that don't meet their needs, but are easier to use, older, more-debugged, and sufficient for those cases that don't require the ability to trust code running on the client machine to implement the policy that the server asks for. i.e., just because they don't meet YOUR needs of today doesn't mean they don't meet MINE. And the requirements you have are more in line with requiring DRM (and thus Trusted Computing where the user of the machine doesn't have access to the trusted platform module) than anything that can be implemented in user-land, anyway. If I understand what you've been working with, you're encoding key generation/request parameters into XML to be handled by the client. If you're doing XML for the parameters-provision, why not break the certificate request into XML too? Oddly enough, there is an ITU standard for this -- it's called XML Encoding Rules for ASN.1, or XER. I'm actually surprised nobody's started using XER for certificate storage/examination. Since DER is a means of encoding ASN.1 structures into the minimum number of bits, and since XER is an alternate encoding mechanism (though arguably into the MAXIMUM number of bits) for the same data, it would work -- yes, the signature is calculated over the DER encoding of the data, but that can be reconstituted from the XER. (My understanding is that this is part of what certificate validation is supposed to handle anyway -- all the information split out and stuck in a database, then reconstituted/revalidated as necessary.) Yes, we'd need special tools to verify the signature, but we already need special tools to parse DER. It would be a net win for debuggability and understanding what is in each certificate without having to load our DER parser every time we want to look at it. -Kyle H On Sun, Dec 28, 2008 at 6:47 AM, Anders Rundgren anders.rundg...@telia.com wrote: I wouldn't spend much work on keygen and crypto.generateCRMFRequest because they don't match today's needs anyway. You cannot even as an issuer control PIN code settings (policy) unless you have a pre-configured crypto container, i.e. these mechanisms are tools for toy PKIs. Serious PKIs use smart cards and physical card/key/certificate distribution because the on-line alternatives are more or less useless in addition to being completely non-standard. The coming HTML5 standards work does not even *try* to address this mess. I think they did the right thing; PKI standards in browsers reached an all-time-high already 10 years ago. PKIX are not aware of the problem because PKIX don't do browsers, they do ASN.1. Anders - Original Message - From: Michael Ströder mich...@stroeder.com Newsgroups: mozilla.dev.tech.crypto To: dev-tech-crypto@lists.mozilla.org Sent: Sunday, December 28, 2008 13:38 Subject: Re: Security-Critical Information (i.e. Private Key) transmittedby Firefox to CA (i.e. Thawte) during X.509 key/cert generation Nelson B Bolyard wrote: I also think we need a page or two on developer.mozilla.org that fully documents both the keygen tag and the crypto.generateCRMFRequest method. +1 The existing documentation is very incomplete. The keygen tag, for example, accepts many more arguments than are now publicly documented. Which arguments are that? Ciao, Michael. ___ 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 ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Security-Critical Information (i.e. Private Key) transmitted by Firefox to CA (i.e. Thawte) during X.509 key/cert generation
Michael Ströder wrote, On 2008-12-28 04:38 PST: Nelson B Bolyard wrote: I also think we need a page or two on developer.mozilla.org that fully documents both the keygen tag and the crypto.generateCRMFRequest method. +1 The existing documentation is very incomplete. The keygen tag, for example, accepts many more arguments than are now publicly documented. Let me start by saying that there are very few documents known to me that are authoritative documentation of the keygen tag, and all are essentially archival copies of documentation developed at Netscape in a prior millennium. They are: http://devedge-temp.mozilla.org/library/manuals/1998/htmlguide/tags10.html#1615503 which is now 11 years old, and http://docs.sun.com/source/816-5535-10/index.html#DSA (6 years old) and https://developer.mozilla.org/En/HTML/HTML_Extensions/KEYGEN_Tag which seems to be the most complete, but is still not complete. Which arguments are that? Now, here's what's not documented. 1. The attribute name keyparams is a synonym for the attribute name pqg. Either name may be used for that attribute. 2. There are 3 recognized values for the keytype attribute. They are rsa, dsa and ec. 3. When the keytype is ec, the EC curve used in the generated key is selected by the value of the optional keyparams attribute, if - it is present and - it is one of the strings found in the table at http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/security/manager/ssl/src/nsKeygenHandler.cpprev=1.49mark=179-256#177 - and the indicated curve is supported in that browser. Otherwise, it is chosen by the user's choice from the key size choice box according to the following table Key SizeCurve - Highsecp384r1 Medium secp256r1 Low secp256r1 The documentation for crypto.generateCRMFRequest is found at https://developer.mozilla.org/en/JavaScript_crypto/generateCRMFRequest but it is also incomplete. The EC key generation documentation is missing. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: dropping the root is useless
On Sun, Dec 28, 2008 at 6:24 AM, Ian G i...@iang.org wrote: (following is just for the record so as to deal with the response. No new info is in here for other readers.) I would very much appreciate it if you would stop using fear, uncertainty, and doubt to manipulate the audience into believing your and only your viewpoint. Unlike you, Eddy actually runs a certifying authority. This means that he has operational experience with not only the technical sides of things, but also the legal sides of things. Just because you also happen to be an advocate for CAcert (and -- unlike Eddy -- feel the urge to hide that affiliation) does not mean that you actually run it, or have the depth or breadth of knowledge necessary to do so. This message shows me that you honestly don't care about what security actually is, you just care about the end-user experience. This is NOT the same thing. As such, my opinion of your authority on the subject matter has diminished severely. True security involves knowing what the risks are. Mozilla's policy for root inclusion tries to reduce the uncertainty for end-users; unfortunately, as has been pointed out repeatedly, there is still far too much uncertainty for end-users in Comodo's operations. They have lost my trust, the same way that you have. On 28/12/08 14:21, Eddy Nigg wrote: On 12/28/2008 02:46 PM, Ian G: 1. Certs: All end-users who rely on these certs will lose. That probably numbers in the millions. All subscribers will lose, probably in the thousands. The CA will lose; potentially it will lose its revenue stream, or have it sliced in half (say), which is what we would call in business circles a plausible bankrupcy event. Not relevant. Well! If they are not relevant, then perhaps we can turn SSL off, with no consequences? If Nelson can upbraid me for ad hominem attacks, I'm going to upbraid you for ad absurdem arguments. TLS (can we PLEASE stop using SSL, since the last version of SSL that got ratified by any standards organization was SSLv2, and SSLv3 is a hack that reached internet-draft phase but was never formally recognized?) has the option of negotiating a secure connection without the use of any certificates at all. (Further, SSLv3 also had the same mechanism.) There's still the endpoint confidentiality concept -- nobody between the client and the server that the client is talking to can hear what's being said between them. The problem that certificates (or key continuity management) is designed to solve is the problem where the client thinks it's talking to one server, when it's really talking to another (the fraudulent endpoint attack in the case where the server-endpoint doesn't pass any data to the real server, and the man in the middle attack in the case it does). To ignore the obvious legal ramifications (agreements in RPAs, disclaimers to end-users, potential lawsuits ...) would be negligence, IMHO. We know the ramifications exist. We know they may be serious. We know that assertations of security are being made to end-users. Hence to continue making these assertations, and not treat them seriously would be negligence. I personally choose not to follow that path into negligence, and will continue to consider the legal ramifications, which leads to the question of how we consider them. In my mind (and this is not legal advice, merely a statement of thought presented for the purposes of argument), Mozilla has a duty to me as an end-user to uphold the letter and spirit of its CA Certificate Policy. I've already presented my thought on how a full tort could be brought against Mozilla by the operator of any CA already in the trust list. If a Comodo-issued certificate causes any user damage after the initial disclosure on the list, a tort could be brought against Mozilla by that end-user. Mozilla has no legal or any other requirement (as far as I know) to include or keep a root. No, I'm afraid there is an agreement to list the root, under a policy. Once listed, Mozilla has to operate according to its side of the bargain. The policy explicitly provides for Mozilla removing a root, at its option. Section 4 of the CA Certificate Policy: We reserve the right to not include a particular CA certificate in our software products, to discontinue including a particular CA certificate in our products, or to modify the trust bits for a particular CA certificate included in our products, at any time and for any reason. It gives examples of the situations that it could do so in, but it also explicitly states that its appropriate reasons for doing so ARE NOT LIMITED TO those examples. Please also recognize that the right and protection of the many tends, at least in the US court system that Mozilla and Comodo are subject to, outweighs the right and protection of the few or one (the company which operates the CA). This is a general consequence of business, there is nothing special about it. Ask any experienced
Re: dropping the root is useless
On Sun, Dec 28, 2008 at 9:28 AM, Ian G i...@iang.org wrote: On 28/12/08 17:06, David E. Ross wrote: How about the users of Mozilla products who might lose money or even go bankrupt because they trusted a root certificate from such a CA? No, such losses are not known (yet). What did happen, however, indicates that such losses are indeed possible and not only through Certstar. Yes, indeed. That's a big question. What I am suggesting is that dropping the root will not address that question. It is too blunt a weapon to be used reliably. Considering that trustability is viewed as a binary state, it's the only weapon that Mozilla has. -Kyle H ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: dropping the root is useless
On 29/12/08 00:37, Kyle Hamilton wrote: On Sun, Dec 28, 2008 at 9:28 AM, Ian Gi...@iang.org wrote: On 28/12/08 17:06, David E. Ross wrote: How about the users of Mozilla products who might lose money or even go bankrupt because they trusted a root certificate from such a CA? No, such losses are not known (yet). What did happen, however, indicates that such losses are indeed possible and not only through Certstar. Yes, indeed. That's a big question. What I am suggesting is that dropping the root will not address that question. It is too blunt a weapon to be used reliably. Considering that trustability is viewed as a binary state, it's the only weapon that Mozilla has. Yes. This is reason for concern. iang ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: dropping the root is useless
On Sun, Dec 28, 2008 at 3:42 PM, Ian G i...@iang.org wrote: On 29/12/08 00:37, Kyle Hamilton wrote: Considering that trustability is viewed as a binary state, it's the only weapon that Mozilla has. Yes. This is reason for concern. FWIW, I agree. Alright, I propose that, in a new thread, we open the table for discussion of the problems inherent in the binary-state model, and ways to mitigate these problems? -Kyle H ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: dropping the root is useless
On 29/12/08 00:36, Kyle Hamilton wrote: On Sun, Dec 28, 2008 at 6:24 AM, Ian Gi...@iang.org wrote: Unlike you, Eddy actually runs a certifying authority. This means that he has operational experience with not only the technical sides of things, but also the legal sides of things. I support your right to an opinion, but can you please ground your criticisms in facts of relevance, rather than ad hominims. Just because you also happen to be an advocate for CAcert Strawman. An Auditor is perhaps an advocate in the sense that he writes an opinion. I have not done that, and won't for another 6 months at current progress. Here's *just* the local dirt: https://bugzilla.mozilla.org/show_bug.cgi?id=215243#c158 I think the advocacy claim looks a little silly, no? Absurd, even. (and -- unlike Eddy -- feel the urge to hide that affiliation) does not mean that you actually run it, or have the depth or breadth of knowledge necessary to do so. This message shows me that you honestly don't care about what security actually is, you just care about the end-user experience. This is NOT the same thing. As such, my opinion of your authority on the subject matter has diminished severely. You are entitled to your opinion, but I would ask you to consider that this is a policy forum, not an ad hominem shooting match. True security involves knowing what the risks are. Mozilla's policy for root inclusion tries to reduce the uncertainty for end-users; unfortunately, as has been pointed out repeatedly, there is still far too much uncertainty for end-users in Comodo's operations. The point I have made is that the discussion of Comodo's operations is outside scope of this forum. You may feel that you have an opinion, and you have a right to it. However, this forum is not for the investigation of breaches or failures to comply with policies. If you dislike that, don't start a war against me. Suggest a policy change to Mozilla. If you want wordings, try this: x. Any breaches of security or failures to comply will be discussed in the policy forum of Mozilla, a ruling by consensus delivered, and will be binding on the CA. Don't disagree with me in a post, do something. Write the proposal, change the policy. Words are less important than acts. They have lost my trust, the same way that you have. Now over to you. Act, not talk. Make a dispute resolution forum happen. On 28/12/08 14:21, Eddy Nigg wrote: On 12/28/2008 02:46 PM, Ian G: 1. Certs: All end-users who rely on these certs will lose. That probably numbers in the millions. All subscribers will lose, probably in the thousands. The CA will lose; potentially it will lose its revenue stream, or have it sliced in half (say), which is what we would call in business circles a plausible bankrupcy event. Not relevant. Well! If they are not relevant, then perhaps we can turn SSL off, with no consequences? If Nelson can upbraid me for ad hominem attacks, I'm going to upbraid you for ad absurdem arguments. TLS (can we PLEASE stop using SSL, since the last version of SSL that got ratified by any standards organization was SSLv2, and SSLv3 is a hack that reached internet-draft phase but was never formally recognized?) has the option of negotiating a secure connection without the use of any certificates at all. (Further, SSLv3 also had the same mechanism.) There's still the endpoint confidentiality concept -- nobody between the client and the server that the client is talking to can hear what's being said between them. The problem that certificates (or key continuity management) is designed to solve is the problem where the client thinks it's talking to one server, when it's really talking to another (the fraudulent endpoint attack in the case where the server-endpoint doesn't pass any data to the real server, and the man in the middle attack in the case it does). Er, Kyle, you are off on a tangent here. My point with Eddy was fully addressed by him pointing out that he was only dealing with the last sentance, I thought he was referring to the earlier sentances. A reasonable clarification. To ignore the obvious legal ramifications (agreements in RPAs, disclaimers to end-users, potential lawsuits ...) would be negligence, IMHO. We know the ramifications exist. We know they may be serious. We know that assertations of security are being made to end-users. Hence to continue making these assertations, and not treat them seriously would be negligence. I personally choose not to follow that path into negligence, and will continue to consider the legal ramifications, which leads to the question of how we consider them. In my mind (and this is not legal advice, merely a statement of thought presented for the purposes of argument), Mozilla has a duty to me as an end-user to uphold the letter and spirit of its CA Certificate Policy. I've already presented my thought on how a full tort could be
Re: dropping the root is useless
On 12/29/2008 03:09 AM, Ian G: The point I have made is that the discussion of Comodo's operations is outside scope of this forum. You may feel that you have an opinion, and you have a right to it. However, this forum is not for the investigation of breaches or failures to comply with policies. If you dislike that, don't start a war against me. Suggest a policy change to Mozilla. If you want wordings, try this: x. Any breaches of security or failures to comply will be discussed in the policy forum of Mozilla, a ruling by consensus delivered, and will be binding on the CA. I don't think you are entirely correct, Ian. The community has its say, is free to discuss, suggest, propose, vent its anger and more. The ultimate decision lies with Frank and Mozilla's management, however discussions, suggestions, opinions, proposals are an important part of shaping those decisions I think. I'm saying this from experience as many times the mentioned above influenced decisions and/or resulted directly in actions. I think this is what makes Mozilla incredible unique. Not every objection, suggestion or proposal results in a standing ovation obviously, but overall I'm quite pleased. And it's a two way street many times, as members of Mozilla and the community made suggestions or voiced their opinion, which directly lead to changes at the company *I* run. Sometimes this happened in the public forums, sometimes in private. The decisions are taken obviously elsewhere, however this forum directly influenced some them. In that respect I disagree that this forum isn't the right place to discuss, disclose, propose, exchange thoughts and even investigate. I wouldn't know a better place. And in the same time, I'd disagree that the community should make the ultimate decision, the responsibility is clearly with the Mozilla Foundation (?) and must be decided there. -- 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: dropping the root is useless
On 12/28/2008 3:45 PM, Kyle Hamilton wrote [in part]: CertStar was found out, only due to the diligence of someone on this list. How many other RAs haven't been found out yet? We can't know, because Comodo won't say. This affects the confidence I have in their system (i.e., it removes ALL confidence that Mozilla extended on my behalf). Actually, Eddy discovered the problem only through the fortuitous receipt of spam from CertStar. If he had not received the spam -- even if others had received it -- it is possible the problem would never have been discovered. This is why the discovery is so frightening. Now that it is known that a subordinate reseller operating under one CA issued certificates without authenticating the identity of the subscribers, we know that the theoretical concern expressed (before all this) about resellers is no longer theoretical. NOW is the time to require that all CAs supervise the operations of their RAs and resellers. This must be done in a way that independent audits of the CAs examine the implementation of such supervision, which can be accomplished by requiring (at least with respect to the Mozilla database) that CPs explicitly address how that supervision is performed. Either a CA's CP must explicitly state that there are NO external RAs or resellers, or else the CP must describe how external subordinates are monitored. Without this, a CA's request to have its root certificate included in the Mozilla database should be denied. Since an audit will generally report on the implementation of such a policy but not necessarily on the policy's adequacy, the internal and public reviews of CA requests must examine the adequacy of the CA's policy for monitoring external subordinates. -- David E. Ross http://www.rossde.com/ Go to Mozdev at http://www.mozdev.org/ for quick access to extensions for Firefox, Thunderbird, SeaMonkey, and other Mozilla-related applications. You can access Mozdev much more quickly than you can Mozilla Add-Ons. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: dropping the root is useless
David E. Ross wrote, On 2008-12-28 21:40 PST: Now that it is known that a subordinate reseller operating under one CA issued certificates without authenticating the identity of the subscribers, we know that the theoretical concern expressed (before all this) about resellers is no longer theoretical. NOW is the time to require that all CAs supervise the operations of their RAs and resellers. This must be done in a way that independent audits of the CAs examine the implementation of such supervision, which can be accomplished by requiring (at least with respect to the Mozilla database) that CPs explicitly address how that supervision is performed. Either a CA's CP must explicitly state that there are NO external RAs or resellers, or else the CP must describe how external subordinates are monitored. Without this, a CA's request to have its root certificate included in the Mozilla database should be denied. +1 Perhaps the policy should even go so far, as Kai has suggested, as to require that whatever entity performs the verification of subject identity for the CA must be audited. Section 6 of the policy requires that all CAs whose certificates are distributed with our software products must prior to issuing certificates, verify certificate signing requests in a manner that we deem acceptable, and provide attestation of their conformance to the stated verification requirements and other operational criteria by a competent independent party or parties with access to details of the CA's internal operations. I think that last part clearly assumed that the verification requirements were part of the CA's internal operations, an assumption that we now know is untrue. So, I would suggest changing it from access to details of the CA's internal operations to access to the details of the operations that verify the certificate signing requests, whether internal or external Since an audit will generally report on the implementation of such a policy but not necessarily on the policy's adequacy, the internal and public reviews of CA requests must examine the adequacy of the CA's policy for monitoring external subordinates. Yes. Agreed. I think the policy should define some parameters (bounds) for determining the adequacy of CSR verification. It is acceptable to have hundreds of parties each responsible for verifying CSRs for a single CA (single issuer)? If not, what limit should apply? I'd like to see any statements made by Mozilla at the beginning of the week of public review to explicitly speak to the CSR verification process, and whether it is internal or external, and how many RAs (or parties entrusted with verifying CSRs) exist for the particular CA (organization), and the number of CSR verification parties per subordinate CA. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: [Fwd: Follow-Up on www.verisign.com SSL Order]
On Sun, 28 Dec 2008 22:13:53 +0200 Eddy Nigg eddy_n...@startcom.org wrote: On 12/28/2008 09:45 PM, Reed Loden: You can use any e-mail address as a Google Account, so yes, I really think so. Patricia's reply confirms this, too. Reed, Servage is a hosting company, their MX record isn't that of Google, but their own. This email account is not hosted with Google. You can't just use any email address you like, you must set the DNS zone accordingly. s/any e-mail address/any _valid_ e-mail address/ When I talk about e-mail addresses, I'm usually referring to valid, real addresses. A Google Account doesn't have to be a Gmail address. I know of a lot of people who use the local part of their e-mail address to represent how the address is used. goo...@servage.net seems like a reasonable account to use for Google-related things. My comment still stands as accurate and valid. ~reed -- Reed Loden r...@reedloden.com ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: dropping the root is useless
On 12/28/2008 9:42 AM Eddy Nigg cranked up the brainbox and said: On 12/28/2008 04:24 PM, Ian G: No, I'm afraid there is an agreement to list the root, under a policy. Once listed, Mozilla has to operate according to its side of the bargain. Apparently you are reading something I haven't. Apparently, but that doesn't mean it's invalid. Mozilla can't act arbitrarily and without cause and expect to retain any shred of respect or trustworthiness. A policy not adhered to is worthless. That's for the specific certstar case. Domain validation isn't performed by Comodo on a wide scale apparently and perhaps no validation is performed at all. Yes, perhaps, and perhaps they send out certs to anyone who asks nicely, but we have little evidence to support these suppositions. Rather than having a kneejerk reaction of removing Comodo from the root list, why don't we examine the situation. This reseller was not acting according to proper procedure. Comodo immediately revoked their reseller status, and reviewed their certs. Further, they've said they're reviewing their policies to ensure this doesn't happen again. Given their candor and quick response, what more do you require that you feel you're not getting that justified removing them as a root CA? I really think you're going overboard. Form what I see, I'm not alone in that assessment. You did a good job in bringing this to light. Having the issues you uncovered addressed and fixed should be sufficient. Why do we need to take punitive action that will do nothing but punish tens of thousands of other Comodo customers and millions of users? -- Grey Hodge email [ grey @ burntelectrons.org ] web [ http://burntelectrons.org ] tag [ Don't touch that! You might mutate your fingers! ] motto [ Make everything as simple as possible, but no simpler. - Einstein ] ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
