On 22/05/2017 18:33, Gervase Markham wrote:
On 19/05/17 21:04, Kathleen Wilson wrote:
- What validity periods should be allowed for SSL certs being issued
in the old PKI (until the new PKI is ready)?
Symantec is required only to be issuing in the new PKI by 2017-08-08 -
in around ten weeks time. In the mean time, there is no restriction
beyond the normal one on the length they can issue. This makes sense,
because if certs issued yesterday will expire 39 months from yesterday,
then certs issued in 10 weeks will only expire 10 weeks after that - not
much difference.
Note that the plan (at least as I read it), involves two major phases:
1. The transition "Managed SubCAs", these will continue to chain to the
old PKI during the transition, but it is possible for clients and root
programs to limit the trust to those specific "Managed SubCAs" instead
of the sprawling old certificate trees. This does not involve CT
checking in clients, just trust decisions.
2. The truly "new infrastructure", built properly to modern standards
will not be ready until some time has passed, and will be a new root
program applicant with new root CA certs. Once those roots become
accepted by multiple root programs (at least Google and Mozilla), the
new root CAs can begin to issue via "new infrastructure" SubCAs that
are signed by both "new root CAs" (for updated clients) and old root
CAs (for old clients).
I prefer that this be on
the order of 13 months, and not on the order of 3 years, so that we
can hope to distrust the old PKI as soon as possible. I prefer to not
have to wait 3 years to stop trusting the old PKI for SSL, because a
bunch of 3-year SSL certs get issued this year.
If we want to distrust the old PKI as soon as possible, then instead of
trying to limit issuance period now, we should simply set a date after
which we are doing this, and require Symantec to have moved all of their
customers across to the new PKI by that time.
Google are doing a phased distrust of old certs, but they have not set a
date in their plan for total distrust of the old PKI. We should ask them
what their plans are for that.
I understood certs issued by the old systems (except the listed Managed
SubCAs) will be trusted only if issued and CT logged between 2016-06-01
and 2017-08-08, and will be subject to the BR lifetime requirements for
such certs. Thus no such certs will remain trusted after approximately
2020-08-08 plus the slack in the BRs.
Clients without SCT checking (NSS ?) cannot check the presence of SCTs,
but can still check the limited range of notBefore dates.
- I'm not sold on the idea of requiring Symantec to use third-party
CAs to perform validation/issuance on Symantec's behalf. The most
serious concerns that I have with Symantec's old PKI is with their
third-party subCAs and third-party RAs. I don't have particular
concern about Symantec doing the validation/issuance in-house. So, I
think it would be better/safer for Symantec to staff up to do the
validation/re-validation in-house rather than using third parties. If
the concern is about regaining trust, then add auditing to this.
Of course, if we don't require something but Google do (or vice versa)
then Symantec will need to do it anyway. But I will investigate in
discussions whether some scheme like this might be acceptable to both
the other two sides and might lead to a quicker migration timetable to
the new PKI.
Gerv
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
