On Thu, Feb 28, 2019 at 6:21 AM Nick Lamb via dev-security-policy < [email protected]> wrote:
> On Thu, 28 Feb 2019 05:52:14 +0000 > Jeremy Rowley via dev-security-policy > <[email protected]> wrote: > > Hi Jeremy, > > > 4. The validation agent specified the approval scope as id-addr.arpa > > I assume this is a typo by you not the agent, for in-addr.arpa ? > > Meanwhile, and without prejudice to the report itself once made: > > > 2. The system marked the WHOIS as unavailable for automated parsing > > (generally, this happens if we are being throttled or the WHOIS info > > is behind a CAPTCHA), which allows a validation agent to manually > > upload a WHOIS document > > This is a potentially large hole in issuance checks based on WHOIS. > > Operationally the approach taken ("We can't get it to work, press on") > makes sense, but if we take a step back there's obvious potential for > nasty security surprises like this one. > > There has to be something we can do here, I will spitball something in > a next paragraph just to have something to start with, but to me if it > turns out we can't improve on basically "sometimes it doesn't work so > we just shrug and move on" we need to start thinking about deprecating > this approach altogether. Not just for DigiCert, for everybody. > > - Spitball: What if the CA/B went to the registries, at least the big > ones, and said we need this, strictly for this defined purpose, give > us either reliable WHOIS, or RDAP, or direct database access or > _something_ we can automate to do these checks ? The nature of CA/B > may mean that it's not appropriate to negotiate paying for this > (pressuring suppliers to all agree to offer members the same rates is > just as much a problem as all agreeing what you'll charge customers) > but it should be able to co-ordinate making sure members get access, > and that it isn't opened up to dubious data resellers that the > registries don't want rifling through their database. > Unfortunately, this is not really viable. The CA/Browser Forum maintains relationships with ICANN, as do individual members. While this, on its face, seems reasonable, there are practical, business, and legal concerns that prevent this from being viable. Further, proposals which would require membership in the CA/Browser Forum should, on their face, be rejected - a CA should not have to join the Forum in order to be a CA. I do agree, however, that the use of WHOIS data continues to show problematic incidents - whether it's with OCR issues or manual entry - and suspect a more meaningful solution is to move away from this model entirely. The recently approved methods to the BRs for expressing contact information via the DNS directly is one such approach. The GDPR issues surrounding WHOIS and RDAP have already led it to be compelling in its own right. Most importantly, you are on the right path of questions, though - which is we should examine such incidents systemically and look for improvements, and not convince ourselves that the status quo is the best possible solution :) _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
