794036 - Enable EV for Firmaprofesional

Status: RESOLVED FIXED

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

Description

[Chema López]

Attachment: SSL Secure Web Server Certificate Policy, v.6.1 EN

User Agent: Mozilla/5.0 (X11; Linux i686) AppleWebKit/536.5 (KHTML, like Gecko) Chrome/19.0.1084.52 Safari/536.5




Expected results:

Reference to the original root-inclusion bug number: #342426
Reference to the renewed root-inclusion bug number: #521439
Links to the:
 - updated CP/CPS (ES, please, find attached an English version): http://www.firmaprofesional.com/cps/FP_CP_Gen_Servidor_Web_SSL_6.1.pdf
 - and the WebTrust EV audit: https://cert.webtrust.org/ViewSeal?id=1363

Comment 1

[Kathleen Wilson]

Attachment: Initial CA Information Document

The attached document summarizes the information that has been verified.

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

Comment 2

[Chema López]

Attachment: Answers to the Initial CA Information Document Questions

Except for the first two questions, I think that this document provides answers to all other

Comment 3

[Kathleen Wilson]

Attachment: Updated CA Information Document

Please note a few more questions on pages 6 and 7.

Comment 4

[Kathleen Wilson]

Attachment: test_ev_roots.txt

Comment 5

[Chema López]

Attachment: OCSP Response

To parse the attached OCSP response to verify "maximum expiration time of OCSP responses"

Comment 6

[Chema López]

Attachment: OCSP Response

To parse the attached OCSP response in order to verify the "maximum expiration time of OCSP responses".

Comment 7

[Chema López]

Attachment: Answers to the Updated CA Information Document

Comment 8

[Kathleen Wilson]

