Request to Include Microsec e-Szigno Root CA 2017 and to EV-enable Microsec e-Szigno Root CA 2009

[Kathleen Wilson]

This request is for inclusion of the Microsec e-Szigno Root CA 2017
trust anchor and to EV-enable the currently included Microsec e-Szigno
Root CA 2009 trust anchor as documented in the following bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=1445364

BR Self Assessment is here:
https://bugzilla.mozilla.org/attachment.cgi?id=9036567

Summary of Information Gathered and Verified:
https://ccadb-public.secure.force.com/mozilla/PrintViewForCase?CaseNumber=00000274

Root Certificate Download URLs:
http://www.e-szigno.hu/rootca2017.crt
http://www.e-szigno.hu/rootca2009.crt

CP/CPS:
eIDAS conform Qualified Certificate for Website Authentication CP (EV):
https://static.e-szigno.hu/docs/hr--min--ssl--EN--v2.13.pdf
eIDAS conform Qualified Certificate for Website Authentication CPS (EV):
https://static.e-szigno.hu/docs/szsz--min--ssl--EN--v2.13.pdf
eIDAS conform Certificate for Website Authentication CP (DV, OV):
https://static.e-szigno.hu/docs/hr--fok--ssl--EN--v2.13.pdf
eIDAS conform Certificate for Website Authentication CPS (DV, OV):
https://static.e-szigno.hu/docs/szsz--fok--ssl--EN--v2.13.pdf

This request is to include the 2017 root with the websites and email
trust bits enabled, and to enable both roots for EV.

Test Websites for the 2017 root:
Valid: https://eqtlsca2018-valid.e-szigno.hu/
Expired: https://eqtlsca2018-expired.e-szigno.hu/
Revoked: https://eqtlsca2018-revoked.e-szigno.hu/

Test Websites for the 2009 root:
Valid: https://qtlsca2018-valid.e-szigno.hu/
Expired: https://qtlsca2018-expired.e-szigno.hu/
Revoked: https://qtlsca2018-revoked.e-szigno.hu/

CRL URLs:
http://rootca2017-crl1.e-szigno.hu/rootca2017.crl,
http://rootca2017-crl2.e-szigno.hu/rootca2017.crl,
http://rootca2017-crl3.e-szigno.hu/rootca2017.crl
http://rootca2009-crl1.e-szigno.hu/rootca2009.crl,
http://rootca2009-crl2.e-szigno.hu/rootca2009.crl,
http://rootca2009-crl3.e-szigno.hu/rootca2009.crl

OCSP URLs:
http://rootca2017-ocsp1.e-szigno.hu,
http://rootca2017-ocsp2.e-szigno.hu, http://rootca2017-ocsp3.e-szigno.hu
http://rootca2009-ocsp1.e-szigno.hu,
http://rootca2009-ocsp2.e-szigno.hu, http://rootca2009-ocsp3.e-szigno.hu

Audit: Annual audits are performed by TÜViT according to the ETSI 319
411 audit criteria.
Microsec e-Szigno Root CA 2017:
BR:
https://www.tuvit.de/fileadmin/Content/TUV_IT/zertifikate/en/AA2019121302_e-Szigno-Root-CA-2017_V1.1_s.pdf
EV:
https://www.tuvit.de/fileadmin/Content/TUV_IT/zertifikate/en/AA2019061201_Microsec-eSzignoRoot-CA-2017_EV-CAs_s.pdf
Microsec e-Szigno Root CA 2009:
BR:
https://www.tuvit.de/fileadmin/Content/TUV_IT/zertifikate/en/AA2019121301_Microsec-eSzignoRoot-CA-2009_V1.1_s.pdf

EV:
https://www.tuvit.de/fileadmin/Content/TUV_IT/zertifikate/en/AA2019121301_Microsec-eSzignoRoot-CA-2009_V1.1_s.pdf


Wayne performed the detailed review of the CPs, CPSs, BR Self
Assessment, and related information for inclusion of the Microsec
e-Szigno Root CA 2017 and the EV-enablement of the Microsec e-Szigno
Root CA 2009 roots that are being tracked in this bug and he had the
following comments:

==Meh==
* The subordinate CA certificates for this root were created in 2017 and
2018. None of those intended for serverAuth are constrained by EKU.
Mozilla began requiring this in 2019.
* Microsec issued two certificates in 2018 with 3-year validity periods [1].
* 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.”
* CP section 1.3.2 permits 3rd party RAs, but in their BR
Self-Assessment, Microsec states that “The Trust Service Provider do not
apply third parties for RA activities.”
* CPS section 4.9.5 provides a detailed explanation of the revocation
process but fails to mention the required preliminary report to the
Subscriber and the entity who filed the Certificate Problem Report.
* CPS section 4.9.1 contains a section titled “Reasons for Revoking a
Subordinate CA Certificate operated by another CA” but in their BR
Self-assessment, Microsec states that “All Subordinate CA-s under the
Microsec roots are operated by Microsec.”

==Bad==
* I was unable to locate the description of email address validation
practices required by Mozilla policy section 2.2. Microsec published new
CPS version adding section 3.2.7 to resolve this issue.
* Microsec recently issued what appears to be two certificate used for
testing that violate the BRs [3][4]. They are now expired.
* CCADB currently lists 9 audit letter validation failures for Microsec.
* The root contains subject L and organizationIdentifier fields which
are arguably in violation of BR 7.1.4.3 [5]. Some, if not all, of the
subCAs also exhibit this issue.
* BR section 4.9.3 requires CPS section 1.5.2 to contain instructions
for reporting an issue such as key compromise to the CA. The Microsec
CPS’ only state that questions related to the policy may be reported via
the info in that section, and other email addresses
(“HighPriorityCertif...@e-szigno.hu”,
“revoc...@e-szigno.hu") are found in other sections of some documents.
Section 4.9.5 then states that revocation requests are only accepted at
the address listed in section 1.2, but there is no email address in this
section.
* 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.
* In comment #18 of the inclusion bug dated January 2019, Microsec
confirms that their CPS did not contain the required CAA information,
despite Microsec being a Mozilla root program member at that time.

* The following non-conformities were listed in the 2018 BR attestation
statement [7]. (they are not defined as “major” or “minor”):
** The TSP shall remove irrelevant and confusing information from each
policy (e.g. explanation of how to create policy codes) [ETSI EN 319
401, REQ-6.1-01]
** The TSP shall clearly indicate which kind of documents are necessary
for the application procedures of different types of certificates. [ETSI
EN 319 401, REQ-6.1-01]
** The TSP shall maintain such asset list which can support the daily
operation and does not cover unnecessary elements (e.g. mouse, keyboard)
[ETSI EN 319 401, REQ-7.3.1-01, REQ-7.3.1-02]•The TSP shall ensure that
the password policy provisions are applied in all systems in the TSP and
shall review them periodically. [ETSI EN 319 401, REQ-7.4-06]
** The TSP shall move the videoserver from the secondary data center to
another secure location without IT administrator access and shall review
the records on regular basis. [ISO27001], [ETSI EN 319 401, REQ-7.6-03]
** The TSP shall check operational state of the CCTV system regularly.
[ETSI EN 319 401, REQ-7.6-03]•The TSP shall extend the Termination Plan
to all services mentioned in the CPSs. [ETSI EN 319 401, REQ-7.12-02]
** The TSP shall check the possibilities to store and review video logs
for a longer period of time. [ETSI EN 319 411-1, OVR-6.4.2-07]
The TSP shall maintain dual control for performing critical functions on
the core systems (including Root CA, intermediate CAs, archiving system,
TSA system, OCSP responders etc.) [ETSI EN 319 411-1, GEN-6.4.3-02,
OVR-6.4.8-07, GEN-6.5.1-04, GEN-6.5.2-06]
** The TSP shall develop a restoration plan which schedules the
restoration over time to cover every system. [ETSI 319 411-1, OVR-6.4.8-05]
** The TSP shall approve and publish the latest version of its CP und
CPS documents. [ETSI EN 319 401, REQ-6.1-05]
** The TSP shall modify the web application form and the registration
interface in such a way that it is clearly indicated what kind of
information are required for the issuance of the given certificate in
accordance with the policies. Misleading information shall be avoided.
[ETSI EN 319 401, REQ-6.1-01]
* The following minor non-conformities are listed in the 2018 EV
attestation statement [8]:
** Findings with regard to ETSI EN 319 401: 7.11 Business continuity
management Documentation and implementation of the generation of the
OCSP certificates within the BCP document shall be improved. [ETSI EN
319 401, Clause 7.11]
** Findings with regard to ETSI EN 319 411-1: 6.2 Identification and
authentication Documentation and implementation of the internal
guideline with regard to the verification of possible organizations
shall be improved. [ETSI EN 319 411-1, Clause 6.2.2 a), g), i)] [EVCG,
Clause 11.1.1, Point 1. (A)] [ETSI EN 319 411-1, Clause 6.2.2 a)]

