Responses inline. On Thu, Mar 12, 2020 at 12:46 PM Sándor dr. Szőke via dev-security-policy < [email protected]> wrote:
> > * Microsec issued two certificates in 2018 with 3-year validity periods > [1]. > > The certificates were issued for CISCO VPN servers. After receiving the > information about the misissuance the certificates were revoked. > This is an example of what I would call a "Highly disconcerting response". While it's important to note that much of the discussion is captured at https://groups.google.com/d/msg/mozilla.dev.security.policy/Pcc1_luzwNs/nAtn94GdBQAJ (Wayne's [1]), this summation/response of the problem downplays the severity, as well as downplays the confusion about long-standing practices that was discovered during such discussions. Most notably, the suggestion that domain controller and VPN server certificates, despite containing id-kp-serverAuth, were not TLS / not in scope. > * There are roughly 20 policy documents for this hierarchy [2]. It is > > quite challenging to determine which documents apply to which types of > > certificates. The upcoming version of Mozilla policy states that “CAs > > must provide a way to clearly determine which CP and CPS applies to each > > of its root and intermediate certificates.” > > Microsec already offers a tool on its homepage which filters the > corresponding policy documents to a specific type of certificates. The CP > and CPS documents contain the policy OID values which are included in the > issued certificates. The CP OID contains also the version of the CP so it > is evident which version of the CP is relevant. Microsec plans to develop a > tool which will help the user to find the proper CP and CPS documents for a > specific certificate based on the CP OID included in the certificate. > To be clear: In the absence of EKU constraints, the policy OIDs provide limited-to-no technical assurance that a given intermediate will be constrained adequately. As such, for a given intermediate, /all/ of the CP/CPS documents may still be relevant. I can understand and appreciate why, especially in keeping with an ITU-T model of X.509, one would use a separate CP for each OID, and a separate CPS to document how that information within that CP is validated. However, the overarching concern is about trying to understand the scope of the root and intermediate(s), what they are technically capable of issuing, as well as what they do issue. Related to the above, for example, the existence of a CP/CPS for a Cisco VPN service or a Windows Domain Controller, which indicated the certificate contained id-kp-serverAuth, would absolutely be meaningful and relevant to an assessment of that CA. So it's not sufficient to structure based on examining what /has been issued/, but what /could be issued/. The latter leads to a consolidation of CP/CPS documents, as the CA focuses on describing exactly what profile(s) a given intermediate/root can issue, and exactly what practice(s) are used to ensure compliance with policies. That's why you see so many CAs with only one or two CP/CPSes. > > > ==Bad== > > * Microsec recently issued what appears to be two certificate used for > > testing that violate the BRs [3][4]. They are now expired. > > These were only pre-certificates which were sent to the log servers. > These pre-certificates have been issued for internal test purposes only. > The live certificates have never been published in our certificate store > and never been used in publicly available networks. > This is exactly the kind of disconcerting response that leads me to suggest Microsec should not be trusted, because this exact interpretation/explanation by Microsec has been expressly rejected. I can understand that, at the time, Microsec may have reached an erroneous and incorrect conclusion. However, the failure to even acknowledge the clarifications that indicate why this is so problematic, and the failure to provide an incident report that talks about systemic fixes to these issues, suggest that Microsec has learned nothing, has no systemic checks in place, and will continue to make "similar mistakes" that share the same root issue. > > * CCADB currently lists 9 audit letter validation failures for Microsec. > > The CCADB presently contains 0 failure > This would have been a useful opportunity for Microsec to discuss the validation failures, what caused them, and the steps taken. However, this reply, as well as the reply regarding audit qualifications, highlights an approach to compliance that seems to focus on "As long as we're currently compliant, we're trustworthy", without systemically addressing the events that lead to non-compliance or how they're being prevented in the future. Knowing a CA is currently compliant is nowhere near as valuable a signal as knowing a CA has had a pattern of non-compliance, what the systemic causes were, and how they've been remediated. This is why I wrote such a strong message previously, and is exactly the kind of response that I'm seeing still continued that only further solidifies my negative opinion. > > * Three EV (QWAC) certificates have been issued with an extra > > subject:serialNumber field that contains what appears to be a policy OID > > [6]. Only one is currently revoked. > > Microsec issued only test EV certificates from the "e-Szigno Qualified TLS > CA 2018" CA to support the test sites for valid, revoked and expired > certificates required by Mozilla. > The OID in the subject:serialNumber field of the certificates is the > unique identifier of the subject assigned by Microsec in a form of an OID. > One of these certificates is revoked on purpose, the next had an extremely > short validity and the third has already expired. > Usually Microsec puts more than one serialnumber field to the different > type of enduser certificates, one of them contains this OID based > identifier of the Subject. > After having the discussion regarding the usage of the > organizationIdentifier filed in the EV certificates last year, it became > clear that the EVG allows only one serialnumber field. Microsec changed its > general practice and policy in case of EV certificates, and presently the > EV certificates contain only one serialnumber field hich contains the > company registration number. > Again, this highlights the systemic concern. That Microsec could read the Baseline Requirements, let alone the EV Guidelines, as permitting this, is a systemic concern. I appreciate the explanation, which is largely "We misunderstood the requirements", but that fits the overall trend of Microsec ignoring or being unaware of a whole host of requirements, or the changes to those requirements. That doesn't instill confidence, especially when combined with the approach of "We are now back in compliance". For better or for worse, Microsec's approach seems to mirror the problematic trend we've seen with respect to European certification, in which the objective is to be "currently compliant". As long as issues are resolved (within a 3-6 month period), "currently compliant" remains the north-star. Unfortunately, that approach fails to recognize the systemic objective of "continuously compliant", in which every divergence or non-conformity represents an enormous, though latent, systemic threat to Relying Parties. An approach of "continuous compliance" seeks not just to understand "What do I need to do to be compliant again", but works to understand "How did I become non-compliant, and how can I prevent that from happening again". My concern with the issues Wayne highlighted, and that have been highlighted in the audit, is that things seem to focus on having all boxes checked, without understanding why and how some might have failed, or systemically, how to ensure continuous compliance going forward. That, combined with the sizable risk caused by the lack of technical constraints, the myriad certificate types, the repeated confusion over the expectations and the requirements, all lead me to conclude that a wiser choice would be phasing out trust. These risks are all systemic, and not easily addressed by "spin up a new hierarchy" but really demonstrating a systemic understanding and commitment to ongoing operations beyond reproach or concern. _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
