530797 - Add Root CA "A-Trust" to trusted list

Status: RESOLVED FIXED

(CA Program :: CA Certificate Root Program, task)

Description

[Ramin Sabet]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.1.5) Gecko/20091102 Firefox/3.5.5 (.NET CLR 3.5.30729)
Build Identifier: Firefox v3.5.5, German

We have finished the WebTrust for Certification Authorities Program with our Auditor Ernst&Young and will receive the final report in the next weeks.

(Superseeds Bug 252610 and Bug 373746)

As soon as we receive the Management Assertion, we will attach/link to it.

CP:  http://www.a-trust.at/docs/cp/a-sign-ssl/a-sign-ssl.pdf
CPS: http://www.a-trust.at/docs/cps/a-sign-ssl/a-sign-ssl_cps.pdf

The certificate hierarchy:
a-trust-nQual-03   (http://www.a-trust.at/certs/A-Trust-nQual-03.crt)
   a-sign-SSL-03   (http://www.a-trust.at/certs/a-sign-ssl-03.crt)
       User certificates (eg.: ssl certificate found on https://www.a-trust.at)

Reproducible: Always

Steps to Reproduce:
1. Visit https://www.a-trust.at 
2. Server Certificate is not trusted
3.
Actual Results:  
Server Certificate is not trusted

Expected Results:  
Certificate is trusted

About A-Trust

a.trust (founded in February 17, 2000) ist the only accredited TrustCenter in 
Austria issuing smartcard based qualified certificates for Austrian citizen 
used in eGovernment, etc.

In March 11, 2002 A-Trust has been accredited according to § 17 of the 
Austrian Signature Law by Telekom-Control-Kommission, the Austrian supervisory 
body.

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.

Comment 1

[Kathleen Wilson]

Starting the Information Gathering and Verification phase as per:
https://wiki.mozilla.org/CA:How_to_apply

Comment 2

[Kathleen Wilson]

Attachment: Initial Information Gathering Document

The attached document summarizes the information that has been gathered and
verified.

The items highlighted in yellow indicate where further information or
clarification is needed. Please review the full document for accuracy and
completeness.

Comment 3

[Ramin Sabet]

Attachment: Answers to the Information Gathering Document

waited until the WebTrust Seal is finally online: https://cert.webtrust.org/ViewSeal?id=1016

regards
   Ramin

Comment 4

[Kathleen Wilson]

Thank you for the information. I have a few more questions.

The audit appears to only cover the SSL certs, the a-sign-ssl_cps.pdf, and the a-sign-ssl.pdf.  Correct? If yes, then only the Websites (SSL/TLS) trust bit is to be enabled. The email (S/MIME) and code signing trust bits are not being requested at this time. Correct?

> English Translation provided for Corporate Light CP

So SSL certs are issued under the a-sign-corporate-light-03, a-sign-corporate-03, and a-sign-SSL-03 sub-CAs?

How does the Corporate Light CP relate to the SSL CP? Are they the same in regards to subscriber verification?

> Domain Name ownership/control

Section 7 of the Mozilla CA Certificate Policy is very important in evaluating root inclusion requests.

The information that I found in a-sign-corporate_light_en.pdf in section 3.3.1 does not provide sufficient information about the steps that are taken to verify the ownership/control of the domain name to be included in the certificate. For instance, are third-party databases used to get information about a domain? If yes, then how is that information used/compared to the subscriber application or info to be included in the certificate? Sufficient information needs to be in a public and audited document, such as the CP or CPS.

Comment 5

[Ramin Sabet]

Many thanks for the fast response.
We had to answer the exact same questions in German during the Audit, we will try to answer the questions now in English, although i thought that was the idea of WebTrust: our not needing to translate all the Policies, etc.
----

a-sign-SSL-03 is the CA used for issuing SSL certrificates.
Are we to perform a WebTrust Audit for every bit ;-)
What do you need to enable the other bits ?


The corporate-light CP was the only one which was translated, hence i sent it (better than Google Translate).
Translation from http://www.a-trust.at/docs/cp/a-sign-corporate-light/a-sign-corporate_light_en.pdf

3.1.8 Verification of Domain or IP Address
Registration Authority verifiies the validity of the ownership of the requested domain by querying a database like www.nic.at, www.denic.de,... If this is not possible the applicant has to guarantee the possession of the Domain in written form. If a server certificate is issued to an IP Address, a written statement of the provider proving the applicants posession of the IP Address is required.

3.1.9 Authentification of individuals
Persons validated during this process are:
 * Signatory ie the domain owner
and if the domain owner is acting for an organisation
 * a representative of the company who is allowed to sign in the name of the company
Both entities have to provide a copy of a valid photo-ID according to the following requirements
 * Austrian Photo ID (List...)
 * international Passport in English or German Language
If the company representative cannot be found in the company registration number or ERB, then an additional proof of his authority is required

Comment 6

[Kathleen Wilson]

> i thought that was the idea of WebTrust: our not needing to 
> translate all the Policies, etc. 

We depend on the audits to ensure that the documented practices are being followed. We still need to know what those practices actually are, and to verify that they sufficiently satisfy section 7 of the Mozilla CA Certificate Policy (http://www.mozilla.org/projects/security/certs/policy/). Sufficient documentation relating to this requirement must be in public-facing documents such as the CP and CPS that are included on the audit.

> What do you need to enable the other bits?

For each trust bit to be enabled, the CA must have information in the appropriate public-facing CP/CPS documents that satisfies section 7 of the Mozilla CA Certificate Policy. Additionally, there will need to be an audit of the corresponding documented practices that satisfies the Mozilla CA Certificate Policy.

I guess that answers my question about only requesting the websites trust bit at this time. Once the requirements are met for enabling the email and code signing trust bits, you may open a new request as per https://wiki.mozilla.org/CA:How_to_apply#Enable_Additional_Trust_Bits_for_an_included_root


> The corporate-light CP was the only one which was translated, hence i sent it

Please list the document names and urls for all of the CP documents that cover sub-CAs under this root that can sign SSL certs.

> 3.1.8 Verification of Domain or IP Address
> 3.1.9 Authentification of individuals

I’m not finding these sections and the corresponding text.  Which document are these in?

Note that the verification of domain ownership/control cannot rely solely on the documentation that the certificate subscriber provides.  There must be some form of checking the information. For instance, the verification procedure may be to use a third party database and compare the information to make sure that it matches. The verification procedure may also use a challenge-response mechanism.

Comment 7

[Ramin Sabet]

Many thanks for the explanation.

> 3.1.8 Verification of Domain or IP Address
> 3.1.9 Authentification of individuals

I think the last messages might have been a bit confusing:

The only CA issuing SSL certificates is a-sign-ssl.
The above translations (repeated below for clarification) all refer to this CA and are from this document:
http://www.a-trust.at/docs/cps/a-sign-ssl/a-sign-ssl_cps.pdf

They describe the identification of the ownership of Domain and the Signatory behind the domain.

3.1.8 Verification of Domain or IP Address
Registration Authority verifiies the validity of the ownership of the requested
domain by querying a database like www.nic.at, www.denic.de,... If this is not
possible the applicant has to guarantee the possession of the Domain in written
form. If a server certificate is issued to an IP Address, a written statement
of the provider proving the applicants posession of the IP Address is required.

3.1.9 Authentification of individuals
Persons validated during this process are:
 * Signatory ie the domain owner
and if the domain owner is acting for an organisation
 * a representative of the company who is allowed to sign in the name of the
company
Both entities have to provide a copy of a valid photo-ID according to the
following requirements
 * Austrian Photo ID (List...)
 * international Passport in English or German Language
If the company representative cannot be found in the company registration
number or ERB, then an additional proof of his authority is required

Comment 8

[Kathleen Wilson]

Thank you for the clarification. 

I need to ask you for some more translations because Google Translate is not working well on these documents.

Please translate section 3.1.7 of http://www.a-trust.at/docs/cps/a-sign-ssl/a-sign-ssl_cps.pdf

Please translate sections 3.3.1 through 3.3.5 of http://www.a-trust.at/docs/cp/a-sign-ssl/a-sign-ssl.pdf

> 3.1.8 Verification of Domain or IP Address
> Registration Authority verifies the validity of the ownership of the 
> requested domain by querying a database like www.nic.at, www.denic.de,... 
> If this is not possible the applicant has to guarantee the possession of the 
> Domain in written form. If a server certificate is issued to an IP Address, 
> a written statement of the provider proving the applicants possession of 
> the IP Address is required.

How is the information from the database query used to verify the validity of the ownership of the requested domain?

When database query isn’t possible, how is the written form and written statement verified?

> CA Hierarchy

I'm still not fully understanding the use of all of the sub-CAs under this A-Trust-nQual-03 root...
• a-sign-Token-03 (encryption/decryption certificates for the Citizen Card)
• a-sign-corporate-light-03 – What types of certs are issued under this sub-CA? Who verifies the end-entity cert subscribers?
• a-sign-corporate-03 - What types of certs are issued under this sub-CA? Who verifies the end-entity cert subscribers?
• a-sign-light-03 (software Certificates - for signature only?)
• a-sign-limited-03 (limited validity Test Certificates - can these be SSL?)
• a-sign-SSL-03 (SSL certs)

Comment 9

[Ramin Sabet]

Hello,

i hope our translation skills are sufficient ...

> How is the information from the database query used to verify the validity of
> the ownership of the requested domain?

As 3.1.9 states: we require a PhotoID from the domain owner and a representative of the company who is signed in the name ...
the domain owner is the person found in the database information of www.nic.at etc as stated in 3.1.8

> When database query isn’t possible, how is the written form and written
> statement verified?

In these rare cases there is still the verification process of a representative as described in 3.1.9 (company registration number/EBR). This trusted person has to guarantee us the validity of the information provided.


CPS 3.1.7:
Authentification of organisations

For applying an a.sign. SSL certificate for a domain owned by an organisation the  organisation will be verified as follows: If the company can be found in the European Business Register (EBR) the verification process performed by the registration authority contains querying the Austrian Company Register or the EBR. The application must include this number. If the company is not registered in this databases the applicant has to provide a document proving the existence of the organisation. This can be a document (not older than three months) of a public department or something comparable.


CP 3.3.1
Registration of the certificate holder

These action for identification and registration of the certificate holder ensure that the application for an a.sign SSL certificate if correct, complete and authorised.

1) Before the contract between certificate holder and a.trust is signed, the business conditions and other applying documents concerning the use of the certificate are made accessible to the certificate holder (3.3.4)

2) the application form and the information are accessible via the a.trust web site

3) the certificate application form contains the following information
  * ful name, phone number and email address of the applicant
  * Password for verification
  * Domainname or IP Address   
  * optional email address which will be included in the certificate (RFC 822)
  * the public key to be signed
