Sleevi, Valid point, no intention to confuse, I have no current affiliation with GlobalSign, though I once did.
The documentation that described the protocol seems to no longer be online, the behavior is observable and has been discussed in the validation working group within the CABFORUM so it is not a secret. Ryan On Sun, Jan 14, 2018 at 7:10 AM, Ryan Sleevi <r...@sleevi.com> wrote: > > > On Sat, Jan 13, 2018 at 8:46 PM, Ryan Hurst via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > >> On Friday, January 12, 2018 at 6:10:00 PM UTC-8, Matt Palmer wrote: >> > On Fri, Jan 12, 2018 at 02:52:54PM +0000, Doug Beattie via >> dev-security-policy wrote: >> > > I’d like to follow up on our investigation and provide the community >> with some more information about how we use Method 9. >> > > >> > > 1) Client requests a test certificate for a domain (only one >> FQDN) >> > >> > Does this test certificate chain to a publicly-trusted root? If so, on >> what >> > basis are you issuing a publicly-trusted certificate for a name which >> > doesn't appear to have been domain-control validated? If not, doesn't >> this >> > test certificate break the customer's SSL validation for the period the >> > certificate is installed, while you do the validation? >> > >> > - Matt >> >> The certificate comes from a private PKI, not public one. > > > Matt: The Baseline Requirements provide a definition of Test Certificate > that applies to 3.2.2.4.9 that already addresses your concerns: > > Test Certificate: A Certificate with a maximum validity period of 30 days > and which: (i) includes a critical > extension with the specified Test Certificate CABF OID (2.23.140.2.1), or > (ii) is issued under a CA where there > are no certificate paths/chains to a root certificate subject to these > Requirements. > > Ryan: I think it'd be good to let GlobalSign answer, or, if the answer is > available publicly, to point them out. This hopefully helps avoid confusion > :) > _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
