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
_______________________________________________
dev-security-policy mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-security-policy
