Re: implement subject alternative names support for SSL connections

On Mon, Aug 25, 2014 at 12:02 PM, Heikki Linnakangas <
hlinnakangas(at)vmware(dot)com> wrote:

> On 08/24/2014 03:11 PM, Alexey Klyukin wrote:
>
>> On Wed, Aug 20, 2014 at 11:53 AM, Heikki Linnakangas <
>> hlinnakangas(at)vmware(dot)com> wrote:
>>
>>>
>>> The patch doesn't seem to support wildcards in alternative names. Is
> that on purpose?
>

Not really, we just did not have any use case for them, but it seems that
RFC 5280 does not disallow them:

" Finally, the semantics of subject alternative names that include
wildcard characters (e.g., as a placeholder for a set of names) are
not addressed by this specification. Applications with specific
requirements MAY use such names, but they must define the semantics."

I've added support for them in the next iteration of the patch attached to
this email.

>
> It would be good to add a little helper function that does the NULL-check,
> straight comparison, and wildcard check, for a single name. And then use
> that for the Common Name and all the Alternatives. That'll ensure that all
> the same rules apply whether the name is the Common Name or an Alternative
> (assuming that the rules are supposed to be the same; I don't know if
> that's true).
>

Thanks, common code has been moved into a separate new function.

Another question is how should we treat the certificates with no CN and
non-empty SAN?

Current code just bails out right after finding no CN section present , but
the RFC (5280) says:
"
Further, if the only subject identity included in the certificate is
an alternative name form (e.g., an electronic mail address), then the
subject distinguished name MUST be empty (an empty sequence), and the
subjectAltName extension MUST be present.
"
which to me sounds like the possibility of coming across such certificates
in the wild, although I personally see little use in them.

Regards,
--
Alexey Klyukin