It's not clear that there is anything for DigiCert to respond to. Are we asserting that the existence of this Arabtec certificate is proof that DigiCert violated section 3.2.1 of their CPS?
- Wayne On Thu, Apr 11, 2019 at 6:57 PM Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On 11/04/2019 04:47, Santhan Raj wrote: > > On Wednesday, April 10, 2019 at 5:53:45 PM UTC-7, Corey Bonnell wrote: > >> On Wednesday, April 10, 2019 at 7:41:33 PM UTC-4, Nick Lamb wrote: > >>> (Resending after I typo'd the ML address) > >>> > >>> At the risk of further embarrassing myself in the same week, while > >>> working further on mimicking Firefox trust decisions I found this > >>> pre-certificate for Arabtec Holding PJSC: > >>> > >>> https://crt.sh/?id=926433948 > >>> > >>> Now there's nothing especially strange about this certificate, except > >>> that its RSA public key is shared with several other certificates > >>> > >>> > https://crt.sh/?spkisha256=8bb593a93be1d0e8a822bb887c547890c3e706aad2dab76254f97fb36b82fc26 > >>> > >>> ... such as the DigiCert Global Root G2: > >>> > >>> https://crt.sh/?caid=5885 > >>> > >>> > >>> I would like to understand what happened here. Maybe I have once again > >>> made a terrible mistake, but if not surely this means either that the > >>> Issuing authority was fooled into issuing for a key the subscriber > >>> doesn't actually have or worse, this Arabtec Holding outfit has the > >>> private keys for DigiCert's Global Root G2 > >>> > >>> Nick. > >> > >> AFAIK there's no requirement in the BRs or Mozilla Root Policy for CAs > to actually verify that the Applicant actually is in possession of the > corresponding private key for public keys included in CSRs (i.e., check the > signature on the CSR), so the most likely explanation is that the CA in > question did not check the signature on the Applicant-submitted CSR and > summarily embedded the supplied public key in the certificate (assuming > Digicert's CA infrastructure wasn't compromised, but I think that's highly > unlikely). > >> > >> A very similar situation was brought up on the list before, but with > WoSign as the issuing CA: > https://groups.google.com/d/msg/mozilla.dev.security.policy/zECd9J3KBW8/OlK44lmGCAAJ > >> > > > > While not a BR requirement, the CA's CPS does stipulate validating > possession of private key in section 3.2.1 (looking at the change history, > it appears this stipulation existed during the cert issuance). So something > else must have happened here. > > > > Except for the Arabtec cert, the other certs looks like cross-sign for > the Digicert root. > > > > Why still no response from Digicert? Has this been reported to them > directly? > > > > 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
