[EN] Padrão de Certificados Open Finance Brasil 2.1

Owned by Former user (Deleted)
Last updated: 06/09/2024 by Marcelo Luppi
16 min read

Foreword

Este documento também está disponível em português.

The Open Finance Brasil Initial Structure is responsible for creating standards and specifications necessary to meet the requirements and obligations of the Brasil Open Finance Legislation as originally outlined by the Brasil Central Bank. There is a possibility that some of the elements of this document may be the subject to patent rights. OFBIS shall not be held responsible for identifying any or all such patent rights.

Objective

Specify the set of necessary certificates required by participating organizations in Open Finance Brasil to ensure interoperability for authentication, confidentiality, integrity and non-repudiation among participants, as well as for users and consumers of these entities. The audience of this specification are the entities participating in Open Finance Brasil that will issue certificates to authenticate themselves with other entities, as well as offering their customers a secure authentication channel.

Notational Conventions

The key words "shall", "shall not", "should", "should not", "may", and "can" in this document are to be interpreted as described in [ISO Directive Part 2][ISODIR2]. These key words are not to be used as lexicon terms such that any occurrence of them shall be interpreted as key words and are not to be interpreted with their natural language meanings.

1. Scope

This document specifies the types of certificates required for:

  • Mutually authenticate (MTLS - Mutual TLS) participants' applications;

  • Message Signature (JWS - JSON Web Signature) applications to ensure authenticity and non-repudiation of messages between participants;

  • Provide a safe and reliable channel for Open Finance Brasil customers;

  • Authenticate participants in the Open Finance Brasil Participant Directory.

2. Normative refences

The following referenced documents are indispensable for the application of this document. For dated references, only the edition cited applied. For undated references, the latest edition of the referenced document (including any amendments) applies.

3. Terms and definitions

For the purpose of this document, the terms defined in [RFC5280], [BCP195], [RFC8705], e ISO29100 apply.

4. Glossary

  • API - Application Programming Interface

  • DCR - Dynamic Client Registration

  • HTTP - Hyper Text Transfer Protocol

  • ICP - Infraestrutura de Chave Públicas Brasileira

  • SS - Software Statement

  • SSA - Software Statement Assertion

  • TLS - Transport Layer Security

  • mTLS - Mutual Transport Layer Security

5. Open Finance Brasil Certificate Standards

5.1. Introduction

The Open Finance Brazil ecosystem makes use of chains of certificates and TLS protocol to guarantee the confidentiality, authentication and integrity of the communication channel used by the APIs of the participating organizations, as well as the customers of each of the participants.

The certificates used by Open Finance Brasil are also required to authenticate applications through private_key_jwt, in addition to being used to perform the payload signature using JWS. Another important attribution of certificates is to authenticate and present a secure channel to the end user in the act of authentication and use of services provided by the participating organizations.

5.2. ICP-Brasil Certificates

Certificates issued by Certifying Authorities authorized by ICP-Brasil are only used for communication between entities participating in the Open Finance Brasil ecosystem.

The certificate issuing and revocation processes are responsibility of the Certifate Authorities themselves, being regulated by Certification Practice Statements, and supervised by the Management Committee of the Brazilian Public Key Infrastructure (Comitê Gestor da Infraestrutura de Chaves Públicas Brasileira).

The practices, processes, availability and values practiced by the Certification Authorities are not responsibility of the Initial Structure of Open Finance Brasil.

Name restrictions

Despite UTF8 support by the certificate attributes, this standard will adhere to name restrictions as outlined in the document: “REQUISITOS MÍNIMOS PARA AS POLÍTICAS DE CERTIFICADO NA ICP-BRASIL”, section 7.1.5, establishing the following name restrictions applicable to all ICP-BRASIL certificates:

  • shall not use punctuation signs, umlauts or cedilla;

  • in addition to alphanumeric characters, only the following special characters may be used:

Character

Code NBR9611 (hexadecimal)

Character

Code NBR9611 (hexadecimal)

White space

20

+

2B

!

21

,

2C

“

22

-

2D

#

23

.

2E

$

24

/

2F

%

25

:

3A

&

26

;

3B

‘

27

=

3D

(

28

?

3F

)

29

@

40

*

2A

\

5C

 

Algorithms

All certificates issued by ICP-Brasil must have the following characteristics:

  • Type A of ICP-Brasil;

  • Key Algorithms: RSA 2048 bits;

  • Message Digest: SHA 256 bits.

Participating Certificate Authorities

The following certifying authorities carried out the onboard process for Open Finance Brasil and are authorized to issue Open Finance Brasil certificates using the level 1 certificates listed here:

Only the certificates indicated with "Situação: válido" (which mean "status: valid") in these ITI repositories referenced above, which are Chain v5 and v10, should be accepted by the servers of the Open Finance Brasil ecosystem.