* The following non-conformities were listed in the 2019 BR attestation
statement [9]:
** The TSP shall not issue non-compliant test certificates from the live
environment. As this has been occurred in the past, the TSP shall
provide evidences of the changed testing procedures to avoid further
occurrence of such events. [ETSI EN 319 401, REQ-6.1-07]
** The TSP shall ensure that all issuance of a qualified signature
comply with eIDAS Article 24 in each case. [ETSI EN 319 411-1,
REG-6.2.3-01]
** The TSP shall ensure that all issuance of a qualified certificate
comply with eIDAS Article 24 when TSP accepts certificate re-keying
requests as written mail with handwritten (wet) signatures via postal
services and any of the subject’s data is changed. [ETSI EN 319 411-1,
REG-6.2.3-01]
** The TSP shall review the re-keying procedure in the CPS and shall
align the CPS with the real process-es and the relating standards. [ETSI
EN 319 411-1, REG-6.2.3-02]
** The TSP shall ensure that the reusing procedure of all data fulfills
the EVCG 11.14 and the CPS corresponds to these reusing requirements.
[ETSI EN 319 411-1, REG-6.2.3-03]
** There are conflicts between Hungarian law and EV Guideline regarding
to the witnessing the root ca key generation by a Qualified Auditor, the
TSP must inform the CAB/Forum about this fact. [ETSI 319 411-1
GEN-6.5.1-14], [BRG, 9.16.3], [EVCG, 8.1], [EVCG, 17.7]
** The TSP shall present a mitigation plan to revoke and replace the
non-conforming certificates with exponent 101. [ETSI EN 319 411-1,
SDP-6.5.1-18]
* The following minor non-conformities are listed in the 2019 EV
attestation statement [10]:
** Documentation and implementation of the generation of the OCSP
certificates within the BCP document shall be improved. [ETSI EN 319
401, Clause 7.11]
** Documentation and implementation of the internal guideline with
regard to the verification of possible organizations shall be improved.
[ETSI EN 319 411-1, Clause 6.2.2 a), g), i)] [EVCG, Clause 11.1.1, Point
1. (A)] [ETSI EN 319 411-1, Clause 6.2.2 a)]


This begins the 3-week comment period for this request [11].

I will greatly appreciate your thoughtful and constructive feedback on
the acceptance of this root into the Mozilla CA program.

- Kathleen

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1512270
[2] https://e-szigno.hu/en/all-documents.html
[3] https://crt.sh/?id=1947655126&opt=zlint,ocsp
[4] https://crt.sh/?id=1947655112&opt=zlint,ocsp
[5] https://cabforum.org/pipermail/servercert-wg/2019-October/001154.html
[6] https://crt.sh/?cablint=225&iCAID=115482&minNotBefore=2017-01-01
[7]
https://www.tuvit.de/fileadmin/Content/TUV_IT/zertifikate/en/AA2018121303_Microsec-eSzignoRoot-CA-2017_nonEV-CAs_s.pdf
[8]
https://www.tuvit.de/fileadmin/Content/TUV_IT/zertifikate/en/AA2019061201_Microsec-eSzignoRoot-CA-2017_EV-CAs_s.pdf
[9]
https://www.tuvit.de/fileadmin/Content/TUV_IT/zertifikate/en/AA2019121302_e-Szigno-Root-CA-2017_V1.1_s.pdf
[10]
https://www.tuvit.de/fileadmin/Content/TUV_IT/zertifikate/en/AA2019061201_Microsec-eSzignoRoot-CA-2017_EV-CAs_s.pdf
[11] https://wiki.mozilla.org/CA/Application_Process

[Matt Palmer]

On Mon, Mar 09, 2020 at 11:48:40AM -0700, Kathleen Wilson via dev-security-policy wrote:
> ==Bad==

This is a *very* long list of bad things. Based on this list alone I think
it would be reasonable for Mozilla to reject this application. I'd like to
highlight the things that are practically problematic, based on my recent
work attempting to revoke certificates for compromised keys.