(In reply to chemalogo from comment #7)
> Answers to the Updated CA Information Document

Thanks! I've updated my notes, and will watch this bug for the test website and updated CP.

Comment 9

[Chema López]

Hi! I made a mistake an uploaded twice the OCSP Response. Is there any way to delete   one of the attachments? Tx.

Comment 10

[Chema López]

Regarding the EV treatment test issue, I have read in the https://wiki.mozilla.org/PSM:EV_Testing_Easy_Version page that "We are willing to help you produce those technical representation. If you have started the formal process to request being added to the Mozilla root store, and have attached your root to a bugzilla bug, you may ask us to produce it for you."

Which are the steps to ask you to produce it?

Thanks!

Comment 11

[Kathleen Wilson]

(In reply to chemalogo from comment #10)
> "We are
> willing to help you produce those technical representation. If you have
> started the formal process to request being added to the Mozilla root store,
> and have attached your root to a bugzilla bug, you may ask us to produce it
> for you."

See Comment #4, where I have attached the test_ev_roots.txt file that you can use to perform the testing as described in
https://wiki.mozilla.org/PSM:EV_Testing_Easy_Version

Comment 12

[Chema López]

Thanks, Kathleen.

The test URL is: https://viafirma.firmaprofesional.com/viafirma/

Comment 13

[Chema López]

Attachment: ASN editor crashed while trying yo convert "serialNumber" field

Comment 14

[Chema López]

Is it possible that "test_ev_roots.txt" is not well generated?
Trying to convert it using ASN Editor, we can convert CN field and see it well, as the CA root 2030 CN, but when we try to do the same with the serialNumber field ASN Editor crashes (see attachment 689645 [details])

We tried to do this since we are unabla to perform the Website URL test (so we can not add screenshots)

Comment 15

[Kaspar]

(In reply to chemalogo from comment #14)
> Is it possible that "test_ev_roots.txt" is not well generated?
> Trying to convert it using ASN Editor, we can convert CN field and see it
> well, as the CA root 2030 CN,

It's the complete DN, for the record (including the countryName RDN)

> but when we try to do the same with the serialNumber field ASN Editor crashes

https://wiki.mozilla.org/PSM:EV_Testing states:

"Note that the binary representation of the serial number is of the DER encoded INTEGER with the Identifier and Length octets removed. Only the Contents octets from the DER representation of the integer serial number are base64 encoded for this file."

Comment 16

[Kathleen Wilson]

(In reply to chemalogo from comment #12)
> The test URL is: https://viafirma.firmaprofesional.com/viafirma/

I notice two problems:

1) The Policy OID in the intermediate cert doesn't match the EV Policy OID that was used to generate test_ev_roots.txt. It also doesn't match the EV Policy OID in the end-entity cert.
2_readable_oid 1.3.6.1.4.1.13177.10.1.3.10

2) There is no OCSP URI in the AIA of the intermediate cert.
https://wiki.mozilla.org/PSM:EV_Testing_Easy_Version#Not_Getting_EV_Treatment.3F

Comment 17

[Chema López]

(In reply to Kathleen Wilson from comment #16)
> (In reply to chemalogo from comment #12)
> > The test URL is: https://viafirma.firmaprofesional.com/viafirma/
> 
> I notice two problems:
> 
> 1) The Policy OID in the intermediate cert doesn't match the EV Policy OID
> that was used to generate test_ev_roots.txt. It also doesn't match the EV
> Policy OID in the end-entity cert.
> 2_readable_oid 1.3.6.1.4.1.13177.10.1.3.10
> 
I do not understand this issue. The certificate at https://viafirma.firmaprofesional.com/viafirma/ contains Policy OID: 1.3.6.1.4.1.13177.10.1.3.10. On the other hand, in the documentation provided one can see that the EV Policy OID claimed is the same one (see 1.2 IDENTIFICATION OF THE DOCUMENT, in the attached document "SSL Secure Web Server Certificate Policy", v.6.1 EN -https://bugzilla.mozilla.org/attachment.cgi?id=664446-)
It is also stated that the EV Policy OID is in the attached document "Answers to the Initial CA Information Document Questions" -https://bugzilla.mozilla.org/attachment.cgi?id=669465-)

So what should we do, now?

> 2) There is no OCSP URI in the AIA of the intermediate cert.
> https://wiki.mozilla.org/PSM:
> EV_Testing_Easy_Version#Not_Getting_EV_Treatment.3F

Seen at https://wiki.mozilla.org/CA:EV_Revocation_Checking#Requirements:
"6. OCSP must also work for the intermediate certificates. A failed OCSP response will result in EV treatment not being given.", but this is not a requirement in neither "CA/Browser Forum - Guidelines For The Issuance And Management Of Extended Validation Certificates, Version 1.4" nor in "WebTrust Certification authorities – 
extended validation AUDIT CRITERIA, Version 1.3" so we do not fulfil this point. Is there any workaround?

From my point of view it is significant to renew an Intermediate CA certificate with the only purpose to modify an extension (to add some information), specially if it has thousands of valid certificates. On the other hand, it is also significant to issue a new intermediate CA and start to issue certificates from this new i-CA, so this is why I am asking for a workaround.

Comment 18

[Kaspar]

Attachment: the current intermediate CA certificate, for reference purposes ("CA1", http://crl.firmaprofesional.com/ca1.crt)

(In reply to chemalogo from comment #17)
> So what should we do, now?

1) read section 6.1.3(d) in RFC 5280 to understand how the certificatePolicies extension is expected to be populated with OIDs

2) read section 9.3.4 of the EV Guidelines to understand the policy OID requirements for EV subordinate CA certs

3) issue a new intermediate CA with a correct certificatePolicies extension: at the very least, you need to change 1.3.6.1.4.1.1377.10.10.1 to 1.3.6.1.4.1.13177.10.10.1 (I don't think that you want to use OIDs from the arc assigned to Comedia Information AB)

> Seen at https://wiki.mozilla.org/CA:EV_Revocation_Checking#Requirements:
> "6. OCSP must also work for the intermediate certificates. A failed OCSP
> response will result in EV treatment not being given.", but this is not a
> requirement in neither "CA/Browser Forum - Guidelines For The Issuance And
> Management Of Extended Validation Certificates, Version 1.4"

Providing an OCSP responder for EV subordinate CA certificates has been a requirement since 1 July 2012, see section 13 of the EV guidelines:

> The requirements in Section 13 of the Baseline Requirements apply equally to
> EV Certificates.

And section 13.2.2 of the Baseline Requirements states:

> For the status of Subordinate CA Certificates:
> [...]
> 2. The CA SHALL update information provided via an Online Certificate Status
> Protocol at least (i) every twelve months and (ii) within 24 hours after
> revoking a Subordinate CA Certificate.
> Effective 1 January 2013, the CA SHALL support an OCSP capability using the
> GET method for Certificates issued in accordance with these Requirements.

Comment 19

[Chema López]

(In reply to Kaspar Brand from comment #18)

First of all, thanks for the quick answer.

> (In reply to chemalogo from comment #17)
> > So what should we do, now?
> 
> 1) read section 6.1.3(d) in RFC 5280 to understand how the
> certificatePolicies extension is expected to be populated with OIDs
 
We will do it, but this is the first time someone ask us to change the way we populate the certificatePolicies extension.
We will read it in order to improve our certificates.

> 2) read section 9.3.4 of the EV Guidelines to understand the policy OID
> requirements for EV subordinate CA certs

We did it when we developed the Certificate Policy. We read the 1.4 version (https://www.cabforum.org/Guidelines_v1_4.pdf) and nowadays I can not find a newer version. What is the problem?

The intermediate CA is controlled by the Root CA, so the 9.3.4 EV Subordinate CA Certificates section states that the anyPolicy 
identifier (OID:  2.5.29.32.0) is optional (MAY shall be interpreted in accordance with RFC 2119), so O do not see what's wrong.

> 3) issue a new intermediate CA with a correct certificatePolicies extension:
> at the very least, you need to change 1.3.6.1.4.1.1377.10.10.1 to
> 1.3.6.1.4.1.13177.10.10.1 (I don't think that you want to use OIDs from the
> arc assigned to Comedia Information AB)

OMG! Yes! You are right! We have the 1.3.6.1.4.1.13177... and not the 1.3.6.1.4.1.1377... As you may know, it is not an easy task to issue a new intermediate certificate so we plan to do it during this very year!

 
> > Seen at https://wiki.mozilla.org/CA:EV_Revocation_Checking#Requirements:
> > "6. OCSP must also work for the intermediate certificates. A failed OCSP
> > response will result in EV treatment not being given.", but this is not a
> > requirement in neither "CA/Browser Forum - Guidelines For The Issuance And
> > Management Of Extended Validation Certificates, Version 1.4"
> 
> Providing an OCSP responder for EV subordinate CA certificates has been a
> requirement since 1 July 2012, see section 13 of the EV guidelines:

You are right, so we will include it in the new subordinate CA certificate to be issued during this 2013.
 
> > The requirements in Section 13 of the Baseline Requirements apply equally to
> > EV Certificates.
> 
> And section 13.2.2 of the Baseline Requirements states:
> 
> > For the status of Subordinate CA Certificates:
> > [...]
> > 2. The CA SHALL update information provided via an Online Certificate Status
> > Protocol at least (i) every twelve months and (ii) within 24 hours after
> > revoking a Subordinate CA Certificate.
> > Effective 1 January 2013, the CA SHALL support an OCSP capability using the
> > GET method for Certificates issued in accordance with these Requirements.

Thanks again.

Comment 20

[Chema López]

Unfortunately we will not be able to face the issuance of a new subordinate certificate in the first quarter due to the following reasons:

 1.- first of all, the old hierarchy is to be out of date at the end of march, so it doesn't seem a good idea to issue a new subCA certificate during this transition period.

 2.- secondly, currently we are renewing our WebTrust for CA seal. The audit is going well, but with the new version of the principles, there's a lot of work to do, so to add new changes will add complexity to the process.

 3.- finally, we are also being audited by the Spanish Ministry of Industry, Energy and Tourism. This is a regular audit here in Spain but it is the first time we have to pass it. The Ministry wants to audit all the Certification Services Providers in order to prepare them to the eventual yearly-audit outlined in the Proposal for a REGULATION OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL on electronic identification and trust services for electronic transactions in the internal market (http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=COM:2012:0238:FIN:en:PDF). This audit also is proceeding properly through the appropriate channels.

Firmaprofesional has always fulfilled its commitments and has been at the forefront of security concerns, actively working with the Mozilla Foundation in the investigation of the DigiNotar case, so we hope that this event does not paralyze the activation process of EV in our CA root.

Thanks in advance.

Comment 21

[Kathleen Wilson]

(In reply to chemalogo from comment #20)
> Unfortunately we will not be able to face the issuance of a new subordinate
> certificate in the first quarter due to the following reasons

That's fine. Please update this bug when you have issued the new intermediate cert, and successfully tested EV as described here:
https://wiki.mozilla.org/PSM:EV_Testing_Easy_Version


> Firmaprofesional has always fulfilled its commitments and has been at the
> forefront of security concerns, actively working with the Mozilla Foundation
> in the investigation of the DigiNotar case, so we hope that this event does
> not paralyze the activation process of EV in our CA root.

We can continue with the approval process for enabling EV after you update this bug to indicate successful completion of EV testing.

Comment 22

[Chema López]

Attachment: New subordinate CA meeting REQUIREMENTS (MUST's), we hope

Comment 23

[Chema López]

The new Subordinate CA certificate could raise two concerns:

 (1) cRLDistributionPoints: distributionPoint is HTTPS. Although Baseline Requirements Appendix B regarding subCA certs states that "cRLDistributionPoints - This extension MUST be present and MUST NOT be marked critical. It MUST contain the HTTP URL of the CA’s CRL service." We do not see any problem nor security issue using a HTTPS.

Why do we use a HTTPS? There is a law in Spain (Ley 11/2007, de 22 de junio, de acceso electrónico de los ciudadanos a los Servicios Públicos - Law 11/2007 of 22 June, on electronic access of citizens to Public Services) that REQUIRES the cRLDistributionPoints to contain an HTTPS URL. Does it make sense? I do not really think so, taking into account that a CRL is signed information so, origin and integrity are "guarantee".

 (2) anyPolicy identifier (OID:  2.5.29.32.0) not included: as stated in Comment 19 (2013-01-04 05:03:05 PST), the intermediate CA is controlled by the Root CA, so the 9.3.4 EV Subordinate CA Certificates section states that the anyPolicy identifier (OID:  2.5.29.32.0) is optional (MAY shall be interpreted in accordance with RFC 2119), so O do not see what's wrong.

Thanks in advance,

Comment 24

[Kathleen Wilson]

Have you successfully completed EV Testing?
https://wiki.mozilla.org/PSM:EV_Testing_Easy_Version

https://wiki.mozilla.org/CA:EV_Revocation_Checking#Requirements

Comment 25

[Chema López]

(In reply to Kathleen Wilson from comment #24)

Hi, Kathleen.

We are working on it right now.

I will update the ticket with the results.

Thanks.

> Have you successfully completed EV Testing?
> https://wiki.mozilla.org/PSM:EV_Testing_Easy_Version
> 
> https://wiki.mozilla.org/CA:EV_Revocation_Checking#Requirements

Comment 26

[Chema López]

We think we are performing the test following the instructions, but we are not able to reach a right result!

Two questions, then:
 1.- Are the following lines built correctly, from the provided CA certificate (https://bugzilla.mozilla.org/attachment.cgi?id=719876) If not, could you be so kind to send them? Thanks.

1_fingerprint F9:78:B1:00:04:D3:48:9C:64:03:A1:27:28:62:19:3B:9E:EB:73:17
2_readable_oid 1.3.6.1.4.1.13177.10.1.3.10
3_issuer
MIGNMQswCQYDVQQGEwJFUzEeMBwGA1UEChMVRmlybWFwcm9mZXNpb25hbCBTLkEuMRowGAYDVQQLExFTZWN1cml0eSBTZXJ2aWNlczESMBAGA1UEBRMJQTYyNjM0MDY4MS4wLAYDVQQDEyVBQyBGaXJtYXByb2Z 
lc2lvbmFsIC0gSU5GUkFFU1RSVUNUVVJB
4_serial AggQ6oA++CrG3w==

 2.- Is it enough to copy the test_ev_roots.txt file to the proper directory or is it needed to recompile something?

Thanks in advance.

Comment 27

[Kathleen Wilson]

Attachment: test_ev_roots.txt

Attached is the test_ev_roots.txt file that I got.

fingerprint should be the SHA1 of the root cert.
readable_oid should be the EV Policy OID that is in both the end-entity cert and the intermediate cert(s).
I also got very different results for the issuer and serial in base 64. 

You have to put the test_ev_roots.txt file in the same folder where the cert8.db file is (https://support.mozilla.org/en-US/kb/profiles-where-firefox-stores-user-data#os=mac&browser=fx20).

Then you have to install and run the Minefield browser. (https://wiki.mozilla.org/PSM:EV_Testing_Easy_Version#Test_version)

If you're still not getting EV treatment, then see:
https://wiki.mozilla.org/PSM:EV_Testing_Easy_Version#Not_Getting_EV_Treatment.3F

Comment 28

[Chema López]

(In reply to Kathleen Wilson from comment #27)
Thank you very much, Kathleen.

We will try with the one you provided.

I have another question: the OID in the intermediate cert is not the same of the end-entity cert.
 - intermediate CA has 1.3.6.1.4.1.13177.10.10.1 referring to the CA cert issuance policy
 - EV end-entity has 1.3.6.1.4.1.13177.10.1.3.10, referring to the EV certs issuance policy

> Created attachment 727367 [details]
> test_ev_roots.txt
> 
> Attached is the test_ev_roots.txt file that I got.
> 
> fingerprint should be the SHA1 of the root cert.
> readable_oid should be the EV Policy OID that is in both the end-entity cert
> and the intermediate cert(s).
> I also got very different results for the issuer and serial in base 64. 
> 
> You have to put the test_ev_roots.txt file in the same folder where the
> cert8.db file is
> (https://support.mozilla.org/en-US/kb/profiles-where-firefox-stores-user-
> data#os=mac&browser=fx20).
> 
> Then you have to install and run the Minefield browser.
> (https://wiki.mozilla.org/PSM:EV_Testing_Easy_Version#Test_version)
> 
> If you're still not getting EV treatment, then see:
> https://wiki.mozilla.org/PSM:
> EV_Testing_Easy_Version#Not_Getting_EV_Treatment.3F

Comment 29

[Kathleen Wilson]

(In reply to chemalogo from comment #28)
> I have another question: the OID in the intermediate cert is not the same of
> the end-entity cert.
>  - intermediate CA has 1.3.6.1.4.1.13177.10.10.1 referring to the CA cert
> issuance policy
>  - EV end-entity has 1.3.6.1.4.1.13177.10.1.3.10, referring to the EV certs
> issuance policy
> 

https://wiki.mozilla.org/CA:EV_Revocation_Checking#Requirements
"4. Intermediate certificates must implicitly or explicitly allow the EV policy OID listed in the server certificate."

The policy OID in the end-entity certificate has to match the policy OID that we will be associating with the root. The policy OID that is in the intermediate certificate(s) has to either be the anyPolicy identifier or has to match the policy OID that we will be associating with the root. (of course, the policy OIDs must also comply with the EV Guidelines)

Comment 30

[Chema López]

Kathleen. We are not able to reach the green URL box background. We get a blue background with a successful SSL certificate validation, but not the EV green background validation.

We now have learn how to generate the values in test_ev_roots.txt and have tested in a development environment with several combinations of OID values (intermediate CA and SSL Ev certitificate) and we can get the blur background but not the green one.

Is there any example of URL that works with a correct test_ev_roots.txt in Minefield but does not work with an incorrect one, that we can consult in order to understand what is going wrong?

Thanks in advance,

Comment 31

[Kathleen Wilson]

Maybe you can look at what another CA did:
https://bugzilla.mozilla.org/show_bug.cgi?id=759732#c26

The EV Policy OID in the end-entity cert and subCA cert must match the 2_readable_oid field in the test_ev_roots.txt file. (or the subCA cert can use the any policy oid).

Also look at 
https://wiki.mozilla.org/PSM:EV_Testing_Easy_Version#Not_Getting_EV_Treatment.3F

Comment 32

[Chema López]

(In reply to Kathleen Wilson from comment #31)
> Maybe you can look at what another CA did:
> https://bugzilla.mozilla.org/show_bug.cgi?id=759732#c26
> 

We've tried with this CA. We add the CA certs to Minefield so we get blue URL box background, then we add the test_ev_roots.txt and still get blue URL box background, instead of the expected green one. Is it necessary to compile anything or simply adding the right test_ev_roots.txt is sufficient?

If we can not achieve green URL with an "accepted" CA we won't be able to knoe when we are generating an EV compliant certificate.

> The EV Policy OID in the end-entity cert and subCA cert must match the
> 2_readable_oid field in the test_ev_roots.txt file. (or the subCA cert can
> use the any policy oid).
> 
> Also look at 
> https://wiki.mozilla.org/PSM:
> EV_Testing_Easy_Version#Not_Getting_EV_Treatment.3F

Comment 33

[Kathleen Wilson]

(In reply to chemalogo from comment #32)
> We've tried with this CA. We add the CA certs to Minefield so we get blue
> URL box background, then we add the test_ev_roots.txt and still get blue URL
> box background, instead of the expected green one. Is it necessary to
> compile anything or simply adding the right test_ev_roots.txt is sufficient?

No need to compile anything, just need to have the right test_ev_roots.txt file and make sure the EV rules are being followed...

When I test with https://viafirma.firmaprofesional.com/viafirma/ I see two problems right away...

First: The EV Policy OID is not consistent in the test file, the intermediate cert, and the end-entity cert.
2_readable_oid 1.3.6.1.4.1.13177.10.1.3.10
Intermediate: 1.3.6.1.4.1.13177.10.10.1
End-entity:      1.3.6.1.4.1.13177.10.1.3.1
 
https://wiki.mozilla.org/CA:EV_Revocation_Checking#Requirements
"3. The server certificate must contain exactly one EV policy extension (OID). The server certificate may contain one or more policy extensions, but it must not contain multiple EV policy extensions.
4. Intermediate certificates must implicitly or explicitly allow the EV policy OID listed in the server certificate."

Note that "implicitly" means that the intermediate cert can use the anyPolicy oid rather than the EV policy oid. But if an EV policy OID is specified, it must match the one that will be specified in Mozilla code (e.g. the one in your CP/CPS documentation) and the one that is in the end-entity cert -- they need to all match.


Second: There is no OCSP URI in the AIA of the end-entity cert.

https://wiki.mozilla.org/CA:EV_Revocation_Checking#Requirements
"5. Firefox 3 will test the server certificate for revocation status using the OCSP protocol.
- The server certificate must contain an Authority Information Access (AIA) extension that carries an OCSP URI using the HTTP protocol.
- Firefox must be able to complete an OCSP request and response transaction with the given OCSP server. When an OCSP server connection fails, Firefox treats the server certificate as invalid for EV. ...
- Firefox must be able to verify the received OCSP response. The response must confirm the server certificate is not revoked. ...
6. OCSP must also work for the intermediate certificates. A failed OCSP response will result in EV treatment not being given."

Comment 34

[Chema López]

Attachment: Minefiled does not show "green bar" even when we test with an accepted CA

Comment 35

[Chema López]

We are still working on it. First of all, the new test URL is:
https://servicios.firmaprofesional.com

There is still an inconsistency regarding OIDs, but we have tested with a new test-SubCA with consistent OIDs and the appropriate test_ev_roots.txt and still appeared the blue background at the URL bar instead of the green one. We made this test in both Linux and Windows environments.

We asked for a CA that had completed successfully the tests and received information about Swisscom (https://bugzilla.mozilla.org/show_bug.cgi?id=759732). In the attachment area you can find a screenshot (https://bugzilla.mozilla.org/attachment.cgi?id=759705) where you can see that we have the same problem with an accepted EV CA. test_ev_roots.txt and test URL are the ones provided by Swisscom, OID are consistent and proper environment variable is set (ENABLE_TEST_EV_ROOTS_FILE=1.) We have test this as well in both Linux and Windows environments, so the only reason we find is that there would be any issue with the Minefield version? We use the one at https://kuix.de/mozilla/browser-ca-ev-testing/ (in a folder named 20101130. are we using a version from year 2.010?)

Comment 36

[Kathleen Wilson]

Did you check the things listed here?
https://wiki.mozilla.org/PSM:EV_Testing_Easy_Version#Not_Getting_EV_Treatment.3F

The Minefield test version is indeed old, but it still works for testing EV-enablement. It's the one I use.

If you fix the EV policy OIDs in the cert hierarchy, I will run the test.

Comment 37

[Chema López]

Thanks, Kathleen.

We plan to reissue the Intermediate CA cert, adding the anyPolicy extension. So we plan to reissue it using the previous keypair since we generated it in notary presence.

Thanks again.

Comment 38

[Chema López]

Attachment: Last intermediate CA taking into accounts last comments

anyPolicy present

Comment 39

[Chema López]

Hi again!

We have issued, as said previously, a new Intermediate CA cert (https://bugzilla.mozilla.org/attachment.cgi?id=765837), and changed the test URL to:

https://publifirma.firmaprofesional.com.

Comment 40

[Kathleen Wilson]

Attachment: test_ev_roots.txt

Comment 41

[Kathleen Wilson]

Attachment: EV Testing Result

EV treatment successfully tested.

Comment 42

[Kathleen Wilson]

Attachment: Updated CA Information Document

Please see the items highlighted in yellow.
- Question about technical constraints on external subCA and RAs.
- Document handling of IDNs
- Re-verification for long-lived SSL certs

Comment 43

[Chema López]

(In reply to Kathleen Wilson from comment #42)

See answers inline

> Created attachment 766120 [details]
> Updated CA Information Document
> 
> Please see the items highlighted in yellow.
> - Question about technical constraints on external subCA and RAs.

We use a data model where RA operators belong to a RA, and a RA is allowed to issue a determined set of Certificate Policy. This allowance is a positive one, that is, when you create a new RA this RA can not issue any certificate at all and two RA administrators have to add one by one the CPs allowed to this new RA.


> - Document handling of IDNs

See new CP version including the proposed solution in Comment #7
(https://www.firmaprofesional.com/images/pdfs/FP_CP_Gen_Servidor_Web_SSL_6.2-EN.pdf)
"Proposed amendment:
3.4 USE OF INTERNATIONALIZED DOMAIN NAMES
The use of IDN is not allowed under this Certificate Policy. This prevents from the homographic spoofing attack.

The following sections of the CP will have to be re-numbered."

> - Re-verification for long-lived SSL certs

See new CP version including the proposed solution in Comment #7
(https://www.firmaprofesional.com/images/pdfs/FP_CP_Gen_Servidor_Web_SSL_6.2-EN.pdf)
"Proposed amendment:
4.3 LONG-LIFE INFORMATION VERIFICATION
The information included in SSL certificates older than three (3) years will be verified according to “4.1 CERTIFICATE ISSUANCE PROCESS”, “b)	Acceptance of the Application” subsection, point 1."

Comment 44

[Kathleen Wilson]

(In reply to chemalogo from comment #43)
> > - Question about technical constraints on external subCA and RAs.
> 
> We use a data model where RA operators belong to a RA, and a RA is allowed
> to issue a determined set of Certificate Policy. This allowance is a
> positive one, that is, when you create a new RA this RA can not issue any
> certificate at all and two RA administrators have to add one by one the CPs
> allowed to this new RA.


I'm not sure I understand. 

Are any external RAs allowed to issue SSL certificates?
Is there software running at Firmaprofesional that limits the types of certs the RAs can issue? 
Is it based on a Certificate Policy setting that can only be changed by Firmaprofesional?

Comment 45

[Chema López]

(In reply to Kathleen Wilson from comment #44)
> (In reply to chemalogo from comment #43)
> > > - Question about technical constraints on external subCA and RAs.
> > 
> > We use a data model where RA operators belong to a RA, and a RA is allowed
> > to issue a determined set of Certificate Policy. This allowance is a
> > positive one, that is, when you create a new RA this RA can not issue any
> > certificate at all and two RA administrators have to add one by one the CPs
> > allowed to this new RA.
> 
> 
> I'm not sure I understand. 
> 
> Are any external RAs allowed to issue SSL certificates?
"The Management of applications and issuances of 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."

Where we say we mean "Domain Name Registrar", using CA/Browser Forum Baseline Requirements for the 
Issuance and Management of Publicly-Trusted Certificates, v.1.1.5 terminology.

Nowadays, however, only Firmaprofesional itself issues SSL certificates. That is, there is no Domain Name Registrar authoried to issue certificates. 

> Is there software running at Firmaprofesional that limits the types of certs
> the RAs can issue?
Yes, a RA software that only shows to the RA Operator the Policies this RA is allowed to issue.

> Is it based on a Certificate Policy setting that can only be changed by
> Firmaprofesional?
Yes! only Firmaprofesional's RA Administrators can change which Policies a RA can issue.

Comment 46

[Kathleen Wilson]

Attachment: Completed CA Information Document

Comment 47

[Kathleen Wilson]

I'll try to start the discussion soon.

Comment 48

[Kathleen Wilson]

I am now opening the first public discussion period for this request from Firmaprofesional to enable EV treatment for the “Autoridad de Certificacion Firmaprofesional CIF A62634068” root certificate that was included in NSS via Bugzilla #521439.

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

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

The discussion thread is called “Firmaprofesional Request to Enable EV Treatment”.

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

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

Comment 49

[Kathleen Wilson]

The public comment period for this request is now over. 

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

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

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

To summarize, this assessment is for the request to enable EV treatment for the “Autoridad de Certificacion Firmaprofesional CIF A62634068” root certificate that was included in NSS via bug #521439.

Section 4 [Technical]. I am not aware of instances where Firmaprofesional has knowingly issued certificates for fraudulent use. If anyone knows of any such issues or instances, please note them in this bug.

Section 6 [Relevance and Policy]. Firmaprofesional appears to provide a service relevant to Mozilla users. It is 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.

Policies are documented in the documents published on their website and listed in the entry on the pending applications list; the main documents of interest are the CPS and CP, which have been translated into English.

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

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

* Email: 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)

* SSL: Firmaprofesional does not delegate issuance of SSL certificates to third parties. According to CPS Section 3.2, Firmaprofesional verifies the organization requesting the certificate. According to SSL CP section 4.1, Firmaprofesional performs a whois query to confirm that the certificate subscriber owns the domain name to be included in the certificate.

* Code: According to the CPS and the Code Signing CP, Firmaprofesional verifies the identity of the certificate subscriber and the authority of the certificate subscriber to request the certificate on behalf of the organization.

Section 18 [Certificate 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.


* EV Policy OID: 1.3.6.1.4.1.13177.10.1.3.10

* CRL 
http://crl.firmaprofesional.com/fproot.crl
http://crl.firmaprofesional.com/firmaprofesional1.crl  
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.

Sections 11-14 [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 

Based on this assessment I intend to approve this request to enable EV treatment for the “Autoridad de Certificacion Firmaprofesional CIF A62634068” root certificate

Comment 50

[Kathleen Wilson]

As per the summary in Comment #49, and on behalf of Mozilla I approve this request from Firmaprofesional to enable EV treatment for the following root certificate.

** “Autoridad de Certificacion Firmaprofesional CIF A62634068” (websites, email, code signing), enable EV.

I will file the PSM bug for the approved change.

Comment 51

[Kathleen Wilson]

I have filed bug #935674 against PSM for the actual change.