I'm glad you added the smiley, because in my experience CAs have rarely, if ever, have had any discretion in such matters. Nor do we (DigiCert) particularly want to, to be honest. I prefer clear, open, and transparent validation rules that other CAs can't play games with.
Whitelisting and disclosure of validation sources was an active topic of discussion at the Redmond F2F, if I'm remembering my meetings correctly. I'm surprised that more small CAs didn't support me in that effort at my previous employer, as they generally have not taken as much time or effort to find the correct sources, and instead rely upon inferior sources. If that's the direction people want to move, I'd echo Matt's concern that it will be a complex and difficult process. It's best to recall we spent a year or three trying to reach consensus about what localities existed in Taiwan and how companies could be identified there, and failed. I'm always willing to work with people on improving the baseline requirements, but there needs to be a recognition up front that this is not going to be an easy problem to solve, and people need to be willing to volunteer and roll up their sleeves and do their part in we're going to undertake such a time consuming effort. -Tim > -----Original Message----- > From: dev-security-policy <dev-security-policy-boun...@lists.mozilla.org> On > Behalf Of Ryan Sleevi via dev-security-policy > Sent: Thursday, September 27, 2018 4:18 PM > To: Matthew Hardeman <mharde...@gmail.com> > Cc: mozilla-dev-security-policy > <mozilla-dev-security-pol...@lists.mozilla.org>; > Ian Carroll <i...@certly.io> > Subject: Re: Concerns with Dun & Bradstreet as a QIIS > > Yes, it would be work, but would result in consistent and reliable > information, > and already reflective of the fact that an EV certificate needs to identify > the > jurisdictionOfIncorporation and it's incorporating documents. Or are we saying > that OV doesn't need to make sure it's actually a valid and legal entity, and > can > just display whatever information the CA feels is appropriate? ;) > > > On Thu, Sep 27, 2018 at 6:48 PM Matthew Hardeman via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > > > A whitelist of QGIS sounds fairly difficult. And how long would it > > take to adopt a new one? > > > > In some states you're going to have an authority per county. It'd be > > a big list. > > > > On Thu, Sep 27, 2018 at 5:35 PM, Ian Carroll via dev-security-policy < > > dev-security-policy@lists.mozilla.org> wrote: > > > > > On Wednesday, September 26, 2018 at 6:12:22 PM UTC-7, Ryan Sleevi > wrote: > > > > Thanks for raising this, Ian. > > > > > > > > The question and concern about QIIS is extremely reasonable. As > > discussed > > > > in past CA/Browser Forum activities, some CAs have extended the > > > definition > > > > to treat Google Maps as a QIIS (it is not), as well as third-party > > WHOIS > > > > services (they’re not; that’s using a DTP). > > > > > > > > In the discussions, I proposed a comprehensive set of reforms that > > would > > > > wholly remedy this issue. Given that the objective of OV and EV > > > > certificates is nominally to establish a legal identity, and the > > > > legal identity is derived from State power of recognition, I > > > > proposed that > > only > > > > QGIS be recognized for such information. This wholly resolves > > differences > > > > in interpretation on suitable QIIS. > > > > > > > > However, to ensure there do not also emerge conflicting > > > > understandings > > of > > > > appropriate QGIS - and in particular, since the BRs and EVGs > > > > recognize > > a > > > > variety of QGIS’s with variable levels of assurance relative to > > > > the information included - I further suggested that the > > > > determination of a > > > QGIS > > > > for a jurisdictional boundary should be maintained as a normative > > > whitelist > > > > that can be interoperably used and assessed against. If a given > > > > jurisdiction is not included within that whitelist, or the QGIS is > > > > not > > on > > > > it, it cannot be used. Additions to that whitelist can be > > > > maintained by > > > the > > > > Forum, based on an evaluation of the suitability of that QGIS for > > > purpose, > > > > and a consensus for adoption. > > > > > > > > This would significantly reduce the risk, while also further > > > > reducing ambiguities that have arisen from some CAs attempting to > > > > argue that non-employees of the CA or QGIS, but which act as > > > > intermediaries on > > > behalf > > > > of the CA to the QGIS, are not functionally and formally DTPs and > > > > this subject to the assessment requirements of DTPs. This > > > > ambiguity is being exploited in ways that can allow a CA to > > > > nominally say it checked a > > QGIS, > > > > but is relying on the word of a third-party, and with no assurance > > > > of > > the > > > > system security of that third party. > > > > > > > > Do you think such a proposal would wholly address your concern? > > > > > > I think I'll always agree with removing intermediaries from the > > validation > > > process. Outside of practical concerns, a whitelist of QGIS entities > > sounds > > > like a good idea. > > > > > > I would wonder what the replacement for D&B is in the United States. > > > You can normally get an address for a company from a QGIS but not > > > (from the states I've seen) a phone number for callback verification. > > > _______________________________________________ > > > dev-security-policy mailing list > > > dev-security-policy@lists.mozilla.org > > > https://clicktime.symantec.com/a/1/y- > dE77yYyDdE_vODZUczVhOtZuTYGGpGY > > > 4Ii6XyCtys=?d=xM_nZuwA5sJLRzEZ-5hDj-JdWPtyAlcZZSlbxRTAHy-P- > XNq9xx3jZ > > > 8iYY-JYfKe4RiDTuQy3-3XiUBrmB3w4qsPdn5Qrf- > CMBxWOl1qZBE7XLTbJKqROFOm98 > > > > igoWWqCcSEnWeNlX7a0Wh3pE05MZ91kVuZWWuarXbE3EoGnfZLEObXJJUmi > Olntz70gG > > > WBYHCIwVzMUQhPCZEPWy12x- > SkAk1M0sZt5O73AtmpMNz6Z08r6LQtV1y2hfVDK3HMhw > > > > EJHdoBlayDtyh1eyIn8SYuMUmODq4R6U5XRY7QIXzNXVe6q7QGPNFNZXiL4zLL > YjPDgs > > > > eJ_9XC01RMMGPoIPYZz_eKhdDLAeohYGycl29w2LIIhVNjTxOHRvnm_aL9Dydyk > KTB-s > > > a9OWGIW7-kCGpvY6utRiMz6-h2bcQC- > 1RofZxCREXLpgDv07vLGgyXoQ%3D%3D&u=htt > > > ps%3A%2F%2Flists.mozilla.org%2Flistinfo%2Fdev-security-policy > > > > > _______________________________________________ > > dev-security-policy mailing list > > dev-security-policy@lists.mozilla.org > > https://clicktime.symantec.com/a/1/y- > dE77yYyDdE_vODZUczVhOtZuTYGGpGY4I > > i6XyCtys=?d=xM_nZuwA5sJLRzEZ-5hDj-JdWPtyAlcZZSlbxRTAHy-P- > XNq9xx3jZ8iYY > > -JYfKe4RiDTuQy3-3XiUBrmB3w4qsPdn5Qrf- > CMBxWOl1qZBE7XLTbJKqROFOm98igoWWq > > > CcSEnWeNlX7a0Wh3pE05MZ91kVuZWWuarXbE3EoGnfZLEObXJJUmiOlntz70g > GWBYHCIwV > > zMUQhPCZEPWy12x- > SkAk1M0sZt5O73AtmpMNz6Z08r6LQtV1y2hfVDK3HMhwEJHdoBlayD > > > tyh1eyIn8SYuMUmODq4R6U5XRY7QIXzNXVe6q7QGPNFNZXiL4zLLYjPDgseJ_9X > C01RMMG > > PoIPYZz_eKhdDLAeohYGycl29w2LIIhVNjTxOHRvnm_aL9DydykKTB- > sa9OWGIW7-kCGpv > > Y6utRiMz6-h2bcQC- > 1RofZxCREXLpgDv07vLGgyXoQ%3D%3D&u=https%3A%2F%2Flists > > .mozilla.org%2Flistinfo%2Fdev-security-policy > > > _______________________________________________ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://clicktime.symantec.com/a/1/y- > dE77yYyDdE_vODZUczVhOtZuTYGGpGY4Ii6XyCtys=?d=xM_nZuwA5sJLRzEZ- > 5hDj-JdWPtyAlcZZSlbxRTAHy-P-XNq9xx3jZ8iYY-JYfKe4RiDTuQy3- > 3XiUBrmB3w4qsPdn5Qrf- > CMBxWOl1qZBE7XLTbJKqROFOm98igoWWqCcSEnWeNlX7a0Wh3pE05MZ91k > VuZWWuarXbE3EoGnfZLEObXJJUmiOlntz70gGWBYHCIwVzMUQhPCZEPWy12x > - > SkAk1M0sZt5O73AtmpMNz6Z08r6LQtV1y2hfVDK3HMhwEJHdoBlayDtyh1eyIn > 8SYuMUmODq4R6U5XRY7QIXzNXVe6q7QGPNFNZXiL4zLLYjPDgseJ_9XC01RM > MGPoIPYZz_eKhdDLAeohYGycl29w2LIIhVNjTxOHRvnm_aL9DydykKTB- > sa9OWGIW7-kCGpvY6utRiMz6-h2bcQC- > 1RofZxCREXLpgDv07vLGgyXoQ%3D%3D&u=https%3A%2F%2Flists.mozilla.org > %2Flistinfo%2Fdev-security-policy
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