> * BR section 4.9.3 requires CPS section 1.5.2 to contain instructions for
> reporting an issue such as key compromise to the CA. The Microsec CPS’ only
> state that questions related to the policy may be reported via the info in
> that section, and other email addresses
> (“HighPriorityCertif...@e-szigno.hu”,
> “revoc...@e-szigno.hu") are found in other sections of some documents.

Section 1.5.2 is where I go looking for contact information to revoke a
certificate. If it's not there... I'm outta luck.

> Section 4.9.5 then states that revocation requests are only accepted at the
> address listed in section 1.2, but there is no email address in this
> section.

I like their clarity that they don't accept revocation requests to other
addresses, but then not listing any valid addresses does make it tricky.
Especially since the previous paragraph gives an e-mail address to contact.

On that subject:

s4.9.5 of the DV/OV CPS states:

> In case of applications sent by electronic mail, the time of arrival is
> when the email is received to the dedicated email address
> revoc...@e-szigno.hu on the server of the Trust Service Provider.
> Emails arriving out of office hours are considered as arrived at the
> beginning of the next business day.

I don't believe this is in alignment with the BRs, Mozilla Policy, or
general expectations around the availability of a CA. Most of the CPSes
I've dug into recently make mention of maintaining "24x7x365" availability
for accepting and processing problem reports (and, to be fair, I do often
get responses from CAs at all hours). "Next business day" processing is
woefully inadequate.

Rolling back to the beginning of s4.9 of the DV/OV CPS, let's go through it
in order.

s4.9:

> The usage of the private key belonging to the revoked Certificate shall be
> eliminated immediately. If possible, the private key belonging to the
> revoked Certificate shall be destroyed immediately after revocation.

This is a bit odd to see in a CPS. I am assuming there is something in the
subscriber agreement that makes this binding on a subscriber. In any event,
I, personally, would consider any issuance of a new certificate using the
same private key as a revoked certificate to be misissuance (I don't know if
Mozilla would feel the same way).

s4.9.2 does not allow me, as an Internet Rando who happens to have an
unhealthy fascination with collecting published private keys, from
requesting revocation. The CPS really must not dissuade third parties from
reporting problems with certificates, IMO.

s4.9.3, subsection "High-Priority Certificate Problem Report", does not
define what constitutes a "high priority" report, but intimates that it
involves requests where law enforcement may need to become involved. If you
follow enough links, you get to a page that suggests that key compromise may
be considered a "high priority" report, however were I to be looking at this
CPS to find a way to report a key compromise, I would not consider using
this "high priority" channel, based on the information in this CPS.

Based on the above points, and the lengthy set of "bad" points previously
identified by Wayne, I would ask Mozilla to reject this application.

- Matt

[Ryan Sleevi]

Comments inline and snipped

On Mon, Mar 9, 2020 at 2:48 PM Kathleen Wilson via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> ==Meh==

>
* Microsec issued two certificates in 2018 with 3-year validity periods [1].
>

That bug, and the related discussion, discussions Microsec's confusion but
does not appear to lead to any understanding about what systemically has
been changed to prevent this confusion in the future. At the time of the
discussion, it was also pointed out how that confusion was unreasonable.

> * CP section 1.3.2 permits 3rd party RAs, but in their BR
> Self-Assessment, Microsec states that “The Trust Service Provider do not
> apply third parties for RA activities.”
> * CPS section 4.9.5 provides a detailed explanation of the revocation
> process but fails to mention the required preliminary report to the
> Subscriber and the entity who filed the Certificate Problem Report.
> * CPS section 4.9.1 contains a section titled “Reasons for Revoking a
> Subordinate CA Certificate operated by another CA” but in their BR
> Self-assessment, Microsec states that “All Subordinate CA-s under the
> Microsec roots are operated by Microsec.”
>
> ==Bad==
> * I was unable to locate the description of email address validation
> practices required by Mozilla policy section 2.2. Microsec published new
> CPS version adding section 3.2.7 to resolve this issue.
> * Microsec recently issued what appears to be two certificate used for
> testing that violate the BRs [3][4]. They are now expired.
> * CCADB currently lists 9 audit letter validation failures for Microsec.
> * The root contains subject L and organizationIdentifier fields which
> are arguably in violation of BR 7.1.4.3 [5]. Some, if not all, of the
> subCAs also exhibit this issue.

> * BR section 4.9.3 requires CPS section 1.5.2 to contain instructions
> for reporting an issue such as key compromise to the CA. The Microsec
> CPS’ only state that questions related to the policy may be reported via
> the info in that section, and other email addresses
> (“HighPriorityCertif...@e-szigno.hu”,
> “revoc...@e-szigno.hu") are found in other sections of some documents.

> Section 4.9.5 then states that revocation requests are only accepted at
> the address listed in section 1.2, but there is no email address in this
> section.

> * 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.
> * In comment #18 of the inclusion bug dated January 2019, Microsec
> confirms that their CPS did not contain the required CAA information,
> despite Microsec being a Mozilla root program member at that time.
>

Every one of the non-snipped incidents here (including the 3 year certs)
seem to point to a systemic failure to understand and follow industry
developments, either within m.d.s.p. or within the CA/Browser Forum's
Baseline Requirements.

That's concerning, as Microsec already operates a trusted root -
https://crt.sh/?caid=778 - in Mozilla's program, and so it's not
unreasonable to expect them to be following and adhering to these
requirements, especially as it relates to the CP/CPS.

I've highlighted similar issues, below, regarding the same systemic
concerns:

* The following non-conformities were listed in the 2018 BR attestation
> statement [7]. (they are not defined as “major” or “minor”):

> ** The TSP shall maintain dual control for performing critical functions

> on
> the core systems (including Root CA, intermediate CAs, archiving system,
> TSA system, OCSP responders etc.) [ETSI EN 319 411-1, GEN-6.4.3-02,
> OVR-6.4.8-07, GEN-6.5.1-04, GEN-6.5.2-06]

> ** The TSP shall modify the web application form and the registration
> interface in such a way that it is clearly indicated what kind of
> information are required for the issuance of the given certificate in
> accordance with the policies. Misleading information shall be avoided.
> [ETSI EN 319 401, REQ-6.1-01]
>

and

> * The following non-conformities were listed in the 2019 BR attestation
> statement [9]:
> ** The TSP shall not issue non-compliant test certificates from the live
> environment. As this has been occurred in the past, the TSP shall
> provide evidences of the changed testing procedures to avoid further
> occurrence of such events. [ETSI EN 319 401, REQ-6.1-07]

> ** The TSP shall review the re-keying procedure in the CPS and shall
> align the CPS with the real process-es and the relating standards. [ETSI
> EN 319 411-1, REG-6.2.3-02]
> ** The TSP shall ensure that the reusing procedure of all data fulfills
> the EVCG 11.14 and the CPS corresponds to these reusing requirements.
> [ETSI EN 319 411-1, REG-6.2.3-03]
> ** There are conflicts between Hungarian law and EV Guideline regarding
> to the witnessing the root ca key generation by a Qualified Auditor, the
> TSP must inform the CAB/Forum about this fact. [ETSI 319 411-1
> GEN-6.5.1-14], [BRG, 9.16.3], [EVCG, 8.1], [EVCG, 17.7]
> ** The TSP shall present a mitigation plan to revoke and replace the
> non-conforming certificates with exponent 101. [ETSI EN 319 411-1,
> SDP-6.5.1-18]

I certainly want to be moderate here in how much weight is placed on the
audit issues. On the one hand, they represent concerns from the auditor
that indicate non-compliance, and they're useful signals. On the other, too
much reading into these concerns may incentivize CAs, and their auditors,
from not highlighting these matters, as we've seen.

The balanced approach that has been historically used is for the CA to file
incident report(s) for these matters, that allow them to more thoroughly
explain the reason for the finding and the steps they've taken to
ameliorate those concerns. However, Microsec hasn't really availed
themselves of that, so I feel like we have to take that judgement at face
value.

Looking at the overall pattern of issues, highlighted by Wayne's review of
the CP/CPS, TUViT, and Microsec's own misissuance, I feel it's a reasonable
conclusion that Microsec is not only following best practices for operating
a trusted root, but also not following minimum practices, nor does it have
effective procedures in to follow and adapt to changes in the ecosystem.
Had there been, prior to this discussion, a clear demonstration of
Microsec's commitment through active engagement. I think Kathleen
rightfully called this out late last year [1]. This seems to also fit the
pattern Wayne observed after his initial review [2].

At the core, I think this cuts to a deep question: As Microsec already
operates a Mozilla-trusted root, fundamentally the decision to include or
not include this root is, in part, a question about whether or not Microsec
is organizationally capable of operating in Mozilla user's best interests.
A decision to reject this root inclusion, but keep the existing root, would
be inconsistent with the concerns being highlighted here. At the same time,
a decision to include the root "solely" because they already have a root
that is trusted seems inconsistent with the principles and objectives of
this review process. Thus, at the core, this is not "just" a question about
whether to include (or not) the new root, but also a question about whether
the incidents, and their handling, rise to the level to consider removal or
distrust (for example, a DISTRUST_AFTER)

My own, personal view, wearing no hats, is that the handling to date does
rise to that level of considering no longer trusting new certs, phasing out
old certs, and rejecting this new root.

This naturally leads to the next question: What _would_ a restoration of
faith look like? Even if the above is rejected, what would it take for
Microsec to demonstrate they're on a trustworthy level? Unfortunately, I
think the only options are radical: radical candor, radical redesign, and a
radical approach to compliance. I think it would involve the creation of
new roots, new policies, and even new profiles, reimplementing everything
from the ground up so that it's simple: simple to understand the policies
and practices, simple to update and adjust to requirements, and simple to
evaluate. And while I suspect that's fundamentally at odds with Microsec's
operational models, I think seeing something from them that was clear and
unambiguously implementing "best practices for 2020" would be what's needed
to restore trust. And I know that's not an easy option, and it may not be
worth it for Microsec to attempt and fail, but I think it's the level we
should be setting for CAs.

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1445364#c33
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1445364#c35

[Corey Bonnell]

On Monday, March 9, 2020 at 2:48:56 PM UTC-4, Kathleen Wilson wrote:

> * The root contains subject L and organizationIdentifier fields which
> are arguably in violation of BR 7.1.4.3 [5]. Some, if not all, of the
> subCAs also exhibit this issue.

Given that Mozilla explicitly encourages CAs to provide detailed identity information in subCA/root certificates on its Forbidden or Problematic Practices Wiki page [1], I don't see how including these additional subject fields would run afoul of Mozilla Root Policy, especially considering that the example given on the Wiki page includes the OU subject RDN.

What is Mozilla's expectation for subject field encoding, considering the discussion in the CAB Forum and the aforementioned Wiki page?

Thanks,
Corey

[1] https://wiki.mozilla.org/CA/Forbidden_or_Problematic_Practices#Generic_Names_for_CAs

[Wiedenhorst, Matthias]

Dear all,

with regard to the findings listed in the different audit attestations, we would like to clarify that
- all non-conformities have been resolved in a timely manner
- the resolution has been audited by and proven to the certification body

In addition, we would like to emphasise that a pure number of non-conformities is not per se an indication of pour quality of the TSP but more an indication of a thorough audit. Give the number of different CAs / services within the scope of the audit, the number of non-conformities appears to be not extraordinary high.
Please also keep in mind, that according to the current agreement, audit attestations list all non-conformities, independent of their severity and status (resolved or not). We feel, that non-conformities should be evaluated individually and TSPs should not suffer to any penalties just because of the number of non-conformities revealed in the audit.

Best regards
Matthias Wiedenhorst
--
TUV Informationstechnik GmbH
TUV NORD GROUP


> -----Ursprüngliche Nachricht-----
> Von: dev-security-policy <dev-security-...@lists.mozilla.org> Im
> Auftrag von Kathleen Wilson via dev-security-policy
> Gesendet: Montag, 9. März 2020 19:49
> An: mozilla-dev-s...@lists.mozilla.org
> Betreff: Request to Include Microsec e-Szigno Root CA 2017 and to EV-enable

> * Microsec issued two certificates in 2018 with 3-year validity periods [1].

> * 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.”

> * CP section 1.3.2 permits 3rd party RAs, but in their BR Self-Assessment,
> Microsec states that “The Trust Service Provider do not apply third parties for RA
> activities.”
> * CPS section 4.9.5 provides a detailed explanation of the revocation process but
> fails to mention the required preliminary report to the Subscriber and the entity
> who filed the Certificate Problem Report.
> * CPS section 4.9.1 contains a section titled “Reasons for Revoking a Subordinate
> CA Certificate operated by another CA” but in their BR Self-assessment, Microsec
> states that “All Subordinate CA-s under the Microsec roots are operated by
> Microsec.”
>
> ==Bad==
> * I was unable to locate the description of email address validation practices
> required by Mozilla policy section 2.2. Microsec published new CPS version
> adding section 3.2.7 to resolve this issue.
> * Microsec recently issued what appears to be two certificate used for testing that
> violate the BRs [3][4]. They are now expired.
> * CCADB currently lists 9 audit letter validation failures for Microsec.

> * The root contains subject L and organizationIdentifier fields which are arguably
> in violation of BR 7.1.4.3 [5]. Some, if not all, of the subCAs also exhibit this issue.

> * BR section 4.9.3 requires CPS section 1.5.2 to contain instructions for reporting
> an issue such as key compromise to the CA. The Microsec CPS’ only state that
> questions related to the policy may be reported via the info in that section, and
> other email addresses (“HighPriorityCertif...@e-szigno.hu”,
> “revoc...@e-szigno.hu") are found in other sections of some documents.
> Section 4.9.5 then states that revocation requests are only accepted at the
> address listed in section 1.2, but there is no email address in this section.
> * 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.
> * In comment #18 of the inclusion bug dated January 2019, Microsec confirms that
> their CPS did not contain the required CAA information, despite Microsec being a
> Mozilla root program member at that time.
>

> * The following non-conformities were listed in the 2018 BR attestation statement
> [7]. (they are not defined as “major” or “minor”):

> ** The TSP shall remove irrelevant and confusing information from each policy
> (e.g. explanation of how to create policy codes) [ETSI EN 319 401, REQ-6.1-01]
> ** The TSP shall clearly indicate which kind of documents are necessary for the
> application procedures of different types of certificates. [ETSI EN 319 401, REQ-
> 6.1-01]
> ** The TSP shall maintain such asset list which can support the daily operation
> and does not cover unnecessary elements (e.g. mouse, keyboard) [ETSI EN 319
> 401, REQ-7.3.1-01, REQ-7.3.1-02]•The TSP shall ensure that the password policy
> provisions are applied in all systems in the TSP and shall review them
> periodically. [ETSI EN 319 401, REQ-7.4-06]
> ** The TSP shall move the videoserver from the secondary data center to another
> secure location without IT administrator access and shall review the records on
> regular basis. [ISO27001], [ETSI EN 319 401, REQ-7.6-03]
> ** The TSP shall check operational state of the CCTV system regularly.
> [ETSI EN 319 401, REQ-7.6-03]•The TSP shall extend the Termination Plan to all
> services mentioned in the CPSs. [ETSI EN 319 401, REQ-7.12-02]
> ** The TSP shall check the possibilities to store and review video logs for a

> longer period of time. [ETSI EN 319 411-1, OVR-6.4.2-07] The TSP shall maintain

> dual control for performing critical functions on the core systems (including Root
> CA, intermediate CAs, archiving system, TSA system, OCSP responders etc.)
> [ETSI EN 319 411-1, GEN-6.4.3-02, OVR-6.4.8-07, GEN-6.5.1-04, GEN-6.5.2-06]

> ** The TSP shall develop a restoration plan which schedules the restoration over
> time to cover every system. [ETSI 319 411-1, OVR-6.4.8-05]
> ** The TSP shall approve and publish the latest version of its CP und CPS
> documents. [ETSI EN 319 401, REQ-6.1-05]

> ** The TSP shall modify the web application form and the registration interface in
> such a way that it is clearly indicated what kind of information are required for the
> issuance of the given certificate in accordance with the policies. Misleading
> information shall be avoided.
> [ETSI EN 319 401, REQ-6.1-01]

> * The following minor non-conformities are listed in the 2018 EV attestation
> statement [8]:
> ** Findings with regard to ETSI EN 319 401: 7.11 Business continuity
> management Documentation and implementation of the generation of the OCSP
> certificates within the BCP document shall be improved. [ETSI EN
> 319 401, Clause 7.11]
> ** Findings with regard to ETSI EN 319 411-1: 6.2 Identification and authentication
> Documentation and implementation of the internal guideline with regard to the
> verification of possible organizations shall be improved. [ETSI EN 319 411-1,
> Clause 6.2.2 a), g), i)] [EVCG, Clause 11.1.1, Point 1. (A)] [ETSI EN 319 411-1,
> Clause 6.2.2 a)]
>

