Public Discussion of SERPRO's CA Inclusion Request

[Ben Wilson]

All,

This is to announce the beginning of a six-week public discussion period for the inclusion request of Serviço Federal de Processamento de Dados (SERPRO) (Bug # 1677631, CCADB Case # 680) for its Autoridade Certificadora do SERPRO SSLv1 issuing CA certificate (SERPRO SSLv1), issued under the Autoridade Certificadora Raiz Brasileira v10, which is the root CA designated under the Brazilian PKI for support of TLS certificate issuance.  Mozilla is considering SERPRO’s request to add the SERPRO SSLv1 CA as a trust anchor with the websites trust bit enabled.

Download –  https://repositorio.serpro.gov.br/cadeias/serprossl.crt

crt.sh - https://crt.sh/?sha256=08FC942D5176E568ACBEF9C595F36A20DE6ACF9EA30C6F5FCEDD48216ED5B070

Repository: The SERPRO document repository is located here:  https://certificados.serpro.gov.br/serprossl/certification-policies.

Relevant Policy and Practices Documentation:

An English version of the SERPRO CPS (v.4.2), March 2022, is available here: https://repositorio.serpro.gov.br/docs/CPS_SERPRO_SSL_CA.pdf

Self-Assessments and Mozilla CPS Reviews are located within Bug # 1677631:

AC_SERPRO_SSL_Self_Assessment.ods

Mozilla’s CP/CPS Review comments – Comment #2, Comment #73, and Comment #77

Value-vs-Risk Justification from SERPRO – see Value vs Risk_SERPRO_SSL_CA.pdf

Audits:  Annual audits have been performed by PKI Contabilidade e Auditoria Ltda in accordance with the Webtrust Principles and Criteria for Certification Authorities. The most recent audits available were published on July 22, 2022, for the period ending May 29, 2022.  See

https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=b6a5cf89-dd0a-484e-bad5-5cf4faeb10a0 (Standard Webtrust)

https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=5bee38f1-db75-46fe-91df-2ff67c6f0560 (WebTrust Baseline Requirements)

I have no other questions related to SERPRO’s inclusion request; however, I urge anyone with concerns or questions to raise them on this list by replying directly in this discussion thread. Likewise, a representative of SERPRO must promptly respond directly in the discussion thread to all questions that are posted.

This email begins a 6-week period for public discussion and comment, which I’m scheduling to close on or about December 31, 2022, after which, if no concerns are raised, we will close the discussion and the request may proceed to Mozilla’s one-week “last-call” phase.

Sincerely yours,

Ben Wilson

Mozilla Root Program Manager

[Kurt Seifried]

Reading their Value-vs-Risk Justification from SERPRO – see Value vs Risk_SERPRO_SSL_CA.pdf

Maybe I misunderstand this:

1. Why does the applicant want its root CA certificate(s) to be included by default in Mozilla’s
root store?

The inclusion of SERPRO SSL CA in Mozilla's root store is crucial for us to build a strong public
trust.
It represents a pledge of confidence for our clients and partners because of Mozilla's strict rules and
requirements for managing its Root Store.
SERPRO SSL CA objective is to become a publicly-trusted commercial CA with Brazilian reach,
securing a wide range of websites visited by Firefox users. 

Would there be any other reason than "we want to become a CA"? 

Also, will there be any Mozilla Applied Constraints e.g. named-constraints applied? It appears not? They're a Brazilian government CA so one assumes they'd be dealing with *.br primarily? Do they need to issue certificates for other domains as well?

--
You received this message because you are subscribed to the Google Groups "public" group.
To unsubscribe from this group and stop receiving emails from it, send an email to public+un...@ccadb.org.
To view this discussion on the web visit https://groups.google.com/a/ccadb.org/d/msgid/public/CA%2B1gtaagUFek6Fp_xp3Rw4PozHz3EJFrvNM5HQvxA2ifmsCLHQ%40mail.gmail.com.

--

Kurt Seifried (He/Him)
ku...@seifried.org

[Andrew Ayer]

As recently as 2021, this CA was issuing certificates with DNS SANs such as:

https://certificados.serpro.gov.br/arssl/ (https://crt.sh/?id=4554741564)
ccd-ct01bsa (https://crt.sh/?id=4541931304)
sgconf.rfoc.srf (srf is not a valid TLD) (https://crt.sh/?id=4415391045)

There are many more examples of shocking misissuances here:
https://cachecker-dot-ccadb-231121.appspot.com/summary/194400?max_depth=-1&start=2020-03-12&end=2021-06-02&z_lint=on&cab_lint=on&x509_lint=on

This is clearly not a mature CA and no root program should include it.

Regards,
Andrew

[Lucia Castelli]

Would there be any other reason than "we want to become a CA"? 

We would like to be a CA with competitive characteristics in our issued certificates. 

No other reason.

[Kurt Seifried]

Oh wow. They have issued certs in the last year or so for:

* HTTPS urls

* Names like "Benner" (multiple times)

* non existing TLDs ("intra") 

* IP address 189.9.81.58

Out of 600 certificates there's 

https://crt.sh/?q=Autoridade+Certificadora+do+SERPRO+SSLv1

https://crt.sh/?id=3756574427

 Subject: (CA ID: 194400)            commonName                = Autoridade Certificadora do SERPRO SSLv1

https://crt.sh/?id=4411160619

Subject:             commonName                = SEGES-171379.mp.intra

https://crt.sh/?id=4375190459

Subject:            commonName                = https://p-datavalidp.estaleiro.serpro.gov.br

https://crt.sh/?id=4374011657

Subject:            commonName                = https://hom-carneleaoweb.estaleiro.serpro.gov.br/carneleao/

https://crt.sh/?id=4345805063

 Subject:            commonName                = https://consopt.www8.receita.fazenda.gov.br/consultaoptantes

https://crt.sh/?id=4310740172

Subject:            commonName                = https://lfft.estaleiro.serpro.gov.br

https://crt.sh/?id=4267330157

Subject:            commonName                = Benner

https://crt.sh/?id=4020518938

Subject:            commonName                = 189.9.81.58

https://crt.sh/?id=4272875230

Subject:        commonName                = Benner

Ok, this is taking too long, I ended up putting it into Excel:

crt.sh ID

Logged At  ⇧

Not Before

Not After

Common Name

Matching Identities

Issuer Name

3.76E+09

########

########

########

Autoridade Certificadora do SERPRO SSLv1

Autoridade Certificadora do SERPRO SSLv1

C=BR, O=ICP-Brasil, OU=Instituto Nacional de Tecnologia da Informacao - ITI, CN=Autoridade Certificadora Raiz Brasileira v10
4.55E+09	########	########	########	https://certificados.serpro.gov.br/arssl/

Autoridade Certificadora do SERPRO SSLv1

C=BR, O=ICP-Brasil, OU=Autoridade Certificadora Raiz Brasileira v10, CN=Autoridade Certificadora do SERPRO SSLv1
4.54E+09	########	########	########	ccd-ct01bsa

Autoridade Certificadora do SERPRO SSLv1

C=BR, O=ICP-Brasil, OU=Autoridade Certificadora Raiz Brasileira v10, CN=Autoridade Certificadora do SERPRO SSLv1
4.54E+09	########	########	########	ccd-ct02bsa

Autoridade Certificadora do SERPRO SSLv1

C=BR, O=ICP-Brasil, OU=Autoridade Certificadora Raiz Brasileira v10, CN=Autoridade Certificadora do SERPRO SSLv1
4.45E+09	########	########	########	Extrato Selic - Producao

Autoridade Certificadora do SERPRO SSLv1

C=BR, O=ICP-Brasil, OU=Autoridade Certificadora Raiz Brasileira v10, CN=Autoridade Certificadora do SERPRO SSLv1
4.45E+09	########	########	########	flexa.pgfn.fazenda

Autoridade Certificadora do SERPRO SSLv1

C=BR, O=ICP-Brasil, OU=Autoridade Certificadora Raiz Brasileira v10, CN=Autoridade Certificadora do SERPRO SSLv1
4.42E+09	########	########	########	sgconf.rfoc.srf

Autoridade Certificadora do SERPRO SSLv1

C=BR, O=ICP-Brasil, OU=Autoridade Certificadora Raiz Brasileira v10, CN=Autoridade Certificadora do SERPRO SSLv1
4.41E+09	########	########	########	SEGES-171379.mp.intra

Autoridade Certificadora do SERPRO SSLv1

C=BR, O=ICP-Brasil, OU=Autoridade Certificadora Raiz Brasileira v10, CN=Autoridade Certificadora do SERPRO SSLv1
4.39E+09	########	########	########	ibmwebspheremqsefazsc

Autoridade Certificadora do SERPRO SSLv1

C=BR, O=ICP-Brasil, OU=Autoridade Certificadora Raiz Brasileira v10, CN=Autoridade Certificadora do SERPRO SSLv1
4.37E+09	########	########	########	https://hom-carneleaoweb.estaleiro.serpro.gov.br/carneleao/

Autoridade Certificadora do SERPRO SSLv1

C=BR, O=ICP-Brasil, OU=Autoridade Certificadora Raiz Brasileira v10, CN=Autoridade Certificadora do SERPRO SSLv1
4.35E+09	########	########	########	https://consopt.www8.receita.fazenda.gov.br/consultaoptantes

Autoridade Certificadora do SERPRO SSLv1

C=BR, O=ICP-Brasil, OU=Autoridade Certificadora Raiz Brasileira v10, CN=Autoridade Certificadora do SERPRO SSLv1
4.31E+09	########	########	########	http://confucius.hcpa.edu.br/

Autoridade Certificadora do SERPRO SSLv1

C=BR, O=ICP-Brasil, OU=Autoridade Certificadora Raiz Brasileira v10, CN=Autoridade Certificadora do SERPRO SSLv1
4.31E+09	########	########	########	http://crlve.detran.ma.gov.br/

Autoridade Certificadora do SERPRO SSLv1

C=BR, O=ICP-Brasil, OU=Autoridade Certificadora Raiz Brasileira v10, CN=Autoridade Certificadora do SERPRO SSLv1
4.27E+09	########	########	########	Benner

Autoridade Certificadora do SERPRO SSLv1

C=BR, O=ICP-Brasil, OU=Autoridade Certificadora Raiz Brasileira v10, CN=Autoridade Certificadora do SERPRO SSLv1
4.27E+09	########	########	########	Benner

Autoridade Certificadora do SERPRO SSLv1

C=BR, O=ICP-Brasil, OU=Autoridade Certificadora Raiz Brasileira v10, CN=Autoridade Certificadora do SERPRO SSLv1
4.23E+09	########	########	########	puma.pgfn.fazenda

Autoridade Certificadora do SERPRO SSLv1

C=BR, O=ICP-Brasil, OU=Autoridade Certificadora Raiz Brasileira v10, CN=Autoridade Certificadora do SERPRO SSLv1
4.16E+09	########	########	########	discorl.bhe.serpro

Autoridade Certificadora do SERPRO SSLv1

C=BR, O=ICP-Brasil, OU=Autoridade Certificadora Raiz Brasileira v10, CN=Autoridade Certificadora do SERPRO SSLv1
4.02E+09	########	########	########	189.9.81.58

Autoridade Certificadora do SERPRO SSLv1

C=BR, O=ICP-Brasil, OU=Autoridade Certificadora Raiz Brasileira v10, CN=Autoridade Certificadora do SERPRO SSLv1
4E+09	########	########	########	TermoITR

Autoridade Certificadora do SERPRO SSLv1

C=BR, O=ICP-Brasil, OU=Autoridade Certificadora Raiz Brasileira v10, CN=Autoridade Certificadora do SERPRO SSLv1
4E+09	########	########	########	discorl.rce.serpro

Autoridade Certificadora do SERPRO SSLv1

C=BR, O=ICP-Brasil, OU=Autoridade Certificadora Raiz Brasileira v10, CN=Autoridade Certificadora do SERPRO SSLv1
4E+09	########	########	########	discorl-rst.rce.serpro

Autoridade Certificadora do SERPRO SSLv1

C=BR, O=ICP-Brasil, OU=Autoridade Certificadora Raiz Brasileira v10, CN=Autoridade Certificadora do SERPRO SSLv1
3.98E+09	########	########	########	autoriza-estaleiro

Autoridade Certificadora do SERPRO SSLv1

C=BR, O=ICP-Brasil, OU=Autoridade Certificadora Raiz Brasileira v10, CN=Autoridade Certificadora do SERPRO SSLv1
3.97E+09	########	########	########	discorl.rce.serpro

Autoridade Certificadora do SERPRO SSLv1

C=BR, O=ICP-Brasil, OU=Autoridade Certificadora Raiz Brasileira v10, CN=Autoridade Certificadora do SERPRO SSLv1
3.96E+09	########	########	########	discorl-rst.rce.serpro

Autoridade Certificadora do SERPRO SSLv1

C=BR, O=ICP-Brasil, OU=Autoridade Certificadora Raiz Brasileira v10, CN=Autoridade Certificadora do SERPRO SSLv1
3.85E+09	########	########	########	discorl.coaf

Autoridade Certificadora do SERPRO SSLv1

C=BR, O=ICP-Brasil, OU=Autoridade Certificadora Raiz Brasileira v10, CN=Autoridade Certificadora do SERPRO SSLv1

Not .br subdomain, so if they ever do 

--
You received this message because you are subscribed to the Google Groups "public" group.
To unsubscribe from this group and stop receiving emails from it, send an email to public+un...@ccadb.org.

To view this discussion on the web visit https://groups.google.com/a/ccadb.org/d/msgid/public/20221117094440.4aae752e4a288d66203affaf%40andrewayer.name.

[Kurt Seifried]

Sorry my sons cat is trying to steal my keyboard.

Not .br domain

4.34E+09

########

########

########

btgpactual.com

Autoridade Certificadora do SERPRO SSLv1

4.2E+09	########	########	########	infoconv.tce.pa

Autoridade Certificadora do SERPRO SSLv1

Also two more urls::

3998121831

2021-01-28

2021-01-28

2022-01-28

https://carneleaoweb.estaleiro.serpro.gov.br

Autoridade Certificadora do SERPRO SSLv1

3847481019	2020-12-29	2020-12-29	2021-12-29	https://spubackoffice.estaleiro.serpro.gov.br

Autoridade Certificadora do SERPRO SSLv1

[Kurt Seifried]

On Thu, Nov 17, 2022 at 9:50 AM Lucia Castelli <lucast...@gmail.com> wrote:

Would there be any other reason than "we want to become a CA"? 

We would like to be a CA with competitive characteristics in our issued certificates. 

No other reason.

What does "competitive characteristics" mean? Like do you want to be free (like letsencrypt)? Do you want to service the brazilian market in some specific way (e.g. language barriers?).

 

[Lucia Castelli]

Indeed, in the beginning we had many certificates issued erroneously and we started to monitor these certificates to eliminate such errors.

We believe that they are errors that any CA can have and that makes the process of revoking and replacing certificates, as with any other CA, that is already in the root program of Mozilla or any other root program.

Daily we receive emails from bugzilla where we can see many certificates issued by major competitors CA with errors.

We believe that there is no CA that is ready and mature to not make mistakes when starting to operate in these issuing. 

We have been trying to submit to this program for more than 2 years and we are always attentive and making efforts to do our best within compliance.

[Lucia Castelli]

"competitive characteristics" -> we mean issuance of certificates with security properties, exactly as the BR SSL requirements impose on us.

[Mike Malone]

On Thu, Nov 17, 2022 at 9:02 AM Lucia Castelli <lucast...@gmail.com> wrote:

Indeed, in the beginning we had many certificates issued erroneously and we started to monitor these certificates to eliminate such errors.

We believe that they are errors that any CA can have and that makes the process of revoking and replacing certificates, as with any other CA, that is already in the root program of Mozilla or any other root program.

Mistakes do happen, but there are simple technical mechanisms that an issuer can implement to prevent this particular mistake.

 

Daily we receive emails from bugzilla where we can see many certificates issued by major competitors CA with errors.

We believe that there is no CA that is ready and mature to not make mistakes when starting to operate in these issuing. 

We have been trying to submit to this program for more than 2 years and we are always attentive and making efforts to do our best within compliance.

What have you done to make sure this doesn't happen again?

Do you have an incident remediation process? Can you share any remediation & response artifacts (e.g., postmortems)?

Mike

[Lucia Castelli]

Currently we only issue to *.br, due to our form of validation that involves the Registro.br, but it has no restriction

[Lucia Castelli]

For each observed error, we create controls in the CA software to prevent the occurrence of these errors, in addition we are subordinate to a ROOT CA that is also pointed out about errors in our certificates. We work with CAB lint to monitor the issued certificates.

[Kurt Seifried]

Then why are there multiple errors of the same type, sometimes the exact same value, e.g. "Benner" occurring multiple times over a large span of time?

I mean a basic "is this even a domain name" vs "starts with https://" spans months. 

Also you issued certs for non br domains last year:

4337379215

2021-04-06

2021-04-06

2022-04-06

btgpactual.com

Autoridade Certificadora do SERPRO SSLv1

C=BR, O=ICP-Brasil, OU=Autoridade Certificadora Raiz Brasileira v10, CN=Autoridade Certificadora do SERPRO SSLv1

4203823298	2021-03-12	2021-03-12	2022-03-12	infoconv.tce.pa

Autoridade Certificadora do SERPRO SSLv1

C=BR, O=ICP-Brasil, OU=Autoridade Certificadora Raiz Brasileira v10, CN=Autoridade Certificadora do SERPRO SSLv1

Also the original data with dates since excel is silly and I missed the "#####" stuff:

crt.sh ID

Logged At  ⇧

Not Before

Not After

Common Name

Matching Identities

Issuer Name

3756574427

2022-01-26

2020-03-12

2032-07-01

Autoridade Certificadora do SERPRO SSLv1

Autoridade Certificadora do SERPRO SSLv1

C=BR, O=ICP-Brasil, OU=Instituto Nacional de Tecnologia da Informacao - ITI, CN=Autoridade Certificadora Raiz Brasileira v10

4554741564	2021-05-19	2021-05-19	2022-05-19	https://certificados.serpro.gov.br/arssl/

Autoridade Certificadora do SERPRO SSLv1

C=BR, O=ICP-Brasil, OU=Autoridade Certificadora Raiz Brasileira v10, CN=Autoridade Certificadora do SERPRO SSLv1

4541931304	2021-05-17	2021-05-17	2022-05-17	ccd-ct01bsa

Autoridade Certificadora do SERPRO SSLv1

C=BR, O=ICP-Brasil, OU=Autoridade Certificadora Raiz Brasileira v10, CN=Autoridade Certificadora do SERPRO SSLv1

4541264547	2021-05-17	2021-05-17	2022-05-17	ccd-ct02bsa

Autoridade Certificadora do SERPRO SSLv1

C=BR, O=ICP-Brasil, OU=Autoridade Certificadora Raiz Brasileira v10, CN=Autoridade Certificadora do SERPRO SSLv1

4453318199	2021-04-30	2021-04-30	2022-04-30	Extrato Selic - Producao

Autoridade Certificadora do SERPRO SSLv1

C=BR, O=ICP-Brasil, OU=Autoridade Certificadora Raiz Brasileira v10, CN=Autoridade Certificadora do SERPRO SSLv1

4448357444	2021-04-29	2021-04-29	2022-04-29	flexa.pgfn.fazenda

Autoridade Certificadora do SERPRO SSLv1

C=BR, O=ICP-Brasil, OU=Autoridade Certificadora Raiz Brasileira v10, CN=Autoridade Certificadora do SERPRO SSLv1

4415391045	2021-04-22	2021-04-22	2022-04-22	sgconf.rfoc.srf

Autoridade Certificadora do SERPRO SSLv1

C=BR, O=ICP-Brasil, OU=Autoridade Certificadora Raiz Brasileira v10, CN=Autoridade Certificadora do SERPRO SSLv1

4411160619	2021-04-21	2021-04-21	2022-04-21	SEGES-171379.mp.intra

Autoridade Certificadora do SERPRO SSLv1

C=BR, O=ICP-Brasil, OU=Autoridade Certificadora Raiz Brasileira v10, CN=Autoridade Certificadora do SERPRO SSLv1

4385268647	2021-04-16	2021-04-16	2022-04-16	ibmwebspheremqsefazsc

Autoridade Certificadora do SERPRO SSLv1

C=BR, O=ICP-Brasil, OU=Autoridade Certificadora Raiz Brasileira v10, CN=Autoridade Certificadora do SERPRO SSLv1

4374011657	2021-04-14	2021-04-14	2022-04-14	https://hom-carneleaoweb.estaleiro.serpro.gov.br/carneleao/

Autoridade Certificadora do SERPRO SSLv1

C=BR, O=ICP-Brasil, OU=Autoridade Certificadora Raiz Brasileira v10, CN=Autoridade Certificadora do SERPRO SSLv1

4345805063	2021-04-08	2021-04-08	2022-04-08	https://consopt.www8.receita.fazenda.gov.br/consultaoptantes

Autoridade Certificadora do SERPRO SSLv1

C=BR, O=ICP-Brasil, OU=Autoridade Certificadora Raiz Brasileira v10, CN=Autoridade Certificadora do SERPRO SSLv1

4306083475	2021-03-31	2021-03-31	2022-03-31	http://confucius.hcpa.edu.br/

Autoridade Certificadora do SERPRO SSLv1

C=BR, O=ICP-Brasil, OU=Autoridade Certificadora Raiz Brasileira v10, CN=Autoridade Certificadora do SERPRO SSLv1

4305829154	2021-03-31	2021-03-31	2022-03-31	http://crlve.detran.ma.gov.br/

Autoridade Certificadora do SERPRO SSLv1

C=BR, O=ICP-Brasil, OU=Autoridade Certificadora Raiz Brasileira v10, CN=Autoridade Certificadora do SERPRO SSLv1

4272875230	2021-03-25	2021-03-25	2022-03-25	Benner

Autoridade Certificadora do SERPRO SSLv1

C=BR, O=ICP-Brasil, OU=Autoridade Certificadora Raiz Brasileira v10, CN=Autoridade Certificadora do SERPRO SSLv1

4267330157	2021-03-24	2021-03-24	2022-03-24	Benner

Autoridade Certificadora do SERPRO SSLv1

C=BR, O=ICP-Brasil, OU=Autoridade Certificadora Raiz Brasileira v10, CN=Autoridade Certificadora do SERPRO SSLv1

4225132514	2021-03-16	2021-03-16	2022-03-16	puma.pgfn.fazenda

Autoridade Certificadora do SERPRO SSLv1

C=BR, O=ICP-Brasil, OU=Autoridade Certificadora Raiz Brasileira v10, CN=Autoridade Certificadora do SERPRO SSLv1

4162997747	2021-03-04	2021-03-04	2022-03-04	discorl.bhe.serpro

Autoridade Certificadora do SERPRO SSLv1

C=BR, O=ICP-Brasil, OU=Autoridade Certificadora Raiz Brasileira v10, CN=Autoridade Certificadora do SERPRO SSLv1

4020518938	2021-02-02	2021-02-02	2022-02-02	189.9.81.58

Autoridade Certificadora do SERPRO SSLv1

C=BR, O=ICP-Brasil, OU=Autoridade Certificadora Raiz Brasileira v10, CN=Autoridade Certificadora do SERPRO SSLv1

4003932904	2021-01-30	2021-01-30	2022-01-30	TermoITR

Autoridade Certificadora do SERPRO SSLv1

C=BR, O=ICP-Brasil, OU=Autoridade Certificadora Raiz Brasileira v10, CN=Autoridade Certificadora do SERPRO SSLv1

3995565484	2021-01-28	2021-01-28	2022-01-28	discorl.rce.serpro

Autoridade Certificadora do SERPRO SSLv1

C=BR, O=ICP-Brasil, OU=Autoridade Certificadora Raiz Brasileira v10, CN=Autoridade Certificadora do SERPRO SSLv1

3995298864	2021-01-28	2021-01-28	2022-01-28	discorl-rst.rce.serpro

Autoridade Certificadora do SERPRO SSLv1

C=BR, O=ICP-Brasil, OU=Autoridade Certificadora Raiz Brasileira v10, CN=Autoridade Certificadora do SERPRO SSLv1

3982843217	2021-01-26	2021-01-26	2022-01-26	autoriza-estaleiro

Autoridade Certificadora do SERPRO SSLv1

C=BR, O=ICP-Brasil, OU=Autoridade Certificadora Raiz Brasileira v10, CN=Autoridade Certificadora do SERPRO SSLv1

3967003223	2021-01-22	2021-01-22	2021-01-23	discorl.rce.serpro

Autoridade Certificadora do SERPRO SSLv1

C=BR, O=ICP-Brasil, OU=Autoridade Certificadora Raiz Brasileira v10, CN=Autoridade Certificadora do SERPRO SSLv1

3961758343	2021-01-21	2021-01-21	2021-01-22	discorl-rst.rce.serpro

Autoridade Certificadora do SERPRO SSLv1

C=BR, O=ICP-Brasil, OU=Autoridade Certificadora Raiz Brasileira v10, CN=Autoridade Certificadora do SERPRO SSLv1

3852508782	2020-12-30	2020-12-30	2021-12-30	discorl.coaf

Autoridade Certificadora do SERPRO SSLv1

C=BR, O=ICP-Brasil, OU=Autoridade Certificadora Raiz Brasileira v10, CN=Autoridade Certificadora do SERPRO SSLv1

--
You received this message because you are subscribed to the Google Groups "public" group.
To unsubscribe from this group and stop receiving emails from it, send an email to public+un...@ccadb.org.

To view this discussion on the web visit https://groups.google.com/a/ccadb.org/d/msgid/public/dc6a28f4-0a68-4a94-bbec-266e3fd31d9dn%40ccadb.org.

[Lucia Castelli]

Currently we only issue to *.br, due to our form of validation that involves the Registro.br, but It has no restriction.

[Cynthia Revström]

Hi,

I am replying to the initial email just due to the branching threads but consider this as a response to all replies as of 2022-11-22 02:00 UTC.

Based on the issues reported by Kurt, Andrew, and Mike and the subsequent replies by Lucia, I would consider it very inappropriate for Mozilla to accept this request.

My issues/concerns with the request are the following:

1. There are very recent issues with the SANs that are so basic that I don't know how they could ever occur.

Issuing certificates for non-existing domains clearly can't have passed any actual domain validation procedure.

I can't comprehend what kind of system would issue a certificate with a URL as a domain in the SAN.

To me that feels like this is not just a small issue but a fundamentally broken system that likely just issues a certificate to whatever string was provided without any validation whatsoever.

2. To me it is very unclear what is meant by "Currently we only issue to *.br, due to our form of validation that involves the Registro.br, but it has no restriction".

Lucia, could you clarify what is meant by this?

3. There seemingly isn't a reason for this request beyond simply wanting to become a CA. (As clarified by Lucia)

I will say that I have not yet read any of the supporting documents but I can't see how that could possibly change the situation in SERPRO's favor enough to overcome the SAN issue.

I fully agree with Andrew's conclusion:

> This is clearly not a mature CA and no root program should include it.

-Cynthia

[Jeroen Ruigrok van der Werven]

Dear Lucia et al,

On Thursday, 17 November 2022 at 19:07:53 UTC+1 Lucia Castelli wrote:

Currently we only issue to *.br, due to our form of validation that involves the Registro.br, but It has no restriction.

I understand from Brazilians I spoke to that SERPRO is a needed certificate issuer for various Brazilian governmental services Brazilians have to use, including tax revenue services. And right now they need to manually install these CA certificates themselves. Is this correct?

I notice that there has not been a follow-up from your side to the questions and concerns raised by Kurt and others in over at least a week. Given this is only a 6-week process for public discussion period, I am worried about this lack of response from a CA. Especially given Ben's initial email stating that "[..] a representative of SERPRO must promptly respond directly in the discussion thread to all questions that are posted."

While a glance at the crt.sh overview gives me an impression that your process might have improved somewhat in recent times, I have strong doubts about the suitability of SERPRO as a mature CA for default inclusion at this time for a number of reasons:

  - There has, so far, not been any clarification given how the processes have been adjusted accordingly to stop the issuing of certificates that are not URLs, IP addresses, a certificate issued for a different country TLD domain or other non-valid domains.

  - The various *.serpro domains issued in the past make me wonder just how well internal and external CA responsibilities and processes have been separated from one another, given that they are leaking onto the internet.

  - It is good to see that the various misissued certificates are revoked, however for many it took many months before the problem was noticed and acted upon. This again makes me wonder about both first and second line processes/controls. It is fully understandable if a mistake is made. None of us are perfect and we keep iterating on our processes to improve them. However, whenever I deal with mistakes in line of my own work, whether they are certificates or something else, I will look at the mistake and double check recent work for similar of such mistakes. When I see a URL being issued and then revoked a month later. And then spot another one, issued in the same month, but being revoked 4 months later I can only wonder why no automated process was kicked off to identify similar issues with your certificates. Even if it was the rough equivalent of an "openssl x509 -noout -subject -in <cert> | grep http" of all certificates.

Jeroen Ruigrok van der Werven

[Lucia Castelli]

All,

First, would like to say that we stoped to answer the questions, because at  November was introduced another subject in that Public List, that was different about SERPRO SSL CA. 

Bellow we answer all the outstanding questions:

SERPRO SSLCA is subject to the Brazilian Public Key Infrastructure (ICP-Brasil) and the rules in force in ICP-Brasil.

At the time of issuing these certificates, the SAN extension should contain other names in addition to the 'dnsName' and 'ipaddress' entries '. 

Once this requirement was understood, ICP-Brasil changed its certification policies and aligned them with the webtrust requirement. With this decision, the SERPRO SSL CA software was adjusted and the situation no longer occurred. 

 After the completion of the correction (revocation of certificates), we also publish it in our bugzilla: https://bugzilla.mozilla.org/show_bug.cgi?id=1677631#c80 

 From that moment on, we started to include a weekly CACHECKER in our CA to eliminate other errors, which we still do till today. 

 There were other notes by CACHECKER that we were requesting answers in bugzilla, among them, about an EV CERTIFICATE note that was issued with error. 

We do not issue EV CERTIFICATES only OV CERTIFICATES. https://bugzilla.mozilla.org/show_bug.cgi?id=1677631#c60 

 Then we received the response from Mozilla support pointing out that the error was in the updated CACHECKER: https://bugzilla.mozilla.org/show_bug.cgi?id=1677631#c65 

 Recently an error was pointed out(again) in EV certificates (which we do not issue) and in contact with Mozilla support, they verified that there is still an error in the CACHECKER that is showing false errors in our certificates. 

All can verify other comments in our bugzilla and the treatments that we have always given to everyone, that is, demonstration of responsibility with the issuance of certificates that are so vulnerable and that all CAs, which are part of these programs, must be attentive. 

All the notes already made here in this public list are just copied and pasted from a CACHECKER result, but do not demonstrate that they were verified, that they are certificates issued previously and that they have already been revoked, that is, there has already been a treatment. 

The motivation for joining the trusted roots program is the possibility of issuing certificates with international recognition that are also in line with Brazilian policies and practices,  maintaining compliance with international standards and observing national needs.

Currently SSL certificates are already issued at  SERPRO SSL CA, not yet recognized,  which imposes on end users to encounter messages from an unsafe site, leaving users with two possible approaches: include the CA as trusted or add a security exception; in both cases, we consider end-user security to be harmful practices.

In this way, the inclusion of SERPRO SSL CA  in the trusted root programs will increase the security of our end users.

SERPRO is the largest public IT company in the world and provider digital solutions for the Brazilian state and the international market (www.sepro.gov.br). 

Regarding the use of a named-constraints to restrict .br domains only, we issue certificates to governments and also to national and international private entities that wish to have a certificate within the Brazilian public key infrastructure. Therefore, we do not consider the use of any named-constraint appropriate. 

Anyway, the criticisms were pointed out and were not evaluated as the CA has already responded promptly to all errors. 

The maturity of the CA and any one that is already part of a root program, was exactly as it was written earlier: mistakes everyone can make and the fact of quantity and lack of quality, all were mistakes already corrected. 

It was also mentioned that our CP or CPS was not read, which may not facilitate the purpose of our CA by someone here on this list. 

We would also like to add how we are a CA that holds the ISO/IEC 27001 and 27701 certification seals. 

All CAs that produce within SERPRO,  except the one that issues an SSL certificate in accordance with BRSSL, have existed within the company for more than 20 years, that is, we are not a company wanting to experiment and only with the intention of selling certificates poor quality and non-compliant. 

Lucia Castelli

[Hubert Chao]

On Fri, Dec 2, 2022 at 7:23 AM Lucia Castelli <lucast...@gmail.com> wrote:

All,

First, would like to say that we stoped to answer the questions, because at  November was introduced another subject in that Public List, that was different about SERPRO SSL CA. 

Bellow we answer all the outstanding questions:

SERPRO SSLCA is subject to the Brazilian Public Key Infrastructure (ICP-Brasil) and the rules in force in ICP-Brasil.

What happens in the case that there is conflict between Root Program requirements and the rules in force in ICP-Brasil?

/hubert

 

[Lucia Castelli]

Hi Hubert,

After the question, the baseline requirements SSL, have priorities over the regulations of ICP-Brasil, even ICP-Brasil itself declares this priority in the regulations currently.

Thank you.

Lucia

[Prof. Reardon]

Hello all:

There is also this cert for infoconv.sicredi.io: https://crt.sh/?id=6202101964
If I'm reading this right it expires in 2023 and is also not .br. It is for the
organization BANCO COOPERATIVO SICREDI - S/A. The domain doesn't work for me
though. The real bank seems to be hosted at: sicredi.com.br but also looks like
it is called Banco Cooperativo Sicredi SA. I'm new to this: does this mean it is
more than an DV cert if something is listed here, as in the presence of an
organization imply an OV or EV cert? I looked at a few Let's Encrypt certs and
couldn't find any organization listed on them, just common name. So if this a
OV/EV cert and its not actually the bank's domain it is rather concerning.

Thanks,
Joel Reardon

[Lucia Castelli]

Hello Mr Joel,

Like I wrote before, our CA,  we do not issue EV CERTIFICATES only OV CERTIFICATES. Regarding the use of a named-constraints to restrict .br domains only, we issue certificates to governments and also to national and international private entities that wish to have a certificate within the Brazilian public key infrastructure. 

Lucia Castelli

[Charles Reiss]

1. The WebTrust audit for period ending 29 May 2022 states:

"SERPRO-CA makes use of external registration authorities for specific subscriber registration activities as disclosed in SERPRO-CA’s business practices. Our procedures did not extend to the controls exercised by these external registration authorities."

But section 1.3.2 of the CPS seems to only mention an internal RA. What external RAs is the audit statement referring to?

2. The period of time audit for May 2020-2021 appears to be at https://repositorio.serpro.gov.br/docs/auditoria/02_-_AC_SERPRO_SSL_Webtrust_BR_SSL_and_Network_Security_-_Period_of_Time_Audit_Report.pdf . In this audit the malformed SANs others have found are noted and the management's assertions state that SERPRO "started the certificate revocation process, with subsequent re-issuance, a process that is in progress" in a statement dated 25 August 2021. The CRL for the "Autoridade Certificadora do SERPRO SSLv1" subCA appears to have timestamps well into September for when these certificates are actually revoked (for example, https://crt.sh/?id=4541931304 has revocation timestamped 9 September). This seems to violate the 24-hour timeline expected in the BRs and SERPRO's CPS for revocation once SERPRO becomes aware certificates were issued in error.

[passerby184]

while its just a nameing thing and unrelated to actuall crypto, isn't SSL deprecated like 2015?
and certificate they cross-signed this https://crt.sh/?id=3396721343 (which already trusted by MS, and have handful of CAs under that) i wonder why they are not try to include that instead of this?

2022년 12월 7일 수요일 오전 3시 0분 40초 UTC+9에 Charles Reiss님이 작성:

[Lucia Castelli]

Hi Charles,

Answers:

1 - The external registration authorities that are mentioned are the ones that were later linked to CA SERPRO SSL.

At the beginning of the CA, during the point in time and period of time audit, we only used the SERPRO(AR SERPRO) registration authority(internal registration authority).

About the CPS,  I will be updating immediatly it and publishing it on the CCADB and on our CA page.

2 - As I explained earlier, we had problems with the SAN of all these certificates, alerted by Mozilla to our Root CA, as the Root CA rules overlapped the BR SSL rules.

Unfortunately, due to the very large number of certificates, it was not possible to fulfill what is expected(24 hours timeline), both from the BR SSL regulations and what we reflect in our regulations (CPS).

These revocations, unfortunately, lasted much longer than expected.

We understand that we would not, yet, be infringing the rules, because our certificate is not in the Mozilla program.

[Lucia Castelli]

At first, when we signed up for the CCADB, we understood that for accreditation it would be for ALL root programs (Mozilla, Chrome, Apple) and that in addition to registering for the CCADB we should also participate in each of the programs.

[Prof. Reardon]

Hello:

regarding this:

 

2 - As I explained earlier, we had problems with the SAN of all these certificates, alerted by Mozilla to our Root CA, as the Root CA rules overlapped the BR SSL rules.

Unfortunately, due to the very large number of certificates, it was not possible to fulfill what is expected(24 hours timeline), both from the BR SSL regulations and what we reflect in our regulations (CPS).

These revocations, unfortunately, lasted much longer than expected.

We understand that we would not, yet, be infringing the rules, because our certificate is not in the Mozilla program.

I suppose my question is what specific operational changes have been made on your side since then so that the inability to fulfill the baseline requirements won't remain an issue were you to be part of Mozilla's program?

 

[Lucia Castelli]

Now I understand better. Thanks for rephrasing the question.
What happened was that we started using the CACHECKER "first" instead of waiting for the Root CA to be alerted to wrong certificates. 

We always aim to only use CA SSL/TLS software in compliance with BR SSL requirements. 

We understand that we need to respect the rules about the time for revocation, and we started intensify this issue even more if we are accepted in root programs. 

Well, as I read the bugzillas daily, I see that even today there are still CAs, that are in the program, and also have problems, keeping the revocation time within the rules.
We assume that we have rules to resolve issues and not remain impartial.

Thanks about your question.l

[Cynthia Revström]

Hi Lucia,

Sorry if I am misunderstanding, but are you saying that you will start adhering to the policies if/when you are accepted into root programs?

I don't think that is a good way of getting the root stores and relying parties to want you included.

You need to first show that you are a properly run CA before you get accepted.

Accepting you based on a promise that you will do better once accepted is not really a good way to do this.

Secondly, I get that you want to sell certificates to entities outside of the Brazilian public administration but I still don't understand what additional value you would bring, could you clarify that?

I have read the statement in the Quantifying Value document but it still don't quite understand the point.

I will admit that I don't know much about the WebPKI situation in Brazil, so maybe there are problems there currently for all I know.

Are there a lot of Brazilian websites that don't have HTTPS using a cert issued by one of the CAs currently trusted by Mozilla?

-Cynthia

--

You received this message because you are subscribed to the Google Groups "public" group.
To unsubscribe from this group and stop receiving emails from it, send an email to public+un...@ccadb.org.

To view this discussion on the web visit https://groups.google.com/a/ccadb.org/d/msgid/public/63ca387d-fcd3-44b3-9838-fdca227134f6n%40ccadb.org.

[Kurt Seifried]

On Thu, Dec 8, 2022 at 7:57 AM Lucia Castelli <lucast...@gmail.com> wrote:

Now I understand better. Thanks for rephrasing the question.
What happened was that we started using the CACHECKER "first" instead of waiting for the Root CA to be alerted to wrong certificates. 

We always aim to only use CA SSL/TLS software in compliance with BR SSL requirements. 

1) What is CACHECKER exactly (a service? software?)

2) How were you validating control of the DNS domains if you weren't ensuring you were only issuing certificates to DNS names? Because you issued many certificates to urls, single names and so on spanning months. 

 

We understand that we need to respect the rules about the time for revocation, and we started intensify this issue even more if we are accepted in root programs. 

Well, as I read the bugzillas daily, I see that even today there are still CAs, that are in the program, and also have problems, keeping the revocation time within the rules.

So to confirm: you're promising to do better once accepted into the root program? But you're not willing to show that you can and will do this prior to being accepted?

 

We assume that we have rules to resolve issues and not remain impartial.

Thanks about your question.l

Em quinta-feira, 8 de dezembro de 2022 às 11:48:38 UTC-3, joel.r...@ucalgary.ca escreveu:

Hello:

regarding this:

 

2 - As I explained earlier, we had problems with the SAN of all these certificates, alerted by Mozilla to our Root CA, as the Root CA rules overlapped the BR SSL rules.

Unfortunately, due to the very large number of certificates, it was not possible to fulfill what is expected(24 hours timeline), both from the BR SSL regulations and what we reflect in our regulations (CPS).

These revocations, unfortunately, lasted much longer than expected.

We understand that we would not, yet, be infringing the rules, because our certificate is not in the Mozilla program.

I suppose my question is what specific operational changes have been made on your side since then so that the inability to fulfill the baseline requirements won't remain an issue were you to be part of Mozilla's program?

 

--

You received this message because you are subscribed to the Google Groups "public" group.
To unsubscribe from this group and stop receiving emails from it, send an email to public+un...@ccadb.org.
To view this discussion on the web visit https://groups.google.com/a/ccadb.org/d/msgid/public/63ca387d-fcd3-44b3-9838-fdca227134f6n%40ccadb.org.

[Lucia Castelli]

Hi, That's not what I tried to explain. We are already adhering to the rules of BR SSL.

We have implemented all the controls required in the policies, the problems that occurred have all been corrected and that we have no non-conformities in the certificates that are active,   we are not waiting to be accepted into the root program to start initiating any rules. They are already in our CA.

You can check the annual results of our external audit.

About what added value AC SERPRO brings is that SERPRO is the largest public IT company in Latin America and that government bodies trust it to guarantee their security, we issue certificates to bodies such as the presidency of the republic and tax authorities, government agencies that wish to maintain the security of their information in the custody of the public administration.

There are no Brazilian CAs, but international ones, which sell their certificates in Brazil, but we need to have a Brazilian CA that is part of the root program to bring security and reliability.

Thanks,

[Lucia Castelli]

1. CA CHECKER:  

   CA Checker is a public use tool for CA Mis-issuance Checker;

2. How were you validating control of the DNS domains if you weren't ensuring you were only issuing certificates to DNS names?  

The issuance of certificates with names that were not DNS would occur, because before we submitted our CA to the root programs there was a usage scenario where web applications authenticated their APIs using the application name as identified and not a DNS, but when adhering to the webtrust requirements, we have eliminated this practice and now the CA software itself verifies that the content is a valid DNS before certificate issuance.

3. So to confirm: you're promising to do better once accepted into the root program? But you're not willing to show that you can and will do this prior to being accepted? 

That's not what I tried to explain. We are already adhering to the rules of BR SSL. 

We have implemented all the controls required in the policies, the problems that occurred have all been corrected and that we have no non-conformities in the certificates that are active,   we are not waiting to be accepted into the root program to start initiating any rules. They are already in our CA. 

You can check the annual results of our external audit. 

Em quinta-feira, 8 de dezembro de 2022 às 14:21:15 UTC-3, ku...@seifried.org escreveu:

On Thu, Dec 8, 2022 at 7:57 AM Lucia Castelli <lucast...@gmail.com> wrote:

Now I understand better. Thanks for rephrasing the question.
What happened was that we started using the CACHECKER "first" instead of waiting for the Root CA to be alerted to wrong certificates. 

We always aim to only use CA SSL/TLS software in compliance with BR SSL requirements. 

1) What is CACHECKER exactly (a service? software?)

