info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Policy 2.7.1: MRSP Issue #186: Requirement to Disclose Self-signed Certificates
531 views
Skip to first unread message
Ben Wilson
Oct 28, 2020, 8:25:50 PM10/28/20
to mozilla-dev-security-policy
Issue #186 in Github <https://github.com/mozilla/pkipolicy/issues/186>
deals with the disclosure of CA certificates that directly or transitively
chain up to an already-trusted, Mozilla-included root. A common scenario
for the situation discussed in Issue #186 is when a CA creates a second (or
third or fourth) root certificate with the same key pair as the root that
is already in the Mozilla Root Store. This problem exists at the
intermediate-CA-certificate level, too, where a self-signed
intermediate/subordinate CA certificate is created and not reported.
Public disclosure of such certificates is already required by section 5.3
of the MRSP, which reads, "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 this policy and MUST either be technically constrained
or be publicly disclosed and audited."
There have been several instances where a CA operator has not disclosed a
CA certificate under the erroneous belief that because it is self-signed it
cannot be trusted in a certificate chain beneath the already-trusted,
Mozilla-included CA. This erroneous assumption is further discussed in Issue
#186 <https://github.com/mozilla/pkipolicy/issues/186>.
The third paragraph of MRSP section 5.3 currently reads, " These
requirements include all cross-certificates which chain to a certificate
that is included in Mozilla’s CA Certificate Program."
I recommend that we change that paragraph to read as follows:
"These requirements include all cross-certificates *and self-signed
certificates (e.g. "Issuer" DN is equivalent to "Subject" DN and public key
is signed by the private key) that* chain to a CA certificate that is
included in Mozilla’s CA Certificate Program*, and CAs must disclose such
CA certificates in the CCADB*.
I welcome your recommendations on how we can make this language even more
clear.
Thanks,
Ben
deals with the disclosure of CA certificates that directly or transitively
chain up to an already-trusted, Mozilla-included root. A common scenario
for the situation discussed in Issue #186 is when a CA creates a second (or
third or fourth) root certificate with the same key pair as the root that
is already in the Mozilla Root Store. This problem exists at the
intermediate-CA-certificate level, too, where a self-signed
intermediate/subordinate CA certificate is created and not reported.
Public disclosure of such certificates is already required by section 5.3
of the MRSP, which reads, "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 this policy and MUST either be technically constrained
or be publicly disclosed and audited."
There have been several instances where a CA operator has not disclosed a
CA certificate under the erroneous belief that because it is self-signed it
cannot be trusted in a certificate chain beneath the already-trusted,
Mozilla-included CA. This erroneous assumption is further discussed in Issue
#186 <https://github.com/mozilla/pkipolicy/issues/186>.
The third paragraph of MRSP section 5.3 currently reads, " These
requirements include all cross-certificates which chain to a certificate
that is included in Mozilla’s CA Certificate Program."
I recommend that we change that paragraph to read as follows:
"These requirements include all cross-certificates *and self-signed
certificates (e.g. "Issuer" DN is equivalent to "Subject" DN and public key
is signed by the private key) that* chain to a CA certificate that is
included in Mozilla’s CA Certificate Program*, and CAs must disclose such
CA certificates in the CCADB*.
I welcome your recommendations on how we can make this language even more
clear.
Thanks,
Ben
Jakob Bohm
Oct 29, 2020, 10:57:49 AM10/29/20
to mozilla-dev-s...@lists.mozilla.org
private/public key pairs as certificates already included in the
requirements." (this covers the situation you mentioned where a
self-signed certificate shares the key pair of a certificate that chains
to an included root).
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
Rob Stradling
Oct 30, 2020, 11:29:21 AM10/30/20
to mozilla-dev-s...@lists.mozilla.org, Jakob Bohm
> Perhaps add: "And also include any other certificates sharing the same
> private/public key pairs as certificates already included in the
> requirements." (this covers the situation you mentioned where a
> self-signed certificate shares the key pair of a certificate that chains
> to an included root).
Jakob,
> private/public key pairs as certificates already included in the
> requirements." (this covers the situation you mentioned where a
> self-signed certificate shares the key pair of a certificate that chains
> to an included root).
I agree that that would cover that situation, but your proposed language goes way, way too far.
Any private CA could cross-certify a publicly-trusted root CA. How would the publicly-trusted CA Operator discover such a cross-certificate? Why would such a cross-certificate be of interest to Mozilla anyway? Would it really be fair for non-disclosure of such a cross-certificate to be considered a policy violation?
________________________________
From: dev-security-policy <dev-security-...@lists.mozilla.org> on behalf of Jakob Bohm via dev-security-policy <dev-secur...@lists.mozilla.org>
Sent: 29 October 2020 14:57
To: mozilla-dev-s...@lists.mozilla.org <mozilla-dev-s...@lists.mozilla.org>
Subject: Re: Policy 2.7.1: MRSP Issue #186: Requirement to Disclose Self-signed Certificates
CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
On 2020-10-29 01:25, Ben Wilson wrote:
> deals with the disclosure of CA certificates that directly or transitively
> chain up to an already-trusted, Mozilla-included root. A common scenario
> for the situation discussed in Issue #186 is when a CA creates a second (or
> third or fourth) root certificate with the same key pair as the root that
> is already in the Mozilla Root Store. This problem exists at the
> intermediate-CA-certificate level, too, where a self-signed
> intermediate/subordinate CA certificate is created and not reported.
>
> Public disclosure of such certificates is already required by section 5.3
> of the MRSP, which reads, "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 this policy and MUST either be technically constrained
> or be publicly disclosed and audited."
>
> There have been several instances where a CA operator has not disclosed a
> CA certificate under the erroneous belief that because it is self-signed it
> cannot be trusted in a certificate chain beneath the already-trusted,
> Mozilla-included CA. This erroneous assumption is further discussed in Issue
> #186 <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmozilla%2Fpkipolicy%2Fissues%2F186&data=04%7C01%7Crob%40sectigo.com%7C3bdb53393f1f4056b59e08d87c1aff51%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637395802683146795%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=ux32CpUMi7X31uD0W%2BsLV%2Bpgrv3lHgCbdZ%2BhVj2UlbA%3D&reserved=0>.
> chain up to an already-trusted, Mozilla-included root. A common scenario
> for the situation discussed in Issue #186 is when a CA creates a second (or
> third or fourth) root certificate with the same key pair as the root that
> is already in the Mozilla Root Store. This problem exists at the
> intermediate-CA-certificate level, too, where a self-signed
> intermediate/subordinate CA certificate is created and not reported.
>
> Public disclosure of such certificates is already required by section 5.3
> of the MRSP, which reads, "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 this policy and MUST either be technically constrained
> or be publicly disclosed and audited."
>
> There have been several instances where a CA operator has not disclosed a
> CA certificate under the erroneous belief that because it is self-signed it
> cannot be trusted in a certificate chain beneath the already-trusted,
> Mozilla-included CA. This erroneous assumption is further discussed in Issue
>
> The third paragraph of MRSP section 5.3 currently reads, " These
> requirements include all cross-certificates which chain to a certificate
> that is included in Mozilla’s CA Certificate Program."
>
> I recommend that we change that paragraph to read as follows:
>
> "These requirements include all cross-certificates *and self-signed
> certificates (e.g. "Issuer" DN is equivalent to "Subject" DN and public key
> is signed by the private key) that* chain to a CA certificate that is
> included in Mozilla’s CA Certificate Program*, and CAs must disclose such
> CA certificates in the CCADB*.
>
> I welcome your recommendations on how we can make this language even more
> clear.
>
> The third paragraph of MRSP section 5.3 currently reads, " These
> requirements include all cross-certificates which chain to a certificate
> that is included in Mozilla’s CA Certificate Program."
>
> I recommend that we change that paragraph to read as follows:
>
> "These requirements include all cross-certificates *and self-signed
> certificates (e.g. "Issuer" DN is equivalent to "Subject" DN and public key
> is signed by the private key) that* chain to a CA certificate that is
> included in Mozilla’s CA Certificate Program*, and CAs must disclose such
> CA certificates in the CCADB*.
>
> I welcome your recommendations on how we can make this language even more
> clear.
>
Perhaps add: "And also include any other certificates sharing the same
private/public key pairs as certificates already included in the
requirements." (this covers the situation you mentioned where a
self-signed certificate shares the key pair of a certificate that chains
to an included root).
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.wisemo.com%2F&data=04%7C01%7Crob%40sectigo.com%7C3bdb53393f1f4056b59e08d87c1aff51%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637395802683146795%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=sJ1Ar%2BE7qnVvPTdqdGEIKj25tRlyDLX%2F2sbqj4v9%2BlY%3D&reserved=0
private/public key pairs as certificates already included in the
requirements." (this covers the situation you mentioned where a
self-signed certificate shares the key pair of a certificate that chains
to an included root).
Enjoy
Jakob
--
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
_______________________________________________
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
dev-security-policy mailing list
dev-secur...@lists.mozilla.org
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.mozilla.org%2Flistinfo%2Fdev-security-policy&data=04%7C01%7Crob%40sectigo.com%7C3bdb53393f1f4056b59e08d87c1aff51%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637395802683156751%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=MFMGD3gQ%2FvhSkbR1jy4GcefGzJHIaWt02bR1Pq6V%2BKk%3D&reserved=0
Jakob Bohm
Oct 30, 2020, 12:38:39 PM10/30/20
to mozilla-dev-s...@lists.mozilla.org
On 2020-10-30 16:29, Rob Stradling wrote:
>> Perhaps add: "And also include any other certificates sharing the same
>> private/public key pairs as certificates already included in the
>> requirements." (this covers the situation you mentioned where a
>> self-signed certificate shares the key pair of a certificate that chains
>> to an included root).
>
> Jakob,
>
> I agree that that would cover that situation, but your proposed language goes way, way too far.
>
> Any private CA could cross-certify a publicly-trusted root CA. How would the publicly-trusted CA Operator discover such a cross-certificate? Why would such a cross-certificate be of interest to Mozilla anyway? Would it really be fair for non-disclosure of such a cross-certificate to be considered a policy violation?
How would my wording include that converse situation (a CA not subject
>> Perhaps add: "And also include any other certificates sharing the same
>> private/public key pairs as certificates already included in the
>> requirements." (this covers the situation you mentioned where a
>> self-signed certificate shares the key pair of a certificate that chains
>> to an included root).
>
> Jakob,
>
> I agree that that would cover that situation, but your proposed language goes way, way too far.
>
> Any private CA could cross-certify a publicly-trusted root CA. How would the publicly-trusted CA Operator discover such a cross-certificate? Why would such a cross-certificate be of interest to Mozilla anyway? Would it really be fair for non-disclosure of such a cross-certificate to be considered a policy violation?
to the Mozilla policy using their own private key to cross sign a CA
subject to the Mozilla policy)?
I do notice though that my wording accidentally included the case where
the private key of an end-entity cert is used in as the key of a private
CA, because I wrote "as certificates" instead of "as CA certificates".
>
>> ________________________________
>> From: Jakob Bohm via dev-security-policy <dev-secur...@lists.mozilla.org>
>> Sent: 29 October 2020 14:57
>> To: mozilla-dev-s...@lists.mozilla.org <mozilla-dev-s...@lists.mozilla.org>
>> Subject: Re: Policy 2.7.1: MRSP Issue #186: Requirement to Disclose Self-signed Certificates
>>
>>
>> To: mozilla-dev-s...@lists.mozilla.org <mozilla-dev-s...@lists.mozilla.org>
>> Subject: Re: Policy 2.7.1: MRSP Issue #186: Requirement to Disclose Self-signed Certificates
>>
>>
>> On 2020-10-29 01:25, Ben Wilson wrote:
>>> Issue #186 in Github <https://github.com/mozilla/pkipolicy/issues/186&data=04>
>>> deals with the disclosure of CA certificates that directly or transitively
>>> chain up to an already-trusted, Mozilla-included root. A common scenario
>>> for the situation discussed in Issue #186 is when a CA creates a second (or
>>> third or fourth) root certificate with the same key pair as the root that
>>> is already in the Mozilla Root Store. This problem exists at the
>>> intermediate-CA-certificate level, too, where a self-signed
>>> intermediate/subordinate CA certificate is created and not reported.
>>>
>>> Public disclosure of such certificates is already required by section 5.3
>>> of the MRSP, which reads, "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 this policy and MUST either be technically constrained
>>> or be publicly disclosed and audited."
>>>
>>> There have been several instances where a CA operator has not disclosed a
>>> CA certificate under the erroneous belief that because it is self-signed it
>>> cannot be trusted in a certificate chain beneath the already-trusted,
>>> Mozilla-included CA. This erroneous assumption is further discussed in Issue
>>> #186 <https://github.com/mozilla/pkipolicy/issues/186&data=04 >.
>>> chain up to an already-trusted, Mozilla-included root. A common scenario
>>> for the situation discussed in Issue #186 is when a CA creates a second (or
>>> third or fourth) root certificate with the same key pair as the root that
>>> is already in the Mozilla Root Store. This problem exists at the
>>> intermediate-CA-certificate level, too, where a self-signed
>>> intermediate/subordinate CA certificate is created and not reported.
>>>
>>> Public disclosure of such certificates is already required by section 5.3
>>> of the MRSP, which reads, "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 this policy and MUST either be technically constrained
>>> or be publicly disclosed and audited."
>>>
>>> There have been several instances where a CA operator has not disclosed a
>>> CA certificate under the erroneous belief that because it is self-signed it
>>> cannot be trusted in a certificate chain beneath the already-trusted,
>>> Mozilla-included CA. This erroneous assumption is further discussed in Issue
>>>
>>> The third paragraph of MRSP section 5.3 currently reads, " These
>>> requirements include all cross-certificates which chain to a certificate
>>> that is included in Mozilla’s CA Certificate Program."
>>>
>>> I recommend that we change that paragraph to read as follows:
>>>
>>> "These requirements include all cross-certificates *and self-signed
>>> certificates (e.g. "Issuer" DN is equivalent to "Subject" DN and public key
>>> is signed by the private key) that* chain to a CA certificate that is
>>> included in Mozilla’s CA Certificate Program*, and CAs must disclose such
>>> CA certificates in the CCADB*.
>>>
>>> I welcome your recommendations on how we can make this language even more
>>> clear.
>>>
>>
>> Perhaps add: "And also include any other certificates sharing the same
>> private/public key pairs as certificates already included in the
>> requirements." (this covers the situation you mentioned where a
>> self-signed certificate shares the key pair of a certificate that chains
>> to an included root).
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
>>> The third paragraph of MRSP section 5.3 currently reads, " These
>>> requirements include all cross-certificates which chain to a certificate
>>> that is included in Mozilla’s CA Certificate Program."
>>>
>>> I recommend that we change that paragraph to read as follows:
>>>
>>> "These requirements include all cross-certificates *and self-signed
>>> certificates (e.g. "Issuer" DN is equivalent to "Subject" DN and public key
>>> is signed by the private key) that* chain to a CA certificate that is
>>> included in Mozilla’s CA Certificate Program*, and CAs must disclose such
>>> CA certificates in the CCADB*.
>>>
>>> I welcome your recommendations on how we can make this language even more
>>> clear.
>>>
>>
>> Perhaps add: "And also include any other certificates sharing the same
>> private/public key pairs as certificates already included in the
>> requirements." (this covers the situation you mentioned where a
>> self-signed certificate shares the key pair of a certificate that chains
>> to an included root).
Enjoy
Jakob
--
Ryan Sleevi
Oct 30, 2020, 1:45:52 PM10/30/20
to Jakob Bohm, mozilla-dev-security-policy
On Fri, Oct 30, 2020 at 12:38 PM Jakob Bohm via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:
> On 2020-10-30 16:29, Rob Stradling wrote:
dev-secur...@lists.mozilla.org> wrote:
> On 2020-10-30 16:29, Rob Stradling wrote:
> >> Perhaps add: "And also include any other certificates sharing the same
> >> private/public key pairs as certificates already included in the
> >> requirements." (this covers the situation you mentioned where a
> >> self-signed certificate shares the key pair of a certificate that chains
> >> to an included root).
> >
> > Jakob,
> >
> > I agree that that would cover that situation, but your proposed language
> goes way, way too far.
> >
> > Any private CA could cross-certify a publicly-trusted root CA. How
> would the publicly-trusted CA Operator discover such a cross-certificate?
> Why would such a cross-certificate be of interest to Mozilla anyway? Would
> it really be fair for non-disclosure of such a cross-certificate to be
> considered a policy violation?
>
I agree with Rob that, while the intent is not inherently problematic, I
> >> private/public key pairs as certificates already included in the
> >> requirements." (this covers the situation you mentioned where a
> >> self-signed certificate shares the key pair of a certificate that chains
> >> to an included root).
> >
> > Jakob,
> >
> > I agree that that would cover that situation, but your proposed language
> goes way, way too far.
> >
> > Any private CA could cross-certify a publicly-trusted root CA. How
> would the publicly-trusted CA Operator discover such a cross-certificate?
> Why would such a cross-certificate be of interest to Mozilla anyway? Would
> it really be fair for non-disclosure of such a cross-certificate to be
> considered a policy violation?
>
think the language proposed by Jakob is problematic, and might not be
desirable.
> How would my wording include that converse situation (a CA not subject
> to the Mozilla policy using their own private key to cross sign a CA
> subject to the Mozilla policy)?
>
> I do notice though that my wording accidentally included the case where
> the private key of an end-entity cert is used in as the key of a private
> CA, because I wrote "as certificates" instead of "as CA certificates".
when coupled with "any other certificates". Rob's example here, of a
privately-signed cross-certificate *is* an "any other certificate", and the
CA who was cross-signed is a CA "already included in the requirements"
I think this intent to restate existing policy falls in the normal trap of
"trying to say the same thing two different ways in policy results in two
different interpretations / two different policies"
Taking a step back, this is the general problem with "Are CA
(Organizations) subject to audits/requirements, are CA Certificates, or are
private keys", and that's seen an incredible amount of useful discussion
here on m.d.s.p. that we don't and shouldn't relitigate here. I believe
your intent is "The CA (Organization) participating in the Mozilla Root
Store shall disclose every Certificate that shares a CA Key Pair with a CA
Certificate subject to these requirements", and that lands squarely on this
complex topic.
A different way to achieve your goal, and to slightly tweak Ben's proposal
(since it appears many CAs do not understand how RFC 5280 is specified) is
to take a slight reword:
"""
These requirements include all cross-certificates that chain to a CA
certificate that is included in Mozilla’s CA Certificate Program, as well
as all certificates (e.g. including self-signed certificates and non-CA
certificates) issued by the CA that share the same CA Key Pair. CAs must
disclose such certificates in the CCADB.
"""
However, this might be easier with a GitHub PR, as I think Wayne used to
do, to try to make sure the language is precise in context. It tries to
close the loophole Rob is pointing out about "who issued", while also
trying to address what you seem to be concerned about (re: key reuse). To
Ben's original challenge, it tries to avoid "chain to", since CAs
apparently are confused at how a self-signed certificate can chain to
another variation of that self-signed certificate (it's a valid path, it's
just a path that can be eliminated as a suboptimal path during chain
building)
Jakob Bohm
Nov 2, 2020, 10:33:15 AM11/2/20
to mozilla-dev-s...@lists.mozilla.org
On 2020-10-30 18:45, Ryan Sleevi wrote:
> On Fri, Oct 30, 2020 at 12:38 PM Jakob Bohm via dev-security-policy <
> dev-secur...@lists.mozilla.org> wrote:
>
>> On 2020-10-30 16:29, Rob Stradling wrote:
>>>> Perhaps add: "And also include any other certificates sharing the same
>>>> private/public key pairs as certificates already included in the
>>>> requirements." (this covers the situation you mentioned where a
>>>> self-signed certificate shares the key pair of a certificate that chains
>>>> to an included root).
>>>
Already rephrased to the following in my Friday post, as you actually
> On Fri, Oct 30, 2020 at 12:38 PM Jakob Bohm via dev-security-policy <
> dev-secur...@lists.mozilla.org> wrote:
>
>> On 2020-10-30 16:29, Rob Stradling wrote:
>>>> Perhaps add: "And also include any other certificates sharing the same
>>>> private/public key pairs as certificates already included in the
>>>> requirements." (this covers the situation you mentioned where a
>>>> self-signed certificate shares the key pair of a certificate that chains
>>>> to an included root).
>>>
quote below.
Perhaps add: "And also include any other certificates sharing the same
requirements." (this covers the situation Rob mentioned where a
self-signed certificate shares the key pair of a certificate that chains
to an included root).
>>> Jakob,
>>>
>>> I agree that that would cover that situation, but your proposed language
>> goes way, way too far.
>>>
>>> Any private CA could cross-certify a publicly-trusted root CA. How
>> would the publicly-trusted CA Operator discover such a cross-certificate?
>> Why would such a cross-certificate be of interest to Mozilla anyway? Would
>> it really be fair for non-disclosure of such a cross-certificate to be
>> considered a policy violation?
>>
>
> I agree with Rob that, while the intent is not inherently problematic, I
> think the language proposed by Jakob is problematic, and might not be
> desirable.
>
See above (and below) rephrasing to limit to reusing the private key
to an included root).
>>> Jakob,
>>>
>>> I agree that that would cover that situation, but your proposed language
>> goes way, way too far.
>>>
>>> Any private CA could cross-certify a publicly-trusted root CA. How
>> would the publicly-trusted CA Operator discover such a cross-certificate?
>> Why would such a cross-certificate be of interest to Mozilla anyway? Would
>> it really be fair for non-disclosure of such a cross-certificate to be
>> considered a policy violation?
>>
>
> I agree with Rob that, while the intent is not inherently problematic, I
> think the language proposed by Jakob is problematic, and might not be
> desirable.
>
from a CA certificate.
>
>> How would my wording include that converse situation (a CA not subject
>> to the Mozilla policy using their own private key to cross sign a CA
>> subject to the Mozilla policy)?
>>
>> I do notice though that my wording accidentally included the case where
>> the private key of an end-entity cert is used in as the key of a private
>> CA, because I wrote "as certificates" instead of "as CA certificates".
>
>
> Because "as certificates already included in the requirements" is ambiguous
> when coupled with "any other certificates". Rob's example here, of a
> privately-signed cross-certificate *is* an "any other certificate", and the
> CA who was cross-signed is a CA "already included in the requirements"
>
> I think this intent to restate existing policy falls in the normal trap of
> "trying to say the same thing two different ways in policy results in two
> different interpretations / two different policies"
>
> Taking a step back, this is the general problem with "Are CA
> (Organizations) subject to audits/requirements, are CA Certificates, or are
> private keys", and that's seen an incredible amount of useful discussion
> here on m.d.s.p. that we don't and shouldn't relitigate here. I believe
> your intent is "The CA (Organization) participating in the Mozilla Root
> Store shall disclose every Certificate that shares a CA Key Pair with a CA
> Certificate subject to these requirements", and that lands squarely on this
> complex topic.
>
avoid overbloating policy with wordy sentences like the one you just
used.
> A different way to achieve your goal, and to slightly tweak Ben's proposal
> (since it appears many CAs do not understand how RFC 5280 is specified) is
> to take a slight reword:
>
> """
> These requirements include all cross-certificates that chain to a CA
> certificate that is included in Mozilla’s CA Certificate Program, as well
> as all certificates (e.g. including self-signed certificates and non-CA
> certificates) issued by the CA that share the same CA Key Pair. CAs must
> disclose such certificates in the CCADB.
> """
>
trying to limit the scope to certificates generated by the
CA-organization, but as written it could be misconstrued as
"certificates issued by the CA certificate that share the same CA Key Pair".
Proposed better wording of your text:
These requirements include all cross-certificates that chain to a CA
certificate that is included in Mozilla's CA Certificate Program, as
non-CA certificates) created by the CA organization that share the same
CA Key Pair as any CA certificate or cross-certificate that chains to an
included CA certificate.
The intent of of my final words is to also cover reuse of keys belonging
to SubCA certificates.
> However, this might be easier with a GitHub PR, as I think Wayne used to
> do, to try to make sure the language is precise in context. It tries to
> close the loophole Rob is pointing out about "who issued", while also
> trying to address what you seem to be concerned about (re: key reuse). To
> Ben's original challenge, it tries to avoid "chain to", since CAs
> apparently are confused at how a self-signed certificate can chain to
> another variation of that self-signed certificate (it's a valid path, it's
> just a path that can be eliminated as a suboptimal path during chain
> building)
>
newsgroup/mailing-list, I will leave the incorporation of the final
wording into PR #186 to Ben.
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Corey Bonnell
Nov 2, 2020, 1:14:17 PM11/2/20
to mozilla-dev-s...@lists.mozilla.org
As an alternate proposal, I suggest replacing the third paragraph of section 5.3, which currently reads:
"These requirements include all cross-certificates which chain to a certificate that is included in Mozilla’s CA Certificate Program."
with:
"A certificate is considered to directly or transitively chain to a certificate included in Mozilla’s CA Certificate Program if there is a CA or Intermediate certificate in scope (as defined in section 1.1 of this Policy) where both of the following is true:
1) The certificate’s Issuer Distinguished Name matches (according to the name-matching algorithm specified in RFC 5280, section 7.1) the Subject Distinguished Name of the certificate in scope, and
2) The certificate is signed with a Private Key whose corresponding Public Key is encoded in the SubjectPublicKeyInfo of the certificate in scope."
This proposal better defines the meaning of chaining to certificates included in the Mozilla CA program and covers the various scenarios that have caused issues historically concerning cross-certificates and self-signed certificates.
Thanks,
Corey
"These requirements include all cross-certificates which chain to a certificate that is included in Mozilla’s CA Certificate Program."
"A certificate is considered to directly or transitively chain to a certificate included in Mozilla’s CA Certificate Program if there is a CA or Intermediate certificate in scope (as defined in section 1.1 of this Policy) where both of the following is true:
1) The certificate’s Issuer Distinguished Name matches (according to the name-matching algorithm specified in RFC 5280, section 7.1) the Subject Distinguished Name of the certificate in scope, and
2) The certificate is signed with a Private Key whose corresponding Public Key is encoded in the SubjectPublicKeyInfo of the certificate in scope."
This proposal better defines the meaning of chaining to certificates included in the Mozilla CA program and covers the various scenarios that have caused issues historically concerning cross-certificates and self-signed certificates.
Thanks,
Corey
Ben Wilson
Nov 11, 2020, 11:16:07 PM11/11/20
to Corey Bonnell, mozilla-dev-security-policy
Here is an attempt to address the comments received thus far. In Github,
here is a markup:
https://github.com/BenWilson-Mozilla/pkipolicy/commit/ee19ee89c6101c3a6943956b91574826e34c4932
This sentence would be deleted: "These requirements include all
"A certificate is deemed to directly or transitively chain to a CA
certificate included in Mozilla’s CA Certificate Program if:
(1) the certificate’s Issuer Distinguished Name matches (according to the
in scope according to section 1.1 of this Policy, and
(2) the certificate is signed with a Private Key whose corresponding
Public Key is encoded in the SubjectPublicKeyInfo of that CA certificate or
intermediate certificate.
Thus, these requirements also apply to so-called reissued/doppelganger CA
certificates (roots and intermediates) and to cross-certificates."
I think it is important not to lose sight of the main reason for this
proposed change-- there has been confusion about whether re-issued root CA
certificates need to be disclosed in the CCADB.
I look forward to your additional comments and suggestions.
Thank you,
Ben
On Mon, Nov 2, 2020 at 11:14 AM Corey Bonnell via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:
> As an alternate proposal, I suggest replacing the third paragraph of
> section 5.3, which currently reads:
>
>
here is a markup:
https://github.com/BenWilson-Mozilla/pkipolicy/commit/ee19ee89c6101c3a6943956b91574826e34c4932
This sentence would be deleted: "These requirements include all
cross-certificates which chain to a certificate that is included in
Mozilla’s CA Certificate Program."
And the following would be added:
Mozilla’s CA Certificate Program."
"A certificate is deemed to directly or transitively chain to a CA
certificate included in Mozilla’s CA Certificate Program if:
(1) the certificate’s Issuer Distinguished Name matches (according to the
name-matching algorithm specified in RFC 5280, section 7.1) the Subject
Distinguished Name in a CA certificate or intermediate certificate that is
in scope according to section 1.1 of this Policy, and
(2) the certificate is signed with a Private Key whose corresponding
Public Key is encoded in the SubjectPublicKeyInfo of that CA certificate or
intermediate certificate.
Thus, these requirements also apply to so-called reissued/doppelganger CA
certificates (roots and intermediates) and to cross-certificates."
I think it is important not to lose sight of the main reason for this
proposed change-- there has been confusion about whether re-issued root CA
certificates need to be disclosed in the CCADB.
I look forward to your additional comments and suggestions.
Thank you,
Ben
On Mon, Nov 2, 2020 at 11:14 AM Corey Bonnell via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:
> As an alternate proposal, I suggest replacing the third paragraph of
> section 5.3, which currently reads:
>
> "These requirements include all cross-certificates which chain to a
> certificate that is included in Mozilla’s CA Certificate Program."
>
> certificate that is included in Mozilla’s CA Certificate Program."
>
> with:
>
> "A certificate is considered to directly or transitively chain to a
> certificate included in Mozilla’s CA Certificate Program if there is a CA
> or Intermediate certificate in scope (as defined in section 1.1 of this
> Policy) where both of the following is true:
> 1) The certificate’s Issuer Distinguished Name matches (according to
> the name-matching algorithm specified in RFC 5280, section 7.1) the Subject
> Distinguished Name of the certificate in scope, and
> 2) The certificate is signed with a Private Key whose corresponding
> Public Key is encoded in the SubjectPublicKeyInfo of the certificate in
> scope."
>
> This proposal better defines the meaning of chaining to certificates
> included in the Mozilla CA program and covers the various scenarios that
> have caused issues historically concerning cross-certificates and
> self-signed certificates.
>
> Thanks,
> Corey
>
> On Wednesday, October 28, 2020 at 8:25:50 PM UTC-4, Ben Wilson wrote:
>
> "A certificate is considered to directly or transitively chain to a
> certificate included in Mozilla’s CA Certificate Program if there is a CA
> or Intermediate certificate in scope (as defined in section 1.1 of this
> Policy) where both of the following is true:
> 1) The certificate’s Issuer Distinguished Name matches (according to
> the name-matching algorithm specified in RFC 5280, section 7.1) the Subject
> Distinguished Name of the certificate in scope, and
> 2) The certificate is signed with a Private Key whose corresponding
> Public Key is encoded in the SubjectPublicKeyInfo of the certificate in
> scope."
>
> This proposal better defines the meaning of chaining to certificates
> included in the Mozilla CA program and covers the various scenarios that
> have caused issues historically concerning cross-certificates and
> self-signed certificates.
>
> Thanks,
> Corey
>
> On Wednesday, October 28, 2020 at 8:25:50 PM UTC-4, Ben Wilson wrote:
> _______________________________________________
> 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
>
Jakob Bohm
Nov 12, 2020, 12:39:49 PM11/12/20
to mozilla-dev-s...@lists.mozilla.org
an included root CA?
Ben Wilson
Nov 12, 2020, 1:54:50 PM11/12/20
to Jakob Bohm, mozilla-dev-security-policy
Jakob,
On Thu, Nov 12, 2020 at 10:39 AM Jakob Bohm via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:
>
> How would that phrasing cover doppelgangers of intermediary SubCAs under
> an included root CA?
>
>
> To clarify, the title of section 5.3 is "Intermediate Certificates".
Also, both subsection (1) and (2) under the proposed amendment reference
"intermediate certificates" - "(1) ...the Subject Distinguished Name in a
CA certificate or *intermediate certificate* that is in scope according to
section 1.1 of this Policy" and "(2)... corresponding Public Key is encoded
in the SubjectPublicKeyInfo of that CA certificate or *intermediate
certificate*." And finally, additional
language would try and make this clear by saying, "Thus, these requirements
also apply to so-called reissued/doppelganger CA certificates (roots *and
intermediates*) and to cross-certificates."
I hope this answers your question.
Sincerely,
Ben
On Thu, Nov 12, 2020 at 10:39 AM Jakob Bohm via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:
>
> How would that phrasing cover doppelgangers of intermediary SubCAs under
> an included root CA?
>
>
Also, both subsection (1) and (2) under the proposed amendment reference
"intermediate certificates" - "(1) ...the Subject Distinguished Name in a
CA certificate or *intermediate certificate* that is in scope according to
section 1.1 of this Policy" and "(2)... corresponding Public Key is encoded
in the SubjectPublicKeyInfo of that CA certificate or *intermediate
certificate*." And finally, additional
language would try and make this clear by saying, "Thus, these requirements
also apply to so-called reissued/doppelganger CA certificates (roots *and
intermediates*) and to cross-certificates."
I hope this answers your question.
Sincerely,
Ben
Ben Wilson
Jan 24, 2021, 5:13:09 PM1/24/21
to mozilla-dev-security-policy
As an alternative for this addition to MRSP section 5.3, please consider
and comment on:
Thus, the operator of a CA certificate trusted in Mozilla’s CA Certificate
Program MUST disclose in the CCADB all non-technically constrained CA
certificates they issue that chain up to that CA certificate trusted in
Mozilla’s CA Certificate Program. This applies to all non-technically
constrained CA certificates, including those that are self-signed,
doppelgänger, reissued, or cross-signed.
On Thu, Nov 12, 2020 at 11:54 AM Ben Wilson <bwi...@mozilla.com> wrote:
> Jakob,
>
> On Thu, Nov 12, 2020 at 10:39 AM Jakob Bohm via dev-security-policy <
> dev-secur...@lists.mozilla.org> wrote:
>
>>
>> How would that phrasing cover doppelgangers of intermediary SubCAs under
>> an included root CA?
>>
>>
>> To clarify, the title of section 5.3 is "Intermediate Certificates".
> Also, both subsection (1) and (2) under the proposed amendment reference
> "intermediate certificates" - "(1) ...the Subject Distinguished Name in a
> CA certificate or *intermediate certificate* that is in scope according
> to section 1.1 of this Policy" and "(2)... corresponding Public Key is
> encoded in the SubjectPublicKeyInfo of that CA certificate or *intermediate
> certificate*." And finally, additional
> language would try and make this clear by saying, "Thus, these
and comment on:
Thus, the operator of a CA certificate trusted in Mozilla’s CA Certificate
Program MUST disclose in the CCADB all non-technically constrained CA
certificates they issue that chain up to that CA certificate trusted in
Mozilla’s CA Certificate Program. This applies to all non-technically
constrained CA certificates, including those that are self-signed,
doppelgänger, reissued, or cross-signed.
On Thu, Nov 12, 2020 at 11:54 AM Ben Wilson <bwi...@mozilla.com> wrote:
> Jakob,
>
> On Thu, Nov 12, 2020 at 10:39 AM Jakob Bohm via dev-security-policy <
> dev-secur...@lists.mozilla.org> wrote:
>
>>
>> How would that phrasing cover doppelgangers of intermediary SubCAs under
>> an included root CA?
>>
>>
>> To clarify, the title of section 5.3 is "Intermediate Certificates".
> Also, both subsection (1) and (2) under the proposed amendment reference
> "intermediate certificates" - "(1) ...the Subject Distinguished Name in a
> CA certificate or *intermediate certificate* that is in scope according
> to section 1.1 of this Policy" and "(2)... corresponding Public Key is
> encoded in the SubjectPublicKeyInfo of that CA certificate or *intermediate
> certificate*." And finally, additional
> requirements also apply to so-called reissued/doppelganger CA certificates
Ben Wilson
Feb 10, 2021, 3:28:39 PM2/10/21
to mozilla-dev-security-policy
In the Github document, which I'm using to track proposed language, I've
added "This applies to all non-technically constrained CA certificates,
including those that share the same key pair whether they are self-signed,
doppelgänger, reissued, cross-signed, or other roots."
https://github.com/BenWilson-Mozilla/pkipolicy/commit/5a3dd2e9d92ec689e08bf1cfa279121e2bb0478b
.
On Sun, Jan 24, 2021 at 3:12 PM Ben Wilson <bwi...@mozilla.com> wrote:
> As an alternative for this addition to MRSP section 5.3, please consider
> and comment on:
>
> Thus, the operator of a CA certificate trusted in Mozilla’s CA Certificate
> Program MUST disclose in the CCADB all non-technically constrained CA
> certificates they issue that chain up to that CA certificate trusted in
> Mozilla’s CA Certificate Program. This applies to all non-technically
> constrained CA certificates, including those that are self-signed,
> doppelgänger, reissued, or cross-signed.
>
>
> On Thu, Nov 12, 2020 at 11:54 AM Ben Wilson <bwi...@mozilla.com> wrote:
>
>> Jakob,
>>
>> On Thu, Nov 12, 2020 at 10:39 AM Jakob Bohm via dev-security-policy <
>> dev-secur...@lists.mozilla.org> wrote:
>>
>>>
>>> How would that phrasing cover doppelgangers of intermediary SubCAs under
>>> an included root CA?
>>>
>>>
>>> To clarify, the title of section 5.3 is "Intermediate Certificates".
>> Also, both subsection (1) and (2) under the proposed amendment reference
>> "intermediate certificates" - "(1) ...the Subject Distinguished Name in a
>> CA certificate or *intermediate certificate* that is in scope according
>> to section 1.1 of this Policy" and "(2)... corresponding Public Key is
>> encoded in the SubjectPublicKeyInfo of that CA certificate or *intermediate
>> certificate*." And finally, additional
>> language would try and make this clear by saying, "Thus, these
added "This applies to all non-technically constrained CA certificates,
including those that share the same key pair whether they are self-signed,
doppelgänger, reissued, cross-signed, or other roots."
https://github.com/BenWilson-Mozilla/pkipolicy/commit/5a3dd2e9d92ec689e08bf1cfa279121e2bb0478b
.
On Sun, Jan 24, 2021 at 3:12 PM Ben Wilson <bwi...@mozilla.com> wrote:
> As an alternative for this addition to MRSP section 5.3, please consider
> and comment on:
>
> Thus, the operator of a CA certificate trusted in Mozilla’s CA Certificate
> Program MUST disclose in the CCADB all non-technically constrained CA
> certificates they issue that chain up to that CA certificate trusted in
> Mozilla’s CA Certificate Program. This applies to all non-technically
> constrained CA certificates, including those that are self-signed,
> doppelgänger, reissued, or cross-signed.
>
>
> On Thu, Nov 12, 2020 at 11:54 AM Ben Wilson <bwi...@mozilla.com> wrote:
>
>> Jakob,
>>
>> On Thu, Nov 12, 2020 at 10:39 AM Jakob Bohm via dev-security-policy <
>> dev-secur...@lists.mozilla.org> wrote:
>>
>>>
>>> How would that phrasing cover doppelgangers of intermediary SubCAs under
>>> an included root CA?
>>>
>>>
>>> To clarify, the title of section 5.3 is "Intermediate Certificates".
>> Also, both subsection (1) and (2) under the proposed amendment reference
>> "intermediate certificates" - "(1) ...the Subject Distinguished Name in a
>> CA certificate or *intermediate certificate* that is in scope according
>> to section 1.1 of this Policy" and "(2)... corresponding Public Key is
>> encoded in the SubjectPublicKeyInfo of that CA certificate or *intermediate
>> certificate*." And finally, additional
>> requirements also apply to so-called reissued/doppelganger CA certificates
0 new messages