> * The following non-conformities were listed in the 2019 BR attestation statement
> [9]:
> ** The TSP shall not issue non-compliant test certificates from the live
> environment. As this has been occurred in the past, the TSP shall provide
> evidences of the changed testing procedures to avoid further occurrence of such
> events. [ETSI EN 319 401, REQ-6.1-07]

> ** The TSP shall ensure that all issuance of a qualified signature comply with
> eIDAS Article 24 in each case. [ETSI EN 319 411-1, REG-6.2.3-01]
> ** The TSP shall ensure that all issuance of a qualified certificate comply with
> eIDAS Article 24 when TSP accepts certificate re-keying requests as written mail
> with handwritten (wet) signatures via postal services and any of the subject’s data
> is changed. [ETSI EN 319 411-1, REG-6.2.3-01]

> ** The TSP shall review the re-keying procedure in the CPS and shall align the
> CPS with the real process-es and the relating standards. [ETSI EN 319 411-1,
> REG-6.2.3-02]
> ** The TSP shall ensure that the reusing procedure of all data fulfills the EVCG
> 11.14 and the CPS corresponds to these reusing requirements.
> [ETSI EN 319 411-1, REG-6.2.3-03]
> ** There are conflicts between Hungarian law and EV Guideline regarding to the
> witnessing the root ca key generation by a Qualified Auditor, the TSP must inform
> the CAB/Forum about this fact. [ETSI 319 411-1 GEN-6.5.1-14], [BRG, 9.16.3],
> [EVCG, 8.1], [EVCG, 17.7]
> ** The TSP shall present a mitigation plan to revoke and replace the non-
> conforming certificates with exponent 101. [ETSI EN 319 411-1, SDP-6.5.1-18]

> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy

______________________________________________________________________________________________________________________
Sitz der Gesellschaft/Headquarter: TÜV Informationstechnik GmbH * Langemarckstr. 20 * 45141 Essen, Germany
Registergericht/Register Court: Amtsgericht/Local Court Essen * HRB 11687 * USt.-IdNr./VAT No.: DE 176132277 * Steuer-Nr./Tax No.: 111/57062251
Geschäftsführung/Management Board: Dirk Kretzschmar


TÜV NORD GROUP
Expertise for your Success


Please visit our website: www.tuv-nord.com<http://www.tuv-nord.com>
Besuchen Sie unseren Internetauftritt: www.tuev-nord.de<http://www.tuev-nord.de>

[Ryan Sleevi]

Matthias,

I took a lot of care to address precisely that concern, so I hope that
message was not directed in response to me. If it was, then I think it
highlights a fundamental misunderstanding of the concern.

I think everything you said is consistent with the response I offered. I am
would be far more deeply concerned with the auditor if they did not list
such non-conformities, and took great care to try to highlight that the
risk of penalizing based on number of non-conformities listed would simply
encourage CAs to work with their auditors to hide things. However, the
response a CA takes to address those non-conformities /is/ a critical
evaluation of trust.

Your response, while appreciated, runs the risk of suggesting we can't make
a decision to not trust a CA without evidence of non-conformities, but if
there is evidence of non-conformities, we shouldn't use that as evidence in
a decision to not trust a CA. That's not really sustainable, nor is it in
line with the purpose and goal of audits themselves, at least as practiced
by Mozilla since the first version of the root policy.

[Sándor dr. Szőke]

2020. március 9., hétfő 19:48:56 UTC+1 időpontban Kathleen Wilson a következőt írta:
> This request is for inclusion of the Microsec e-Szigno Root CA 2017
> trust anchor and to EV-enable the currently included Microsec e-Szigno
> Root CA 2009 trust anchor as documented in the following bug:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1445364
>
>

Thank you for opening the 3-week comment period for our inclusion request.

At first let us give some background information regarding the findings of the auditor.

Microsec is a qualified trust service provider in Hungary and operates under strong control and supervision.
The yearly regular conformity assessment audit is made by the German TÜViT, which is one of the most stringent and thorough auditor in Europe.
Based on that very deep and careful audit TÜViT issues the audit reports and the attestation letters which contain all of the findings.
The findings are classified according to their weight.
If the auditor finds any major non-conformity, the audit report is not issued at all.
In case of minor non-conformity, the audit report is issued, and the CA may continue its services, but the CA shall report the action made to solve the findings within 3 months.
In case of recommendation the weight of the problem is low, and the CA shall solve the issue till the next audit (1 year).
TÜViT includes both the minor non-conformities and the recommendations in the attestation letter and the classification of the finding is not indicated in the report.
There was no major issue during the Microsec audit, so TÜViT issued the certificates and the attestation letters to Microsec.
Most of the findings were classified as recommendation.
Microsec has applied remediations to all findings in a timely fashion and all the remediations have been accepted by TÜViT.