2) How were you validating control of the DNS domains if you weren't ensuring you were only issuing certificates to DNS names? Because you issued many certificates to urls, single names and so on spanning months. 

 

We understand that we need to respect the rules about the time for revocation, and we started intensify this issue even more if we are accepted in root programs. 

Well, as I read the bugzillas daily, I see that even today there are still CAs, that are in the program, and also have problems, keeping the revocation time within the rules.

So to confirm: you're promising to do better once accepted into the root program? But you're not willing to show that you can and will do this prior to being accepted?

Thanks 

[Rob Stradling]

> 1) What is CACHECKER exactly (a service? software?)

Hi Kurt.

An instance of the service is at https://cachecker-dot-ccadb-231121.appspot.com/.

Source code is at https://github.com/mozilla/CCADB-Tools/tree/master/cacheck, AIUI.

It's an alternative web UI for viewing crt.sh's cached certificate linting results.  Whereas the crt.sh web UI currently only considers each CA (Name/Key) separately, CACHECKER is able to iterate through all of the Sub-CAs, Sub-Sub-CAs, etc below the target CA, and then summarize all of the linting issues in one table.

---

From: 'Kurt Seifried' via public <pub...@ccadb.org>
Sent: 08 December 2022 17:20
To: Lucia Castelli <lucast...@gmail.com>
Cc: public <pub...@ccadb.org>; joel.r...@ucalgary.ca <joel.r...@ucalgary.ca>; Charles Reiss <wogg...@gmail.com>; bwi...@mozilla.com <bwi...@mozilla.com>
Subject: Re: Public Discussion of SERPRO's CA Inclusion Request

 

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.

