On 03/04/2017 19:24, Ryan Sleevi wrote:
On Mon, Apr 3, 2017 at 12:58 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
taking a holiday and not being able to process a disclosure of a new
SubCA.
Considering that the CCADB does not require any of these parties to process
a disclosure, can you again explain why the proposed wording would not be
sufficient?
I think you may be operating on incomplete/incorrect assumptions about
disclosure, and it would be useful to understand what you believe happens,
since that appears to have factored in to your suggestion. Given that the
proposal allows the CA to fully self-report (if they have access) or to
defer until they do have access, that does seem entirely appropriate and
relevant to allow for one week.
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.
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).
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.
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.
4. It is common IT practice to take systems that don't need 24/7
holiday availability offline during business holidays where the
primary users are not going to need it. This is done for big
"flag day" changes, such as migrating the CCADB from a SalesForce to
Google platform or back. This is obviously not done for every
holiday, and often not for the entire holiday, but when it is done,
the entire holiday is often reserved for it in semi-outside
availability announcements.
The logical derivatives are:
5. SubCA Disclosure and processing of said disclosure should be done
nearly simultaneously to minimize the problem mentioned in 3.
6. If any ONE root program cannot process the disclosure immediately
(it is not using CCADB style automation or its backend infrastructure
is offline), and the issuing CA is made aware of this, they should
thus postpone the disclosure (and the handout of the SubCA cert)
until the announced unavailability is over.
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.
8. If some less automated root program handles each SubCA disclosure
via manual processing by a small team which goes on holiday at the
same time, then that root program can hold back the entire thing,
thus raising the practical minimum to which the grace period in
assumption #1 can be set.
So here is a hypothetical example:
Minor French browser F has its own root program but cannot process
SubCA disclosures during weekends and the entire Gregorian Christmas
period.
Minor Russian browser R has its own root program but similarly cannot
process SubCA disclosures during weekends and the entire Julian
Christmas period (due to basing their company holidays on a Julian
calendar interpretation of orthodocs Christianity).
The CCADB is fully online and disclosing there would make the SubCA
publicly visible to the SubCA operator within minutes.
CA X schedules a high security, audit root key access ceremony for
Dec 22 in some year and arranges for the parties to be present.
On Dec 20, French team F sends them their holiday mail, it is too
late to reschedule the ceremony.
On Dec 22 around noon PST, CA X holds a key signing ceremony to
generate fresh SubCA certificates for the next calendar year, for
both themselves and external SubCAs (including one brand new SubCA).
Because The French browser F team went on holiday around 16:00 CET
(8:00 AM PST), CA X cannot proceed until CA F opens for manual
processing on Jan 6.
But because Russian browser R similarly closed offices on Jan 2
Gregorian, CA X must actually wait until Jan 19 Gregorian.
Jan 19 happens to be a Saturday, so CA X needs to wait until Monday
Jan 21.
So on Jan 21, CA X sends/uploads SubCA disclosures to all root
programs, including the CCADB, French team F and Russian team R.
This starts a window of risk, where the SubCA operators could grab
their certificates from e.g. the CCADB before officially receiving it
from CA X.
Withing a 17 to 24 hours, all the manual processing root programs
(including F and R) confirm acceptance of the disclosed SubCAs to CA
X.
Now CA X is allowed to hand the external SubCA certificates over to
the SubCA operators (See #1) and unlock issuance from any internally
operated SubCAs (See #2).
The gap between Dec 22 and Jan 21 in this example scenario must not
exceed the grace period in #1, or there would be no way for CA X
to comply with the disclosure needs of all the root programs.
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