The other reason while Microsec may have longer finding list than usual is, that Microsec offers several types of services and issues several types of certificates for different purposes (webserver authentication, electronic signature, electronic seal, encryption, authentication etc.) on different trust levels (EU qualified and not qualified).
All of the certificates are issued under the same root and there are no EKU to constrain most of the subordinate CAs from the BR audit, this way all the certificate types and CA-s shall be covered by the audit, including certificates which are not in the scope of the BR.
The higher number of certificate types and services may result more findings during the audit which can be unusual in a CA who offers only one service.

The relatively high number of findings doesn't mean that Microsec is a bad CA, but means that TÜViT is a very thorough auditor.

[Sándor dr. Szőke]

2020. március 9., hétfő 19:48:56 UTC+1 időpontban Kathleen Wilson a következőt írta:

> This request is for inclusion of the Microsec e-Szigno Root CA 2017
> trust anchor and to EV-enable the currently included Microsec e-Szigno
> Root CA 2009 trust anchor as documented in the following bug:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1445364
>
>

> Wayne performed the detailed review of the CPs, CPSs, BR Self
> Assessment, and related information for inclusion of the Microsec
> e-Szigno Root CA 2017 and the EV-enablement of the Microsec e-Szigno
> Root CA 2009 roots that are being tracked in this bug and he had the
> following comments:
>

Let me answer Wayne's findings in the original text

> ==Meh==
> * The subordinate CA certificates for this root were created in 2017 and
> 2018. None of those intended for serverAuth are constrained by EKU.
> Mozilla began requiring this in 2019.

The subordinate CA-s already contain EKU which are intended to issue codesigning certificates and certificates for time stamping units. There is not EKU in the subordinate CA certificates which are intended to issue other types of certificates, like website authentication, digital signature, client authentication, encryption etc. These subordinate CAs were created in 2017.

> * 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.

> * 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.

> * CP section 1.3.2 permits 3rd party RAs, but in their BR
> Self-Assessment, Microsec states that “The Trust Service Provider do not
> apply third parties for RA activities.”

Correct, Microsec presently do not apply any third parties for RA activities as it written in the CPS.

> * CPS section 4.9.5 provides a detailed explanation of the revocation
> process but fails to mention the required preliminary report to the
> Subscriber and the entity who filed the Certificate Problem Report.

The working process contains the communication with the Subscriber and the entity who filed the Certificate Problem Report.
This information will be included in the next version of the CPS.

> * CPS section 4.9.1 contains a section titled “Reasons for Revoking a
> Subordinate CA Certificate operated by another CA” but in their BR
> Self-assessment, Microsec states that “All Subordinate CA-s under the
> Microsec roots are operated by Microsec.”

Microsec is open for this type of cooperation, but presently Microsec operates all the subordinate CA-s under the Microsec roots.

>
> ==Bad==
> * I was unable to locate the description of email address validation
> practices required by Mozilla policy section 2.2. Microsec published new
> CPS version adding section 3.2.7 to resolve this issue.

Microsec always validates the email address, typically by sending an email containing an unique URL to the email address which has to be used by the Subscriber. The actual CPS contains more detailed description about the validation method of the email addresses.

> * 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.

> * CCADB currently lists 9 audit letter validation failures for Microsec.

The CCADB presently contains 0 failure

> * The root contains subject L and organizationIdentifier fields which
> are arguably in violation of BR 7.1.4.3 [5]. Some, if not all, of the
> subCAs also exhibit this issue.

It is a general requirement that CA name shall be detailed enough to allow relatively straightforward identification of the CA. In the EU all of the companies has an official and unique company registration number, and it is a requirement to add this value into the enduser certificates in the organizationIdentifier field. It is widely used in subordinate certificates too.
The section BR 7.1.4.3 contains only 3 mandatory fields which shall be included in the certificate, but it is not clear in the wording of the BR that other fields are not allowed to be used.
According to the basic requirement Microsec adds these two more fields to the CA certificates to make possible the clear identification of the CA.

> * BR section 4.9.3 requires CPS section 1.5.2 to contain instructions
> for reporting an issue such as key compromise to the CA. The Microsec
> CPS’ only state that questions related to the policy may be reported via
> the info in that section, and other email addresses

