On 20/03/2018 17:39, Wayne Thayer wrote:
Jakob,
On Mon, Mar 19, 2018 at 9:48 PM, Jakob Bohm via dev-security-policy <
[email protected]> wrote:
On 17/03/2018 01:23, Wayne Thayer wrote:
Note, that if it is reasonably certain/validated that the only activity
is maintaining CRLs/OCSP for the remaining unexpired certificates, then
most of the updated BR requirements (such as CAA, CT and stricter
validation methods) become noops, since no validations are being done,
no CAA strings are accepted, no new certificates are issued etc.
I agree in practice, but if a WebTrust audit were to be conducted it would
contain a number of qualifications, or as is the case here, no ETSI audit
statement would be issued.
We may thus be looking at the 12 months of an orderly shutdown of a
CA, as per section 5.8 of the standard CPS template, and might
reasonably consider accepting the lack of normal activity levels for
such a situation. The BRs and Mozilla policy seem silent on the
subject,
Are you suggesting that we delay removal of this root until all leaf
certificates expire?
Are you suggesting that the BRs be modified so a CA that has ceased
issuance can obtain a clean audit report without meeting all current BR
requirements?
I am suggesting that we consider what policy should be applied to the
(required!) capability of keeping revocation running for max cert
lifetime after a CA ceases to operate.
For starters, a wind-down CA will not issue any more certificates (and
should probably be audited to that fact), and will thus not be
meaningfully subject to the various requirements associated with that
activity (such as validation procedures, contents of newly issued
certificates etc.). This alone should significantly reduce the scope of
requirements and audits.
Secondly, a wind-down CA (as opposed to a wind-down root key from an
otherwise active CA) is likely to be operating from a prepaid
contingency fond, set up before the wind down based on the bare-bones
cost of safely doing the wind down procedures by a qualified but not
stellar skeleton crew. Thus maybe it shouldn't be required to engage
in time consuming administrative procedures such as responding to
quarterly Mozilla surveys or diligently watching m.d.s.p for new
requirements.
From the perspective of keeping Mozilla users safe, there are simply a
lot less that could go wrong, and a reasonable expectation that they can
still access servers that haven't yet switched to a new CA, because the
old cert is not expired and has working CRL and OCSP servers confirming
its validity.
So on a general basis, future BRs and/or Mozilla policy could have an
explicit list of things that are (or not) required during shutdown. For
example, there would still be a requirement to revoke at 24 hours notice
and to keep CRL and OCSP servers running in accordance with the policy
requirements at time of last external end entity issuance. There would
also be a requirement to state, in both CCADB and at their own website,
that the CA is winding down but will try to keep previously issued
certificates valid until <date>. They would be required to fix security
bugs in their still operational systems (such as OCSP responders and CRL
download web servers), but would not be required to implement new
security measures.
On a more practical basis, under current policy, I guess a BR audit
would contain a lot of trivial sections such as "validation: Not
applicable", "CPS updates: Not applicable", "sampling of issued
certificates: No certificates were issued in the audit period", etc.
Also, some ad hoc leniency may be used as a temporary substitute for a
formal policy.
The only critical thing that seems to be missing is a BR audit report to
confirm that no issuance is taking place and the revocation management
and CA private key protection is still being done properly.
Continued audit reports are indeed critical to maintaining trust in a CA
even after it has ceased issuance.
- Wayne
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