If the domain is owned by an organisation
  * full name and contact information of a person allowed to sign for the company
  * company register or ERB number (if exists)
  * Name and place of the organisation
  * optional name of the organisatiuonal unit

4) the contract to be signed with the certificate holder contains
  * acceptance of the responsibilites of a certificate holder
  * acceptance that a.trust is allowed to record the process of registration and all contained data and accepting that this data in case of the CAs end of operation may be given to a third party
  * the certificate holders confirmation that the provided data is correct

5) a.trust verified the following data
  * verification of the ownership of the domain or IP Address
If the domain owner is an organisation the following additional verification is performed
  * Verification of the organisation (company register databases)
  * Verification that the person allowed to sign for the company is mentioned as such in the company register and verification of the photo ID

6) The certificate request and all contained documents (copy of photo ID, info about company, domain/ip,..) are archived for seven years (electronic archiving)

7) The regulations of the Datenschutzkomission DSG (i.e. data privacy protection commission) are assured by the registration authorities following the procedere described by a.trust.

CP 3.3.2
Certificate renewal
The following measures ensure the correctness and completeness of applications for certificates which had already been authorised by a.trust:
1) the data contained in the certifcate has to be verified by the registration authority
2) changes in the conditions of a contract are sent to the applicant
3) changes of data used for applying for a certificate are verified and need to be signed by the applicant in accordance to 3.3.1
4) changes  of certificate lifecycle before the validTo of the certificate is reached are perfornmed according to §12 of SigV [Austrian Signature Law] The new certificate lifetime must not exceed five years. Renewal is only performed, if the used cryptographic methods are still state of the art and there are no signs of compromise of the private key.