> (“HighPriority...@e-szigno.hu”,

> “revoc...@e-szigno.hu") are found in other sections of some documents.
> Section 4.9.5 then states that revocation requests are only accepted at
> the address listed in section 1.2, but there is no email address in this
> section.

The CPS of Microsec is structured according to the requirement of RFC3647. This also required by the CABF BR in section 2.2.
According to RFC3647 the Section 1.5 is for the policy administration and section 1.5.2 defines the contact person who is responsible for maintaining the CPS.
Section 4.9.3 of the CPS contains detailed information about the possibilities of revocation request submission. Section 1.3.1 contains the email addresses, where revocation request can be sent (mentioning section 1.2 is an editorial mistake, it will be corrected in the next version of the CPS).
Section 4.9.3 contains also a subsection which describes the High-Priority Certificate Problem Report mechanism. More detailed information can be found on our website on the given link.

> * 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.

> * In comment #18 of the inclusion bug dated January 2019, Microsec
> confirms that their CPS did not contain the required CAA information,
> despite Microsec being a Mozilla root program member at that time.
>

The Microsec CPS contains, that Microsec checks the content of the CAA record as part of the validation process from the CPS version 2.3 dated 2017-04-30.
The information about the accepted domain name is added to the CPS in the version 2.9 dated 2019-04-24.

[Ryan Sleevi]

Responses inline.

On Thu, Mar 12, 2020 at 12:46 PM Sándor dr. Szőke via dev-security-policy <
dev-secur...@lists.mozilla.org> 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.

[Wiedenhorst, Matthias]

Hello Ryan,

my message was not meant as a response to your previous message but as a general contribution.
I know that you have deepest knowledge around the different audit schemes. However, others on this list might be less familiar with audits. That’s why I thought it might be useful to provide some framing information from the auditors perspective, although knowing that you already had elaborated on some of the aspects.

I am not proposing that decisions should not be based on published non-conformities but I wanted to point out that decisions shall consider all the facts and should not be based purely on the number of non-conformities. As you said, just counting "bad" points without looking at the whole picture might set wrong incentives.

Best regards
Matthias

Von: Ryan Sleevi <ry...@sleevi.com>
Gesendet: Mittwoch, 11. März 2020 19:18

Matthias,

I took a lot of care to address precisely that concern, so I hope that message was not directed in response to me. If it was, then I think it highlights a fundamental misunderstanding of the concern.

I think everything you said is consistent with the response I offered. I am would be far more deeply concerned with the auditor if they did not list such non-conformities, and took great care to try to highlight that the risk of penalizing based on number of non-conformities listed would simply encourage CAs to work with their auditors to hide things. However, the response a CA takes to address those non-conformities /is/ a critical evaluation of trust.

Your response, while appreciated, runs the risk of suggesting we can't make a decision to not trust a CA without evidence of non-conformities, but if there is evidence of non-conformities, we shouldn't use that as evidence in a decision to not trust a CA. That's not really sustainable, nor is it in line with the purpose and goal of audits themselves, at least as practiced by Mozilla since the first version of the root policy.

On Wed, Mar 11, 2020 at 11:45 AM Wiedenhorst, Matthias via dev-security-policy <mailto:dev-secur...@lists.mozilla.org> wrote:
Dear all,

with regard to the findings listed in the different audit attestations, we would like to clarify that
- all non-conformities have been resolved in a timely manner
- the resolution has been audited by and proven to the certification body

In addition, we would like to emphasise that a pure number of non-conformities is not per se an indication of pour quality of the TSP but more an indication of a thorough audit. Give the number of different CAs / services within the scope of the audit, the number of non-conformities appears to be not extraordinary high.
Please also keep in mind, that according to the current agreement, audit attestations list all non-conformities, independent of their severity and status (resolved or not). We feel, that non-conformities should be evaluated individually and TSPs should not suffer to any penalties just because of the number of non-conformities revealed in the audit.

[Sándor dr. Szőke]

I provide brief explanations for the 2018 audit findings as follows:

> * The following non-conformities were listed in the 2018 BR attestation
> statement [7]. (they are not defined as “major” or “minor”):

https://www.tuvit.de/fileadmin/Content/TUV_IT/zertifikate/en/AA2018121303_Microsec-eSzignoRoot-CA-2017_nonEV-CAs_s.pdf

This is the non EV attestation letter for the new ECC root in 2018-12-13 based on the point in time audit for the new service

> ** The TSP shall remove irrelevant and confusing information from each
> policy (e.g. explanation of how to create policy codes) [ETSI EN 319
> 401, REQ-6.1-01]

Microsec issues several types of certificates based on different certificate policies. One CP and CPS document typically contains the requirements for a number of similar certificate types by using slightly different policies.
These policies can be classified by using 5 main parameters.
Microsec introduced a five-character short reference code to be able to refer to a given policy easily. This short reference code is used in the CP and CPS documents to mark those requirements, which are related only to a specific policy. This code is used also in the CA system of Microsec to identify configuration settings.
The meaning of this classification was included in the CP and CPS documents to help the Subscribers understand it.
To fulfil the requirement of the auditor, Microsec terminated the usage of some policies regarding electronic signature and moved this description to the Appendix of the CP and CPS documents.

> ** The TSP shall clearly indicate which kind of documents are necessary
> for the application procedures of different types of certificates. [ETSI
> EN 319 401, REQ-6.1-01]

This finding refers to the 2018 version of the webpage of Microsec, which listed all the public documents on one page, like the following list presently:
https://e-szigno.hu/en/all-documents.html
The names of the documents are meaningful, and the documents are grouped, but due to the high number of the offered services, it was not easy to find all the relevant documents for a specific service or service package based on this page.
To fulfil this finding of the auditor, Microsec developed a web page to help the users find the corresponding documents more easily. You can see this page on the following link:
https://e-szigno.hu/en/terms-and-informations/
This lists the most frequently used services and service packages. After selecting the proper service or package the web page shows all the corresponding public documents.
Example:
https://e-szigno.hu/en/terms-and-informations/filtered-versions.html?szolg=minositett_weboldal_hitelesites
Clients and relying parties can find all the current and previous versions of our public documents on these sites. If a draft document is available which will take effect soon, it is also indicated by giving the planned effect date.

> ** The TSP shall maintain such asset list which can support the daily
> operation and does not cover unnecessary elements (e.g. mouse, keyboard)
> [ETSI EN 319 401, REQ-7.3.1-01, REQ-7.3.1-02]

Microsec has a detailed asset list which contains all of the valuable assets according to the legal and financial requirements in Hungary.
This list is maintained by our finance department and each asset is added to the list immediately upon purchase.
Of course, this asset list does not contain the low-value assets (such as mouse or keyboard), but contains the computers, screens, all the furniture and other tangible assets.
The auditor asked to maintain a shorter asset list, which contains only those IT assets which are essential for the operation of the services (HSMs, routers, switches, servers, desktop computers used for the services, etc.)
Microsec now maintains two lists in parallel, which are synchronized regularly. One is the full list and the other is the list of the critical IT devices.
The Microsec low level risk analysis is connected to this critical asset list.

> ** The TSP shall ensure that

> the password policy provisions are applied in all systems in the TSP and
> shall review them periodically. [ETSI EN 319 401, REQ-7.4-06]

Microsec uses various devices with different operating systems which have different support for forcing the password policies.
Microsec typically uses PKI certificate-based authentication between servers and when users log into applications, but in some cases username and password is also used (typically in addition to a PKI-based authentication).
Microsec reviewed the abilities of the used servers and the best practices regarding passwords, and changed the password policies accordingly, so that the requirements are now enforced across all used platforms

> ** The TSP shall move the videoserver from the secondary data center to
> another secure location without IT administrator access and shall review
> the records on regular basis. [ISO27001], [ETSI EN 319 401, REQ-7.6-03]

In 2018 Microsec already had two data centers on two separate locations at 10 km distance from each other. Each data center had its own video monitoring system. The video records were stored locally in each data center. The video servers were stored outside the server room in the operator room in a closed rack. The administrators who had access to the server room were able to go into the operator room, so they had physical access to the video server machine. They had no user access to the video server, so they were not able to delete the records, but they were able to damage the server. The video records were being deleted after 3 days according to the Hungarian regulation, and they were checked only in case of a possible incident.
To solve the issue Microsec routed all the video signals to the server room in the Microsec office. As a result, the internal IT operators can see all the camera pictures in real time and all the video is recorded continuously on two separate locations. This effectively prevents any administrator from damaging the stored video records

> ** The TSP shall check operational state of the CCTV system regularly.
> [ETSI EN 319 401, REQ-7.6-03]

Earlier, the video records were deleted after 3 days according to the Hungarian regulation and checked only in case of a possible incident.
Presently, the IT operators can see all the camera pictures in real time and all the video is recorded continuously on two separate locations.
The availability and quality of the recorded video is also checked every workday as part of the daily system supervision process.



> ** The TSP shall extend the Termination Plan

> to all services mentioned in the CPSs. [ETSI EN 319 401, REQ-7.12-02]

This finding refers to the use of external RA.
In 2018 the CP contained the possibility to use an external RA. It contained general requirements, i.e. the CA is responsible for the operation of the external RA and the details of the cooperation shall be fixed in the service contract. The option of the external RA has never been used.
There was no detailed description for the external RA in the termination plan, because the exact way of operation was not fixed.
The auditor required to work out all the details for each possibility included in the CPS.
Microsec did not use external RA at that time and did not plan to use external RA. Instead of working out the details of a non-existent cooperation, Microsec removed all the parts related to external RA from its CPS.

> ** The TSP shall check the possibilities to store and review video logs
> for a longer period of time. [ETSI EN 319 411-1, OVR-6.4.2-07]

In 2018, due to the Hungarian regulations, video logs were allowed to be stored only for 3 days.
Microsec agreed with the auditor that this was not sufficient in all cases (for example in case an incident happens on Friday) and asked the authorities to amend this regulation.
This national regulation was changed in 2019 and after this change Microsec increased the storage time of the video logs to 30 days.


> ** The TSP shall maintain dual control for performing critical functions on

> the core systems (including Root CA, intermediate CAs, archiving system,
> TSA system, OCSP responders etc.) [ETSI EN 319 411-1, GEN-6.4.3-02,
> OVR-6.4.8-07, GEN-6.5.1-04, GEN-6.5.2-06]

This finding refers to dual control upon leaving the server room.
Microsec uses dual control in each component of its system as a general requirement. It is not only required by our processes but also enforced by our IT systems critical for the certificate management.
Microsec also has dual control for the physical access in several places.
Access to the data center server room is only possible if two authorized persons use their contactless cards and enter their passwords at the same time. The distance of the card readers and the time limit makes it impossible for a single person to enter the server room alone.
This system was used for entry to the server room, but it was not used to enforce the use of two cards when leaving the server room.
The auditor required to install the same system to be able to leave the server room only by using dual control.
Microsec developed the same system inside the server room and now it is possible to leave the server room only if two authorized persons are present.

> ** The TSP shall develop a restoration plan which schedules the
> restoration over time to cover every system. [ETSI 319 411-1, OVR-6.4.8-05]

This finding refers to the readability of backup discs over a long period of time.
In 2018 Microsec used optical discs to store the system logs and the backup data.
The discs are stored in two copies in the data centers in a physically protected metal cabinet. The temperature and the humidity are controlled, there is no light or other radiation, so the discs are expected to remain readable for the 10 years storage period.
These discs are durable for at least 10 years. Earlier, the discs were checked for readability only when the data was needed. Microsec had never experienced any problem with the readability of any disc.
The auditor asked to make a plan and check the readability of all the stored discs regularly by defining sampling rules. Microsec shall check that the stored data is readable and suitable to restore the whole working system by using the stored data.
Microsec developed a maintenance plan, and since then, based on the plan, regularly checks the readability of the discs.
In September 2019 Microsec introduced a new system for backup purposes based on magnetic tape. The backup is made in parallel on two locations and stores all the log and backup data continuously.
We have two tapes on each location, one tape is active in the tape recorder, and the other is stored in a safe-deposit on that location as a backup tape. The active and the backup tapes are changed monthly on both locations. After the tape change the system checks the content of the installed tape and automatically copies the missing log data to the tape (the log of the previous month). The readability of the tape is automatically checked by the recording system when writing new data to the log.
The log data is also stored on the storage system and is removed from the backup server only after copying all data to the tapes in 4 copies.

> ** The TSP shall approve and publish the latest version of its CP und
> CPS documents. [ETSI EN 319 401, REQ-6.1-05]

During the audit Microsec had an open draft version of the public documents and Microsec made some smaller changes based on the requirements of the auditor. The audit was partially based on this draft document and the auditor recorded this way that the draft version shall be published.
The new versions of the public documents were published on the planned date with the already agreed improvements.

> ** The TSP shall modify the web application form and the registration
> interface in such a way that it is clearly indicated what kind of
> information are required for the issuance of the given certificate in
> accordance with the policies. Misleading information shall be avoided.
> [ETSI EN 319 401, REQ-6.1-01]

Microsec employs web-based forms to offer clients an easy certificate request method for the most widely used certificate types.
The finding refers to the application form for the electronic signature certificate. The customers who require electronic signature certificates typically belong to some organization, and the form required to enter the organization data, but the auditor wanted to request a certificate as a private person without any organization data.
The form did not specify that it was designed only for those natural persons who are associated with an organization. Based on this finding Microsec reviewed all the certificate request forms and made the necessary improvements. The form header now clearly describes what type of certificate you can apply for using the form.

> * The following minor non-conformities are listed in the 2018 EV
> attestation statement [8]:

https://www.tuvit.de/fileadmin/Content/TUV_IT/zertifikate/en/AA2019061201_Microsec-eSzignoRoot-CA-2017_EV-CAs_s.pdf


This is the period of time EV attestation letter for the new ECC root on 2019-06-12
This is the same document as included at the year 2019

> ** Findings with regard to ETSI EN 319 401: 7.11 Business continuity

> management - Documentation and implementation of the generation of the

> OCSP certificates within the BCP document shall be improved. [ETSI EN
> 319 401, Clause 7.11]

The generation of the OCSP certificates was changed, it was moved to another server. The actual version of the Business Continuity Plan contained the earlier server configuration and not the actual configuration.
Microsec reviewed the whole BCP document and corrected the fault in it.
Microsec held a training for the employees responsible for the maintenance of the BCP document, to ensure that it is kept up to date.

> ** Findings with regard to ETSI EN 319 411-1: 6.2 Identification and

> authentication - Documentation and implementation of the internal

> guideline with regard to the verification of possible organizations
> shall be improved. [ETSI EN 319 411-1, Clause 6.2.2 a), g), i)] [EVCG,
> Clause 11.1.1, Point 1. (A)] [ETSI EN 319 411-1, Clause 6.2.2 a)]
>

