info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Disclosure and CP/CPS for Cross-Signed Roots
653 views
Skip to first unread message
Wayne Thayer
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
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
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
#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
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
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
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
> Andrew Ayer filed two bugs yesterday [1] [2] that might be worthy of
> a bit of discussion.
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
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 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
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
> 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?
>
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
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
>> Andrew Ayer filed two bugs yesterday [1] [2] that might be worthy of
>> a bit of discussion.
>
Rob Stradling
Senior Research & Development Scientist
Sectigo Limited
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
>> 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
--
>
> 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
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
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.
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
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
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
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
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 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.
> [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.
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
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...
>
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.
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.
>
>
>
> 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.
>
>
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
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:
>
> 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.
>
>>
>> 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.
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:
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
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
> 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.")
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
0 new messages