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