The internal documents contain detailed guidelines on how to validate the data of an organization. Hungary has a national company registration system which contains all the data of the bigger companies. The database is publicly available and contains the actual and authentic data of all the registered companies.
Microsec uses this service during the validation of the company data.
This database does not contain the registration data of the private entrepreneurs. Since these entities very rarely apply for certificates, the internal guideline did not specify how to check private entrepreneurs, this information was planned to be added as needed for the first application. Registration officers were aware of this. This did not cause any problems in practice; no such entity requested an EV certificate from Microsec.
Based on the finding of the auditor, Microsec developed the validation rules for this type of entity and added this information to the internal guideline.

[Sándor dr. Szőke]

I provide brief explanations for the 2019 audit findings as follows:

>
> * The following non-conformities were listed in the 2019 BR attestation
> statement [9]:

https://www.tuvit.de/fileadmin/Content/TUV_IT/zertifikate/en/AA2019121302_e-Szigno-Root-CA-2017_V1.1_s.pdf

This is the latest non-EV report for the ECC root from 2019-12-13

> ** The TSP shall not issue non-compliant test certificates from the live
> environment. As this has been occurred in the past, the TSP shall
> provide evidences of the changed testing procedures to avoid further
> occurrence of such events. [ETSI EN 319 401, REQ-6.1-07]

Microsec uses automated tests to monitor the availability of the Web Immediate Suspension service. To perform the tests, Microsec needs one test certificate from each of the subordinate CAs. Private keys are not needed at all so, after the issuance of the test certificates the private keys are destroyed. These test certificates are periodically suspended and then automatically reinstated.
On 2019-09-13, new test certificates were issued directly from each CA in the ECC root hierarchy with the following Subject DN data:
SERIALNUMBER = 1.3.6.1.4.1.21528.2.2.1.13331
E = info@..........hu
CN = Microsec zrt. - Automata Felfüggesztő - ECC
2.5.4.97 = VATHU-23584497
O = Microsec zrt.
L = Budapest
C = HU
5 of the test certificates were issued to natural persons for electronic signature creation, but this DN does not match the certificate profile for electronic signature certificates.
The auditor reported one of the incorrect certificates to Microsec at 2019-10-12 21:23
Microsec processed the report, identified the issue, verified the entire certificate database for similar issues, and revoked all 5 affected certificates with this issue at 2019-10-13 13:19.
Following the revocation of the test certificates concerned, new test certificates were issued in accordance with the normal certificate issuance process.
Microsec introduced a new process for issuing internal test certificates issued in the live system. All internal test certificates shall be issued from the RA system as part of the normal issuance process. It is now prohibited to issue even test certificates directly from the CA software. The standard certificate issuance process has multiple built-in automatic controls to avoid issuing faulty certificates.
The auditor has reviewed the changed testing procedures, accepted the provided evidence, and deemed this finding as resolved.

> ** The TSP shall ensure that all issuance of a qualified signature
> comply with eIDAS Article 24 in each case. [ETSI EN 319 411-1,
> REG-6.2.3-01]

Article 24 of eIDAS contains very stringent (stronger than the EVG) requirements for the identity verification before issuing qualified certificates. The basic process requires face-to-face identity verification of the natural person, who can be the Subject in case of a signing certificate or the representative of the Subject in case of seal or website authentication certificate.
eIDAS and the ETSI standards do not specify how long this face-to-face verification can be reused or when it shall be repeated. Different EU member states have different interpretations and different practices. Some member states allow the re-use of the verification result in the case of a certificate renewal, but in other member states it has to be repeated in case of issuance of a certificate due to any reason (renewal, rekey, modification).
Instead of the face-to-face identity verification, the CA may accept a qualified signature or qualified seal created with the certificate to be renewed. This cannot be done if the certificate cannot be used to create a valid digital signature.
The Hungarian requirements are very strict and always require face-to-face verification in each case when a valid digital signature is not available.
Microsec CPS did not provide detailed regulation in some of these special cases.
Microsec updated its public documents, which are valid from 2019-12-12. The section 3.2 of the CPS was modified. When issuing any certificate, Microsec uses the same identity verification process as used for initial identity verification.
In all cases, the procedure for issuing qualified certificates is fully in line with Article 24 of eIDAS.

> ** The TSP shall ensure that all issuance of a qualified certificate
> comply with eIDAS Article 24 when TSP accepts certificate re-keying
> requests as written mail with handwritten (wet) signatures via postal
> services and any of the subject’s data is changed. [ETSI EN 319 411-1,
> REG-6.2.3-01]

It is the same issue as described above. In the event of a lost smartcard, the Subscriber is not able to create a valid digital signature to request a certificate re-key, and it is not possible at all with a website authentication certificate. Microsec had previously accepted the re-key request in a paper and ink based signed document, and Microsec used a trusted communication channel (usually a phone call) to validate the signature of the received request.
In the current version of the CPS, this process can only be used if the expiration date of the re-keyed certificate is the same as the original certificate. In all other cases, the initial validation process shall be repeated, including the face-to-face verification.

> ** The TSP shall review the re-keying procedure in the CPS and shall

> align the CPS with the real processes and the relating standards. [ETSI
> EN 319 411-1, REG-6.2.3-02]

Nowhere is it defined exactly what re-keying means. The most useful information can be found in RFC3647.
The definition does not exist in the ETSI standards, and ETSI EN 319 411-1 contains requirements that can be interpreted in different ways. The main question is whether the re-key can be used for an invalid certificate or not.
After discussing the situation with the auditor and the supervisory body, we concluded that re-keying is possible for both valid and invalid certificates, but only during the validity of the service contract.
Microsec improved its CPS and slightly modified the requirements for the re-keying process. It clearly states that re-keying is possible for both valid and invalid certificates, but only during the validity of the service contract.
This practice is in accordance with RFC3647 and ETSI EN 319 411-1.

> ** The TSP shall ensure that the reusing procedure of all data fulfills
> the EVCG 11.14 and the CPS corresponds to these reusing requirements.
> [ETSI EN 319 411-1, REG-6.2.3-03]

According to Hungarian requirements, all validation result shall be re-validated before a qualified certificate is issued. During the validation process, Microsec only accepts validation data not older than 3 months.
Microsec improved its public documents to define this topic in more detail. Version 12 of public documents are effective from 2019-12-12.
The new documents have stricter requirements for re-use of validation data than EVG requires. Generally, Microsec repeats all the validation tasks when a certificate is re-issued. The only exception is when the new certificate is issued with the same expiry date as the original certificate in case of re-keying. In this case, the original validation results can be re-used.

> ** There are conflicts between Hungarian law and EV Guideline regarding
> to the witnessing the root ca key generation by a Qualified Auditor, the
> TSP must inform the CAB/Forum about this fact. [ETSI 319 411-1
> GEN-6.5.1-14], [BRG, 9.16.3], [EVCG, 8.1], [EVCG, 17.7]