To view this discussion on the web visit https://groups.google.com/a/ccadb.org/d/msgid/public/CABqVa39KWyBW1EEdV1KMbk4TmKOj%3D1ob2zjiW45269O2cfdiLw%40mail.gmail.com.

[Kurt Seifried]

On Thu, Dec 8, 2022 at 12:46 PM Rob Stradling <r...@sectigo.com> wrote:

> 1) What is CACHECKER exactly (a service? software?)

Hi Kurt.

An instance of the service is at https://cachecker-dot-ccadb-231121.appspot.com/.

Source code is at https://github.com/mozilla/CCADB-Tools/tree/master/cacheck, AIUI.

Can you confirm if you run your own instance or rely upon a public instance?

[Lucia Castelli]

Q: I suppose my question is what specific operational changes have been made on your side since then so that the inability to fulfill the baseline requirements won't remain an issue were you to be part of Mozilla's program?

Mr Kurt, as I explained earlier, the wrong emissions were initial, the rules for us were from ICP-Brasil. 

After the incident, it was also clear to the RAIZ CA that we should just follow the BR SSL rules for SERPRO SSL CA.

So we've made the necessary tweaks to the CA software for that.

Since then, we have continued to carry out matching emissions within the BR SSL rules.
In addition, as previously written, we use Cachecker to help us make immediate analyzes if we are infringing any BR SSL rule and, if necessary, adjust the CA software. 

We understand that the improvement process is continuous.

Em quinta-feira, 8 de dezembro de 2022 às 14:21:15 UTC-3, ku...@seifried.org escreveu:

[Rob Stradling]

> Can you confirm if you run your own instance or rely upon a public instance?

I don't run any instances of CACHECKER.  AIUI, someone at Mozilla built that tool, and the instance at https://cachecker-dot-ccadb-231121.appspot.com/ is operated by Mozilla.

CACHECKER relies on the public crt.sh database, which I built, and which is operated by my employer (Sectigo).

---

From: 'Kurt Seifried' via public <pub...@ccadb.org>

Sent: 09 December 2022 03:52
To: Rob Stradling <r...@sectigo.com>
Cc: public <pub...@ccadb.org>; joel.r...@ucalgary.ca <joel.r...@ucalgary.ca>; Charles Reiss <wogg...@gmail.com>; bwi...@mozilla.com <bwi...@mozilla.com>; Lucia Castelli <lucast...@gmail.com>

To view this discussion on the web visit https://groups.google.com/a/ccadb.org/d/msgid/public/CABqVa38qGs%3DcjQQGNodW1ssy%2BStsJupQ1Hxp4-v-iF6U%2BmRi4Q%40mail.gmail.com.

[Lucia Castelli]

Hi

We run on a public instance. We inform our CA ID in the option of "CA issuance investigator Query Settings" as well as choosing the other options available in the tool.

Thanks

[Charles Reiss]

On Wednesday, December 7, 2022 at 2:40:23 PM UTC-5 Lucia Castelli wrote:

Hi Charles,

Answers:

1 - The external registration authorities that are mentioned are the ones that were later linked to CA SERPRO SSL.

At the beginning of the CA, during the point in time and period of time audit, we only used the SERPRO(AR SERPRO) registration authority(internal registration authority)

Does SERPRO expect to use external registration authorities in the near future? If so, what identity validation tasks will they perform? Where are the procedures for them documented?

- Charles Reiss

 

[Lucia Castelli]

Does SERPRO expect to use external registration authorities in the near future? 

  Currently we already use external registration authorities. 

  What identity validation tasks will they perform? Where are the procedures for them documented? 

  Each RA, which issues CA SERPRO SSL certificates, uses specific operating procedures. 

  For each RA associated with CA, specific training was carried out and validators specialized in this type of issue were trained. 

  We carry out the checks provided for in BR SSL, such as validating the domain following the item: 3.2.2.4.2 and 3.2.2.4.18, in addition to  searching the URL, which we look for through the google transparency report (https://transparencyreport. google.com/safe-browsing/search?url= ). 

  If the search returns a message that SOME NOT secure content WAS found, the requester is informed that it will not be possible to issue the certificate for the URL in question until this situation is resolved. We also make the query using the WHOis tool (https://registro.br/tecnologia/ferramentas/whois/ ). This query aims to verify: 

  a) which organization is responsible for the domain with Registro.Br; 

  b) which person or which area of the organization is registered as responsible for the domain.

  There are conditions to follow the approval, that is, if the requester is the same as responsible for the domain or if the name and e-mail constant in the request also match what appears in the domain. 

