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

[Matt Palmer via dev-security-policy]

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
> (“highprioritycertificateproblemrep...@e-szigno.hu”,
> “revocat...@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
> revocat...@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

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Ryan Sleevi via dev-security-policy]

Comments inline and snipped

On Mon, Mar 9, 2020 at 2:48 PM Kathleen Wilson via dev-security-policy <
dev-security-policy@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
> (“highprioritycertificateproblemrep...@e-szigno.hu”,
> “revocat...@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.

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

[Corey Bonnell via dev-security-policy]

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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Ryan Sleevi via dev-security-policy]

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  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.
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Sándor dr . Szőke via dev-security-policy]

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.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Sándor dr . Szőke via dev-security-policy]

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

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

[Ryan Sleevi via dev-security-policy]

Responses inline.

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

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

[Sándor dr . Szőke via dev-security-policy]

 
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 201

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

[Sándor dr . Szőke via dev-security-policy]

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 = i...@..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

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

[Sándor dr . Szőke via dev-security-policy]

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.


___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Ben Wilson via dev-security-policy]

Dear Sándor,

I have a couple of follow-up questions for Microsec.

There were some responses during the recent public discussion in which
Microsec indicated it would update its CPS(es).

When do you anticipate that this will occur?

Also, it is also unclear from the quoted thread below whether such updates
will include additions to section 1.5.2 as required by Section 4.9.3 of the
Baseline Requirements.

Could you please clarify if and when section 1.5.2 will be updated?

Thanks.

Sincerely yours,

Ben Wilson
Mozilla Root Program



   -

   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.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Sándor dr . Szőke via dev-security-policy]

Dear Ben,

I confirm that Microsec will correct all issues in the CP and CPS documents as 
promised during the public discussion.

Thanks to everyone who took the time to read Microsec CP and CPS and to comment 
on them.

If there are no more comments on the content of our CP and CPS documents in the 
public discussion, we will review the thread again and gather all the issues to 
be resolved. 
As usual, Microsec will review current versions of all applicable requirements 
for changes.

I confirm that the section 1.5.2 will be changed. The High Priority Certificate 
Problem Report will be reviewed and will be moved here from section 4.9.3.

Other issues I can see after a brief overview:
- Preliminary report in case of Certificate problem report in section 4.9.5
- correct the reference to section 1.3.1 instead of 1.2 in section 4.9.5
- review the email address validation rules in case of non-automatic validation 
procedure in section 3.2.7

I expect that Microsec will be able to do it within one week and will prepare 
the draft version of the public documents by the end of April.

We publish the drafts on our website and send them to the auditor and our 
supervisory authority at the same time.

This is followed by a 30-day commenting period during which anyone can comment 
on the planned changes. 
If significant issues arise during this period, the draft shall be amended and 
the 30 days shall begin again.
If there are no significant issues, the new document will enter into force by 
the end of May 2020. 

Please let us know if you expect us to take any further steps in this process.

Best regards,

Sándor

dr. Sándor Szőke
Microsec deputy director
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Ben Wilson via dev-security-policy]

In accordance with the CA inclusion process,[1] this is a summary of the
public discussion of Microsec’s application for inclusion of the e-Szigno
Root CA 2017 into the Mozilla root store, and to EV enable it and the
currently-included e-Szigno Root CA 2009. The request is documented in
Bugzilla #1445364.[2] The public discussion began on 9-March-2020.[3] The
email launching the public discussion and comments received during the
public discussion raised a number of issues, not all of which are itemized
here, including:

* the CPS was unclear about certificate problem reporting and revocation
request processing[4]; and

* Microsec has had systemic, standards-related non-conformities, e.g. Bug#
1622539[5], and needs to demonstrate better behavior in keeping up with and
complying with the CABF Baseline Requirements and root store policy.[6]

Microsec is resolving these concerns by:

- updating its CPS[7][8]; and

- committing to engage in better compliance with industry standards[9].

In my opinion Microsec has demonstrated sufficient response that we do not
need to remove Microsec from Mozilla’s root store. Therefore, once I am
satisfied after a review of the updated CPS, I am planning to recommend
that we approve the request to include the e-Szigno Root CA 2017
certificate and enable the websites trust bit. However, I plan to deny the
request for EV treatment for both root certificates. Microsec may re-apply
by filing a new request for EV treatment after they have demonstrated
improved compliance with the BRs and EV Guidelines.

I appreciate any feedback on this proposed course of action.

[1] https://wiki.mozilla.org/CA/Application_Process#Process_Overview

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

[3]
https://groups.google.com/d/msg/mozilla.dev.security.policy/jRKOr4nvOfY/QrhdAWq_AAAJ

[4]
https://groups.google.com/d/msg/mozilla.dev.security.policy/jRKOr4nvOfY/KN-gnSLLAAAJ


[5] https://bugzilla.mozilla.org/show_bug.cgi?id=1622539

[6]
https://groups.google.com/d/msg/mozilla.dev.security.policy/jRKOr4nvOfY/T7hcaOYGAQAJ


[7]
https://groups.google.com/d/msg/mozilla.dev.security.policy/rHTmKOzspCo/pyZKc40_CQAJ


[8]
https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/1L0crAafm30


[9]
https://groups.google.com/d/msg/mozilla.dev.security.policy/jRKOr4nvOfY/mNFZGgXBAgAJ



On Mon, Apr 20, 2020 at 5:44 AM Sándor dr. Szőke via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

>
> Dear Ben,
>
> I confirm that Microsec will correct all issues in the CP and CPS
> documents as promised during the public discussion.
>
> Thanks to everyone who took the time to read Microsec CP and CPS and to
> comment on them.
>
> If there are no more comments on the content of our CP and CPS documents
> in the public discussion, we will review the thread again and gather all
> the issues to be resolved.
> As usual, Microsec will review current versions of all applicable
> requirements for changes.
>
> I confirm that the section 1.5.2 will be changed. The High Priority
> Certificate Problem Report will be reviewed and will be moved here from
> section 4.9.3.
>
> Other issues I can see after a brief overview:
> - Preliminary report in case of Certificate problem report in section 4.9.5
> - correct the reference to section 1.3.1 instead of 1.2 in section 4.9.5
> - review the email address validation rules in case of non-automatic
> validation procedure in section 3.2.7
>
> I expect that Microsec will be able to do it within one week and will
> prepare the draft version of the public documents by the end of April.
>
> We publish the drafts on our website and send them to the auditor and our
> supervisory authority at the same time.
>
> This is followed by a 30-day commenting period during which anyone can
> comment on the planned changes.
> If significant issues arise during this period, the draft shall be amended
> and the 30 days shall begin again.
> If there are no significant issues, the new document will enter into force
> by the end of May 2020.
>
> Please let us know if you expect us to take any further steps in this
> process.
>
> Best regards,
>
> Sándor
>
> dr. Sándor Szőke
> Microsec deputy director
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Sándor dr . Szőke via dev-security-policy]

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.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Ben Wilson via dev-security-policy]

I have now reviewed Microsec's updated CPS for OV and DV.  I am not going
to hold up approval of the inclusion of this root for the following
reasons, which I believe are relatively minor, but Microsec should be aware
that:

   - section 3.1.1 of Microsec's "eIDAS conform Certificate for Website
   Authentication CPS" (
   https://static.e-szigno.hu/docs/szsz--fok--ssl--EN--v2.14.pdf) ("the
   CPS") appears to allow certain identifiers, allowed for EV, but not yet
   added to the Baseline Requirements, see
   