5.2.1. Server Certificate

The Server Certificate must be issued to protect and authenticate the TLS channel used by the APIs that will be consumed by client applications of organizations participating in Open Finance.

The certificate standard used must follow the existing certificate issuing practices of "CERTIFICATE FOR WEB SERVER - ICP-Brasil".

The server certificate shall be sent with the intermediate chain, according to RFC5246.

5.2.2. Client Certificate

Client Application Certificates (Transport) are used to authenticate the mTLS channel and to authenticate the client application through private_key_jwt, according to the application registration performed by the Dynamic Client Registration process with the transmitting organization. Regarding mTLS, the client certificate shall be sent with the intermediate chain, according to RFC5246.

To issue a Client Certificate, the participating organization in Open Finance Brasil must register the application in the Directory Service through the Software Statement Assertion issue process, and thus have already obtained the Software Statement ID value.

5.2.2.1. Open Finance Brasil Attributes

  • serialNumber: National Register of Legal Personnel (CNPJ) of the legal entity holding the certificate and associated with the UID attribute and Software Statement ID, during validation with the Directory Service of Open Finance Brasil;

  • organizationIdentifier: Participant Code associated with the CNPJ listed in the Directory Service of Open Finance Brasil; For certificates issued until August 31 the field used for this information is organizationalUnitName.

  • UID: Software Statement ID registered in the Directory Service of Open Finance Brasil and belonging to the CNPJ and Participant Code.

The Client Certificate must be issued through the V10 chain, and must contain the following attributes:

Distinguished Name, as per the sequence bellow (details available in section 9.2):

  • businessCategory (OID 2.5.4.15): Type of business category, which must contain: "Private Organization" or "Government Entity" or "Business Entity" or "Non-Commercial Entity"

  • jurisdictionCountryName (OID: 1.3.6.1.4.1.311.60.2.1.3): BR

  • serialNumber (OID 2.5.4.5): CNPJ

  • countryName (OID 2.5.4.6): BR

  • organizationName (OID 2.5.4.10): Company Name

  • stateOrProvinceName (OID 2.5.4.8): Federation unit of the certificate holder's physical address

  • localityName (OID 2.5.4.7): City of the holder's physical address

  • organizationIdentifier (OID 2.5.4.97): Participant Code associated with the CNPJ listed in the Directory Service of Open Finance Brasil. *For certificates issued until August 31: organizationalUnitName (OID 2.5.4.11): Participant Code associated with the CNPJ listed in the Directory Service of Open Finance Brasil*

  • UID (OID 0.9.2342.19200300.100.1.1): Software Statement ID generated by Open Finance Brasil Directory

  • commonName (OID 2.5.4.3): FQDN or Wildcard

Certificate Extensions

  • keyUsage: critical,digitalSignature,keyEncipherment

  • extendedKeyUsage: clientAuth

Subject Alternative Name

DNSName: FQDN or Wildcard

5.2.3. Signature Certificate

Signature Certificates are used to perform payload signature through the use of JWS (JSON Web Signature).

5.2.3.1. Open Finance Brasil Attributes Present in the Certificate

  • UID: Participant Code associated with the CNPJ listed in the Directory Service of Open Finance Brasil;

  • commonName: Company Name registered in the Directory Service of Open Finance Brasil and belonging to the CNPJ and Participant Code.

The Signature Certificate must be issued through the V5 chain, and must contain the following attributes:

Distinguished Name

  • UID (OID 0.9.2342.19200300.100.1.1): Participant Code associated with the CNPJ listed in the Directory Service of Open Finance Brazil

  • countryName (OID 2.5.4.6): BR

  • organizationName (OID 2.5.4.10): ICP-Brasil

  • organizationalUnitName (OID 2.5.4.11): Certificate Authority Name

  • organizationalUnitName (OID 2.5.4.11): CNPJ of the Registration Authority

  • organizationalUnitName (OID 2.5.4.11): Type of identification used (in person, videoconference or digital certificate)

  • commonName (OID 2.5.4.3): Company Name

Certificate Extensions

keyUsage: critical,digitalSignature,nonRepudiation

Subject Alternative Name

  • otherName (OID 2.16.76.1.3.2 - ICP-Brasil): Name of the person responsible for the certificate

  • otherName (OID 2.16.76.1.3.3 - ICP-Brasil): National Register of Legal Entities (CNPJ) of the legal entity holding the certificate;

  • otherName (OID 2.16.76.1.3.4 - ICP-Brasil): Responsible for the certificate of legal entity holding the certificate (date of birth, CPF, PIS/PASEP/CI, RG);

  • otherName (OID 2.16.76.1.3.7 - ICP-Brasil): INSS Specific Registry Number (CEI) of the legal entity holding the certificate.

