On Tue, Feb 5, 2019 at 4:37 AM Matthias van de Meent via dev-security-policy <dev-security-policy@lists.mozilla.org> wrote:
> On Mon, 4 Feb 2019 at 18:06, Ryan Sleevi <r...@sleevi.com> wrote: > > > > On Mon, Feb 4, 2019 at 10:46 AM Matthias van de Meent via > dev-security-policy <dev-security-policy@lists.mozilla.org> wrote: > >> > >> Hi, > >> > >> Today we've bought a wildcard certificate [0] for our cofano.io domain > >> from Sectigo (previously ComodoCA) via a reseller. Our CAA policy > >> describes that only "comodoca.com" can issue wildcards. The > >> certificate has been issued and signed by Sectigo's 'new' intermediate > >> and root [1] [2]. > >> > >> My question is the following: Was Sectigo allowed to sign the > >> certificate using their Sectigo (not ComodoCA) keys, while my CAA > >> record specifies 'issuewild "comodoca.com"'? > > > > > > Yes > > > >> > >> I.E. How should a CA name > >> change be reflected in ( CAA ) conformance? Especially since the > >> Sectigo CPS [3] still only specifies Comodo as their issuer name, > >> which conflicts with the CN/O of the signing certificate [1]. > > > > > > There's zero requirement about any such mapping. > > > > The Baseline Requirements, Section 2.2, requires that CAs disclose their > policies and respected domains for their CAA policy. > > > > Section 3.2.2.8 places more requirements, largely around the > processing/validation model. To the question of domain names is not touched. > > > > Thus, a CA can disclose in their CP/CPS many domains, including those of > affiliated or non-affiliated CAs. Provided that this is disclosed in their > CP/CPS, and their exception process is clearly documented for domains not > in that enumerated list, then they're complying. > > > > Sectigo's CP/CPS discloses that they'll issue for comodoca.com (4.2 of > their CPS - https://sectigo.com/uploads/files/Comodo-CA-CPS-4-2.pdf ; > section 4.2.4), therefore they've met the requirements. > > I agree that sectigo hosts a CPS which meets the requirements for them > to issue a certificate for the website. The issue is different here, > though. > > The apparent signee (ComodoCA/Sectigo) has issued their CPS here > (https://sectigo.com/legal , https://www.comodoca.com/en-us/legal/ ), > latest version both being 4.2, which mentions (in section 7.1.1 > <Certificate Profile, Certificate Versions>) that the certificates > will be issued according based on the CPS, Appendix C, which only > includes 'O=Comodo Limited'-, 'O=Comodo CA Limited'- and 'O=The > USERTRUST Network'-issuer certificates. > > As the signee of my certificate is not included in any way or form in > the CPS of neither ComodoCA nor Sectigo, this would _not_ qualify as a > certificate signed according to ComodoCAs nor Sectigos CPS (using a > strict reading), and as such this would be an indication of a rogue > intermediate certificate authority (if that is the correct term). > > Please advise > > It appears that the "Sectigo RSA Organization Validation Secure Server CA" was issued on 2-November, after Sectigo last updated their CPS (version 4.2 is dated 5-October). Using that new intermediate CA certificate to sign subscriber certificates prior to updating the CPS does seem like a problem, although I can't point to a specific requirement that forbids doing so. Mozilla policy section 5.3.2 requires all new intermediate CA certificates to be disclosed in CCADB within one week of creation, and that was done properly by Sectigo. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
