On 03/04/2017 21:48, Ryan Sleevi wrote:
On Mon, Apr 3, 2017 at 3:36 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
The assumptions are:
0. All relevant root programs set similar/identical policies or they
get incorporatated into the CAB/F BRs on a future date.
This is not correct at present.
It is a simply application of the rule that policies should not fall
apart if others in the industry do the same. It's related to the
"Golden Rule".
1. When the SubCA must be disclosed to all root programs upon the
*earlier* of issuance + grace period OR outside facility SubCA
receiving the certificate (no grace period).
This is not correct as proposed.
It is intended to prevent SubCAs issued to "new" parties from
meaningfully issuing trusted certificates before root programs have had
a chance to check the contents of the disclosure (CP/CPS, point in time
audit, whatever each root program requires).
2. The SubCA must not issue any certificate (other than not-yet-used
SubCAs, OCSP certs and other such CA operation certs generated in the
same ceremony) until Disclosure to all root programs has been
completed.
This is correct.
3. Disclosing to an operational and not-on-holiday root program team
(such as the the CCADB most of the time) indirectly makes the SubCA
certificate available to the SubCA operator, *technically* (not
legally) allowing that SubCA to (improperly) start issuing before
rule #2 is satisfied.
And given that this disclosure (in the CCADB) satisfies #2, why is this an
issue?
It is merely a step in the detailed logic argument that Ryan Sleevi
requested.
Note that no Browser or other client will trust certificates from the
new SubCA until the new SubCA or its clients can send the browser the
signed SubCA cert. This technical point is also crucial for after-
the-fact cross certificates.
5. SubCA Disclosure and processing of said disclosure should be done
nearly simultaneously to minimize the problem mentioned in 3.
I believe you're suggesting simultaneously across all root programs, is
that correct? But that's not a requirement (and perhaps based on the
incorrect and incomplete understanding of point 1)
Yes, across all root programs, that is the key point, see #0.
Also, it is argued as a logical consequence of #3, #2, #0, i.e.
assume another root program enacts similar rules. Once the SubCA cert
is disclosed on the CCADB for Mozilla and Chrome, the SubCA operator
can download the SubCA cert from the CCADB and use it to make users of
that other root program trust issued certificates before that other
root program received the disclosure.
By symmetry, if Mozilla has to shut down the CCADB for maintenance for
2 days, another root program might receive and publish the disclosure
first, causing the same problem for users of Mozilla and Chrome
products.
I think the rest of the argument now falls apart.
7. Thus between performing the audited root key access ceremony to
issue one or more SubCA certificates etc., and actually disclosing
those SubCA certificates to the root programs, an issuing CA may have
to wait for all the root programs to be *simultaneously* ready to
receive the SubCA certificate, without violating the grace period as
per assumption #1.
This is definitely not correct, or at the least, this is not Mozilla's
problem to solve.
Again it is a logic consequence of the other items, not an explicit
rule or assumption.
Thanks for clarifying your response. It's clear now we disagree because you
expect Mozilla to accommodate the entirety of all needs for all other
browser programs. That is something I fundamentally disagree with. It is
unnecessary to introduce complexity to the Mozilla process for hypothetical
third-parties. That is, in some degree, indistinguishable from concern
trolling (if insisted upon the hypothetical abstract, without evidence),
but is otherwise, not Mozilla's problem to solve the challenges for
hypothetical French and Russian programs. I think
https://wiki.mozilla.org/CA:FAQ#Can_I_use_Mozilla.27s_set_of_CA_certificates.3F
is relevant to that case as it is to the general case.
See my answer to #0 why I consider this a valid consideration. Think
of it as "scalability".
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
