On 18/10/2016 20:50, douglas.beat...@gmail.com wrote:
On Monday, October 17, 2016 at 4:19:34 PM UTC-7, Jakob Bohm wrote:
On 16/10/2016 09:59, Adrian R. wrote:
Hello
i read in the news (but not here on m.d.s.p) that a few days ago Globalsign
revoked one of their intermediary roots and then un-revoked it (well, the
revocation is accidental, but it was still a properly announced revocation, via
signed CRL and OCSP).
The official report is available here:
https://www.globalsign.com/en/customer-revocation-error/
Yes, I read the full report, I was nitpicking the bad communication
skills of whomever GlobalSign assigned to write the contents of the web
page (as it existed at that time).
Seems only fair to nitpick a western CA in perfect standing when we are
being so harsh on a Chinese CA in much worse standing.
To be clear, an intermediate root (not sure what this is tbh) was never revoked
- we revoked a cross certificate between roots R2 and R1 and an unused/EOL CA
under R2. These correctly appeared and continues to appear on the CRL, in fact
it was included on the October 7th Root R1 CRL well before the OCSP incident.
http://www.theregister.co.uk/2016/10/15/globalsign_incident_report/
They rolled back the revocation, but i thought that the BRs explicitly forbid
that a suspended/revoked certificate be un-suspended/un-revoked.
https://www.globalsign.com/en/customer-revocation-error/
is this revival/un-revocation of an intermediary CA allowed by the BRs?
I have just read that page, and find it utterly confusing and badly
written. Lot's of formal tone of voice, but no precision or clarity.
What I would have expected was a much clearer statement (on the page,
not in some linked document) as to:
I hope my responses help clarify the situation:
1. Which Intermediary CA certificates were affected (because
certificate holders cannot see the cache state affecting relying
parties, we need to check our certificates against something
specific to see if we are affected).
All CAs under Root R1 were effected.
And the page should have said that. Or more precisely:
- All certificates whose chain goes to Root R1 before going to Root R2.
- Maybe (unclear in retrospect) certificates under root R2 on machines
that only trust root R1 (such as Windows 8.x without auto-root
updates), and which checked the OCSP status of the R1 to R2 cross
cert or R1-root, at a time affected by the OCSP responder bug.
- Maybe (unclear in retrospect) certificates under root R2 if the web
server sends the R1 to R2 cross certificate to support R1-only
trusting machines, and the web browser uses certificates sent be the
web server in preference to checking that its root store already
contains R2 (a common implementation limitation), while actually
checking for revocation of R1-to-R2 cross or R1-root, at a time
affected by the OCSP responder bug.
2. If this affects all AlphaSSL and CloudSSL certificates or only some
of them.
This affects the CAs under Root R1 only (AlphaSSL, DV, OV, CloudSSL). None of
the actual end entity SSL certificates were ever revoked or marked as revoked
either via CRL or OCSP. The scope of the users impacted by this depends on
many factors, which are outlined in the report. Not all users were blocked
from accessing sites with SSL certificates under R1.
Yes, the report explains the cache issue clearly, but the web page
could have said something like:
AlphaSSL SHA-1 certificates issued before/after some dates (I guess
all of them).
AlphaSSL SHA-256 certificates issued before some date
CloudSSL ...
GlobalSign branded DV ...
GlobalSign branded OV ...
3. If this was an "exercise" (training/experimental etc.) or an actual
operational decision.
We intentionally revoked 2 CA certificates as listed in the incident report -
One old CA that had no live certificates issued under it, and the one cross
certificate referenced above.
So the word "exercise" was badly chosen (an exotic use of the word,
which I am fully aware of, but which is not clear in a context where
the meaning could just as well have been for example "as part of a
disaster readiness test").
We did not take actions to revoke any CAs other than these two; however as
pointed out, the OCSP responders incorrectly created and provided OCSP status
messages for CAs under R1 indicating that the CA was revoked. These CAs never
appeared in any CRLs.
4. If the revoked cross certificate was one of the cross certificates
previously provided to certificate holders to allow us to make our
servers compatible with older clients, and if so, which one.
The report explains it was not, the web page was 100% vague.
5. If this was e-mailed to all potentially affected certificate
holders, or just dumped in some public forums which certificate
holders might not see in time to take necessary action.
GlobalSign contacted as many of our customers as possible with SSL certificates
issued under Root R1. Note that EV certificates are issued under Root R2 and
were not impacted by this issue.
P.S.
In case you haven't realized after publishing the report, I suspect
your initial confusion about this being browser specific was really
about which browsers check OCSP by default and which don't. Which is
actually an interesting data point in general.
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
