Disclosure of intermediates that chain to multiple roots

[Rob Stradling]

Kathleen,

Some NSS built-in roots are cross-certified by other built-in roots.

When an intermediate cert chains to multiple roots, does it need to be
disclosed multiple times (once for each root)?

Or, if it only needs to be disclosed once, then how should we determine
which CA is responsible for disclosing? (Shortest chain, perhaps?)

Thanks.

--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

[Richard Barnes]

IIRC, the disclosure requirement is in terms of certificates, and the
disclosure responsibility is on the issuing CA. So you would have one
disclosure per certificate, and the issuing CA would be responsible.

Note that you can end up with multiple parents for the same exact
certificate, but that requires that each parent have the same public key --
so if those parents are owned by different organizations, we would have a
problem!

On Fri, May 13, 2016 at 2:08 PM, Rob Stradling <rob.st...@comodo.com>
wrote:

> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>

[Rob Stradling]

On 13/05/16 13:41, Richard Barnes wrote:
> IIRC, the disclosure requirement is in terms of certificates, and the
> disclosure responsibility is on the issuing CA. So you would have one
> disclosure per certificate, and the issuing CA would be responsible.

The Inclusion Policy [1] says that the responsibility is on "the CA that
has their certificate included in Mozilla's CA Certificate Program". I
don't see a mention of the "issuing CA".

The recent CA Communication said:
"ACTION #2: Beginning with Version 2.1 of Mozilla's CA Certificate
Policy, for any certificate which directly or transitively chains to the
root certificates you currently have included in Mozilla's CA
Certificate Program, which are capable of being used to issue new
certificates, and which are not technically constrained as described in
Section 9 of Mozilla's CA Certificate Inclusion Policy, you are required
to provide public-facing documentation about the certificate
verification requirements and annual public attestation of conformance
to said requirements. This includes certificates owned by, operated by,
or issued by third parties, whether or not those issuing certificates
are already part of Mozilla's CA Certificate Program, if they have been
cross-signed by a certificate that directly or transitively chains to
your root certificate."

IIUC, that last sentence is saying that multiple disclosures are
required (one disclosure per root to which the intermediate chains).
Have I misread it?


[1]
https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/inclusion/

[2]
https://mozillacaprogram.secure.force.com/Communications/CACommunicationSurveySample?CACommunicationId=a05o000000iHdtx

Office Tel: +44.(0)1274.730505
Office Fax: +44.(0)1274.730909
www.comodo.com

COMODO CA Limited, Registered in England No. 04058690
Registered Office:
3rd Floor, 26 Office Village, Exchange Quay,
Trafford Road, Salford, Manchester M5 3EQ

This e-mail and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they are
addressed. If you have received this email in error please notify the
sender by replying to the e-mail containing this attachment. Replies to
this email may be monitored by COMODO for operational or business
reasons. Whilst every endeavour is taken to ensure that e-mails are free
from viruses, no liability can be accepted and the recipient is
requested to use their own virus checking software.

[Kurt Roeckx]

On 2016-05-13 14:41, Richard Barnes wrote:
> IIRC, the disclosure requirement is in terms of certificates, and the
> disclosure responsibility is on the issuing CA. So you would have one
> disclosure per certificate, and the issuing CA would be responsible.
>
> Note that you can end up with multiple parents for the same exact
> certificate, but that requires that each parent have the same public key --
> so if those parents are owned by different organizations, we would have a
> problem!

I think there is a misunderstanding of the question.

If you have "Root CA1" and "Root CA2", both have issued a certificate
for "Intermediate CA1". That is, the subject and public key for those 2
certificates is the same but the issuer is different. And "Intermediate
CA1" issued one for "Intermediate CA2".

Do both "Root CA1" and "Root CA2" need to disclose "Intermediate CA1"?
"Intermediate CA2"?

My answer would be that a CA needs to disclose all non-constrained CAs
starting from their root CAs, and so both would need to disclose it.


