ANF Root Inclusion Request

[Kathleen Wilson]

ANF Autoridad de Certificaci�n has applied to include the �ANF Server
CA� and �ANF Global Root CA� root certificates, turn on the websites
trust bit for both, and enable EV treatment for the �ANF Global Root CA�
certificate.

ANF Autoridad de Certificaci�n (ANF AC) is a private Certification
Authority, recognized and accredited by the Spanish Government as a
Certificate Services Provider (CSP). ANF AC has accredited more than
1000 Registry Authorities throughout Spain to issue qualified user
identity certificates. ANF CA also issues certificates for SSL with and
without Extended Validation.

The request is documented in the following bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=555156

And in the pending certificates list:
http://www.mozilla.org/en-US/about/governance/policies/security-group/certs/pending/

Summary of Information Gathered and Verified:
https://bugzilla.mozilla.org/attachment.cgi?id=8416718

Noteworthy points:

* The primary documents are the CPS for SSL CP, which are provided in
Spanish and English.

Document repository (ES):
http://www.anf.es/es/politicas/psc-acreditado/documentos-publicados

Document repository (EN): http://www.anf.es/en/
CPS: https://anf.es/es/pdf/DPC_ANF_AC_EN.pdf
SSL CP: https://anf.es/es/pdf/PC_SSL_Sede_EV_EN.pdf

* CA Hierarchy: Both roots have internally-operated subordinate CAs
which sign end-entity certificates for individuals and organization.

* This request is to enable the websites trust bit for both roots, and
to enable EV treatment for the �ANF Global Root CA� certificate.

** CPS section 1.3.1.4, Issuance Report Managers: These are staff
attached to ANF AC's Legal Department, responsible for checking the
documentation provided by the Registration Authorities. They determine
whether the documents are sufficient or not, they check the reliability
of the information, and, if they consider it necessary, order further
investigations.

** SSL CP section 4.2.1 provides a description of the process for
performing identification and authentication functions for verifying the
certificate subscriber�s identity, organization, and authority to
request the certificate on behalf of the organization.

** SSL CP section 4.2.2: The Issuance Reports Manager (IRM) assumes the
final response assumes the ultimate responsibility to verify the
information contained in the Application Form, and to assess the
adequacy of the documents provided and of the application, in accordance
with the provisions of this Certification Policy.

** SSL CP section 4.2.2.1, SSL Certificates: The IRM shall check the
documentation by consulting the whois database, verifying that the
domain is registered, by consulting valid registrars. A copy of the
whois query is attached to the validation act.

** SSL CP section 4.2.2.3, SSL EV y and Electronic Office EV
Certificates: In the process of verification of the information and
documentation received, the following means may be used:
- Consultation to official public records in which the entity must be
registered in order to check availability, effect of charges and other
legal issues such as activity and date of establishment.
- Official Journals of national or regional public bodies belonging to
public bodies and enterprises.
- With regard to Internet addresses and domains, ANF AC consult
recorders attached only by ICANN / IANA domain names and addresses
associated with the certificate. In this query, it is verified verify:
-- That the holder (registrant) agrees with the subscriber.
-- People and contact information associated with that domain registration.
- One of the contact persons listed in the whois query shall be reached
in order to verify compliance of the certificate issuance request
associated with that domain.

* EV Policy OID: 1.3.6.1.4.1.18332.55.1.1.2.22

* Root Certs:
http://www.anf.es/es/certificates_download/ANF_Server_CA.cer
http://www.anf.es/es/certificates_download/ANF_Global_Root_CA_SHA256.cer

* Test Websites:
https://anf.kerberosns.com/en/
https://kerberosns.com/cloud

* OCSP
http://ocsp.anf.es/spain/AV

