Kafka authorization - Email address in certificate subject name converted with OID - apache-kafka

Question

We use mTLS authentication between clients and Kafka cluster and some ACLs configured on topics.
A client has in his subject name the email address, like:
Owner: EMAILADDRESS=user#my-domain.com, CN=my-service, OU=my-ou, O=my-org, L=my-loc, ST=my-state, C=my-country
But when the client calls kafka cluster we see the email address converted with his [OID code].
[2022-07-13 10:37:32,549] INFO Principal = User:1.2.840.113549.1.9.1=#3uR2XK21ru2nwVymHN9u4B7wQCs4wrhcPavdGktA,CN=my-service,OU=my-ou,O=my-org,L=my-loc,ST=my-state,C=my-country is Denied Operation = Write from host = 10.10.10.2 on resource = Topic:LITERAL:my-topic for request = Produce with resourceRefCount = 1 (kafka.authorizer.logger)
Could someone explain me why this happen and how to get the email address literal instead?
[OID code] https://oidref.com/1.2.840.113549.1.9.1

Answer 1

You cannot get the email address as a literal because Kafka parses the principal DN (Distinguished Name) as described in rfc2253, which doesn't support the EMAILADDRESS attribute. Unsupported attributes are encoded as in your example.
The next step depends on what you're trying to achieve.
If you are trying to use the email address in the ACL rule, then you can do one of:
if you can, issue certificates where the email address is in one of the supported attributes, such as within the CN.
use a script to encode it and get the correct value, which you can use as-is in the ACL rule.
If you don't mean to use the email address, and instead you mean to use other attributes which appear as literals (like the CN), you can either:
If you have access, the best option is to issue certificates without an email in the subject name and create ACL rules accordingly.
Another option might be to use Kafka ssl principal mapping rules to strip the email address and
leave the rest for use in ACL rules. This rule should do the work:
RULE:^1.2.840.113549.1.9.1=.,(CN=.)/$1
Furthermore, EMAILADDRESS oid is deprecated as mentioned here: https://oidref.com/1.2.840.113549.1.9.1 altNames should be used instead. You can see an example here: On certificates, what type should E-mail addresses be when in subjectAltName.