| I see a few takeaways here. For consideration: 1) 39 months is entirely too much time to elapse before a cert requester should re-demonstrate control over a domain. Too much can happen in that time, including the abandonment of a domain name itself. 2) To that point, CA's should probably check that a domain is still active before every cert issuance--that is has not expired, been deleted, or been re-purchased by someone else prior to deletion. 3) Many (all?) CPS documents seem to have a clause about relying parties saying, in essence, that it's up to the relying party to decide when to trust the cert. There are many reasons I think such clauses are not enforceable but the main reason in this case is that the relying party must not only perform the technical validation but must also familiarize oneself with the business model of the cert holder. In this case, I see multiple domains listed that seem unrelated, except that they happen to use the same CDN service and that it's because of the CDN that the domains appear together. In other cases where seemingly unrelated domains appear, what am I to conclude? 4) DNS proxies and, now, certificate proxies are problematic because they obfuscate the true owner and thus the true intentions for holding a certificate. In this case, the true owner of the domain has no intention of actually using a certificate. Yet, as a relying party, what am I to conclude if I connect to a server with his domain name that is offering up a certificate? Basically I have no choice but to accept the connection even though I might be putting myself in harm's way. Merely demonstrating control of a domain doesn't necessarily mean that issuance of a cert is appropriate, so how will CA's make the right decisions so that relying parties will continue to trust them?
On 12/09/2016 23:48, Ryan Sleevi wrote: > On Monday, September 12, 2016 at 2:33:47 PM UTC-7, Jakob Bohm wrote: >> I find fault in CloudFlare (presuming the story is actually as >> reported). > > Why? Apologies, but I fail to see what you believe is "wrong", given how multiple people have pointed to you it being well-understood and permissible, under past and present guidelines. > Note that this is *entirely* outside CA/B and CA inclusion related guidelines, since CloudFlare is (presumably) not a CA and thus not subject to such guidelines. I am saying that they are (if the story is true) morally at fault for requesting a certificate that the domain owner did not authorize them to request, abusing their job of handling some technical aspects of the domain owners operation. The common equivalent would be a network administrator requesting a certificate that his boss had not authorized him to request. There is no way an outside CA could know that such authorization had not been given if that employee was in a position where the only difference between a real or bad request would be what their boss did or did not tell the employee to do. This common equivalent would be sufficiently common (on a worldwide statistical basis), that it would be useful for large CAs to have standard procedures and policies (be they manual or automated, public or internal) for handling such situations. The defining characteristic would be "this person claims to outrank the original certificate requestor and is requesting revocation of a certificate without having access to the files etc. involved in the original request". >> From the story as reported, Comodo had every reason to believe that >> CloudFlare was authorized by the domain owner to request that DV cert, >> and had no additional preemptive tests to do (baring a future finding >> that CloudFlare should be blacklisted from requesting DV certificates, >> which would require a large number of cases given the huge number of >> domains they handle without objection by domain owners). > > This gets further into "What you're proposing doesn't exist" territory, such as the notion of blacklisting an organization from requesting a DV cert, when the whole notion of DV is that the only thing validated is the domain (not the organization operating the domain or requesting the cert) > I was arguing *against* adding CloudFlare to such a list, even if it existed. And I would presume that any security conscious CA would have an internal black list of bad networks that they refuse to sell to because it tends to create too many practical, security or legal problems. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy | ||
_______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
