Re: Unbelievable!
https://bugzilla.mozilla.org/show_bug.cgi?id=426575 UTN-UserFIRST-Hardware is enabled for EV per that bug. -Kyle H On Thu, Dec 25, 2008 at 9:59 AM, Frank Hecker hec...@mozillafoundation.org wrote: Kyle Hamilton wrote: What is the effect of this problem on the request to enable the UTN-UserFirst-Hardware root for EV, https://bugzilla.mozilla.org/show_bug.cgi?id=401587 ? I think (but don't have time to confirm right at the moment) that that request is moot. As far as I know, Comodo EV certificates are working fine right now even in the absence of the UTN-UserFirst-Hardware root being enabled for EV. This is due to EV-enabling of the new Comodo EV root and also IIRC due to code that was added to PSM (?) to specially handle cases like this where the EV root was cross-signed by a non-EV legacy root. (AFAIK this scenario was/is not unique to Comodo. I believe all the VeriSign EV CAs work this way as well: a newly added and EV-enabled EV root cross-signed by a non-EV legacy root.) Frank -- Frank Hecker hec...@mozillafoundation.org ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Unbelievable!
On Dec 24, 2:13 am, Paul C. Bryan em...@pbryan.net wrote: On Dec 23, 5:56 pm, ro...@comodo.com wrote: Some questions: 1. Does Comodo take full responsibility for the actions of its resellers? If so, how should the repercussions of such failures be to Comodo? Comodo accepts responsibility for the work of its RAs in the validation that they do leading to the issuance of certificates under our root certificates. 2. Are resellers subject to the same audits that Comodo presumably had to undergo to get its root certs added to Mozilla? Who performs, and who verifies such audits? How often are they performed? No, the RAs are not subject to the same audits as Comodo. Comodo undergoes an annual external audit to maintain our Webtrust certification for CAs. http://www.cica.ca/download.cfm?ci_id=45239la_id=1re_id=0 https://cert.webtrust.org/ViewSeal?id=804 3. Are you willing to openly, continually disclose your list of resellers, the frequency of audits, audit methodology, and actual audit reports so that third parties can evaluate whether Comodo is trustworthy as a CA? That is a question combined with an assertion. To the question: on a unilateral basis, no, Comodo wouldn't reveal that level of detail of our internal operation. If all CAs were required to provide the information, either to retain Webtrust certification or to gain or retain access to the root program of a major browser or other platform, then we would reconsider. To the assertion that this is a pre-requisite for a CA to be trustworthy: I am not aware that it is Mozilla's policy to require this information to be disclosed. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Unbelievable!
See, Robin, my thought is this: You've already shown that it's possible for the RA function to bypass all controls. At this point, because they're not subject to the same audits that Comodo is, and because the last WebTrust audit that anyone here can find any record of is in 2007, I find it difficult to believe that you have the annual external audit. The internal controls are supposed to prevent this kind of mis-issuance. Because they didn't, they throw all the audits that you have provided into doubt. Because of this, there is no trust that I have in Comodo's operation. Further, this is a problematic practice (delegation of Registration Authority function, as opposed to simple reseller role) that has been shown to cast doubt on the entire domain. The Registration Authority function is terribly security-sensitive. If the whistle had not been blown by someone who knew where to post to kick the beehive, would this have been detected? Since the RAs aren't audited (which is, by the way, a TERRIBLY dangerous practice, as you're seeing), and your statements about a representative sample of certificate requests are reviewed suggesting that they're not even properly audited by your internal controls... It is not necessarily a requirement for reseller information to be disclosed. However, we're trying to evaluate your company's continued trustworthiness, and (at least at the moment) I can't find anything there to trust. I'm willing to allow your eleven roots to stay in the root store with trust bits removed until you provide documentation and an update to your agreement with your RAs to require on-site audits at least annually (even if done by your internal auditors) -- the only alternative at this point is to completely remove your roots from the program. I would like to know how you're going about ensuring that none of your other RAs are subject to the same 'glitch' in their signup processes. I'd like to hear that you're being proactive about this issue. Unfortunately, I'm not hearing such. -Kyle H On Fri, Dec 26, 2008 at 1:10 PM, ro...@comodo.com wrote: On Dec 24, 2:13 am, Paul C. Bryan em...@pbryan.net wrote: On Dec 23, 5:56 pm, ro...@comodo.com wrote: Some questions: 1. Does Comodo take full responsibility for the actions of its resellers? If so, how should the repercussions of such failures be to Comodo? Comodo accepts responsibility for the work of its RAs in the validation that they do leading to the issuance of certificates under our root certificates. 2. Are resellers subject to the same audits that Comodo presumably had to undergo to get its root certs added to Mozilla? Who performs, and who verifies such audits? How often are they performed? No, the RAs are not subject to the same audits as Comodo. Comodo undergoes an annual external audit to maintain our Webtrust certification for CAs. http://www.cica.ca/download.cfm?ci_id=45239la_id=1re_id=0 https://cert.webtrust.org/ViewSeal?id=804 3. Are you willing to openly, continually disclose your list of resellers, the frequency of audits, audit methodology, and actual audit reports so that third parties can evaluate whether Comodo is trustworthy as a CA? That is a question combined with an assertion. To the question: on a unilateral basis, no, Comodo wouldn't reveal that level of detail of our internal operation. If all CAs were required to provide the information, either to retain Webtrust certification or to gain or retain access to the root program of a major browser or other platform, then we would reconsider. To the assertion that this is a pre-requisite for a CA to be trustworthy: I am not aware that it is Mozilla's policy to require this information to be disclosed. ___ 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: [Fwd: Follow-Up on www.verisign.com SSL Order]
goo...@servage.net wrote: On Dec 26, 5:27 pm, David E. Ross nob...@nowhere.not wrote: Note that the message from Certstar that Eddy posted said [emphsis added]: I am contacting you as I noticed that *you did completed* your SSL Certificate order forwww.verisign.comand wanted to follow up on it. You are right. It seems there was a typo in that email, it should of course have said you did not complete your SSL Certificate order as it is a follow up for people who do not complete the ordering process. Looking at the From: goo...@servage.net line of your posting you seem to like using names possibly leading to misunderstandings. Strange... Ciao, Michael. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Unbelievable!
On 12/26/2008 11:38 PM, Kyle Hamilton: You've already shown that it's possible for the RA function to bypass all controls. At this point, because they're not subject to the same audits that Comodo is, and because the last WebTrust audit that anyone here can find any record of is in 2007, I find it difficult to believe that you have the annual external audit. Robin just gave us the link for the current WebTrust report. As I mentioned previously Comodo does perform a yearly audit. However, since no directory exists at WebTrust, the last audit I could find was the one published at the Pending page. Here the new link: https://cert.webtrust.org/SealFile?seal=804file=pdf -- 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: Unbelievable!
Thanks for your response Robin. On Dec 26, 1:10 pm, ro...@comodo.com wrote: Comodo accepts responsibility for the work of its RAs in the validation that they do leading to the issuance of certificates under our root certificates. You failed to answer the other half of this question. What should the repercussions of such failures as this be for Comodo? Simply hoping you follow-up with your resellers (as has so far been the case with Certstar) is not an acceptable remedy in my opinion. No, the RAs are not subject to the same audits as Comodo. Comodo undergoes an annual external audit to maintain our Webtrust certification for CAs. How can the results of the Comodo audits be considered valid if Comodo outsources portions of its functions to third parties, that are not subject to the same audits? http://www.cica.ca/download.cfm?ci_id=45239la_id=1re_id=0https://cert.webtrust.org/ViewSeal?id=804 This link responds with an error result. That is a question combined with an assertion. Indeed, which I'll address below. To the question: on a unilateral basis, no, Comodo wouldn't reveal that level of detail of our internal operation. If all CAs were required to provide the information, either to retain Webtrust certification or to gain or retain access to the root program of a major browser or other platform, then we would reconsider. As I have mentioned in previous postings, a trust chain is only as strong as its weakest link. Comodo has added extra links in its chain, in the form of resellers whom it trusts to peform DV. If those links in the chain are not disclosed, and not subject to the same audits as the party applying for trust certification, then the integrity of the chain cannot be established. I expect that no other CAs are delegating their RA/DV functionality to third parties. If they are, then they're in the same boat as Comodo. To the assertion that this is a pre-requisite for a CA to be trustworthy: I am not aware that it is Mozilla's policy to require this information to be disclosed. I can't see how a CA can be considered trustworthy by anyone if it outsources portions of its core operations to undisclosed parties, and those parties are not subject to the same criteria, inspection and audits as the CA itself. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Unbelievable!
On Dec 26, 2:18 pm, Paul C. Bryan em...@pbryan.net wrote: This link responds with an error result. Apologies. Disregard my statement about the link error. I realized it's two links. I will now go drink some more coffee to increase my alertness level. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Avoid incorrect issuing of Certificates
Hi, Lately we have all seems that the certificate system is not 100% secure - mistakes happen. It might never become fully bullet proof but one simple change might help a lot. How about creating certificate type that is registered in a central database and require all CAs to check this DB before issuing new certificates? Once in that database no certificates could be issued for this specific domain. I think that most high profile sites would take advantage of such service. My suggestion probably needs a little fine tuning but it would be a step in the right direction. -- kind regards, Patricia, Certstar ApS ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Unbelievable!
On 26/12/08 22:38, Kyle Hamilton wrote: See, Robin, my thought is this: You've already shown that it's possible for the RA function to bypass all controls. At this point, because they're not subject to the same audits that Comodo is, and because the last WebTrust audit that anyone here can find any record of is in 2007, I find it difficult to believe that you have the annual external audit. The internal controls are supposed to prevent this kind of mis-issuance. Because they didn't, they throw all the audits that you have provided into doubt. Because of this, there is no trust that I have in Comodo's operation. The internal controls are not supposed to prevent mis-issuance. This is a gross consumer simplification, and has no place here. The controls are meant to reduce the likelihood of them, make them discoverable, and deal with them when they happen. We can no more prevent bad certs than we can stop the winter from coming. The point is to put in place economically reasonable policies and practices that meet an appropriate balance of security versus cost. If there has been a case where a particular instance has swayed and delivered too much convenience, for too high a security risk, then the systems will deal with it. So far the systems are dealing with it. Check the facts: CA was notified. Reseller frozen. Certs revoked. Internal audits are checking. External audit might get involved. This is what the systems are supposed to do. To all: Although we might in other contexts promote the use of open forums for open governance purposes -- analysis and discussion of the properties of providers by open parties -- *this public lynching is not that*. It is neither informed, nor professional. Mozilla runs a process where there is a one week period of public scrutiny of a CA. During that time, we could reasonably argue that people here are invited to state their fears. We might consider discussions to be more priviledged such as in parliament. However, outside that week, there is no such protection. Where people in this group have crossed the line, and made actionable statements, and/or done actionable harm to a business or individual, they should note: it is unlikely that Mozilla, or the community, or the businesses as a whole will, can or should protect them. And where corporates are forced to be quiet for fear of reputational damage, then it is up to the rest of us to seek professionalism and self-governance. The process of recovery from this hack is not an open nor public process. CAs, as businesses, and audits, as governance are not generally public affairs. If you wish to advance these into the open, by all means do, but first, establish a policy and a practice. Let's establish guidelines on reasonable behaviour so that criticism can be seen in a narrow context, and can be protected and informed. Elsewise, it is unbalanced. You can talk unprofessionally, but others are forced to remain silent. Any comments are wasted, discussion is fruitless at best, and at worst, the mob will have their way. iang ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Avoid incorrect issuing of Certificates
On 26/12/08 23:52, patri...@certstar.com wrote: How about creating certificate type that is registered in a central database and require all CAs to check this DB before issuing new certificates? Once in that database no certificates could be issued for this specific domain. I think that most high profile sites would take advantage of such service. I have toyed with an alternate idea which is to indicate an appropriate CA in the technical contact of the whois registry details. The reason I thought of that is perhaps an unhappiness at yet another registry for intellectual property on the net. But all ideas are worth thinking about. iang ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Unbelievable!
On 26/12/08 02:28, Gen Kanai wrote: On Dec 26, 2008, at 1:49 AM, Frank Hecker wrote: Beyond that? It's somewhat of an open question. Frank Mozilla needs to have a concrete policy and procedures in place so that there is no question as to what the penalties would be for future actions of this kind. Penalties ... tough talk, but what does it really mean? Basically, all that a vendor can do is to drop the root. (Ok, we can fiddle with the trust bits, but it seems a little but like fiddling to me.) In short, it is DROP or NIX. Can we say, blunt weapon ? Either the vendor is small, so it matters not, or the vendor is huge, and it matters a great deal. (In that latter case, it then matters a great deal to the CA. It could be a deal killer. E.g., bankrupcy. Which means, Mozilla has to get that *right* or it faces another issue, further downstream. Deep pockets plus aggressive liquidator equals not-nice maths.) How does Mozo make the right decision here ? Part of the problem in making it right whatever that means is that according to classical browser PKI it is not the responsibility of Mozo or any other vendor to do anything, let alone deciding what right is. Classically, this is the policy, in a nutshell: CA sets up. CA gets audited. some technical things are checked... root is added. It is that second part that is the clue: the audit. It is the audit's area to check whether the CA is following some sort of policy or practice or compliance. So, if there is a failure, the first question to ask is whether this the failure is in the Audit's responsibility, or whether it is a vendor issue? It might be one, or the other, or BOTH. Certainly, in the current case, the vendor does not have the information to make a decision, whereas the Auditor might reasonably, having been in there and kicked the tires? (Although I think, it is a singular observation: there is no effective dispute resolution for this case or any other. What does that say?) iang ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Unbelievable!
On Fri, Dec 26, 2008 at 3:12 PM, Ian G i...@iang.org wrote: (Although I think, it is a singular observation: there is no effective dispute resolution for this case or any other. What does that say?) That there is no reason to trust a system without dispute resolution procedures. -Kyle H ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Avoid incorrect issuing of Certificates
On Dec 27, 12:06 am, Ian G i...@iang.org wrote: The reason I thought of that is perhaps an unhappiness at yet another registry for intellectual property on the net. But all ideas are worth thinking about. Maybe, I don't like central registries either. I just think we need to think about if we can add an additional layer of security especially for banks, high profile sites and others who could be phising targets. -- kind regards, Patricia, Certstar ApS ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Avoid incorrect issuing of Certificates
On 12/27/2008 12:52 AM, patri...@certstar.com: Hi, Patricia, even though I value your suggestion, I believe this is not the appropriate time and place to raise them. Please note, that you are not a certification authority but a reseller. It's the certification authority which needs to have reasonable and sufficient controls in place to prevent that from happening. They bear the ultimate responsibility. Lately we have all seems that the certificate system is not 100% secure - mistakes happen. It might never become fully bullet proof but one simple change might help a lot. I would agree with you in case I'd have had to resort to special tools and hacking your servers in order to overcome domain validation procedures. However in your case there was no validation at all. This is not a mistake, it's negligence from bottom to top. I believe that you are new to digital certification and it seems to me that you haven't understood the very basics of certification. However the fact that the issuing CA hasn't checked your implementations suggests gross negligence on their part and a complete failure of any controls that might have been in place. I believe that no such controls exist at all. How about creating certificate type that is registered in a central database and require all CAs to check this DB before issuing new certificates? Why? So that you can search the database for new customers? Do you believe that this would remove the burden to perform domain control validation? And why shouldn't I be able to get certificates for my domain from multiple certification authorities? Heck, your CA even issues certificates multiple times with the same subject line. I guess they won't be very happy with your proposal. Once in that database no certificates could be issued for this specific domain. I think that most high profile sites would take advantage of such service. High profile sites should use EV certificates anyway these days. Additionally it would require participation of all CAs, something which is very unlikely from happening. Otherwise a customer simply searches for another CA not participating... -- 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: Unbelievable!
On 27/12/08 00:15, Kyle Hamilton wrote: On Fri, Dec 26, 2008 at 3:12 PM, Ian Gi...@iang.org wrote: (Although I think, it is a singular observation: there is no effective dispute resolution for this case or any other. What does that say?) That there is no reason to trust a system without dispute resolution procedures. I would be somewhat sympathetic to this but it is kind of damning to the entire system. Question is, is there a way of creating a dispute resolution system that would deal with the entire problem space? Let's say you and I are in dispute, and the damages are N bucks. We need someone to tell us who did what, and who does what, and who pays what. We could envisage a forum of dispute resolution where we both agree to enter because we are inside this space already. And agree to those liabilities. That might work between us, but it doesn't scale. E.g., it can't apply easily to a Firefox end-user who hasn't agreed to this forum. So, if a Firefox user was ripped off because of a cert, then she would be shut out. Alternatively, if she libelled a CA by claiming insecurities in a public blog, the CA would not be able to get satisfaction because she wouldn't recognise the forum. However, maybe a partial solution is better than none? Anything might be better than what we've got now... iang ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Unbelievable!
On 12/27/2008 12:54 AM, Ian G: We can no more prevent bad certs than we can stop the winter from coming. The point is to put in place economically reasonable policies and practices that meet an appropriate balance of security versus cost. Yeah right! It really depends what the right balance is, ehhh?! So far the systems are dealing with it. Check the facts: CA was notified. Reseller frozen. Certs revoked. Internal audits are checking. External audit might get involved. This is what the systems are supposed to do. The story starts before that. You are just seeing the tail, I'm seeing what preceded to that - or better, what did not happen and should have. That's not up to an internal audit as if it were a well hidden bug in one of Comodo's system that somebody succeeded to crack. But maybe Robin can explain to us which failures happened at their side as they are taking supervision of RAs and resellers very seriously. But that's most likely something which we'll never know. However, outside that week, there is no such protection. Where people in this group have crossed the line, and made actionable statements, and/or done actionable harm to a business or individual, they should note: it is unlikely that Mozilla, or the community, or the businesses as a whole will, can or should protect them. Are you speaking in the name of Mozilla? Or in the name of the community? Or in the name of which business exactly? -- 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: [Fwd: Follow-Up on www.verisign.com SSL Order]
On 12/26/2008 10:36 AM, goo...@servage.net wrote: On Dec 26, 5:27 pm, David E. Ross nob...@nowhere.not wrote: Note that the message from Certstar that Eddy posted said [emphsis added]: I am contacting you as I noticed that *you did completed* your SSL Certificate order forwww.verisign.comand wanted to follow up on it. You are right. It seems there was a typo in that email, it should of course have said you did not complete your SSL Certificate order as it is a follow up for people who do not complete the ordering process. -- kind regards, Patricia, Certstar ApS I have a problem with this response. The message that Eddy quoted appears to be a canned message (equivalent to a form letter). This was put into use without proper quality assurance (QA). The whole issue under discussion reflects a general disregard for QA, with this message merely another example. I find these failures of Certstar's QA processes alarming when you consider the purpose of certificates. That is, if you can't get a simple canned message correct and allow several certificates to be signed without verifying that the subscriber is authorized, what else is amiss in your QA department? Do you even have a QA department? If so, is it independent of marketing and other departments within your company? -- 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: Unbelievable!
On 27/12/08 00:53, Eddy Nigg wrote: On 12/27/2008 12:54 AM, Ian G: We can no more prevent bad certs than we can stop the winter from coming. The point is to put in place economically reasonable policies and practices that meet an appropriate balance of security versus cost. Yeah right! It really depends what the right balance is, ehhh?! There is no right balance just like there is no world peace. Security is an economic phenomena, not a beauty pageant. So far the systems are dealing with it. Check the facts: CA was notified. Reseller frozen. Certs revoked. Internal audits are checking. External audit might get involved. This is what the systems are supposed to do. The story starts before that. You are just seeing the tail, I'm seeing what preceded to that - or better, what did not happen and should have. That earlier story has no real place here, IMHO. This is a forum for the discussion of technical, crypto, root and general PKI issues, by either dictat or convention. It is not a forum for the airing of general business complaints. https://lists.mozilla.org/listinfo/dev-tech-crypto I elsewhere mentioned there is no general mechanism for dispute resolution, your earlier story might be a case in point. Or might not. Either way, here is not the place to grumble about practices of other businesses. However, outside that week, there is no such protection. Where people in this group have crossed the line, and made actionable statements, and/or done actionable harm to a business or individual, they should note: it is unlikely that Mozilla, or the community, or the businesses as a whole will, can or should protect them. Are you speaking in the name of Mozilla? Or in the name of the community? Or in the name of which business exactly? Having appreciated this point, a more interesting one is whether we as a community think about opening up the processes for more open governance, more open scrutiny, more stakeholder checking [1]. There seems to be an emerging consensus that more open is more better, in general at least. Would we be in a position to explore a general opening of all auditing investigations and controls [2] ? E.g., where Comodo or any CA completes an internal audit and creates a report to document that audit action, could we expect the CA or the internal auditor to publish this as a routine action? iang [1] My thanks to Robin for underscoring that observation! I had to kick myself for failing to see it. [2] Plausibly, such a proposal will not be accepted in time for the current case to be effected, but that's fine as this is a forum of improving processes, not dispute resolution. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Avoid incorrect issuing of Certificates
On 12/26/2008 2:52 PM, patri...@certstar.com wrote: Hi, Lately we have all seems that the certificate system is not 100% secure - mistakes happen. It might never become fully bullet proof but one simple change might help a lot. How about creating certificate type that is registered in a central database and require all CAs to check this DB before issuing new certificates? Once in that database no certificates could be issued for this specific domain. I think that most high profile sites would take advantage of such service. My suggestion probably needs a little fine tuning but it would be a step in the right direction. The issue at hand is not the first time issues about external RAs and certificate sellers have been raised. These are the issues that need to be addressed now. A CA should either assert in its CP that there are no RAs and resellers, or else describe the CA's relationship with them. By policy, the Mozilla organization should require a CA's CP to address the following four points (lumping external certificate sellers with RAs): 1. The CP should detail how external registration authorities (RAs) are approved. 2. The CP should detail how RAs verify subscriber identities. 3. The CP should detail how RAs verifies authorization of individuals to represent organizational subscribers. 4. The CP should detail how the CA verifies that RAs operate in accord with the CA's policies. The first would tell us how RAs and resellers are chosen. The second and third would tell us what processes are imposed on RAs and resellers. The fourth would tell us how the operations of RAs and resellers are monitored. Placing these four in a CP puts them in view of outside auditors and subjects them -- especially #1 and #4 -- to being audited. All four of these trace to WebTrust criteria. Note, however, none of these require disclosing who are the RAs and resellers. Instead, I'm willing to rely on ISO 9000 principles: Say what you do, do what you say, and prove it. If Mozilla policies required these four points in a CP, then approval of a CA's request for inclusion in the certificate database could depend -- with respect to RAs and resellers -- upon (a) Mozilla's and the public's review of the adequacy of the CP statements and (b) the independent auditor's review of compliance with those statements. -- 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/27/2008 02:33 AM, patri...@certstar.com: This is just sales. Patricia, I know that this is all just sales, this is what we all do here. But don't you think that Comodo should have helped you a little bit with the setup of your site? -- 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: Avoid incorrect issuing of Certificates
On 12/27/2008 02:42 AM, David E. Ross: The issue at hand is not the first time issues about external RAs and certificate sellers have been raised. These are the issues that need to be addressed now. A CA should either assert in its CP that there are no RAs and resellers, or else describe the CA's relationship with them. By policy, the Mozilla organization should require a CA's CP to address the following four points (lumping external certificate sellers with RAs): 1. The CP should detail how external registration authorities (RAs) are approved. 2. The CP should detail how RAs verify subscriber identities. 3. The CP should detail how RAs verifies authorization of individuals to represent organizational subscribers. 4. The CP should detail how the CA verifies that RAs operate in accord with the CA's policies. The first would tell us how RAs and resellers are chosen. The second and third would tell us what processes are imposed on RAs and resellers. The fourth would tell us how the operations of RAs and resellers are monitored. Placing these four in a CP puts them in view of outside auditors and subjects them -- especially #1 and #4 -- to being audited. All four of these trace to WebTrust criteria. Note, however, none of these require disclosing who are the RAs and resellers. Instead, I'm willing to rely on ISO 9000 principles: Say what you do, do what you say, and prove it. If Mozilla policies required these four points in a CP, then approval of a CA's request for inclusion in the certificate database could depend -- with respect to RAs and resellers -- upon (a) Mozilla's and the public's review of the adequacy of the CP statements and (b) the independent auditor's review of compliance with those statements. Seconded. BTW, this is part of the WebTrust criteria. We need to make it explicit similar to the intermediate CAs. -- 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: Unbelievable!
On Dec 26, 4:40 pm, Ian G i...@iang.org wrote: With respect: This is a forum for the discussion of technical, crypto, root and general PKI issues, by either dictat or convention. It is not a forum for the airing of general business complaints. Are you characterizing this issue as merely a general business complaint? I happen to agree that this should not be the forum for such discussion, but as you point out, there is no other apparent forum for dispute resolution. Where should such discussions be taken? Having appreciated this point, a more interesting one is whether we as a community think about opening up the processes for more open governance, more open scrutiny, more stakeholder checking [1]. My first reaction would be: most definitely, +1. That said, you have classified this discussion as a public lynching of a CA, called into question the professionalism of those engaging in such discussion, and identified potential legal liabilities in doing so. My question to you would be: assuming the issues you raised are legitimate (I happen to disagree) how could such an open governance model cope with the restrictions that would most certainly be necessary to address the issues you raised? Would we be in a position to explore a general opening of all auditing investigations and controls [2] ? +1 ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Unbelievable!
On 12/27/2008 02:40 AM, Ian G: On 27/12/08 00:53, Eddy Nigg wrote: Yeah right! It really depends what the right balance is, ehhh?! There is no right balance just like there is no world peace. Security is an economic phenomena, not a beauty pageant. No, security is an inconvenience, but I've said that earlier already. The story starts before that. You are just seeing the tail, I'm seeing what preceded to that - or better, what did not happen and should have. That earlier story has no real place here, IMHO. This is a forum for the discussion of technical, crypto, root and general PKI issues, by either dictat or convention. It is not a forum for the airing of general business complaints. You don't seem to get it, do you? The story starts before your stating of the facts you would like us to believe. The story starts with putting resellers and so-called RAs in charge of validation procedures they have no clue about and with failing to audit, approving and controlling them, it's called due diligence. The story continues with failing to prevent issuance of high-profile target certificates such as Mozilla certainly is and the story continues with failing to detect them once issued. As I said, you are only seeing the tail... There seems to be an emerging consensus that more open is more better, in general at least. This might be correct. However generally speaking CP and CP statements, other documents publicly available in addition to general questioning (at least during our review procedures at Mozilla) are fairly sufficient. In relation to Comodo, the writing has been on the wall. E.g., where Comodo or any CA completes an internal audit and creates a report to document that audit action, could we expect the CA or the internal auditor to publish this as a routine action? I don't think we can expect that as a general role. -- 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: Unbelievable!
ro...@comodo.com wrote, On 2008-12-26 03:28: We have finished our initial investigation on the certificates issued by Certstar. Of the 111 orders that had been placed through Certstar there remain 13 orders for which we have still not been able to gather adequate evidence of the applicant having domain control. We have therefore, regrettably, revoked the certificates on those orders. Of those 13 orders, 2 were placed by Eddy, for startcom.org and www.mozilla.com, as he has already described. As we previously stated, the certificate for www.mozilla.com was revoked shortly after it was issued. Of the remaining 11 orders we do not have any reason to believe that any were placed fraudulently and had we not set such a short timescale to effect the (re-)validation and had it not been over this Holiday season we believe that we would have been able to achieve validation of domain control for all 11. Certstar have passed to us all of their records for these customers and we will ensure that they are contacted for 2 purposes: a) to check if it would have been possible to complete the re-validation b) to offer a replacement certificate. Some of the orders have either been charged-back or refunded. We have to accept the possibility that some of those customers will not assist us in re-validation. Regards Robin Alden Comodo Robin, Thanks for that report. Speaking for myself only, I think that the speed with which you and Comodo dealt with this issue, once it became publicly known, and the integrity you Comodo showed by revoking 11 certs (~10%) whose veracity simply could not be determined in a timely fashion, is commendable. Issues remain, and will continue to be discussed about how this situation came to be, and what new measures should be taken, and by whom, to minimize the probability of it ever happening again. But one clear conclusion from this episode is that there is not a single clear line of separation of responsibilities between CAs and RAs that applies to all CAs. Clearly several participants in this discussion were surprised that a CA would delegate the duty of validating domain control to an RA, and some opined that a CA ought to perform that duty itself. I'm not convinced that's necessary, but it certainly does seem that a CA firm ought to be prepared to deal with the possibility that an RA makes a (potentially big) mistake without sacrificing the CA firm's entire business. The challenge, in the event of an RA error, is to restore/maintain confidence in the integrity of the CA's PKI overall, while mitigating the potential damage from dubious enrollments. In this case, it was feasible to examine the data for ~90% of the RA's 111 enrollments in a reasonably short time. If the RA had enrolled 10 or 100 times as many, a much larger number (and probably a larger percentage) of the enrollments might not have been verifiable in such a short time. I wonder if it would have been perceived as feasible to revoke all the unverified certs in such a case, and still remain in business. I personally received numerous requests (mostly privately) asking for ways for browser users to effectively disable the trust for the certs issued under the auspices of this particular RA, at least until the veracity of those certs could be sorted out. As you and I discussed in bug 470897, the only options available to users, which would effectively distrust the entire PositiveSSL CA cert (or the entire root with all its subordinate CAs), would have also effectively distrusted the certs issued under the auspices of numerous other RAs. Hence that solution would not have been a good fit for the scope of the problem. Nevertheless, a number of people expressed to me the view that disabling trust in the subordinate CA that issued certs for that RA, while too broad of a measure, was nonetheless preferable to leaving themselves vulnerable to the possibility of false certificates. I sensed that they wanted the ability to take action that fit the scope of the potential problem well, and also was potentially reversible if and when things were finally sorted out (as it now seems they are). Had there been a separate CA issuing certs for this RA, the ability to disable trust for that CA cert and the ability to restore that trust at a later time (such as now) would have been much more satisfying to many, I believe. So, I would like to suggest that Comodo consider modifying its practices somewhat, to reduce the mismatch of scope between subordinate CAs and RAs. I suggest that Comodo operate a separate subordinate CA for each RA to whom Comodo has delegated validation duties. I suggest that a new subordinate CA be created for each such RA, and that all new certs issued for those RAs be issued from those new single-RA CAs. I am aware of at least one other commercial CA that operates that way, operating a separate subordinate CA for each RA to whom they have delegated validation duties. I
Re: Unbelievable!
I am minded of the CRL entry reason remove from CRL. Does NSS properly handle that reason-code? If so, a temporary revocation of all unknown certificates might be a sound practice, removing them from the CRL as they're found and verified. We are running up against problems that are caused by absolute adherence to inflexible standards, and we're proposing mechanisms inside of the inflexible standards to deal with them. If there were a way to, say, have the CA include a unique, opaque code for the RA that submitted a CSR in the issued certificate, AND if there were a way to filter based on the content of an extension (rather than simply leaving it completely opaque, which leads to the current problem), then there would be no need for a separate CA for each RA. -Kyle H On Fri, Dec 26, 2008 at 5:38 PM, Nelson B Bolyard nel...@bolyard.me wrote: ro...@comodo.com wrote, On 2008-12-26 03:28: We have finished our initial investigation on the certificates issued by Certstar. Of the 111 orders that had been placed through Certstar there remain 13 orders for which we have still not been able to gather adequate evidence of the applicant having domain control. We have therefore, regrettably, revoked the certificates on those orders. Of those 13 orders, 2 were placed by Eddy, for startcom.org and www.mozilla.com, as he has already described. As we previously stated, the certificate for www.mozilla.com was revoked shortly after it was issued. Of the remaining 11 orders we do not have any reason to believe that any were placed fraudulently and had we not set such a short timescale to effect the (re-)validation and had it not been over this Holiday season we believe that we would have been able to achieve validation of domain control for all 11. Certstar have passed to us all of their records for these customers and we will ensure that they are contacted for 2 purposes: a) to check if it would have been possible to complete the re-validation b) to offer a replacement certificate. Some of the orders have either been charged-back or refunded. We have to accept the possibility that some of those customers will not assist us in re-validation. Regards Robin Alden Comodo Robin, Thanks for that report. Speaking for myself only, I think that the speed with which you and Comodo dealt with this issue, once it became publicly known, and the integrity you Comodo showed by revoking 11 certs (~10%) whose veracity simply could not be determined in a timely fashion, is commendable. Issues remain, and will continue to be discussed about how this situation came to be, and what new measures should be taken, and by whom, to minimize the probability of it ever happening again. But one clear conclusion from this episode is that there is not a single clear line of separation of responsibilities between CAs and RAs that applies to all CAs. Clearly several participants in this discussion were surprised that a CA would delegate the duty of validating domain control to an RA, and some opined that a CA ought to perform that duty itself. I'm not convinced that's necessary, but it certainly does seem that a CA firm ought to be prepared to deal with the possibility that an RA makes a (potentially big) mistake without sacrificing the CA firm's entire business. The challenge, in the event of an RA error, is to restore/maintain confidence in the integrity of the CA's PKI overall, while mitigating the potential damage from dubious enrollments. In this case, it was feasible to examine the data for ~90% of the RA's 111 enrollments in a reasonably short time. If the RA had enrolled 10 or 100 times as many, a much larger number (and probably a larger percentage) of the enrollments might not have been verifiable in such a short time. I wonder if it would have been perceived as feasible to revoke all the unverified certs in such a case, and still remain in business. I personally received numerous requests (mostly privately) asking for ways for browser users to effectively disable the trust for the certs issued under the auspices of this particular RA, at least until the veracity of those certs could be sorted out. As you and I discussed in bug 470897, the only options available to users, which would effectively distrust the entire PositiveSSL CA cert (or the entire root with all its subordinate CAs), would have also effectively distrusted the certs issued under the auspices of numerous other RAs. Hence that solution would not have been a good fit for the scope of the problem. Nevertheless, a number of people expressed to me the view that disabling trust in the subordinate CA that issued certs for that RA, while too broad of a measure, was nonetheless preferable to leaving themselves vulnerable to the possibility of false certificates. I sensed that they wanted the ability to take action that fit the scope of the potential problem well, and also was potentially
Re: Avoid incorrect issuing of Certificates
patri...@certstar.com wrote, On 2008-12-26 14:52: Lately we have all seems that the certificate system is not 100% secure - mistakes happen. It might never become fully bullet proof but one simple change might help a lot. How about creating certificate type that is registered in a central database and require all CAs to check this DB before issuing new certificates? Once in that database no certificates could be issued for this specific domain. I think that most high profile sites would take advantage of such service. I think you're suggesting a cooperative agreement among CAs, whereby once a cert was issued for a domain name by one CA, other cooperating CAs would refuse to issue a cert for that same domain name. Is that what you're suggesting? Assuming that it is, here are some questions and observations. 1) What problem would this proposed central database solve? Would it exist merely to keep CAs from inadvertently soliciting the customers of their competitors? What other purpose, if any, would it achieve? 2) Would this lock a cert customer into a single vendor? Would it prevent a party from enrolling for certs from several different CAs? As an acquirer of certificates, I would not want to be locked in to a single CA. 3) If some CAs agree to such an approach, and others do not, is it still valuable? 4) I think this database effectively exists already, albeit in a distributed (not centralized) fashion. If you want to know if the server at a certain DNS name already has a cert, and who issued it, and when it is due to expire, you can simply visit that server with an SSL client on any (or all) of the usual SSL ports (443, 465, 993), get the server's current cert, and get all that information from it. I suspect you know this already. :) 5) There is an organization of cooperating CAs and browser makers, known as the CA-Browser Forum (CABForum.org), the people behind EV. They're probably the group to which proposals for CA cooperation should be directed. They only admit CAs, and as Certstar is an RA, I'm not sure you could become a member. But Comodo could represent you, or perhaps invite you to participate in the mailing list. And you can always send email to the email address on their web site. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Facts about Comodo Resellers and RAs
Comodo's CPS [1] lists the following: 1.10.2 Web Host Reseller Partners Through a “front-end” referred to as the “Management Area”, the Web Host *Reseller* Partner has access to the *RA* functionality including but not limited to the issuance of Secure Server Certificates is obliged to *conduct validation* in accordance with the validation guidelines and agrees via an online process (checking the “I have sufficiently validated this application” checkbox when applying for a Certificate) that sufficient validation has taken place prior to issuing a certificate. This seems to be exactly in line with my comment [2] and the published image [3]. If this is correct, than it is in direct conflict with section 4.2.7 PositiveSSL and PositiveSSL Wildcard Secure Server Certificates of this statement [4]: To validate PositiveSSL and PositiveSSL Wildcard Secure Server Certificates, *Comodo* checks that the Subscriber has control. and the use of generic e-mails which ordinarily are only available to person(s) controlling the domain name administration, for example, webmaster@ . . ., postmaster@ . . ., admin@; This basically means that Comodo outsources domain validation not only to RAs but also to resellers. In addition, domain validation is effectively circumvented and non-existent for such resellers. The mere checking of the checkbox is the only requirement for the issuance of any certificate. This is in my opinion insufficient and and undue risk! Considering the size of Comodo's reseller and RA network (which I'm sure makes up the biggest junk of their certificates issuance), it is reasonable to assume that unvalidated certificates exist currently. Additionally I want to point out that the CPS [4] explicitly states that Comodo performs the validation, which however is not the case as we've seen with certstar. Since I was reading this document during the review period of Comodo this spring, I was fairly convinced that Comodo performs those validations. I request to receive further information about how exactly domain control is validated and which controls Comodo has in place to prevent fraudulent or mistaken issuance. Incidentally I've found discrepancy in statements made by Robin as to the status of certstar in particular and concerning domain validation in general. [1] http://www.comodo.com/repository/09_22_2006_Certification_Practice_Statement_v.3.0.pdf [2] https://bugzilla.mozilla.org/show_bug.cgi?id=470897#c27 [3] https://bugzilla.mozilla.org/attachment.cgi?id=354425 [4] http://www.comodo.com/repository/PositiveSSL_addendum_to_the_Certification_Practice_Statement.pdf -- 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: Unbelievable!
On Dec 26, 5:38 pm, Nelson B Bolyard nel...@bolyard.me wrote: Clearly several participants in this discussion were surprised that a CA would delegate the duty of validating domain control to an RA, and some opined that a CA ought to perform that duty itself. I certainly fall in that category. I'm not convinced that's necessary, but it certainly does seem that a CA firm ought to be prepared to deal with the possibility that an RA makes a (potentially big) mistake without sacrificing the CA firm's entire business. The challenge, in the event of an RA error, is to restore/maintain confidence in the integrity of the CA's PKI overall, while mitigating the potential damage from dubious enrollments. I think I can boil down my concern in this statement: When trust is being established in a certification authority, trust is explicitly being placed in its operational practices. It is not being trusted in its ability to place trust in turn in whomever it may decide to outsource its operations. By allowing arbitrary parties to perform critical RA activities (such as DV) the CA is attempting to extend its operations beyond that which was originally judged. So, I would like to suggest that Comodo consider modifying its practices somewhat, to reduce the mismatch of scope between subordinate CAs and RAs. I suggest that Comodo operate a separate subordinate CA for each RA to whom Comodo has delegated validation duties. I suggest that a new subordinate CA be created for each such RA, and that all new certs issued for those RAs be issued from those new single-RA CAs. I am aware of at least one other commercial CA that operates that way, operating a separate subordinate CA for each RA to whom they have delegated validation duties. I believe that is a sound way to minimize the collateral damage that might need to be inflicted, even temporarily, to restore/maintain PKI integrity in the event of a breach. I believe your suggestion is valid. This seems to fit s. 13 of the Mozilla CA Certificate policy: ... we recommend that CAs consider using separate root CA certificates with separate public keys (or separate intermediate CA certificates with separate public keys under a single root) when issuing certificates according to different Certificate Policies, so that we or others may selectively enable or disable acceptance of certificates issued according to a particular policy, or may otherwise treat such certificates differently ... I believe another valid option would be for the CA to incorporate key RA duties, namely domain verification. The CA can still have resellers that initiate registration and collect information. Verification would remain within the operations of that which is judged in the CA's conformance to policy. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Avoid incorrect issuing of Certificates
On 12/27/2008 04:10 AM, Kyle Hamilton: I note that the WebTrust audit seal that Robin provided links to only mentions auditing in relation to EV certificate issuance, and does not address anything at all outside of that scope. This report does not include any representation as to the quality of Comodo's services beyond those covered by the WebTrust for Certification Authorities EV Criteria, nor the suitability of any of Comodo's services for any customer's intended purpose. i.e., there is no audit for non-EV certificate issuance, and thus non-EV certificate issuance has no reason at all to be trusted. This is problematic. Right, there must be another report for regular WebTrust somewhere. -- 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: Avoid incorrect issuing of Certificates
Kyle Hamilton wrote, On 2008-12-26 18:10 PST: I note that the WebTrust audit seal that Robin provided links to only mentions auditing in relation to EV certificate issuance, and does not address anything at all outside of that scope. Here are some Comodo seal numbers that I found: 212 537 636 798 804 ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
