CAA policy - ComodoCA or Sectigo?

[Matthias van de Meent]

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"'? 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].

Thanks in advance,

Matthias van de Meent

PS. If this is not the correct location for such questions, then
please advise on where to ask instead. My basic knowledge is just that
- basic - and only got me so far. I have searched the archives of this
mailing list for 'CA name change' and 'Sectigo', which both resulted
in no relevant results for this question.

[0] https://crt.sh/?id=1169278151
[1] https://crt.sh/?caid=105493
[2] https://crt.sh/?caid=1167
[3] https://sectigo.com/legal

[Ryan Sleevi]

On Mon, Feb 4, 2019 at 10:46 AM Matthias van de Meent via
dev-security-policy <dev-secur...@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.

[Matthias van de Meent]

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

[Wayne Thayer]

On Tue, Feb 5, 2019 at 4:37 AM Matthias van de Meent via

> 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.

[Ryan Sleevi]

On Tue, Feb 5, 2019 at 6:37 AM Matthias van de Meent <
matthias....@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
> <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
>

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?

[Robin Alden]

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 <Issuer 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

> > 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-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy

[Matthias van de Meent]

On Tue, 5 Feb 2019 at 18:05, Robin Alden <robin...@sectigo.com> 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 name <Issuer 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.

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)

[Matthias van de Meent]

On Tue, 5 Feb 2019 at 16:58, Ryan Sleevi <ry...@sleevi.com> wrote:

>
> On Tue, Feb 5, 2019 at 6:37 AM Matthias van de Meent <matthias....@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
>> <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
>
>

> 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.

[Wayne Thayer]

> 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