Hi Robin, Sorry that I'm relying to you only now.
Robin Alden: >> The behavior of Comodo in this respect is really surprising! Supposed >> you would issue certificates with longer validity only to entities which >> were thorough verified and validated, I could offer some understanding. >> But by issuing *domain validated* certificate for up to *ten years*, >> without revalidation is completely irresponsible and borders on gross >> negligent. >> >> > [Robin said...] > I disagree. With a DV certificate the only thing that we are warranting is > that the key holder controls the domain. Between us, even this isn't true exactly , or at least I'm not sure if your CA warrants anything in the domain validated settings... But this isn't the point at all, but the fact, that your certificates are issued for a very long time without re-validating and confirming continued ownership of the domain name. This is the problem here. > >> >> The risk exists and I gave a real show-case to a reply to Frank >> yesterday (most likely you've read it too). If this is made possible, >> than why validate a domain at all? As you agreed with me, there is a >> risk of fraud, it just requires somewhat more patience and money for a >> sophisticated attacker, but detection is accordingly also much more >> difficult. And it defeats the very purpose of domain validated >> certificates. >> > [Robin said...] > Fraud how? For DV, we validate domain control. Let me explain as I continue to answer below... > If a company goes bust and > passes the domain on to someone else then that new person could get a DV > certificate for the domain. You seem to ignore the fact, that the original owner of the domain name still holds a certificate with a validity of potentially close to ten years. The previous owner can at will perform a MITM attack with a completely legitimate certificate. > Or are you suggesting that the risk you are addressing is of someone > choosing a defunct domain with a Comodo DV certificate (that we did not > become aware of and revoke) Yes, and the new owner of this web site and the visitors of this web site can fall victim to an MITM attack. > and getting hold of the private key of the > certificate from a server (from ebay or by theft or whatever) and then using > that certificate to mount a man-in-the-middle attack on the new owners of > the domain? > No, it has nothing to do with a key compromise. > Why go to that effort? DV certificates are easy to get. That is a valid > criticism against DV. > I'm absolutely not against domain validated certificates and they have a rightful place in the landscape of this infrastructure. However I'm completely against issuance of domain validated certificates to any longer period which isn't reasonable and beyond the expected ownership period of said domain name. > DV products exist today - that is a fact. The browsers (in this case > Mozilla) have been content for us to issue DV certificates. Sure, a longer > duration certificate carries higher risk than a short one. Thank you for confirming this. > We'd also accept > that a wildcard carries somewhat more risk than a single domain certificate, > but where is the line to be drawn? > I'll be glad to evaluate this line together with you and other members of this community. I have drawn my line and provided a concrete proposal. We may discuss this and find the best solution for all. > Also, why draw the line retrospectively and at this moment in time? Because your CA is a candidate for inclusion and upgrade into the NSS store and as a matter of fact re-evaluated as if your CA never had any roots in NSS (See this comment in the bug entry: https://bugzilla.mozilla.org/show_bug.cgi?id=401587#c20 If we don't speak up now, we can't blame anybody else later. > Should Mozilla's policy on this not be published and clear for us to follow, > rather > than ad-hoc? > The Mozilla CA policy is clear in that respect in various points, starting with the first paragraph: 1. We will determine which CA certificates are included in software products distributed through mozilla.org, *based on the benefits and risks of such inclusion to typical users of those products.* 2. We will make such decisions through *a public process*, based on objective and verifiable criteria as described below. 3. 4. 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. This includes (*but is not limited to*) cases where we believe that including a CA certificate (or setting its "trust bits" in a particular way) *would cause undue risks to users' security*, for example, with CAs that Further at section 6: * prior to issuing certificates, verify certificate signing requests in a manner that we deem acceptable for the stated purpose(s) of the certificates; * otherwise operate in accordance with published criteria that we deem acceptable The other sections go into some more details. Additionally there is the objective of this policy as explained in the initial sections to prevent undue risk to the users security. I agree with you that we can and should refine the Mozilla CA policy to some extend, something which has been done already once (to allow EV upgrades) and to all of my knowledge we at Mozilla will work on that as soon as possible and if necessary (Frank, is that correct?) > > > [Robin said...] > It is in our interest to know about as many SSL protected domains out there > on the internet as possible. We do actively look for them. > The snag is that with wildcard domains there really are an awful lot of > possibilities to search for. We are looking for needles in haystacks. If > we could get a zone transfer for the DNS server hosting domain.com (to pick > up all the existing sub-domains) then our life would be made simple and we > would certainly check them all, but that just doesn't work. > Robin, I'm glad that it's *you* who made this statement and I couldn't have it formulated better - I absolutely agree with you. And *exactly because of that*, wild card certificates should (must) be at least identity validated. Because CAs can't control wild card certificates in the same way as regular certificates and because of the "card blanche" this certificates offer to the subscriber, a CA must implement additional measures beyond merely validating the domain name (for example by validating the identity of the subscriber). > >> Which I never, ever suggest at all. However I would expect that Comodo >> does perform additional steps, to ensure that misuse of wild card >> certificates is prevented, or at least the risk lowered. This can be >> done by validating the identity of the subscriber for example. You may >> find other effective ways for doing the same. I'd be glad to learn about >> any implementation of your CA in regards lowering the risk for wild card >> certificates. >> > [Robin said...] > I agree that wildcard certificates are somewhat higher risk than single > domain certificates. > Thanks! > We are always looking for ways to improve our products, but we are also > influenced by commercial considerations in this matter. > Sure, I understand that, but it can't be the only consideration. For Mozilla and its users, the relying party matters most. It should be in your interest too. > We could perform EV validation for every DV certificate we sold. No, I believe this to be an overkill. Proper domain validation for regular certificates are sufficient, for wild card certificates regular identity validation as you perform already at your CA should be sufficient too in my opinion. > I know you want us to ignore what everyone else does, but commercially it > would not make sense for us to pull out of that particular market segment > and leave it to a competitor. > No, I never suggested that nor would I do that... > Don't block us as an individual CA. This is not the intention of Mozilla or me! I suggest that we work together on solving the issues which came up with your request > Publish (as Mozilla) a list of policies we must follow. Yes. > Also, apply those policies across the board. > Absolutely! More than that, I suggest to you (and any other interest party) to join that effort. If you know about CAs which present the same risk as your CA does currently (in my point of view), than provide that information. It will help us at Mozilla to better evaluate the situation and help us to improve the software in relation to SSL certificates. > If you were to block one CA but allow other CAs in to the root program which > operate the same policy the blocked CA must take some action to defend its > market position. What would you have that be? > No way! Only in case said CA simply doesn't conform to the Mozilla CA policy and isn't willing to make the required adjustments, said CA can not be included. I agree with you that this must be evenly applied. > > >> About which I agree with you. Non-EV and wild card certificates are an >> important part of existing PKIs, however you also bear a responsibility! >> Considering that you claim to be #2 in this industry, you aren't doing a >> great service to our industry nor can I see how your CA is actively >> trying to improve the standing and security of PKI in general, and for >> Mozilla and its users in particular. >> > [Robin said...] > We are a commercial CA. We are driven by two forces. > On one side there are the requirements of the Browser (& OS) platforms. > E.g. They say we must be webtrust for CAs compliant (or equivalent) so we > are. If there are other published requirements we will follow them - or > expect not to have our roots embedded if we do not follow them. > Excellent! > On the other hand there is the commercial pressure on us to compete in the > market place. We cannot drop ranges of products that are offered by our > competitors. We agree that the SSL products out there need to be improved, > but that improvement must come across the board I agree with you! > Likewise the old standards (such as DV) must, in an ideal world, be phased > out No, as I said previously, DV certs have their rightful place and are excellent for the intended purpose. But we must also do that with responsibility and take into consideration its limitations. Issuing such certificates for up to ten years without re-validating and/or wild card certificates without any additional verifications are irresponsible actions in my opinion. Specially the former. > I appreciate that Mozilla is at > liberty to make any decisions on it's CA acceptance policy that it sees fit, > but again the policies should be clear and stated in advance. Persuasion > and cajoling to change standards or withdraw products should not need to > happen at the level of an individual CA's application to have a root > certificate embedded (or its trust status changed). > There are things which the current CA policy doesn't cover explicitly, but in more general formulation. Supposed tomorrow a CA introduces a scheme about which the editors of the Mozilla CA policy haven't thought about, but pose a potential risk to Mozilla and its users, I would take care to make the community aware of the problem and have this evaluated accordingly. This makes perfect sense in my opinion. > [Robin said...] > It covers anything and everything that they feel (OR we feel) is relevant to > WebTrust. > Do we operate a green disposal policy for recyclable materials? - Yes. > Is that examined by the auditors? - No, because WebTrust does not address > it. > > OK! > > [Robin said...] > You are missing a lot of information that is available to the auditors. > Much of the information about the structure of our business is kept out of > the public domain. You won't find our organization chart on our website. > You won't find network diagrams there either. > We are a commercial organization and we are not a public company. We share > the information with our auditors, they issue us with a statement of > compliance to the standards we are required to achieve. Exactly the same > type of thing happens with a financial audit. The Auditor does not document > everything he knows about the company, he examines all the available (to > him) information and makes statements about that information. Those > statements are made available to 3rd parties, but the underlying information > remains confidential. > Which is as expected and perfectly acceptable. My question however was, if your auditor could confirm all the locations to which the audits apply? Since you operate at various locations, I'd like to know if the audit covers all your operations at all locations or not. > > >> This is an issue for Frank. It has been previously raised here at the >> mailing list (not be me btw) and there might be a problem with it. >> >> Personally I think that if the company to which the root was issued, >> stopped its operation and/or ceased to exist, or if the details within a >> certificates (including root certificates) are not correct anymore, they >> should be revoked. Instead an updated certificate should be issued with >> the correct information included. Alternatively the same keys could be >> reused. We require this conditional for end users, but certainly should >> be true as well for CA roots. This is proper handling of PKI certificate >> life cycle, something which auditors confirm. As a matter of fact, I >> believe that we have CA roots in NSS which have untrue and wrong >> information in the subject line. >> > [Robin said...] > We could conceivably issue new certificates for those root CAs to which you > object, but the thing we can't do is change the common name or the CA key > because a CA is defined as being a pairing of common name and key pair. If > we change the name then it is a different CA. If we change the key then it > is a different CA. Changing either would be equivalent to us throwing the > CA away. > We can issue new CAs and have them signed by the old CAs - but in fact this > is what we do with most of our products now. We issue many certificates via > intermediate CA certificates (whose subjects do not refer to legacy > entities). > Our main use for the UserTrust and AddTrust roots is to cross-sign other CAs > which we rely on where possible, falling back on the cross-signing to > inherit trust only where needed - usually on older platforms. > You will certainly shake things up if you remove all root CA certificates > whose subjects are no longer accurate. Our customers whose certificates > stop working will be decidedly miffed, I feel sure. Or did you have some > less drastic measure in mind, perhaps? > I think this is something about which we need to gather more information in every respect. I'm certain that if this is confirmed to be a problem, we'll have the possibility to find a common understanding and approach this accordingly. I'm not sure why you think that you can't change the common name. Apparently the key pairs could be reused, but the certificates content changed - the very purpose of such an exercise. But there could be more ideas on solving it and I think we can invest the needed time to approach this correctly, should such a decision be taken. > > >> What is this timescale? Current + ten years? (I guess not, but what does >> it really mean?) >> > [Robin said...] > No, not 10 years. I can't disclose the figure without checking with our > board, but it is a conservative figure which offers some benefit to us in > the level of reduction of validation effort while limiting the risk to the > validation process. It is a figure which is discussed each year with our > auditors and they have never raised it as a matter of concern. > I think this answer satisfies my question. -- Regards Signer: Eddy Nigg, StartCom Ltd. <http://www.startcom.org> Jabber: [EMAIL PROTECTED] <xmpp:[EMAIL PROTECTED]> Blog: Join the Revolution! <http://blog.startcom.org> Phone: +1.213.341.0390 _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
