Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Firmaprofesional Request to Enable EV Treatment
588 views
Skip to first unread message
Kathleen Wilson
Aug 6, 2013, 1:59:29 PM8/6/13
to mozilla-dev-s...@lists.mozilla.org
Firmaprofesional has applied to enable EV treatment for the “Autoridad
de Certificacion Firmaprofesional CIF A62634068” root certificate that
was included in NSS via Bugzilla #521439.
Firmaprofesional is a commercial CA in Spain that issues certificates to
professional corporations, companies and other institutions. Their main
activity is the generation, transmission and distribution of digital
certificates through professional corporations, companies or other
institutions, which act as Registration Authorities and Certification
Authorities in the hierarchy of certification Firmaprofesional.
Firmaprofesional has a network of more than 70 Registration Authorities
located throughout Spain.
The request is documented in the following bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=794036
And in the pending certificates list here:
http://www.mozilla.org/projects/security/certs/pending/#Firmaprofesional
Summary of Information Gathered and Verified:
https://bugzilla.mozilla.org/attachment.cgi?id=779867
Noteworthy points:
* The primary documents are as follows:
Document Repository: http://www.firmaprofesional.com/cps
CPS (English): https://www.firmaprofesional.com/images/pdfs/FP_CPS_5-EN.pdf
SSL CP (English):
https://www.firmaprofesional.com/images/pdfs/FP_CP_Gen_Servidor_Web_SSL_6.2-EN.pdf
Code Signing CP (Spanish):
http://www.firmaprofesional.com/cps/FP_CP_Gen_Firma_Codigo_5.pdf
* CA Hierarchy: Currently Firmaprofesional's Certification Hierarchy
consists of two internal Subordinate CA certificates and one external
Subordinate CA certificate:
- The Subordinate Certification Authority "AC Firmaprofesional - CA1"
issues digital certificates to Private Corporations, as established by
Law 59/2003 of 19 December on electronic signatures.
- The Subordinate Certification Authority "AC Firmaprofesional - AAPP"
issues digital certificates to Public Corporations, as established by
Law 11/2007 of 22 June on Citizens' Electronic Access to Public Services.
- The Subordinate Certification Authority "SIGNE Autoridad de
Certificación" is governed by its own certification policies and
practices that can be obtained directly from SIGNE'S homepage:
http://www.signe.es (https://www.signe.es/signe-ac/dpc). SIGNE is an
external subordinate CA, with a number of caveats, namely:
1. RA software is the same used by the other RA’s bound to Firmaprofesional,
2. SIGNE Subordinate CA server and keys (HSM) are hosted in the
Firmaprofesional facilities. SIGNE and Firmaprofesional have signed a
service agreement by which, Firmaprofesional hosts SIGNE Subordinate CA
server and keys (HSM) and technically manage and maintain them
3. SIGNE Subordinate CA is not allowed to issue SSL Certificates.
* All three trust bits are already enabled for this root certificate.
This request is to enable EV treatment.
** CPS section 3.2.5 Domain Validation
To guarantee that an applicant entity has control over the domain (URL)
which it seeks to include in a certificate, two types of checks are
performed:
- Organizational checks: the ownership title of the domain name is
requested and is certified by a legal representative of the organization.
- Technical checks: the following authenticated whois services are
consulted:
-- For "*.es" domains:
https://www.nic.es/sgnd/dominio/publicInformacionDominios.action
-- For all other domains: https://www.networksolutions.com/whois/index.jsp
** SSL CP section 4.1:
The organization must be the holder of the domain in order to apply for
a SSL Secure Web Server Certificate.
…
Following verification must be done in order to guarantee that the
requesting organization has control over the domain (URL) that is
requested to be included in a certificate. This is carried out without
detriment to what is established in the corresponding Certification
Practice Statement (CPS) of Firmaprofesional:
1. The following authenticated whois services are consulted:
-- For “*.es” domains, consult the following authenticated WHOIS
service: https://www.nic.es/sqnd/dominio/publicInformacionDominios.action
-- For the rest of the domains consult on
http://www.iana.org/domains/root/db/ which is the authenticated WHOIS
server to look for information about the domain, depending on the Top
Level Domain (TLD), or said in another way, depending on whether the
domain ends in .com, .org, .net, …
2. The details of the applicant will be validated as “Administrative
Contact” of the domain.
3. The application, electronically signed by the legal representative,
will be validated. If this is not possible the organization details will
be validated through some of the following mechanisms:
a. Contractual agreement between the organization and Firmaprofesional,
previous to the application.
b. Consult the Commercial Register.
c. Manual verification of the organization’s details through telephone call.
** SSL CP section 4.1.e:
Firmaprofesional will issue an EV SSL Web Server Certificate if the
application is electronically signed with a Corporate Legal
Representative Certificate of Firmaprofesional; in other case it will be
issued a standard SSL Web Server Certificate.
Additionally, the EV SSL Web Server Certificate’s issuance requires the
approval of two people: the RA Operator responsible for managing the
request and the Technical Department Manager responsible for issuing the
certificate.
** Firmaprofesional RAs use a challenge/response mechanism to verify
that the certificate subscriber has control of the email address to be
included in the certificate when it is not the RA requesting the
certificate. Alternatively, the organization acting as the RA may
request a certificate on behalf of an individual and provide the
individual’s email address from their organization’s database, where the
email address is in the organization’s domain and controlled by the
organization.
** CPS Section 3.2.6: In general, the signers are people linked to the
Registration Authority (for example, associates, association members,
etc.). In these cases it is not the signer who requests a specific email
address to be included in the certificate but the RA itself which, by
consulting its database, obtains the address.
In cases where the signer has no connection with the RA, verification of
the e-mail address is performed using a challenge-response mechanism
* EV Policy OID: 1.3.6.1.4.1.13177.10.1.3.10
* Test Website: https://publifirma.firmaprofesional.com/
* CRL
http://crl.firmaprofesional.com/fproot.crl
http://crl.firmaprofesional.com/firmaprofesional1.crl (NextUpdate: 7 days)
CPS Section 4.9.6: The CRL of end-entity certificates is issued at least
every 24 hours, or whenever a revocation is effected, with a validity of
7 days.
* OCSP
http://servicios.firmaprofesional.com/ocsp
http://ocsp.firmaprofesional.com
Maximum expiration time of OCSP responses is from five (5) minutes up to
one (1) day, as a maximum, depending on the server load.
* Audit: Annual audits are performed by Ernst & Young, according to the
WebTrust CA and WebTrust EV criteria and posted on the webtrust.org website.
https://cert.webtrust.org/ViewSeal?id=946
https://cert.webtrust.org/ViewSeal?id=1363
* Potentially Problematic Practices – External RAs
(http://wiki.mozilla.org/CA:Problematic_Practices)
** SSL CP section 2.2: The Management of applications and issuances of
the certificates will be carried out by Firmaprofesional or by an
authorized intermediary. The authorized intermediaries will be register
domain’s entities accredited by ICANN which has a collaboration
agreement with Firmaprofesional.
** CPS section 1.3.3: The following may act as RA of Firmaprofesional:
- Any Corporation which is a client of Firmaprofesional, issuing
certificates in the name of the corporation or to the members of the
corporation.
- Any trusted institution reaching an agreement with Firmaprofesional,
acting as an intermediary on behalf of Firmaprofesional.
- Firmaprofesional itself directly.
** Firmaprofesional does not currently delegate issuance of SSL
certificates to third party RAs, but does currently delegate issuance of
S/MIME certificates to third party RAs. The RA software only shows to
the RA Operator the Policies the RA is allowed to issue. Only
Firmaprofesional's RA Administrators can change which Policies a RA can
issue.
This begins the discussion of the request from Firmaprofesional to
enable EV treatment for the “Autoridad de Certificacion Firmaprofesional
CIF A62634068” root certificate. At the conclusion of this discussion I
will provide a summary of issues noted and action items. If there are
outstanding issues, then an additional discussion may be needed as
follow-up. If there are no outstanding issues, then I will recommend
approval of this request in the bug.
Kathleen
de Certificacion Firmaprofesional CIF A62634068” root certificate that
was included in NSS via Bugzilla #521439.
Firmaprofesional is a commercial CA in Spain that issues certificates to
professional corporations, companies and other institutions. Their main
activity is the generation, transmission and distribution of digital
certificates through professional corporations, companies or other
institutions, which act as Registration Authorities and Certification
Authorities in the hierarchy of certification Firmaprofesional.
Firmaprofesional has a network of more than 70 Registration Authorities
located throughout Spain.
The request is documented in the following bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=794036
And in the pending certificates list here:
http://www.mozilla.org/projects/security/certs/pending/#Firmaprofesional
Summary of Information Gathered and Verified:
https://bugzilla.mozilla.org/attachment.cgi?id=779867
Noteworthy points:
* The primary documents are as follows:
Document Repository: http://www.firmaprofesional.com/cps
CPS (English): https://www.firmaprofesional.com/images/pdfs/FP_CPS_5-EN.pdf
SSL CP (English):
https://www.firmaprofesional.com/images/pdfs/FP_CP_Gen_Servidor_Web_SSL_6.2-EN.pdf
Code Signing CP (Spanish):
http://www.firmaprofesional.com/cps/FP_CP_Gen_Firma_Codigo_5.pdf
* CA Hierarchy: Currently Firmaprofesional's Certification Hierarchy
consists of two internal Subordinate CA certificates and one external
Subordinate CA certificate:
- The Subordinate Certification Authority "AC Firmaprofesional - CA1"
issues digital certificates to Private Corporations, as established by
Law 59/2003 of 19 December on electronic signatures.
- The Subordinate Certification Authority "AC Firmaprofesional - AAPP"
issues digital certificates to Public Corporations, as established by
Law 11/2007 of 22 June on Citizens' Electronic Access to Public Services.
- The Subordinate Certification Authority "SIGNE Autoridad de
Certificación" is governed by its own certification policies and
practices that can be obtained directly from SIGNE'S homepage:
http://www.signe.es (https://www.signe.es/signe-ac/dpc). SIGNE is an
external subordinate CA, with a number of caveats, namely:
1. RA software is the same used by the other RA’s bound to Firmaprofesional,
2. SIGNE Subordinate CA server and keys (HSM) are hosted in the
Firmaprofesional facilities. SIGNE and Firmaprofesional have signed a
service agreement by which, Firmaprofesional hosts SIGNE Subordinate CA
server and keys (HSM) and technically manage and maintain them
3. SIGNE Subordinate CA is not allowed to issue SSL Certificates.
* All three trust bits are already enabled for this root certificate.
This request is to enable EV treatment.
** CPS section 3.2.5 Domain Validation
To guarantee that an applicant entity has control over the domain (URL)
which it seeks to include in a certificate, two types of checks are
performed:
- Organizational checks: the ownership title of the domain name is
requested and is certified by a legal representative of the organization.
- Technical checks: the following authenticated whois services are
consulted:
-- For "*.es" domains:
https://www.nic.es/sgnd/dominio/publicInformacionDominios.action
-- For all other domains: https://www.networksolutions.com/whois/index.jsp
** SSL CP section 4.1:
The organization must be the holder of the domain in order to apply for
a SSL Secure Web Server Certificate.
…
Following verification must be done in order to guarantee that the
requesting organization has control over the domain (URL) that is
requested to be included in a certificate. This is carried out without
detriment to what is established in the corresponding Certification
Practice Statement (CPS) of Firmaprofesional:
1. The following authenticated whois services are consulted:
-- For “*.es” domains, consult the following authenticated WHOIS
service: https://www.nic.es/sqnd/dominio/publicInformacionDominios.action
-- For the rest of the domains consult on
http://www.iana.org/domains/root/db/ which is the authenticated WHOIS
server to look for information about the domain, depending on the Top
Level Domain (TLD), or said in another way, depending on whether the
domain ends in .com, .org, .net, …
2. The details of the applicant will be validated as “Administrative
Contact” of the domain.
3. The application, electronically signed by the legal representative,
will be validated. If this is not possible the organization details will
be validated through some of the following mechanisms:
a. Contractual agreement between the organization and Firmaprofesional,
previous to the application.
b. Consult the Commercial Register.
c. Manual verification of the organization’s details through telephone call.
** SSL CP section 4.1.e:
Firmaprofesional will issue an EV SSL Web Server Certificate if the
application is electronically signed with a Corporate Legal
Representative Certificate of Firmaprofesional; in other case it will be
issued a standard SSL Web Server Certificate.
Additionally, the EV SSL Web Server Certificate’s issuance requires the
approval of two people: the RA Operator responsible for managing the
request and the Technical Department Manager responsible for issuing the
certificate.
** Firmaprofesional RAs use a challenge/response mechanism to verify
that the certificate subscriber has control of the email address to be
included in the certificate when it is not the RA requesting the
certificate. Alternatively, the organization acting as the RA may
request a certificate on behalf of an individual and provide the
individual’s email address from their organization’s database, where the
email address is in the organization’s domain and controlled by the
organization.
** CPS Section 3.2.6: In general, the signers are people linked to the
Registration Authority (for example, associates, association members,
etc.). In these cases it is not the signer who requests a specific email
address to be included in the certificate but the RA itself which, by
consulting its database, obtains the address.
In cases where the signer has no connection with the RA, verification of
the e-mail address is performed using a challenge-response mechanism
* EV Policy OID: 1.3.6.1.4.1.13177.10.1.3.10
* Test Website: https://publifirma.firmaprofesional.com/
* CRL
http://crl.firmaprofesional.com/fproot.crl
http://crl.firmaprofesional.com/firmaprofesional1.crl (NextUpdate: 7 days)
CPS Section 4.9.6: The CRL of end-entity certificates is issued at least
every 24 hours, or whenever a revocation is effected, with a validity of
7 days.
* OCSP
http://servicios.firmaprofesional.com/ocsp
http://ocsp.firmaprofesional.com
Maximum expiration time of OCSP responses is from five (5) minutes up to
one (1) day, as a maximum, depending on the server load.
* Audit: Annual audits are performed by Ernst & Young, according to the
WebTrust CA and WebTrust EV criteria and posted on the webtrust.org website.
https://cert.webtrust.org/ViewSeal?id=946
https://cert.webtrust.org/ViewSeal?id=1363
* Potentially Problematic Practices – External RAs
(http://wiki.mozilla.org/CA:Problematic_Practices)
** SSL CP section 2.2: The Management of applications and issuances of
the certificates will be carried out by Firmaprofesional or by an
authorized intermediary. The authorized intermediaries will be register
domain’s entities accredited by ICANN which has a collaboration
agreement with Firmaprofesional.
** CPS section 1.3.3: The following may act as RA of Firmaprofesional:
- Any Corporation which is a client of Firmaprofesional, issuing
certificates in the name of the corporation or to the members of the
corporation.
- Any trusted institution reaching an agreement with Firmaprofesional,
acting as an intermediary on behalf of Firmaprofesional.
- Firmaprofesional itself directly.
** Firmaprofesional does not currently delegate issuance of SSL
certificates to third party RAs, but does currently delegate issuance of
S/MIME certificates to third party RAs. The RA software only shows to
the RA Operator the Policies the RA is allowed to issue. Only
Firmaprofesional's RA Administrators can change which Policies a RA can
issue.
This begins the discussion of the request from Firmaprofesional to
enable EV treatment for the “Autoridad de Certificacion Firmaprofesional
CIF A62634068” root certificate. At the conclusion of this discussion I
will provide a summary of issues noted and action items. If there are
outstanding issues, then an additional discussion may be needed as
follow-up. If there are no outstanding issues, then I will recommend
approval of this request in the bug.
Kathleen
Erwann Abalea
Aug 7, 2013, 9:13:44 AM8/7/13
to
Le mardi 6 août 2013 19:59:29 UTC+2, Kathleen Wilson a écrit :
> Firmaprofesional has applied to enable EV treatment for the “Autoridad
> de Certificacion Firmaprofesional CIF A62634068” root certificate that
> was included in NSS via Bugzilla #521439.
[...]
> Firmaprofesional has applied to enable EV treatment for the “Autoridad
> de Certificacion Firmaprofesional CIF A62634068” root certificate that
> was included in NSS via Bugzilla #521439.
Testing both OCSP responders to validate the test certificate (publifirma.firmaprofesional.com) or the intermediate CA certificate gives a valid answer for POST requests, but invalid for GET requests:
- if the request is URL-encoded, the result is a 404 error
- if the request isn't URL-encoded, i'm continously redirected to http://ocsp.firmaprofesional.com/<part of OCSPRequest until the last '/'>/errorOCSPPUBLICO.html (there's a loop, my wget stops after 20 redirections)
Erwann Abalea
Aug 7, 2013, 9:25:10 AM8/7/13
to
chem...@isigma.es
Aug 27, 2013, 6:57:39 AM8/27/13
to
First of all, thanks, Erwann, for the findings.
We start to work to solve them. We will need to issue a new OCSP certificate with the OCSPNoCheck extension activated and warn to our customers and give them some time.
Thanks again.
We start to work to solve them. We will need to issue a new OCSP certificate with the OCSPNoCheck extension activated and warn to our customers and give them some time.
Thanks again.
Chema Lopez
Sep 25, 2013, 4:37:10 AM9/25/13
to
Dear all, we are proud to announce that we have solved the issues detected by Erwann Abalea.
Is it possible to continue with the process, now? Remember, test URL is:
https://publifirma.firmaprofesional.com/
Thanks to all of you.
Is it possible to continue with the process, now? Remember, test URL is:
https://publifirma.firmaprofesional.com/
Thanks to all of you.
Erwann Abalea
Sep 26, 2013, 11:10:36 AM9/26/13
to
Bonjour,
Le mercredi 25 septembre 2013 10:37:10 UTC+2, Chema Lopez a écrit :
> Dear all, we are proud to announce that we have solved the issues detected by Erwann Abalea.
>
> Is it possible to continue with the process, now? Remember, test URL is:
> https://publifirma.firmaprofesional.com/
The OCSP responder certificate has the "OCSPNoCheck" extension.
But the OCSP service is still unavailable for GET requests. There's no more recursive 302 redirections, but the service isn't available.
Therefore, your OCSP service isn't BR compliant.
Le mercredi 25 septembre 2013 10:37:10 UTC+2, Chema Lopez a écrit :
> Dear all, we are proud to announce that we have solved the issues detected by Erwann Abalea.
>
> Is it possible to continue with the process, now? Remember, test URL is:
> https://publifirma.firmaprofesional.com/
But the OCSP service is still unavailable for GET requests. There's no more recursive 302 redirections, but the service isn't available.
Therefore, your OCSP service isn't BR compliant.
Chema Lopez
Sep 30, 2013, 12:43:16 PM9/30/13
to
We are going to investigate why the service is not available, since it seemed to be available five days ago.
Chema Lopez
Oct 1, 2013, 5:20:10 AM10/1/13
to
El jueves, 26 de septiembre de 2013 17:10:36 UTC+2, Erwann Abalea escribió:
We have fixed the issues kindly reported by Erwann Abalea.
Thanks.
Erwann Abalea
Oct 10, 2013, 11:31:03 AM10/10/13
to
Bonjour,
Still no.
Look at RFC2560/6960 section A.1, describing the format of a request sent over HTTP:
An OCSP request using the GET method is constructed as follows:
GET {url}/{url-encoding of base-64 encoding of the DER encoding of
the OCSPRequest}
That is, some characters from the base64 representation of the request are transformed:
/ is transformed into %2F
+ is transformed into %2B
= is transformed into %3D
and your OCSP responder is supposed to reverse that transformation (only once), then base-64 decode the string, and continue with the process (OCSP request parsing, etc).
Your OCSP service don't show any problem when + and = are URL-encoded, but when a / is URL-encoded, an HTTP 404 error is returned.
If you want to see it in practice under a different browser (IE, for example), clear the OCSP+CRL cache, capture network trafic going from your desktop to {ocsp,crl,crl2}.firmaprofesional.com and tcp port 80, and try to connect to the test site (publifirma). The browser/OS will first request an OCSP token with a GET request (URL-encoded), receive a 404 error, and fallback to CRL download, thus hiding the malfunction of the OCSP responder.
Look at RFC2560/6960 section A.1, describing the format of a request sent over HTTP:
An OCSP request using the GET method is constructed as follows:
GET {url}/{url-encoding of base-64 encoding of the DER encoding of
the OCSPRequest}
That is, some characters from the base64 representation of the request are transformed:
/ is transformed into %2F
+ is transformed into %2B
= is transformed into %3D
and your OCSP responder is supposed to reverse that transformation (only once), then base-64 decode the string, and continue with the process (OCSP request parsing, etc).
Your OCSP service don't show any problem when + and = are URL-encoded, but when a / is URL-encoded, an HTTP 404 error is returned.
If you want to see it in practice under a different browser (IE, for example), clear the OCSP+CRL cache, capture network trafic going from your desktop to {ocsp,crl,crl2}.firmaprofesional.com and tcp port 80, and try to connect to the test site (publifirma). The browser/OS will first request an OCSP token with a GET request (URL-encoded), receive a 404 error, and fallback to CRL download, thus hiding the malfunction of the OCSP responder.
Chema Lopez
Oct 11, 2013, 2:59:19 AM10/11/13
to
Thanks, Erwan for the details, that will help us a lot to fix this issue.
We put hands on!
We put hands on!
Chema Lopez
Oct 11, 2013, 4:31:53 AM10/11/13
to
It was a flag in Apache, that treated the "/".
Kathleen Wilson
Oct 28, 2013, 1:47:22 PM10/28/13
to mozilla-dev-s...@lists.mozilla.org
On 8/6/13 10:59 AM, Kathleen Wilson wrote:
> Firmaprofesional has applied to enable EV treatment for the “Autoridad
> de Certificacion Firmaprofesional CIF A62634068” root certificate that
> was included in NSS via Bugzilla #521439.
>
Thank you Erwann for providing feedback on this request.
> Firmaprofesional has applied to enable EV treatment for the “Autoridad
> de Certificacion Firmaprofesional CIF A62634068” root certificate that
> was included in NSS via Bugzilla #521439.
>
The OCSP issues (with regards to complying with the Baseline
Requirements) have been resolved, so if there is no further feedback for
Firmaprofesional on this request, I will recommend approval in the bug.
Thanks,
Kathleen
Kathleen Wilson
Oct 30, 2013, 3:37:59 PM10/30/13
to mozilla-dev-s...@lists.mozilla.org
On 10/28/13 10:47 AM, Kathleen Wilson wrote:
> On 8/6/13 10:59 AM, Kathleen Wilson wrote:
>> Firmaprofesional has applied to enable EV treatment for the “Autoridad
>> de Certificacion Firmaprofesional CIF A62634068” root certificate that
>> was included in NSS via Bugzilla #521439.
Thank you to those of you who reviewed and contributed to this
> On 8/6/13 10:59 AM, Kathleen Wilson wrote:
>> Firmaprofesional has applied to enable EV treatment for the “Autoridad
>> de Certificacion Firmaprofesional CIF A62634068” root certificate that
>> was included in NSS via Bugzilla #521439.
discussion about the request from Firmaprofesional to enable EV
treatment for the “Autoridad de Certificacion Firmaprofesional CIF
A62634068” root certificate.
The concerns that were raised during this discussion have been resolved.
I am closing this discussion, and I will recommend approval in the bug.
https://bugzilla.mozilla.org/show_bug.cgi?id=794036
Any further follow-up on this request should be added directly to the bug.
Thanks,
Kathleen
0 new messages