5.2.4. Front-End Certificates

Front-End certificates are utilized to make services available, generally web pages, using TLS, that are acessible by the end users. Due to their function, and in order to guarantee better interoperability, those certificates must be of the type EV (Extended Validation) and must be generated by a valid certificate authority, following definitions of RFC 5280 e RFC 2818, in conformance with WebTrust principles and criteria.

5.2.5. About certificates for exchanging information between authorized institutions and partners (non-participating)

According to section IV of Joint Resolution No. 1 of May 4, 2020, the establishment of bilateral partnerships between authorized institutions and partners is an arrangement provided for in the regulation which must observe, where applicable, the same standards and certificates requirements that are applicable to exchange of information between participating institutions.

In accordance with §2 of Art. 10 of Provisional Measure 2200-2 of August 24, 2001 and with the provisions of item 3.12 in BCB Normative Instruction No. 134, for bilateral communication between institutions and partners, the use is authorized, by mutual agreement between the parties, of a private PKI, provided that the requirements of this profile for security certificates are observed, including their formatting, algorithms and established attributes.

The values for filling in the attributes required in this specification, but not applicable to the partner, should be defined in common agreement between the authorized institution and the partner, which does not exempt the authorized institution from the responsibility for filling it in properly.

6. Acknowledgements

Thanks to all who have set the foundations for secure and safe data sharing through the formation of the OpenID Foundation FAPI Working Group, the Open Finance Brasil GT Security and to the pioneers who will stand on their shoulders.

The following people contributed to this document:

  • João Rodolfo Vieira (Itaú)

  • José Michael Dias (Grupo Pan)

  • Marcos Rodrigues (Itaú)

  • Nic Marcondes (Quanto)

  • Ralph Bragg (Raidiam)

7. Notices

Copyright (c) 2023 Open Finance Brasil Initial Structure.

The Open Finance Brasil Initial Structure (OFBIS) grants to any Contributor, developer, implementer, or other interested party a non-exclusive, royalty-free, worldwide copyright license to reproduce, prepare derivative works from, distribute, perform and display, this Implementers Draft or Final Specification solely for the purposes of (i) developing specifications, and (ii) implementing Implementers Drafts and Final Specifications based on such documents, provided that attribution be made to the OFBIS as the source of the material, but that such attribution does not indicate an endorsement by the OFBIS.

The technology described in this specification was made available from contributions from various sources, including members of the OpenID Foundation, the Open Finance Brasil GT Security Working Group and others. Although the Open Finance Brasil Initial Structure has taken steps to help ensure that the technology is available for distribution, it takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this specification or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any independent effort to identify any such rights. The Open Finance Brasil Initial Structure and the contributors to this specification make no (and hereby expressly disclaim any) warranties (express, implied, or otherwise), including implied warranties of merchantability, non-infringement, fitness for a particular purpose, or title, related to this specification, and the entire risk as to implementing this specification is assumed by the implementer. The Open Finance Brasil Intellectual Property Rights policy requires contributors to offer a patent promise not to assert certain patent claims against other contributors and against implementers. The Open Finance Brasil Initial Structure invites any interested party to bring to its attention any copyrights, patents, patent applications, or other proprietary rights that may cover technology that may be required to practice this specification.

8. Appendix

8.1. Configuration Template for Client Certificate - OpenSSL - For certificates issued until August 31, 2022

[req] default_bits = 2048 default_md = sha256 encrypt_key = yes prompt = no string_mask = utf8 distinguished_name = client_distinguished_name req_extensions = req_cert_extensions [ client_distinguished_name ] businessCategory = <type of organization> jurisdictionCountryName = BR serialNumber = <CNPJ> countryName = BR organizationName = <Company Name> stateOrProvinceName = <UF> localityName = <City> organizationalUnitName = <Participant Code> UID = <Software Statement ID issued by the Directory> commonName = <FQDN|Wildcard> [ req_cert_extensions ] basicConstraints = CA:FALSE subjectAltName = @alt_name keyUsage = critical,digitalSignature,keyEncipherment extendedKeyUsage = clientAuth [ alt_name ] DNS = <FQDN|Wildcard>

8.2. Configuration Template for Client Certificate - OpenSSL - For certificates issued after August 31, 2022

oid_section = OIDs [req] default_bits = 2048 default_md = sha256 encrypt_key = yes prompt = no string_mask = nombstr distinguished_name = client_distinguished_name req_extensions = req_cert_extensions [ OIDs ] organizationIdentifier = 2.5.4.97 [ client_distinguished_name ] businessCategory = <type of organization> jurisdictionCountryName = BR serialNumber = <CNPJ> countryName = BR organizationName = <Company Name> stateOrProvinceName = <UF> localityName = <City> organizationIdentifier = OFBBR-<Participant Code> UID = <Software Statement ID issued by the Directory> commonName = <FQDN|Wildcard> [ req_cert_extensions ] basicConstraints = CA:FALSE subjectAltName = @alt_name keyUsage = critical,digitalSignature,keyEncipherment extendedKeyUsage = clientAuth [ alt_name ] DNS = <FQDN|Wildcard>