For domains other than .br, we use the link https://who.is/ with the same criteria mentioned above. 

  We also validate whether the requester has management of the request address (URL) 

  Obs. 1: This requirement shows that the requester has management (control) over the request address (URL). This evidence is automatically confirmed by the CA software. 

  Obs. 2: The customer/applicant, right after the request in the CA software, receives the instructions in his e-mail on how to proceed to carry out this test of control as foreseen in the operational procedure. 

  All of these procedures are carried out at the time of requesting the certificate, including the CA software automatically validating the proof of control, in addition to validating the applicant's possession and the company's and applicant's documents. 

  In addition to verifying the certificates issued by the CA, we also follow the rule provided for in BR SSL, to perform a self-audit of three percent of the Certificates issued by the CA, on a quarterly basis. 

[Andrew Ayer]

On Mon, 12 Dec 2022 11:08:36 -0800 (PST)
Lucia Castelli <lucast...@gmail.com> wrote:

> For domains other than .br, we use the link https://who.is/ with the
> same criteria mentioned above.

Could you clarify what you use https://who.is/ for? Is it to determine
the Domain Contact for domain validation method 3.2.2.4.2?

Regards,
Andrew

[Lucia Castelli]

This query aims to verify

a) which organization is responsible for the domain with Registro.br or non-br;

b) which person or which area of ​​the organization is registered as responsible for the

domain. We also use option 3.2.2.4.2 for domain validation.

[Kurt Seifried]

On Mon, Dec 12, 2022 at 1:00 PM Lucia Castelli <lucast...@gmail.com> wrote:

This query aims to verify
a) which organization is responsible for the domain with Registro.br or non-br;
b) which person or which area of the organization is registered as responsible for the
domain. We also use option 3.2.2.4.2 for domain validation.

Why are you using  https://who.is/ instead of running your own whois query server (e.g. a linux box with jwhois)? Do you have a contract or some agreement with who.is? I tried finding their contact/legal information and all their website lists is whod...@gmail.com so it's not clear who/what entity is behind this website (e.g. can I pay them to change WHOIS info they serve so I can buy a certificate for a website I don't in fact control?).

 

Em segunda-feira, 12 de dezembro de 2022 às 16:46:13 UTC-3, Andrew Ayer escreveu:

On Mon, 12 Dec 2022 11:08:36 -0800 (PST)
Lucia Castelli <lucast...@gmail.com> wrote:

> For domains other than .br, we use the link https://who.is/ with the
> same criteria mentioned above.

Could you clarify what you use https://who.is/ for? Is it to determine
the Domain Contact for domain validation method 3.2.2.4.2?

Regards,
Andrew

--

You received this message because you are subscribed to the Google Groups "public" group.
To unsubscribe from this group and stop receiving emails from it, send an email to public+un...@ccadb.org.

To view this discussion on the web visit https://groups.google.com/a/ccadb.org/d/msgid/public/94bff8df-364d-4a23-899c-069547be3509n%40ccadb.org.

[Joel Reardon]

who.is does "not warrant that our services will meet your requirements, or that the services will be uninterrupted, timely, secure or error free" nor do they "make any warranty as to the results obtained from the use of the services or as to the accuracy or reliability of any information obtained through our services."

In my view this is not a serious way to do organization validation.

[Kurt Seifried]

To go meta for a moment, @kwilson/bwilson do we have any idea what services other CA's are relying upon to do validation that may have problems similar to this? 

Ironically this is an area I've been looking into as part of my work at the CloudSecurityAlliance, e.g. 

https://github.com/kurtseifried/wardley-maps/blob/main/cloud/Creating%20cloud%20services.wm

[Ben Wilson]

All,

Forking this side discussion with its own subject line.

Here is what we say about WHOIS -

https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#WHOIS_and_DNS.

This was likely written before the detailed provisions of section 3.2.2.4 of the Baseline Requirements. Any suggestions to improve this will be appreciated.

Thanks,

Ben

To view this discussion on the web visit https://groups.google.com/a/ccadb.org/d/msgid/public/CABqVa3-7gaZQd36nz%3DqQ%3D0enEqSyC4Tw%3Did96uFFiGK7kPEH9g%40mail.gmail.com.

[Kurt Seifried]

Ok a quick refresher on WHOIS since a lot has changed since https://www.rfc-editor.org/rfc/rfc3912.html was published in 2004:

Lots of places still support WHOIS. AFAIK none support SSL/TLS, hopefully they use DNSSEC for the domain but this still allows BGP hijacking as mentioned in the Mozilla docs.

Lots of places don't support WHOIS, it's old, it's a pain, and they have a website, so you can use their website to search for WHOIS records.

AFAIK almost everyone modern does private DNS registrations now, in fact, many DNS registrars make it the default (e.g. Cloudflare).

Is there a list of official sources for WHOIS for all the domains? I can't find anything remotely up to date with all the new TLDs.

Perhaps it is time to consider retiring this method? It seems prone to error and unreliable, and there are better ways to do this (ACME yo).

 

[Matthias Merkel]

ICANN provides a central lookup service for RDAP (the more modern replacement for Whois) at https://lookup.icann.org/. The lookups are made client side. It supports all gTLDs and some of the more popular ccTLDs.

To view this discussion on the web visit https://groups.google.com/a/ccadb.org/d/msgid/public/CABqVa39o4%2BYmecxVxeA46kw%2BvpcqLqF%3DUsCKTzqaAtz9iYT7pg%40mail.gmail.com.

[Job Snijders]

Hi all,

I second Matthias suggestion of RDAP;

Other benefits of RDAP: the data schemas are IETF standardised (making machine reading easier), there is a solid referral mechanism to find the authoritative source for a given query, and most RDAP servers offer access over TLS. 

https://github.com/arineng/nicinfo

https://github.com/openrdap/rdap

https://github.com/meeb/whoisit

It would be good to consider RDAP the primary mechanism and only fall back to using WHOIS if RDAP isn’t available.

Kind regards,

Job

To view this discussion on the web visit https://groups.google.com/a/ccadb.org/d/msgid/public/CAKtZuQ6Oc9-SpDFFfujATvDXCFWoGLsnGmtEkaGuQiARQOLTLA%40mail.gmail.com.

