438825 - Add CA Root certificate (Brazil's National PKI)

Status: RESOLVED WONTFIX

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

Description

[Ruy Ramos]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.12) Gecko/20080208 Mandriva/2.0.0.12-1.1mdv2008.0 (2008.0) Firefox/2.0.0.12
Build Identifier: 

The ITI (Instituto Nacional de Tecnologia da Informação), a Federal organism linked to the Presidency of the Republic of Brazil with the principal attribution of being the Root Certification Authority (CA-Root) and supervising too many Certification Authority (CA).

The ITI, between other attributions, is the Root Certification Authority (CA Root) of ICP Brasil (Infra-Estrutura de Chaves Públicas Brasileira) or Brazil's National PKI created by the law (Medida Provisória nº 2.200-2 / 2001).

As such is the first authority of the chain of certification, executioner of the Politics of Certificates and technical and operational standards approved by the Committee of ICP-Brasil.

The first chain ICP-Brasil was created from the certificate signed in 30 of November of 2001. The certificate is available in http://acraiz.icpbrasil.gov.br/CertificadoACRaiz.crt

The second chain created in 05 of June of 2008. The certificate is available in http://acraiz.icpbrasil.gov.br/ICP-Brasil.crt

The practice of certification shears ICP-Brasil follows international standards being the approved available politics in http://acraiz.icpbrasil.gov.br/resolucoes/Resolucao%2049.pdf

At the moment, we have 8 entities accredited like 1st level of the conformable ICP-Brasil links following. Each one of these certifying Authorities has been accredited by it of 2nd level that certificates give out for persons, enterprises and equipments (servers). Additional informations it is in http://www.iti.br/twiki/bin/view/Certificacao/EstruturaIcp .

I inform that all the informations referring to the ICP-Brasil are in Portuguese, since it is the official language in Brazil.

Microsoft will include our CA certs in the next update.  The first chain just included.


Reproducible: Always

Steps to Reproduce:
1.
2.
3.



The links available are:

- ITI www.iti.gov.br <http://www.iti.gov.br/>

- ICP-Brasil www.icpbrasil.gov.br <http://www.icpbrasil.org.br/>

- AC-raiz (CA Root) http://acraiz.iti.gov.br/twiki/bin/view/Certificacao/RepositoriodaACRaiz

Any new informations please contact by e-mail [e-mail] (Director) or [e-mail] (Coordinator) or [e-mail]

Comment 1

[Ruy Ramos]

Attachment: Certification Practice Statement of ICP-Brasil

Comment 2

[Frank Hecker]

Confirming this bug, and assigning it to myself for now.

Comment 3

[Leonardo José da Cunha Peixoto]

Hi Frank, I work in an brazilian government site, so I can confirm the severity of this bug. Because of the scary message it presents to the user, the use of FF has decreased from about 8% to about 5%, and is still dropping as users migrate from FF2 to FF3.
I can only imagine that it is also happening in other brazilian sites, because ICP Certificates are used in all secure brazilian government sites (and several financial too). As you can see, it has the potential to severely undermine the popularity of FF in Brazil, as it cripples FF´s hability to handle secure sites (form the user point of view).
I would immensely appreciate if you could increase the assigned severity of this bug, and release an update fixing the CA list ASAP.

Thank you,
Leonardo Peixoto - [e-mail]

Comment 4

[Frank Hecker]

Re-assigning this bug to Gerv Markham, who will start collecting data relating to the request.

Comment 5

[André Carezia]

Please note that ICP Brasil seems to be a little lazy regarding their own security. Firefox note today while trying to enter https://www.icpbrasil.gov.br/:

Secure Connection Failed
www.icpbrasil.gov.br uses an invalid security certificate.
The certificate expired on 07/26/2008 05:46 PM.
(Error code: sec_error_expired_certificate)

Comment 6

[Ruy Ramos]

(In reply to comment #5)
> Please note that ICP Brasil seems to be a little lazy regarding their own
> security. Firefox note today while trying to enter
> https://www.icpbrasil.gov.br/:
> 
> Secure Connection Failed
> www.icpbrasil.gov.br uses an invalid security certificate.
> The certificate expired on 07/26/2008 05:46 PM.
> (Error code: sec_error_expired_certificate)
> 

I thank the observation. I inform that the above-mentioned site contains institutional informations on the ICP-Brasil. The fact, though relevant, it does not wrap the principal repositories of the ICP-Brasil. The services are totally different, including maintained by different teams.

Comment 7

[André Fillipe O. Silva]

I received the following e-mail from Viviane R. L. Bertol, who seems to work for a related entity, the National Institute of Information Technology:

> A auditoria da AC Raiz  não é realizada por uma empresa 
> de auditoria independente, mas por uma equipe designada 
> pelo Comitê-Gestor da ICP-Brasil, conforme item 3.1 do 
> DOC-ICP-08 (disponível em 
> http://www.iti.gov.br/twiki/bin/view/Certificacao/DocIcp).
> Os relatórios são sigilosos.  
>
> -- 
> Atenciosamente
> Viviane Bertol
> Coordenadora-Geral de Normalização e Pesquisa
> Instituto Nacional de Tecnologia da Informação / PR

"Auditing of the Root CA is not performed by an independent organization, but by a team designated by the ICP-Brasil Management Committee, as stated in item 3.1 of DOC-ICP-08 (available at http://www.iti.gov.br/twiki/bin/view/Certificacao/DocIcp). The audit reports are confidential."

Could any of this hinder the process being discussed? If my interpretation of the Mozilla CA Certificate Policy is correct, the team she speaks of *could be* a "competent party", since the Management Committee is indeed a (the!) relevant government agency. What about the secrecy of the reports, though?

I further inquired her if the auditing guidelines follow any of the documents listed in item 9 of the Mozilla policy (or even others). I'm still waiting for an answer.

Finally, I'm CC-ing myself and offering any help within my limits to resolve this issue.

Comment 8

[Ruy Ramos]

Firstly, there is need of explaining some topics. The ICP-Brasil presents a conformable hierarchy like illustrated in the figure 1 (attached).

According to observed in the figure (1), it is the Committee who determines the auditing of the Root Authority, which can be done by extern independent audit company or commission formed by auditors of other agencies of inspection of the federal government. There are two agencies that audit in the Institute: TCU – Court of Accounts of the Union (http: // www.tcu.gov.br) and CGU – General-Control of the Union (http: // www.cgu.gov.br/).


The standards used like reference for processes of auditing are them RFC 2527, BS7799 and NBR17799. The proceedings of auditing follow requisites of the American Institute of Certified Public Accountants (AICPA) and Information Systems Audit and Control Association (ISACA).

The document ICP DOC-ICP-08 v.2.0 defines the practices of auditing adopted (http://www.iti.gov.br/twiki/pub/Certificacao/DocIcp/DOC-ICP-08_-_v_2.0.pdf )

The ITI also is responsible for the process of inspection of the Authorities subordinated according to document ( http://www.iti.gov.br/twiki/pub/Certificacao/DocIcp/DOC-ICP-09_-_v_2.0.pdf )

All the documents used like reference CPS (Certification Practice Statement), CP (Certify Policy), SP (Security Policy) between others they are available in http://www.iti.gov.br/twiki/bin/view/Certificacao/DocIcp

And so, the CA subordinate of 1st level are audited by the ITI itself.
The CA subordinate of 2nd level are audited by the ITI and independent auditing. The independent auditing accredited by the ITI previously..
The RA also are audited by independent auditing accredited by the ITI.

The independent accredited auditing is in http://www.iti.gov.br/twiki/bin/view/Certificacao/AuditoriaIndependente

The accredited independent auditor follow the requisites of auditing predicted in the Resolution 44 of ICP-Brasil available in http://www.iti.gov.br/twiki/pub/Certificacao/AuditoriaIndependente/RESOLU__O_44_DE_18_04_2006II.pdf <http://www.iti.gov.br/twiki/pub/Certificacao/AuditoriaIndependente/RESOLU__O_44_DE_18_04_2006II.pdf>

Comment 9

[Ruy Ramos]

Attachment: hierarchy of ICP Brasil (figure 1)

Comment 10

[Frank Hecker]

Reassigning to Kathleen Wilson to do information gathering.

Comment 11

[Kathleen Wilson]

Attachment: Initial Information Gathering Document

I have been asked to do the information gathering and verification for this request as per http://wiki.mozilla.org/CA:Information_checklist.  The attached document provides a summary of the information that has been gathered and verified so far. I have the following questions and request for further information. Please provide the information in English.

1) Is there a statement in the CP (or other relevant document) that specifies the frequency of update for the CRLs for the end-entity certificates chaining up to this root? Would you please translate the relevant text into English?

2) Which Trust Bits do you want enabled for these roots?  Just Website?  Or email and code signing?

3) I see the certificate hierarchy diagrams, but I need further explanation as follows:

a) Internally Operated Subordinate CAs: List or description of subordinate CAs operated by the CA organization associated with the root CA. (For example, this might include subordinate CAs created to issue different classes or types of end entity certificates: Class 1 vs. class 2 certificates, qualified vs. non-qualified certificates, SSL certificates vs. email certificates, and so on.)
For internally-operated subordinate CAs the key is to confirm that their operation is addressed by the relevant CPS, and that any audit covers them as well as the root.

b) Externally Operated Subordinate CAs: For subordinate CAs operated by third parties, provide a general description of the types of third-party subordinates that exist, and what the general legal/technical arrangements are by which those subordinates are authorized, controlled, and audited.
(For example, contractual arrangements should require third-party subordinates to operate in accordance with some CPS/CP. Technical arrangements might include name constraints, not allowing them to create their own subordinates, etc.) 

c) List any other root CAs that have issued cross-signing certificates for this
root CA

4) I am supposed to review the CP/CPS to ensure that procedures are in place to do the following. Would you please translate the relevant text from the latest CP into English? We are looking for text that describes exactly what information is verified, and how the information is verified.
a) For SSL, verify that the domain referenced in the certificate is owned/controlled by the certificate subscriber. 
b) Verify the email account associated with the email address in the cert is owned by the subscriber, in addition to verification of subscriber’s legal identity.  (if applicable)
c) Verify identity information in code signing certificates is that of subscriber (if applicable)
d) Make sure it’s clear which checks are done for which context (cert usage)

5) For the v1 root, would you please provide a URL whose website cert chains up to the root? The website can either be a test site or an existing site.

6) I’m supposed to review the CP/CPS for potentially problematic practices,
as per http://wiki.mozilla.org/CA:Problematic_Practices. Since the CPS is not
in English, would you please comment as to whether any of these are relevant. 
If relevant, please provide further info:
a)Long-Lived Domain-Validated SSL certs 
b)Wildcard DV SSL certs
c)Issuing end entity certs directly from root rather than using an offline root and issuing certs through a subordinate CA 
d)Allowing external entities to operate subordinate CAs – in this case need to demonstrate that the external entities are required to follow the CPS and are audited as such.

7) Please see section 8, 9, and 10 of
http://www.mozilla.org/projects/security/certs/policy/
We need a publishable statement or letter (in English) from an auditor (who meets the policy requirements) that states that they have reviewed the practices as outlined in the CP/CPS for these roots, and that the CA does indeed follow these practices and meets the requirements of one of:
•     ETSI TS 101 456
•     ETSI TS 102 042
•     WebTrust Principles and Criteria for Certification Authorities

Note that this can be a letter/statement that is posted into bugzilla, and then I will need to do an independent verification of the authenticity of the document by contacting the auditor directly.

I have done my best to review the information provided so far, but I cannot find reference to ETSI or WebTrust.  We will need to find a way to bridge the gap in regards to the independent auditor and the type of audit. I would greatly appreciate suggestions here.

Thanks,
Kathleen

Comment 12

[Ruy Ramos]

"I have done my best to review the information provided so far, but I cannot
find reference to ETSI or WebTrust.  We will need to find a way to bridge the
gap in regards to the independent auditor and the type of audit. I would
greatly appreciate suggestions here."

The references of the ICP Brazil are RFC 2527 and RFC 3647. In the annexes C (of ts_102042v010304p.pdf)  and D (of ts_101456v010403p.pdf) it is possible to find the cross reference.

Other questions will be answered as so as possible.

Regards,
Ruy Ramos

Comment 13

[Ruy Ramos]

Attachment: ETSI TS 102 042 V1.3.4 (2007-12)

Comment 14

[Ruy Ramos]

Attachment: ETSI TS 101 456 V1.4.3 (2007-05)

Comment 15

[Kathleen Wilson]

Thank you for this information, but I will still need a statement from the auditor (could be in the form of a letter) saying that the CA has been audited and found to comply with RFC 2527/3647, ETSI TS 101 456 or ETSI TS 102 042. According to comment #7 the audit reports are confidential, so perhaps you could have the auditor provide a letter stating compliance.  We would also need to know if any issues were identified that impact compliance with the RFC/Policy.

I'm not sure yet how to resolve the issue of the need for an independent audit. Since your subordinate CAs go through an independent audit, I wonder if it would be possible to use one of those audits as an example. 

Thanks,
Kathleen

Comment 16

[Ruy Ramos]

(In reply to comment #11)
> Created an attachment (id=335646) [details]
> Initial Information Gathering Document
> 
> I have been asked to do the information gathering and verification for this
> request as per http://wiki.mozilla.org/CA:Information_checklist.  The attached
> document provides a summary of the information that has been gathered and
> verified so far. I have the following questions and request for further
> information. Please provide the information in English.
> 
> 1) Is there a statement in the CP (or other relevant document) that specifies
> the frequency of update for the CRLs for the end-entity certificates chaining
> up to this root? Would you please translate the relevant text into English?
> 

More information about CP:
http://www.iti.gov.br/twiki/pub/Certificacao/DocIcp/DOC-ICP-04_-_v_2.0.pdf

In page 27/27:
“Freqüência de emissão de LCR (horas)” = Frequency of update for CRL (hours)
6 hours (six hours) for all certificates!



> 2) Which Trust Bits do you want enabled for these roots?  Just Website?  Or
> email and code signing?

The CA Root of ICP-Brazil has a "self-signed" certificate; in other words, the entity signing the certificate is the same entity whose public key is in the certificate.
Trust bits enabled: website, email, code signing and timestamping.
See figure 3 (figure-3.pdf)

> 
> 3) I see the certificate hierarchy diagrams, but I need further explanation as
> follows:
> 
> a) Internally Operated Subordinate CAs: List or description of subordinate CAs
> operated by the CA organization associated with the root CA. (For example, this
> might include subordinate CAs created to issue different classes or types of
> end entity certificates: Class 1 vs. class 2 certificates, qualified vs.
> non-qualified certificates, SSL certificates vs. email certificates, and so
> on.)
> For internally-operated subordinate CAs the key is to confirm that their
> operation is addressed by the relevant CPS, and that any audit covers them as
> well as the root.


The ITI operates only the CA root (V0 and V1 chains) !
Another diagram in figure 3 (figure-3.pdf) can explain more information about this.



> 
> b) Externally Operated Subordinate CAs: For subordinate CAs operated by third
> parties, provide a general description of the types of third-party subordinates
> that exist, and what the general legal/technical arrangements are by which
> those subordinates are authorized, controlled, and audited.
> (For example, contractual arrangements should require third-party subordinates
> to operate in accordance with some CPS/CP. Technical arrangements might include
> name constraints, not allowing them to create their own subordinates, etc.) 
> 


According to the diagram of the figure 3, the 8 CAs (1º level) are externally operated by anothers organizations: CAIXA (www.caixa.gov.br), SERPRO (www.serpro.gov.br), SERASA (http://www.serasa.com.br/) , Certisign – a affiliate Verisign (http://www.certisign.com.br/), Secretaria da Receita Federal (http://www.receita.fazenda.gov.br/), Presidência da República (http://www.presidencia.gov.br/ingles/), Imprensa Oficial do Estado de São Paulo (http://www.imprensaoficial.com.br/PortalIO/Certificacao/Sobre/Apresentacao_7_0.aspx) , Poder Judiciário Brasileiro (http://www.acjus.gov.br/) .

The ITI authorizes, supervises and audits the operations of CAs (1º level) like table in figure 4 (figure-4.pdf)


> c) List any other root CAs that have issued cross-signing certificates for this
> root CA
> 

Not aplicable, because there is not cross-signing certification.



> 4) I am supposed to review the CP/CPS to ensure that procedures are in place to
> do the following. Would you please translate the relevant text from the latest
> CP into English? We are looking for text that describes exactly what
> information is verified, and how the information is verified.
> a) For SSL, verify that the domain referenced in the certificate is
> owned/controlled by the certificate subscriber.

not applicable.

 
> b) Verify the email account associated with the email address in the cert is
> owned by the subscriber, in addition to verification of subscriber’s legal
> identity.  (if applicable)

