On 04/04/2017 00:31, Peter Bowen wrote:
On Mon, Apr 3, 2017 at 1:45 PM, Jakob Bohm via dev-security-policy
<dev-security-policy@lists.mozilla.org> wrote:
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).
I don't see this as part of the proposed requirement. The requirement
is simply disclosure, not approval.
I see it as part of the underlying reasoning. Mozilla et al wants
disclosure in order to take action if the disclosed facts are deemed
unacceptable (under policy or otherwise). Upon receiving the
disclosure, the root program gains the ability to take counteractions,
such as protesting to the issuing CA, or manually blocking the unwanted
SubCA cert via mechanisms such as OneCRL. The rules don't make the CAs
wait for the root programs to get upset, but must allow at least zero
time for this time to happen.
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.
(Note, I split my paragraph to connect your reply to the specific
sentence it applies to)
This technical point is also crucial for after-
the-fact cross certificates.
This is a more interesting case. Going back to the start:
"The CA with a certificate included in Mozilla's CA Certificate
Program MUST disclose this information before any such subordinate CA
is allowed to issue certificates."
This implies that the subordinate CA is not already issuing
certificates. If a CA signs a certificate naming an existing CA as
the subject, then what?
Indeed. The easy case would be if the existing CA was already in the
CCADB and accepted in the Mozilla root program, making the cross-cert a
mere convenience for older browsers (old Mozilla or non-Mozilla), with
an added requirement that the cross-signing CA now must now do its own
audited checking and referencing of the existing CA's status and
compliance (the cost of which is hopefully included in the fee charged
for doing so, but that's their money to gain or loose).
If the Mozilla program member certifies a CA that is not a terminal CA
(e.g. not pathlen:0) and that CA then issues to another CA, how does
that certificate get into the CCADB?
The issuing CA would gain (by existing policy, I presume) an obligation
to disclose those too, and thus an incentive to contractually require
this disclosure from the SubCA.
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.
I see zero problem with the SubCA receiving the certificate
immediately from the issuing CA, even prior to disclosure in the
CCADB. The proposed requirement is that the SubCA not issue prior to
confirming the disclosure has been made.
Not receiving the certificate prevents a rogue or rookie SubCA from
meaningfully issuing prematurely. After all, SubCA operators are only
humans, and usually less experienced in all this than long time major
CA operators.
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'm not sure where you see the "problem for users" here. This is no
different than what happens today for many CAs.
The problem for users is that their Browser/client trusts a certificate
from a SubCA that their trusted root program has never seen, and thus
not even had a chance to form an opinion about.
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
