Re: Policy 2.7.1: MRSP Issue #186: Requirement to Disclose Self-signed Certificates

[Ben Wilson via 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  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  wrote:
>
>> Jakob,
>>
>> On Thu, Nov 12, 2020 at 10:39 AM Jakob Bohm via dev-security-policy <
>> dev-security-policy@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
>>
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy 2.7.1: MRSP Issue #186: Requirement to Disclose Self-signed Certificates

[Ben Wilson via 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  wrote:

> Jakob,
>
> On Thu, Nov 12, 2020 at 10:39 AM Jakob Bohm via dev-security-policy <
> dev-security-policy@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
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy 2.7.1: MRSP Issue #186: Requirement to Disclose Self-signed Certificates

[Ben Wilson via dev-security-policy]

Jakob,

On Thu, Nov 12, 2020 at 10:39 AM Jakob Bohm via dev-security-policy <
dev-security-policy@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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy 2.7.1: MRSP Issue #186: Requirement to Disclose Self-signed Certificates

[Jakob Bohm via dev-security-policy]

On 2020-11-12 05:15, Ben Wilson wrote:

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
cross-certificates which chain to a certificate that is included in
Mozilla’s CA Certificate Program."

And the following would be added:

"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-security-policy@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."

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:

Issue #186 in Github 
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 .

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.



How would that phrasing cover doppelgangers of intermediary SubCAs under 
an included root CA?




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 

Re: Policy 2.7.1: MRSP Issue #186: Requirement to Disclose Self-signed Certificates

[Ben Wilson via 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
cross-certificates which chain to a certificate that is included in
Mozilla’s CA Certificate Program."

And the following would be added:

"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-security-policy@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."
>
> 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:
> > Issue #186 in Github 
> > 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 .
> >
> > 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
> ___
> dev-security-policy mailing 

Re: Policy 2.7.1: MRSP Issue #186: Requirement to Disclose Self-signed Certificates

[Corey Bonnell via dev-security-policy]

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

On Wednesday, October 28, 2020 at 8:25:50 PM UTC-4, Ben Wilson wrote:
> Issue #186 in Github  
> 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 . 
> 
> 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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy 2.7.1: MRSP Issue #186: Requirement to Disclose Self-signed Certificates

[Jakob Bohm via dev-security-policy]

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-security-policy@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 
quote below.


Perhaps add: "And also include any other certificates sharing the same
private/public key pairs as CA certificates already included in the
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 
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.



This is precisely what I am trying to state in a concise manner, to
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.
"""



The words "issued by the CA" are problematic.  I realize that you are 
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
wall as all certificates  (e.g. including self-signed certificates and
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 

Re: Policy 2.7.1: MRSP Issue #186: Requirement to Disclose Self-signed Certificates

[Ryan Sleevi via dev-security-policy]

On Fri, Oct 30, 2020 at 12:38 PM Jakob Bohm via dev-security-policy <
dev-security-policy@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
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".


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.

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)
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy 2.7.1: MRSP Issue #186: Requirement to Disclose Self-signed Certificates

[Jakob Bohm via dev-security-policy]

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
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 
Sent: 29 October 2020 14:57
To: mozilla-dev-security-pol...@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=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=04 >.

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
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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy 2.7.1: MRSP Issue #186: Requirement to Disclose Self-signed Certificates

[Rob Stradling via dev-security-policy]

> 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?


From: dev-security-policy  on 
behalf of Jakob Bohm via dev-security-policy 

Sent: 29 October 2020 14:57
To: mozilla-dev-security-pol...@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:
> Issue #186 in Github 
> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmozilla%2Fpkipolicy%2Fissues%2F186data=04%7C01%7Crob%40sectigo.com%7C3bdb53393f1f4056b59e08d87c1aff51%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637395802683146795%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=ux32CpUMi7X31uD0W%2BsLV%2Bpgrv3lHgCbdZ%2BhVj2UlbA%3Dreserved=0>
> 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%2F186data=04%7C01%7Crob%40sectigo.com%7C3bdb53393f1f4056b59e08d87c1aff51%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637395802683146795%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=ux32CpUMi7X31uD0W%2BsLV%2Bpgrv3lHgCbdZ%2BhVj2UlbA%3Dreserved=0>.
>
> 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%2Fdata=04%7C01%7Crob%40sectigo.com%7C3bdb53393f1f4056b59e08d87c1aff51%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637395802683146795%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=sJ1Ar%2BE7qnVvPTdqdGEIKj25tRlyDLX%2F2sbqj4v9%2BlY%3D

Re: Policy 2.7.1: MRSP Issue #186: Requirement to Disclose Self-signed Certificates

[Jakob Bohm via dev-security-policy]

On 2020-10-29 01:25, Ben Wilson wrote:

Issue #186 in Github 
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 .

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
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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy