A-Trust Root Renewal Request

[Kathleen Wilson]

This request is to include the ‘A-Trust-Root-05’ root certificate, turn
on the Websites trust bit, and enable EV treatment. This new root
certificate will replace the ‘A-Trust-nQual-03’ root certificate that
was included via Bugzilla Bug #530797. The ‘A-Trust-nQual-03’ root
certificate expired, so it was removed via Bugzilla Bug #1204997.

A-Trust’s product range comprises user certificates, developer
certificates and corporate certificates as well as consultation services
and support with the development of e-commerce and signature
applications in accordance with the Directive 1999/93/EC. A-Trust’s CA
hierarchy is used to issue Austrian Citizen Cards and A-Trust SSL
certificates.

The request is documented in the following bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=1092963

And in the pending certificates list:
https://wiki.mozilla.org/CA:PendingCAs

Summary of Information Gathered and Verified:
https://bugzilla.mozilla.org/attachment.cgi?id=8668186

Noteworthy points:


* The primary documents are the CP and CPS, provided in German, with
some translations into English.

Document Repository: http://www.a-trust.at/ATrust/Downloads.aspx
CP: https://www.a-trust.at/docs/cp/a-sign-ssl-ev/a-sign-ssl-ev.pdf
CPS: https://www.a-trust.at/docs/cps/a-sign-ssl-ev/a-sign-ssl-ev_cps.pdf

* CA Hierarchy: This root has internally-operated subordinate CAs:
- a-sign-SSL-05 (http://www.a-trust.at/certs/a-sign-ssl-05.crt)
- a-sign-SSL-EV-05 (http://www.a-trust.at/certs/a-sign-ssl-ev-05.crt)

* This request is to turn on the Websites trust bit, and enable EV
treatment.

Translation of EV SSL CPS sections 3.1.7, 3.1.8, and 3.1.9:
https://bug1092963.bugzilla.mozilla.org/attachment.cgi?id=8584406

3.1.7 Authentication of organisations
When ordering an a.sign SSL EV certficate, the domain and organisation
has to be verified. If the ordering entity is registered in either the
austrian commercial register or the European Business Register (EBR),
A-Trust verifies the existence using the online - database of those
registers. The registration number has to be inlcuded in the request.
The physical address is also verified using the offical register. If not
applicable, the check is performed using a duplicate of a document that
confirms the organisations existence. Examples for such documents are
extracts from legal registers or databases of trusted third parties.
The checks are performed according to the requirements in EV-GL
(guidelines v1.2, CAB Forum), section 10.

In case an a.sign SSL EV certificate is order, additional information
has to be gathered:
# confirmation issued by the bank of the ordering organisation,
confirming the existance of an account related to the organisation
# annual statement of the organisation, verified by a certified accountant
# if an exchange embargos exist (inqury at responsible entity in the
applicants country through A-Trust)
# verification of the physical address. If the address provided in the
legal register used for verification of the organisation is also stated
in the annual statement gathered in point 2, the physical address is
considered correct. If these requirements are not met, verification can
only be achieved through a check on location. Possible costs of this
check are charged to the applicant. Further information can be found at
EV-GL, section 10.4.1.

If an entire obtaining of all required information is not possible
within a reasonable amount of time, the application is rejected and the
applicant will be informed.

3.1.8 Check of Domain or IP Address
The holder of a domain is verified using the databases provided by the
applicable authority (such as www.nic.at, www.denic.de,...).
The use of IP adresses in EV certficates is not permitted.

3.1.9 Authentication of individuals
The individuals, who are audited in the process of issuing an a.sign SSL
EV certificate are
# the domain owner
and, if the domain order is acting in the name of an organisation
# an organisational responsible person, that is allowed to sign in the
ogranisations name and confirms the correctness of the application
The people that are mentioned in the application have to provide an
identification document (i.e. passport).
If the organisational responsible person is not listed in the used
register, additional confirmation of his status has to be provided (i.e.
a certificate of authority).

* Root Certificate Download URL:
http://www.a-trust.at/certs/A-Trust-Root-05.crt

* EV Policy OID: 1.2.40.0.17.1.22

* Test Website: https://ca-train.a-trust.at/

* CRL URLs:
http://crl.a-trust.at/crl/A-Trust-Root-05
http://crl.a-trust.at/crl/a-sign-SSL-EV-05

* OCSP URL:
http://ocsp.a-trust.at/ocsp
Max expiration time of OCSP responses: 10 minutes

* Audit: Annual audits are performed by Ernst & Young, according to the
WebTrust criteria.
Standard Audit: https://cert.webtrust.org/SealFile?seal=1932&file=pdf
BR Audit: https://cert.webtrust.org/SealFile?seal=1934&file=pdf
EV Audit: https://cert.webtrust.org/SealFile?seal=1933&file=pdf

* Potentially Problematic Practices: None Noted
(http://wiki.mozilla.org/CA:Problematic_Practices)

This begins the discussion of the request from A-Trust to include the
‘A-Trust-Root-05’ root certificate, turn on the Websites trust bit, and
enable EV treatment.

At the conclusion of this discussion I will provide a summary of issues
noted and action items. If there are outstanding issues, then an
additional discussion may be needed as follow-up. If there are no
outstanding issues, then I will recommend approval of this request in
the bug.

Kathleen

[Charles Reiss]

On 02/09/16 01:22, Kathleen Wilson wrote:
> This request is to include the ‘A-Trust-Root-05’ root certificate, turn
> on the Websites trust bit, and enable EV treatment. This new root
> certificate will replace the ‘A-Trust-nQual-03’ root certificate that
> was included via Bugzilla Bug #530797. The ‘A-Trust-nQual-03’ root
> certificate expired, so it was removed via Bugzilla Bug #1204997.

[snip]

> * CA Hierarchy: This root has internally-operated subordinate CAs:
> - a-sign-SSL-05 (http://www.a-trust.at/certs/a-sign-ssl-05.crt)

These certificates were issued last year for the internal name 'TRUE'
and are valid until at least 2018 (well past the deadline for internal
names under the BRs):
https://crt.sh/?dnsname=True&iCAID=5662

These were issued last year for the internal name '1' and are valid
until at least 2017 (still well past the deadline):
https://crt.sh/?dnsname=1&iCAID=5662

>From those internal name certificates above, these certificates are
valid from 2015 until 2020, which is longer than the 39 months allowed
under the BRs:
https://crt.sh/?id=8991758&opt=cablint
https://crt.sh/?id=9123894&opt=cablint

This certificate was issued last year for the internal name 'BSB-oenb'
and is valid from 2015 until 2020:
https://crt.sh/?id=10540258&opt=cablint

These certificates also seem to lack the at least 20 bits of entropy in
the certificate serial number that the BRs recommend in section 7.1.

> - a-sign-SSL-EV-05 (http://www.a-trust.at/certs/a-sign-ssl-ev-05.crt)

CT appears to know about several other subCAs; see child CAs here:
https://crt.sh/?caid=5661

My assumption is that the other subCAs are not supposed to issue SSL
certificates however, they still need to be in scope as they do not
appear technically constrained from doing so (e.g. by extendedKeyUsage).
(However, it appears that the prior root's subCA
a-sign-corporate-light-03 issued TLS server certificates (e.g.
https://crt.sh/?id=5669744&opt=cablint) and it is presumably similar to
a-sign-corporate-05.)

[Jesus F]

Dear all,

As A-Trust request EV treatment, I checked the EV issued certificates from a-sign-SSL-EV-05 subordinate in ctr.sh (https://crt.sh/?Identity=%25&iCAID=6096)

ALL of them states in businessCategory the following text "V1.0, Clause 5.(X)". This text is similar to what permitted by EV guidelines version 1.2 and prior, although "X" should have been "b", "c", "d" or "e" depending upon whether the Subject qualifies in the permitted categories. This text is not permitted since EV guidelines version 1.3 published in 2010.

As the EV audit conducted by E&Y states A-trust is in compliance with "WebTrust Principles and Criteria for Certification Authorities - Extended Validation SSL - Version 1.4.5" that is based on CA/Browser Forum Guidelines for the Issuance and Management of Extended Validation SSL Certificates - Version 1.4.5 and it's obvious that the auditor failed to detect this very basic issue, can we, the Mozilla Community, be reasonably assured of any of the auditor's necessary checks?

In addition there are several more issues in this certificates:

- rfc822Name in SAN (https://crt.sh/?id=8889537&opt=cablint, https://crt.sh/?id=8889537&opt=cablint)
- FATAL: ASN.1 Error in EmailAddress (https://crt.sh/?id=12491213&opt=cablint, https://crt.sh/?id=9410992&opt=cablint)
- This cert has the following errors: Cert without subject alternative names extension, Cert of 1024 bits (https://crt.sh/?id=8935972&opt=cablint)

Best,
J

[Erwann Abalea]

Bonjour,

Without saying that the audit was perfect, but all the presented evidences here have been produced after the audit was performed.

[Jesus F]

Thanks Mr Erwann Abalea to bring this to our (my) attention.

As the A-trust EV audit report do not include any CA in scope and only states "for its Certification Authority (CA) operations at Vienna"... Should we consider this audit includes all roots and subordinates?

I can not find any EV certificate issued by a-sign-SSL-EV-05 during the audit period, but I am afraid this is a common practice due all certificates contains the same businessCategory text and because I found EV certificates issued by "a-sign-SSL-EV-03" from other A-trust hierarchy (Sorry for including other A-trust hierarchy in this public discussion but it's just to illustrate my comment) that also includes the same businessCategory text issued during the audit period report.

Examples:
https://www.a-trust.at/DesktopModules/LdapSuche/Download.aspx?type=downloadCert&cert=1468071
https://www.a-trust.at/DesktopModules/LdapSuche/Download.aspx?type=downloadCert&cert=1352665

As I comment in last post, the permitted text on the businessCategory changed on EV Guidelines 1.3 (2010).
How auditors could not detect this basic issue? And A-trust, why your internal procedures fail to align the EV profile for 5 years?

Best
J

[Matt Palmer]

On Tue, Feb 09, 2016 at 04:24:22AM -0800, Erwann Abalea wrote:
> Bonjour,
>
> Le mardi 9 février 2016 10:47:16 UTC+1, Jesus F a écrit :

> Without saying that the audit was perfect, but all the presented evidences here have been produced after the audit was performed.

I may be misunderstanding the purpose of an audit, but doesn't the fact that
the evidence was created after the audit was performed show that the audit
was, in fact, insufficient? To my way of thinking, an audit is supposed to
verify that things can *only* be done in a conformant manner -- that is,
that there are procedures and controls in place to prevent Bad Things from
happening. In this case, it is fairly clear that Bad Things have, in fact,
happened, based on the existence of certificates issued in contravention of
the BRs. Thus, the CA's procedures are insufficient, and the audit *should*
have found that, or else the audit is useless and unnecessary, and we should
just rely on catching bad happenings after the fact via CT.

- Matt

[Jakob Bohm]

With any kind of audit (whether of fiscal accounting or other things),
expecting the auditor to be able to foresee any potential future mishap
leads to madness and meaningless audit elements (such as the
requirement in current legislation that company auditors should assess
and publish if they believe the company will survive the coming year).

What an auditor can reasonably check (without resorting to potentially
disastrous pen-testing), is if the current official (written) internal
procedures are correct, if the CA private key is stored in a certified
secure way, if the systems that actually sign certificate requests are
in a locked room with physical mechanisms to ensure two authorized
persons have to enter together. The auditor can and should also check
that records of past (public and private) activities are being
correctly maintained, are up to date, are consistent with the
observable current state of things etc. For instance the auditor can
check if the set of software changes/patches/updates installed
corresponds to the list of software changes in the written maintenance
log.

But the auditor cannot be expected to do things such as:
- Debug or verify the code in any commercial or in-house software and
scripts used to run the CA (he may be able to check if requirements
for 3rd party validations, such as FIPS 140-2 in US gov CAs are met
by checking if the certification documentation is in place).
- Make obviously invalid certificate requests to check if this such
requests are spotted and rejected.
- Test the CA's web interface for XSS or SQL injection bugs.
- If any of the authorized people are stupid in any but the most
glaringly obvious way.

Note for clarity, that unlike the audits of published procedures (CP,
CPS etc.) done in this forum, an auditor can check if the more detailed
internal procedure documents are consistent with the published
documents and the applicable standard(s). For instance the auditor has
the right and duty to access and check documents that reveal exactly
who in the CA organization checks what aspect of a request, how they
perform any additional checks to catch fraudulent requests that somehow
manage to fake the checks that are listed in the CP/CPS documents etc.

For example a CA may have a special permission and procedure to
directly check certain government records of applicants, even though
the published procedures say the applicant must provide a certified
copy. This would catch a fraudulent application accompanied by a
perfectly forged certified copy of such records.


Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

[Christoph Klein]

Dear All!

Thank you for contributing in our discussion and illustrate some existing problems with our certificates. I would like to address the stated points seperatley.

* Wrong CNs in Subject (1, True, BSB-oenb): This was an issue that arose with the switch to SHA-256 certificates in combination with OIDs for administrative certificates. The problem is fixed and new certificates will not be affected. We have already contacted the customers and will replace all the issued certificates within the next week.

* Certifcates with a validty larger than 39 months were issued for a short time and are already being replaced, the old certificates will be revoked shortly.

* 20 Bits of Entropy: the Serialnumber included in the Subject of our SSL - certificatges is randomly generated

* V Clause (X): We analyzed this problem and found an issue, where the variable wasn't transfered into the final certificate. This bug has been around since our first issued EV certificate and wasn't noticed until now. The problem is fixed, new certificates will replace the x with the proper letter.

* rfc822 Name in SAN / ANS1 Error: we will not add any more E-Mail Addresses in the SAN or the subject.

Regards,
Christoph Klein
A-Trust GmbH

[Charles Reiss]

On 02/12/16 14:26, Christoph Klein wrote:
> Dear All!
>
> Thank you for contributing in our discussion and illustrate some
> existing problems with our certificates. I would like to address the
> stated points seperatley.

[snip]

> * 20 Bits of Entropy: the Serialnumber included in the Subject of our
> SSL - certificatges is randomly generated

When you reissue a certificate for the same subject, you appear to reuse
the same serial number (see, e.g., https://crt.sh/?id=12740856 and
https://crt.sh/?id=1659927). This makes sense for a subject's serial
number, but means that the random value does not serve the purpose of
making chosen-prefix collision attacks more difficult when a subscriber
requests a renewed certificate.

Also, in EV certificates, this subject serialNumber field number field
represents the registration number of the subject, so those certificates
do not seem to have added entropy at all.

>
> * V Clause (X): We analyzed this problem and found an issue, where
> the variable wasn't transfered into the final certificate. This bug
> has been around since our first issued EV certificate and wasn't
> noticed until now. The problem is fixed, new certificates will
> replace the x with the proper letter.

Given that every EV certificate you issued had this error, and you have
been issuing EV certificates since at least 2013 (from your old root),
how was this error not detected by the self-audit you are required to
perform of 'a randomly selected sample of at least three percent of the
EV Certificates'?

[snip]

[Jesus F]

Dear Mr Christoph Klein,

>>* V Clause (X): We analyzed this problem and found an issue, where the variable wasn't transfered into the final certificate. This bug has been around since our first issued EV certificate and wasn't noticed until now. The problem is fixed, new certificates will replace the x with the proper letter.

>>>Given that every EV certificate you issued had this error, and you have
been issuing EV certificates since at least 2013 (from your old root),
how was this error not detected by the self-audit you are required to
perform of 'a randomly selected sample of at least three percent of the
EV Certificates'?

This text is not permitted since EV guidelines version 1.3, published in 2010.

Please, read the "Guidelines For The Issuance And Management Of Extended Validation Certificates" (https://cabforum.org/wp-content/uploads/EV-V1_5_7.pdf)

Section 9.2.4:
Certificate field: subject:businessCategory (OID: 2.5.4.15)
Required/Optional: Required
Contents: This field MUST contain one of the following strings: "Private Organization", "Government Entity", "Business Entity", or "Non-Commercial Entity" depending upon whether the Subject qualifies under the terms of Section 8.5.2, 8.5.3, 8.5.4 or 8.5.5 of these Guidelines, respectively.

Best,
J

[Christoph Klein]

Dear All!

We have used the last week to address all the issues:

* all the certificates with problems (CN, validty) have been replaced with our customers

* the field for the business Category has been changed to only accept the valid strings

* to avoid problems with replacmenet certificates that had the same serial number in the subject, we have implemented a longer serial number in the dedicated field, that fulfills the 20 Bits of Entropy requirement and is completely random

To prevent future problems with values in the certficate fields, we have implemented another layer of cross checks after the issuing of the certificate. Until now, the checks performed by the agent have been verified by a second agent, who wasn't involved in the process until then. We will now perform another check after each certificate hast been issued and before it is sent to the customer. This check includes: used domains and values in cn / Subject Alternativ Name, key length, business category, general integrity of als values in the Subject, validity period and lenght of the serial number. We hope to avoid issues as found in this thread and I would like to thank everybody for pointing them out.

[Matt Palmer]

On Fri, Feb 26, 2016 at 06:22:22AM -0800, Christoph Klein wrote:
> To prevent future problems with values in the certficate fields, we have
> implemented another layer of cross checks after the issuing of the
> certificate.

Shouldn't you be doing the checking *before* you issue the certificate? It
seems wasteful and risky to issue the certificate and only then make sure it
should have been issued before sending it to the customer.

- Matt

[Christoph Klein]

Yes, the new check happens after we issued the certificate to make sure, that the final content of the certificate matches the data gathered and checked in the "first round", before the issuing.

This will be done in addition to the checks before, not instead.

[thelt...@hotmail.com]

I believe this is just a misunderstanding/confusion here as to the term "issue". Because if you look at the sentence after your quote it cleary comes out that this check is performed *before* sending the certificate to the customer. So it seems by "issue" "creation" is meant, not the sending to the customer. But I am sure Mr Klein will clarify this.

[Matt Palmer]

On Sun, Feb 28, 2016 at 10:40:36PM -0800, thelt...@hotmail.com wrote:
> Am Sonntag, 28. Februar 2016 00:31:48 UTC+1 schrieb Matt Palmer:

> I believe this is just a misunderstanding/confusion here as to the term
> "issue". Because if you look at the sentence after your quote it cleary
> comes out that this check is performed *before* sending the certificate to
> the customer. So it seems by "issue" "creation" is meant, not the sending
> to the customer. But I am sure Mr Klein will clarify this.

Certificate issuance happens when the certificate is created, not when it's sent to
the customer.

- Matt

[Christoph Klein]

Maybe a "Timeline" could help here:

* the customer orders the certificate
* the agent gathers all the necessary information from various sources
* once everything is available, another agent verifies the data (first check)
* the certificate is issued / created
* new second check that compares information gathered with the content of the issued certificate
* certificate is sent to the customer

The additional new check counters the issues that were raised in this thread about the wrong business category or possible problems that arise during the creation process, not the data gathering (this part is still covered in the first check before the issuance).

[thelt...@hotmail.com]

Hallo!

Is there any reason why this request is not proceeded?

[mcu...@gmail.com]

Hi,
can someone explain to a non security expert, why A-Trust is still not in the inclusion phase? This bug-report goes over a year now. Is A-Trust not cooperating promptly and correctly? Is Mozilla working too slow? I really don't understand that...

[Peter Bowen]

On Fri, Mar 25, 2016 at 7:33 AM, <mcu...@gmail.com> wrote:
> can someone explain to a non security expert, why A-Trust is still not in the inclusion phase? This bug-report goes over a year now. Is A-Trust not cooperating promptly and correctly? Is Mozilla working too slow? I really don't understand that...

https://bugzilla.mozilla.org/show_bug.cgi?id=1092963 tracks the
inclusion request. From a quick review of the comments:
It was opened on 2014-11-03.
On 2014-11-04, Mozilla requested further information.
On 2015-08-27, A-Trust appears to have finished providing information
On 2015-09-30, it was confirmed that A-Trust had completed the initial
phase and it was added to the queue for discussion
On 2016-02-08, discussion opened.

This is a little longer than listed on the wiki
(https://wiki.mozilla.org/CA:How_to_apply#Timeline), but not notable
longer than other CAs take.

[Andrew Whalley]

Hello,

Given the numerous problems discovered so far, including several that contract the explicit declaration made to Mozilla [1], I would not feel comfortable supporting the application at this juncture.

My next step would be to go though the CP/CPS with a fine-tooth comb, but alas my schoolboy German isn't up to the task. I would be most grateful if a translation into English - attested as accurate by A-Trust - could be made available.

I also note the test site https://ca-train.a-trust.at is unreachable.

Cheers,

Andrew

[1] See the "CA's Response to Problematic Practices" section of https://bugzilla.mozilla.org/attachment.cgi?id=8668186)

[Kathleen Wilson]

This discussion will be on hold until the CA provides translations (into English) of the *new* CP and CPS documents pertaining to the 'A-Trust-Root-05' root certificate, non-EV TLS/SSL certificates, and EV TLS/SSL certificates. (i.e. the version of the documents that are being used for the audit covering the period of March 2015 through February 2016.

This discussion may proceed after the CA provides the translated documents.

Thanks,
Kathleen

[thelt...@hotmail.com]

A-Trust, are you in any way still doing something in this issue?