[André Silva]

Hi all,

I work in the same department as Lúcia at Serpro. 

Just to clarify this point we already use primary RDAP protocol (when Lúcia previously answeared "including the CA software automatically validating the proof of control") this is exactly the first step the System do to get information for proceduring to the Validation of Domain Authorization or Control, and than next it starts the steps described in section 3.2.2.4 in the Baseline Requirements.

Best regards,

André

[Jeffrey Walton]

On Tue, Dec 13, 2022 at 1:18 AM 'Kurt Seifried' via public <pub...@ccadb.org> wrote:

Ok a quick refresher on WHOIS since a lot has changed since https://www.rfc-editor.org/rfc/rfc3912.html was published in 2004:

Lots of places still support WHOIS. AFAIK none support SSL/TLS, hopefully they use DNSSEC for the domain but this still allows BGP hijacking as mentioned in the Mozilla docs.

Lots of places don't support WHOIS, it's old, it's a pain, and they have a website, so you can use their website to search for WHOIS records.

One small comment about this... A website lookup may not be equivalent to an old WHOIS lookup. Legal risk can be shuffled away from the operator for a website lookup (assuming a properly executed ToS). Shifting risk away from the operator is a disincentive for the operator to provide the service, provide accurate information, or even follow ICANN contractual obligations.

AFAIK almost everyone modern does private DNS registrations now, in fact, many DNS registrars make it the default (e.g. Cloudflare).

Is there a list of official sources for WHOIS for all the domains? I can't find anything remotely up to date with all the new TLDs.

Perhaps it is time to consider retiring this method? It seems prone to error and unreliable, and there are better ways to do this (ACME yo).

Jeff

[Andrew Ayer]

On Mon, 12 Dec 2022 12:00:22 -0800 (PST)
Lucia Castelli <lucast...@gmail.com> wrote:

> This query aims to verify
> a) which organization is responsible for the domain with Registro.br
> or non-br;
> b) which person or which area of ​​the organization is registered as
> responsible for the
> domain. We also use option 3.2.2.4.2 for domain validation.

How do you determine the Domain Contact for domain validation method
3.2.2.4.2?

[Ryan Dickson]

Hi all,

It seems a few messages have been getting caught in the group's spam filter. Though many of them have been brought to the attention of the group by way of a follow-up response, we're releasing them to the group now for completeness (e.g., Andrew's above message was sent yesterday).

We'll try to catch these issues closer to real-time moving forward.

Sorry for the inconvenience,

Ryan

--
You received this message because you are subscribed to the Google Groups "public" group.
To unsubscribe from this group and stop receiving emails from it, send an email to public+un...@ccadb.org.

To view this discussion on the web visit https://groups.google.com/a/ccadb.org/d/msgid/public/20221212150722.ea922840d1588d0844b4a206%40andrewayer.name.

[André Silva]

We use the RDAP protocol to query the domain contact as difined in the Baseline Requirements - section 1.6.1:

Domain Contact: The Domain Name Registrant, technical contact, or administrative contact (or the equivalent under a ccTLD) as listed in the WHOIS record of the Base Domain Name or in a DNS SOA record, or as obtained through direct contact with the Domain Name Registrar  

[Kurt Seifried]

On Tue, Dec 13, 2022 at 11:23 AM André Silva <andre...@gmail.com> wrote:

We use the RDAP protocol to query the domain contact as difined in the Baseline Requirements - section 1.6.1:

Sorry, who is "we" in this context? If you are speaking on behalf of SERPRO why are you using an anonymous @gmail.com address? 

I think it's critically important that if you are speaking for SERPRO, that you are actually able to prove to some minimal degree that 

you speak for SERPRO.

 

Domain Contact: The Domain Name Registrant, technical contact, or administrative contact (or the equivalent under a ccTLD) as listed in the WHOIS record of the Base Domain Name or in a DNS SOA record, or as obtained through direct contact with the Domain Name Registrar  

Em terça-feira, 13 de dezembro de 2022 às 12:04:57 UTC-3, Andrew Ayer escreveu:

On Mon, 12 Dec 2022 12:00:22 -0800 (PST)
Lucia Castelli <lucast...@gmail.com> wrote:

> This query aims to verify
> a) which organization is responsible for the domain with Registro.br
> or non-br;
> b) which person or which area of the organization is registered as
> responsible for the
> domain. We also use option 3.2.2.4.2 for domain validation.

How do you determine the Domain Contact for domain validation method
3.2.2.4.2?

--

You received this message because you are subscribed to the Google Groups "public" group.
To unsubscribe from this group and stop receiving emails from it, send an email to public+un...@ccadb.org.

To view this discussion on the web visit https://groups.google.com/a/ccadb.org/d/msgid/public/df80f7c8-a1e7-4d32-944f-57bcd108ea9dn%40ccadb.org.

[Lucia Castelli]

Hi Kurt, please, is possible to keep this conversations calm ? Sorry, but sometimes you do a lot of confusion with what is simple to understand.

OK, Andre is not using SERPRO. GOV.BR, but he works with us, in our team.

WE -> Means in this context - us from CA SERPRO SSL.

Thank you 

[André Silva]

I've introduced myself earlier (..." Hi all, I work in the same department as Lúcia at Serpro. ")

Ok, from now on I´ll enter the discussion with my SERPRO email if it´s a problem for you.

Em terça-feira, 13 de dezembro de 2022 às 15:49:06 UTC-3, ku...@seifried.org escreveu:

[Kurt Seifried]

On Tue, Dec 13, 2022 at 11:59 AM Lucia Castelli <lucast...@gmail.com> wrote:

Hi Kurt, please, is possible to keep this conversations calm ? Sorry, but sometimes you do a lot of confusion with what is simple to understand.

Your logical fallacy is: "Playing on Emotion". Please don't play these games, keep it real and factual.

I also work for SERPRO now and can speak for them.

My proof is a non SERPRO email address, and the fact that I said I work there. Which is the same as your proof.

Do you see why this is a problem now? Please use your work email addresses that are tightly associated with the CA applying (ideally the same domain). I suspect we need to make this a requirement for CAs to communicate clearly and provably instead of allowing throw-away Gmail addresses.

Otherwise, we'll have random @gmail.com addresses joining the list and claiming to be the CA and potentially causing problems. 

[Lucia Castelli]

I already ask Ben Wilson to change Andre´s email.

Thank you.

[Kurt Seifried]

You can signup for this list publicly, why have you not signed up using your SERPRO work email address? 

I would challenge you to prove you work for SERPRO and are allowed to speak on their behalf.

I think it's critical that the people speaking for the CA's during the public discussion period are actually probably speaking for the CAs for the public discussion period.

[André Silva]

Hi all,

here we go again...

We (at CA SERPRO) use the RDAP protocol to query the domain contact as difined in the Baseline Requirements - section 1.6.1:

Domain Contact: The Domain Name Registrant, technical contact, or administrative contact (or the equivalent under a ccTLD) as listed in the WHOIS record of the Base Domain Name or in a DNS SOA record, or as obtained through direct contact with the Domain Name Registrar 

Em terça-feira, 13 de dezembro de 2022 às 12:04:57 UTC-3, Andrew Ayer escreveu:

[Kurt Seifried]

On Wed, Dec 14, 2022 at 10:15 AM André Silva <andre-lu...@serpro.gov.br> wrote:

Hi all,

here we go again...

Thanks, also why were you not emailing from your work account at the beginning and instead using a throw-away Gmail account? It's very odd and potentially suspicious behavior that you would create a new email account to do this instead of using your existing account and I think it deserves an explanation (there must be a simple reason, right?). 

 

[Prof. Reardon]

Hello:

I just want to make sure I clearly understand the use of who.is. So for this certificate for infoconv.sicredi.io https://crt.sh/?id=6202101964, since it is non-.br when SERPRO issued it for the organization name of the bank BANCO COOPERATIVO SICREDI the validation was to go to  https://who.is/whois/sicredi.io and see that Confederacao Sicredi was listed? Were there any other steps involved?

Thanks,

Joel Reardon

[André Silva]

You ask me to signup with my SERPRO work email address and I did it.

If you have more requirements on authentication for signing up to this discussion, please make it clear, otherwise let´s continue the questions and answears about CA SERPRO practices, keeping it real and factual.

[Kurt Seifried]

On Wed, Dec 14, 2022 at 11:07 AM André Silva <andre-lu...@serpro.gov.br> wrote:

You ask me to signup with my SERPRO work email address and I did it.

If you have more requirements on authentication for signing up to this discussion, please make it clear, otherwise let´s continue the questions and answears about CA SERPRO practices, keeping it real and factual.

Fair enough. What other external services such as who.is and Gmail is SERPRO dependent upon for providing CA services and validation of control/ownership? 

The reason I ask is it would literally never occur to me to use a website to do a whois lookup when every Linux/Mac OS/heck even Windows with WSL has jwhois locally, so I wonder what other external services might  be in use to support your CA operations instead of doing them in house and controlling them yourself.

[André Silva]

Our CA Software implements RDAP protocol to query domain contact, there´s no website involved in this process.

[André Silva]

Hi Joel,

The main purpose do use the WHOIS service is to get domain contact to proceed to domain validation, as described in BR SSL section 3.2.2.4, after that we proceed to validation of the documentation presented by the entity (organization) by the government agencies.

[Amir Omidi (aaomidi)]

