A-Trust Root Inclusion Request
Kathleen Wilson
on the Websites trust bit, and enable EV.
A-Trust is an accredited TrustCenter in Austria issuing smartcard based
qualified certificates for Austrian citizens used in eGovernment.
A-Trust has been accredited according to 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.
The request is documented in the following bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=530797
And in the pending certificates list here:
http://www.mozilla.org/projects/security/certs/pending/#A-Trust
Information Gathering Document:
https://bugzilla.mozilla.org/attachment.cgi?id=518133
Noteworthy points:
* Cert Download URL: http://www.a-trust.at/certs/A-Trust-nQual-03.crt
* The CP/CPS documents are in German. Translations of some sections of
the documents are included in the Information Gathering Document.
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
* A-Trust�s Certificate Hierarchy Diagram:
https://www.a-trust.at/docs/CA-Hierarchy_v11.pdf
** This root inclusion request is only for the �A-Trust-nQual-03� root
certificate which has internally-operated subordinate CAs for signing
certificates for smart cards, email, code signing, and SSL.
* The request is to enable the Websites trust bit.
** SSL CPS section 3.1.7: For applying an a.sign. SSL certificate for a
domain owned by an organization 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.
** SSL CPS section 3.1.8: 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.
** SSL CPS section 3.1.9: 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
** SSL CP section 3.3.1: 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
2) the application form and the information are accessible via the
a.trust web site
3) the certificate application form contains the following information
* full name, phone number and email address of the applicant
* Password for verification
* Domain name 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.
* EV Policy OID: 1.2.40.0.17.1.22
** EV SSL CPS section 3.1.7: When ordering an a.sign SSL EV certificate,
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
included in the request.
The physical address is also verified using the official 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.
** EV SSL CPS section 3.1.8: The holder of a domain is verified using
the databases provided by the applicable authority (such as www.nic.at,
www.denic.de,...).
** EV SSL CPS section 3.1.9: 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).
* Test Website: https://test1.a-trust.at/
*CRL: CRL Distribution point of SSL certs is ldap.
* OCSP: AIA of SSL cert has OCSP URI http://ocsp.a-trust.at/ocsp
** EV SSL CP section 3.3.6, #7: 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.
* 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.
Potentially Problematic Practices
(http://wiki.mozilla.org/CA:Problematic_Practices):
* Certificates referencing hostnames or private IP addresses
** IP Addresses have been issued, but only after validation of the
ownership of the IP Address (SSL CP section 3.3.1, point 5)
** EV SSL CPS section 3.1.8: The use of IP addresses in EV certificates
is not permitted.
This begins the discussion of the request from A-Trust to add the
�A-Trust-nQual-03� root certificate, turn on the Websites trust bit, and
enable EV. At the conclusion of this discussion, I will provide a
summary of issues noted and action items. If there are no outstanding
issues, then this request can be approved. If there are outstanding
issues or action items, then an additional discussion may be needed as
follow-up.
Kathleen
David E. Ross
> A-Trust has applied to add the �A-Trust-nQual-03� root certificate, turn
> on the Websites trust bit, and enable EV.
[snipped]
> Potentially Problematic Practices
> (http://wiki.mozilla.org/CA:Problematic_Practices):
>
> * Certificates referencing hostnames or private IP addresses
> ** IP Addresses have been issued, but only after validation of the
> ownership of the IP Address (SSL CP section 3.3.1, point 5)
> ** EV SSL CPS section 3.1.8: The use of IP addresses in EV certificates
> is not permitted.
[snipped]
Do I have the three following items correct?
1. A-Trust is requesting installing a root certificate in the NSS
database with with EV enabled.
2. The use of IP addresses is prohibited in EV certificates.
3. A-Trust has signed subscriber certificates with IP addresses.
If I have this correct, why has this request progressed to public
discussion? Should not the request be rejected because A-Trust is not
in compliance with the requirements for EV-enabled certificates?
--
David E. Ross
<http://www.rossde.com/>
On occasion, I might filter and ignore all newsgroup messages
posted through GoogleGroups via Google's G2/1.0 user agent
because of spam from that source.
Kathleen Wilson
> On 3/14/11 2:55 PM, Kathleen Wilson wrote [in part]:
>> on the Websites trust bit, and enable EV.
>
> [snipped]
>> Potentially Problematic Practices
>> (http://wiki.mozilla.org/CA:Problematic_Practices):
>>
>> * Certificates referencing hostnames or private IP addresses
>> ** IP Addresses have been issued, but only after validation of the
>> ownership of the IP Address (SSL CP section 3.3.1, point 5)
>> ** EV SSL CPS section 3.1.8: The use of IP addresses in EV certificates
>> is not permitted.
>
> [snipped]
>
> Do I have the three following items correct?
>
> 1. A-Trust is requesting installing a root certificate in the NSS
> database with with EV enabled.
>
> 2. The use of IP addresses is prohibited in EV certificates.
>
> 3. A-Trust has signed subscriber certificates with IP addresses.
>
> If I have this correct, why has this request progressed to public
> discussion? Should not the request be rejected because A-Trust is not
> in compliance with the requirements for EV-enabled certificates?
>
Only their EV sub-CA can sign EV certs, and according to their EV SSL CP
they do not allow the use of IP addresses in EV certs.
Kathleen
Jeremy Rowley
of information"? I don't think the answer to this question is clear in the
policy. If a document submitted by the applicant does not qualify then,
this practice is not compliant:
"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"
Also, I question whether a self-representation by the applicant of domain
ownership constitutes a reasonable measure to verify that the entity
submitting the certificate request has registered the domain. Therefore, I
think this practice is not compliant:
"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."
Jeremy
-----Original Message-----
From:
dev-security-policy-bounces+jeremy.rowley=digice...@lists.mozilla.org
[mailto:dev-security-policy-bounces+jeremy.rowley=digice...@lists.mozilla
.org] On Behalf Of Kathleen Wilson
Sent: Monday, March 14, 2011 4:56 PM
To: mozilla-dev-s...@lists.mozilla.org
Subject: A-Trust Root Inclusion Request
A-Trust has applied to add the "A-Trust-nQual-03" root certificate, turn
on the Websites trust bit, and enable EV.
A-Trust is an accredited TrustCenter in Austria issuing smartcard based
qualified certificates for Austrian citizens used in eGovernment.
A-Trust has been accredited according to 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.
The request is documented in the following bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=530797
And in the pending certificates list here:
http://www.mozilla.org/projects/security/certs/pending/#A-Trust
Information Gathering Document:
https://bugzilla.mozilla.org/attachment.cgi?id=518133
Noteworthy points:
* Cert Download URL: http://www.a-trust.at/certs/A-Trust-nQual-03.crt
* The CP/CPS documents are in German. Translations of some sections of
the documents are included in the Information Gathering Document.
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
* A-Trust's Certificate Hierarchy Diagram:
https://www.a-trust.at/docs/CA-Hierarchy_v11.pdf
** This root inclusion request is only for the "A-Trust-nQual-03" root
Potentially Problematic Practices
(http://wiki.mozilla.org/CA:Problematic_Practices):
* Certificates referencing hostnames or private IP addresses
** IP Addresses have been issued, but only after validation of the
ownership of the IP Address (SSL CP section 3.3.1, point 5)
** EV SSL CPS section 3.1.8: The use of IP addresses in EV certificates
is not permitted.
This begins the discussion of the request from A-Trust to add the
"A-Trust-nQual-03" root certificate, turn on the Websites trust bit, and
enable EV. At the conclusion of this discussion, I will provide a
summary of issues noted and action items. If there are no outstanding
issues, then this request can be approved. If there are outstanding
issues or action items, then an additional discussion may be needed as
follow-up.
Kathleen
_______________________________________________
dev-security-policy mailing list
dev-secur...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
Christoph Klein
> Does a document provided by the applicant constitute an "independent source
> of information"? I don't think the answer to this question is clear in the
> policy. If a document submitted by the applicant does not qualify then,
> this practice is not compliant:
>
> "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"
I think the translation is a bit fuzzy here; the policy in german
says:
"Dies kann ein aktueller (nicht älter als drei Monate) Auszug aus
einem zuständigen amtlichen Register bzw. vergleichbare Dokumente
sein. Darüber hinaus kann die Überprüfung auch anhand von Datenbanken
vertrauenswürdiger Dritter erfolgen. Die Überprüfung der hier
erhobenen Daten erfolgt auf Basis der Vorgaben aus [EV-GL] Abschnitt
10."
"This can be a recent extract (not older than three months) from a
federeal record or comparable source. Additionally, the check can be
performed using the database of a trusted third party. The data
retrieved from this process is checked according to the regulations
found at paragraph 10, CA/Browser EV Certificate Guidelines. (only
applies to EV-certificates)"
I hope, I was able to provide a better translation here - we need this
possibility in our policy, because some of our clients are public
authorities that are not registered in the Austrian (or European)
Business Register.
> Also, I question whether a self-representation by the applicant of domain
> ownership constitutes a reasonable measure to verify that the entity
> submitting the certificate request has registered the domain. Therefore, I
> think this practice is not compliant:
>
> "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."
As we always check the ownership of a domain during the application
process, this practice only applies to internal domain names. If an
owner for a domain is found during the process and we cannot determine
the ownership (or authorization by the owner), the application is
denied. We could clarify this part in our CPS if needed.
Regards,
Christoph
A-Trust GmbH
Christoph Klein
> Does a document provided by the applicant constitute an "independent source
> of information"? I don't think the answer to this question is clear in the
> policy. If a document submitted by the applicant does not qualify then,
> this practice is not compliant:
>
> "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"
I think the translation is a bit fuzzy here; the policy in german
says:
"Dies kann ein aktueller (nicht älter als drei Monate) Auszug aus
einem zuständigen amtlichen Register bzw. vergleichbare Dokumente
sein. Darüber hinaus kann die Überprüfung auch anhand von Datenbanken
vertrauenswürdiger Dritter erfolgen. Die Überprüfung der hier
erhobenen Daten erfolgt auf Basis der Vorgaben aus [EV-GL] Abschnitt
10."
"This can be a recent extract (not older than three months) from a
federeal record or comparable source. Additionally, the check can be
performed using the database of a trusted third party. The data
retrieved from this process is checked according to the regulations
found at paragraph 10, CA/Browser EV Certificate Guidelines. (only
applies to EV-certificates)"
I hope, I was able to provide a better translation here - we need this
possibility in our policy, because some of our clients are public
authorities that are not registered in the Austrian (or European)
Business Register.
> Also, I question whether a self-representation by the applicant of domain
> ownership constitutes a reasonable measure to verify that the entity
> submitting the certificate request has registered the domain. Therefore, I
> think this practice is not compliant:
>
> "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."
As we always check the ownership of a domain during the application
Jeremy Rowley
under section 3.3.2 you allow 5-year certificates. The recent policy change
requires re-verification every 39 months. I didn't see where this was
disclosed in the translated section.
Also, if you are only issuing OV certificates, why is the O field listed as
optional? Shouldn't this be required for OV?
For EV certificates, section 3.1.9 states that people have to provide an
authentication document. However, I don't see language describing how you
confirm the authority of the contract signer. Perhaps this part didn't get
translated?
Also your check of IP addresses as described under section 3.1.8 verifies
that the Applicant is the registered holder but does not describe how you
confirm the Applicant's Exclusive Right to Use and Knowledge of the domain
as required under 10.6.2 of the EV Guidelines. Can you provide more details
on this?
Jeremy
-----Original Message-----
From:
dev-security-policy-bounces+jeremy.rowley=digice...@lists.mozilla.org
[mailto:dev-security-policy-bounces+jeremy.rowley=digice...@lists.mozilla
.org] On Behalf Of Christoph Klein
Sent: Thursday, March 17, 2011 8:45 AM
To: mozilla-dev-s...@lists.mozilla.org
Subject: Re: A-Trust Root Inclusion Request
On 16 Mrz., 23:31, "Jeremy Rowley" <jeremy.row...@digicert.com> wrote:
> Does a document provided by the applicant constitute an "independent
source
> of information"? I don't think the answer to this question is clear in
the
> policy. If a document submitted by the applicant does not qualify then,
> this practice is not compliant:
>
> "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"
I think the translation is a bit fuzzy here; the policy in german
says:
"Dies kann ein aktueller (nicht älter als drei Monate) Auszug aus
einem zuständigen amtlichen Register bzw. vergleichbare Dokumente
sein. Darüber hinaus kann die Überprüfung auch anhand von Datenbanken
vertrauenswürdiger Dritter erfolgen. Die Überprüfung der hier
erhobenen Daten erfolgt auf Basis der Vorgaben aus [EV-GL] Abschnitt
10."
"This can be a recent extract (not older than three months) from a
federeal record or comparable source. Additionally, the check can be
performed using the database of a trusted third party. The data
retrieved from this process is checked according to the regulations
found at paragraph 10, CA/Browser EV Certificate Guidelines. (only
applies to EV-certificates)"
I hope, I was able to provide a better translation here - we need this
possibility in our policy, because some of our clients are public
authorities that are not registered in the Austrian (or European)
Business Register.
> Also, I question whether a self-representation by the applicant of domain
> ownership constitutes a reasonable measure to verify that the entity
> submitting the certificate request has registered the domain. Therefore,
I
> think this practice is not compliant:
>
> "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."
As we always check the ownership of a domain during the application
process, this practice only applies to internal domain names. If an
owner for a domain is found during the process and we cannot determine
the ownership (or authorization by the owner), the application is
denied. We could clarify this part in our CPS if needed.
Regards,
Christoph
A-Trust GmbH
Christoph Klein
> under section 3.3.2 you allow 5-year certificates. The recent policy change
> requires re-verification every 39 months. I didn't see where this was
> disclosed in the translated section.
Thank you for pointing that out, we were not aware of this fact. We
will change the section accordingly and do re-checks for certificates
that expire after the 39 month period. New certificates will be issued
for three years from now on.
> Also, if you are only issuing OV certificates, why is the O field listed as
> optional? Shouldn't this be required for OV?
Were did you find this information? According to the SSL CP 3.3.1,
only the OU field is optional:
"the company
* company register or ERB number (if exists)
* Name and place of the organisation
* optional name of the organisatiuonal unit "
> For EV certificates, section 3.1.9 states that people have to provide an
> authentication document. However, I don't see language describing how you
> confirm the authority of the contract signer. Perhaps this part didn't get
> translated?
I am not sure if I fully understand the question: if someone applies
for an EV certificate, we perform all checks needed to verifiy the
organisation first. When everything is valid, the identity of all
individuals involved is checked through an official ID. Once the
organisation and the individuals have been explicitly identified, the
authority (in terms of being allowed to sign for the organisation) of
the participating persons is reviewed. We use the same register, that
lists the company (for example the Austrian Business Register) for
this verification. If the necessary information cannot be found in the
used register, we require additional confirmation on this part
(normally a certificate of authority signed by an official
representative).
> Also your check of IP addresses as described under section 3.1.8 verifies
> that the Applicant is the registered holder but does not describe how you
> confirm the Applicant's Exclusive Right to Use and Knowledge of the domain
> as required under 10.6.2 of the EV Guidelines. Can you provide more details
> on this?
We do not issue EV - certificates for IP addresses at all, I think you
mixed that up with the SSL policy.
"EV SSL CPS section 3.1.8: The use of IP addresses in EV certificates
is not permitted."
Regards
Christoph
Jeremy Rowley
I got the O field as being optional from section 3.3.3 of your CPS as stated
in the information gathering document. Perhaps this is a typo in the
information gathering document?
The IP address was a mistake on my part. According to the information gather
document, in section 3.1.8 of your EV CPS "the holder of a domain is
verified using the databases provided by the applicable authority (such as
www.nic.at, www.denic.de,...)." Although this process verifies the
applicant's ownership of the domain name, it does not verify the applicant's
exclusive control and knowledge as required under 10.6.2. Can you add
something about how you validate these two important elements?
I hope that helps.
Jeremy
-----Original Message-----
From:
dev-security-policy-bounces+jeremy.rowley=digice...@lists.mozilla.org
[mailto:dev-security-policy-bounces+jeremy.rowley=digice...@lists.mozilla
.org] On Behalf Of Christoph Klein
Sent: Monday, March 21, 2011 10:32 AM
To: mozilla-dev-s...@lists.mozilla.org
Subject: Re: A-Trust Root Inclusion Request
> Thanks for the clarification Christoph. A few other issues I noted was
that
> under section 3.3.2 you allow 5-year certificates. The recent policy
change
> requires re-verification every 39 months. I didn't see where this was
> disclosed in the translated section.
Thank you for pointing that out, we were not aware of this fact. We
will change the section accordingly and do re-checks for certificates
that expire after the 39 month period. New certificates will be issued
for three years from now on.
> Also, if you are only issuing OV certificates, why is the O field listed
as
> optional? Shouldn't this be required for OV?
Were did you find this information? According to the SSL CP 3.3.1,
only the OU field is optional:
"the company
* company register or ERB number (if exists)
* Name and place of the organisation
* optional name of the organisatiuonal unit "
> For EV certificates, section 3.1.9 states that people have to provide an
> authentication document. However, I don't see language describing how you
> confirm the authority of the contract signer. Perhaps this part didn't
get
> translated?
I am not sure if I fully understand the question: if someone applies
for an EV certificate, we perform all checks needed to verifiy the
organisation first. When everything is valid, the identity of all
individuals involved is checked through an official ID. Once the
organisation and the individuals have been explicitly identified, the
authority (in terms of being allowed to sign for the organisation) of
the participating persons is reviewed. We use the same register, that
lists the company (for example the Austrian Business Register) for
this verification. If the necessary information cannot be found in the
used register, we require additional confirmation on this part
(normally a certificate of authority signed by an official
representative).
> Also your check of IP addresses as described under section 3.1.8 verifies
> that the Applicant is the registered holder but does not describe how you
> confirm the Applicant's Exclusive Right to Use and Knowledge of the
domain
> as required under 10.6.2 of the EV Guidelines. Can you provide more
details
> on this?
We do not issue EV - certificates for IP addresses at all, I think you
mixed that up with the SSL policy.
"EV SSL CPS section 3.1.8: The use of IP addresses in EV certificates
is not permitted."
Regards
Christoph
Eddy Nigg
>
> ** SSL CPS section 3.1.8: 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.
The later is not an acceptable form of verification, self assertion
isn't considered sufficient in my opinion.
> * Certificates referencing hostnames or private IP addresses
> ** IP Addresses have been issued, but only after validation of the
> ownership of the IP Address (SSL CP section 3.3.1, point 5)
Does that mean that actually no private Class C/B IP addresses have been
included in the certificates?
> ** EV SSL CPS section 3.1.8: The use of IP addresses in EV
> certificates is not permitted.
Does that mean that no EV certificates have been issued with IP
addresses in the certificates?
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
XMPP: star...@startcom.org
Blog: http://blog.startcom.org/
Twitter: http://twitter.com/eddy_nigg
Kathleen Wilson
> A-Trust has applied to add the “A-Trust-nQual-03” root certificate, turn
> on the Websites trust bit, and enable EV.
>
> A-Trust is an accredited TrustCenter in Austria issuing smartcard based
> qualified certificates for Austrian citizens used in eGovernment.
> A-Trust has been accredited according to the Austrian Signature Law by
> 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.
>
> The request is documented in the following bug:
> https://bugzilla.mozilla.org/show_bug.cgi?id=530797
>
> And in the pending certificates list here:
> http://www.mozilla.org/projects/security/certs/pending/#A-Trust
>
> Information Gathering Document:
> https://bugzilla.mozilla.org/attachment.cgi?id=518133
>
> Noteworthy points:
>
> * Cert Download URL: http://www.a-trust.at/certs/A-Trust-nQual-03.crt
>
> * The CP/CPS documents are in German. Translations of some sections of
> the documents are included in the Information Gathering Document.
>
> 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
>
> https://www.a-trust.at/docs/CA-Hierarchy_v11.pdf
> ** This root inclusion request is only for the “A-Trust-nQual-03” root
> certificate which has internally-operated subordinate CAs for signing
> certificates for smart cards, email, code signing, and SSL.
>
> * The request is to enable the Websites trust bit.
>
Thank you to those of you who have reviewed this request and contributed
to this discussion. Here is a summary of the action items that have
been identified.
1) Update section 3.1.8 of the SSL CPS to clarify the statement “If this
is not possible the applicant has to guarantee the possession of the
Domain in written form.” Written statements provided by the certificate
subscriber are insufficient. There must be some form of independent
verification performed by the CA.
2) Update the corresponding CP and CPS documents and practices to meet
the requirements of section 6 of the Mozilla CA Certificate Inclusion
Policy: “verify that all of the information that is included in SSL
certificates remains current and correct at time intervals of
thirty-nine months or less”.
3) Update section 3.3.3 of the SSL CP (and wherever else is needed) to
remove the indication that the O field is optional. If only OV and EV
SSL certs are issued, then the O field should not be optional.
4) In both the SSL CPS and the EV SSL CPS add clarification about the
steps that are taken when the company is not in the Austrian Business
Register to verify that the extract from a federal record or a
certificate of authority signed by an official representative is
authentic. Written statements provided by the certificate subscriber are
insufficient. There must be some form of independent verification
performed by the CA.
5) Add more information to the SSL CPS and EV SSL CPS to explain how
information from the NIC database is used to confirm that the
certificate subscriber owns/controls the domain name to be included in
the certificate. For instance, is a phone call made or email sent to the
technical or administrative contact field of the domain's record? If an
email is sent, does it include non-predictable information that the
technical or administrative contact must use to respond?
I did not see an answer to the follow question.
> * Certificates referencing hostnames or private IP addresses
> ** IP Addresses have been issued, but only after validation of the
> ownership of the IP Address (SSL CP section 3.3.1, point 5)
Does that mean that actually no private Class C/B IP addresses have been
included in the certificates?
Are the action items listed above complete and accurate?
Thanks,
Kathleen
Christoph Klein
We have updated our Policies, they are available
Kathleen Wilson
Cristoph,
Please provide translations into English of the updated sections of the
documents in regards each of the items listed above.
Kathleen
Christoph Klein
again:
Hi!
We have updated our Policies, the new versions are available at the
usual spot.
> 1) Update section 3.1.8 of the SSL CPS to clarify the statement “If this
> is not possible the applicant has to guarantee the possession of the
> Domain in written form.” Written statements provided by the certificate
> subscriber are insufficient. There must be some form of independent
> verification performed by the CA.
If the applicant is not the owner of the domain himself, a written
confirmation signed by the owner is required. If the included address
is an IP address and no domain, a written confirmation issued by the
applicants provider is needed.
> 2) Update the corresponding CP and CPS documents and practices to meet
> the requirements of section 6 of the Mozilla CA Certificate Inclusion
> Policy: “verify that all of the information that is included in SSL
> certificates remains current and correct at time intervals of
> thirty-nine months or less”.
The changes have been made in the corresponding sections (SSL CPS
6.3.2, EV CPS 6.3.2, EV CP 3.3.2).
> 3) Update section 3.3.3 of the SSL CP (and wherever else is needed) to
> remove the indication that the O field is optional. If only OV and EV
> SSL certs are issued, then the O field should not be optional.
Optional removed.
> 4) In both the SSL CPS and the EV SSL CPS add clarification about the
> steps that are taken when the company is not in the Austrian Business
> Register to verify that the extract from a federal record or a
> certificate of authority signed by an official representative is
> authentic. Written statements provided by the certificate subscriber are
> insufficient. There must be some form of independent verification
> performed by the CA.
If the applicant acts on behalf of a governmental entity or a federal
record is used to identify an organization, A-Trust verifies the
stated information through an inquiry at the
“Bundeskanzleramt” (Federal Institution responsible for these records
in Austria). (CPS 3.1.7)
> 5) Add more information to the SSL CPS and EV SSL CPS to explain how
> information from the NIC database is used to confirm that the
> certificate subscriber owns/controls the domain name to be included in
> the certificate. For instance, is a phone call made or email sent to the
> technical or administrative contact field of the domain's record? If an
> email is sent, does it include non-predictable information that the
> technical or administrative contact must use to respond?
A-Trust may verify that the applicant is aware of his exclusive
control of the domain name by obtaining a confirmation from the
administrative contact listed at the domain record through e-mail or
telephone. (CPS 3.1.8)
> I did not see an answer to the follow question.
>
> > * Certificates referencing hostnames or private IP addresses
> > ** IP Addresses have been issued, but only after validation of the
> > ownership of the IP Address (SSL CP section 3.3.1, point 5)
>
> Does that mean that actually no private Class C/B IP addresses have been
> included in the certificates?
Sorry, it seems my reply has been lost:
Yes, there are no valid SSL-certificates issued with included Class B
or C IP addresses.
I hope that our changes meet the requirments,
Regards
Christoph Klein
Eddy Nigg
> If the applicant is not the owner of the domain himself, a written
> confirmation signed by the owner is required. If the included address
> is an IP address and no domain, a written confirmation issued by the
> applicants provider is needed.
I'm interested to know if you are going to contact the party that owns
the domain and if you verify that the owner information matches the
WHOIS records of that domain. Also if you have reasonable controls in
place in order to ensure that the persona that signed the confirmation
is A) authorized to sign it (if it's an organization) and B) ensure
independently that the confirming party is indeed the one they claim to be.
In other words, if I'd provide you with an authorization letter for
microsoft.com, which steps are you performing that I may use this domain.
Additionally I'm not sure if you perform any additional domain control
validation for those cases.
> If the applicant acts on behalf of a governmental entity or a federal
> record is used to identify an organization, A-Trust verifies the
> stated information through an inquiry at the
> “Bundeskanzleramt” (Federal Institution responsible for these records
> in Austria). (CPS 3.1.7)
I'm not sure if this is what Kathleen requested and might be missing the
point. Which independent verification are you performing to ensure that
the identity or organization is indeed the one it claims to be. This may
of course also apply to governmental entities, but this was not
mentioned in the action item.
Christoph Klein
> > If the applicant is not the owner of the domain himself, a written
> > confirmation signed by the owner is required. If the included address
> > is an IP address and no domain, a written confirmation issued by the
> > applicants provider is needed.
>
> I'm interested to know if you are going to contact the party that owns
> the domain and if you verify that the owner information matches the
> WHOIS records of that domain. Also if you have reasonable controls in
> place in order to ensure that the persona that signed the confirmation
> is A) authorized to sign it (if it's an organization) and B) ensure
> independently that the confirming party is indeed the one they claim to be.
>
> In other words, if I'd provide you with an authorization letter for
> microsoft.com, which steps are you performing that I may use this domain.
>
> Additionally I'm not sure if you perform any additional domain control
> validation for those cases.
We verify the identity of all individuals, involved in the process,
through a photo ID. If the applicant is not listed in the whois entry
himself (or only the organization is listed), a letter of
authorization is required, that can only be issued by a person,
authorized to sign for the company. We check this authorization via
the business registers (more exact information to be found in the next
point) and, as already mentioned, verify the identity of this person
separately.
So, for your example, we would see that the domain is registered to
Microsoft, so we would perform a query in the business register to
find someone, who is allowed to sign for the company. This person will
be identified and has to issue the letter of authorization for you. If
the letter you sent us is signed by such a person and we can verify
his identity (normally we call the responsible person and ask him, to
send us an ID, contact data gathered from the whois entry and/or the
business register).
> > If the applicant acts on behalf of a governmental entity or a federal
> > record is used to identify an organization, A-Trust verifies the
> > stated information through an inquiry at the
> > “Bundeskanzleramt” (Federal Institution responsible for these records
> > in Austria). (CPS 3.1.7)
>
> I'm not sure if this is what Kathleen requested and might be missing the
> point. Which independent verification are you performing to ensure that
> the identity or organization is indeed the one it claims to be. This may
> of course also apply to governmental entities, but this was not
> mentioned in the action item.
Maybe I have misunderstood some point there , the section stated is
just in use, if we cannot verify an organization through the official
business record – I’ll try to roll it up from the beginning:
When we receive an application, we perform a query in the Austrian (or
European) Business Register to find the organization stated in the
application. If the applicant is listed himself (with authorization to
sign for the company), we regard the organization as identified - the
identity of the individual person is checked separately. If the
applicant himself is not authorized to sign for the organization he
requests a certificate for, we need a letter of authorization from a
person with these rights (also confirmed via the Business Register).
The identity of this person is also reviewed, using the same means
that are used to identify the applicant himself.
If we cannot find the organization in the mentioned registers, there
may be two reasons:
1) The applicant is a governmental entity: in this case, we confirm
the existence through an inquiry (a call or an e-mail) with the
responsible federal institute (the Bundeskanzleramt in Austria). We
then proceed as normal, verify who is responsible to sign for the
entity and request identification and a letter of authorization if
needed.
2) There may be other reasons, why an organization is not listed in
the register, for example because of self-employment. To verify these
types of companies, we make an inquiry at the Austrian chamber of
Trade, and get the information (data similar to what we can find in
the business register normally) signed by the chamber. We then proceed
with our identification process like in the other cases – find out,
who is allowed to sign on behalf of the organization and identify the
involved individuals.
If none of the above ways leads to a proper identification of the
organziation, the certificate application is rejected.
I hope, I was able to clarify those points,
Regards
Christoph
Kathleen Wilson
> It seems that there was a problem with my posting yesterday, I'll try
> again:
>
> Hi!
>
> We have updated our Policies, the new versions are available at the
> usual spot.
>
>> 1) Update section 3.1.8 of the SSL CPS to clarify the statement “If this
>> is not possible the applicant has to guarantee the possession of the
>> Domain in written form.” Written statements provided by the certificate
>> subscriber are insufficient. There must be some form of independent
>> verification performed by the CA.
>
> If the applicant is not the owner of the domain himself, a written
> confirmation signed by the owner is required. If the included address
> is an IP address and no domain, a written confirmation issued by the
> applicants provider is needed.
>
The CP/CPS documentation needs to have information about how you check
the business register to find someone who can sign for the company and
then call them.
"...so we would perform a query in the business register to find
someone, who is allowed to sign for the company. This person will be
identified and has to issue the letter of authorization for you. If the
letter you sent us is signed by such a person and we can verify his
identity (normally we call the responsible person and ask him, to send
us an ID, contact data gathered from the whois entry and/or the business
register)."
>
>> 2) Update the corresponding CP and CPS documents and practices to meet
>> the requirements of section 6 of the Mozilla CA Certificate Inclusion
>> Policy: “verify that all of the information that is included in SSL
>> certificates remains current and correct at time intervals of
>> thirty-nine months or less”.
>
> The changes have been made in the corresponding sections (SSL CPS
> 6.3.2, EV CPS 6.3.2, EV CP 3.3.2).
>
I’m not finding the change in the SSL CPS, do I have the wrong link?
http://www.a-trust.at/docs/cps/a-sign-ssl/a-sign-ssl_cps.pdf
I see the change in the EV CP and CPS. I’m not sure of the translations.
It appears to say that SSL certs can be valid for 3.25 years, and EV SSL
certs can be valid for 2.25 years. Correct?
>> 3) Update section 3.3.3 of the SSL CP (and wherever else is needed) to
>> remove the indication that the O field is optional. If only OV and EV
>> SSL certs are issued, then the O field should not be optional.
>
> Optional removed.
>
I’m still seeing that the organization name is optional in the SSL CP.
Do I have the wrong url?
http://www.a-trust.at/docs/cp/a-sign-ssl/a-sign-ssl.pdf
>> 4) In both the SSL CPS and the EV SSL CPS add clarification about the
>> steps that are taken when the company is not in the Austrian Business
>> Register to verify that the extract from a federal record or a
>> certificate of authority signed by an official representative is
>> authentic. Written statements provided by the certificate subscriber are
>> insufficient. There must be some form of independent verification
>> performed by the CA.
>
> If the applicant acts on behalf of a governmental entity or a federal
> record is used to identify an organization, A-Trust verifies the
> stated information through an inquiry at the
> “Bundeskanzleramt” (Federal Institution responsible for these records
> in Austria). (CPS 3.1.7)
>
Please add information to the appropriate sections of the CP/CPS
documents to indicate that the phone call or email correspondence is
performed in order to confirm the existence of the organization.
"1) The applicant is a governmental entity: in this case, we confirm
the existence through an inquiry (a call or an e-mail) with the
responsible federal institute (the Bundeskanzleramt in Austria). We
then proceed as normal, verify who is responsible to sign for the
entity and request identification and a letter of authorization if
needed."
"2) There may be other reasons, why an organization is not listed in
the register, for example because of self-employment. To verify these
types of companies, we make an inquiry at the Austrian chamber of
Trade, and get the information (data similar to what we can find in
the business register normally) signed by the chamber. We then proceed
with our identification process like in the other cases – find out,
who is allowed to sign on behalf of the organization and identify the
involved individuals."
>> 5) Add more information to the SSL CPS and EV SSL CPS to explain how
>> information from the NIC database is used to confirm that the
>> certificate subscriber owns/controls the domain name to be included in
>> the certificate. For instance, is a phone call made or email sent to the
>> technical or administrative contact field of the domain's record? If an
>> email is sent, does it include non-predictable information that the
>> technical or administrative contact must use to respond?
>
> A-Trust may verify that the applicant is aware of his exclusive
> control of the domain name by obtaining a confirmation from the
> administrative contact listed at the domain record through e-mail or
> telephone. (CPS 3.1.8)
>
I am not finding the part about “obtaining a confirmation from the
administrative contact listed at the domain record through e-mail or
telephone” in either the SSL or EV CPS. Is it getting lost in translation?
Kathleen
Eddy Nigg
> So, for your example, we would see that the domain is registered to
> Microsoft, so we would perform a query in the business register to
> find someone, who is allowed to sign for the company. This person will
> be identified and has to issue the letter of authorization for you. If
> the letter you sent us is signed by such a person and we can verify
> his identity (normally we call the responsible person and ask him, to
> send us an ID, contact data gathered from the whois entry and/or the
> business register).
OK, sounds very good. Maybe this needs to be addressed in some form in
the CP/CPS. But this is basically what I expect.
> Maybe I have misunderstood some point there , the section stated is
> just in use, if we cannot verify an organization through the official
> business record – I’ll try to roll it up from the beginning:
Probably a misunderstanding. Quote from Kathleen:
> > 1) Update section 3.1.8 of the SSL CPS to clarify the statement “If this
> > is not possible the applicant has to guarantee the possession of the
> > Domain in written form.” Written statements provided by the certificate
> > subscriber are insufficient. There must be some form of independent
> > verification performed by the CA.
Explicitly she states that written statements provided by the
certificatesubscriber are insufficient for possession or control over a
domain. This has nothing to do with how you validate a governmental
entity, but about how you validate domain control or ownership.
Christoph Klein
On 12 Apr., 01:20, Kathleen Wilson <kathleen95...@yahoo.com> wrote:
> The CP/CPS documentation needs to have information about how you check
> the business register to find someone who can sign for the company and
> then call them.
> "...so we would perform a query in the business register to find
> someone, who is allowed to sign for the company. This person will be
> identified and has to issue the letter of authorization for you. If the
> letter you sent us is signed by such a person and we can verify his
> identity (normally we call the responsible person and ask him, to send
> us an ID, contact data gathered from the whois entry and/or the business
> register)."
I do not really understand this point - the policy already says that:
we request a recent extract from the business register and verify the
identitiy of the people that are allowed to sign for the company
(these facts are stated in the register). We additionally check a
persons identity through an official ID - if the applicant is not
stated here, the mentioned letter of authorization is required (with
an additional ID check to verify the signer of the letter). These
steps are explained in our CPS and already translated - I can scan an
example extract for A-Trust if you like, you can see the data provided
in it (names, addresses and birthdates of all authorised
representatives assigned to the company).
> I’m not finding the change in the SSL CPS, do I have the wrong link?http://www.a-trust.at/docs/cps/a-sign-ssl/a-sign-ssl_cps.pdf
We are trying to merge the four CP/CPS documents for SSL and SSL EV
into two general "SSL & EV" CP and CPS documents in the future -
that's why the change was not done in the SSL CPS. We will add the
changes there too and upload the new version.
> I see the change in the EV CP and CPS. I’m not sure of the translations.
> It appears to say that SSL certs can be valid for 3.25 years, and EV SSL
> certs can be valid for 2.25 years. Correct?
that's correct, yes
>
> I’m still seeing that the organization name is optional in the SSL CP.
> Do I have the wrong url?http://www.a-trust.at/docs/cp/a-sign-ssl/a-sign-ssl.pdf
same as above, will be changed
> Please add information to the appropriate sections of the CP/CPS
> documents to indicate that the phone call or email correspondence is
> performed in order to confirm the existence of the organization.
> "1) The applicant is a governmental entity: in this case, we confirm
> the existence through an inquiry (a call or an e-mail) with the
> responsible federal institute (the Bundeskanzleramt in Austria). We
> then proceed as normal, verify who is responsible to sign for the
> entity and request identification and a letter of authorization if
> needed."
> "2) There may be other reasons, why an organization is not listed in
> the register, for example because of self-employment. To verify these
> types of companies, we make an inquiry at the Austrian chamber of
> Trade, and get the information (data similar to what we can find in
> the business register normally) signed by the chamber. We then proceed
> with our identification process like in the other cases – find out,
> who is allowed to sign on behalf of the organization and identify the
> involved individuals."
the means of contact will be added at both CPS documents, section
3.1.7. The other parts are already there, I will try to change the
wording a bit, to clarify them.
> I am not finding the part about “obtaining a confirmation from the
> administrative contact listed at the domain record through e-mail or
> telephone” in either the SSL or EV CPS. Is it getting lost in translation?
It just says (3.1.8), that we get in touch with the administrative
contact, not how. I will clarifiy that too.
-------------
On 12 Apr., 01:33, Eddy Nigg <eddy_n...@startcom.org> wrote:
> OK, sounds very good. Maybe this needs to be addressed in some form in
> the CP/CPS. But this is basically what I expect.
I will try to point that out (I think it is already covered with the
last point from Kathleens list)
> Probably a misunderstanding. Quote from Kathleen:
> Explicitly she states that written statements provided by the
> certificatesubscriber are insufficient for possession or control over a
> domain. This has nothing to do with how you validate a governmental
> entity, but about how you validate domain control or ownership.
Our policy requires a written statement from the service provider, not
the applicant:
"Wird ein Serverzerti kat nicht für eine Domain, sondern eine IP-
Adresse ausgestellt, so muss eine Bestätigung des Providers eingeholt
werden, aus der hervorgeht, dass dem Antragsteller die entsprechende
IP-Adresse zugewiesen wurde."
If a server-certificate is issued for an IP-address and not a domain,
a statement of the provider has to be aquired. The statement has to
confirm, that the requested IP-address has been assigned to the
applicant.
The new policy will be online on Monday,
Regards
Christoph
Kathleen Wilson
> Hi!
>
> On 12 Apr., 01:20, Kathleen Wilson<kathleen95...@yahoo.com> wrote:
>
>> The CP/CPS documentation needs to have information about how you check
>> the business register to find someone who can sign for the company and
>> then call them.
>> "...so we would perform a query in the business register to find
>> someone, who is allowed to sign for the company. This person will be
>> identified and has to issue the letter of authorization for you. If the
>> letter you sent us is signed by such a person and we can verify his
>> identity (normally we call the responsible person and ask him, to send
>> us an ID, contact data gathered from the whois entry and/or the business
>> register)."
>
> I do not really understand this point - the policy already says that:
> we request a recent extract from the business register and verify the
> identitiy of the people that are allowed to sign for the company
> (these facts are stated in the register). We additionally check a
> persons identity through an official ID - if the applicant is not
> stated here, the mentioned letter of authorization is required (with
> an additional ID check to verify the signer of the letter). These
> steps are explained in our CPS and already translated - I can scan an
> example extract for A-Trust if you like, you can see the data provided
> in it (names, addresses and birthdates of all authorised
> representatives assigned to the company).
>
My interpretation based on the CPS was that the extract was something
the certificate subscriber provided. I didn't see that it is A-Trust who
requests the extract from the business register. I guess it got lost in
the translation.
> The new policy will be online on Monday,
Please post an update here when the new documents are available.
Kathleen
Christoph Klein
Hi!
Oh, ok - so from your view, this point is covered now?
The new policies are online (the URLs didn't change).
Christoph
Kathleen Wilson
>
> The new policies are online (the URLs didn't change).
>
> Christoph
Cristoph, Please provide translations into English of the following
sections of the updated documents.
Sections 3.1.7, 3.1.8, and 3.1.9 of the SSL CPS,
http://www.a-trust.at/docs/cps/a-sign-ssl/a-sign-ssl_cps.pdf
Sections 3.1.7, 3.1.8, and 3.1.9 of the EV SSL CPS,
http://www.a-trust.at/docs/CPS/a-sign-ssl-ev/a-sign-ssl-ev_cps.pdf
Section 3.3.2 of the EV SSL CP,
http://www.a-trust.at/docs/CP/a-sign-ssl-ev/a-sign-ssl-ev.pdf
Kathleen
Christoph Klein
>
> Cristoph, Please provide translations into English of the following
> sections of the updated documents.
>
>
> Sections 3.1.7, 3.1.8, and 3.1.9 of the EV SSL CPS,http://www.a-trust.at/docs/CPS/a-sign-ssl-ev/a-sign-ssl-ev_cps.pdf
>
> Section 3.3.2 of the EV SSL CP,http://www.a-trust.at/docs/CP/a-sign-ssl-ev/a-sign-ssl-ev.pdf
>
> Kathleen
Hi!
I translated the above sections:
SSL CPS
3.1.7 Authentication of organizations
When ordering an a.sign SSL EV certificate, the domain and
organization 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 by comparing the
provided data with data gathered from the corresponding online -
database. The registration number has to be included in the request.
A.sign SSL certificates can only be issued to organizations, whose
head office is located in the EU. The physical address is also
verified using the official register. If not applicable (the
organization is a legal entity that cannot be found in the given
registers, for example a governmental authority or self-employed
persons) , the check is performed using a duplicate of a document
that confirms the organizations existence, acquired from a
governmental entity. Examples for such documents are extracts from
legal registers or databases of trusted third parties.
All communication with the involved parties (applicant, authorized
persons from the organization, trusted third parties like governmental
contacts) is carried out through e-mail, fax or telephone.
3.1.8 Check of domain / IP address
A-Trust verifies the validity of the ownership of the requested domain
by querying a database like www.nic.at, www.denic.de. If the
applicant is not the owner of the domain himself, a written
confirmation signed by the owner is required. If the included address
is an IP address and no domain, a written confirmation (that the IP
address is only assigned to the applicant) issued by the applicants
provider is needed.
In case of a.sign SSL EV certificates, the use of IP – addresses is
restricted. A-Trust may verify that the applicant is aware of his
exclusive control of the domain name by obtaining a confirmation from
the
administrative contact listed at the domain record through e-mail or
telephone.
3.1.9 Authentication of individuals
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 organization
• an organizational responsible person, that is allowed to sign in the
ogranizations name and confirms the correctness of the application
The people that are mentioned in the application have to provide an
identification document from the following list:
• a Photo ID, issued in Austria (a list of accepted documents is
available at the A-Trust Website)
• an international passport in german or english language
If the organizational responsible person is not listed in the used
register, additional confirmation of his status has to be provided
(i.e. a certificate of authority from a person allowed to sign for the
company – check through business register / EBR).
EV SSL CPS
3.1.7 Authentication of organizations
When ordering an a.sign SSL EV certificate, the domain and
organization 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 by comparing the
provided data with data gathered from the corresponding online -
database. The registration number has to be included in the request.
A.sign SSL EV certificates can only be issued to organizations, whose
head office is located in the EU. The physical address is also
verified using the official register. If not applicable (the
organization is a legal entity that cannot be found in the given
registers, for example a governmental authority or self-employed
persons) , the check is performed using a duplicate of a document
that confirms the organizations existence, acquired from a
governmental entity. Examples for such documents are extracts from
legal registers or databases of trusted third parties.
All communication with the involved parties (applicant, authorized
persons from the organization, trusted third parties like governmental
contacts) is carried out through e-mail, fax or telephone.
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 organization,
confirming the existance of an account related to the organization
• annual statement of the organization, 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 organization 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 / IP address
A-Trust verifies the validity of the ownership of the requested domain
by querying a database like www.nic.at, www.denic.de. If the
applicant is not the owner of the domain himself, a written
confirmation signed by the owner is required. If the included address
is an IP address and no domain, a written confirmation (that the IP
address is only assigned to the applicant) issued by the applicants
provider is needed.
In case of a.sign SSL EV certificates, the use of IP – addresses is
restricted. A-Trust may verify that the applicant is aware of his
exclusive control of the domain name by obtaining a confirmation from
the
administrative contact listed at the domain record through e-mail or
telephone.
3.1.9 Authentication of individuals
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 organization
• an organizational responsible person, that is allowed to sign in the
ogranizations name and confirms the correctness of the application
The people that are mentioned in the application have to provide an
identification document from the following list:
• a Photo ID, issued in Austria (a list of accepted documents is
available at the A-Trust Website)
• an international passport in german or english language
If the organizational responsible person is not listed in the used
register, additional confirmation of his status has to be provided
(i.e. a certificate of authority from a person allowed to sign for the
company – check through business register / EBR).
EV SSL CP
3.3.2 Extension of validity of a certificate and replace of expired
certificates
The following measures make sure, that request from applicants that
already use certificates are processed correctly. The rules are
applied for renewal as well as replacement of (revoked or expired)
certificates.
1. The registration authority has to re-check all data, contained in
the certificate (e.g. the name of the organization) according to
recent validity
2. Possible changes in contractual terms have to be communicated
3. Possible changes in contents of important documents (CP, CPS,…)
have to be provided to the applicant (acceptance is signed in
contract)
4. The renewal (extension) of valid certificates is carried out
according to the Austrian Signature Law. The validity period of the
new certificate may not be longer than 3.25 years. The renewal is only
possible, if the cryptographic security provided by the used method
(e.g. key lengths, algorithms) is still adequate and no hints for a
possible key compromise of the applicants private key exist.
a.sign SSL EV certificates cannot be extended. If a certificate
expires, the complete application- and issuing procedure has to be
carried out from the beginning.
Regards,
Christoph
Kathleen Wilson
> On 16 Mai, 22:34, Kathleen Wilson<kathleen95...@yahoo.com> wrote:
>>
>> Cristoph, Please provide translations into English of the following
>> sections of the updated documents.
>>
>> Sections 3.1.7, 3.1.8, and 3.1.9 of the SSL CPS,http://www.a-trust.at/docs/cps/a-sign-ssl/a-sign-ssl_cps.pdf
>>
>> Sections 3.1.7, 3.1.8, and 3.1.9 of the EV SSL CPS,http://www.a-trust.at/docs/CPS/a-sign-ssl-ev/a-sign-ssl-ev_cps.pdf
>>
>> Section 3.3.2 of the EV SSL CP,http://www.a-trust.at/docs/CP/a-sign-ssl-ev/a-sign-ssl-ev.pdf
>>
>> Kathleen
>
> Hi!
>
> I translated the above sections:
Thanks. I have some additional comments...
>
> SSL CPS
>
> 3.1.7 Authentication of organizations
>
> When ordering an a.sign SSL EV certificate, the domain and
> organization 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 by comparing the
> provided data with data gathered from the corresponding online -
> database. The registration number has to be included in the request.
> A.sign SSL certificates can only be issued to organizations, whose
> head office is located in the EU. The physical address is also
> verified using the official register. If not applicable (the
> organization is a legal entity that cannot be found in the given
> registers, for example a governmental authority or self-employed
> persons) , the check is performed using a duplicate of a document
> that confirms the organizations existence, acquired from a
> governmental entity. Examples for such documents are extracts from
> legal registers or databases of trusted third parties.
>
> All communication with the involved parties (applicant, authorized
> persons from the organization, trusted third parties like governmental
> contacts) is carried out through e-mail, fax or telephone.
>
I think this satisfies the questions about what A-Trust does when the
entity is not in the EBR... A-Trust will use a trusted third party
governmental entity to confirm the organization's existence.
> 3.1.8 Check of domain / IP address
>
> A-Trust verifies the validity of the ownership of the requested domain
> by querying a database like www.nic.at, www.denic.de. If the
> applicant is not the owner of the domain himself, a written
> confirmation signed by the owner is required. If the included address
> is an IP address and no domain, a written confirmation (that the IP
> address is only assigned to the applicant) issued by the applicants
> provider is needed.
>
> In case of a.sign SSL EV certificates, the use of IP – addresses is
> restricted. A-Trust may verify that the applicant is aware of his
> exclusive control of the domain name by obtaining a confirmation from
> the
> administrative contact listed at the domain record through e-mail or
> telephone.
>
I think there's a cut-and-paste error in this translation. I think for
the SSL CPS there are three paragraphs in this section, and none of them
mention EV certs. If this is the case, please provide the translation of
section 3.1.8 of the SSL CPS.
> 3.1.9 Authentication of individuals
>
> 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 organization
>
> • an organizational responsible person, that is allowed to sign in the
> ogranizations name and confirms the correctness of the application
>
> The people that are mentioned in the application have to provide an
> identification document from the following list:
>
> • a Photo ID, issued in Austria (a list of accepted documents is
> available at the A-Trust Website)
> • an international passport in german or english language
>
> If the organizational responsible person is not listed in the used
> register, additional confirmation of his status has to be provided
> (i.e. a certificate of authority from a person allowed to sign for the
> company – check through business register / EBR).
>
Again, I think there's a cut-and-paste error in this translation. In the
SSL CPS I don't think there is any mention of EV certs in section 3.1.9.
I am not able to tell if there are other differences.
Thanks for translating this section too; the 3.25 in item #4 confused
me. The last paragraph clarifies that EV SSL certs may not be extended.
So I guess that means that they can only be valid for up to 2.25 years
as per the EV SSL CPS. It seems like #4 belongs in the SSL CP rather
than the EV SSL CP.
Kathleen
Christoph Klein
Hi!
> Thanks. I have some additional comments...
> …
> I think this satisfies the questions about what A-Trust does when the
> entity is not in the EBR... A-Trust will use a trusted third party
> governmental entity to confirm the organization's existence.
> …
> I think there's a cut-and-paste error in this translation. I think for
> the SSL CPS there are three paragraphs in this section, and none of them
> mention EV certs. If this is the case, please provide the translation of
> section 3.1.8 of the SSL CPS.
>
Yes, I forgot to remove the sentence from the translation at the
a.sign SSL part – the rest of the section is completely similar, in
case of EV there is one added sentence (regarding no IP addresses with
EV – certificates. So the correct translation for 3.1.8 in the a.sign
SSL CPS:
A-Trust verifies the validity of the ownership of the requested domain
by querying a database like www.nic.at, www.denic.de. If the
applicant is not the owner of the domain himself, a written
confirmation signed by the owner is required.
If the included address is an IP address and no domain, a written
confirmation (that the IP address is only assigned to the applicant)
issued by the applicants provider is needed.
A-Trust may verify that the applicant is aware of his exclusive
control of the domain name by obtaining a confirmation from the
administrative contact listed at the domain record through e-mail or
telephone.
>
> Again, I think there's a cut-and-paste error in this translation. In the
> SSL CPS I don't think there is any mention of EV certs in section 3.1.9.
> I am not able to tell if there are other differences.
>
The section is completely the same in the a.sign SSL and the a.sign
SSL EV documents. We did not remove the parts only relevant to a.sign
SSL certificates from the “new” EV policies, because we want to merge
the policies into one document in the future.
>
>
> Thanks for translating this section too; the 3.25 in item #4 confused
> me. The last paragraph clarifies that EV SSL certs may not be extended.
> So I guess that means that they can only be valid for up to 2.25 years
> as per the EV SSL CPS. It seems like #4 belongs in the SSL CP rather
than the EV SSL CP.
>
Yes , that’s true – I explained the reason above (we want to combine
the documents in the future, maybe the next WebTrust/WebTrust EV
recertification).
Regards,
Christoph
Kathleen Wilson
> on the Websites trust bit, and enable EV.
>
> A-Trust is an accredited TrustCenter in Austria issuing smartcard based
> qualified certificates for Austrian citizens used in eGovernment.
> A-Trust has been accredited according to the Austrian Signature Law by
> 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.
>
> The request is documented in the following bug:
> https://bugzilla.mozilla.org/show_bug.cgi?id=530797
>
> And in the pending certificates list here:
> http://www.mozilla.org/projects/security/certs/pending/#A-Trust
>
> Information Gathering Document:
> https://bugzilla.mozilla.org/attachment.cgi?id=518133
>
> Noteworthy points:
>
> * Cert Download URL: http://www.a-trust.at/certs/A-Trust-nQual-03.crt
>
> * The CP/CPS documents are in German. Translations of some sections of
> the documents are included in the Information Gathering Document.
>
> 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
>
> https://www.a-trust.at/docs/CA-Hierarchy_v11.pdf
> ** This root inclusion request is only for the “A-Trust-nQual-03” root
> certificate which has internally-operated subordinate CAs for signing
> certificates for smart cards, email, code signing, and SSL.
>
Thanks again to those of you who have reviewed and commented on this
request from A-Trust to add the “A-Trust-nQual-03” root certificate,
turn on the Websites trust bit, and enable EV.
As a result of this discussion, A-Trust has updated their CP/CPS
documentation as follows.
1) Clarified that if the ordering entity is not registered in the
Austrian commercial register or the EBR, A-Trust will use a trusted
third party governmental entity to confirm the organization's existence.
2) Specified that SSL certs may be valid up to 3.25 years, and EV SSL
certs may be valid up to 2.25 years.
3) Removed the indication that the O field is optional, because only OV
and EV SSL certs are issued.
4) Clarified domain name verification.
English translations of the relevant sections of the CP/CPS documents
have been provided and attached to the bug:
https://bugzilla.mozilla.org/attachment.cgi?id=533777
To those of you who have already commented on this request, do the
updates to the CP/CPS sufficiently address the questions/concerns that
you raised?
Further comments on this request will also be appreciated.
Kathleen
Kathleen Wilson
If there are no further comments or concerns regarding this request I
will close this discussion and update the bug to recommend approval to
add the “A-Trust-nQual-03” root certificate, turn on the Websites trust
bit, and enable EV.
Kathleen
Kathleen Wilson
The action items that were identified during this discussion have been
completed, and A-Trust has updated their CP/CPS documentation to add the
requested clarifications.
This concludes the public discussion about A-Trust’s request to add the
“A-Trust-nQual-03” root certificate, turn on the Websites trust bit, and
enable EV.
I will post my recommendation for approval of this request in the bug.
https://bugzilla.mozilla.org/show_bug.cgi?id=530797
All follow-up on this request should be posted directly in the bug.
Thanks again to all of you who have participated in this discussion.
Kathleen