Disclosure and CP/CPS for Cross-Signed Roots

641 views
Skip to first unread message

Wayne Thayer

unread,
Jul 18, 2019, 2:40:52 PM7/18/19
to mozilla-dev-security-policy
Andrew Ayer filed two bugs yesterday [1] [2] that might be worthy of a bit
of discussion. They both appear to be in reference to root certificates
included in the Mozilla program that are cross-signed by a different TSP
(CA). In both cases the TSP that signed the cross-certificate has had it
audited, and disclosed it in CCADB as operating under their own CPS.

For example:
TSP 1 has Root A (subject A, issuer A, public key A) included in the
Mozilla root store
TSP 2 has Root B (subject B, issuer B, public key B) also included in the
Mozilla root store
TSP 2 has signed a cross certificate (subject A, issuer B, public key A)
with Root B.
TSP 2 has disclosed the cross-certificate in CCADB, has it included in
their audit, and asserts that it is operated under their CP/CPS.

One issue, that I recall having been been previously discussed, is that TSP
1 has no way of knowing if another TSP has cross-signed one of their CA
certificates, so it makes sense to require disclosure from the TSP that
issued the cross-certificate.

I think Andrew is asserting that the cross-certificate is really operated
by the root TSP that is in control of the key-pair (TSP 1), and should be
audited and disclosed as such. Should that be our policy?

A secondary question is if the disclosures made by GoDaddy and Sectigo and
documented the bugs filed by Andrew violate our current policies?

- Wayne

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1567060
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1567061

Ryan Sleevi

