DCR - obligation on oauth client to use a specific format for tls_client_auth_subject_dn

[RalphBragg]

Whilst there is an obligation on the Authorisation Server to support a specific format of the tls_client_auth_subject_dn, there is no corresponding provion on the oauth client to use that mechanism for the creation of this value.

Section 7 of Brazil DCR needs a client provision section created with the following text.

if required, shall calculate tls_client_auth_subject_dn by using x.500 AttributeType name strings defined in the Distinguished Name of the x.509 Certificate Profiles defined in Open Banking Brasil x.509 Certificate Standards;

And an appendix example created with a PEM and a corresponding value.

[joaorodolfo]

We will include it at Security WG agenda and keep it updated.

[lujunior]

I leave as a suggestion use RFC 2253, to deal with how to read the client certificate subj and convert this as a String to be used in the DCR body.

[bernardoVale]

I leave as a suggestion use RFC 2253, to deal with how to read the client certificate subj and convert this as a String to be used in the DCR body.

RFC 2253 is obsoleted by RFC 4514

[ginglass]

Hello guys.

This attribute tls_client_auth_subject_dn is not required by DCR RFC7591, right? It is used as part of oAuth2 process when using MTLS (as RFC 8705), right? The main problem is the way AS decode a certificate subject DN (it have to follow RFC4514, but could use long or short names etc), right? On OBB, the registration endpoint is protected by MTLS (the client shall use the same transport certification presented at transport.jwks), so as it (AS) has the client certificate (received at SSL level) it could check with software_transport_uri value (signed by directory), decode it as "AS wants" and include the decoded subject_dn string on registration response, doesn't it? The TTP/client shall keep this information (as it have to keep client_is/client_secret) and use it for auth purpose as defined at RFC8705...

To be more specific... Why the AS doesn't get the TTP client certificate received at SSL level, validate it with software_transport_uri value (signed by directory), decoded it as "AS wants" and include the decoded subject_dn string on registration response? This way doesn't matter how AS decode the ASN1 info... The point is the TTP/client shall keep this information (as it have to keep client_is/client_secret) and use it on tls_client_auth_subject_dn attribute for auth purpose as defined at RFC8705.

Did I miss something here? Is there any security related issue or any protocol violation (RFC7591)?

Best regards

[RalphBragg]

@ginglass - yes it is required as part of MTLS https://datatracker.ietf.org/doc/html/rfc8705#section-2.1.2 The rest of your points are exactly spot on. Brazil requires that DCR is performed over a mutual TLS channel. Banks therefor should be making sure that they are confident that the MTLS channel is authenticated by the owner of the software statement. This property when used over DCR is nearly entirely superfluous... nearly.

[joaorodolfo]

In terms of format, the Security WG have defined the examples in bellow:

• Start backwards, the order is reversed from what is entered.
• Append each RDN (RelativeDistinguishedName) segment with a comma ‘,’
• Use RFC Strings (CN, L, ST, O, OU, C, Street, DC, UID) + OBB Certificate Specs (businessCategory, jurisdictionCountryName , serialNumber)

Examples: subject_dn	Issuer
subject_dn	Issuer
--	--
UID=67c57882-043b-11ec-9a03-0242ac130003,jurisdictionCountryName=BR,businessCategory=Private Organization,serialNumber=00038166000954,CN=mycn.bank.com.br,OU=497e1ffe-b2a2-4a4e-8ef0-70633fd11b59,O=MY BANK SA,L=SAO PAULO,ST=SP,C=BR	issuer=CN=Open Banking SANDBOX Issuing CA - G1,OU=Open Banking,O=Open Banking Brasil,C=BR
UID=67c57882-043b-11ec-9a03-0242ac130003, jurisdictionCountryName=BR,businessCategory=Business Entity,CN=mycn.bank.gov.br,serialNumber=00038166000954,OU=497e1ffe-b2a2-4a4e-8ef0-70633fd11b59,O=My Public Bank,L=BRASILIA,ST=DF,C=BR	issuer=CN=Autoridade Certificadora do SERPRO SSLv1,OU=Autoridade Certificadora Raiz Brasileira v10,O=ICP-Brasil,C=BR,jurisdictionCountryName=BR,businessCategory=Private
Organization,UID=67c57882-043b-11ec-9a03-0242ac130003,CN=openbanking.mybank.com.br,serialNumber=00038166000954,OU=497e1ffe-b2a2-4a4e-8ef0-70633fd11b59,L=Goiania,ST=GO,O=MyBank SA,C=BR	issuer=CN=AC SOLUTI SSL EV,OU=Autoridade Certificadora Raiz Brasileira v10,O=ICP-Brasil,C=BR
CN=mycn.bank.com.br,UID=67c57882-043b-11ec-9a03-0242ac130003,OU=497e1ffe-b2a2-4a4e-8ef0-70633fd11b59,L=Sao Paulo,ST=SP,O=MyBank SA,C=BR,serialNumber=00038166000954, jurisdictionCountryName=BR,businessCategory=Private Organization	issuer=CN=AC SERASA SSL EV,OU=Autoridade Certificadora Raiz Brasileira v10,O=ICP-Brasil,C=BR

It's will be published into specs and FAQ.

[RalphBragg]

Remember if you mandate aspsp’s validate this field on a continuous basis, or if aspsp’s use this field on a continuous basis to check for a match for a transport certificate then you’ll have significant challenges for TPPs when it comes to renewals.

Trying to rely on the exact match every time really will cause long term issues. Banks need to understand what the identifiers are and then confirm that the appropriate identifiers are present however they choose to do so.

Banks should be encouraged to think about the user journey if a TPP wants to change certificate supplier.

[alexandre-stockhausen]

@joaorodolfo @alex-siqueira @ginglass

Não estamos conseguindo prosseguir com a recertificação do DCR devido a esta definição.

https://gitlab.com/openid/conformance-suite/-/issues/964

Qual o posicionamento do GT Segurança?

[joaorodolfo]

@alexandre-stockhausen os documentos de DCR já foram atualizados e estão aderentes aos testes de DCR. Qualquer dificuldade por favor direcionar o problema via Squad de Operação Fase 2/3 através da sua associação.