CP 3.3.3
Issuing the certificate

The following measures assure that the issuing and renewal of certificates are performed in a secure manner according to the Austrian Signature law

1) a.sign SSL certificate are X.509 v3 certificates. the following informations are included
   * version number
   * serial number
   * name of the certificate issuer 
   * validity period
   * DN of the signatory
      * CN
      * O (optional)
      * OU (optional)
      * email (optional)
      * CIN (Cardholder IDentification Number) [ie: internal unique number for the customer]
      * Nationality of the domain owner (eg. AT, DE)
   * public key
   * Algorithm used
   * signature
   * Certificate Extensions 
2) The certificates are only issued after proper verification of the provided data. Same procedure is used for renewal.
3) The correct assignment of certificate to certificate holder is ensured by:
   * PKCS #10 delivered by applicant
   * Issuing of the certificate only after verificateion of data
   * All data provided signed by customer if apoplicable
4) The Data aquired in the registration authority is sent via SSL to the CA 
5) Every Registration Officer has to authenticate via a smart card

CP 3.3.4

publishing of Terms

a.trust informs its customers about the terms of use on the homepage: https://www.a-trust.at/docs
1) CP
2) CPS
3) terms and conditions
4) other information

Changes are also published on the homepage in some cases addionally an emails is sent

3.3.5
Publication of the certificates

