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 chain
building)
In the spirit of keeping all discussion in this public
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
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