Kurt

[Kurt Roeckx]

It might also be the case that "Intermediate CA1" moved from "Root CA1"
to "Root CA2", and "Root CA1" revoked it's "Intermediate CA1"
certificate, and so it only discloses that it revoked it and nothing
about "Intermediate CA2".


Kurt

[Richard Barnes]

On Fri, May 13, 2016 at 3:28 PM, Kurt Roeckx <ku...@roeckx.be> wrote:

> On 2016-05-13 14:41, Richard Barnes wrote:
>

>> IIRC, the disclosure requirement is in terms of certificates, and the
>> disclosure responsibility is on the issuing CA. So you would have one
>> disclosure per certificate, and the issuing CA would be responsible.
>>
>> Note that you can end up with multiple parents for the same exact
>> certificate, but that requires that each parent have the same public key
>> --
>> so if those parents are owned by different organizations, we would have a
>> problem!
>>
>

> I think there is a misunderstanding of the question.
>
> If you have "Root CA1" and "Root CA2", both have issued a certificate for
> "Intermediate CA1". That is, the subject and public key for those 2
> certificates is the same but the issuer is different. And "Intermediate
> CA1" issued one for "Intermediate CA2".
>
> Do both "Root CA1" and "Root CA2" need to disclose "Intermediate CA1"?
> "Intermediate CA2"?
>
> My answer would be that a CA needs to disclose all non-constrained CAs
> starting from their root CAs, and so both would need to disclose it.
>

I agree. Policy says "All [CA] certificates ... MUST either be technically
constrained or be publicly disclosed and audited".

--Richard



>
>
> Kurt

[Richard Barnes]

On Fri, May 13, 2016 at 3:05 PM, Rob Stradling <rob.st...@comodo.com>
wrote:

> On 13/05/16 13:41, Richard Barnes wrote:
>
>> IIRC, the disclosure requirement is in terms of certificates, and the
>> disclosure responsibility is on the issuing CA. So you would have one
>> disclosure per certificate, and the issuing CA would be responsible.
>>
>

> The Inclusion Policy [1] says that the responsibility is on "the CA that
> has their certificate included in Mozilla's CA Certificate Program". I
> don't see a mention of the "issuing CA".
>
> The recent CA Communication said:
> "ACTION #2: Beginning with Version 2.1 of Mozilla's CA Certificate Policy,
> for any certificate which directly or transitively chains to the root
> certificates you currently have included in Mozilla's CA Certificate
> Program, which are capable of being used to issue new certificates, and
> which are not technically constrained as described in Section 9 of
> Mozilla's CA Certificate Inclusion Policy, you are required to provide
> public-facing documentation about the certificate verification requirements
> and annual public attestation of conformance to said requirements. This
> includes certificates owned by, operated by, or issued by third parties,
> whether or not those issuing certificates are already part of Mozilla's CA
> Certificate Program, if they have been cross-signed by a certificate that
> directly or transitively chains to your root certificate."
>
> IIUC, that last sentence is saying that multiple disclosures are required
> (one disclosure per root to which the intermediate chains). Have I misread
> it?
>

No, I agree with you. If two certs have different issuers, they're
different certs, so they both need to be disclosed.

--Richard

>
>
> [1]
> https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/inclusion/
>
> [2]
> https://mozillacaprogram.secure.force.com/Communications/CACommunicationSurveySample?CACommunicationId=a05o000000iHdtx
>
>

> Note that you can end up with multiple parents for the same exact
>> certificate, but that requires that each parent have the same public key
>> --
>> so if those parents are owned by different organizations, we would have a
>> problem!
>>