not applicable.

> c) Verify identity information in code signing certificates is that of
> subscriber (if applicable)

not applicable.

> d) Make sure it’s clear which checks are done for which context (cert usage)
> 

not applicable (?)

> 5) For the v1 root, would you please provide a URL whose website cert chains up
> to the root? The website can either be a test site or an existing site.

There is an existing site: https://wws.prontodente.com.br/login/logon.asp?USUARIO


> 
> 6) I’m supposed to review the CP/CPS for potentially problematic practices,
> as per http://wiki.mozilla.org/CA:Problematic_Practices. Since the CPS is not
> in English, would you please comment as to whether any of these are relevant. 
> If relevant, please provide further info:
> a)Long-Lived Domain-Validated SSL certs 

not applicable

> b)Wildcard DV SSL certs

not applicable

> c)Issuing end entity certs directly from root rather than using an offline root
> and issuing certs through a subordinate CA 

The CA root is off-line. All certificates are issuing through a subordinate CA (2º level). See figure 3.

> d)Allowing external entities to operate subordinate CAs – in this case need to
> demonstrate that the external entities are required to follow the CPS and are
> audited as such.
> 

The figure 4 presents as it is the process of auditing (english).
The completely document is here
http://www.iti.gov.br/twiki/pub/Certificacao/DocIcp/DOC-ICP-08_-_v_2.0.pdf

Each CA (1º and 2º level) has CP/CPS approved by the ITI.


> 7) Please see section 8, 9, and 10 of
> http://www.mozilla.org/projects/security/certs/policy/
> We need a publishable statement or letter (in English) from an auditor (who
> meets the policy requirements) that states that they have reviewed the
> practices as outlined in the CP/CPS for these roots, and that the CA does
> indeed follow these practices and meets the requirements of one of:
> •     ETSI TS 101 456
> •     ETSI TS 102 042
> •     WebTrust Principles and Criteria for Certification Authorities
> 
> Note that this can be a letter/statement that is posted into bugzilla, and then
> I will need to do an independent verification of the authenticity of the
> document by contacting the auditor directly.
> 
> I have done my best to review the information provided so far, but I cannot
> find reference to ETSI or WebTrust.  We will need to find a way to bridge the
> gap in regards to the independent auditor and the type of audit. I would
> greatly appreciate suggestions here.
> 
> Thanks,
> Kathleen

Regards
Ruy Ramos

Comment 17

[Ruy Ramos]

Attachment: Figure-3.pdf (Diagram of ICP-Brazil)

Comment 18

[Ruy Ramos]

Attachment: Figure-4.pdf (Process of Auditing)

Comment 19

[Ruy Ramos]

(In reply to comment #15)
> Thank you for this information, but I will still need a statement from the
> auditor (could be in the form of a letter) saying that the CA has been audited
> and found to comply with RFC 2527/3647, ETSI TS 101 456 or ETSI TS 102 042.
> According to comment #7 the audit reports are confidential, so perhaps you
> could have the auditor provide a letter stating compliance.  We would also need
> to know if any issues were identified that impact compliance with the
> RFC/Policy.
> 
> I'm not sure yet how to resolve the issue of the need for an independent audit.
> Since your subordinate CAs go through an independent audit, I wonder if it
> would be possible to use one of those audits as an example. 
> 
> Thanks,
> Kathleen


In fact the reports of auditing are confidential. The ITI publishes through the Official Diary of the Republic of Brazil a summary. This summary informs on the process of auditing and the agreement with the standards of the ICP-Brazil.

Since alternative will be able to do contact with one of the independent auditors and to ask eventual explanations of as the ICP-Brazil works with some standards (RFC 2527/3647).

http://www.iti.gov.br/twiki/bin/view/Certificacao/AuditoriaIndependente

Regards,
Ruy Ramos

Comment 20

[Ruy Ramos]

Dear Kathleen,

It is very important to say that the ICP-Brazil is not exclusively used by the government but the whole Brazilian society. The ICP-Brazil has the only (V0 and V1) chain operated by the ITI. There is the only one that has legal validity in Brazil.

Regards,
Ruy Ramos

Comment 21

[Ruy Ramos]

The ITI sponsored CERTFORUM -  Digital Certification Forum in Brazil.

http://www.certforum.com.br/eng/

Comment 22

[André Fillipe O. Silva]

(In reply to comment #21)
> The ITI sponsored CERTFORUM -  Digital Certification Forum in Brazil.
> 
> http://www.certforum.com.br/eng/

Can we keep it to the subject matter? ITI sponsoring a local event does not attest to the technical soundness of the procedures adopted by the ICP-Brasil Root CA.

Comment 23

[Ruy Ramos]

(In reply to comment #22)
> (In reply to comment #21)
> > The ITI sponsored CERTFORUM -  Digital Certification Forum in Brazil.
> > 
> > http://www.certforum.com.br/eng/
> 
> Can we keep it to the subject matter? ITI sponsoring a local event does not
> attest to the technical soundness of the procedures adopted by the ICP-Brasil
> Root CA.

Of course it is very important show to The Foundation Mozilla and others about this event. First, many companies support the initiative, which obviously demonstrates the credibility of the process managed by the ITI when the ICP-Brasil, otherwise besides, the topics discussed in the healthy event relevant for the digital certification. I wait that you are present to know a little more on all the work that it has been developed what attests to the seriousness, credibility and authenticity of the process of digital certification in Brazil.

Comment 24

[André Carezia]

(In reply to comment #19)
> In fact the reports of auditing are confidential. The ITI publishes through the

The "credibility of the process managed by the ITI" comes naturally with transparency, and confidential things do not contribute to this.

What can possibly justify the confidentiality of a CA Root auditing report? Security by obscurity? Remains of a past dictatorship?

Comment 25

[Kathleen Wilson]

Attachment: Updated Information Gathering Document

I have completed as much of the information gathering and verification as I can for this request at this point in time. The updated information gathering document reflects the current state.

Comment 26

[Kathleen Wilson]

I’m assigning this request back to Frank, so that decisions can be made in regards to how to proceed, such that the following two items are addressed:

1) A decision will have to be made in regards to how subordinate-CAs are handled; e.g. do we review the practices/audits of each of the subordinate CA’s?  Is that a scalable solution? What happens when another subordinate CA is added? Or is the answer that the minimum practices for subordinate CAs be documented in the ICP-Brasil CP/CPS such that the following criteria are met.
a) Section 7 of http://www.mozilla.org/projects/security/certs/policy/ - need text from the appropriate CP/CPS demonstrating that reasonable measures are taken to verify the domain name, email address, etc. for end-entity certificates. This needs to be part of the audit process.
b) Need to be able to specify when/how the organizational identity of the certificate subscriber is verified.
c) Need to be able to identify and address problematic practices as per http://wiki.mozilla.org/CA:Problematic_Practices

2) The audit for ICP-Brasil is for the root, and not for the subordinate CAs. This probably means that the audit reports for all of the subordinate CAs would need to be reviewed. Also note the issues with meeting sections 8, 9, and 10 of http://www.mozilla.org/projects/security/certs/policy/, in regards to the audit results being confidential and the audit being performed internally.

Thanks,
Kathleen

Comment 27

[Ruy Ramos]

(In reply to comment #26)
> I’m assigning this request back to Frank, so that decisions can be made in
> regards to how to proceed, such that the following two items are addressed:
> 
> 1) A decision will have to be made in regards to how subordinate-CAs are
> handled; e.g. do we review the practices/audits of each of the subordinate
> CA’s?  Is that a scalable solution? What happens when another subordinate CA is added? 

I think that a new information attached (Sample-OAB-CA.pdf) maybe show more informations about the process. In this case, a new CA (2º level) named OAB will be add to ICP-Brazil. So, ITI audit and authorizes working (see the file).


>Or is the answer that the minimum practices for subordinate CAs be
> documented in the ICP-Brasil CP/CPS such that the following criteria are met.


See information about subordinate CA (1º level):

AC-SERASA: http://www.certificadosdigitais.com.br/compras/Conteudo/Conteudo.aspx?Categoria=Repositorio
(all documents)
CPS: http://publicacao.certificadodigital.com.br/repositorio/dpc/declaracao-scd.pdf
CRL: http://publicacao.certificadodigital.com.br/repositorio/lcr/serasacdv1.crl
Certificate: http://publicacao.certificadodigital.com.br/suporte/serasacdv1.cer


AC-CERTISIGN: http://icp-brasil.certisign.com.br/repositorio/index.htm (all documents)
CPS: http://icp-brasil.certisign.com.br/repositorio/dpc/AC_Certisign/DPC_AC_Certisign_v3.0.pdf
CRL: http://icp-brasil.certisign.com.br/repositorio/lcr/ACCertiSign/LatestCRL.crl
Certificate: http://icp-brasil.certisign.com.br/repositorio/certificados/AC_Certisign_V3.cer

AC-CAIXA: http://icp.caixa.gov.br/asp/repositorio.asp (all documents) 
CPS: http://icp.caixa.gov.br/repositorio/DPCACCAIXA.pdf
CRL: http://icp.caixa.gov.br/repositorio/ACCAIXA1.crl
Certificate: http://icp.caixa.gov.br/repositorio/ACCAIXA.cer

AC-IMESP: http://www.imprensaoficial.com.br/PortalIO/Certificacao/Sobre/Repositorio_7_6.aspx (all documents) 
CPS: http://icp-brasil.certisign.com.br/repositorio/dpc/AC_IMESP/DPC_AC_IMESP_v3.0.pdf
CRL: http://icp-brasil.certisign.com.br/repositorio/lcr/ACImprensaOficialSP/LatestCRL.crl
Certificate: http://icp-brasil.certisign.com.br/repositorio/certificados/AC_IMESP.cer

AC-Jus: http://www.acjus.gov.br/repositorio  (all documents)
CPS: http://www.acjus.gov.br/acjus/dpcacjus.pdf
CRL: http://www.acjus.gov.br/acjus/acjusv1.crl
Certificate: http://www.acjus.gov.br/repositorio/certificados_lcr/cert_acjus.cer

AC-PR: http://www.planalto.gov.br/ACPR/ (all documents) 
CPS: http://www.planalto.gov.br/ACPR/pdf/DPCACPR.pdf
CP (A3): http://www.planalto.gov.br/ACPR/pdf/PCACPR_A3.pdf
CRL: http://ccd.serpro.gov.br/lcr/ACPRv1.crl
Certificate: http://acraiz.icpbrasil.gov.br/credenciadas/AC_PR_20092006.crt


AC- SRF : http://www.receita.fazenda.gov.br/acsrf/index.htm  (all documents)
CPS: http://www.receita.fazenda.gov.br/acsrf/DPCACSRFv2.1.pdf
CRL: http://www.receita.fazenda.gov.br/acsrf/acsrfv1.crl
Certificate: http://www.receita.fazenda.gov.br/acsrf/acsrfv1.crt

AC-SERPRO: http://www.serpro.gov.br/servicos/certificacao_digital/certificacaoCCDSerpro
CPS: https://ccd.serpro.gov.br/serproacf/docs/dpcserproacf.pdf
CRL: http://ccd.serpro.gov.br/lcr/acserpro.crl
Certificate: http://acraiz.icpbrasil.gov.br/credenciadas/ACSERPRO_2005.cer



> a) Section 7 of http://www.mozilla.org/projects/security/certs/policy/ - need
> text from the appropriate CP/CPS demonstrating that reasonable measures are
> taken to verify the domain name, email address, etc. for end-entity
> certificates. This needs to be part of the audit process.
> b) Need to be able to specify when/how the organizational identity of the
> certificate subscriber is verified.


In summary there are the next steps for emission of a certificate:
1)To access the site of the CA subordinate (AC-SERASA, AC-Caixa, AC-Certisign, etc) and to make a request for certificate
2)Filling out of informations that will be registered in the certificate. (to see examples in https://icp.caixa.gov.br/wwwRA/Input/individual_ind.asp?baseurl=&tipo=01  and https://www.certificadosdigitais.com.br/compras/Cadastro/Usuario.aspx?Url=%2fcompras%2fCarrinho%2fAdicionarProduto.aspx%3fSKU%3d0644&UrlBack=http%3a%2f%2fwww.certificadosdigitais.com.br%2fcompras%2fprodutos%2fvitrine.aspx%3fCategoria%3dProdutos_eCPF )
3)To appear on RA representative with the quoted documents and copies (physical presence)
4)Receiving on RA of the media (token or smartcard) and protocol of solicitation of certificate
5)To access the site of the CA to obtain certificate

You can see (last page) of “Sample-OAB-CA.pdf” more details about this process.

Comment 28

[Ruy Ramos]

Attachment: Sample-OAB-CA.pdf

Comment 29

[Ruy Ramos]

In this document (figure-5.pdf) there is the presidential nomination of the new Committee for ICP-Brasil. The members of the committee represent the brazilian civil society. A CV from the members is here  http://www.iti.gov.br/twiki/bin/view/Certificacao/ComiteGestor

Comment 30

[Ruy Ramos]

Attachment: Figure-5.pdf (Committee for ICP-Brasil)

Comment 31

[Kathleen Wilson]

Thank you for the additional info.

There is a discussion about handling subordinate CAs operated by third parties on Mozilla Dev Tech Crypto:
http://groups.google.com/group/mozilla.dev.tech.crypto/browse_thread/thread/265f94877056b2bb#

I suspect that we may have to take a two-pronged approach... First, review the CP/CPS/audits for the sub-CAs that currently exist (I would need help with this in regard to translations of particular text into English). Second, proceed with a more general solution which will apply to future sub-CAs, such as is being discussed in the dev-tech-crypto group.

More info to follow soon.

Thanks,
Kathleen

Comment 32

[Kathleen Wilson]

We have created the following wiki page to itemize the information that is needed when subordinate CAs are operated by third parties.

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

This page has been created based on discussions on dev-tech-crypto, and based on discussion and ongoing resolution of CA inclusion requests in which subordinate CAs are operated by third parties.

Comment 33

[Patricia T Oliveira Leite]

Attachment: Serasa´s information

Serasa´s information

Comment 34

[Kathleen Wilson]

Thank you for the information about the Serasa sub-CA. After reviewing the information, here are my questions:

1) Does the Serasa sub-CA issue any sub-CAs? If yes, please describe. What limits/controls the number of sub-CAs that they can issue?

2) What types of end-entity certificates are issued by the Serasa sub-CA? eg websites (SSL), email (S/MIME), code signing?

3) In regard to DV/OV SSL certificates. According to Google Translations of section 3.1 of
http://publicacao.certificadodigital.com.br/repositorio/dpc/declaracao-scd.pdf
it looks like the identity of individuals and the identity of organizations is confirmed.
Section 3.1.11.2 also seems to indicate that the authorization to use the domain must be presented.

a) This indicates to me that the SSL certs are OV (both the identity/organization and the domain name are verified). Correct?

b) How do they verify the ownership of the domain name? Do they trust the documentation that is provided? Or do they do an additional check via something like whois?

4) If they issue email certificates, they will need to have controls in their publicly available and audited documentation (eg CP/CPS) that describes at a high level how they confirm that the email address is owned by the certificate subscriber. As per section 7 of the Mozilla CA Policy.

5) We will need audit criteria and audit statements of compliance for the sub-CAs, as per sections 8, 9, and 10 of http://www.mozilla.org/projects/security/certs/policy/


In addition to reviewing sub-CAs, we will need to be able to find information in the ICP-Brasil CP/CPS that provides controls over the sub-CAs, including:

1) Requirements (technical and contractual) for subordinate CAs in regards to whether or not subordinate CAs are constrained to issue certificates only within certain domains, and whether or not subordinate CAs can create their own subordinates.

2) Requirements for sub-CAs to take reasonable measures to verify the ownership of the domain name and email address for end-entity certificates chaining up to the root, as per section 7 of
http://www.mozilla.org/projects/security/certs/policy/.
a) domain ownership/control
b)email address ownership/control 
c) digitally signing code objects -- entity submitting the certificate signing request is the same entity referenced in the certificate

I have not found this information in the ICP-Brasil CP/CPS, so it may need to be added. If it is already there, please point me to the sections/pages.

Thanks,
Kathleen

Comment 35

[Frank Hecker]

Re-assigning this bug to Kathleen Wilson, since she's the person actively working on it.

Comment 36

[Mauricio Balassiano]

Attachment: Certisign's Information

Comment 37

[Kathleen Wilson]

Thank you for the information on the Certisign sub-CA.

Does this sub-CA issue email certificates to people who are not employees of Certisign?  If so, is there text in their CP/CPS about verifying the ownership/control of the email address?

Does this sub-CA issue code-signing certificates to people who are not employees of Certisign?

