Policy revision proposal - transitive disclosure exception

[Peter Bowen]

The Mozilla CA Certificate policy says, in part:

"8. All certificates that are capable of being used to issue new
certificates, and which directly or transitively chain to a
certificate included in Mozilla’s CA Certificate Program, MUST be
operated in accordance with Mozilla’s CA Certificate Policy and MUST
either be technically constrained or be publicly disclosed and
audited.

* A certificate is deemed as capable of being used to issue new
certificates if it contains an X.509v3 basicConstraints extension,
with the cA boolean set to true.
* These requirements include all cross-certified certificates which
chain to a certificate that is included in Mozilla’s CA Certificate
Program."

I would propose that transitive disclosure not be required when the
subject of the CA-certificate is also the subject of a certificate
included directly in the Mozilla trust store.

This will not change the total set of certificates disclosed, rather
just limit duplicate disclosure. It also ensures that the program
member who most closely controls or is responsible for the transitive
certificates is handling the disclosure, which should help assure
accuracy of the disclosures.

However, to be clear, in the event that a CA not in the Mozilla trust
store is cross-certified by two different program members, both are
still responsible for full disclosure of all transitive certificates.
This is due to the fact that each member is equally responsible;
revocation of a cross-certificate issued by one member does not impact
the cross-certificate issued by the other member.

I think that this should be adopted for policy version 2.3.

Thanks,
Peter

[Kathleen Wilson]

On 2/6/16 11:45 AM, Peter Bowen wrote:
> The Mozilla CA Certificate policy says, in part:
>
> "8. All certificates that are capable of being used to issue new
> certificates, and which directly or transitively chain to a
> certificate included in Mozilla’s CA Certificate Program, MUST be
> operated in accordance with Mozilla’s CA Certificate Policy and MUST
> either be technically constrained or be publicly disclosed and
> audited.
>
> * A certificate is deemed as capable of being used to issue new
> certificates if it contains an X.509v3 basicConstraints extension,
> with the cA boolean set to true.
> * These requirements include all cross-certified certificates which
> chain to a certificate that is included in Mozilla’s CA Certificate
> Program."
>
> I would propose that transitive disclosure not be required when the
> subject of the CA-certificate is also the subject of a certificate
> included directly in the Mozilla trust store.
>

I think we want such relationships to be clearly disclosed. In the
future, in the case that there is an incident that requires blocking a
particular CA-certificate, we would be able to use Salesforce to find
all the relationships with other CA-Certificates in the program.

Kathleen

[Peter Bowen]

On Mon, Feb 8, 2016 at 11:29 AM, Kathleen Wilson <kwi...@mozilla.com> wrote:
> On 2/6/16 11:45 AM, Peter Bowen wrote:
>>

>> The Mozilla CA Certificate policy says, in part:
>>
>> "8. All certificates that are capable of being used to issue new
>> certificates, and which directly or transitively chain to a
>> certificate included in Mozilla’s CA Certificate Program, MUST be
>> operated in accordance with Mozilla’s CA Certificate Policy and MUST
>> either be technically constrained or be publicly disclosed and
>> audited.
>>
>> * A certificate is deemed as capable of being used to issue new
>> certificates if it contains an X.509v3 basicConstraints extension,
>> with the cA boolean set to true.
>> * These requirements include all cross-certified certificates which
>> chain to a certificate that is included in Mozilla’s CA Certificate
>> Program."
>>
>> I would propose that transitive disclosure not be required when the
>> subject of the CA-certificate is also the subject of a certificate
>> included directly in the Mozilla trust store.
>>
>
>

> I think we want such relationships to be clearly disclosed. In the future,
> in the case that there is an incident that requires blocking a particular
> CA-certificate, we would be able to use Salesforce to find all the
> relationships with other CA-Certificates in the program.

I'm not proposing that they not be disclosed. Consider this situation:

Example Corp Root CA is in the Mozilla trust store.
Contoso Corp Root CA is in the Mozilla trust store.

Example has two subordinates: Example Server CA and Example Client CA.
Contoso has two subordinates: Contoso CA - S1A and Contoso CA - C1B.
Example issues a cross certificate signed by Example Corp Root CA to
Contoso Corp Root CA.

I'm proposing that Example has to disclose the Example Server CA,
Example Client CA, and Contoso Corp Root CA certificates. Contoso has
to disclose the Contoso CA - S1A and Contoso CA - C1B certificates.
However Example would not have to separately disclose the Contoso CA -
S1A and C1B certificates, even though they transitively chain to the
Example Root.

Everything would be in Salesforce, but only one CA would be managing
it Salesforce, rather that having two CAs separately report the same
information.

Thanks,
Peter