(Full disclosure, I'm an engineer on Google Trust Services - this email is on my personal capacity)

Question regarding the self assessment:

Reading 4.9.2. Who Can Request Revocation from the self assessment and I see the response is 

4.9.2 Who can request revocation
The request to revoke a certificate can only be made:
a) at the request of the certificate holder;
b) at the request of the person responsible for the certificate, in the case of a certificate of equipment, applications and legal entities;
c) at the request of a company or body, when the holder of the certificate provided by that company or body is its employee, employee or servant;
d) by the issuing CA;
e) by a linked RA;
f) by determination of the CG of ICP-Brasil or AC Raiz;
h) By active civil servants and military personnel from the Union, States and the Federal District, authorized by the respective competent bodies for their identification

If you issue a certificate for "example.com" that was associated with some organization called Example. Then I take control over this domain and I don't have an organization behind this domain, would I be able to request a revocation for this certificate per this self-assessment? If so, which category would this fall under?

[Cynthia Revström]

Hi André,

It feels like I am getting conflicting information here, can you please clarify what method SERPRO uses in order to get domain contact info?

As far as I can tell you are saying that you use both who.is and RDAP but I might very well be misunderstanding it.

-Cynthia

--
You received this message because you are subscribed to a topic in the Google Groups "public" group.
To unsubscribe from this topic, visit https://groups.google.com/a/ccadb.org/d/topic/public/Mux855BsRg4/unsubscribe.
To unsubscribe from this group and all its topics, send an email to public+un...@ccadb.org.
To view this discussion on the web visit https://groups.google.com/a/ccadb.org/d/msgid/public/ae3fb36a-7a8e-4a48-acbd-250e3f6fe95an%40ccadb.org.

[Ben Wilson]

All,

We have received a request from SERPRO to pause the public discussion until the end of February while they re-assess their application and to give them time to prepare better answers to the questions raised here.  As stated:

We are going to organize ourselves to include more technical and more consistent answers in the group, since we consider it important to clarify all the doubts understood.

We know that we have had a process for validating and issuing SSL/TLS certificates since 2019, in practice, we are always looking to improve every day, ensuring compliance with the requirements defined in the baseline.

We would like to request a pause in this discussion in the AC SERPRO SSL group, until the end of February, which will be used to include the new responses as mentioned above. If the group had more questions, we ask that they continue to be forwarded so that we can use this new deadline to answer them.

I am granting their request and will pick the discussion back up on March 1, 2023, unless SERPRO notifies me prior to then that they are prepared to re-convene.

Sincerely yours,

Ben Wilson

Mozilla Root Store Manager

You received this message because you are subscribed to the Google Groups "public" group.

To unsubscribe from this group and stop receiving emails from it, send an email to public+un...@ccadb.org.
To view this discussion on the web visit https://groups.google.com/a/ccadb.org/d/msgid/public/CAKw1M3NAsiDuwyhsf8z3TP2odRFnyy4F%2BHg1JN8b%2BQ3eM-Z6DA%40mail.gmail.com.

[Kurt Seifried]

I assume this resets the 6 week clock for dicussions? Or do they get to call timeouts and run the clock out?

To view this discussion on the web visit https://groups.google.com/a/ccadb.org/d/msgid/public/CA%2B1gtaYxBkk7_UR6yqvHvbhmchSLLoJymUdKNJnnj7FSHt_nTw%40mail.gmail.com.

[ke ju]

In general, worried that a CA who can’t get its info ready at the start will protect trust as a CA. If they issue a bad cert, can’t take two+ months to revoke it when actively being used maliciously. If they cannot get current information now, worried about their ability to do so in the future and their competency 

[Ben Wilson]

All,

SERPRO has communicated to me that they are working on integrating pre-issuance linting into their CA processes. They are also considering obtaining a new CA certificate from ICP-Brasil. Thus, they are advising us that they need March to complete such work and will be able to re-commence discussion in April. 

Thanks,

Ben

[Watson Ladd]

Needless to say this extension being announced on the day the previous
one expires does not fill me with confidence in the abilities of
SERPRO.

Sincerely,
Watson Ladd
--
Astra mortemque praestare gradatim

[Kathleen Wilson]

I agree with Watson, so I think we should deny this root inclusion request.

The CA may re-apply when they truly have everything in order.

Also, for future discussions, perhaps we should not allow CAs root inclusion discussions to be put on hold while the CA fixes things.

Thanks,

Kathleen

[Ryan Hurst]

I personally agree that they should have to start over.

Putting aside all the other concerning issues in this thread it is super concerning that they have come this far without pre-issuance linting. This has been a standard for many years and applying for inclusion without this standard practice strongly suggests there are other operation issues to be discovered.

As for not giving time to address concerns raised in the inclusion process, I do think some accommodation is needed but when it comes to basics like this it seems very appropriate to say start over.

Ryan Hurst

--
You received this message because you are subscribed to the Google Groups "CCADB Public" group.

To unsubscribe from this group and stop receiving emails from it, send an email to public+un...@ccadb.org.

To view this discussion on the web visit https://groups.google.com/a/ccadb.org/d/msgid/public/c0614023-9fde-4d12-a782-ac2cfa039286n%40ccadb.org.

[Kathleen Wilson]

Just to clarify -- I was speaking on behalf of Mozilla, not on behalf of any other root store who they may be applying to. So for this discussion here in the CCADB Public forum I think we should close this discussion now, and then the root stores the CA is applying to can make their independent decisions. For Mozilla I think the decision should be to deny this particular request.

Thanks,

Kathleen

[Lucia Castelli]

Dear all, 

We would like to clarify that we have tried our best to present ourselves to the Mozilla program and other root stores, despite the difficulties we have encountered over the last two years to remain within the BR SSL requirements.

During this journey within this group, it was just learning, we don't see it as a defeat. 

One of the situations that perhaps inhibited us was the wrong understanding that we had because we had that the ICP-Brasil regulations should be met first. 

We will prepare ourselves better and make sure that our root (RAIZ CA) is able to meet all browser program requirements.

It was an excellent learning experience, and we would like to thank you for all the feedback you have given us. 

Our thanks in particular to Ben Wilson, who was always patient, polite and teaching us, guiding us to try to get the right direction.

[Kurt Seifried]

On Wed, Mar 1, 2023 at 1:32 PM Lucia Castelli <lucast...@gmail.com> wrote:

Dear all, 

We would like to clarify that we have tried our best to present ourselves to the Mozilla program and other root stores, despite the difficulties we have encountered over the last two years to remain within the BR SSL requirements.

Can you clarify who "we" is? Also can you use a work email address?

 

To view this discussion on the web visit https://groups.google.com/a/ccadb.org/d/msgid/public/a5f1de46-6cc7-4b33-a650-a32f7fff0a8bn%40ccadb.org.

[Lucia de Fatima Castelli Rabelo]

Dear all, 

On behalf of SERPRO, would like to clarify that we have tried our best to present ourselves to the Mozilla program and other root stores, despite the difficulties we have encountered over the last two years to remain within the BR SSL requirements.

During this journey within this group, it was just learning, we don't see it as a defeat. 

One of the situations that perhaps inhibited us was the wrong understanding that we had because we had that the ICP-Brasil regulations should be met first. 

We will prepare ourselves better and make sure that our root (RAIZ CA) is able to meet all browser program requirements.

It was an excellent learning experience, and we would like to thank you for all the feedback you have given us. 

Our thanks in particular to Ben Wilson, who was always patient, polite and teaching us, guiding us to try to get the right direction.

Cordialmente,

Lucia de Fatima Castelli Rabelo

Analista

Superintendência de Produtos e Serviços-Operações   

Diretoria de Operações

+55 (21)2159-3734(Whatsapp Business) 

---

De: 'Kurt Seifried' via CCADB Public <pub...@ccadb.org>
Enviado: quinta-feira, 2 de março de 2023 01:10
Para: Lucia Castelli <lucast...@gmail.com>
Cc: CCADB Public <pub...@ccadb.org>; Kathleen Wilson <kwi...@mozilla.com>
Assunto: Re: Public Discussion of SERPRO's CA Inclusion Request

 

To view this discussion on the web visit https://groups.google.com/a/ccadb.org/d/msgid/public/CABqVa39mYMUpMnejsJZACOK5cw6zrBR-KBboBopQ%2BFUWoJUiQQ%40mail.gmail.com.

“Essa mensagem do SERVIÇO FEDERAL DE PROCESSAMENTO DE DADOS (SERPRO), empresa pública federal regida pelo disposto na Lei Federal nº 5.615, é enviada exclusivamente ao destinatário informado e pode conter dados pessoais, protegidos pela Lei Geral de Proteção de Dados (Lei 13.709/2018), assim como informações confidenciais, protegidas por sigilo profissional. O SERPRO ressalta seu comprometimento em assegurar a segurança e a proteção das informações contidas neste e-mail e informa que a sua utilização desautorizada é ilegal e sujeita o infrator às penas da lei. Se você o recebeu indevidamente, queira, por gentileza, reenviá-lo ao emitente, esclarecendo o equívoco.” “This message from SERVIÇO FEDERAL DE PROCESSAMENTO DE DADOS (SERPRO) - a government company established under Brazilian law (5.615/70) - is directed exclusively to its addressee and may contain personal data protected by the General Data Protection Law (13.709/2018) as well as confidencial data, protected under professional secrecy rules. SERPRO highlights its commitment to ensuring the security and protection of the information contained in this email and its unauthorized use is illegal and may subject the transgressor to the law´s penalties. If you´re not the addressee, please send it back, elucidating the failure.”