> Robin Alden: > > > > The only certificates we issue for 10 years are DV certificates. > > We do not currently repeat any of the validation checks during a > > certificate's lifetime for any of our certificate types. > > > > 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. There are no organizational details in certificate - only the domain name in the common name.
> In comparison, there are intermediate CA certificates in use by CAs > which are in NSS which have a shorter lifetime even than that in order > to lower the risks! One can assume that this type of CA certificates are > adequately secured and don't rely on domain names which might stop to > exist and change owners (willingly and unwillingly). > > > We have certainly thought about the case where an organization ceases to > > operate, or a domain name changes hands, and when we follow the cases > > through where the subscriber does not inform us they do not strike us as > > being of high risk. There is some risk of fraud, certainly, but it is > not > > high up the list of ways we see people using SSL certificates to commit > > fraud. > This issue has come up with other CAs as well, but apparently any of > them offering certificates for longer validity, require the subscriber > to re-validate their domain. As far as I know, you are the only CA doing > that (which is included in NSS) and in that respect an argument (which > you used elsewhere), that the competition is doing it as well, is not > relevant. > > 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. 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. In fact it will be a lot easier for them to get a new DV certificate for the domain from us than to try and get the private key of the old one from a defunct server. To use the certificate you must be in possession of the private key and (because of the validation) be in control of the domain. 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) 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? Why go to that effort? DV certificates are easy to get. That is a valid criticism against DV. 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. We'd also accept that a wildcard carries somewhat more risk than a single domain certificate, but where is the line to be drawn? Also, why draw the line retrospectively and at this moment in time? Should Mozilla's policy on this not be published and clear for us to follow, rather than ad-hoc? > > > We restrict the wildcard character in the domain name to be the > > leading sub-domain. e.g. *.foo.com, *.foo.co.uk. > > > Good. > > > > E.g. If we find a certificate is being used at ebay.foo.com we would > > not **automatically** take action on that certificate unless we > > become aware (either through our own inspection or by notification > > from a third party) that fraud is likely. > > > May I suggest to implement an automatic check for certificates which > could be potentially used for phishing and other fraud, including > certificates which are obviously for financial institution? Revocation > of a certificate after detection through your inspection is not as good > as possible prevention of the issuance in first place. Considering the > size of your CA and the difficulty of controlling automated issuance, I > would expect it from you and I'm rather surprised not to find any > provision in that respect. [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. > > > > We agree that wildcard certificates pose more problems than > > non-wildcard certificates but Wildcard certificate products exist > > today and we are not minded to unilaterally withdraw them. > > > 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. We are always looking for ways to improve our products, but we are also influenced by commercial considerations in this matter. We could perform EV validation for every DV certificate we sold. It would increase the quality of the issued certificate base. Sadly it would have the side effect that we would go out of business because we would be accepting high costs for validating each certificate which we then sell as a low price product (because it offers a low level of assurance). 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. Don't block us as an individual CA. Publish (as Mozilla) a list of policies we must follow. That allows us to make a decision as to whether we want to be in the root program or not. Also, apply those policies across the board. 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? > > > > We helped to found the CAB forum and continue to support it to improve > > the overall security of SSL certificates. > > > I'm afraid, but in my opinion your CA does exactly the opposite. I'm > glad that you support the CAB forum, however your CPSs aren't convincing > at all what your non-EV business concerns. > > > > We hope that one day all certificates will be EV, but until that day > > we feel we must be allowed to compete with order CAs issuing wildcard > > products. > > > 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. 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 - and the way to do that is to introduce new standards (such as EV) and promote their adoption. Likewise the old standards (such as DV) must, in an ideal world, be phased out - but in a planned approach which has been agreed by an appropriate forum. The CAB Forum may be that forum - but a Browser (& OS) only forum would be capable of a similar approach - although we'd like to think they would accept some input from CAs too. 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). > > > The WebTrust Audit covers most aspects of our operation as a CA. > Most or all? [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. > > The > > auditors visit any part of our operation which they deem to be involved > in > > our CA operation. > > The Manchester office is our UK based validation operation. It handles > both > > EV and OV validation. > > The New Jersey office is our US based validation operation. It too > handles > > both EV and OV validation. > > We have one more validation operation which handles OV validation only > and > > which is also audited each year as part of the webtrust audit. > > > > Is it possible to receive a statement from your auditor in that respect? > Because this isn't what your audit reports and confirmations are saying. > Perhaps we are also missing some audit reports at all... [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. > > > The AddTrust root was purchased by Comodo from the ScandTrust > organization > > in Malmö, Sweden. They had acquired the root (and continued the > protection > > of the key material, etc.) when they took over the AddTrust operation. > > The four UserTrust roots became available to Comodo when UserTrust > became a > > Comodo Group Company. > > In both of the above cases the key material was removed from its > original > > sites of operation (in Sweden and Salt Lake City, respectively) and > > trafserred into Comodo's data centres and backup centres. > > The roots you see with Comodo's name in, or mentioning a Salford address, > > are roots for which we have generated the keys ourselves. > > > 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? > > > Concerning code signing: > > We have various other checks in this area which we apply in addition to > those explicitly mentioned in the CPS. I appreciate that doesn't help you > much because we wouldn't disclose them publicly, but they are disclosed to > our WebTrust auditors during our audits and we would probably be prepared > to discuss them further with Mozilla (and other browser / OS providers) > under NDA. > > > I think that statement from you is just fine (expect if proven otherwise). > > > We also have means whereby we are able to spot the misuse of our code- > signing certificates at an early stage. We revoke code-signing > certificates and push new CRLs out at very short notice when we become > aware of fraud / malware involving them. > > > > Very good! > > > The only automated processes which occur now are to avoid the > > unnecessary duplication of validation work. To try and clarify that a > > little, when we undertake some validation work we give that > > information a lifetime. If we check the existence of a legal domain, > > or domain ownership, we will not repeat that work if the same > > organization buys another certificate within some prescribed timescale. > > 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. What is Mozilla's policy on this matter? I am happy to give a commitment that I will give an honest answer as to whether we meet it. > > I understood your explanation on your use of internal databases and > third party sources. Your answers satisfy my questions in that respect. > > [Robin said...] Regards Robin _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
