925740 - Add "Autoridad Certificadora Raíz Nacional de Uruguay" Root Certificate to NSS

Status: RESOLVED WONTFIX

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

Comment 1

[Nicolás Piquerez]

Attachment: CAInformation.odt

Information for verification

Comment 2

[Nicolás Piquerez]

Attachment: Root CA certificate

Comment 3

[Nicolás Piquerez]

Attachment: Root CA crl

Comment 4

[Kathleen Wilson]

> The ACRN (Spanish acronym of National Root Certification Authority of Uruguay - Autoridad 
> Certificadora Raiz Nacional de Uruguay) is the root of the chain of trust of the Uruguayan 
> National PKI (PKI Uruguay). 
>
> Through the ACRN, AGESIC (a national government agency) enables technologically the operation 
> of the Accredited Certification Service Providers (PSCA for its acronym in Spanish) issuing 
> electronic certificates for their Certifying Authorities (ACPA - Spanish acronym for Certification
> Authority of the Accredited Provider). Thus, the ACPA become part of the trust chain of PKI Uruguay.
> The ACRN and all their subordinate CA (ACPA) will be under the control and regulations of the UCE. 
> The UCE (Spanish acronym of Electronic Certification Unit) was created by Article 12 of Law 
> No. 18,600 “Electronic Document and Electronic Signature” as a decentralized body of AGESIC in 
> order to regulate and control the ACRN and subordinate CA.
>
> The hierarchy of CAs will be of one level, with the ACPA being the subordinate CAs. It is not 
> allowed that a PSCA create a subordinate ACPA of another ACPA therefore the hierarchy will be of 
> a level. Currently they are crediting three PSCA: "Interior Ministry (Ministerio del Interior)",
> "Uruguayan mail (Correo Uruguayo)" and "Abitab".
>
> Each ACPA will be operated independently under the control and regulation of the UCE.
>


Based on the information that has been provided, I think ACRN is similar in function to SUSCERTE (bug #489240), because ACRN acts as a super CA and their CA policies don't apply to the subordinate CAs (including auditing). It looks like ACRN's policies don't specify things like SSL Verification Procedures for end-entity certificate issuance, and compliance with CA/Browser Forum's Baseline Requirements.

Therefore, I think the subordinate CAs should apply for inclusion themselves.

Comment 5

[Nicolás Piquerez]

Currently we are still developing policies for TLS certificates and code signing.
We have certification policies to certificate physical and legal person. How about if we try to validate the CA for the bit of S/MIME and then as the documentation is ready, attempt to enable the other bits.
The reason I started the process is because we want the CA to be approved as soon as possible after it is functionally for the final user (that happen when we accredit the first CA in this month) and thus move up the missing requirements ASAP.
I will update the information of the CA with the certification policies of physical and legal person which I attach.

Comment 6

[Nicolás Piquerez]

Attachment: cp_persona_fisica.pdf

Comment 7

[Nicolás Piquerez]

Attachment: Politica+de+Certificacion+-+Persona+Juridica+-+vfinal1.0.pdf

Comment 8

[ghdotta]

It is important to add that all the allowed certificate policies for end-entities (TLS Servers in particular), regardless of who operates the CA, are created and maintained by UCE, the regulatory office. Therefore, UCE and AGESIC have the complete control over the validation procedures. Subordinate CA can change the procedure lightly to suit their business, but special care is taken at UCE through CPS review and audits to ensure that those procedures comply with all the verification and security requirements of the current CP.
Bottom Line, even with the Subordinate CA being operated by third-parties, all the procedures are nevertheless defined by the Root and the regulatory unit.

Comment 9

[Kathleen Wilson]

Please see https://wiki.mozilla.org/CA:SubordinateCA_checklist

and

sections 8 through 14 of http://www.mozilla.org/projects/security/certs/policy/InclusionPolicy.html

Comment 10

[Nicolás Piquerez]

I understand that our subordinate CAs will be of type "Third-Party/Public" and as their will not be technically constrained, we have to provide you with the information of the subordinates CAs to be considered publicly disclosed.
The "Correo Uruguayo CA" is in its finals steps for start to operate, soon it will be realising the key ceremony. So as soon as its start to operate we will send you the info to continue with the process.

Comment 11

[Nicolás Piquerez]

While I understand that the situation does not change much, I inform you that we were accepted into the Microsoft Root Certificate Program and are making the necessary arrangements to enter the program from Apple and Adobe.

Comment 12

[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, and provide the necessary information in this bug.

Comment 13

[Aaron Wu]

There's no update from CA for more than 1.5 year. Closing this bug for now as Won't fix.
If CA ever provide further information, this bug will be re-opened.