8.3. Configuration Template for Signature Certificate - OpenSSL

[req] default_bits = 2048 default_md = sha256 encrypt_key = yes prompt = no string_mask = nombstr distinguished_name = client_distinguished_name req_extensions = req_cert_extensions [ client_distinguished_name ] UID = <Participant Code> countryName = BR organizationName = ICP-Brasil 0.organizationalUnitName = <Certificate Authority> 1.organizationalUnitName = <CNPJ of the Registration Authority> 2.organizationalUnitName = <Validation type> commonName = <Company Name> [ req_cert_extensions ] basicConstraints = CA:FALSE subjectAltName = @alt_name keyUsage = critical,digitalSignature,nonRepudiation [ alt_name ] otherName.0 = 2.16.76.1.3.2;PRINTABLESTRING:<Name of the person responsible for the organization> otherName.1 = 2.16.76.1.3.3;PRINTABLESTRING:<CNPJ> otherName.2 = 2.16.76.1.3.4;PRINTABLESTRING:<CPF/PIS/RF of the responsible person> otherName.3 = 2.16.76.1.3.7;PRINTABLESTRING:<INSS Number>

8.4. Endpoints vs Certificate type and mTLS requirements

Below we present which endpoints can be published utilizing the EV certificate as consent authentication and the endpoints of private/bussiness API authentication using the ICP certificate. You will also be able to check which endpoints must protect its connections using mTLS.

ASPSP may choose the certificate that should be adopted for Open Data endpoints, which, by nature, are publicly accessible.

Table 1

 

 

 

 

OFB Phase

group

endpoint

certificate type

mTLS

NA

OIDC

.well-known/openid-configuration

EV or ICP WEB SSL

 

NA

OIDC

jwks_uri

EV or ICP WEB SSL

 

NA

OIDC

authorization_endpoint

EV

 

NA

OIDC

token_endpoint

ICP WEB SSL

Required

NA

OIDC

userinfo_endpoint

ICP WEB SSL

Required

NA

OIDC

pushed_authorization_request_endpoint

ICP WEB SSL

Required

NA

DCR

registration_endpoint

ICP WEB SSL

Required

NA

OIDC

revocation_endpoint

ICP WEB SSL

Required

2

Consentimentos