* Audit: Annual audits are performed by DNB (http://www.dnbcons.com)
according to the WebTrust criteria.
WebTrust CA: https://cert.webtrust.org/SealFile?seal=1625&file=pdf
WebTrust EV: https://cert.webtrust.org/SealFile?seal=1626&file=pdf
WebTrust BR: https://bugzilla.mozilla.org/attachment.cgi?id=8401262

* Potentially Problematic Practices � None Noted
(http://wiki.mozilla.org/CA:Problematic_Practices)

This begins the discussion of the request from ANF Autoridad de
Certificaci�n to include the �ANF Server CA� and �ANF Global Root CA�
root certificates, turn on the websites trust bit for both, and enable
EV treatment for the �ANF Global Root CA� 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]

Le jeudi 19 juin 2014 20:28:28 UTC+2, Kathleen Wilson a écrit :
> ANF Autoridad de Certificaci�n has applied to include the �ANF Server
> CA� and �ANF Global Root CA� root certificates, turn on the websites
> trust bit for both, and enable EV treatment for the �ANF Global Root CA�
> certificate.

[...]

Under "ANF Global Root CA":

https://kerberosns.com/cloud
EV certificate is not compliant with EV Guidelines:
- missing mandatory serialNumber in subjectDN (see section 9.2.6)
- are you sure that "JORGE CABRERA CLARISSO" is the legal name of the entity as recorded by the the incorporating or registration agency? Other attributes in the certificate imply that this is in fact a personal name (givenName=JORGE, surname=CABRERA CLARISSO)

OCSP service behind "http://ocsp.anf.es/spain/AV" when validating the subscriber certificate sends useless certificates in the responses:
- the issuer of the dedicated OCSP responder (the requester already has it, since it is necessary to build the request)
- the root certificate "ANF Global Root CA" (seriously?)
That's 4.8k wasted on the wire for each response, approx. 70%.


Under "ANF Server CA":

https://anf.kerberosns.com/en/
Nothing particular on the server certificate

OCSP service behind "http://ocsp.anf.es/spain/AV" when validating the subscriber certificate has the same problems as mentioned (useless CA certificates in the response), plus:
- OCSP responder certificate is a 1024 bits one
- OCSP responder certificate doesn't contain the OCSPNoCheck extension
- OCSP responder certificate contains an empty CRLDP extension (forbidden by definition); remove it, and add the OCSPNoCheck extension

Issuing certificate "ANF SSL Sede CA1" has the following problems:
- the CRLDP is invalid; 3 URLS are concatenated, separated by a '\n' character), one of them seems to be improperly constructed (ldap://ldap.anf.es:389/cn=ANF_SSL_Sede_CA1.crl,ou=ANF_SSL_Sede_CA1,ou=ANF_Server_CA,dc=anf should probably be ldap://ldap.anf.es:389/cn=ANFServerCA_arl.crl,ou=ANF_Server_CA,dc=anf), while the 2 others point to a CRL whose scope is reduced to user certificates, thus not compatible with this CA certificate
- the SAN extension contains an invalid "dNSName=http://www.anf.es" entry (this is a URI, not a DNS Name)

OCSP service behind "http://www.anf.es/AC/RC/ocsp" when validating the issuing certificate has the same problems (useless CA certificates in the response), plus:
- OCSP responder certificate doesn't contain the OCSPNoCheck extension

Root certificate contains useless extensions:
- AIA:OCSP
- CRLDP (pointing to a CRL valid for user certificates only)

[anf.ac...@gmail.com]

El viernes, 20 de junio de 2014 17:07:05 UTC+2, Erwann Abalea escribió:

> Under "ANF Global Root CA":
>
> https://kerberosns.com/cloud
>
> EV certificate is not compliant with EV Guidelines:

[...]

Hello,

I'm Moises Amador, ANF's representative.

This is the account from which officially respond.

Erwann, thanks for taking the time to review our request.
We will carefully review the points you mention, and answer all soon.

[Erwann Abalea]

Bonjour Moises,

There's one additional point which doesn't affect Mozilla (for now), but currently affects Microsoft.
Your OCSP responders don't set the nextUpdate date (it's optional). This is valid, but it has a side-effect, Microsoft CAPI considers that such responses are obsolete, and fall back to CRL download.
If your CRLs are invalid, as it's the case when validating "ANF SSL Sede CA1" certificate, it becomes a security problem.

[anf.ac...@gmail.com]

We respond you point by point:

> Under "ANF Global Root CA":
>
> https://kerberosns.com/cloud
>
> EV certificate is not compliant with EV Guidelines:
>
> - missing mandatory serialNumber in subjectDN (see section 9.2.6)
>
> - are you sure that "JORGE CABRERA CLARISSO" is the legal name of the entity as recorded by the the incorporating or registration agency? Other attributes in the certificate imply that this is in fact a personal name (givenName=JORGE, surname=CABRERA CLARISSO)

We will revoke that certificate and we will issue a new name of an entity whose data/information are clearer than the first one.

> OCSP service behind "http://ocsp.anf.es/spain/AV" when validating the subscriber certificate sends useless certificates in the responses:
>
> - the issuer of the dedicated OCSP responder (the requester already has it, since it is necessary to build the request)
>
> - the root certificate "ANF Global Root CA" (seriously?)
>
> That's 4.8k wasted on the wire for each response, approx. 70%.

The reason to respond in that way is because it is possible to do OCSP queries from JAVA which you only need the certificate issuer, then it is advisable to include the entire chain. In addition, some OCSP users demand, for more security, to be included in the response chain OCSP.

> Under "ANF Server CA":
>
> https://anf.kerberosns.com/en/
>
> Nothing particular on the server certificate
>
> OCSP service behind "http://ocsp.anf.es/spain/AV" when validating the subscriber certificate has the same problems as mentioned (useless CA certificates in the response), plus:
>
> - OCSP responder certificate is a 1024 bits one
>
> - OCSP responder certificate doesn't contain the OCSPNoCheck extension
>
> - OCSP responder certificate contains an empty CRLDP extension (forbidden by definition); remove it, and add the OCSPNoCheck extension

We understand the problem is that the certificate should be 2048. We will issue new certificates according to your comments.

> Issuing certificate "ANF SSL Sede CA1" has the following problems:
>
> - the CRLDP is invalid; 3 URLS are concatenated, separated by a '\n' character), one of them seems to be improperly constructed (ldap://ldap.anf.es:389/cn=ANF_SSL_Sede_CA1.crl,ou=ANF_SSL_Sede_CA1,ou=ANF_Server_CA,dc=anf should probably be ldap://ldap.anf.es:389/cn=ANFServerCA_arl.crl,ou=ANF_Server_CA,dc=anf), while the 2 others point to a CRL whose scope is reduced to user certificates, thus not compatible with this CA certificate
>
> - the SAN extension contains an invalid "dNSName=http://www.anf.es" entry (this is a URI, not a DNS Name)
>

A new certificate will be issued considering your comments.

>
> OCSP service behind "http://www.anf.es/AC/RC/ocsp" when validating the issuing certificate has the same problems (useless CA certificates in the response), plus:
>
> - OCSP responder certificate doesn't contain the OCSPNoCheck extension

The same response as discussed above for certificates of OCSP, new OCSP certificates will be issued.

> Root certificate contains useless extensions:
>
> - AIA:OCSP
>
> - CRLDP (pointing to a CRL valid for user certificates only)

This was a recommendation from an important Korean software company, they require us to include the extensions to allow the interoperability with software from Ecuador and Panama. Including the extensions dont have to affect to the root certificate security.

[anf.ac...@gmail.com]

Regarding this last point, as is an optional field and also our OCSP responders do not consult CRLs, not the "nextUpdate date" field is included.
Regarding the comment to "ANF SSL Sede CA1" certificate as a solution to this was proposed in 30 june:

> > Issuing certificate "ANF SSL Sede CA1" has the following problems:
> >
> > - the CRLDP is invalid; 3 URLS are concatenated, separated by a '\n' character), one of them seems to be improperly constructed (ldap://ldap.anf.es:389/cn=ANF_SSL_Sede_CA1.crl,ou=ANF_SSL_Sede_CA1,ou=ANF_Server_CA,dc=anf should probably be ldap://ldap.anf.es:389/cn=ANFServerCA_arl.crl,ou=ANF_Server_CA,dc=anf), while the 2 others point to a CRL whose scope is reduced to user certificates, thus not compatible with this CA certificate
> >
> > - the SAN extension contains an invalid "dNSName=http://www.anf.es" entry (this is a URI, not a DNS Name)
> >

[Kathleen Wilson]

All,

Are there any other concerns regarding this root inclusion request from ANF?

If ANF resolves all of the concerns that Erwann listed below, then
should we allow this request to continue?
Or should we require a new audit?

Thanks,
Kathleen


On 6/20/14, 8:07 AM, Erwann Abalea wrote:
> Le jeudi 19 juin 2014 20:28:28 UTC+2, Kathleen Wilson a �crit :
>> ANF Autoridad de Certificaci�n has applied to include the �ANF Server
>> CA� and �ANF Global Root CA� root certificates, turn on the websites
>> trust bit for both, and enable EV treatment for the �ANF Global Root CA�

[Kathleen Wilson]

Thank you to those of you who have contributed to this discussion about
ANF's request to include the "ANF Server CA" and "ANF Global Root CA"

root certificates, turn on the websites trust bit for both, and enable
EV treatment for the "ANF Global Root CA" certificate.

To summarize this discussion, the following concerns were raised.

1) The SSL certificate in the test website was not compliant with EV
Guidelines, in particular it was missing the mandatory serialNumber in
subjectDN (see section 9.2.6)

