Hi Robin, First of all thank you for your honest answers, I appreciate that and the time you invested! This is going to be a summarized response of all your posts and answers.
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. 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. > 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. > > 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. > > 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. > The WebTrust Audit covers most aspects of our operation as a CA. Most or all? > 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... > 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. > 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?) I understood your explanation on your use of internal databases and third party sources. Your answers satisfy my questions in that respect. -- 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