/consents/*

ICP WEB SSL

Required

2

Resources

/resources/*

ICP WEB SSL

Required

2

Dados

/customers/*

ICP WEB SSL

Required

2

Cartão

/credit-cards-accounts/*

ICP WEB SSL

Required

2

Contas

/accounts/*

ICP WEB SSL

Required

2

Empréstimos

/loans/*

ICP WEB SSL

Required

2

Financiamentos

/financings/*

ICP WEB SSL

Required

2

Adiantamento

/unarranged-accounts-overdraft/*

ICP WEB SSL

Required

2

Direitos Creditórios

/invoice-financings/*

ICP WEB SSL

Required

3

Pagamentos

/payments/*

ICP WEB SSL

Required

3

Webhook

/webhook/*

ICP WEB SSL

Required

4

Câmbio

/exchanges/*

ICP WEB SSL

Required

4

Investimentos

/credit-fixed-incomes/*

ICP WEB SSL

Required

8.5. Guide for the exchange of Certification Authorities approved in the Open Finance Brazil ecosystem by institutions

8.5.1. Introduction

Open Finance is an initiative of the Brazil Central Bank whose main objectives are to bring innovation to the financial system, promote competition, and improve the offer of financial products and services to the end consumer. This guide aims to assist professionals involved in the management of digital certificates used in the scope of Open Finance services by presenting the necessary technical analyses for migrating from an approved certificate authority (CAs/PKIs) to another certificate authority.

An approved certificate issuer is understood to be a certification authority that is linked to ITI/ICP, meeting all requirements and current legislation related to ITI/ICP's public key infrastructure and that is duly registered by the Open Finance ecosystem as a certification authority able to issue digital certificates in ITI/ICP's Brasil (Management Committee of the Brazilian Public Key Infrastructure) V5 and V10 chains,  following all the requirements listed in the Digital Certificate Standard.

You can find the list of approved organizations here: Participating Certificate Authorities.

8.5.2. Responsibilities and Prerequisites

8.5.2.1 Responsibilities:

The participating institutions, when hiring the new certificate issuance service provider, in addition to observing the technical standards and recommendations of the working groups, must observe the rules for contracting technological services and on digital certificates under their responsibility under the terms of the current regulations, especially, in the case of Open Finance, items 2.6 and 3.9 of IN BCB 305/2022:

Item 2.6 IN BCB 305

Participating institutions, prior to contracting the services required to conduct activities related to Open Finance, must adopt procedures that include the verification of the potential service provider's ability to ensure compliance with current legislation and regulations.

Item 3.9 IN BCB 305

For message signing and secure communication with APIs used for the sharing of customer registration and transaction data and the payment transaction initiation service related to the Pix arrangement, valid digital certificates issued by a certification authority participating in ICP-Brasil must be used, in accordance with the standards for digital certification established by the Structure Responsible for the Governance of Open Finance.

8.5.2.2. Prerequisites:

Prior knowledge of the documents, standards and legislation listed below is recommended for the correct execution and analysis proposed by this guide:

8.5.3. Digital Certificate Analysis

Changes to the values contained in the "subjectDN" attribute of the digital certificate used by the Open Finance client certificate may impact the certificate holder's access to the ecosystem if the participant does not follow the instructions of the OAuth 2.0 Dynamic Client Registration Management Protocol RFC7592.

Given the fact that the certificate authority will validate the organization's data registered in the central directory, and if correct, will sign the certificate request (CSR) generated by the participant, the use of lowercase letters, uppercase letters and special characters, may distinguish from the certificate in use, causing differences in the "subjectDN" attribute as shown in the examples below.

It is up to the participant to pay attention during the signature request and when checking the data. For didactic purposes the digital certificates below will be used as examples of changes in the "subjectDN" attributes, the divergence of locales, their formatting as uppercase and lowercase characters will change the result of the "subjectDN".

Certificate 1

-----BEGIN CERTIFICATE-----

MIIHxzCCBa+gAwIBAgIIB4Faz1mRPo0wDQYJKoZIhvcNAQELBQAwdzELMAkGA1UE

BhMCQlIxEzARBgNVBAoMCklDUC1CcmFzaWwxNTAzBgNVBAsMLEF1dG9yaWRhZGUg

Q2VydGlmaWNhZG9yYSBSYWl6IEJyYXNpbGVpcmEgdjEwMRwwGgYDVQQDDBNBQyBT

RVJBU0EgU1NMIEVWIFY0MB4XDTIzMDczMTExNDgwMFoXDTI0MDczMDExNDc1OVow

ggFDMR0wGwYDVQQPDBRQcml2YXRlIE9yZ2FuaXphdGlvbjETMBEGCysGAQQBgjc8

AgEDEwJCUjEXMBUGA1UEBRMONDMxNDI2NjYwMDAxOTcxCzAJBgNVBAYTAkJSMSIw

IAYDVQQKDBlDaGljYWdvIEFkdmlzb3J5IFBhcnRuZXJzMQswCQYDVQQIDAJTUDES

MBAGA1UEBwwJU0FPIFBBVUxPMTMwMQYDVQRhDCpPRkJCUi1kNzM4NGJkMC04NDJm

LTQzYzUtYmUwMi05ZDJiMmQ1ZWZjMmMxNDAyBgoJkiaJk/IsZAEBDCRiYzk3Yjhm

MC1jYWUwLTRmMmYtOTk3OC1kOTNmMGU1NmE4MzMxNzA1BgNVBAMMLndlYi5jb25m

dHBwLmRpcmVjdG9yeS5vcGVuYmFua2luZ2JyYXNpbC5vcmcuYnIwggEiMA0GCSqG

SIb3DQEBAQUAA4IBDwAwggEKAoIBAQDM7Q2MgkLsqSusK6CoFpe7idPfW4QN5mMR

jK1qiCXJFTlHyot6gDlq48dHq5VDg78zy33Bio/r93KGwQEOKGsr8HOuAou6IOQA

9OPyUNMg9f64scq8lUkNqNoqAKr/I2U6ELE0LtOAwe8SW4uMhkcYBOE+eP5D76M2

n5idrjsKdN/WloUKU9H2ZjraJLOhPQ0MHD8epL7SrU0/wKEShxO5e9i0MByP00ht

B74bn3yWc7pFe9TQ8oeyhMmsIky50ixIHKm5Vv/RWCjB/6CmBLyEENoNhNDMEy4k

GNGsDcuPGWrRnhNbylAX7luWpSvoOCd7z/ZLZ354zDiMHbn57VAdAgMBAAGjggKH

MIICgzAJBgNVHRMEAjAAMB8GA1UdIwQYMBaAFLFWplh4DM49EiNVGKlDGLbQWMUQ

MIGjBggrBgEFBQcBAQSBljCBkzBNBggrBgEFBQcwAoZBaHR0cDovL3d3dy5jZXJ0

aWZpY2Fkb2RpZ2l0YWwuY29tLmJyL2NhZGVpYXMvc2VyYXNhc3NsZXZ2MTAtNC5w

N2IwQgYIKwYBBQUHMAGGNmh0dHA6Ly9vY3NwLmNlcnRpZmljYWRvZGlnaXRhbC5j

b20uYnIvc2VyYXNhc3NsZXZ2MTAtNDA5BgNVHREEMjAwgi53ZWIuY29uZnRwcC5k

aXJlY3Rvcnkub3BlbmJhbmtpbmdicmFzaWwub3JnLmJyMIGFBgNVHSAEfjB8MAkG

B2BMAQIBgQAwbwYFZ4EMAQEwZjBkBggrBgEFBQcCARZYaHR0cDovL3B1YmxpY2Fj

YW8uY2VydGlmaWNhZG9kaWdpdGFsLmNvbS5ici9yZXBvc2l0b3Jpby9kcGMvZGVj

bGFyYWNhby1zZXJhc2Etc3NsLWV2LnBkZjATBgNVHSUEDDAKBggrBgEFBQcDAjCB

pwYDVR0fBIGfMIGcME+gTaBLhklodHRwOi8vd3d3LmNlcnRpZmljYWRvZGlnaXRh

bC5jb20uYnIvcmVwb3NpdG9yaW8vbGNyL3NlcmFzYXNzbGV2djEwLTQuY3JsMEmg

R6BFhkNodHRwOi8vbGNyLmNlcnRpZmljYWRvcy5jb20uYnIvcmVwb3NpdG9yaW8v

bGNyL3NlcmFzYXNzbGV2djEwLTQuY3JsMB0GA1UdDgQWBBQ4XEp8dD3mZfBTKm2J

n4UgdrMItzAOBgNVHQ8BAf8EBAMCBaAwDQYJKoZIhvcNAQELBQADggIBAJmNLrQL

+OeV3DHURcHa2nHzkF+V6WugJRDnlovEed1kuK+knd/us0kmpMZfqw5GJT1ZVYFX

wiW2WWfEnswEM+U1pOQCckqhWRfn+jaShj7irR+Boe9aCOw/Z2wLDl5Fk2pqb2Sj

hp2JGfBjrDqy5Sw9piVZxHf0oObNsh/S3I402xFyBg7r0D6rOGtMg2JNTc+5w1dZ

mZoqOYxY+pLU6c5JgvsvaipJmBav256QywYM1nOZheva6b2OnJ5ddrDqyTe2MX6+

DD4qG9kPouqegrLAxQUcJZsdmmQ59RuiwiHiwR3javX5R71fSDAd4VTdX6KHRtgr

/O94a9JSW+7/Sh9jjW+ORN09wSRVM04AB5t86D7YdMlbi/kFtXOjq0IGpPl1UyD/

LUrBtQji4O3uiCwzhVSRX5Hjte5e80GLossLA3HKc0vqpNoDzKKkOj7upzOHOT5O

gfVnd7LID1xn/FmyF4O8jlxoI0IZDTRcdfYnUHTUCFIF0NaPImQ2hIHxHTFHwOtO

B5pNOHS7PfGpIWpt7OHEdsGh+Q3LG4zXwoCVdiTNSFZWkxN1LZECb1Fhmj+Nwout

4H75JUMdk2CHPVKKOxcNeWXeAyDLmPHl+Pah5zurX6sdaOq0SVnaN8mG1iZdd+KO

0G+Zk0R+t4wxbnGVJ+HR5f4diOF9fxegCldJ

-----END CERTIFICATE-----

Certificate 2

-----BEGIN CERTIFICATE-----

MIIHlzCCBX+gAwIBAgIIEd4jERdackgwDQYJKoZIhvcNAQENBQAwdzELMAkGA1UE

BhMCQlIxEzARBgNVBAoTCklDUC1CcmFzaWwxNTAzBgNVBAsTLEF1dG9yaWRhZGUg

Q2VydGlmaWNhZG9yYSBSYWl6IEJyYXNpbGVpcmEgdjEwMRwwGgYDVQQDExNBQyBT

T0xVVEkgU1NMIEVWIEc0MB4XDTIzMTEyMTE3MzgwMFoXDTI0MTEyMDE3MzgwMFow

ggFvMR0wGwYDVQQPDBRQcml2YXRlIE9yZ2FuaXphdGlvbjETMBEGCysGAQQBgjc8

AgEDEwJCUjEXMBUGA1UEBRMONDMxNDI2NjYwMDAxOTcxCzAJBgNVBAYTAkJSMUkw

RwYDVQQKDEBDSElDQUdPIEFEVklTT1JZIFBBUlRORVJTIENPTlNVTFRPUklBIEVN

IEdFU1RBTyBFTVBSRVNBUklBTCBMVERBMQswCQYDVQQIDAJSSjEXMBUGA1UEBwwO

UmlvIGRlIEphbmVpcm8xMzAxBgNVBGEMKk9GQkJSLWQ3Mzg0YmQwLTg0MmYtNDNj

NS1iZTAyLTlkMmIyZDVlZmMyYzE0MDIGCgmSJomT8ixkAQEMJGJjOTdiOGYwLWNh

ZTAtNGYyZi05OTc4LWQ5M2YwZTU2YTgzMzE3MDUGA1UEAwwud2ViLmNvbmZ0cHAu

ZGlyZWN0b3J5Lm9wZW5iYW5raW5nYnJhc2lsLm9yZy5icjCCASIwDQYJKoZIhvcN

AQEBBQADggEPADCCAQoCggEBAK/TbHTlFk94cic91xBGoGAAkRiy1H0WSBIiI6B+

HWDUPN0XW8dnOVGEp/Hk/p8SB2kuIs5mEiECfeEd8/peZqlkFkmNRwYu8e10O7F1

bEx8uwGTkPX/m1s+bbw+b/oA+hDvm+77Bwun04VCtTylpyEyNfcwe7FYK8NWZnz0

A+kOC74KNwXDlpx5fCKYaknLxN40caY8scpSrbPPgk1+6TbjyyUBODDXsgj8qPwh

uzSGrQ7gmrfKVd12BqrDDYiPD2g4q832lvm6zoMu5txujujQ+Svxhc3w2wIAPDf6

eFgeRceNhSzzvODYNH52DcM6th6kNKsQNiRmexARvmhNNh0CAwEAAaOCAiswggIn

MAkGA1UdEwQCMAAwHwYDVR0jBBgwFoAU/ga5LJV+L+bQuKjxL7fyLoXV18AwgYAG

CCsGAQUFBwEBBHQwcjBGBggrBgEFBQcwAoY6aHR0cDovL2NjZC5hY3NvbHV0aS5j

b20uYnIvbGNyL2FjLXNvbHV0aS1zc2wtZXYtdjEwLWc0LmNydDAoBggrBgEFBQcw

AYYcaHR0cDovL29jc3AzLmFjc29sdXRpLmNvbS5icjA5BgNVHREEMjAwgi53ZWIu

Y29uZnRwcC5kaXJlY3Rvcnkub3BlbmJhbmtpbmdicmFzaWwub3JnLmJyMGQGA1Ud

IARdMFswBwYFZ4EMAQEwUAYGYEwBAgFwMEYwRAYIKwYBBQUHAgEWOGh0dHA6Ly9j

Y2QuYWNzb2x1dGkuY29tLmJyL2RvY3MvZHBjLWFjLXNvbHV0aS1zc2wtZXYucGRm

MBMGA1UdJQQMMAoGCCsGAQUFBwMCMIGQBgNVHR8EgYgwgYUwQKA+oDyGOmh0dHA6

Ly9jY2QuYWNzb2x1dGkuY29tLmJyL2xjci9hYy1zb2x1dGktc3NsLWV2LXYxMC1n

NC5jcmwwQaA/oD2GO2h0dHA6Ly9jY2QyLmFjc29sdXRpLmNvbS5ici9sY3IvYWMt

c29sdXRpLXNzbC1ldi12MTAtZzQuY3JsMB0GA1UdDgQWBBQ3ZGduKdZRoh8RHnMu

lRcGqwTTpDAOBgNVHQ8BAf8EBAMCBaAwDQYJKoZIhvcNAQENBQADggIBAAq9CdAd

9wR+IS5g+eD2x/8wNZjPkFyimCQXuTnkJeDzdLjUv1TJvoPXRg6mByeWy5tX1JRe

vU9e29z+q2yCuuoFmqKLCseWabHvhjA7L68whJIuSqPBohbjb4dPcb+cWlIZ69mq

hq5G+wT1fC/PRzK+4eDvwstC+gMpP7547MCoVP6g8n5GPe6gbsdG4gufjOJ4c3YQ

VWncCeH2psmOlYaXDFgR4zppNZ+Kp6tLott3iz8Q73Bu2t8lQRAekUOUrbsw70z4

3KVDfQt5GircSEiph9rzD3u/JGJjnB+m7URVC8Tg9FIIWhoWsJxqRXwr9B9JECc1

f6EAdLdr82IYhzVmAkfWb1l+YBWSPfYaPoVbjdJw7mZQlk7LUrN+przNyl961VkC

INfKap+EYzjfdQ1j9kbARzFJmJ50ruOqbk6lQ21kv15oF7HC09DSuNqfs/mGOpzQ

fp1OtIz4vxBO9jkYjRkKzEYW9rpNwrZ9Lsttb7n84PkXO8CAq+7ep5D75CjHDQWx

U3EYoQVL5pi84LUw4x11cPrrnSw3Qx0eDyE554A5pBUzFVUIkE8tGM5CQKQ77tDD

FfWy75gY8C4ee5MJ7Uhh3JA5RAnMJ4Y3OH9gn6jrlZsiLGnPJh2uZaAV9S5UoixO

vd0g7wv04oksqGSykYL5RAp1gu9yJNwkF2Se

-----END CERTIFICATE-----

Certificate 1

subject= CN=web.conftpp.directory.openbankingbrasil.org.br,UID=bc97b8f0-cae0-4f2f-9978-d93f0e56a833,2.5.4.97=#0C2A4F464242522D64373338346264302D383432662D343363352D626530322D396432623264356566633263,L=SAO PAULO,ST=SP,O=Chicago Advisory Partners,C=BR,serialNumber=43142666000197,jurisdictionCountryName=BR,businessCategory=Private Organization

Certificate 2

Example 2:

subject= CN=web.conftpp.directory.openbankingbrasil.org.br,UID=bc97b8f0-cae0-4f2f-9978-d93f0e56a833,2.5.4.97=#0C2A4F464242522D64373338346264302D383432662D343363352D626530322D396432623264356566633263,L=Rio de Janeiro,ST=RJ,O=CHICAGO ADVISORY PARTNERS CONSULTORIA EM GESTAO EMPRESARIAL LTDA,C=BR,serialNumber=43142666000197,jurisdictionCountryName=BR,businessCategory=Private Organization

Participants who have implemented OAUTH MTLS (RFC 8705), use the "subjectDN" of the client certificate in the Client Data Registration process as per item: RFC8705 - 2.1.2. Client Registration Metadata; Considering this fact, if the "subjectDN" of the certificate is changed by March 24, 2024, it will be necessary for the institution issuing the certificate to perform the DCM to update the: tls_client_auth_subject_dn.

Participants who update their digital customer certificate after March 25, 2024 will be able to use the DCM (Dynamic Client Management) window provided for the migration schedule for the new Open Finance security profile, as reported in the ecosystem’s communication process (Infoma #480).

9. Open Finance Client Certificate Subject DN Pattern - After January 19, 2023 {#subjectDNtemplates}

On January 19, 2023 the sequence and encoding of the Subject DN used in Open Finance Client Certificates was standardized. Below is determined the sequence and coding of how the attributes of the certificates should be presented in the Subject DN.

The coexistence period between the different types of Subject DN must be considered, so the participants of the ecosystem should not implement blocking controls that limit the use of only certificates with the Subject DN standardized below. Participants must ensure that the other DN standards already in use continue to function until the end of the coexistence period, a date yet to be determined.

Special attention is required from the participants during the Subject DN generation process, as below are presented Subject DN and RDN formats. The Ecosystem expects the use of RDN in compliance with RFC4514.

When in doubt:

9.1 Example:

9.1.1. JWKS with certificate’s information:

Example: https://keystore.directory.openbankingbrasil.org.br/d7384bd0-842f-43c5-be02-9d2b2d5efc2c/bc97b8f0-cae0-4f2f-9978-d93f0e56a833/transport.jwks

9.1.2. Public Key Certificate Example:

https://keystore.directory.openbankingbrasil.org.br/d7384bd0-842f-43c5-be02-9d2b2d5efc2c/bc97b8f0-cae0-4f2f-9978-d93f0e56a833/wdHeYDz0v4m9tzxpNjsfovbl1fKCFAUvsSIs-ljM4xU.pem

9.2. Example Subject Distinguished Name of the Certificate - Human readable:

9.3. Relative Distinguished Name (RDN) - Human readable:

9.4. Relative Distinguished Name (RDN) using OID - ANS.1:

9.5. Subject DN in RDN - According to RFC4514 - Open Finance Brazil Ecosystem Standard:

9.6. Table with RDN and details of the OIDs and Encodings.

The table below presents the sequence in Relative Distinguished Name as per item 9.5. In order to check the sequential order of the subjectDN, refer to itens 9.2 and 5.2.2.1

RDN Order

OID

Attribute

ASN.1 - Bit String

Enconding

1

2.5.4.3

CN

#0C

UTF8

2

0.9.2342.19200300.100.1.1

UID

#0C

UTF8

3

2.5.4.97

organizationIdentifier

#0C

UTF8

4

2.5.4.7

L

#0C

UTF8

5

2.5.4.8

ST

#0C

UTF8

6

2.5.4.10

O

#0C

UTF8

7

2.5.4.6

C

#13

PrintableString

8

2.5.4.5

serialNumber

#13

PrintableString

9

1.3.6.1.4.1.311.60.2.1.3

jurisdictionCountryName

#13

PrintableString

10

2.5.4.15

businessCategory

#0C

UTF8