[Dovecot] Username from rfc822Name subject alternative name
Hello,
I'm looking into adding support for extracting the username from client certificate's rfc822Name (from the subjectAltName extension).
The question I have is what would be the best approach to do this? Current implementation has a kind of clean code since it just goes through the subject name, extracting the values with X509_NAME_get_text_by_NID (while NID is obtained with OBJ_txt2nid). If I were to add this, it's bound to make the code a little bit more complicated since SAN's can't be retrieved in the same way.
So far in terms of options I have, I can see the following:
Create a distinct configuration option for the ssl_cert_username_field (i.e. specify something like "sanrfc822Name" to have Dovecot extract the username from the designated alternative name).
Make the current code fail-over to rfc822Name SAN if emailAddress is provided for ssl_cert_username (less invasion in code, but less flexibility as well).
Any input/recommendation/directioning is welcome. I've wanted to actually first write a patch, and then submit it, but I think it might be better to check what would be preferable by Dovecot maintainers/devs.
Best regards
-- Branko Majic Jabber: branko@majic.rs Please use only Free formats when sending attachments to me.
Бранко Мајић Џабер: branko@majic.rs Молим вас да додатке шаљете искључиво у слободним форматима.
On 9.4.2012, at 16.51, Бранко Мајић wrote:
I'm looking into adding support for extracting the username from client certificate's rfc822Name (from the subjectAltName extension).
The question I have is what would be the best approach to do this? Current implementation has a kind of clean code since it just goes through the subject name, extracting the values with X509_NAME_get_text_by_NID (while NID is obtained with OBJ_txt2nid). If I were to add this, it's bound to make the code a little bit more complicated since SAN's can't be retrieved in the same way.
So far in terms of options I have, I can see the following:
- Create a distinct configuration option for the ssl_cert_username_field (i.e. specify something like "sanrfc822Name" to have Dovecot extract the username from the designated alternative name).
I'm not sure if this is a good idea, but what about:
ssl_cert_username_field = subjectAltName:rfc822Name
- Make the current code fail-over to rfc822Name SAN if emailAddress is provided for ssl_cert_username (less invasion in code, but less flexibility as well).
Automatic failover seems dangerous.
Another solution could be having another property that specifies whether the information should be pulled in from subject or subjectAltName.
But I think what you've proposed would be ok as well, and it'd allow for future expansion too (if anyone decides to use some other SAN). I can get working on adding the support for this (might take a couple of days until I sort it out - getting quite busy here :).
Would a patch both against the 1.x and 2.x be welcome?
Дана Tue, 10 Apr 2012 19:10:04 +0300 Timo Sirainen tss@iki.fi написа:
On 9.4.2012, at 16.51, Бранко Мајић wrote:
I'm looking into adding support for extracting the username from client certificate's rfc822Name (from the subjectAltName extension).
The question I have is what would be the best approach to do this? Current implementation has a kind of clean code since it just goes through the subject name, extracting the values with X509_NAME_get_text_by_NID (while NID is obtained with OBJ_txt2nid). If I were to add this, it's bound to make the code a little bit more complicated since SAN's can't be retrieved in the same way.
So far in terms of options I have, I can see the following:
- Create a distinct configuration option for the ssl_cert_username_field (i.e. specify something like "sanrfc822Name" to have Dovecot extract the username from the designated alternative name).
I'm not sure if this is a good idea, but what about:
ssl_cert_username_field = subjectAltName:rfc822Name
- Make the current code fail-over to rfc822Name SAN if emailAddress is provided for ssl_cert_username (less invasion in code, but less flexibility as well).
Automatic failover seems dangerous.
-- Branko Majic Jabber: branko@majic.rs Please use only Free formats when sending attachments to me.
Бранко Мајић Џабер: branko@majic.rs Молим вас да додатке шаљете искључиво у слободним форматима.
I can add the patch to v2.1, but probably not to earlier versions.
On 11.4.2012, at 0.07, Бранко Мајић wrote:
Another solution could be having another property that specifies whether the information should be pulled in from subject or subjectAltName.
But I think what you've proposed would be ok as well, and it'd allow for future expansion too (if anyone decides to use some other SAN). I can get working on adding the support for this (might take a couple of days until I sort it out - getting quite busy here :).
Would a patch both against the 1.x and 2.x be welcome?
Дана Tue, 10 Apr 2012 19:10:04 +0300 Timo Sirainen tss@iki.fi написа:
On 9.4.2012, at 16.51, Бранко Мајић wrote:
I'm looking into adding support for extracting the username from client certificate's rfc822Name (from the subjectAltName extension).
The question I have is what would be the best approach to do this? Current implementation has a kind of clean code since it just goes through the subject name, extracting the values with X509_NAME_get_text_by_NID (while NID is obtained with OBJ_txt2nid). If I were to add this, it's bound to make the code a little bit more complicated since SAN's can't be retrieved in the same way.
So far in terms of options I have, I can see the following:
- Create a distinct configuration option for the ssl_cert_username_field (i.e. specify something like "sanrfc822Name" to have Dovecot extract the username from the designated alternative name).
I'm not sure if this is a good idea, but what about:
ssl_cert_username_field = subjectAltName:rfc822Name
- Make the current code fail-over to rfc822Name SAN if emailAddress is provided for ssl_cert_username (less invasion in code, but less flexibility as well).
Automatic failover seems dangerous.
-- Branko Majic Jabber: branko@majic.rs Please use only Free formats when sending attachments to me.
Бранко Мајић Џабер: branko@majic.rs Молим вас да додатке шаљете искључиво у слободним форматима.
participants (3)
-
Timo Sirainen
-
Бранко Мај ић
-
Бранко Мајић