2) In the certificate the SAN extension contained an invalid
"dNSName=http://www.anf.es" entry (this is a URI, not a DNS Name) �
The BRs require compliance with RFC 5280, and this is a violation. RFC
5280, Page 35: "When the subjectAltName extension contains a domain name
system label, the domain name MUST be stored in the dNSName (an
IA5String). The name MUST be in the "preferred name syntax", as
specified by Section 3.5 of [RFC 1034] and as modified by Section 2.1 of
[RFC1123].
Section 3.5 is unambiguous about the construction of what a domain is
(namely, ":" is never a valid character - only a-zA-Z are allowed as the
first character, and a-zA-Z0-9 (and hyphen, -) are allowed as the
remaining).

3) The CRLDP is improperly encoded - this is a violation of 4.2.1.13
(Page 45) of RFC5280. "If the DistributionPointName contains a general
name of type URI, the following semantics MUST be assumed: ... . When
the HTTP or FTP URI scheme is used, the URI MUST point to a single DER
encoded CRL as specified in RFC2585"
So it's invalid (not a valid URI, due to the embedded NULL), and even
the URIs included are invalid.

4) OCSP issues, including 1024-bit OCSP responder certificate, and OCSP
responder certificate doesn't contain the OCSPNoCheck extension.
The lack of an OCSP noCheck is a violation of BR section 13.2.5: "In the
latter case, the OCSP signing Certificate MUST contain an extension of
type id-pkix-ocsp-nocheck, as defined by RFC2560"


Based on the findings listed above, I believe the proper course of
action is for the ANF CA to fix these issues and be re-audited according to:
https://wiki.mozilla.org/CA:BaselineRequirements#Audit_Mistakes
After which, a second round of discussion will be needed.

Does anyone have any further comments about this request before I close
this discussion and track the action items in the bug?

Thanks,
Kathleen

[ad...@dnbcons.com]

Dear Mozilla Community,

This is an unofficial statement from the Auditor (DNBCONS) in order to clarify certain points discussed on this thread:

1)Is important to read promptly the *Scope* of our Audits, as you can see "ANF Server CA" hierarchy is not in the scope of none of the Audit Reports regarding this request/thread. Thus we cannot give an Audit opinion regarding to "ANF Server CA" and the stated concerns showed in this request/thread.

2)Additionally the WT EV Audit was "Point of Time". We reviewed the unique sample EV certificate issued in the Audit Dates and in our Auditor's opinion it was compliant and obviously it included the serialNumber as required by section 9.2.6 and it was issued to a legal entity (in Spain a physical person can act as a legal entity - Freelance Worker/" Empresario Autónomo") . However, the sample EV certificate included in this request/thread was not audited by us in the Audit Dates and it is different from the audited one.

We would like to remark that the Audit was conducted in accordance with standards for assurance engagements of WebTrust and we don't observe any mistake in our audit procedures in this particular engagement, we should remember that the projection of any conclusions based in our findings (in a Point of Time Audit), to future periods subsequent to the date of our report, is subject to the risk that there may be:

