Since QuoVadis has not yet responded, let me point to a few (partial)
answers already known from previous messages from QuoVadis or others:
On 15/08/2017 14:53, Ryan Sleevi wrote:
On Tue, Aug 15, 2017 at 4:53 AM, Stephen Davidson via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
Update on Siemens - Certificates with less than 64 bits of entropy
The following is regarding the topic https://groups.google.com/
forum/#!topic/mozilla.dev.security.policy/vl5eq0PoJxY regarding the
“Siemens Issuing CA Internet Server 2016” that is root signed by QuoVadis
and independently audited and disclosed.
At the time the issue was reported, Siemens agreed to immediately take the
CA offline, and it remains offline pending resolution. This was reported
to the listserv by me on 7/20.
Siemens confirmed a bug in their internally-developed CA software which
meant it was issuing TLS/SSL with 32bit serial numbers, although the serial
numbers were non sequential. Siemens informed their external auditors of
the situation.
It was found that 1201 currently valid certificates chained to the
QuoVadis root were affected. An additional 137 currently valid
certificates were issued under the previous "Siemens Issuing CA Internet
2013" chained to a Digicert root, noted in an email from Ben Wilson of
Digicert yesterday. In the case of the QuoVadis-chained certificates, the
certificates are virtually all of one year validity with expirations
balanced across the calendar months (there are a handful of two and three
year certificates, similar to the Digicert-chained population). The
remaining Digicert-chained certificates all expire by end of November
2017. All certificates were issued to Siemens entities and
Siemens-controlled domains.
Next steps
Siemens has moved to accelerate the previously planned replacement of
their existing inhouse CA platform with a well-known open source CA with
which QuoVadis is well familiar. QuoVadis and Siemens' auditors are
coordinating with Siemens to confirm that the new CA configuration meets
Baseline Requirements. It is worth noting that some BR controls,
particularly related to vetting, are imposed by the Siemens certificate
lifecycle system which will continue to be used with the new CA. Siemens
will not recommence their inhouse SSL issuance until the new CA is active
and confirmed compliant. The new CA is expected to come online in the
second week of September. Siemens commits to logging new SSL from that CA
in Certificate Transparency.
Replacement
Although the Siemens PKI is centralised, the certificates are issued to a
wide variety of Siemens group companies around the world and are used on
both infrastructure and high traffic websites. A rushed revocation and
replacement of these certificates would have a negative business impact on
Siemens that they believe outweighs the risk of the lower serials entropy
(particularly given that they are nonsequential).
We propose that Siemens begin the early replacement of the affected
certificates as soon as the new CA infrastructure is approved, with the
goal of completing the task by January 31, 2018. This will include all the
affected certificates (ie those chained from both the QuoVadis and Digicert
roots). While Siemens acknowledges that the affected certificates should
not have occurred, we point out that they will all be replaced far in
advance of the September 2019 date when industry-wide the last certificates
issued before the BR change (to larger serial numbers) are scheduled to
expire.
We request that Siemens be allowed this expanded scope to conduct an
orderly replacement of the affected certificates.
Many thanks, Stephen Davidson
QuoVadis
Stephen,
Thanks for posting your update regarding Siemens. Unfortunately, however,
it's lacking in many critical details necessary to take appropriate next
steps.
On the positive side, it is good to see that QuoVadis immediately took (and
kept) the Siemens CA offline. This represents a minimum necessary step when
faced with misissuance from a subordinate, and is a step expected of all
CAs while they investigate the issue and its causes, to prevent future
misissuance.
Note that it was (obviously) Siemens that took the SubCA offline, at the
request of QuoVadis.
However, the assessment of what went wrong, what steps are being taken, and
the risk are all deficient and, at worse, potentially demonstrate a
misunderstanding of both the risk of these certificates and the purposes of
these discussions.
To understand an appropriate level of detail, and the set of questions that
both QuoVadis and Siemens should be asking, I think a postmortem to the
level of detail provided by PKIoverheid, in
https://groups.google.com/d/msg/mozilla.dev.security.policy/vl5eq0PoJxY/W1D4oZ__BwAJ
, is a _minimum_ necessary step to take. In particular, it's useful to
understand
1) Siemens has maintained it was a "bug" that caused 32-bit serial numbers.
However, it's unclear from the community whether or not Siemens actually
took steps to appropriately implement the necessary controls - meaning it
was a bug in process - or whether code was implemented, but the
implementation was faulty - a bug in software. Including sufficient detail,
by analyzing both the process and the software development methodology, is
necessary to help the community both understand the nature of the "bug" and
the processes that gave rise to it.
> 2) QuoVadis failed to detect these certificates from a sub-CA it is
supervising. Why is this, and what steps is QuoVadis taking to properly
oversee its independently-operated sub-CAs?
3) Given that this issue persisted in both the previous and present
hierarchy, and given Siemens' limited issuance, why was this not detected
by audits? Were the audits by a sufficiently technically skilled auditor?
Did every certificate they sampled have an appropriately random serial
number? How many certificates did they sample?
4) QuoVadis and Siemens have not disclosed all affected certificates. Can
you please provide full details for all 1201 currently valid certificates,
such as via CT? A separate document (e.g. spreadsheet) would be appropriate
to contain all of the links to this.
In short, the analysis by Siemens and QuoVadis fails to identify or address
the systemic factors that lead to this failure, and as a consequence,
restore little confidence in either Siemens' operation or QuoVadis'.
Further, the analysis of the risk of serial numbers is either misguided or
disingenuous. Serial number entropy represents a critical risk mitigation
regarding hash collisions - its criticality is about ensuring it is in
place at time of issuance, as once a certificate is issued, the harm has
been introduced. Thus, it's both inappropriate and unrelated to suggest
that other legacy certificates with inappropriate entropy exist - those
were issued in a earlier time - and what is relevant is when the process
was introduced, how long it happened, and when it stopped.
It's worth noting that Siemens made a design and business decision to use
an in-house CA, and apparently made a series of design and business
decisions that failed to oversee or detect this issue. Similarly, QuoVadis,
despite having tools available to monitor and supervise issuance, appears
to have failed to detect these issues. The impact that revoking these
certificate has can thus be argued to be through the decisions of Siemens
and QuoVadis, rather than the community, and thus appropriate to suggest
that the cost of this impact should be borne by Siemens and QuoVadis.
Further, it's worth noting that, given the future risk of further
non-compliance, it's not unreasonable to suggest that Siemens should
absolutely be prepared to replace all 1201 currently valid certificates
within 24 hours, or, at most, a week, rather than the nearly five months
being proposed here. In 2017, it is no longer defensible to suggest an
organization may need that long to replace its certificates - and if it is,
that represents a series of design and business decisions made over the
past several years that have ignored both modern deployment practices and
the changing nature of the ecosystem. It should not be the role of CAs, or
the Mozilla community, to prop up these parts of the ecosystem, which need
to support evolving to address the continued threats and necessary
ecosystem improvements.
As the Baseline Requirements require revocation of the subscriber
certificates within 24 hours (4.9.1.1 (4), (9), (15)), which Siemens has
not done, and the Baseline Requirements require revocation of the
subordinate CA certificate within 7 days (4.9.1.2 (5)), which QuoVadis has
not done, it's expected that both Siemens and QuoVadis will present
qualified audits during the next audit period due to knowing and
intentional violation of the requirements. The effect these qualifications
have on the continued trust status of past certificates, and the continued
recognition of future certificates, is predicated on the ability to provide
sufficient assurance that the systemic issues have been identified,
understood, and remediated. At present, this response does not indicate a
sufficient level of disclosure to make that conclusion. Timely and
immediate revocation is one step that can be taken to restore that
confidence, while similarly, a full, holistic, and detailed response may
help mitigate the damage to trust that this misissuance has done.
Note that as you explained above the danger is caused by issuance, not
continued validity. Thus for this particular issue, revocation at any
speed provides no protection. Thus for this *particular* failure,
allowing practical considerations to override the legal 24 hour
requirement should cause no further harm (given that no further such
misissuance will occur).
For examples of what might be considered positive and appropriate
responses, and demonstrates the CAs' awareness and understanding of the
issues:
- Let's Encrypt
-
https://community.letsencrypt.org/t/may-19-2017-ocsp-and-issuance-outage-postmortem/34922
- PKIoverheid
-
https://groups.google.com/d/msg/mozilla.dev.security.policy/vl5eq0PoJxY/W1D4oZ__BwAJ
You can also consider post-mortems from related parts, such as CT logs, as
seen in Venafi's CT log post-mortem at
https://groups.google.com/a/chromium.org/d/msg/ct-policy/ohtZ64gLN3I/namq_NDmAQAJ
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
