On 23/03/2018 19:34, Wayne Thayer wrote:
Recently I've received a few questions about audit requirements for
subordinate CAs newly issued from roots in our program. Mozilla policy
section 5.3.2 requires these to be disclosed "within a week of certificate
creation, and before any such subCA is allowed to issue certificates.", but
says nothing about audits.
The fundamental question is 'when must a new subCA be audited?' It is clear
that the TSP's [1] next period-of-time statement must cover all subCAs,
including any new ones. However, it is not clear if issuance from a new
subCA is permitted prior to being explicitly included in an audit.
I believe that it is common practice for TSPs to begin issuing from new
subCAs prior to inclusion in an audit. This practice is arguably supported
by paragraph 3 of BR 8.1 which reads:
If the CA has a currently valid Audit Report indicating compliance with an
audit scheme listed in Section 8.1, then no pre-issuance readiness
assessment is necessary.
When disclosing a new subCA, the TSP can select "CP/CPS same as parent" and
"Audits same as parent" in CCADB to indicate that the same policies apply
to the new subordinate as to the root.
This issue was raised at the CA/Browser Forum meeting in October 2016 [2].
Three options have been proposed to resolve this ambiguity:
1. Permit a new subCA to be used for issuance prior to being listed on an
audit report.
2. Require the TSP to attest that the new subCA complies with a set of
existing policies prior to issuance [3].
3. Require an audit report (point-in-time or period-of-time) covering the
new subCA before any issuance (possibly with an exception for test
certificates or certificates required for audit purposes).
Please consider these options in the context of a TSP with a current audit
for the parent root that has issued a new subCA, and for which the new
subCA is operating under existing policies and in an existing operational
environment. If this is not the case, I would propose that a new audit
covering the subCA be required.
This is #32 on the policy issues list [4].
I would like to request everyone's input on this topic. Based on our
discussion, I may propose that we address this issue in policy version 2.6.
- Wayne
[1] To avoid confusion, I've chosen to use the term Trust Service Provider
(TSP) to refer to the CA organization.
[2] https://cabforum.org/2016/10/19/2016-10-19-20-f2f-meeting-
39-minutes/#Disclosure-of-Subordinate-CAs
<https://cabforum.org/2016/10/19/2016-10-19-20-f2f-meeting-39-minutes/#Disclosure-of-Subordinate-CAs>
[3] https://cabforum.org/pipermail/public/2016-September/008464.html
[4] https://github.com/mozilla/pkipolicy/issues/32
<https://github.com/mozilla/pkipolicy/issues/32>
Since rotating issuing SubCAs on a regular basis is a best practice to
mitigate the cost of SubCA key compromise (e.g. quarterly or monthly,
maybe more often for someone like LetsEncrypt), it would be highly
impractical to require fresh audits for each such periodic key
generation ceremony.
Having the generation of fresh SubCAs under established procedures be
considered a normal operational task, that just requires a notification
of the new SubCA cert to CCADB, plus inclusion in the next annual audit
would be much more practical, and would encourage the use of frequently
rotated SubCA keys.
One practical limitation for the issuance period of a SubCA is the worst
case size of the resulting CRL (imagine a CRL revoking all but one of
the certificates under a SubCA, then consider the download size of that
CRL for those who still use that method of revocation checking).
Technical note:
The ordinary lifecycle of a SubCA has 5 phases:
1. Generated but not yet issuing, upload to CCADB must occur within
the first 7 days of this phase.
2. Issuing, issued certificates may last as long as end of this phase
+ max cert duration for this SubCA.
3. Revocation only, no new EE certs issued, revocation signatures
(including OCSP certs) still signed. Ideally, this mode is enforced by
an irreversible HSM setting per SubCA. Early in this phase a SubCA
should publish a signed list of all issued EE certs (e.g. serial plus
strong hashes of full cert).
4. All expired, historical revocation only. In this phase the SubCA
issues revocation messages for expired certificates that were reported
as compromised, misissued etc. after their expiry. This is to help
relying parties (Mozilla users) detect if previously signed data was
false. This period will be short for TLS certs, but much longer for
e-mail certs (because a mail program like Thunderbird can store and
check e-mails that are years old when revisiting them in the user
interface).
5. Final revocations. The last act of a SubCA should be to sign a
non-expiring (or very long lived) set of revocation messages (CRLs and
canned OCSP responses), after which the private key is destroyed. Audit
logs etc. are retained for future audits. After this, OCSP responders
will need to reject (without signature) any queries for multiple certs
and never issued certs.
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
[email protected]
https://lists.mozilla.org/listinfo/dev-security-policy