(1) changes made to the system or controls;
(2) changes in processing requirements;
(3) changes required because of the passage of time; or
(4) degree of compliance with the policies or procedures may alter the validity of such conclusions.

We appreciate the efforts of Mozilla Community to improve global CA security and please don't hesitate to contact us for further details.

[Erwann Abalea]

Bonjour,

Le jeudi 11 septembre 2014 11:08:42 UTC+2, ad...@dnbcons.com a écrit :
> Dear Mozilla Community,
>
> This is an unofficial statement from the Auditor (DNBCONS) in order to clarify certain points discussed on this thread:
>
> 1)Is important to read promptly the *Scope* of our Audits, as you can see "ANF Server CA" hierarchy is not in the scope of none of the Audit Reports regarding this request/thread. Thus we cannot give an Audit opinion regarding to "ANF Server CA" and the stated concerns showed in this request/thread.

That's a problem. This CA is referenced by the Spanish TSL for production of Qualified certificates, I guess it has been audited based on ETSI TS101456.

> 2)Additionally the WT EV Audit was "Point of Time". We reviewed the unique sample EV certificate issued in the Audit Dates and in our Auditor's opinion it was compliant and obviously it included the serialNumber as required by section 9.2.6 and it was issued to a legal entity (in Spain a physical person can act as a legal entity - Freelance Worker/" Empresario Autónomo").

A "Freelance worker" or "Empresario Autonomo" is fine, if it fits one of the categories defined by EV Guidelines (Private Organization, Business Entity, etc). If the entity designated by the certificate doesn't fit one of those 4 categories, then this entity isn't entitled to obtain an EV certificate.

The sample EV certificate presented here was for a "Private Organization", therefore my asking. It wasn't an identified non-compliance, merely a request for clarification.

[Kathleen Wilson]

On 9/11/14, 2:08 AM, ad...@dnbcons.com wrote:
> Dear Mozilla Community,
>
> This is an unofficial statement from the Auditor (DNBCONS) in order to clarify certain points discussed on this thread:
>

Thank you for bringing this to our attention.

From the BR audit statement that was provided:
https://bug555156.bugzilla.mozilla.org/attachment.cgi?id=8401262

"We have audited the performed Assertion by the ANF Autoridad de
Certificacion Management, (hereinafter, ANF AC) according its services
as Certification Authority for issuing SSL certificates (through the
�ANF High Assurance EV CA1� subordinate issued by �ANF Global Root CA�)
as of March 31st 2014."
....
"Our audit was conducted in accordance with standards for assurance
engagements established by the AICPA/CICA and, accordingly, included (1)
obtaining an understanding of ANF AC� SSL certificate life cycle
management practices and procedures, including its relevant controls
over the issuance, renewal and revocation of SSL certificates; (2)
evaluating the suitability of the design of the controls; and (3)
performing such other procedures as we considered necessary in
the circumstances."

So, apparently the audit did not include the �ANF Server CA� certificate
and hierarchy.

ANF, is there a reason why the "ANF Server CA" is not mentioned in the
audit statements?

Kathleen

[Kathleen Wilson]

On 6/19/14, 11:28 AM, Kathleen Wilson wrote:
> ANF Autoridad de Certificaci�n has applied to include the �ANF Server
> CA� and �ANF Global Root CA� root certificates, turn on the websites
> trust bit for both, and enable EV treatment for the �ANF Global Root CA�
> certificate.

I am now closing this discussion regarding ANF�s root inclusion request.

The following action items will be tracked in the bug.

ACTION ANF: State (in the bug) ANF�s plan for remediation of all of the
issues noted in the discussion.

ACTION ANF: Get re-audited according to
https://wiki.mozilla.org/CA:BaselineRequirements and to confirm that the
problems noted in the discussion have been resolved.

ACTION ANF: Provide new annual audit statements with audit scope that
includes all of the root certificates in the inclusion request.

After confirming completion of these action items, I will start a second
round of discussion about ANF�s root inclusion request.

Any further follow-up on this request should be added directly to the bug.

https://bugzilla.mozilla.org/show_bug.cgi?id=555156

Thanks,
Kathleen