unread,
Jul 18, 2019, 3:45:40 PM7/18/19
to Wayne Thayer, mozilla-dev-security-policy
For the easiest one first: with respect to the GoDaddy disclosure [1 (your
#2)], I can't see either certificate being disclosed in the audit report.
That definitely sounds like a clear and obvious incorrect disclosure - but
perhaps I'm missing something?

With respect to the Sectigo disclosure [2 (your #1)], this is a bit
trickier.

That's because Sectigo's audit [3] does include the relevant certificates,
as does Management's Assertion. Similarly, Web.com's / Network Solutions
audit [4] and Management's Assertion similarly contain the relevant
certificates. The former audit was conducted by E&Y New York, the latter
audit conducted by E&Y Tampa.

You can note a number of similarities in the audit reports (and have
existed for some time), such as Web.com's audits listing all the same
locations as Sectigo's. I believe that this is because Sectigo has been
running "white label" services for Network Solutions / Web.com, in which
Sectigo performs the management and maintenance, but Web.com obtains an
independent audit bearing their own name. While rare for the CA space, this
is not terribly unique in the compliance space - for example, you will find
many products on the NIST CMVP list that use OpenSSL's FIPS module under
the hood, but branded with their own corporate information and accompanying
security policy.

In theory, this is 'valid'. Sectigo's auditors would examine all of the
systems and controls, ensuring that they're consistent with Sectigo's
CP/CPS and the relevant requirements, and issue an opinion. Web.com's
auditors would similarly examine all of the systems and controls (e.g.
inspecting Sectigo's facilities and employees/controls), and ensure that
they're consistent with Web.com's CP/CPS and the relevant requirements.
Provided that Sectigo allows Web.com's auditors access to their facilities
(and vice-versa), it is possible to issue audits and opinions in this way,
assuming that the CP/CPS of both organizations are harmonized. They don't
even have to use the same auditors.

Whether this is good or advisable, from a policy perspective, I'm not sure.
It does highlight some of the issues we've long talked about due to an
overreliance on audits and their presumed objectivity, and highlights the
importance of careful examination. The past discussions on m.d.s.p., when
audits were first introduced as a requirement. Ian Grigg's work in the
context of CACert, the community CA, and in trying to develop and define an
audit methodology [5], highlighted the role of audits examining a CA's
CP/CPS. This approach was similarly highlighted by the ABA's PKI Assessment
Guidelines, which deeply influenced what WebTrust (and its predecessor)
became and evolved into.

Thus, in order to understand whether or not Sectigo and Web.com's
disclosures represent a bug, we'd need to better understand from them, and
their auditors, the relationship between these two organizations, as well
as what independent steps each group of auditor took, in order to examine
who has operational and issuance control, and how those policies were
evaluated.

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1567061
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1567060
[3]
https://www.cpacanada.ca/generichandlers/aptifyattachmenthandler.ashx?attachmentid=231163
[4]
https://www.cpacanada.ca/generichandlers/aptifyattachmenthandler.ashx?attachmentid=230862
[5] https://iang.org/papers/open_audit_lisa.html
[6]
https://www.americanbar.org/content/dam/aba/events/science_technology/2013/pki_guidelines.pdf

Andrew Ayer

unread,
Jul 18, 2019, 4:46:32 PM7/18/19
to Wayne Thayer, mozilla-dev-security-policy
On Thu, 18 Jul 2019 11:40:31 -0700
Wayne Thayer via dev-security-policy
<dev-secur...@lists.mozilla.org> wrote:

> Andrew Ayer filed two bugs yesterday [1] [2] that might be worthy of
> a bit of discussion.

There's a third bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1567062

Like the GoDaddy case, the intermediate supposedly having the same
CP/CPS/audits as parent is not listed in the parent's audit report, so
this too looks like an incorrect disclosure.

Regarding Sectigo and Web.com, although their CPSes use extremely
similar language, they are not consistent, since they list different
CAA domains.

Regards,
Andrew

Peter Bowen

unread,
Jul 18, 2019, 5:43:29 PM7/18/19
to Wayne Thayer, mozilla-dev-security-policy
On Thu, Jul 18, 2019 at 11:40 AM Wayne Thayer via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> Andrew Ayer filed two bugs yesterday that might be worthy of a bit
> of discussion. They both appear to be in reference to root certificates
> included in the Mozilla program that are cross-signed by a different TSP
> (CA). In both cases the TSP that signed the cross-certificate has had it
> audited, and disclosed it in CCADB as operating under their own CPS.
>
> For example:
> TSP 1 has Root A (subject A, issuer A, public key A) included in the
> Mozilla root store
> TSP 2 has Root B (subject B, issuer B, public key B) also included in the
> Mozilla root store
> TSP 2 has signed a cross certificate (subject A, issuer B, public key A)
> with Root B.
> TSP 2 has disclosed the cross-certificate in CCADB, has it included in
> their audit, and asserts that it is operated under their CP/CPS.
>
> One issue, that I recall having been been previously discussed, is that TSP
> 1 has no way of knowing if another TSP has cross-signed one of their CA
> certificates, so it makes sense to require disclosure from the TSP that
> issued the cross-certificate.
>
> I think Andrew is asserting that the cross-certificate is really operated
> by the root TSP that is in control of the key-pair (TSP 1), and should be
> audited and disclosed as such. Should that be our policy?
>

I think this confusion stems from the fact that the CCADB mixes the concept
of trust anchors and certificates (nodes and edges in the trust graph). A
certificate is a link between two entities - the issuer and the subject.
The creation of a certificate is governed by the issuer's practices but the
use of the key that is certified by the issuer is governed by the subject's
practices.

When it comes to audits, the issuer and subject can each make different
auditable assertions. The issuer can assert that the certificate was
created in accordance with the issuer's practices and the issuer can
describe controls around publishing status and revocation information about
the certificate. The subject can describe controls around the generation
of the subject key and storage and usage of the private key associated with
the certified public key. Unfortunately this nuance is currently not
describable in the CCADB. It expects that a certificate hash is included
in the audit report but does not allow separate listing of trust anchors.

I think that the process should be updated to list CAs (subject, subject
public key, subject key identifier), is addition to listing the CA
certificates.

Thanks,
Peter

Rob Stradling

unread,
Jul 24, 2019, 12:42:03 PM7/24/19
to Andrew Ayer, Wayne Thayer, mozilla-dev-security-policy
[Wearing Sectigo hat]

Andrew, thanks for filing [1]. Sectigo will provide a full response on
that bug, but I'll just note here that we have updated the CCADB records
for the cross-certificates such that the Audit and CP/CPS details are
now consistent with the Web.com roots. As it happens, I was already
aware of this inconsistency, but I'd delayed fixing it so that I could
use it as a test case for...

[Wearing crt.sh hat]

https://crt.sh/mozilla-disclosures now has two new buckets:
- Disclosed, but with Inconsistent Audit details
- Disclosed, but with Inconsistent CP/CPS details

(I started discussing this new feature with Kathleen, Wayne and Sleevi
off-list a few months ago, but I was not able to finish implementing it
until a few days ago).

I've also made the checks for the "Disclosure Incomplete" bucket
stricter. Missing/incomplete disclosures of BR and/or EV audits are now
flagged.


[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1567060

On 18/07/2019 21:46, Andrew Ayer via dev-security-policy wrote:
> On Thu, 18 Jul 2019 11:40:31 -0700
> Wayne Thayer via dev-security-policy
> <dev-secur...@lists.mozilla.org> wrote:
>
>> Andrew Ayer filed two bugs yesterday [1] [2] that might be worthy of
>> a bit of discussion.
>
> There's a third bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1567062
>
> Like the GoDaddy case, the intermediate supposedly having the same
> CP/CPS/audits as parent is not listed in the parent's audit report, so
> this too looks like an incorrect disclosure.
>
> Regarding Sectigo and Web.com, although their CPSes use extremely
> similar language, they are not consistent, since they list different
> CAA domains.
>
> Regards,
> Andrew

--
Rob Stradling
Senior Research & Development Scientist
Sectigo Limited

Wayne Thayer

unread,
Jul 24, 2019, 8:49:34 PM7/24/19
to Rob Stradling, Andrew Ayer, mozilla-dev-security-policy
Thank you Rob! These are excellent additions to this report.

I'd like to ask all the CA representatives on this list to take a look at
the updated report (https://crt.sh/mozilla-disclosures) and correct any
issues with your company's disclosures as soon as possible.

Regarding Peter's earlier comment:

> I think that the process should be updated to list CAs (subject, subject
public key, subject key identifier), is addition to listing the CA
certificates.

It makes sense. I'll discuss this suggestion with Kathleen.

For now, what I'm hearing is that the GoDaddy and Asseco cases are clearly
incorrect disclosures due to the certificates not showing up on the
"parent" audit statement.

I think we want to continue to hold the issuing CA accountable for
disclosing any cross-certificates it signs, but they need to indicate that
the audit and applicable CP/CPS is that of the subject CA when that is the
case. I will also consider adding guidance on this issue to
https://www.ccadb.org/cas/intermediates

- Wayne

Brenda Bernal

unread,
Jul 26, 2019, 7:49:17 PM7/26/19
to Rob Stradling, Andrew Ayer, Wayne Thayer, mozilla-dev-security-policy
We are curious why our cross-roots are showing up on the list? Can you share the logic on why these are appearing on the report?
As far as our reviews are concerned, we see that all of these cross-roots are properly disclosed and have covering audits.

We also see that you have listed CAs where there is a different audit for the issuing CA than the audit that covers the root and the intermediate CA.
We have reviewed the audits we have posted on CCADB for the non-TLS CAs and we find we have accurately disclosed the division of responsibility between our external CA operators who control the issuing CA under their own qualifying audit, and our audits which cover the Root and the intermediate CA which we operate in an offline manner.

Thank you,
Brenda Bernal
DigiCert
_______________________________________________
dev-security-policy mailing list
dev-secur...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Andrew Ayer

unread,
Jul 29, 2019, 4:52:50 PM7/29/19
to mozilla-dev-security-policy
On Wed, 24 Jul 2019 16:41:53 +0000
Rob Stradling via dev-security-policy
<dev-secur...@lists.mozilla.org> wrote:

> [Wearing crt.sh hat]
>
> https://crt.sh/mozilla-disclosures now has two new buckets:
> - Disclosed, but with Inconsistent Audit details
> - Disclosed, but with Inconsistent CP/CPS details
>
> (I started discussing this new feature with Kathleen, Wayne and
> Sleevi off-list a few months ago, but I was not able to finish
> implementing it until a few days ago).
>
> I've also made the checks for the "Disclosure Incomplete" bucket
> stricter. Missing/incomplete disclosures of BR and/or EV audits are
> now flagged.

Thanks, Rob. This is a really valuable feature.

I noticed some false positives, for example where one disclosure URL
refers directly to the CP/CPS and the other refers to a repository
page which links to the CP/CPS. Perhaps it's time to require CAs to
disclose the URL of the actual CP/CPS rather than a repository page, as
discussed a few months ago:

https://groups.google.com/d/msg/mozilla.dev.security.policy/DyF-5NcYpJI/UNoF46XXAgAJ

Regards,
Andrew

Rob Stradling

unread,
Jul 30, 2019, 7:08:57 AM7/30/19
to Brenda Bernal, mozilla-dev-security-policy, Andrew Ayer, Wayne Thayer
Hi Brenda.

https://crt.sh/mozilla-disclosures now shows more information about why
each intermediate certificate is being flagged as requiring further
disclosure.

I've also added a "Review this Subject CA's CCADB records" link for each
entry in the two new buckets. This searches the CCADB for all records
that share the same SPKI. (The expectation is that the Audit and CP/CPS
details will be consistent across all CCADB records that share the same
SPKI).

Does that help?

On 27/07/2019 00:49, Brenda Bernal wrote:
> We are curious why our cross-roots are showing up on the list? Can you share the logic on why these are appearing on the report?
> As far as our reviews are concerned, we see that all of these cross-roots are properly disclosed and have covering audits.
>
> We also see that you have listed CAs where there is a different audit for the issuing CA than the audit that covers the root and the intermediate CA.
> We have reviewed the audits we have posted on CCADB for the non-TLS CAs and we find we have accurately disclosed the division of responsibility between our external CA operators who control the issuing CA under their own qualifying audit, and our audits which cover the Root and the intermediate CA which we operate in an offline manner.
>
> Thank you,
> Brenda Bernal
> DigiCert
>
> On 7/24/19, 9:42 AM, "dev-security-policy on behalf of Rob Stradling via dev-security-policy" <dev-security-...@lists.mozilla.org on behalf of dev-secur...@lists.mozilla.org> wrote:
>
> [Wearing Sectigo hat]
>
> Andrew, thanks for filing [1]. Sectigo will provide a full response on
> that bug, but I'll just note here that we have updated the CCADB records
> for the cross-certificates such that the Audit and CP/CPS details are
> now consistent with the Web.com roots. As it happens, I was already
> aware of this inconsistency, but I'd delayed fixing it so that I could
> use it as a test case for...
>
> [Wearing crt.sh hat]
>
> https://crt.sh/mozilla-disclosures now has two new buckets:
> - Disclosed, but with Inconsistent Audit details
> - Disclosed, but with Inconsistent CP/CPS details
>
> (I started discussing this new feature with Kathleen, Wayne and Sleevi
> off-list a few months ago, but I was not able to finish implementing it
> until a few days ago).
>
> I've also made the checks for the "Disclosure Incomplete" bucket
> stricter. Missing/incomplete disclosures of BR and/or EV audits are now
> flagged.
>
>
Email: r...@sectigo.com
Bradford, UK
Office: +441274024707
Sectigo Limited

This message and any files associated with it may contain legally
privileged, confidential, or proprietary information. If you are not the
intended recipient, you are not permitted to use, copy, or forward it,
in whole or in part without the express consent of the sender. Please
notify the sender by reply email, disregard the foregoing messages, and
delete it immediately.

Rob Stradling

unread,
Jul 30, 2019, 7:55:18 AM7/30/19
to Andrew Ayer, mozilla-dev-security-policy
On 29/07/2019 21:52, Andrew Ayer via dev-security-policy wrote:
> On Wed, 24 Jul 2019 16:41:53 +0000
> Rob Stradling via dev-security-policy
> <dev-secur...@lists.mozilla.org> wrote:
>
>> [Wearing crt.sh hat]
>>
>> https://crt.sh/mozilla-disclosures now has two new buckets:
>> - Disclosed, but with Inconsistent Audit details
>> - Disclosed, but with Inconsistent CP/CPS details
>>
>> (I started discussing this new feature with Kathleen, Wayne and
>> Sleevi off-list a few months ago, but I was not able to finish
>> implementing it until a few days ago).
>>
>> I've also made the checks for the "Disclosure Incomplete" bucket
>> stricter. Missing/incomplete disclosures of BR and/or EV audits are
>> now flagged.
>
> Thanks, Rob. This is a really valuable feature.

:-)

> I noticed some false positives, for example where one disclosure URL
> refers directly to the CP/CPS and the other refers to a repository
> page which links to the CP/CPS.

crt.sh simply checks whether or not the CP and CPS URLs exactly match
across all CCADB records for the same Subject CA. I can't think of any
good reason why these URLs would ever need to not match.

> Perhaps it's time to require CAs to
> disclose the URL of the actual CP/CPS rather than a repository page, as
> discussed a few months ago:

I think this is a reasonable thing to ask for, at least in principle.

It's currently only possible for CAs to update the CP/CPS URLs in their
CCADB Root Certificate records by opening a "CA Audit Update Request"
Case. (Each CCADB Root Certificate page says "CAs cannot modify data
for the Root Certificate records. It is verified and maintained by root
store operator.")

Practically, I believe this means that CAs can currently only disclose
(changes to) CP/CPS URLs to the CCADB on an annual basis. Given that
https://www.ccadb.org/policy says (emphasis mine) "The URLs to such CPs,
CPSes...need to be updated *as new information become available*", ISTM
that CAs cannot currently use different URLs for different versions of
their CP/CPS (as some CAs do) unless they restrict themselves to only
updating their CP/CPS once a year, immediately prior to opening a "CA
Audit Update Request" Case.

Requiring non-versioned CP/CPS URLs that point directly to the current
CP/CPS document (rather than a repository page) could work though, I think.

Alternative idea:
Set up a GitHub repository (managed by the CCADB root store operators)
that will hold CP/CPS documents. Require CAs to disclose each new
CP/CPS document by submitting a Pull Request.

> https://groups.google.com/d/msg/mozilla.dev.security.policy/DyF-5NcYpJI/UNoF46XXAgAJ

Kathleen Wilson

unread,
Aug 7, 2019, 6:28:51 PM8/7/19
to mozilla-dev-s...@lists.mozilla.org
> It's currently only possible for CAs to update the CP/CPS URLs in their
> CCADB Root Certificate records by opening a "CA Audit Update Request"
> Case. (Each CCADB Root Certificate page says "CAs cannot modify data
> for the Root Certificate records. It is verified and maintained by root
> store operator.")


Our CCADB to-do list includes an item about enabling CAs to update
certain root and owner information more frequently, such as CP/CPS docs.
However, I prioritized extending Audit Letter Validation (ALV) to
intermediate certs higher.

In the meantime, if CAs want to update their CP/CPS URLs more
frequently, they can send me email with the URLs and which roots they
apply to, and I will enter the updates directly in the CCADB.

Thanks,
Kathleen

Reply all
Reply to author
Forward
0 new messages