The conflict concerns a qualified auditor checking the generation of the root CA key.
The Hungarian legislation requires the presence of two persons with special trusted roles but excludes the presence of any further persons. CABF BR requires the presence of a third person, such as a qualified auditor.
These requirements are contradictory and cannot be met at the same time.
Before generating ECC root keys in 2017, Microsec contacted the auditor and the Hungarian supervisory authority to discuss the issue. Based on the outcome of the discussion, Microsec decided to comply with the CABF BR requirement, and an auditor from TÜViT was present during the ECC root key generation process.
In addition, Microsec informed the Ministry of Interior about this conflict and asked them to change the Hungarian regulations.
Following the 2019 audit, Microsec discussed the situation with the auditor via email.
Finally, Microsec agreed with the auditor that there was no need to notify CABF, as Microsec complied with the CABF BR and EVG requirements.
In 2020, Microsec received a letter from the Ministry. We have been informed that the problematic regulation is about to change.

> ** The TSP shall present a mitigation plan to revoke and replace the
> non-conforming certificates with exponent 101. [ETSI EN 319 411-1,
> SDP-6.5.1-18]

The issue is related to keys generated onboard on a specific type of smartcard. The corresponding certificates had been issued to create qualified electronic signatures and authenticate clients. The keys were generated with a public exponent 101. This value does not meet the specification of ETSI TS 119 312, but it did not represent a security risk for the affected customers.

Microsec decided to generate new keypairs on the smartcards onboard with proper public exponent. Microsec developed a secure web platform and client application and has organized the entire process within a limited time frame.

The detailed mitigation plan was sent to TÜViT on 2019-10-24 and subsequently upgraded two times.
The whole process was performed according to the accepted mitigation plan.
The process in numbers is:

Total number of affected cards: 4380
Cardholder have seen the information web page: 3918
Cardholder have successfully downloaded the application: 3916
Cardholder have started running the application: 3898
Cardholder have successfully finished running the application: 3842
Cardholders with new certificates: 3821

3821 of 4380 cards have been successfully upgraded and can be used further.
559 cards have not been upgraded for different reasons. Some of the cardholders were unavailable, some of them had different technical problems and some of them terminated the service.
They are managed individually by the Microsec customer service.

Before 16:00 on 2019-12-09 all certificates with public exponent 101 have been revoked.

---------------------

The Audit letter also declares, that:

For all minor non-conformities, the remediation has been successfully checked by provided evidences.
This Audit Attestation has not recorded any incident.

> * The following minor non-conformities are listed in the 2019 EV
> attestation statement [10]:

https://www.tuvit.de/fileadmin/Content/TUV_IT/zertifikate/en/AA2019061201_Microsec-eSzignoRoot-CA-2017_EV-CAs_s.pdf

This is the period of time EV attestation letter for the new ECC root on 2019-06-12

This is the same document as included at the year 2018

> ** Documentation and implementation of the generation of the OCSP
> certificates within the BCP document shall be improved. [ETSI EN 319
> 401, Clause 7.11]

The generation of the OCSP certificates was changed, it was moved to another server. The actual version of the Business Continuity Plan contained the earlier server configuration and not the actual configuration.
Microsec reviewed the whole BCP document and corrected the fault in it.
Microsec held a training for the employees responsible for the maintenance of the BCP document, to ensure that it is kept up to date.

> ** Documentation and implementation of the internal guideline with
> regard to the verification of possible organizations shall be improved.
> [ETSI EN 319 411-1, Clause 6.2.2 a), g), i)] [EVCG, Clause 11.1.1, Point
> 1. (A)] [ETSI EN 319 411-1, Clause 6.2.2 a)]
>

The internal documents contain detailed guidelines on how to validate the data of an organization. Hungary has a national company registration system which contains all the data of the bigger private companies. The database is publicly available and contains the actual and authentic data of all the registered companies.

[Sándor dr. Szőke]

Dear All,

Microsec Ltd. is dedicated to comply with the standards and industry best practices at all times, including the applicable IETF RFCs, ETSI standards and technical specifications, CA/Browser Forum Baseline Requirements, Extended Validation Guidelines and Network Security Controls, as well as the Mozilla Root Store Policy and other root program policies. Being an EU-based Qualified Trust Service Provider, our trust services are regulated and nationally supervised under the Regulation (EU) No 910/2014 (eIDAS), which mandates the annual conformity assessment by an accredited conformity assessment body.

In order to comply with all the latest legal and technical requirements, our CP/CPS documents incorporate all requirements from the above mentioned applicable sources, and we actively monitor the updates of the IETF RFCs, ETSI standards, CA/Browser Forum documents and the Mozilla Root Store Policy and other root program policies. As changes in the totality of requirements occur quite frequently, we regularly update our practices and develop our systems to ensure compliance with the changes too. Our annual conformity assessment, performed by TÜV Informationstechnik GmbH (TÜViT), is always based on the current version of the standards, as detailed in the Audit Attestation.

Microsec greatly appreciates the detailed evaluation of our inclusion request, as well as the automated checks in the CCADB, since these enhance transparency and contribute to the security of the ecosystem. We welcome the opportunity to engage in the public discussion, to provide supporting information that none of the findings of the evaluation represent a significant risk for Mozilla users, and to take away any useful advice which might help us further improve our practices and documentation. Regarding the findings, please consider the information and explanations provided in our previous postings to this thread and several other threads, which are summarized in the following:

2020-03-09 - the thread was opened by Kathleen Wilson

2020-03-11 - First responses which were published one day later due to moderator approval delay.
At first, Microsec gave some background information regarding the relatively high number of audit findings:
https://groups.google.com/d/msg/mozilla.dev.security.policy/jRKOr4nvOfY/78T_0HWkAQAJ
Then, Microsec uploaded the first answers to the original ===Meh=== and ===Bad=== findings of Wayne:
https://groups.google.com/d/msg/mozilla.dev.security.policy/jRKOr4nvOfY/xNUov3WkAQAJ

2020-03-12 – Discussion to clarify the proper place of the Private Key Compromise information in CPS
https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/1L0crAafm30

2020-03-13 – Incident report about the Issuance of 2 IVCP precertificates without givenName, surName, localityName fields
https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/C8YdPLAmCOE

The evaluation of the issue runs according to the planned schedule.

2020-03-24 – Discussion: Microsec: Revoked subordinate CA certificates under the „Microsec e-Szigno Root CA 2009” root
https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/QqYm4BhFMHs

It is a complex issue and it is probably better to explain it in a separate discussion than as part of the present thread.
Wayne asked to transform this information into a formal incident report. Microsec will do it soon.


2020-03-24 - Short explanations for the year 2018 audit findings:
https://groups.google.com/d/msg/mozilla.dev.security.policy/jRKOr4nvOfY/iiMVWwQGBAAJ

2020-03-27 - Short explanations for the year 2019 audit findings:
https://groups.google.com/d/msg/mozilla.dev.security.policy/jRKOr4nvOfY/ofERMFLnAQAJ


We hope the above information reinforces that our procedures are reliable, and our certificates are trustworthy. We would like to thank Wayne, Matt, Ryan and all members of the forum for your valued feedback, which we can use as input to our continuous efforts to improve the clarity of our documentation and the high quality of our services. We remain open to constructive discussion regarding our inclusion request, as always.

[Sándor dr. Szőke]

I inform you that Microsec issued the new version of its public documents on 2020-05-26.

The information has already been updated in CCADB.

The actual links of the most relevant public documents are:

CP/CPS:
eIDAS conform Qualified Certificate for Website Authentication CP (EV):

https://static.e-szigno.hu/docs/hr--min--ssl--EN--v2.14.pdf

eIDAS conform Qualified Certificate for Website Authentication CPS (EV):

https://static.e-szigno.hu/docs/szsz--min--ssl--EN--v2.14.pdf

eIDAS conform Certificate for Website Authentication CP (DV, OV):

https://static.e-szigno.hu/docs/hr--fok--ssl--EN--v2.14.pdf

eIDAS conform Certificate for Website Authentication CPS (DV, OV):

https://static.e-szigno.hu/docs/szsz--fok--ssl--EN--v2.14.pdf


I also inform you, that our auditor issued the updated version of our Attestation Letter, which contains all the doppelganger certificates of our root certificate "Microsec e-Szigno Root CA 2009".
The new Attestation Letter is available on the following link from today:

https://www.tuvit.de/fileadmin/Content/TUV_IT/zertifikate/de/AA2019121301_Microsec-eSzignoRoot-CA-2009_V1.2_s.pdf

The new audit information will be added to CCADB soon.

[Sándor dr. Szőke]

The information has been updated.

There is no Microsec Audit Letter Validation Failure in CCADB.