>> On Fri, May 13, 2016 at 2:08 PM, Rob Stradling <rob.st...@comodo.com>
>> wrote:
>>
>> Kathleen,
>>>
>>> Some NSS built-in roots are cross-certified by other built-in roots.
>>>
>>> When an intermediate cert chains to multiple roots, does it need to be
>>> disclosed multiple times (once for each root)?
>>>
>>> Or, if it only needs to be disclosed once, then how should we determine
>>> which CA is responsible for disclosing? (Shortest chain, perhaps?)
>>>
>>> Thanks.
>>>
>>> --
>>> Rob Stradling
>>> Senior Research & Development Scientist
>>> COMODO - Creating Trust Online
>>>

>>> _______________________________________________
>>> dev-security-policy mailing list
>>> dev-secur...@lists.mozilla.org
>>> https://lists.mozilla.org/listinfo/dev-security-policy
>>>
>>> _______________________________________________
>> dev-security-policy mailing list
>> dev-secur...@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-security-policy
>>
>>

[Rob Stradling]

On 13/05/16 19:59, Richard Barnes wrote:
<snip>

> IIUC, that last sentence is saying that multiple disclosures are
> required (one disclosure per root to which the intermediate chains).
> Have I misread it?
>
>
> No, I agree with you. If two certs have different issuers, they're
> different certs, so they both need to be disclosed.

I agree with that. However, I'm not talking about two certs. I'm
talking about one cert whose issuing CA is the subject of multiple certs
that chain to multiple roots.

Consider this intermediate: https://crt.sh/?id=1790

It chains directly to a Built-in Root (https://crt.sh/?id=7677) that
belongs to Web.com.

It also chains, via 6 cross-certificates (see the Certificates section
of https://crt.sh/?caid=157) to the "AddTrust External CA Root" and
"UTN-USERFirst-Hardware" Built-in Roots (https://crt.sh/?id=1 and
https://crt.sh/?id=34) that belong to Comodo.

Re-quoting the recent CA Communication:

"This includes certificates owned by, operated by, or issued by third
parties, whether or not those issuing certificates are already part of
Mozilla's CA Certificate Program, if they have been cross-signed by a
certificate that directly or transitively chains to your root certificate"

I think this means that both Comodo and Web.com MUST disclose
https://crt.sh/?id=1790 to Salesforce.

Perhaps Comodo actually need to disclose it twice - once for "AddTrust
External CA Root" and once for "UTN-USERFirst-Hardware". Or perhaps 6
times - once for each possible chain!

<snip>
[I wrote]

> Or, if it only needs to be disclosed once, then how should
> we determine
> which CA is responsible for disclosing? (Shortest chain,
> perhaps?)

If it were up to me, I would...
1. Require https://crt.sh/?id=1790 to be disclosed precisely once, by
Web.com, because the chain up to Web.com's Built-in Root is the shortest
chain.
2. Hold both Web.com and Comodo equally to blame if
https://crt.sh/?id=1790 is not disclosed. (The gives Comodo the
incentive to ensure that Web.com do disclose it).

Anyway, please could you clarify exactly what needs to be done for
https://crt.sh/?id=1790 to be properly disclosed? Thanks.

[Nick Lamb]

On Friday, 13 May 2016 21:02:25 UTC+1, Rob Stradling wrote:
> If it were up to me, I would...
> 1. Require https://crt.sh/?id=1790 to be disclosed precisely once, by
> Web.com, because the chain up to Web.com's Built-in Root is the shortest
> chain.
> 2. Hold both Web.com and Comodo equally to blame if
> https://crt.sh/?id=1790 is not disclosed. (The gives Comodo the
> incentive to ensure that Web.com do disclose it).

FWIW Rob has exactly specified what I, as a relying party, would want Mozilla to do on my behalf although I would interpolate ("... and audited") each time he mentions disclosure.

I agree with him that the current policy does not clearly state this.

[Richard Barnes]

On Fri, May 13, 2016 at 10:48 PM, Nick Lamb <tiala...@gmail.com> wrote:

> On Friday, 13 May 2016 21:02:25 UTC+1, Rob Stradling wrote:

> > If it were up to me, I would...
> > 1. Require https://crt.sh/?id=1790 to be disclosed precisely once, by
> > Web.com, because the chain up to Web.com's Built-in Root is the shortest
> > chain.
> > 2. Hold both Web.com and Comodo equally to blame if
> > https://crt.sh/?id=1790 is not disclosed. (The gives Comodo the
> > incentive to ensure that Web.com do disclose it).
>