https://cabforum.org/2019/05/21/ballot-sc17-version-7-alternative-registration-numbers-for-ev-certificates/.
   This is something that should be taken up with the CA/Browser Forum (and
   corrected in Microsec's CPS); and
   - section 4.9.5 of the CPS, which states, "Emails arriving out of office
   hours are considered as arrived at the beginning of the next business day."
   This may put Microsec at risk of a violation of the Baseline Requirements
   sections 4.9.1 through 4.9.5. While "receipt" (or "arrival") is not yet
   defined in the Baseline Requirements, there is an expectation of 24x7
   availability, which it appears Microsec is providing - "The Trust Service
   Provider maintains a continuous 24x7 ability to respond internally to a
   High Piority Certificate Problem Report."

This concludes my review of the Microsec CPs/CPSes, and I believe it is now
appropriate to begin the process of adding this root CA into NSS (without
EV enablement).

On Thu, May 28, 2020 at 1:00 PM Ben Wilson  wrote:

> In accordance with the CA inclusion process,[1] this is a summary of the
> public discussion of Microsec’s application for inclusion of the e-Szigno
> Root CA 2017 into the Mozilla root store, and to EV enable it and the
> currently-included e-Szigno Root CA 2009. The request is documented in
> Bugzilla #1445364.[2] The public discussion began on 9-March-2020.[3] The
> email launching the public discussion and comments received during the
> public discussion raised a number of issues, not all of which are itemized
> here, including:
>
> * the CPS was unclear about certificate problem reporting and revocation
> request processing[4]; and
>
> * Microsec has had systemic, standards-related non-conformities, e.g. Bug#
> 1622539[5], and needs to demonstrate better behavior in keeping up with and
> complying with the CABF Baseline Requirements and root store policy.[6]
>
> Microsec is resolving these concerns by:
>
> - updating its CPS[7][8]; and
>
> - committing to engage in better compliance with industry standards[9].
>
> In my opinion Microsec has demonstrated sufficient response that we do not
> need to remove Microsec from Mozilla’s root store. Therefore, once I am
> satisfied after a review of the updated CPS, I am planning to recommend
> that we approve the request to include the e-Szigno Root CA 2017
> certificate and enable the websites trust bit. However, I plan to deny
> the request for EV treatment for both root certificates. Microsec may
> re-apply by filing a new request for EV treatment after they have
> demonstrated improved compliance with the BRs and EV Guidelines.
>
> I appreciate any feedback on this proposed course of action.
>
> [1] https://wiki.mozilla.org/CA/Application_Process#Process_Overview
>
> [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1445364
>
> [3]
> https://groups.google.com/d/msg/mozilla.dev.security.policy/jRKOr4nvOfY/QrhdAWq_AAAJ
>
> [4]
> https://groups.google.com/d/msg/mozilla.dev.security.policy/jRKOr4nvOfY/KN-gnSLLAAAJ
>
>
> [5] https://bugzilla.mozilla.org/show_bug.cgi?id=1622539
>
> [6]
> https://groups.google.com/d/msg/mozilla.dev.security.policy/jRKOr4nvOfY/T7hcaOYGAQAJ
>
>
> [7]
> https://groups.google.com/d/msg/mozilla.dev.security.policy/rHTmKOzspCo/pyZKc40_CQAJ
>
>
> [8]
> https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/1L0crAafm30
>
>
> [9]
> https://groups.google.com/d/msg/mozilla.dev.security.policy/jRKOr4nvOfY/mNFZGgXBAgAJ
>
>
>
> On Mon, Apr 20, 2020 at 5:44 AM Sándor dr. Szőke via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
>>
>> Dear Ben,
>>
>> I confirm that Microsec will correct all issues in the CP and CPS
>> documents as promised during the public discussion.
>>
>> Thanks to everyone who took the time to read Microsec CP and CPS and to
>> comment on them.
>>
>> If there are no more comments on the content of our CP and CPS documents
>> in the public discussion, we will review the thread again and gather all
>> the issues to be resolved.
>> As usual, Microsec will review current versions of all applicable
>> requirements for changes.
>>
>> I confirm that the section 1.5.2 will be changed. The High Priority
>> Certificate Problem Report will be reviewed and will be moved here from
>> section 4.9.3.
>>
>> Other issues I can see after a brief overview:
>> - Preliminary report in case of Certificate problem report in section
>> 4.9.5
>> - correct the reference to section 1.3.1 instead of 1.2 in sec

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

[Ben Wilson via dev-security-policy]

Having received no further comments, I have recommended approval of this
request in bug 1445364


- Ben

On Tue, Jun 2, 2020 at 1:57 PM Ben Wilson  wrote:

> I have now reviewed Microsec's updated CPS for OV and DV.  I am not going
> to hold up approval of the inclusion of this root for the following
> reasons, which I believe are relatively minor, but Microsec should be aware
> that:
>
>- section 3.1.1 of Microsec's "eIDAS conform Certificate for Website
>Authentication CPS" (
>https://static.e-szigno.hu/docs/szsz--fok--ssl--EN--v2.14.pdf) ("the
>CPS") appears to allow certain identifiers, allowed for EV, but not yet
>added to the Baseline Requirements, see
>
> https://cabforum.org/2019/05/21/ballot-sc17-version-7-alternative-registration-numbers-for-ev-certificates/.
>This is something that should be taken up with the CA/Browser Forum (and
>corrected in Microsec's CPS); and
>- section 4.9.5 of the CPS, which states, "Emails arriving out of
>office hours are considered as arrived at the beginning of the next
>business day." This may put Microsec at risk of a violation of the Baseline
>Requirements sections 4.9.1 through 4.9.5. While "receipt" (or "arrival")
>is not yet defined in the Baseline Requirements, there is an expectation of
>24x7 availability, which it appears Microsec is providing - "The Trust
>Service Provider maintains a continuous 24x7 ability to respond internally
>to a High Piority Certificate Problem Report."
>
> This concludes my review of the Microsec CPs/CPSes, and I believe it is
> now appropriate to begin the process of adding this root CA into NSS
> (without EV enablement).
>
> On Thu, May 28, 2020 at 1:00 PM Ben Wilson  wrote:
>
>> In accordance with the CA inclusion process,[1] this is a summary of the
>> public discussion of Microsec’s application for inclusion of the e-Szigno
>> Root CA 2017 into the Mozilla root store, and to EV enable it and the
>> currently-included e-Szigno Root CA 2009. The request is documented in
>> Bugzilla #1445364.[2] The public discussion began on 9-March-2020.[3] The
>> email launching the public discussion and comments received during the
>> public discussion raised a number of issues, not all of which are itemized
>> here, including:
>>
>> * the CPS was unclear about certificate problem reporting and revocation
>> request processing[4]; and
>>
>> * Microsec has had systemic, standards-related non-conformities, e.g.
>> Bug# 1622539[5], and needs to demonstrate better behavior in keeping up
>> with and complying with the CABF Baseline Requirements and root store
>> policy.[6]
>>
>> Microsec is resolving these concerns by:
>>
>> - updating its CPS[7][8]; and
>>
>> - committing to engage in better compliance with industry standards[9].
>>
>> In my opinion Microsec has demonstrated sufficient response that we do
>> not need to remove Microsec from Mozilla’s root store. Therefore, once I am
>> satisfied after a review of the updated CPS, I am planning to recommend
>> that we approve the request to include the e-Szigno Root CA 2017
>> certificate and enable the websites trust bit. However, I plan to deny
>> the request for EV treatment for both root certificates. Microsec may
>> re-apply by filing a new request for EV treatment after they have
>> demonstrated improved compliance with the BRs and EV Guidelines.
>>
>> I appreciate any feedback on this proposed course of action.
>>
>> [1] https://wiki.mozilla.org/CA/Application_Process#Process_Overview
>>
>> [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1445364
>>
>> [3]
>> https://groups.google.com/d/msg/mozilla.dev.security.policy/jRKOr4nvOfY/QrhdAWq_AAAJ
>>
>> [4]
>> https://groups.google.com/d/msg/mozilla.dev.security.policy/jRKOr4nvOfY/KN-gnSLLAAAJ
>>
>>
>> [5] https://bugzilla.mozilla.org/show_bug.cgi?id=1622539
>>
>> [6]
>> https://groups.google.com/d/msg/mozilla.dev.security.policy/jRKOr4nvOfY/T7hcaOYGAQAJ
>>
>>
>> [7]
>> https://groups.google.com/d/msg/mozilla.dev.security.policy/rHTmKOzspCo/pyZKc40_CQAJ
>>
>>
>> [8]
>> https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/1L0crAafm30
>>
>>
>> [9]
>> https://groups.google.com/d/msg/mozilla.dev.security.policy/jRKOr4nvOfY/mNFZGgXBAgAJ
>>
>>
>>
>> On Mon, Apr 20, 2020 at 5:44 AM Sándor dr. Szőke via dev-security-policy <
>> dev-security-policy@lists.mozilla.org> wrote:
>>
>>>
>>> Dear Ben,
>>>
>>> I confirm that Microsec will correct all issues in the CP and CPS
>>> documents as promised during the public discussion.
>>>
>>> Thanks to everyone who took the time to read Microsec CP and CPS and to
>>> comment on them.
>>>
>>> If there are no more comments on the content of our CP and CPS documents
>>> in the public discussion, we will review the thread again and gather all
>>> the issues to be resolved.
>>> As usual, Microsec will review current versions of all applicable
>>> requirements for changes.
>>>
>>> I confirm th

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

[Kathleen Wilson via dev-security-policy]

On 6/4/20 11:17 AM, Ben Wilson wrote:

Having received no further comments, I have recommended approval of this
request in bug 1445364


- Ben




To clarify, Ben is recommending approval of the request to include the 
e-Szigno Root CA 2017 certificate and enable the websites trust bit.


However, he has recommended that we deny the request for EV treatment 
for both root certificates. Microsec may re-apply by filing a new 
request for EV treatment after they have demonstrated improved 
compliance with the BRs and EV Guidelines.


Reference: 
https://groups.google.com/d/msg/mozilla.dev.security.policy/rHTmKOzspCo/yLTkQ25uAAAJ


Thanks,
Kathleen
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Sándor dr . Szőke via dev-security-policy]

The information has been updated.

There is no Microsec Audit Letter Validation Failure in CCADB.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy