Re: Using UPN from subjectAltName with SSLUserName

[Jan Kaluža <jk...@redhat.com>]

On 06/29/2015 03:14 PM, Jan Pazdziora wrote:
> On Mon, Jun 29, 2015 at 01:47:45PM +0200, Jan Pazdziora wrote:
>> On Sun, Jun 28, 2015 at 05:11:57PM +0200, Kaspar Brand wrote:
>>> On 22.06.2015 10:37, Jan Pazdziora wrote:
>>>> Please find a new patch attached which I hope covers all the
>>>> parts you've outlined, for SSL_CLIENT_SAN_OTHER_msUPN_*.
>>>
>>> Thanks. Your implementation assumes that only a single otherName form
>>> (msUPN) needs to be supported, but I would prefer to code it in a
>>> somewhat more extensible way.
>>>
>>> Does the attached patch work for you? As a practical way of
>>
>> Yes it does.
>>
>> My only question (and comments bellow) is about passing the oid rather
>> than nid through the functions. I can see the string "id-on-dnsSRV"
>> used twice in the patch in call OBJ_txt2nid and twice in call OBJ_txt2obj
>> as well when ideally all which should be needed one
>> OBJ_txt2nid("id-on-dnsSRV") and one OBJ_create if not found -- the rest
>> could be done by comparing integers (nid). Unless I'm missing something
>> about the oid/nid interaction.
>
> Ah, now I see it -- you look at the semantics of oid to compare
> value->type so nid would not be enough.
>
> How about just passing char * and doing all the mapping logic
> including possible OBJ_create in parse_otherName_value? My goal here
> is to have all the "hard" work of determining the semantics isolated
> in one place.
>
> Please see patch attached.

Hi Kaspar,

please could you find some time to review this patch?

I can say that both proposed patches (your and Jan's) are equivalent 
when it comes to implementation functionality. Unfortunately, I don't 
have the OpenSSL knowledge to comment the differences on technical 
level, but I would also like to see this functionality in the trunk :).

Regards,
Jan Kaluza