Re: CAA policy - ComodoCA or Sectigo?
On Tue, Feb 5, 2019 at 11:55 AM Matthias van de Meent via dev-security-policy wrote: > On Tue, 5 Feb 2019 at 16:58, Ryan Sleevi wrote: > > > CAs are not presently required to disclose those profiles in that > detail, but it sounds as if the issue is that Sectigo did not update the > CP/CPS following the rebrand. Does that match your understanding of the > issue? > > That is indeed my understanding. > > I've now read that there will be a post-rebrand CPS, so I hope that > this gap in documentation will be resolved soon. > > In the meantime, does this qualify as a nonconformance according to > point 7.1.4 in the mozilla certificate policy -- a Certificate Policy > and Certification Practice Statement (or links to a CP and CPS) or > equivalent disclosure document(s) for the CA or CAs in question --? > Using a strict reading, the CPS linked to in the issued certificate > does not cover the certificate (in a strict reading) by not having > CP/CPS information about the CA in question. > > Section 7.1 covers "Inclusions" - the process of getting a root certificate added to Mozilla's program. Since the USERTrust RSA Certification Authority is already in the program, this section isn't applicable to the current situation. For this to qualify as a non-conformance under Mozilla policy, I think we would first need to require CAs to list all CA certificates covered by the CPS in the document. I'm unable to locate an example, but I am fairly confident that not all CAs do this currently. I would be interested to know if others think that we should or should not add such a requirement to our policy. On a more practical level, Sectigo's own crt.sh service exposes the information that CAs disclose about CA certificates in CCADB. On the Audit details row you can see that Sectigo has disclosed that this new intermediate is governed by their existing CPS: https://crt.sh/?id=924467861 - Wayne ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: CAA policy - ComodoCA or Sectigo?
On Tue, 5 Feb 2019 at 16:58, Ryan Sleevi wrote: > > On Tue, Feb 5, 2019 at 6:37 AM Matthias van de Meent > wrote: >> >> 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 >> ) 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 > > > Thanks for clarifying. Note that Sectigo is the rebranded name of Comodo CA ( > https://groups.google.com/d/msg/mozilla.dev.security.policy/Feh5Xk95mtM/JzINdTT7AwAJ > ), as the same entity. > > I want to make sure I follow your point: Your new remark is that there's > nothing amiss with CAA, but you're concerned that Sectigo's CPS does not > enumerate all of the intermediates they use to issue, by virtue of not > enumerating their subject names within Appendix C, which is cross-referenced > by Section 7.1. Is that correct? That is correct. The CPS enumerate subject names as were it a conclusive list, in multiple sections (1.4.1, Appendix C and Appendix D - which is not mentioned throughout the CPS). Apparently this is not the case, but a conclusive list can only be obtained using certificate transparency logs and certificate authority repositories. Then there is still no information about what policies are applied to said certificates, as the table in 1.4.1 does not include said subject names. > CAs are not presently required to disclose those profiles in that detail, but > it sounds as if the issue is that Sectigo did not update the CP/CPS following > the rebrand. Does that match your understanding of the issue? That is indeed my understanding. I've now read that there will be a post-rebrand CPS, so I hope that this gap in documentation will be resolved soon. In the meantime, does this qualify as a nonconformance according to point 7.1.4 in the mozilla certificate policy -- a Certificate Policy and Certification Practice Statement (or links to a CP and CPS) or equivalent disclosure document(s) for the CA or CAs in question --? Using a strict reading, the CPS linked to in the issued certificate does not cover the certificate (in a strict reading) by not having CP/CPS information about the CA in question. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: CAA policy - ComodoCA or Sectigo?
On Tue, 5 Feb 2019 at 18:05, Robin Alden wrote: > > Wayne, Mattias, > We have a post-rebrand CPS which is almost ready to publish and has > a new Certificate Profiles section. Thanks for the heads-up, is there a projected timeframe in which this new CPS will be available? > To the OP's first question, we continue to accept (amongst others) > comodo.com and comodoca.com as Issuer Domain Names in CAA records that > authorize us to issue. > > RFC6844 says > ".. authorizes the holder of the domain nameName> or a party acting under the explicit authority of the holder > of that domain name to issue certificates for the domain in which > the property is published." > We are the holder of comodoca.com. We have explicit authority to use > comodo.com for this purpose. > > We have always disclosed updates to our CAA domains to the CCADB promptly. As stated earlier in the thread, the main problem is not per se the CAA domain validation, but about the issuer of the certificates created after CAA validation, as there was to my knowledge no public CP/CPS for the intermediates used for the certificate, which raised red flags in our internal certificate validation process. > Regards > Robin Alden > Sectigo Limited Regards, Matthias van de Meent Cofano Software Solutions (nl) ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: CAA policy - ComodoCA or Sectigo?
Wayne, Mattias, We have a post-rebrand CPS which is almost ready to publish and has a new Certificate Profiles section. To the OP's first question, we continue to accept (amongst others) comodo.com and comodoca.com as Issuer Domain Names in CAA records that authorize us to issue. RFC6844 says ".. authorizes the holder of the domain name or a party acting under the explicit authority of the holder of that domain name to issue certificates for the domain in which the property is published." We are the holder of comodoca.com. We have explicit authority to use comodo.com for this purpose. We have always disclosed updates to our CAA domains to the CCADB promptly. Regards Robin Alden Sectigo Limited > -Original Message- > From: dev-security-policy > On Behalf Of Wayne Thayer via dev-security-policy > Sent: 05 February 2019 15:58 > To: Matthias van de Meent > Cc: Ryan Sleevi ; MDSP pol...@lists.mozilla.org> > Subject: Re: CAA policy - ComodoCA or Sectigo? > > On Tue, Feb 5, 2019 at 4:37 AM Matthias van de Meent via > dev-security-policy wrote: > > > On Mon, 4 Feb 2019 at 18:06, Ryan Sleevi wrote: > > > > > > On Mon, Feb 4, 2019 at 10:46 AM Matthias van de Meent via > > dev-security-policy 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 > > ) 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 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
Re: CAA policy - ComodoCA or Sectigo?
On Tue, Feb 5, 2019 at 6:37 AM Matthias van de Meent < matthias.vandeme...@cofano.nl> wrote: > 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 > ) 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 > Thanks for clarifying. Note that Sectigo is the rebranded name of Comodo CA ( https://groups.google.com/d/msg/mozilla.dev.security.policy/Feh5Xk95mtM/JzINdTT7AwAJ ), as the same entity. I want to make sure I follow your point: Your new remark is that there's nothing amiss with CAA, but you're concerned that Sectigo's CPS does not enumerate all of the intermediates they use to issue, by virtue of not enumerating their subject names within Appendix C, which is cross-referenced by Section 7.1. Is that correct? CAs are not presently required to disclose those profiles in that detail, but it sounds as if the issue is that Sectigo did not update the CP/CPS following the rebrand. Does that match your understanding of the issue? ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: CAA policy - ComodoCA or Sectigo?
On Tue, Feb 5, 2019 at 4:37 AM Matthias van de Meent via dev-security-policy wrote: > On Mon, 4 Feb 2019 at 18:06, Ryan Sleevi wrote: > > > > On Mon, Feb 4, 2019 at 10:46 AM Matthias van de Meent via > dev-security-policy 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 > ) 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
Re: CAA policy - ComodoCA or Sectigo?
On Mon, 4 Feb 2019 at 18:06, Ryan Sleevi wrote: > > On Mon, Feb 4, 2019 at 10:46 AM Matthias van de Meent via dev-security-policy > 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 ) 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 ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: CAA policy - ComodoCA or Sectigo?
On Mon, Feb 4, 2019 at 10:46 AM Matthias van de Meent via dev-security-policy 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. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