In regards to DPC_AC_Certisign_Multipla_v3.0.pdf, 4.4.9.2. The CRL update frequency is 1 (one) hour.
Is their nextUpdate in their end-entity CRLs set to 1 hour? The requests that I’ve seen usually have nextUpdate for end-entity CRLs set to 24 to 48 hours to avoid issues with system load.

Comment 38

[Alexandre Carvalho]

Attachment: CA CAIXA's Information

Comment 39

[Kathleen Wilson]

Thank you for the information about the CAIXA sub-CA.

Does this sub-CA sign it's own sub-CAs? If yes, please provide further info.

Does this sub-CA issue email certs? Code-signing certs?

Comment 40

[Sylas Mendes]

Attachment: CA ACSERPRO Checklist Description

Comment 41

[Sylas Mendes]

Attachment: CA SERPROACF Checklist Description

Comment 42

[Ruy Ramos]

Attachment: Letter about independent auditing process

Letter about independent auditing process in CA Root of ICP-Brazil

Comment 43

[Alexandre Carvalho]

(In reply to comment #39)
> Thank you for the information about the CAIXA sub-CA.
> Does this sub-CA sign it's own sub-CAs? If yes, please provide further info.
> Does this sub-CA issue email certs? Code-signing certs?

Katleen,

The CA CAIXA signs the CA CAIXA PF (certificates for individuals) and the CA CAIXA PJ (certificates for legal representants of companies). These CA are part of Brazil´s official PKI (ICP-Brasil). The link http://www.iti.gov.br/twiki/pub/Certificacao/EstruturaIcp/AC_CEF_-_site.pdf contains a chart that represents the CA CAIXA and its sub-CAs.

The sub-CA CAIXA PF and the sub-CA CAIXA PJ doesn´t issue certificates for code-signing.

And about e-mail certificate, there is a list below with the use purposes of our certificates, extracted from CA CAIXA PF CPS. (https://icp.caixa.gov.br/repositorio/DPCACCAIXAPF.pdf) 

6.1.9. Use purposes of the key (as the "key usage" in X.509 v3) 
6.1.9.1 The private keys of the holders of certificates issued by the CA CAIXA PF can be used for digital signature, as specified in its corresponding CP. 
6.1.9.2 Certificates of signature are used in applications such as confirmation of identity on the web, email, online transactions, virtual private networks, cipher session keys and signature of electronic documents with verification of integrity of their information. 
6.1.9.3 The private key of the CA CAIXA PF is only used for the signature of certificates issued by it and its LCR.

Alexandre

Comment 44

[Sylas Mendes]

Comment on attachment 374495 [details] [diff] [review]
CA ACSERPRO Checklist Description

Submetida nova versão em função de problemas no arquivo.

Comment 45

[Sylas Mendes]

Comment on attachment 374496 [details] [diff] [review]
CA SERPROACF Checklist Description

Submetida nova versão em função de problemas no arquivo.

Comment 46

[Sylas Mendes]

Attachment: SERPROACF

Comment 47

[Sylas Mendes]

Attachment: ACSERPRO

Comment 48

[Kathleen Wilson]

Sylas,

Thank you for the information about Sepro.

Would you also please explain this hierarchy diagram in English:
http://www.iti.gov.br/twiki/pub/Certificacao/EstruturaIcp/AC_SERPRO_-_site.pdf
What is AC PRODERJ and AR SERPRO?

Thanks,
Kathleen

Comment 49

[Patricia T Oliveira Leite]

These are Serasa´s information related with Comment #34:
1)	Does the Serasa sub-CA issue any sub-CAs? If yes, please describe. What limits/controls the number of sub-CAs that they can issue?
[SERASA] Serasa CA direct under ICP-Brasil root (Serasa Autoridade Certificadora Principal) is allowed to issue sub-CAs. 
	There´s 3 sub-CAs: 2 belongs to Serasa itself<Serasa Autoridade Certificadora and Serasa Certificadora Digital> and 1 to Fenacor - Federação Nacional dos Corretores de Seguros Privados e de Resseguros, de Capitalização, de Previdência Privada e das Empresas Corretoras de Seguros e de Resseguros (AC Fenacor)

2) What types of end-entity certificates are issued by the Serasa sub-CA? eg websites (SSL), email (S/MIME), code signing?
[SERASA] Serasa Autoridade Certificadora: signing certificates to banks
Serasa Certificadora Digital: website, email, code signing, signing and encryption certificates.
AC FENACOR:signing certificates.


3) In regard to DV/OV SSL certificates. According to Google Translations of section 3.1 of http://publicacao.certificadodigital.com.br/repositorio/dpc/declaracao-scd.pdf
it looks like the identity of individuals and the identity of organizations is confirmed.
Section 3.1.11.2 also seems to indicate that the authorization to use the domain must be presented.

a) This indicates to me that the SSL certs are OV (both the identity/organization and the domain name are verified). Correct?
both the identity/organization and the domain name are verified, but we don´t refer it as OV.

b) How do they verify the ownership of the domain name? Do they trust the documentation that is provided? Or do they do an additional check via something like whois?
[SERASA] We check the ownership of the domain name at FAPESP, domain name Brazilian responsable (http://www.fapesp.org/)

4) If they issue email certificates, they will need to have controls in their publicly available and audited documentation (eg CP/CPS) that describes at a high level how they confirm that the email address is owned by the certificate subscriber. As per section 7 of the Mozilla CA Policy.
[SERASA] We don´t have this description on our CP/CPS

5) We will need audit criteria and audit statements of compliance for the sub-CAs, as per sections 8, 9, and 10 of http://www.mozilla.org/projects/security/certs/policy/

[SERASA] We don´t have any of this audit reports right now. We are analizing have one of them in 1 year.

In addition to reviewing sub-CAs, we will need to be able to find information in the ICP-Brasil CP/CPS that provides controls over the sub-CAs, including:

1) Requirements (technical and contractual) for subordinate CAs in regards to whether or not subordinate CAs are constrained to issue certificates only within certain domains, and whether or not subordinate CAs can create their own subordinates.
[SERASA] It´s described on item 3.1.11. of CPS.

2) Requirements for sub-CAs to take reasonable measures to verify the ownership of the domain name and email address for end-entity certificates chaining up to the root, as per section 7 of http://www.mozilla.org/projects/security/certs/policy/.
a) domain ownership/control
b)email address ownership/control
c) digitally signing code objects -- entity submitting the certificate signing request is the same entity referenced in the certificate
[SERASA] We don´t have this description on our CP/CPS

Comment 50

[Kathleen Wilson]

Thank you for the information about the Serasa sub-CA.

I have a question for ICP-Brazil, at the root level...

You have requested to enable all three of the trust bits for the Autoridade Certificadora Raiz Brasileira root: Websites (SSL/TLS), Email (S/MIME), and Code Signing.