Certificates issued by a.trust are published in the following manner
1) All a.sign SSL certificates are published in the public LDAP directory
2) terms are published as mentioned in 3.3.4
3) The relevant documents can be found using the product name "a.sign SSL"
4) public LDAP directory is available 24/7
5) LDAP directory is public

a.trust reserves the right to block certain IP Addresses in case of abuse (DOS).

>> CA Hierarchy

Only a.sign SSL is used for SSL cerificates. The other are only used for client authentication and or email signing

>I'm still not fully understanding the use of all of the sub-CAs under this A-Trust-nQual-03 root...
>• a-sign-Token-03 (encryption/decryption certificates for the Citizen Card)
>• a-sign-corporate-light-03 – What types of certs are issued under this sub-CA?
email signing
>Who verifies the end-entity cert subscribers?
similar procedure as a.sign SSL
>• a-sign-corporate-03 - What types of certs are issued under this sub-CA? 
email signing
>Who verifies the end-entity cert subscribers?
similar procedure as a.sign SSL
>• a-sign-light-03 (software Certificates - for signature only?)
we set all key usages despite NonRep
>• a-sign-limited-03 (limited validity Test Certificates - can these be SSL?)
No, and no new certificates are issued.
>• a-sign-SSL-03 (SSL certs)

Comment 10

[Kathleen Wilson]

Attachment: Completed Information Gathering Document

Comment 11

[Kathleen Wilson]

This request has been added to the queue for public discussion:
https://wiki.mozilla.org/CA:Schedule#Queue_for_Public_Discussion

Now that you have a request in the Queue for Public Discussion, you are
directly impacted by the time it takes to work through the queue. The goal is
to have each discussion take about one week. However, that time varies
dramatically depending on the number of reviewers contributing to the
discussion, and the types of concerns that are raised. If no one reviews and
contributes to a discussion, then a request may sit in the discussion for
weeks. When there are not enough people contributing to the discussions ahead
of yours, then your request will sit in the queue longer.

How can you help reduce the time that your request sits in the queue?

You can help by reviewing and providing your feedback in the public discussions
of root inclusion requests, or by asking a knowledgeable colleague to do so.

Please see: https://wiki.mozilla.org/CA:How_to_apply#Public_discussion

Comment 12

[Kathleen Wilson]

This request is nearing the top of the queue for public discussion. As such, I have re-reviewed the information that has been provided. 