Thanks for explaining the specifics, Rob. To restate and check my
understanding, this is a "Y-shaped" scenario, with the following CAs (by
CN):

(1) AddTrust External CA Root (included, owned by Comodo)
(2) UTN-USERFirst-Hardware (included, owned by Comodo)
(3) Network Solutions Certificate Authority (included, owned by Web.com)
(4) Network Solutions EV Server CA

... and the following certificates (in graphviz notation):

digraph {
1 -> 3;
2 -> 3;
3 -> 3;
3 -> 4;
}

And the question is who needs to disclose the (3->4) certificate.

FWIW Rob has exactly specified what I, as a relying party, would want
> Mozilla to do on my behalf although I would interpolate ("... and audited")
> each time he mentions disclosure.
>

This seems like a pretty sensible policy to me. One could consider it as
parallel to a hypothetical non-cross-signed scenario where the root relies
on the intermediate to disclose its subtree, then the root discloses the
intermediate.

> I agree with him that the current policy does not clearly state this.
>

The current policy has the blessing / curse of using the passive voice
("...MUST either be technically constrained or be publicly disclosed and
audited."), which obscures which agent must do the disclosing. But that
also means (ISTM) that Rob's suggested resolution is consistent with the
policy. As long as the subordinate below the cross-signed intermediate is
disclosed, it doesn't matter who disclosed it; but if it's not, then all
the cross-signers are out of compliance.

--Richard

[Peter Bowen]

On Fri, May 13, 2016 at 2:09 PM, Richard Barnes <rba...@mozilla.com> wrote:
> On Fri, May 13, 2016 at 10:48 PM, Nick Lamb <tiala...@gmail.com> wrote:
>
>> On Friday, 13 May 2016 21:02:25 UTC+1, Rob Stradling wrote:

>> > If it were up to me, I would...
>> > 1. Require https://crt.sh/?id=1790 to be disclosed precisely once, by
>> > Web.com, because the chain up to Web.com's Built-in Root is the shortest
>> > chain.
>> > 2. Hold both Web.com and Comodo equally to blame if
>> > https://crt.sh/?id=1790 is not disclosed. (The gives Comodo the
>> > incentive to ensure that Web.com do disclose it).
>>
>

> Thanks for explaining the specifics, Rob. To restate and check my
> understanding, this is a "Y-shaped" scenario, with the following CAs (by
> CN):
>
> (1) AddTrust External CA Root (included, owned by Comodo)
> (2) UTN-USERFirst-Hardware (included, owned by Comodo)
> (3) Network Solutions Certificate Authority (included, owned by Web.com)
> (4) Network Solutions EV Server CA
>
> ... and the following certificates (in graphviz notation):
>
> digraph {
> 1 -> 3;
> 2 -> 3;
> 3 -> 3;
> 3 -> 4;
> }
>
> And the question is who needs to disclose the (3->4) certificate.

There are two more variants of this:

Variant B: Where (1) and (2) are owned by different companies

Variant C: Where (1) and (2) are owned by different companies and (3)
is not included in the root list

