On Saturday, 7 January 2017 09:08:21 UTC, Gervase Markham wrote: > One possibility for the latter two is that Comodo and/or Symantec used > an algorithm for detecting certs with internal names which was "no > dots", which wouldn't have turned these up. .local is clearly a local > domain - RFC 6762. .corp was originally just another TLD, but it was > controversial due to widespread internal use, and I was arguing for it > to be reserved for special use, but I don't know if it ever was. Does > anyone know the current status?
Presumably Mozilla would agree that checking only for dotless names was not adequate to meet the text or the intention of 7.1.4.2.1 here? Although .corp isn't called out as reserved, it has also never been delegated for use. Nothing ever legitimately owned these names in the Internet DNS hierarchy. https://icannwiki.com/.corp says that ICANN labelled .corp and .home as "high risk" after reviewing research into how bad the collisions would be if they were delegated, with the implication that they'll remain high risk for the foreseeable future and so these TLDs mustn't be delegated. Actually reserving these names would reward earlier misbehaviour, such as Microsoft and its certified professionals advising clients to use names in .corp for internal systems (Microsoft's documentation and training now says not to do this any more). Even if ICANN relents tomorrow, and gives an outlier like Donuts control over .corp the certificates I'm examining significantly pre-date such a decision and if anything it would become even more urgent to revoke them. > However, the first one of the three is a clear internal name, and it > would be good to hear from Comodo as to how it missed their revocation > sweep. > Given that you had to process 2 million certs to find them, and given > that auditors currently check on a "sampling" basis, I wouldn't > necessarily expect auditors to find these. I see. I guess I was mostly thinking about the aspects auditors are expected to be strong on, such as identifying whether a CA has a documented process to obey this aspect of 7.1.4.2.1 and ensured that process happened in a timely fashion. CT grants us good (and eventually superb) visibility into whether they actually do obey 7.1.4.2.1 but the auditors are better placed to understand why they didn't, for example because of inadequate process. You will know from our interactions outside m.d.s.policy that I'm very sceptical of the value of audit in the Web PKI today, and one reason is that even when audit is the appropriate mechanism to detect a problem it doesn't seem to have worked. This was true (and Mozilla took appropriate action) for WoSign/ StartCom and it's been true in other problem cases too. Anyway, I have another million certificates to examine now. _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