However, in reviewing the information that I have received from the sub-CAs so far, I think it will be difficult to get approval to enable the Email and Code Signing trust bits. Please refer to section 7 of the Mozilla CA Policy (http://www.mozilla.org/projects/security/certs/policy/). I am finding that the sub-CAs tend not to meet the requirements in regards to verifying control of the email address, and having procedures for verifying the identity for code signing certs.

Would you like to proceed with only requesting enablement of the websites (SSL/TLS) trust bit?

The email and code signing trust bits could be requested later by submitting another bug once all of the sub-CAs that issue such certs have updated their CP/CPS documents to meet the requirements of the Mozilla CA Policy.

Comment 51

[Rafael Teigão]

Dear Kathleen,

Thanks for moving this bug forward. Regarding the requirements for verifying IDs for Code Signing and EMail certs, I'd like to share my experience (even if anecdotal) with the Serasa sub-CA on emitting such certs:

I work at the development department of the Justice Court of the State of Parana, in Brazil, and we are in the process of emitting around two thousand, smart-card stored, email certs and have recently gotten a code signing cert.

For the email certs, Serasa is mounting several RAs across the state and verifying a bunch of different documents for each user (even for the higher members of the judiciary), so I can attest that at least in our case they are taking it very seriously.

We only had one code signing certificate emitted to us, and it was really bureaucratic (as it should be...) Not even the director of the development department was able to move the process forward; the president of the Court himself had to present his papers (and the documents that prove that he had, in fact, such authority) in order to get a certificate emitted in my name.

Their written policy might not reflect such high requirements for Code Signing and Email certificate emission, but I'm sure that in reality, at least to what concerns the Serasa sub-CA, the verification is pretty rigorous.

Cheers,
Rafael Coninck Teigão.

Comment 52

[Ruy Ramos]

(In reply to comment #50)
> Thank you for the information about the Serasa sub-CA.
> 
> I have a question for ICP-Brazil, at the root level...
> 
> You have requested to enable all three of the trust bits for the Autoridade
> Certificadora Raiz Brasileira root: Websites (SSL/TLS), Email (S/MIME), and
> Code Signing.
> 
> However, in reviewing the information that I have received from the sub-CAs so
> far, I think it will be difficult to get approval to enable the Email and Code
> Signing trust bits. Please refer to section 7 of the Mozilla CA Policy
> (http://www.mozilla.org/projects/security/certs/policy/). I am finding that the
> sub-CAs tend not to meet the requirements in regards to verifying control of
> the email address, and having procedures for verifying the identity for code
> signing certs.
> 
> Would you like to proceed with only requesting enablement of the websites
> (SSL/TLS) trust bit?
> 
> The email and code signing trust bits could be requested later by submitting
> another bug once all of the sub-CAs that issue such certs have updated their
> CP/CPS documents to meet the requirements of the Mozilla CA Policy.

The issuance of certificates by ICP-Brazil follows rigorous proceedings of checking of the authenticity and identity (face-to-face validation). 

It is important to emphasize that the ICP Brazil does not oblige the information of the e-mail since it the question is non-compulsory extension (item 7.1.2.7 in http://publicacao.certificadodigital.com.br/repositorio/pc/politica-a1.pdf) . Meantime, the one who informs the e-mail, will have to attest and declare the existence over affirmation  that all information contained in the Certificate request is true and correct (“Termo de Titularidade”, see a sample in http://www.acfenacon.com.br/compre/arquivos/termo_de_titularidade_assinatura_e-cpf.htm or https://icp.caixa.gov.br/repositorio/CONTRATO_AC_JUS_A3.pdf ). The e-mail is used for notification on the emission of the certificate (see more in item 4.2.1 in http://icp-brasil.certisign.com.br/repositorio/dpc/AC_Certisign_RFB/DPC_AC_Certisign_RFB_v3.0.pdf or http://publicacao.certificadodigital.com.br/repositorio/dpc/declaracao-scd.pdf  )

And besides, the agreement is in CPS, item 4.3.1 and 4.3.2 , see http://publicacao.certificadodigital.com.br/repositorio/dpc/declaracao-scd.pdf 

In the particular case of  “code signing ” and “ e-mail signing ” do not be described specifically in current rules of the ICP Brazil, since such options are attended by the premise of which a certificate of ICP Brazil allows DIGITAL SIGNATURE, can be for use in code signing or e-mail signing, for example. You can see more in CP item 1.3.5.7 ( http://publicacao.certificadodigital.com.br/repositorio/pc/politica-a3.pdf )

It is also a part of the issuance of the certificate, the user to receive a PIN (PIN1) in RA and another PIN (PIN2) to be sent to e-mail. 

It is important to emphasize that any certificate of ICP Brazil is given out only from the physical presence after face-to-face validation with a complete documentary file (personal statement, government-issued identification document with photo and signature). See Requirements in   
http://icp.caixa.gov.br/asp/obter.asp 

All the CP/CPS uses the same numeration, so it can be found the items quoted in this answer in the differentes CA of ICP-Brasil. The references above it forms actions on the AC-Certisign, AC-SERASA. AC-JUS and AC-CAIXA authorities.

Comment 53

[Nelson Bolyard (seldom reads bugmail)]

12345678901234567890123456789012345678901234567890123456789012345678901234567890
(In reply to comment #52)
> It is important to emphasize that the ICP Brazil does not oblige the
> information of the e-mail since it the question is non-compulsory extension

I think this means that a person who applies for a certificate is not required
to provide an email address.  Is that a correct understanding?

> Meantime, the one who informs the e-mail, will have to attest and declare the
> existence over affirmation  that all information contained in the Certificate
> request is true and correct (“Termo de Titularidade”, 

I believe that, by itself, the act of "attest and declare [...] over affirmation" does not meet Mozilla's requirements for proving mailbox control.
However, ...

> The e-mail is used for notification on the emission of the certificate 
> It is also a part of the issuance of the certificate, the user to receive 
> a PIN (PIN1) in RA and another PIN (PIN2) to be sent to e-mail. 

That provision might satisfy the requirement of proving control of the mailbox, provided that it cannot be circumvented.  But since you do not require email 
addresses in all certs, how does a user with no email address get his PIN2?
Could a user whose cert has an email address also use that non-email technique to get his PIN2, and thereby fail to prove his control of the email address?

> In the particular case of "code signing" and "e-mail signing" do not be
> described specifically in current rules of the ICP Brazil, since such 
> options are attended by the premise of which a certificate of ICP Brazil 
> allows DIGITAL SIGNATURE, can be for use in code signing or e-mail signing, 
> for example. 

The mere fact that Brazil allows these certs to be used for those purposes 
is not (by itself) sufficient for Mozilla's policy purposes, I believe.

Comment 54

[Ruy Ramos]

Dear  Nelson Bolyard,

I hope to explain your questions.


(In reply to comment #53)
> 12345678901234567890123456789012345678901234567890123456789012345678901234567890
> (In reply to comment #52)
> > It is important to emphasize that the ICP Brazil does not oblige the
> > information of the e-mail since it the question is non-compulsory extension
> 
> I think this means that a person who applies for a certificate is not required
> to provide an email address.  Is that a correct understanding?
> 

Yes. You are correct !
It's possible to give out a certificate without the e-mail address but it's not a common (usually) practice.

The e-mail is registered in SUBJECT ALTERNATIVE NAME (“The subject alternative name extension allows identities to be bound  to the subject of the certificate. These identities may be included in addition to or in place of the identity in the subject field of the certificate. - 4.2.1.6. RFC 5280). 

The field SUBJECT contains official informations of the person or company (CN,OU,U,C) what are validated (face-to-face). If there is declaration of using the e-mail in the certificate, it will be setting field: EXTENDED KEY USAGE: “E-mail protection (1.3.6.1.5.5.7.3.4)” . There is cases (CP AC-SRF)  when e-mail is mandatory (see 7.1.2.7 http://publicacao.certificadodigital.com.br/repositorio/pc/politica-srf-a3.pdf )



> > Meantime, the one who informs the e-mail, will have to attest and declare the
> > existence over affirmation  that all information contained in the Certificate
> > request is true and correct (“Termo de Titularidade”, 
> 
> I believe that, by itself, the act of "attest and declare [...] over
> affirmation" does not meet Mozilla's requirements for proving mailbox control.
> However, ...

At moment the CA/RA (ICP Brazil) follows some practices of confirmation of the informations according (or similar) to the guide (Guidelines for the Issuance and Management of Extended Validation Certificates - pages 19-20, item (4)). 

We understand that a validation face-to-face (vetting documents submitted to CA) exceeds the requirements, so does meet “Mozilla CA Policy”.



> 
> > The e-mail is used for notification on the emission of the certificate 
> > It is also a part of the issuance of the certificate, the user to receive 
> > a PIN (PIN1) in RA and another PIN (PIN2) to be sent to e-mail. 
> 
> That provision might satisfy the requirement of proving control of the mailbox,
> provided that it cannot be circumvented.  But since you do not require email 
> addresses in all certs, how does a user with no email address get his PIN2?
> Could a user whose cert has an email address also use that non-email technique
> to get his PIN2, and thereby fail to prove his control of the email address?


The person receives the certificate in RA or received a PIN2 in RA, after documentation confirmed and validated.



> 
> > In the particular case of "code signing" and "e-mail signing" do not be
> > described specifically in current rules of the ICP Brazil, since such 
> > options are attended by the premise of which a certificate of ICP Brazil 
> > allows DIGITAL SIGNATURE, can be for use in code signing or e-mail signing, 
> > for example. 
> 
> The mere fact that Brazil allows these certs to be used for those purposes 
> is not (by itself) sufficient for Mozilla's policy purposes, I believe.


When I said “DIGITAL SIGNATURE” I refer to KEY_USAGE: digitalSignature,
nonRepudiation and keyEncipherment. I think the same purposes to Mozilla's policy. In the ICP-Brazil importance is attached to the primary uses of use of the certificate.


The model of the ICP-Brazil (Brazilian PKI) is based on the Germany PKI model. We understand that some pratices in Brazilian PKI exceeds the Mozilla requirements. At last all the standards of the ICP-Brazil are based on international standards. 

We believe that there is for certain eventual misunderstanding due to all our documentation is in Portuguese and eventually essential points had not been translated correctly.

Regards,
Ruy Ramos

Comment 55

[Ruy Ramos]

(In reply to comment #50)
> Thank you for the information about the Serasa sub-CA.
> 
> I have a question for ICP-Brazil, at the root level...
> 
> You have requested to enable all three of the trust bits for the Autoridade
> Certificadora Raiz Brasileira root: Websites (SSL/TLS), Email (S/MIME), and
> Code Signing.
> 
> However, in reviewing the information that I have received from the sub-CAs so
> far, I think it will be difficult to get approval to enable the Email and Code
> Signing trust bits. Please refer to section 7 of the Mozilla CA Policy
> (http://www.mozilla.org/projects/security/certs/policy/). I am finding that the
> sub-CAs tend not to meet the requirements in regards to verifying control of
> the email address, and having procedures for verifying the identity for code
> signing certs.
> 
> Would you like to proceed with only requesting enablement of the websites
> (SSL/TLS) trust bit?
> 

If is it possible. Please, go ahead.
With only this option enabled already we will be going to resolve great part of our problems. I believed.

regards, Ruy Ramos
 

> The email and code signing trust bits could be requested later by submitting
> another bug once all of the sub-CAs that issue such certs have updated their
> CP/CPS documents to meet the requirements of the Mozilla CA Policy.

Comment 56

[Kathleen Wilson]

Attachment: Updated Information Gathering Document

Comment 57

[Kathleen Wilson]

Attachment: SubCA-Review Document

Comment 58

[Kathleen Wilson]

I have attached the updated Information Gathering Document and the SubCA-review document.  Please review both of these documents for accuracy and completeness.  Within the document the items highlighted in yellow indicate where further clarification or information is needed. Note that I seem to be having difficulty accessing some of the urls today, so I've noted those in the document.

Comment 59

[Ruy Ramos]

Attachment: Updated Information Gathering Document - Ruy Ramos Comments

Kathleen,

Follow information to update the  "Updated Information Gathering Document" in a new document attached. 

regards
Ruy Ramos

Comment 60

[Ruy Ramos]

Attachment: SubCA-Review-Document-RuyRamos-comments

Follow information to update the  "SubCA-Review-Document" in a
new document attached.

Comment 61

[Kathleen Wilson]

Attachment: Updated Information Gathering Document

The https://internetbanking.caixa.gov.br/SIIBC/index.processa site works for me and the SSL cert chains up to the old root.

The https://wws.prontodente.com.br/login/logon.asp?USUARIO site works when I install the Serasa CA. 
However, the website certificate does not appear to chain up to the “Autoridade Certificadora Raiz Brasileira v1” root. Please provide a website whose SSL cert chains up to the “Autoridade Certificadora Raiz Brasileira v1” root.

Please verify that I have interpreted the CP and CPS documents correctly in regards to the requirements for the sub-CAs to have specific information in section 3.1.9, 3.1.10, and 3.1.11.

> Audit Report: not applicable - confidential (report is not published until 2010)
I understand that the audit report may be confidential for government organizations, but could someone from the audit committee provide a statement that an audit was provided over a specific time frame, what criteria was used (eg ETSI 101 456 and ETSI 102 042), and if any issues were found?

Comment 62

[Patricia T Oliveira Leite]

this is a response to comment #61:
the https://www.pragmapatrimonio.com.br/Sistema/Sistema/Login.aspx site works with a certificate issued by a CA up to the “Autoridade Certificadora Raiz Brasileira v1” root.

Comment 63

[Ruy Ramos]

> Please verify that I have interpreted the CP and CPS documents correctly in
> regards to the requirements for the sub-CAs to have specific information in
> section 3.1.9, 3.1.10, and 3.1.11.

ok. That's correct!


IMPORTANT: in ICP-Brazil we have 2 documents about CPS: 
- CPS of CA-root http://www.iti.gov.br/twiki/pub/Certificacao/DocIcp/DOC-ICP-01_-_versao_4.0_retificada_em_15-01-09.pdf    - CPS requiremnents to sub-CA
http://www.iti.gov.br/twiki/pub/Certificacao/DocIcp/DOC-ICP-05_-_versao_3.1_(REQUISITOS_MIN._PARA_AS_DPCs_DAS_ACs).pdf

For this information:
"CPS section 3.1.8, Identification of an organization: The identification of a CA by the CA Root is executed through the
procedures described in the document CRITERIA AND PROCEDURES FOR ACCREDITATION BODIES OF MEMBERS OF ICPBRASIL [6]. 
CPS Section 3.1.9, Authentication of the identity of an individual: Not applicable."

You see in "CPS requiremnents to sub-CA".


> 
> > Audit Report: not applicable - confidential (report is not published until 2010)
> I understand that the audit report may be confidential for government
> organizations, but could someone from the audit committee provide a statement
> that an audit was provided over a specific time frame, what criteria was used
> (eg ETSI 101 456 and ETSI 102 042), and if any issues were found?

We have 2 documents about this:
a) http://www.iti.gov.br/twiki/pub/Certificacao/Resolucoes/Resolucao_05.pdf

b) http://www.iti.gov.br/twiki/pub/Certificacao/Resolucoes/RESOLU__O_29_DE_29_01_2004.PDF

The references are for the CPS (CA-root), in none of these public documents you are going to find reference the quoted standards.
In the auditing to happen in 2010 we will have informations of equivalences to the quoted standards.

Comment 64

[Kathleen Wilson]

Re Comment #62, Thanks, but it appears that website was recently updated to a new cert that does not chain up to the Autoridade Certificadora Raiz Brasileira v1 root.

I still need a website whose SSL cert chains up to the Autoridade Certificadora Raiz Brasileira v1 root. Note that this can be a test website.

Comment 65

[Kathleen Wilson]

In regards to Comment #63:

> IMPORTANT: in ICP-Brazil we have 2 documents about CPS: 
> - CPS of CA-root
> - CPS requiremnents to sub-CA

Thanks for the clarification. That helps a lot.

> Audit
> The references are for the CPS (CA-root), in none of these public documents you
> are going to find reference the quoted standards.
> In the auditing to happen in 2010 we will have informations of equivalences to
> the quoted standards.

We’ll proceed as per the queue for public discussion
https://wiki.mozilla.org/CA:Schedule#Queue_for_Public_Discussion
This will allow us to proceed through the approval process. However, it is likely that the actual inclusion will be postponed until an audit that meets the requirements of the Mozilla CA Certificate Policy has been provided.

Comment 66

[Kathleen Wilson]

> Complete CA Hierarchy: 
>http://www.iti.gov.br/twiki/pub/Certificacao/EstruturaIcp/Estrutura_completa.pdf

Just to make sure I am interpreting the diagram correctly... Do the blue boxes indicate the types of end-entity certs that are issued, rather than sub-CAs?

> Sub-CAs
For the following sub-CAs please indicate which of the potentially problematic practices (http://wiki.mozilla.org/CA:Problematic_Practices) are applicable, and provide further information when applicable. 
1) Secretaria da Receita Federal  
2) Presidência da República 
3) Imprensa Oficial do Estado de São Paulo 
4) Poder Judiciário Brasileiro

For the Secretaria da Receita Federal sub-CA, why does the CPS say:
--
3.1.11 Autenticação da Identidade de um equipamento ou aplicação
Não se aplica.
--
What types of certs are issued under this sub-CA? How are the validation processes of the externally-operated sub-CAs under this sub-CA documented/controlled/audited?

Comment 67

[Ruy Ramos]

(In reply to comment #66)
> > Complete CA Hierarchy: 
> >http://www.iti.gov.br/twiki/pub/Certificacao/EstruturaIcp/Estrutura_completa.pdf
> 
> Just to make sure I am interpreting the diagram correctly... Do the blue boxes
> indicate the types of end-entity certs that are issued, rather than sub-CAs?

The blue boxes indicates the RA (registry authority) linked with sub-CAs (2º level)

> 
> > Sub-CAs
> For the following sub-CAs please indicate which of the potentially problematic
> practices (http://wiki.mozilla.org/CA:Problematic_Practices) are applicable,
> and provide further information when applicable. 

> 1) Secretaria da Receita Federal  

* "Allowing external entities to operate unconstrained subordinate CAs"
AC-SRF (Secretaria Receita Federal) only issues certs to sub-CA (2º level). 
AC-SRF is an authority of standards and politics. The end-user certs are issued by external entities that operate sub-CAs (2º level):AC-Serpro-RFB, AC-Certisign-RFB, AC-Serasa-RFB, AC-Imprensa-Oficial-SP-RFB, AC-Prodemge-RFB, AC-Sincor-RFB, AC-Notarial-RFB, AC-BR-RFB.

Note: "Secretaria da Receita Federal (SRF)" = "Receita Federal do Brasil (RFB)"  

> 2) Presidência da República 

Not applicable

> 3) Imprensa Oficial do Estado de São Paulo 

Not applicable

> 4) Poder Judiciário Brasileiro

* "Allowing external entities to operate unconstrained subordinate CAs"
AC-Jus (Poder Judiciário Brasileiro) only issues certs to sub-CA (2º level). 
AC-Jus is an authority of standards and politics. The end-user certs are issued by external entities that operate sub-CAs (2º level): AC-Serpro-Jus, AC-Certisign-Jus, AC-Serasa-Jus, AC-Caixa-Jus.



> 
> For the Secretaria da Receita Federal sub-CA, why does the CPS say:
> --
> 3.1.11 Autenticação da Identidade de um equipamento ou aplicação
> Não se aplica.
> --
> What types of certs are issued under this sub-CA? 

Only issues certs to sub-CA (2º level)
"2.1.1 Obrigações da AC-RFB:
g) Emitir, expedir e distribuir os certificados das AC de nível imediatamente subseqüente ao seu;

g) To issue, to dispatch and to distribute the certificates of the CA of level immediately subsequently (sub-CA 2º level);"

See more in CPS of AC-SRF 


How are the validation
> processes of the externally-operated sub-CAs under this sub-CA
> documented/controlled/audited?

sub-CAs by AC-SRF ( AC-Serpro-RFB, AC-Certisign-RFB, AC-Serasa-RFB, AC-Imprensa-Oficial-SP-RFB, AC-Prodemge-RFB, AC-Sincor-RFB, AC-Notarial-RFB, AC-BR-RFB) are auditing by AC-SRF follow CPS/CP (see more in Comment #8 )

For sample, you can see 3.1.11 in CPS of AC-Serasa-RFB: http://publicacao.certificadodigital.com.br/repositorio/dpc/declaracao-rfb.pdf

The summary report auditing (sample) are in http://www.iti.gov.br/twiki/bin/view/OLD/Main/RelatorioAuditoriasSrf

The summary report inspection and independent auditing (managed by ITI) are in 
http://www.iti.gov.br/twiki/pub/Certificacao/AuditoriaIndependente/processo_fiscalizacao.pdf

Comment 68

[Kathleen Wilson]

>> For the Secretaria da Receita Federal sub-CA, why does the CPS say:
>> --
>> 3.1.11 Autenticação da Identidade de um equipamento ou aplicação
>> Não se aplica.
>> --
>> What types of certs are issued under this sub-CA? 
>
> Only issues certs to sub-CA (2º level)
> "2.1.1 Obrigações da AC-RFB:
> g) Emitir, expedir e distribuir os certificados das AC de nível imediatamente
> subseqüente ao seu;
> 
> g) To issue, to dispatch and to distribute the certificates of the CA of level
> immediately subsequently (sub-CA 2º level);"
> 
> See more in CPS of AC-SRF

In regards to verification of domain ownership as described in section 7 of the Mozilla CA Policy, http://www.mozilla.org/projects/security/certs/policy/, what CP/CPS document specifies the minimum verification procedures for the sub-CAs of AC-SRF?

Comment 69

[Ruy Ramos]

(In reply to comment #68)
> >> For the Secretaria da Receita Federal sub-CA, why does the CPS say:
> >> --
> >> 3.1.11 Autenticação da Identidade de um equipamento ou aplicação
> >> Não se aplica.
> >> --
> >> What types of certs are issued under this sub-CA? 
> >
> > Only issues certs to sub-CA (2º level)
> > "2.1.1 Obrigações da AC-RFB:
> > g) Emitir, expedir e distribuir os certificados das AC de nível imediatamente
> > subseqüente ao seu;
> > 
> > g) To issue, to dispatch and to distribute the certificates of the CA of level
> > immediately subsequently (sub-CA 2º level);"
> > 
> > See more in CPS of AC-SRF
> 
> In regards to verification of domain ownership as described in section 7 of the
> Mozilla CA Policy, http://www.mozilla.org/projects/security/certs/policy/, what
> CP/CPS document specifies the minimum verification procedures for the sub-CAs
> of AC-SRF?

You can see in item 3.1.11.2 in these documents (CPS of sub-CAs):

AC-Serpro-RFB:
https://ccd.serpro.gov.br/acserprorfb/docs/dpcserprorfb_v3.0.pdf

AC-Certisign-RFB:
http://icp-brasil.certisign.com.br/repositorio/dpc/AC_Certisign_RFB/DPC_AC_Certisign_RFB_v3.0.pdf

AC-Serasa-RFB:
http://publicacao.certificadodigital.com.br/repositorio/dpc/declaracao-rfb.pdf

AC-Imprensa-Oficial-SP-RFB:
http://www.imprensaoficial.com.br/PortalIO/Certificacao/downloads/pdf/RFB/DPC_AC_IMESP_RFB_v3.0.pdf

AC-Prodemge-RFB:
https://wwws.prodemge.gov.br/images/stories/pdf/dpc_ac_prodemge_rfb_v3.0.pdf

AC-Sincor-RFB:
http://icp-brasil.acsincor.com.br/repositorio/dpc/AC_SINCOR/DPC_AC_SINCOR_v3.0.pdf

AC-Notarial-RFB:
http://icp-brasil.acnotarial.com.br/repositorio/dpc/AC_Notarial_RFB/DPC_AC_Notarial_RFB_v3.0.pdf

AC-BR-RFB: http://icp-brasil.acbr.org.br/repositorio/dpc/AC_BR_RFB/DPC_AC_BR_RFB_v3.0.pdf

Comment 70

[Ruy Ramos]

(In reply to comment #64)
> Re Comment #62, Thanks, but it appears that website was recently updated to a
> new cert that does not chain up to the Autoridade Certificadora Raiz Brasileira
> v1 root.
> 
> I still need a website whose SSL cert chains up to the Autoridade Certificadora
> Raiz Brasileira v1 root. Note that this can be a test website.

You can see this website
https://ccd.serpro.gov.br/certificados/index.htm

Maybe you must be installing these certificates:
- https://ccd.serpro.gov.br/acserpro/docs/serprov2.crt
- https://ccd.serpro.gov.br/acserpro/docs/serprofinalv2.crt

Comment 71

[Patricia T Oliveira Leite]

(In reply to comment #64)

Hello, here it is a site that uses a certificate chained to AC Raiz Brasileira V1.

https://www.lemonbank.com.br/Login/login.aspx
It was issued by Serasa Certificadora Digital V1, that is chained to AC Raiz Brasileira V1.

Comment 72

[Kathleen Wilson]

Attachment: Completed Information Gathering Document

Comment 73

[Kathleen Wilson]

Attachment: Completed subCA Review Document

Comment 74

[Kathleen Wilson]

I am getting this request ready for public discussion:
https://wiki.mozilla.org/CA:Schedule#Queue_for_Public_Discussion

For the test websites I have the following
** Old Root 
https://internetbanking.caixa.gov.br/SIIBC/index.processa
** New Root
https://ccd.serpro.gov.br/certificados/index.htm
https://www.lemonbank.com.br/Login/login.aspx

However, none of these sites appear to be set up to automatically load the cert chain.  Other than the root certificate, I should not have to manually load any of the certs in the chain.  Would you please have these websites updated to resolve this?

In regards to OCSP, I will also need example websites for the sub-CAs that provide OCSP. 

Based on the CPS documents it looks like AC-SERASA provides OCSP, so please provide an example website whose SSL cert chains up through their sub-CA. Maybe the www.lemonbank.com.br website meets this request, but I haven't been able to load the website.

It looks like AC-Certisign and AC-Imprensa-Oficial-Estado-SãoPaulo may provide OCSP under certain conditions/contracts. If OCSP under these two sub-CAs is available to the general public, then please also provide example websites whose SSL certs chain up through these sub-CAs.

Comment 75

[Kathleen Wilson]

Ruy, Please let me know when you expect to be able to provide the updates requested in Comment #74.

Comment 76

[Kathleen Wilson]

This request is at the top of the discussion queue, and it is time to start the next discussion.
https://wiki.mozilla.org/CA:Schedule#Queue_for_Public_Discussion

I have received email stating that the information that I requested in Comment #74 is forthcoming, so I will bump this request down just one slot in the queue.

Comment 77

[Ruy Ramos]

(In reply to comment #74)
> I am getting this request ready for public discussion:
> https://wiki.mozilla.org/CA:Schedule#Queue_for_Public_Discussion
> 
> For the test websites I have the following
> ** Old Root 
> https://internetbanking.caixa.gov.br/SIIBC/index.processa
> ** New Root
> https://ccd.serpro.gov.br/certificados/index.htm
> https://www.lemonbank.com.br/Login/login.aspx
> 
> However, none of these sites appear to be set up to automatically load the cert
> chain.  Other than the root certificate, I should not have to manually load any
> of the certs in the chain.  Would you please have these websites updated to
> resolve this?

There is a repository in each sub-CA and CA-root. Some sub-CA uses AIA, so the load is automatic, except for the CA-root. Another way is the implementation he was seeing Apache or IIS (web server) when set up to automatically load the cert chain. But there is no interference of the CA-root. The AIA atribute will be official/compulsory soon.

Comment 78

[Kathleen Wilson]

> There is a repository in each sub-CA and CA-root. Some sub-CA uses AIA, 
> so the load is automatic, except for the CA-root.

For both the old and new root, can you send me a url to a website (may be a test website) whose SSL cert chains up to the root and has the cert chain (except for the root) loaded automatically?

Also please note my request about OCSP in Comment #74. Recent events with other CAs have demonstrated the need for me to be more diligent about testing the OCSP responders of roots and their sub-CAs.

Comment 79

[Ruy Ramos]

(In reply to comment #78)
> > There is a repository in each sub-CA and CA-root. Some sub-CA uses AIA, 
> > so the load is automatic, except for the CA-root.
> 
> For both the old and new root, can you send me a url to a website (may be a
> test website) whose SSL cert chains up to the root and has the cert chain
> (except for the root) loaded automatically?

I still did not discover which implement the commented ( Comment #77 )

The problem is what while the certificate is not available in the repository of the browser I do not see how it will load the chain of automatic form (AIA maybe). These suggested examples allow the automatic load when there is used the IE, who already has the certificate root (ICP-Brasil).

AIA only works if CA-root load in browser repository. The OCSP needs of AIA.

We inform that the implementation of the AIA
(authority Information Access) - it is not compulsory for the authorities 
certifying of the ICP-Brasil, meantime, some sub-CAs implements in 
new chain of the ICP-Brasil (AC Root V1), but this service is not 
operational as soon as it depends on the insertion of the certificate in the browsers repository.



> 
> Also please note my request about OCSP in Comment #74. Recent events with other
> CAs have demonstrated the need for me to be more diligent about testing the
> OCSP responders of roots and their sub-CAs.

The service is still not operational but it is predicted for the sub-CAs (1o. and 2o. level):

_AC CERTISIGN MULTIPLA_
_AC OAB_
_AC SINCOR
AC SERASA JUS_
_AC CERTISIGN JUS_
_AC BR RFB_
_AC FENACON CERTISIGN RFB_
_AC IMESP RFB_
_AC NOTARIAL RFB_
_AC SINCOR RFB_
_AC CERTISIGN RFB_
_AC PRODEMGE RFB_
_AC SERASA RFB_
_AC FENACOR_
_SERASA CD

Additionally the obligatoriness is in study in the ICP-Brasil 
of the use of the field AIA for all sub-CAs.

Comment 80

[Ruy Ramos]

If the user wants to install of the only time the chain of 
certification by ICP-Brasil, it is enough to follow the instructions. 
There is updating for the FIREFOX, Internet Explorer and Adobe Acrobat Reader.

Firefox: http://acraiz.icpbrasil.gov.br/repositorio/mfirefox-der.der
IE: http://acraiz.icpbrasil.gov.br/repositorio/msie-der.p7b
Adobe Acrobat Reader: http://acraiz.icpbrasil.gov.br/repositorio/acrobat.acrobatsecuritysettings

Comment 81

[Ruy Ramos]

(In reply to comment #78)
> For both the old and new root, can you send me a url to a website (may be a
> test website) whose SSL cert chains up to the root and has the cert chain
> (except for the root) loaded automatically?

please try this: https://ccd.serpro.gov.br/certificados/index.htm

Comment 82

[Kathleen Wilson]

I have already manually imported the root cert.
When I go to https://ccd.serpro.gov.br/certificados/index.htm
in order to trust the website and see the full chain, I also have to manually import these subCAs:
https://ccd.serpro.gov.br/acserpro/docs/serprov2.crt
https://ccd.serpro.gov.br/acserpro/docs/serprofinalv2.crt

Intermediate CA certificates are expected to be distributed to the certificate subjects (the holders of the private keys) together with the subjects' own certificates.  Those subject parties (e.g. SSL servers) are then expected to send out the intermediate CA certificates together with their own certificates whenever they are asked to send out their certificates.  That is required by SSL/TLS.

Comment 83

[Ruy Ramos]

(In reply to comment #82)
> I have already manually imported the root cert.
> When I go to https://ccd.serpro.gov.br/certificados/index.htm
> in order to trust the website and see the full chain, I also have to manually
> import these subCAs:
> https://ccd.serpro.gov.br/acserpro/docs/serprov2.crt
> https://ccd.serpro.gov.br/acserpro/docs/serprofinalv2.crt
> 
> Intermediate CA certificates are expected to be distributed to the certificate
> subjects (the holders of the private keys) together with the subjects' own
> certificates.  Those subject parties (e.g. SSL servers) are then expected to
> send out the intermediate CA certificates together with their own certificates
> whenever they are asked to send out their certificates.  That is required by
> SSL/TLS.

It is necessary but not compulsory. How you know that there are two forms of mounting a chain. The first one is web server side, for example, in the Apache is necessary the chain of certificates informs in the variable SSLCertificateChainFile ("PKCS#7 Bundle" or .p7b). The second way (browser side) is when the browser makes use of the certificate itself with the AIA attribute.

The ICP-Brasil not as it will oblige the administrators of web server sending of the chain of automatic form. On the other side, The ICP-Brasil can demand the use of the AIA attribute.

I list someone sub-CA what already has the automatic load using AIA.


*AC PR*: http://ccd.serpro.gov.br/cadeias/ACPRv1.p7b

*AC OAB*: http://icp-brasil.certisign.com.br/repositorio/certificados/AC_OAB.p7c

*AC CERTISIGN MULTIPLA*: http://icp-brasil.certisign.com.br/repositorio/certificados/AC_Certisign_Multipla_G3.p7c

*AC CERTISIGN SPB*: http://icp-brasil.certisign.com.br/repositorio/certificados/AC_Certisign_SPB_G3.p7c

*AC IMESP*: http://icp-brasil.certisign.com.br/repositorio/certificados/AC_IMESP_G2.p7c

*AC PETROBRAS*: 
http://icp-brasil.certisign.com.br/repositorio/certificados/AC_PETROBRAS_G2.p7c

*AC PRODEMGE*:
http://icp-brasil.certisign.com.br/repositorio/certificados/AC_PRODEMGE_G2.p7c

*AC SINCOR*:
http://icp-brasil.acsincor.com.br/repositorio/certificados/AC_SINCOR_G2.p7c

*SERASA AC*:
http://www.certificadodigital.com.br/cadeias/serasaacv1.p7b

*SERASA CD*:
http://www.certificadodigital.com.br/cadeias/serasacdv1.p7b

*AC FENACOR*:
http://ocsp.certificadodigital.com.br/fenacorv1.p7b 

*AC IMESP RFB*:
http://icp-brasil.certisign.com.br/repositorio/certificados/AC_IMESP_RFB_G2.p7c

*AC SINCOR RFB*:
http://icp-brasil.acsincor.com.br/repositorio/certificados/AC_SINCOR_RFB_G2.p7c

*AC PRODEMGE RFB*:
http://icp-brasil.certisign.com.br/repositorio/certificados/AC_PRODEMGE_RFB_G2.p7c

*AC SERPRO RFB*:
http://ccd.serpro.gov.br/cadeias/acserprorfb.p7b

*AC CERTISIGN JUS*:
http://icp-brasil.certisign.com.br/repositorio/certificados/AC_Certisign_JUS_G2.p7c

*AC SERPRO JUS*:
http://ccd.serpro.gov.br/cadeias/acserprojusv2.p7b

*AC SERASA JUS*:
http://www.certificadodigital.com.br/cadeias/serasajusv1.p7b

Comment 84

[Ruy Ramos]

Testing URL https with AIA: https://servicos.dpf.gov.br/sinic-certidao/
(Brazilian Federal Police)

Comment 85

[Kathleen Wilson]

In my Firefox browser this website (https://servicos.dpf.gov.br/sinic-certidao/) behaves the same as the previously provided website (https://ccd.serpro.gov.br/certificados/index.htm). As long as I have manually imported and trusted the “Autoridade Certificadora do SERPRO Final v2” and “Autoridade Certificadora SERPRO v2” root certificates, the website loads fine.

However, if I have not manually imported those sub-CAs, the website will not load. The way I tested this is by going to Tools->Options…->Advanced->Encryption->View Certificates, and deleting those two sub-CAs (they are in the ICP-Brasil section). Then I clear recent history and try the websites again. This results in an untrusted connection for both.

Then if I manually import and trust the sub-CAs, both websites will work again.

Note that AIA for the SSL certs of both of these websites is the same:
Not Critical
CA Issuers: URI: http://ccd.serpro.gov.br/cadeias/serproacfv2.p7b

Since the context here is inclusion in Mozilla products, the major use case that needs to be tested is that of the end-user using a Firefox browser. If the root is included in Mozilla products, then the end-user should not have to manually import and trust the sub-CAs into their Firefox browser.

Comment 86

[Eddy Nigg (StartCom)]

Firefox (and NSS) don't support the fetching of CA certificates via AIA extension. Also I'm not sure if PKCS#7 files are supported either in this extension.

Servers must provide the complete chain up to the CA root.

Comment 87

[Ruy Ramos]

(In reply to comment #85)
> In my Firefox browser this website
> (https://servicos.dpf.gov.br/sinic-certidao/) behaves the same as the
> previously provided website (https://ccd.serpro.gov.br/certificados/index.htm).
> As long as I have manually imported and trusted the “Autoridade Certificadora
> do SERPRO Final v2” and “Autoridade Certificadora SERPRO v2” root certificates,
> the website loads fine.
> 
> However, if I have not manually imported those sub-CAs, the website will not
> load. The way I tested this is by going to
> Tools->Options…->Advanced->Encryption->View Certificates, and deleting those
> two sub-CAs (they are in the ICP-Brasil section). Then I clear recent history
> and try the websites again. This results in an untrusted connection for both.
> 
> Then if I manually import and trust the sub-CAs, both websites will work again.
> 
> Note that AIA for the SSL certs of both of these websites is the same:
> Not Critical
> CA Issuers: URI: http://ccd.serpro.gov.br/cadeias/serproacfv2.p7b
> 
> Since the context here is inclusion in Mozilla products, the major use case
> that needs to be tested is that of the end-user using a Firefox browser. If the
> root is included in Mozilla products, then the end-user should not have to
> manually import and trust the sub-CAs into their Firefox browser.

Kathleen and Eddy,

Please see this bug: https://bugzilla.mozilla.org/show_bug.cgi?id=399324
I believe what we could add to this discussion.

Regards, 
Ruy Ramos

Comment 88

[Kathleen Wilson]

Attachment: Completed Information Gathering Document

Updating the Info Gathering Document in preparation for the upcoming discussion.

Comment 89

[Kathleen Wilson]

I am now opening the first public discussion period for this request from ICP-Brasil to add the “Autoridade Certificadora Raiz Brasileira” and “Autoridade Certificadora Raiz Brasileira v1” root certificates and enable the Websites trust bit.

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.

http://www.mozilla.org/community/developer-forums.html
https://lists.mozilla.org/listinfo/dev-security-policy
news://news.mozilla.org/mozilla.dev.security.policy

The discussion thread is called “ICP-Brasil Root Inclusion Request”

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

Comment 90

[Kathleen Wilson]

The first public comment period for this request is now over. 

The primary concerns that were raised during the public discussion were in regards to the size of the CA hierarchy and the audits.

We have decided to take the approach to include the root if the upcoming audits meet Mozilla CA Requirements, cover all of the sub-CAs, and find no significant deficiencies.

While the hierarchy under this root is large, we should be able to approve the root as long as we have adequate information on all sub-CAs in terms of their meeting requirements and being under a reasonable audit and regulatory regime. Having the upcoming, third-party audits will provide some additional assurance that the overall hierarchy is being run properly.

The action items resulting from the discussion are as follows:

ACTION ICP-Brasil: Proceed with the upcoming audits that have been planned and budgeted. Please make sure that these audits meet the requirements of sections 8, 9, and 10 of the Mozilla CA Policy, http://www.mozilla.org/projects/security/certs/policy/.

ACTION ICP-Brasil: Update this bug to provide links to the public-facing audit reports/statements for the root and the sub-CAs, as those audits become available.

ACTION Kathleen: If the audit statements are not posted on a third-party website such as cert.webtrust.org, then follow the Mozilla process to do an independent verification of the authenticity of the audit statements.

ACTION Kathleen: After the audit statements for the root and sub-CAs have been provided and verified, start the second round of public discussion.

Comment 91

[Ruy Ramos]

I notice the ICP-Brazil has one more CA (1st level). This is CASA DA MOEDA DO BRASIL. All documentation (in Portuguese) is on this site https://ccd.serpro.gov.br/accmb/


Regards,
Ruy Ramos

Comment 92

[michael]

I put firefox in the cybercafe, and people are sometimes complaining, I really don't want to, but unfortunately it would be more respectful to clients to remove it, and I am considering it. 

This site belongs to the national tax dept, the "Brazilian IRS". 

https://cav.receita.fazenda.gov.br

FF 3.6 - invalid certificate warning

chrome 4.0.249.89 - access, no warnings, "the identity of this website has been verified by Autoridade Certificadora do SERPRORFB. 

IE8 - access, no warnings, similar confirmation to chrome.

Comment 93

[David E. Ross]

To all those who are impatient for this certificate to be approved and implemented for Gecko-based products:

The presence of a root certificate in the NSS database used by Gecko-based products indicates that users can place some degree of trust in the use of that certificate for secure Web browsing.  For that trust to be valid, the certificate authority owning the root certificate must undergo some scrutiny, which takes time.

The timeline for such scrutiny is described at <https://wiki.mozilla.org/CA:Schedule>, which also shows the current queue for the public discussion that is part of the process.  As noted in comment #90, an audit report is required before further progress can be made on this request.  

Thus, the problem lies in the hands of ICP-Brazil and its auditor, not with Mozilla.  

Further expressions of the need for haste will not speed the process.  Any shortcuts or other measures to hasten the process can only weaken the trust users have in the overall certificate database.

Those who are anxious for these root certificates -- those who already trust them and who have no patience with the Mozilla process for scrutinizing certificate authorities -- can download and install the root certificates themselves.  The links are at <http://www.mozilla.org/projects/security/certs/pending/#ICP-Brasil>.  

When downloaded, open the Certificate Manager at the "Authorities" tab and select the Import button.  On SeaMonkey, the Certificate Manager is reached from the menu bar via [Edit > Preferences > Privacy & Security > Certificates]. Since I don't use Firefox, I don't know the path of navigation there.

Comment 94

[Rodrigo Rodrigues da Silva]

(In reply to comment #93)
> As noted in comment #90, an
> audit report is required before further progress can be made on this request.  
> 
> Thus, the problem lies in the hands of ICP-Brazil and its auditor, not with
> Mozilla.

Any update on this issue? Is ICP-Brasil aware of this pending task? If there is anything that can be done, like contacting local authorities, I would be glad to help out.

Comment 95

[Ruy Ramos]

I notice the ICP-Brazil has two more chains.

The third chain ICP-Brasil (called v2) was created from the certificate signed in 21 of June of 2010. The certificate is available in
http://acraiz.icpbrasil.gov.br/ICP-Brasilv2.crt

The fourth chain ICP-Brasil (called v3) created in 21 of June of 2010. The certificate is available in
http://acraiz.icpbrasil.gov.br/ICP-Brasilv3.crt

The PCS is here http://acraiz.icpbrasil.gov.br/DPCacraiz.pdf

The main features of each chain:
-sha-512 With RSA Encryption (v2)
-sha-512 With ECDSA Encryption (v3)

Comment 96

[Renan Manola]

Last week I sent an e-mail to all of the people listed on this website: 
http://www.iti.gov.br/twiki/bin/view/Faleconosco/WebHome

So far, I haven't received any answer. I'd like to ask all Brazilians that have interest on this request to do the same. I guess ITI should put here some information on how the audits are going (if they are happening).

Regards.

Comment 97

[Anderson]

I will do it now...

After, I will also send an e-mail to these people: http://www.iti.gov.br/twiki/bin/view/ITI/QuemeQuem

Comment 98

[Kathleen Wilson]

(In reply to Kathleen Wilson from comment #90)
> While the hierarchy under this root is large, we should be able to approve
> the root as long as we have adequate information on all sub-CAs in terms of
> their meeting requirements and being under a reasonable audit and regulatory
> regime. Having the upcoming, third-party audits will provide some additional
> assurance that the overall hierarchy is being run properly.
> 
> The action items resulting from the discussion are as follows:
> 
> ACTION ICP-Brasil: Proceed with the upcoming audits that have been planned
> and budgeted. Please make sure that these audits meet the requirements of
> sections 8, 9, and 10 of the Mozilla CA Policy,
> http://www.mozilla.org/projects/security/certs/policy/.
> 
> ACTION ICP-Brasil: Update this bug to provide links to the public-facing
> audit reports/statements for the root and the sub-CAs, as those audits
> become available.
> 
> ACTION Kathleen: If the audit statements are not posted on a third-party
> website such as cert.webtrust.org, then follow the Mozilla process to do an
> independent verification of the authenticity of the audit statements.
> 
> ACTION Kathleen: After the audit statements for the root and sub-CAs have
> been provided and verified, start the second round of public discussion.


It has been brought to our attention that the ICP-Brasil CA is a Brazilian Government organization, and the sub-CAs are also all operated within the Brazilian Government. Therefore, the audits may only be performed by an organization within the Brazilian Government.

Mozilla's CA Certificate Policy has provision for Government CAs...
-- According to section 9 of Mozilla's CA Certificate Inclusion Policy, the annual audit must be performed according to criteria that is equivalent to one (or more) of ETSI TS 101 456, ETSI TS 102 042, or WebTrust CA. The government’s auditing agency should provide a statement about which of these their government criteria is equivalent to.
-- According to sections 10 and 11 of Mozilla's CA Certificate Inclusion Policy, it is acceptable for a government auditing organization to perform the audit of the government’s CA organization. It must be clear that the CA organization does not audit itself. The auditor may be within the Brazilian Government, as long as the auditor is not the same organization that is creating or owning the CA infrastructure. 
-- The auditor will need to provide annually a public-facing statement about the audit criteria, high-level summary of the outcome, and dates that the audit was performed. The statements may either be posted on a website or attached to a Mozilla Bugzilla bug. 

If ICP-Brasil wishes to continue with this root inclusion request, then please have a representative of ICP-Brasil add a comment in this bug.

Comment 99

[Ruy Ramos]

Dear Kathleen,

It is interesting to know about this new approach. We believe that this new approach is more suitable to ICP-Brazil.
 
In addition, everything has been said and discussed, the ITI, an agent of the Brazilian Government is who operates the CA-Root of ICP-Brasil. The ITI also monitors and audits the sub-CA. The publication of audits carried out by the ITI is done directly in the Official Journal of the Brazilian Government (DOU). Within this new perspective we will arrange to place external auditing of ITI. We will contact one of the entities that audit services (see comments of 8 - https://bugzilla.mozilla.org/show_bug.cgi?id=438825#c8 ) for the necessary arrangements.
And so, the audit reports of the sub-CA, if necessary we can provide all the necessary link to public publications in DIARIO OFICIAL DA UNIÃO (DOU), all in portuguese.

Regards,
Ruy Ramos

Comment 100

[Kathleen Wilson]

Hi Ruy,

It is fine if the documents are in Portuguese, as long as I can copy-and-paste relevant content into a translator.

Please provide links to the public-facing audit statements when they are available.

Regards,
Kathleen

Comment 101

[chris hofmann]

I can also help round up translation help if the machine translation is unclear.

Comment 102

[Eduardo Habkost]

(In reply to Kathleen Wilson from comment #98) 
> It has been brought to our attention that the ICP-Brasil CA is a Brazilian
> Government organization, and the sub-CAs are also all operated within the
> Brazilian Government.

Is this really true? The root CA and most sub-CAs are from the government, but I see at least 3 private companies listed as CAs at http://www.iti.gov.br/twiki/bin/view/Certificacao/EstruturaIcp and attachment #333737 [details] (Serasa, Certisign, and Valid).

(I don't know if this fact would affect the requirements for inclusion)

Comment 103

[Mardeg]

(In reply to Kathleen Wilson from comment #100)
> Hi Ruy,
> Please provide links to the public-facing audit statements when they are
> available.
> 
> Regards,
> Kathleen
One year on, adding needinfo flag for the above.

Comment 104

[Ruy Ramos]

I would like to say that the PriceWaterHouseCoopers company was hired and has up to 180 days to audit Root CA of ICP-Brasil. So, as soon as we have the audit extract we will publish it here (in english).

Regards,
Ruy Ramos

Comment 105

[Ruy Ramos]

Attachment: Information about the independent auditing firm that was hired (Diário Oficial da União BRASIL)

Comment 106

[André Carezia]

(In reply to Ruy Ramos from comment #104)
> I would like to say that the PriceWaterHouseCoopers company was hired and
> has up to 180 days to audit Root CA of ICP-Brasil. So, as soon as we have
> the audit extract we will publish it here (in english).

Now you're talking!

Comment 107

[Ralph Daub [:rdaub]]

(In reply to Ruy Ramos from comment #104)
> I would like to say that the PriceWaterHouseCoopers company was hired and
> has up to 180 days to audit Root CA of ICP-Brasil. So, as soon as we have
> the audit extract we will publish it here (in english).
> 
> Regards,
> Ruy Ramos

Hi Ruy,

Thanks for keeping us updated! Has there been any new development in the audit?

- Ralph

Comment 108

[Ruy Ramos]

Hi Ralph,
At this point the audit is completing the work. The delivery of audit report is July and then this report will be submitted to the Committee (CG-ICP-Brasil). And when approved will issue the extract for publication in this board. We hope to complete this phase until September.
Regards,
Ruy Ramos

Comment 109

[Ruy Ramos]

(In reply to Ralph Daub [:rdaub] from comment #107)
> (In reply to Ruy Ramos from comment #104)
> > I would like to say that the PriceWaterHouseCoopers company was hired and
> > has up to 180 days to audit Root CA of ICP-Brasil. So, as soon as we have
> > the audit extract we will publish it here (in english).
> > 
> > Regards,
> > Ruy Ramos
> 
> Hi Ruy,
> 
> Thanks for keeping us updated! Has there been any new development in the
> audit?
> 
> - Ralph

Hi Ralph,
At this point the audit is completing the work. The delivery of audit report is July and then this report will be submitted to the Committee (CG-ICP-Brasil). And when approved will issue the extract for publication in this board. We hope to complete this phase until September.
Regards,
Ruy Ramos

Comment 110

[David E. Ross]

(In reply to Ruy Ramos from comment #109)
> At this point the audit is completing the work. The delivery of audit report
> is July and then this report will be submitted to the Committee
> (CG-ICP-Brasil). And when approved will issue the extract for publication in
> this board. We hope to complete this phase until September.

I believe that either (1) the extract will have to be issued by the auditor and not the Committee or else (2) the auditor will publicly have to confirm the correctness of the extract.

Comment 111

[Ruy Ramos]

(In reply to David E. Ross from comment #110)
> (In reply to Ruy Ramos from comment #109)
> > At this point the audit is completing the work. The delivery of audit report
> > is July and then this report will be submitted to the Committee
> > (CG-ICP-Brasil). And when approved will issue the extract for publication in
> > this board. We hope to complete this phase until September.
> 
> I believe that either (1) the extract will have to be issued by the auditor
> and not the Committee or else (2) the auditor will publicly have to confirm
> the correctness of the extract.

David,

Yes (1), The extract shall be issued by the auditor. The PriceWaterHouseCoopers company has to deliver 2 products: a report and an extract (audit letter), in english and portuguese languages.

Regards
Ruy Ramos

Comment 112

[Ruy Ramos]

Attachment: Audit letter by PWC

Comment 113

[Ruy Ramos]

(In reply to Ruy Ramos from comment #112)
> Created attachment 822410 [details]
> Audit letter by PWC

Dear Kathleen,

Audit Letter as required by PriceWaterHouseCoopers.

Regards,
Ruy Ramos

Comment 114

[Kathleen Wilson]

Dear Ruy,

Thank you for providing the audit statement. 

Before I can start processing this request again, I need to make sure I have current information, as follows.

1) Which root certificates you will now seek to include in NSS? 

2) Which trust bits are you requesting for these root certificates?
One or more of: websites (SSL/TLS), email (S/MIME), code signing

3) What subordinate CAs chain up to these root certificates?

4) Are those subordinate CA certificates operated by ICP Brazil at the sites listed in the audit report?
From audit report: "Our responsibility is to issue a reasonable assurance report on the design and implementation of the controls in operation on June 30, 2013 for the Contingency site (located in Florianopolis, state of Santa Catarina) and the Production site (located in Brasilia, Federal District) in conformity with the requirements of DOC-ICP-01 and DOC-ICP-02, as set out in Attachment I of this report."

5) What audit criteria (or equivalent) was used by the auditors?
per item #11 of
http://www.mozilla.org/projects/security/certs/policy/InclusionPolicy.html


6) Please provide ICP Brazil's responses to the following CA Communications:
https://wiki.mozilla.org/CA:Communications#January_10.2C_2013
https://wiki.mozilla.org/CA:Communications#July_30.2C_2013

Comment 115

[Ruy Ramos]

Dear Kathleen,


(In reply to Kathleen Wilson from comment #114)
> Dear Ruy,
> 
> Thank you for providing the audit statement. 
> 
> Before I can start processing this request again, I need to make sure I have
> current information, as follows.
> 
> 1) Which root certificates you will now seek to include in NSS? 
> 
AC-raiz ICP-Brasil (v1,v2,v3)

v1: http://acraiz.icpbrasil.gov.br/ICP-Brasil.crt
v2: http://acraiz.icpbrasil.gov.br/ICP-Brasilv2.crt
v3: http://acraiz.icpbrasil.gov.br/ICP-Brasilv3.crt

> 2) Which trust bits are you requesting for these root certificates?
> One or more of: websites (SSL/TLS), email (S/MIME), code signing

none.

> 
> 3) What subordinate CAs chain up to these root certificates?
> 
Subordinate CAs (v1 and v2) 
See this file: http://acraiz.icpbrasil.gov.br/credenciadas/CertificadosAC-ICP-Brasil/ACcompactado.zip

> 4) Are those subordinate CA certificates operated by ICP Brazil at the sites
> listed in the audit report?
> From audit report: "Our responsibility is to issue a reasonable assurance
> report on the design and implementation of the controls in operation on June
> 30, 2013 for the Contingency site (located in Florianopolis, state of Santa
> Catarina) and the Production site (located in Brasilia, Federal District) in
> conformity with the requirements of DOC-ICP-01 and DOC-ICP-02, as set out in
> Attachment I of this report."

The ICP-Br root CA has two sites, one main and one contingency (back-up).
> 
> 5) What audit criteria (or equivalent) was used by the auditors?
> per item #11 of
> http://www.mozilla.org/projects/security/certs/policy/InclusionPolicy.html
> 
> 
> 6) Please provide ICP Brazil's responses to the following CA Communications:
> https://wiki.mozilla.org/CA:Communications#January_10.2C_2013
> https://wiki.mozilla.org/CA:Communications#July_30.2C_2013

We will provide ASAP.

Regards,
Ruy Ramos

Comment 116

[Cesar Eduardo Barros]

(In reply to Ruy Ramos from comment #115)
> (In reply to Kathleen Wilson from comment #114)
> > 2) Which trust bits are you requesting for these root certificates?
> > One or more of: websites (SSL/TLS), email (S/MIME), code signing
> 
> none.

Shouldn't it need at least the "Websites" trust bit, so sites like https://www.receita.fazenda.gov.br/ work correctly?

Comment 117

[André Fillipe O. Silva]

Attachment: Translation of the Items of Noncompliance

This is a free translation of the items of noncompliance identified by PWC during the audit (paragraph 8 of the report). The items were extracted from [1] and [2]. I think the translation might be useful if there is another round of discussion.

I may provide the translation of related items if the reviewers believe more context is needed.

[1] http://www.iti.gov.br/images/legislacao/Docicp/DOC-ICP-01_-_versao_4.3_DPC_DA_AC_RAIZ_DA_ICP-BRASIL_09.10.2013.pdf
[2] http://www.iti.gov.br/images/twiki/URL/pub/Certificacao/DocIcp/DOC-ICP-02_-_v._3.0.pdf

Comment 118

[Ruy Ramos]

> 
> > 4) Are those subordinate CA certificates operated by ICP Brazil at the sites
> > listed in the audit report?
> > From audit report: "Our responsibility is to issue a reasonable assurance
> > report on the design and implementation of the controls in operation on June
> > 30, 2013 for the Contingency site (located in Florianopolis, state of Santa
> > Catarina) and the Production site (located in Brasilia, Federal District) in
> > conformity with the requirements of DOC-ICP-01 and DOC-ICP-02, as set out in
> > Attachment I of this report."
> 
> The ICP-Br root CA has two sites, one main and one contingency (back-up).
> > 

In addition to the previous information, I have to say that none subordinate authority is hosted by the ICP-Brasil CA-root. The report comes only from the CA-root sites.

Comment 119

[Ruy Ramos]

Attachment: SRF-sample

Comment 120

[Ruy Ramos]

(In reply to Cesar Eduardo Barros from comment #116)
> (In reply to Ruy Ramos from comment #115)
> > (In reply to Kathleen Wilson from comment #114)
> > > 2) Which trust bits are you requesting for these root certificates?
> > > One or more of: websites (SSL/TLS), email (S/MIME), code signing
> > 
> > none.
> 
> Shouldn't it need at least the "Websites" trust bit, so sites like
> https://www.receita.fazenda.gov.br/ work correctly?

Andre,

I think we're having some confusion.

In CA-root certificates, we have described for the field:"Certificate Key usage" only trust bits:Certificate Signer and CRL Signer.

Only for certificates of entities (like Receita Federal do Brasil, as your example) we will have another bit setting. See entity certificate in attachment SRF-sample https://bugzilla.mozilla.org/attachment.cgi?id=8374174
In this way, each PCS of CA subordinate determines the bit to be set (code signing, e-mail, websites, etc).

Regards
Ruy Ramos

Comment 121

[Mauricio Maia]

(In reply to Ruy Ramos from comment #120)
> (In reply to Cesar Eduardo Barros from comment #116)
> > (In reply to Ruy Ramos from comment #115)
> > > (In reply to Kathleen Wilson from comment #114)
> > > > 2) Which trust bits are you requesting for these root certificates?
> > > > One or more of: websites (SSL/TLS), email (S/MIME), code signing
> > > 
> > > none.
> > 
> > Shouldn't it need at least the "Websites" trust bit, so sites like
> > https://www.receita.fazenda.gov.br/ work correctly?
> 
> Andre,
> 
> I think we're having some confusion.
> 
> In CA-root certificates, we have described for the field:"Certificate Key
> usage" only trust bits:Certificate Signer and CRL Signer.
> 
> Only for certificates of entities (like Receita Federal do Brasil, as your
> example) we will have another bit setting. See entity certificate in
> attachment SRF-sample https://bugzilla.mozilla.org/attachment.cgi?id=8374174
> In this way, each PCS of CA subordinate determines the bit to be set (code
> signing, e-mail, websites, etc).
> 
> Regards
> Ruy Ramos

Ruy,

I think you are confusing the X.509 Key Usage Extension with the trust bits required by the NSS. When a Root CA is included on the NSS a set of up to three trust bits must be enabled for it. You can find more information about this subject here: https://wiki.mozilla.org/CA:Root_Change_Process#Add_a_Trust_Bit .

Comment 122

[Kathleen Wilson]

To summarize the progression of this bug…
--
Comment #90 (in 2009): “ACTION ICP-Brasil: Update this bug to provide links to the public-facing audit reports/statements for the root and the sub-CAs, as those audits become available.”

Comment #98 (in 2011): “It has been brought to our attention that the ICP-Brasil CA is a Brazilian Government organization, and the sub-CAs are also all operated within the Brazilian Government. Therefore, the audits may only be performed by an organization within the Brazilian Government.”

Comment #99 (in 2011): “In addition, everything has been said and discussed, the ITI, an agent of the Brazilian Government is who operates the CA-Root of ICP-Brasil. The ITI also monitors and audits the sub-CA. …
And so, the audit reports of the sub-CA, if necessary we can provide all the necessary link to public publications in DIARIO OFICIAL DA UNIÃO (DOU), all in portuguese.”

Comment #102 (in 2012): “The root CA and most sub-CAs are from the government, but I see at least 3 private companies listed as CAs at http://www.iti.gov.br/twiki/bin/view/Certificacao/EstruturaIcp and attachment #333737 [details] (Serasa, Certisign, and Valid).”

February 2013: Mozilla’s CA Certificate Policy version 2.1 published, which added requirements for subordinate CAs and added the requirement for CAs to comply with the CA/Browser Forum’s Baseline Requirements. 
https://wiki.mozilla.org/CA:CertificatePolicyV2.1

Comment #112 (October 2013): PWC Audit letter provided. However, it appears to be for the operation of the root certificate only, not the subCAs.

Comment #115 (in 2014): “> 2) Which trust bits are you requesting for these root certificates?
> One or more of: websites (SSL/TLS), email (S/MIME), code signing
none.”

Comment #115: Subordinate CAs (v1 and v2) 
See this file: http://acraiz.icpbrasil.gov.br/credenciadas/CertificadosAC-ICP-Brasil/ACcompactado.zip

Comment #118: “In addition to the previous information, I have to say that none subordinate authority is hosted by the ICP-Brasil CA-root. The report comes only from the CA-root sites.”

Comment #120: “Only for certificates of entities (like Receita Federal do Brasil, as your example) we will have another bit setting. See entity certificate in attachment SRF-sample https://bugzilla.mozilla.org/attachment.cgi?id=8374174
In this way, each PCS of CA subordinate determines the bit to be set (code signing, e-mail, websites, etc).”

--

I have come to the conclusion that the ICP-Brasil CA functions as a super CA in that the subordinate CAs (some internal to the government, and some externally-operated) have their own policies according to the types of certificates they issue and their own audits. The policy and audit of the ICP-Brasil site only applies to the root certificates in their issuance of subordinate CA certificates. Therefore, the subordinate CAs must apply for inclusion themselves as separate trust anchors. 
For more information, see https://wiki.mozilla.org/CA:SubordinateCA_checklist

Please have the subordinate CAs apply for inclusion separately, by filing separate bugs. This is consistent with the approach we have taken for other similar super-CAs, such as Venezuela’s national government CA (SUSCERTE, bug #489240) and India’s national government CA (CCA, bug #557167). 

Each subordinate CA who applies for inclusion will need to demonstrate compliance with Mozilla’s CA Certificate Policy and the CA/Browser Forum’s Baseline Requirements (if requesting the websites trust bit).
https://wiki.mozilla.org/CA:How_to_apply#Creation_and_submission_of_the_root_CA_certificate_inclusion_request

Comment 123

[Ruy Ramos]

> --
> 
> I have come to the conclusion that the ICP-Brasil CA functions as a super CA
> in that the subordinate CAs (some internal to the government, and some
> externally-operated) have their own policies according to the types of
> certificates they issue and their own audits. The policy and audit of the
> ICP-Brasil site only applies to the root certificates in their issuance of
> subordinate CA certificates. Therefore, the subordinate CAs must apply for
> inclusion themselves as separate trust anchors. 
> For more information, see https://wiki.mozilla.org/CA:SubordinateCA_checklist
> 
> Please have the subordinate CAs apply for inclusion separately, by filing
> separate bugs. This is consistent with the approach we have taken for other
> similar super-CAs, such as Venezuela’s national government CA (SUSCERTE, bug
> #489240) and India’s national government CA (CCA, bug #557167). 
> 
> Each subordinate CA who applies for inclusion will need to demonstrate
> compliance with Mozilla’s CA Certificate Policy and the CA/Browser Forum’s
> Baseline Requirements (if requesting the websites trust bit).
> https://wiki.mozilla.org/CA:
> How_to_apply#Creation_and_submission_of_the_root_CA_certificate_inclusion_req
> uest

Kathleen,

The brazilian root CA for ICP-Brasil has complete accountability for the operations of its subsidiary CAs. That is achieved by annual audit procedures take into effect by ITI, the federal agency that plays the role of Root CA of ICP-Brasil. 

So, in our opinion, it doesn't make any sense to include only the subsidiary CAs certificates, cause the trusted chain won't be correctly achieved without the check against the root certificates of ICP-Brasil root CA (the ITI's certificates). 

So, in our case, we would like very much to see the root certificates of the so called super CA (ITI root certificates) included in the NSS database. Otherwise, it won't work for the brazilian applications.

Ruy Ramos

Comment 124

[Kathleen Wilson]

(In reply to Ruy Ramos from comment #123)
> 
> The brazilian root CA for ICP-Brasil has complete accountability for the
> operations of its subsidiary CAs. That is achieved by annual audit
> procedures take into effect by ITI, the federal agency that plays the role
> of Root CA of ICP-Brasil. 


Please see sections 8 through 14 of Mozilla's CA Certificate Inclusion Policy.
http://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/inclusion/

Section 10 says that if the subordinate CA certificate is not technically constrained (as described in section 9) then the subordinate CA must be audited according to sections 11 through 14. So, according to section 11 the subordinate CA operations must be audited according to the WebTrust CA or ETSI TS 102 042 criteria. Likewise, according to section 12 the subordinate CA operations must also be audited according to the Baseline Requirements.

How would we know that the criteria that ITI/ICP-Brasil uses to audit their subordinate CAs is inclusive of the versions of the WebTrust, ETSI, and BR audit criteria that Mozilla requires?

How would we know that the people within ITI/ICP-Brasil who are performing the audits are qualified to do so, and are acting as an independent party as described in sections 13 and 14?


> 
> So, in our opinion, it doesn't make any sense to include only the subsidiary
> CAs certificates, cause the trusted chain won't be correctly achieved
> without the check against the root certificates of ICP-Brasil root CA (the
> ITI's certificates). 


In Mozilla products (NSS) the trust bits are set at the root or trust anchor level. Each included root or trust anchor has one or more of the three trust bits set: websites (SSL/TLS), email (S/MIME), code signing.

When I asked which trust bits should be set for the ICB-Brasil root, the response in Comment #115 was "none.”

When asked for clarification, the response in Comment #120 was: “Only for certificates of entities (like Receita Federal do Brasil, as your example) we will have another bit setting. ...
In this way, each PCS of CA subordinate determines the bit to be set (code signing, e-mail, websites, etc).”

In order to have trust bit settings specific to each subordinate CA, then each subordinate CA would need to be included as a separate trust anchor in NSS.


> 
> So, in our case, we would like very much to see the root certificates of the
> so called super CA (ITI root certificates) included in the NSS database.
> Otherwise, it won't work for the brazilian applications.


As per the discussion in mozilla.dev.security.policy, I think we could consider this if Mozilla constrains the CA hierarchy to certain domains, such as *.gov.br.

If we consider this, what domains (such as *.gov.br) would need to be allowed?

Comment 125

[Kathleen Wilson]

(In reply to Kathleen Wilson from comment #122)
> The policy and audit of the
> ICP-Brasil site only applies to the root certificates in their issuance of
> subordinate CA certificates. Therefore, the subordinate CAs must apply for
> inclusion themselves as separate trust anchors. 
> For more information, see https://wiki.mozilla.org/CA:SubordinateCA_checklist
> 
> Please have the subordinate CAs apply for inclusion separately, by filing
> separate bugs. This is consistent with the approach we have taken for other
> similar super-CAs, such as Venezuela’s national government CA (SUSCERTE, bug
> #489240) and India’s national government CA (CCA, bug #557167). 
> 
> Each subordinate CA who applies for inclusion will need to demonstrate
> compliance with Mozilla’s CA Certificate Policy and the CA/Browser Forum’s
> Baseline Requirements (if requesting the websites trust bit).
> https://wiki.mozilla.org/CA:
> How_to_apply#Creation_and_submission_of_the_root_CA_certificate_inclusion_request


This has been discussed here:
https://groups.google.com/d/msg/mozilla.dev.security.policy/oZE1hNEY16w/HqxdwaEXVVoJ
"... 13 first-level authorities apply for inclusion themselves - so that it's clear to Mozilla (and the
public) whether or not ICP-Brazil is fully conforming with the Mozilla policy throughout the PKI hierarchy."

Please have the subordinate CAs apply for inclusion separately.

Comment 126

[Kathleen Wilson]

The topic of Super-CAs has been discussed in mozilla.dev.security.policy.
https://groups.google.com/d/msg/mozilla.dev.security.policy/oZE1hNEY16w/nrecA1vOakgJ

The conclusion of the discussion is:
https://wiki.mozilla.org/CA:SubordinateCA_checklist#Super-CAs
"Such signing CAs are called Super-CAs, and their subordinate CAs must apply for inclusion of their own certificates until the following has been established and demonstrated: ..."

Therefore, this request for inclusion of the ICP-Brasil root will be on hold, pending inclusion of ICP-Brasil's subordinate CAs. The subordinate CAs should create separate Bugzilla bugs and apply for inclusion themselves as separate trust anchors, https://wiki.mozilla.org/CA:How_to_apply.

Comment 127

[Garret Wilson]

Everyone, I haven't read all the tiny details of all the comments on this bug. I'm a software developer, but I'm not an SSL/TLS certificate expert.

But what I do know is that everybody---everybody!!---wanting a Brazilian visa to attend the 2014 World Cup in Brazil in just a few weeks has to go to https://scedv.serpro.gov.br/ and fill out a visa application. If they are using Firefox 29, they get a big warning and have to add a security exception just to enter the site. If they are using Chrome 34 or IE 11, they do _not_ get any such errors.

This bug was filed back in 2008, almost six years ago. I don't know who is at fault, but this should have been rectified by now. I'm not placing blame. I'm just saying it should have been addressed by now, one way or another, by somebody.

Is this issue going to be unresolved when it's time for the Olympic Games of 2016 in Brazil?

Comment 128

[André Carezia]

(In reply to Garret Wilson from comment #127)
> But what I do know is that everybody---everybody!!---wanting a Brazilian
> visa to attend the 2014 World Cup in Brazil in just a few weeks has to go to
> https://scedv.serpro.gov.br/ and fill out a visa application. If they are
> using Firefox 29, they get a big warning and have to add a security
> exception just to enter the site. If they are using Chrome 34 or IE 11, they
> do _not_ get any such errors.

One more reason for not coming here for the Cup.

As I noted before on this bug, the inclusion of Brazilian PKI on Firefox is a mistake. Our government has a history of security incompetence that won't go away any time soon. There's no transparency, no accountability. The whole PKI business stands on MP 2200/01, a kind of temporary law similar to a presidential decree. According to our Constitution, such temporary laws have to be submitted to the Congress for approval. But it never was, and it's been 13 years now.

This bug is about convincing Mozilla that the government manages and audits the CA and everything is going to work like magic. And Santa is real.

Comment 129

[Sergio Oliveira Campos]

(In reply to Kathleen Wilson from comment #126)
> The topic of Super-CAs has been discussed in mozilla.dev.security.policy.
> https://groups.google.com/d/msg/mozilla.dev.security.policy/oZE1hNEY16w/
> nrecA1vOakgJ
> 
> The conclusion of the discussion is:
> https://wiki.mozilla.org/CA:SubordinateCA_checklist#Super-CAs
> "Such signing CAs are called Super-CAs, and their subordinate CAs must apply
> for inclusion of their own certificates until the following has been
> established and demonstrated: ..."
> 
> Therefore, this request for inclusion of the ICP-Brasil root will be on
> hold, pending inclusion of ICP-Brasil's subordinate CAs. The subordinate CAs
> should create separate Bugzilla bugs and apply for inclusion themselves as
> separate trust anchors, https://wiki.mozilla.org/CA:How_to_apply.


Hello Kathleen, 

I'm not a member of ITI or any government organization but I've been a Mozilla volunteer for a long while (also a Rep) and I'm willing to help here.

Just to make sure I understood, each subordinate CA will have to start the application process and the documents from the superCA will be reused in each case?

Are those processes totally independent? If only some of the subordinate CAs apply and/or pass in Mozilla's validation is that ok?

I'm planing to try to contact some of the major subordinate CAs and try to explain how to process works.
I might be able to schedule some meetings to understand their problems and doubts and bring it back to you.

Do you think that could help?

Comment 130

[Kathleen Wilson]

(In reply to Sergio Oliveira Campos from comment #129)
> 
> I'm not a member of ITI or any government organization but I've been a
> Mozilla volunteer for a long while (also a Rep) and I'm willing to help here.

Excellent! Thanks!

> 
> Just to make sure I understood, each subordinate CA will have to start the
> application process 

Correct, each subordinate CA will have to go through the approval/inclusion process on their own, applying to have their subordinate CA certificate be a trust anchor in NSS.


> and the documents from the superCA will be reused in
> each case?

Each subordinate CA should have their on CP/CPS documentation, and annual audit statements that meet the requirements of Mozilla Policy and the CA/Browser Forum's Baseline Requirements.

References:
https://wiki.mozilla.org/CA:How_to_apply
https://wiki.mozilla.org/CA:BaselineRequirements


> 
> Are those processes totally independent? 

The approval/inclusion process for each subordinate CA will be completely independent of the others.

I recommend finding the subordinate CA that is closest to satisfying Mozilla Policy and the Baseline Requirements, and working with that one to get through the process. Then, they can be used as an example for the other subordinate CAs.


> If only some of the subordinate CAs
> apply and/or pass in Mozilla's validation is that ok?

It is fine and very possible that only some of the subordinate CAs get accepted and included. However, all of them would need to be accepted/included before the super CA could be.

> 
> I'm planing to try to contact some of the major subordinate CAs and try to
> explain how to process works.
> I might be able to schedule some meetings to understand their problems and
> doubts and bring it back to you.
> 
> Do you think that could help?

That sounds great.

Comment 131

[henriquevicente]

Mozilla shouldn't accept this certificate.

The Brazilian government has no respect for people's rights and allowing it is a privacy concern.

Even allowing this certificate only for *.gov.br and other government-reserved sub-domains isn't very recommended. Allowing for *.com.br is the same as creating a backdoor on Firefox and giving the keys to the government apparatus to spy on people.


Reference:
http://www.heritage.org/index/country/brazil


PS: if you search for news on Internet regulation on Brazil you'll see how the government wants to destroy freedom of speech in Brazil. If you search for corruption levels in Brazil, you'll see you can't trust the Brazilian government.
http://www.theguardian.com/world/2013/sep/20/brazil-dilma-rousseff-internet-us-control

Comment 132

[terceiro]

Dear Henrique,

Due to how asymmetric encryption works, your concerns are not valid.

By the way it is very funny to see someone so concerned about privacy using a
gmail.com email account.

Comment 133

[henriquevicente]

Dear terceiro,

Your argument is invalid. My concerns are valid. The use of asymmetric encryption doesn't mean Certificate Authorities can't issue / sign a rogue certificate. They can do it, just like they do for regular trustworthy certificates.

If you can't trust the CA, you can't trust the certificate signed by it.

Users seldom take their time to verify the name to whom a given website certificate was issued, never mind verify the CA and decide if they can trust it or not. This is why it's important that software vendors that embed CAs (mainly browsers vendors and operating systems) should do their best to accept only trustworthy entities.

I recommend the following resources for reference.
https://bluebox.com/blog/technical/questioning-the-chain-of-trust-investigations-into-the-root-certificates-on-mobile-devices/

Best regards,
Henrique.


PS: my personal email provider of choice is out of question and is not in any ways relevant for this issue.

Comment 134

[André Carezia]

(In reply to henriquevicente from comment #131)
> Mozilla shouldn't accept this certificate.
> 
> The Brazilian government has no respect for people's rights and allowing it
> is a privacy concern.

I second that.

And you did not even mention the huge electoral fraud, with cuban/venezuelan Smartmatic voting machines and secret vote counting process...

http://henrymakow.com/2014/10/dilmas-re-election-in-brazil-l.html

Comment 135

[André Fillipe O. Silva]

Dear Henrique,

If you read the latest comments by Mozilla staff in this report (did you?), you’ll notice that the Root CA will most certainly not be included in the Mozilla trusted key store due to it being a super CA. Individual CAs — be they controlled by the government, such as Receita Federal, or privately controlled, like Serasa and Certisign — will each have to request their inclusion.

Therefore, it would be more appropriate that you raise your concern — on technical grounds — when the particular CA that causes your anxiety actually requests their inclusion. (Don’t hold your breath.) Keep in mind that Mozilla policy requires the CAs to be audited by an independent party. Moreover, Mozilla is in no obligation to keep a Brazilian certificate in their trusted key store if down the line it proves to be, well, untrustworthy.

Right now, however, Brazilian citizens are being taught a behaviour that is far more damaging to their online security and privacy than the *ghost* of a rogue government CA: manual installation of “a” Root CA certificate downloaded from a plain HTTP connection.

Comment 136

[Augusto Herrmann]

It is utterly ridiculous, inconsistent and disrespectful towards Mozilla's users to continue to deny the inclusion of Brazil's root CA for so many years, while at the same time include Chinese Government's CNIIC root CA which spies on users and is known to produce malware.

See: http://en.wikipedia.org/wiki/China_Internet_Network_Information_Center#Malware_Production_And_Distribution
bug #476766 and bug #607208

On the other hand, Brazilian users of Firefox have for years been obligated to manually download and install the ICP Brasil root certificates for any interaction with the government (for instance, to file mandatory income tax declarations). Most people however don't even know this is an issue, however, and have become used to adding security exceptions, which is even worse for their own security.

Mozilla is only punishing Brazilian users of Firefox by not having still accepted this root CA.

I for one have for more than 10 years always manually installed the Brazilian root CA into every browser I use (including Firefox), and also Thunderbird. Since I discovered last year that China's CA is installed by default, I have always manually disabled (untrusted) it. I always do recommend by friends do the same as a security best practice.

Comment 137

[henriquevicente]

You don't fix a security issue by creating a second one making the problem worse.

The proper thing to do is to remove the CNIIC root CA. Not to add a new one from another unstable, corrupt country know to spy on people for political and unjust reasons.

Comment 138

[André Fillipe O. Silva]

(In reply to Augusto Herrmann from comment #136)
> It is utterly ridiculous, inconsistent and disrespectful towards Mozilla's
> users to continue to deny the inclusion of Brazil's root CA for so many
> years, while at the same time include Chinese Government's CNIIC root CA
> which spies on users and is known to produce malware.

Please, acquaint yourself with the long history of this bug. The only reason we still don't have a trusted Brazilian CA is ICP-Brasil's own inertia, questionable practices, and disregard for openness and transparency. 

ICP-Brasil have always relied on obscure partnerships with Microsoft [1,2] to have its root certificate included in the Windows trust store. Now that Mozilla, Google, and Apple are the dominant browser vendors, ICP-Brasil are finally finding out that their practices and (literally) fractal structure [3] will not pass technical scrutiny.

Mozilla are being diligent precisely to minimize the possibility of another CNNIC, Comodo, or ANNSI happening. Mozilla are protecting one of the most critical and fragile elements of secure Internet communications: the PKI. It's a good thing ICP-Brasil is not part of it yet. Our "suffering" as involuntary ICP-Brasil users does entitle ICP-Brasil to anything.

Your outrage, while understandable, is misdirected. You should be complaining to ITI and ICP-Brasil. Mozilla have been clear that the Root CA will not be included (see comment #126). By now, one would expect ICP-Brasil to have already notified their subordinate CAs to apply for inclusion, but I see no evidence of that [4].



[1]: http://www.iti.gov.br/noticias/iti-na-midia/1387-parceria-torna-internet-explorer-compativel-com-icp-brasil
[2]: https://www.microsoft.com/brasil/setorpublico/temas/icp-brasil.mspx
[3]: http://www.iti.gov.br/images/icp-brasil/estrutura/2013/atualiza%C3%A7%C3%A3o23/Estrutura_completa.pdf
[4]: https://bugzilla.mozilla.org/buglist.cgi?list_id=12145824&short_desc=serasa%20certisign%20serpro%20digitalsign%20cef%20jus&query_format=advanced&short_desc_type=anywordssubstr&component=CA%20Certificates

Comment 139

[André Fillipe O. Silva]

(In reply to henriquevicente from comment #137)
> You don't fix a security issue by creating a second one making the problem
> worse.
> 
> The proper thing to do is to remove the CNIIC root CA. Not to add a new one
> from another unstable, corrupt country know to spy on people for political
> and unjust reasons.

Do please provide evidence of the ICP-Brasil root certificate being used for spying purposes. There's been ample opportunity for that, since it's been part of the Windows trust store for a long time.

Both demanding ICP-Brasil be included "just because" AND requiring it not even be considered because of one's personal perceptions is not productive. There are rules governing the process. You actually had the opportunity to voice your concerns [1]. Right now, you're just being inflammatory.

[1]: https://wiki.mozilla.org/CA:How_to_apply#Public_discussion

Comment 140

[Daniel Kahn Gillmor]

I agree with the (In reply to André Fillipe O. Silva from comment #138)
> Mozilla are being diligent precisely to minimize the possibility of another
> CNNIC, Comodo, or ANNSI happening. Mozilla are protecting one of the most
> critical and fragile elements of secure Internet communications: the PKI.
> It's a good thing ICP-Brasil is not part of it yet.

I think i agree with this perspective, but Brazilian users who hand-install the ICP-Brasil root certificate are now vulnerable to attacks that should be prevented by public key pinning (HPKP).  See bug 1168603 for a suggested way to fix that part of the problem.  Brazilian users who need to access gov.br web sites should not make themselves vulnerable to pinning violations on non-gov.br web sites.

See also bug 953322 which is another way that Brazilian citizens (and those applying for visas, as noted in comment 127) could constrain the risks involved with importing the ICP-Brasil root.

Comment 141

[Adail Spinola Horst]

Hi all,

  I am member of CISL (Brazilian Committee of free software implementation - www.softwarelivre.gov.br) and like to know what we can do for solve this PROBLEM. 

  Currently ALL government services are published using ICP/Brasil certificates and this issue make serious problems for the users.

  What we can do for finish this issue ?

Comment 142

[Reuben Morais [:reuben]]

(In reply to Adail Spinola Horst from comment #141)
>   What we can do for finish this issue ?

Email ITI/ICP-Brasil and ask them to follow the process. They haven't made any progress on this since 2014-04-01 (comment 126).

Comment 143

[Ruy Ramos]

Dear Kathleen,

We publish the links of the letter from independent audit. The letters are in portuguese and english.
the first comes from the Brazilian legislation and the second refers to the established in the policy of the Foundation Mozilla.

(1) http://www.iti.gov.br/images/icp-brasil/pareceres/Parecer_Resumo-_AC_Raiz_-_EY_-_2015-ing.pdf
(2) http://www.iti.gov.br/images/icp-brasil/pareceres/Webtrust_for_CA_-_AC_Raiz_-_2015.pdf


In addition to comment 126, we inform you that the Committee (in dec/2015) has defined the creation of a technical group to evaluate the requested forwarding. In fact there is a different understanding, of this forum regarding Brazilian legislation and the ICP-Brazil. Since include all subordinate authorities means, include 14 CA (1st level) and 61 CA (2nd level).

The results from technical group will be published as soon as available.

Regards,

Ruy Ramos

Comment 144

[Kathleen Wilson]

(In reply to Ruy Ramos from comment #143)
> ...
> In addition to comment 126, we inform you that the Committee (in dec/2015)
> has defined the creation of a technical group to evaluate the requested
> forwarding. In fact there is a different understanding, of this forum
> regarding Brazilian legislation and the ICP-Brazil. Since include all
> subordinate authorities means, include 14 CA (1st level) and 61 CA (2nd
> level).

The 14 1st-level subCAs would need to apply for inclusion.
But, please start with one or two of the 1st-level subCAs that are fully compliant with the CA/Browser Forum's Baseline Requirements and you think would pass through Mozilla's process.

Comment 145

[Sergio Oliveira Campos]

If one of the 14 1st-level subCAs apply and everything works fine all the certs issued by that CA and it's 2nd-level CAs would be valid or all 2nd-level would have to apply as well?

Basically my question is: to a CA get accepted all CAs under it must be accepted as well?

Is it common/normal to a CA to have so many subCAs under it?

Comment 146

[lvella]

Does anyone knows if any subCAs have applied themselves to the inclusion process? Can you link the bugs?

Comment 147

[Adail Spinola Horst]

Kathleen Wilson,

  Currently I work in one of 14 1st-level subCAs and like to know what is the process to apply.
  Reading this bug I found reference to this page: 

https://wiki.mozilla.org/CA:How_to_apply#Creation_and_submission_of_the_root_CA_certificate_inclusion_request

  Is this ?

Comment 148

[lvella]

(In reply to Kathleen Wilson from comment #130)
> (In reply to Sergio Oliveira Campos from comment #129)
> > Just to make sure I understood, each subordinate CA will have to start the
> > application process 
> 
> Correct, each subordinate CA will have to go through the approval/inclusion
> process on their own, applying to have their subordinate CA certificate be a
> trust anchor in NSS.

Not that I believe ICP-Brasil Root Certificate will ever meet the requirements for inclusion by itself (maybe some of the independently administered first-level CAs will), but reading the rules for Super-CAs, your interpretation seems wrong.

There it says the subordinate CAs must apply for inclusion of their own certificates until some conditions are met that will allow the Super-CA to be included, but doesn't says this inclusion of all subordinates is a requirement by itself.

That means that if some Super-CA like ICP-Brasil manages somehow to fulfil those highly stringent requirements (which include auditing their subordinates just like Mozilla would), there is no need for their subordinate CAs to be included directly.

Comment 149

[Kathleen Wilson]

(In reply to Sergio Oliveira Campos from comment #145)
> If one of the 14 1st-level subCAs apply and everything works fine all the
> certs issued by that CA and it's 2nd-level CAs would be valid or all
> 2nd-level would have to apply as well?

No, the 2nd-level CAs would not need to apply separately.

> 
> Basically my question is: to a CA get accepted all CAs under it must be
> accepted as well?

The subCAs will be considered at the same time as their parent CA.
The parent CA will have to provide all the information listed here:
https://wiki.mozilla.org/CA:SubordinateCA_checklist

> 
> Is it common/normal to a CA to have so many subCAs under it?

It is normal. It just makes evaluation of the CA Hierarchy more difficult.

Comment 150

[Kathleen Wilson]

(In reply to lvella from comment #146)
> Does anyone knows if any subCAs have applied themselves to the inclusion
> process? Can you link the bugs?

PROCERT (Bug #593805) is an example, as a subCA of SUSCERTE. In Bug #489240 it was determined that SUSCERTE's subCAs would need to apply for inclusion separately.

Comment 151

[Kathleen Wilson]

(In reply to Adail Spinola Horst from comment #147)
> Kathleen Wilson,
> 
>   Currently I work in one of 14 1st-level subCAs and like to know what is
> the process to apply.
>   Reading this bug I found reference to this page: 
> 
> https://wiki.mozilla.org/CA:
> How_to_apply#Creation_and_submission_of_the_root_CA_certificate_inclusion_req
> uest
> 
>   Is this ?


Yes, please follow the instructions and file a new Bugzilla Bug as described here:
https://wiki.mozilla.org/CA:How_to_apply#Creation_and_submission_of_the_root_CA_certificate_inclusion_request

Comment 152

[Ruy Ramos]

Kathleen Wilson,

As already reported, we now have a technical group to discuss various issues, including the issue of the insertion of the root certificate in Mozilla's repository. 
The group asked me to publish the following issues:

1) If included one or two 1st CA (Comment #144 https://bugzilla.mozilla.org/show_bug.cgi?id=438825#c144 ), and these meet the criteria of the Mozilla Foundation, what will we have next? The inclusion of CA-root or the need to also include all other 1st level CA?

2) the audit report produced by the ITI can be accepted or only independent auditing companies report? It is important to say that is assigned to the ITI auditing 1st CA.

3) there is a need to include a second level for AC validation? Remembering that are 2nd level CA that issue certificates to end users.

4) is there any guarantee of inclusion of the root CA at the end of the process? This is necessary to meet the brazilian legislation that defines the trust chain cycle ends at root CA (ICP-Brasil) and not in a 1st level CA. This is very critical because it could confuse users in Brazil.

Thank you for your attention.

regards,
Ruy Ramos

Comment 153

[Kathleen Wilson]

(In reply to Ruy Ramos from comment #152)
> 1) If included one or two 1st CA (Comment #144
> https://bugzilla.mozilla.org/show_bug.cgi?id=438825#c144 ), and these meet
> the criteria of the Mozilla Foundation, what will we have next? The
> inclusion of CA-root or the need to also include all other 1st level CA?

In considering a root certificate for inclusion in NSS, Mozilla must also evaluate the current subordinate CAs and the selection/approval criteria for future subordinate CAs.

If 2 of your subordinate CAs successfully complete Mozilla's root inclusion process, and you are then confident that all of your other subordinate CAs meet all of the requirements, then would could proceed as one big request, where we evaluate all of the remaining subordinate CAs at the same time.


> 2) the audit report produced by the ITI can be accepted or only independent
> auditing companies report? It is important to say that is assigned to the
> ITI auditing 1st CA.

If the Websites trust bit is to be enabled, then the auditor and audit statements need to meet the requirements of Mozilla's policy.

See sections 11 through 14 of
https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/inclusion/
Section 14: By "independent party" we mean a person or other entity who is not affiliated with the CA as an employee or director... 

> 
> 3) there is a need to include a second level for AC validation? Remembering
> that are 2nd level CA that issue certificates to end users.

All of the root certificates and non-technically-constrained intermediate certificates must meet the audit requirements. And the required audit statements must be provided annually.

See sections 8 through 10 of
https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/inclusion/

This is also described in the CA/Browser Forum's Baseline Requirements.


> 4) is there any guarantee of inclusion of the root CA at the end of the
> process? 

There is no guarantee of inclusion. Mozilla's inclusion process includes a public discussion phase, at which time concerns can be raised that prevent approval of the request.
https://wiki.mozilla.org/CA:How_to_apply#Public_discussion

Comment 154

[Ruy Ramos]

Kathleen Wilson,

Now, ICP-Brasil are in according WebTrust compliance.

See in https://cert.webtrust.org/ViewSeal?id=2210

Regards
Ruy Ramos

Comment 155

[Ryan Sleevi]

That's WebTrust for CAs (known as "Trust Service Principles and Criteria for Certification Authorities, Version 2.0"), but not "WebTrust Principles and Criteria for Certification Authorities - SSL Baseline with Network Security, Version 2.2". Mozilla requires both.

Note that this was completed by E&Y Brazil, which is the same party which recently completed Certisigns' deficient audit, and as a result, has caused at least Symantec to refuse to accept audits from this party for their RA or sub-CA partners. You can read about the questions related to Certisign's audit, and Symantec's replies, at Bug 1334377 (specifically, https://bug1334377.bmoattachments.org/attachment.cgi?id=8836487 )

Comment 156

[Ruy Ramos]

Hi Kathleen,

My colleague Andre Caricatti ( [e-mail] ) will answer the questions on this forum.

I'm going to be assisting when needed.

Regards
Ruy Ramos

Comment 157

[Kathleen Wilson]

Andre,

Please begin by creating a new Bugzilla Bug to request inclusion of one of the subordinate CAs -- start with one that is in full compliance with the BRs and Mozilla's Root Store Policy.

https://wiki.mozilla.org/CA/Application_Instructions#Create_Root_Inclusion.2FUpdate_Request
https://wiki.mozilla.org/CA/Application_Process

In the new bug, indicate that it is a subCA of the ICP-Brasil root, which has been declared to be a Super-CA.
https://wiki.mozilla.org/CA/Subordinate_CA_Checklist#Super-CAs

Comment 158

[Andre Caricatti]

Hi Kathleen,

This is the new WebTrust Seal of assurance for the root CA - AC Raiz - of ICP Brasil.

https://cert.webtrust.org/ViewSeal?id=2378.

Regards,
Andre Caricatti.

Comment 159

[abraaopessoa]

Please let us know what is needed to add brazilian CAs as trustable in the Firefox! It has become a big shame for us, brazilian people, all our site has been blocked! I can help if needed, ten years of negotiation is a very long time for solving a problem like this!

Comment 160

[lvella]

As I understand, from previous comment, highest level CA Root, issued by ICP Brazil, can't be added first, per rules of Mozilla. Every CA under it must apply individually. So, for instance, if you bought your certificate from Serasa, you must ask them to apply for inclusion.

Comment 161

[edu.carlos.vieira]

Doesn't ICPEDU use the same idea of sub-CAs? 

https://www.rnp.br/en/services/advanced-services/icpedu

Is someone from there here? Maybe they could help ITI/ICP-Brasil.

Comment 162

[B.]

OMG, this was reported 11 years ago!

ELEVEN YEARS!!!

How come this isn't solved yet?!?

Comment 163

[Kathleen Wilson]

I am closing old requests that are for inclusion of super-CA root certificates.

This CA may re-apply for inclusion of their root certificate when they meet all of the requirements listed here:

https://wiki.mozilla.org/CA/Subordinate_CA_Checklist#Super-CAs

Until then, this CA's (first-level) subordinate CAs may apply for inclusion of their certificate as a trust anchor, as described here:

https://wiki.mozilla.org/CA/Application_Process