>
> FWIW Rob has exactly specified what I, as a relying party, would want
>> Mozilla to do on my behalf although I would interpolate ("... and audited")
>> each time he mentions disclosure.
>>
>
> This seems like a pretty sensible policy to me. One could consider it as
> parallel to a hypothetical non-cross-signed scenario where the root relies
> on the intermediate to disclose its subtree, then the root discloses the
> intermediate.
>
>
>> I agree with him that the current policy does not clearly state this.
>>
>
> The current policy has the blessing / curse of using the passive voice
> ("...MUST either be technically constrained or be publicly disclosed and
> audited."), which obscures which agent must do the disclosing. But that
> also means (ISTM) that Rob's suggested resolution is consistent with the
> policy. As long as the subordinate below the cross-signed intermediate is
> disclosed, it doesn't matter who disclosed it; but if it's not, then all
> the cross-signers are out of compliance.

In the scenario where the only chain to 4 is from 3 and 3 is in the
root list, I would only hold 3 responsible. However 1 and 2 become
responsible if 3 is ever removed from the trust store, so they should
be prepared to take on that at any time.

Thanks,
Peter

[Rob Stradling]

On 13/05/16 22:09, Richard Barnes wrote:
<snip>

> Thanks for explaining the specifics, Rob. To restate and check my
> understanding, this is a "Y-shaped" scenario, with the following CAs (by
> CN):
>
> (1) AddTrust External CA Root (included, owned by Comodo)
> (2) UTN-USERFirst-Hardware (included, owned by Comodo)
> (3) Network Solutions Certificate Authority (included, owned by Web.com)
> (4) Network Solutions EV Server CA
>
> ... and the following certificates (in graphviz notation):
>
> digraph {
> 1 -> 3;
> 2 -> 3;
> 3 -> 3;
> 3 -> 4;
> }
>
> And the question is who needs to disclose the (3->4) certificate.

Yes, that's my question.

> FWIW Rob has exactly specified what I, as a relying party, would want
>> Mozilla to do on my behalf although I would interpolate ("... and audited")
>> each time he mentions disclosure.
>>
>
> This seems like a pretty sensible policy to me. One could consider it as
> parallel to a hypothetical non-cross-signed scenario where the root relies
> on the intermediate to disclose its subtree, then the root discloses the
> intermediate.
>
>
>> I agree with him that the current policy does not clearly state this.
>>
>
> The current policy has the blessing / curse of using the passive voice
> ("...MUST either be technically constrained or be publicly disclosed and
> audited."), which obscures which agent must do the disclosing. But that
> also means (ISTM) that Rob's suggested resolution is consistent with the
> policy. As long as the subordinate below the cross-signed intermediate is
> disclosed, it doesn't matter who disclosed it; but if it's not, then all
> the cross-signers are out of compliance.

I agree that my suggested resolution is consistent with the Mozilla CA
Policy.

However, it seems to be inconsistent with what Mozilla's recent CA
Communication requires CAs to do by the end of June (emphasis mine):

"ACTION #2: Beginning with Version 2.1 of Mozilla's CA Certificate
Policy, for any certificate which directly or transitively chains to the
root certificates you currently have included in Mozilla's CA
Certificate Program, which are capable of being used to issue new
certificates, and which are not technically constrained as described in

Section 9 of Mozilla's CA Certificate Inclusion Policy, *you are
required* to provide public-facing documentation about the certificate

verification requirements and annual public attestation of conformance

to said requirements. *This includes certificates owned by, operated by,

or issued by third parties, whether or not those issuing certificates
are already part of Mozilla's CA Certificate Program, if they have been
cross-signed by a certificate that directly or transitively chains to

your root certificate.*
To facilitate this public disclosure, Mozilla is requiring that these
certificates, as well as their CP/CPS and audit statements, be entered
into Mozilla's CA Community in Salesforce."

I see that Kathleen has added the following text to
https://wiki.mozilla.org/CA:CertificatePolicyV2.3#Proposed_Changes_Currently_in_Discussion
"Update transitive disclosure policy to reduce duplication of full CA
hierarchies
Update section 8 of Mozilla's CA Certificate Inclusion policy to say
that transitive disclosure is not required when the subject of the
CA-certificate is also the subject of a certificate included directly in
the Mozilla trust store."

However, ISTM that a "proposed change currently in discussion" is less
authoritative than the CA Communication (which, as I've said, seems to
explicitly require multiple disclosures of the same intermediate when
multiple trust paths exist).

Assuming everyone's happy with my suggested resolution, please would you
update the requirements for "ACTION #2" before the end of June (the
earlier the better!) so that multiple disclosures are not required?

[Kathleen Wilson]

On Monday, May 16, 2016 at 1:33:40 PM UTC-7, Rob Stradling wrote:
> However, ISTM that a "proposed change currently in discussion" is less
> authoritative than the CA Communication (which, as I've said, seems to
> explicitly require multiple disclosures of the same intermediate when
> multiple trust paths exist).
>
> Assuming everyone's happy with my suggested resolution, please would you
> update the requirements for "ACTION #2" before the end of June (the
> earlier the better!) so that multiple disclosures are not required?

It's too late to update the CA Communication itself, so I will provide the update here.


Proposed by Rob:

1. Require https://crt.sh/?id=1790 to be disclosed precisely once, by
Web.com, because the chain up to Web.com's Built-in Root is the shortest
chain.
2. Hold both Web.com and Comodo equally to blame if
https://crt.sh/?id=1790 is not disclosed. (The gives Comodo the
incentive to ensure that Web.com do disclose it).

I agree with this proposal, but will try to clarify a bit more...
For root certificate A that is cross-signed by another included root certificate B (that has the Websites trust bit enabled), the intermediate certificates chaining up to A only need to be disclosed once.
The cross-certificates for root certificate A must be entered into Salesforce, chaining to root certificate B.
If root certificate A is included and has the Websites trust bit enabled, then its intermediate certificates should be entered into Salesforce such that they chain directly to root certificate A.
If root certificate A has been removed from NSS or does not have the Websites trust bit enabled, then its intermediate certificates must be entered into Salesforce such that they chain to root certificate B.


Thanks,
Kathleen

[Rob Stradling]

On 19/05/16 21:48, Kathleen Wilson wrote:
> On Monday, May 16, 2016 at 1:33:40 PM UTC-7, Rob Stradling wrote:

>> However, ISTM that a "proposed change currently in discussion" is less
>> authoritative than the CA Communication (which, as I've said, seems to
>> explicitly require multiple disclosures of the same intermediate when
>> multiple trust paths exist).
>>
>> Assuming everyone's happy with my suggested resolution, please would you
>> update the requirements for "ACTION #2" before the end of June (the
>> earlier the better!) so that multiple disclosures are not required?
>
>

> It's too late to update the CA Communication itself, so I will provide the update here.
>
>
> Proposed by Rob:

> 1. Require https://crt.sh/?id=1790 to be disclosed precisely once, by
> Web.com, because the chain up to Web.com's Built-in Root is the shortest
> chain.
> 2. Hold both Web.com and Comodo equally to blame if
> https://crt.sh/?id=1790 is not disclosed. (The gives Comodo the
> incentive to ensure that Web.com do disclose it).
>

> I agree with this proposal, but will try to clarify a bit more...
> For root certificate A that is cross-signed by another included root certificate B (that has the Websites trust bit enabled), the intermediate certificates chaining up to A only need to be disclosed once.
> The cross-certificates for root certificate A must be entered into Salesforce, chaining to root certificate B.
> If root certificate A is included and has the Websites trust bit enabled, then its intermediate certificates should be entered into Salesforce such that they chain directly to root certificate A.
> If root certificate A has been removed from NSS or does not have the Websites trust bit enabled, then its intermediate certificates must be entered into Salesforce such that they chain to root certificate B.

Great. That's completely clear. Thanks Kathleen.

[Kathleen Wilson]

I added text about this to the wiki page:
https://wiki.mozilla.org/CA:SalesforceCommunity#Which_intermediate_certificate_data_should_CAs_add_to_Salesforce.3F

Thanks,
Kathleen