I have noted that the WebTrust CA audit posted at https://cert.webtrust.org/ViewSeal?id=1016 has been recently updated as per the audit that completed in November.

I have also noted that the CA might update this request to include enabling EV. If you would like to request EV enablement at this time, please provide the following:
- Updated CP/CPS that include the EV policies and EV Policy OID
- WebTrust EV audit statement
- test website with EV SSL cert

Comment 13

[klein]

Yes, we would like to include EV in our current request, so we don't have to wait for the public discussion a second time.

The audit statement can be found at https://trusties.a-trust.at/ev.pdf - we will provide the test website with EV certs and the new policies within this week.

Comment 14

[klein]

- CPS can be found at http://www.a-trust.at/docs/CPS/a-sign-ssl-ev/a-sign-ssl-ev_cps.pdf, CP at http://www.a-trust.at/docs/CP/a-sign-ssl-ev/a-sign-ssl-ev.pdf

- a test certificate is installed at https://test1.a-trust.at/

Comment 15

[Kathleen Wilson]

(In reply to comment #14)
> - CPS can be found at
> http://www.a-trust.at/docs/CPS/a-sign-ssl-ev/a-sign-ssl-ev_cps.pdf, CP at
> http://www.a-trust.at/docs/CP/a-sign-ssl-ev/a-sign-ssl-ev.pdf

Copy-and-paste into a translator is not giving me usable results. Please provide translations into English of the sections of the EV SSL CP and/or EV SSL CPS that describe the procedures for verifying the information that is provided by the certificate subscriber; specifically, the verification of the organization and authority of the subscriber, and confirming that the subscriber owns/controls the domain to be included in the certificate.


> 
> - a test certificate is installed at https://test1.a-trust.at/

I have the A-Trust-nQual-03 root cert installed, but when I try to browse to the test website in my Firefox browser, I get an sec_error_unknown_issuer error. 

Please test using Firefox.

Also, please perform the testing described on the following wiki page:
https://wiki.mozilla.org/PSM:EV_Testing_Easy_Version

Comment 16

[Kathleen Wilson]

Also, would you please provide a new hierarchy diagram to include EV?
https://www.a-trust.at/docs/CA-Hierarchy_v11.pdf

Comment 17

[klein]

* EV has been implemented into the hierarchy diagram - https://www.a-trust.at/docs/CA-Hierarchy_v12.pdf

* we have altered some ocsp settings and can now verify the test website using firefox / minefield

* translation for the relevant parts in our CPS:

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

Comment 18

[Kathleen Wilson]

I have the A-Trust-nQual-03 root cert imported and the website trust bit turned on (http://www.a-trust.at/certs/A-Trust-nQual-03.crt).

When I try to browse to https://test1.a-trust.at/ I get the sec_error_unknown_issuer error.

I think the problem is that the a-sign-SSL-EV-03 sub-CA is not being sent by the server along with the end-entity cert. You may already have this sub-CA imported into your browser, which would explain why your testing worked. Please test by first deleting the a-sign-SSL-EV-03 sub-CA using the Certificate Manager. 

Intermediate CA certificates are expected to be distributed to the certificate subjects (the holders of the private keys) together with the subjects' own certificates. Those subject parties (e.g. SSL servers) are then expected to send out the intermediate CA certificates together with their own certificates whenever they are asked to send out their certificates. That is required by SSL/TLS.

Comment 19

[Kathleen Wilson]

One more thing, where is the EV Policy OID documented? e.g. which page of either the EV SSL CP or EV SSL CPS?

Comment 20

[klein]

The Policy OID is documented in paragraph 1.2 in both documents - we updated the policy as the old OID (for non - EV certificates) was still listed.

Also, the certificates should now be distributed with the subject's certificates. We succesfully opened the test site using Firefox on a new plain installation and hope that the sec_error_unknown_issuer error is gone now.

Comment 21

[Kathleen Wilson]

I verified that for the test website the intermediate cert is now distributed with the subject's cert.

Is there a typo in the EV CP and EV CPS in regards to the EV Policy OID, or was there a mistake in creating the cert for the test website?

In the documents the EV Policy OID appears to be: 1.2.040.0.17.1.22 

In the SSL cert of the test website the EV Policy OID is missing a zero before the forty: 1.2.40.0.17.1.22

Comment 22

[Ramin Sabet]

As far as i understand it: 
leading zeroes in OIDs (dotted decimals) can be ignored. 

The fact that there was this (not nice) 040 had historical reasons.

We used this issue to get rid of this:
http://www.a-trust.at/docs/CP/a-sign-ssl-ev/a-sign-ssl-ev.pdf
http://www.a-trust.at/docs/CPS/a-sign-ssl-ev/a-sign-ssl-ev_cps.pdf

regards
   ramin

Comment 23

[Kathleen Wilson]

(In reply to comment #22)
> As far as i understand it: 
> leading zeroes in OIDs (dotted decimals) can be ignored. 

I did not know this. This is the first time I ran into the EV OID in the cert being different from in the policy documentation.

> The fact that there was this (not nice) 040 had historical reasons.
> 
> We used this issue to get rid of this:
> http://www.a-trust.at/docs/CP/a-sign-ssl-ev/a-sign-ssl-ev.pdf
> http://www.a-trust.at/docs/CPS/a-sign-ssl-ev/a-sign-ssl-ev_cps.pdf
> 

Thanks.

Comment 24

[Kathleen Wilson]

I just realized there is one more question that needs to be answered before I can start the public discussion for this request.

From CA/Browser Forum's EV Guidelines Section 26(b): “If the CA provides revocation information via an Online Certificate Status Protocol (OCSP) service, it MUST update that service at least every four days. OCSP responses from this service MUST have a maximum expiration time of ten days.” 

Where is the availability and update requirements for your OCSP service documented?

Comment 25

[klein]

CPS 4.3.9 OCSP service

An OCSP service, that can be used to request the status of a certificate in realtime is available at http://ocsp.a-trust.at/ocsp.


CP 3.3.6 

7. Information concerning the status of a certificate can also be aquired in reatime, using the OCSP service.

Comment 26

[Kathleen Wilson]

Somewhere in the A-Trust CP/CPS there should be text about the maximum expiration time allowed for OCSP responses.

Comment 27

[klein]

We updated the part in our CP according to RFC2560:

If nextUpdate is not set, the responder is indicating that newer
   revocation information is available all the time.

CP 3.3.6 

7. Information concerning the status of a certificate can also be aquired in
reatime, using the OCSP service. The integrity and the authenticity are secured using a digital signature. As the current status of the certificate is being newly determined every time the query is performed, the ocsp-response field  "nextUpdate" is not set.


I hope this meets the requirement for the documentation of the maximum expiration time?

Comment 28

[Kathleen Wilson]

Attachment: Completed Information Gathering Document

Comment 29

[Kathleen Wilson]

I am now opening the first public discussion period for this request from A-Trust to add the “A-Trust-nQual-03” root certificate, turn on the Websites trust bit, and enable EV.

For a description of the public discussion phase, see https://wiki.mozilla.org/CA:How_to_apply#Public_discussion

Public discussion will be in the mozilla.dev.security.policy newsgroup and the corresponding [e-mail] mailing list.

http://www.mozilla.org/community/developer-forums.html
https://lists.mozilla.org/listinfo/dev-security-policy
news://news.mozilla.org/mozilla.dev.security.policy

The discussion thread is called “A-Trust Root Inclusion Request”

Please actively review, respond, and contribute to the discussion.

A representative of A-Trust must promptly respond directly in the discussion thread to all questions that are posted.

Comment 30

[Kathleen Wilson]

Christoph, This discussion stalled out because we're still waiting for you to respond to the two posts from April 11 (one from me, and one from Eddy).

Perhaps you didn't see the postings because the discussion got buried in a flurry of activity in the m.d.s.policy forum. Here's a link to the discussion thread that may help:
http://groups.google.com/group/mozilla.dev.security.policy/browse_thread/thread/8851c784b8509295#

Comment 31

[Kathleen Wilson]

Attachment: A-Trust CPS Translations into English

Comment 32

[Kathleen Wilson]

This request has been evaluated as per the Mozilla CA Certificate Policy at

 http://www.mozilla.org/projects/security/certs/policy/

Here follows a summary of the assessment. If anyone sees any factual errors, please point them out.

To summarize, this assessment is for the request from A-Trust to add the “A-Trust-nQual-03” root certificate, turn on the Websites trust bit, and enable EV.

Section 4 [Technical]. I am not aware of any technical issues with certificates issued by A-Trust, or of instances where they have knowingly issued certificates for fraudulent use. If anyone knows of any such issues or instances, please note them in this bug report.

Section 6 [Relevancy and Policy]. A-Trust appears to provide a service relevant to Mozilla users: It is an accredited TrustCenter in Austria issuing smartcard based qualified certificates for Austrian citizens used in eGovernment. 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.

Policies are documented in the documents published on their website and listed in the entry on the pending applications list. The main documents of interest are the CP and CPS for SSL and EV SSL. The documents are in German, and translations of some sections of the documents have been attached to this bug.

SSL CPS: http://www.a-trust.at/docs/cps/a-sign-ssl/a-sign-ssl_cps.pdf
SSL CP:  http://www.a-trust.at/docs/cp/a-sign-ssl/a-sign-ssl.pdf

EV SSL CPS: http://www.a-trust.at/docs/CPS/a-sign-ssl-ev/a-sign-ssl-ev_cps.pdf
EV SSL CP: http://www.a-trust.at/docs/CP/a-sign-ssl-ev/a-sign-ssl-ev.pdf

Translations regarding subscriber authentication and domain validation:
https://bugzilla.mozilla.org/attachment.cgi?id=533777

Section 7 [Validation]. A-Trust appears to meet the minimum requirements for subscriber verification, as follows:

* SSL: For SSL certificates, A-Trust verifies the legal existence of the organization requesting the certificate, the identity and authorization of the certificate subscriber, and that the certificate subscriber has the exclusive right to use the domain name(s) to be listed in the certificate. This is documented in sections 3.1.7, 3.1.8, and 3.1.9 of the SSL CPS and the EV SSL CPS.

* Email: Not Applicable. A-Trust is not requesting the Email trust bit at this time.

* Code: Not Applicable. A-Trust is not requesting the Code Signing trust bit at this time.

* EV Policy OID: 1.2.40.0.17.1.22

Section 15 [Certificate Hierarchy]. 
* This root has internally-operated subordinate CAs for signing certificates for smart cards, email, code signing, SSL, and EV SSL.

Other: 
* CRL Distribution point of SSL certs is ldap.
* OCSP URI: http://ocsp.a-trust.at/ocsp
** EV SSL CP section 3.3.6: As the current status of the certificate is being newly determined every time the query is performed, the ocsp-response field "nextUpdate" is not set.

Section 8-10 [Audit]. 
Ernst & Young performed the audit according to the WebTrust CA criteria, and the audit report is posted on the webtrust.org website at  https://cert.webtrust.org/ViewSeal?id=1016 (2010.11.30). Ernst & Young also performed a WebTrust EV Readiness audit, and the audit report is available here: https://trusties.a-trust.at/ev.pdf.

Based on this assessment I intend to approve this request from A-Trust to add the “A-Trust-nQual-03” root certificate, turn on the Websites trust bit, and enable EV.

Comment 33

[Kathleen Wilson]

To the representatives of A-Trust: Thank you for your cooperation and your
patience.

To all others who have commented on this bug or participated in the public
discussion: Thank you for volunteering your time to assist in reviewing this CA
request.

As per the summary in Comment #32, and on behalf of Mozilla I approve this request from A-Trust to include the following root certificate in Mozilla:

** A-Trust-nQual-03 (websites), enable EV.

I will file the NSS and PSM bugs to effect the approved changes.

Comment 34

[Kathleen Wilson]

I have filed bug 661672 against NSS and bug 661681 against PSM for the actual changes.

Comment 35

[Kathleen Wilson]

Confirmed EV treatment in FF 11.