On 01/03/2017 12:43, Gervase Markham wrote:
On 13/02/17 12:23, Gervase Markham wrote:
The GoDaddy situation raises an additional issue.
....
What can be done about the potential future issue (which might happen
with any large CA) of the need to untrust a popular intermediate?
Suggestions welcome.
Reviewing the discussion, I unfortunately don't see any workable
solutions proposed yet. I think AIA chasing is a red herring. Jeremy's
engagement on intermediate rotation was illuminating, but it seems to me
that having multiple intermediates in play at the same time over an
extended period is very likely not to solve the problem, because any
issuance problem would cut across them all.
If customers tend to renew annually, one could imagine a "January
intermediate", "February intermediate" and so on, and one uses the
former every January, etc. This might reduce the need for an
intermediate change when an EE cert changes, as
CA's tend to encourage ahead-of-time annual renewals, offering to add
the leftover days to the validitiy period of the replacement
certificate (this is presumably also the reason BR max validity periods
are slightly more than a whole number of years, for example a 3 year
certificate renewed 2½ month ahead of expiry would have a validity of
38.5 months, which is less than 39).
I have sympathy for the
view that in today's world changing intermediate does make the process a
little more error prone. (Although it shouldn't, and that's a technology
fail I hope can be addressed.) Then, if you have an issuance problem
which persisted for a month but which has led to a situation where you
can't trust anything off the intermediates used during those times, only
1/6th of your outstanding certs from that root are at risk of needing
immediate change rather than all of them.
I would say a lot could be improved if certificate issuance customer
messages provided the *relevant* chains and their individual
certificates directly and with human-friendly names, it would greatly
reduce the confusion compared to the common practice of asking each EE
to manually navigate disorganized support pages for individual
certificates with semi-numerical names such as "Foo intermediate G3"
For example the confirmation mail or individualized web page could
be something like this:
--- Begin example for an OV SSL cert validated by the Joe's certs RA ---
Here is your new SSL/TLS certificate for www.example.com, example.com
and static.example.com (serial number
1231231421432453255268924750932758934750): example_com_2017_03_17.cer
(PEM format).
Needed intermediary certificates to put on your server:
All in one file (including your certificate):
example_com_2017_03_17_with_chain.pem (PEM format as needed by most
servers) Or example_com_2017_03_17_with_chain.p7 (PKCS#7 for Microsoft
IIS, Exchange etc.)
One at a time (These are included in the all-in-one files above except
the ones marked with an X, which your server shouldn't send)
NiceCA-via-JoeRA-SSL-Regular-March-2017.cer (PEM format)
X NiceCA-SHA256RSA-Root-2016.cer (PEM format)
NiceCA-SHA256RSA-Root-2016-cross-by-UserFirst.cer (PEM format)
X UserFirst-ancient-root.cer (PEM format)
--- End example ---
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
