Re: implement subject alternative names support for SSL connections

On 08/28/2014 07:28 PM, Alexey Klyukin wrote:
> 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.

Hmm. So wildcards MAY be supported, but should we? I think we should
follow the example of common browsers here, or OpenSSL or other SSL
libraries; what do they do?

RFC 6125 section 6.4.4 Checking of Common Names says:

> As noted, a client MUST NOT seek a match for a reference identifier
> of CN-ID if the presented identifiers include a DNS-ID, SRV-ID,
> URI-ID, or any application-specific identifier types supported by the
> client.

So, to conform to that we shouldn't check the Common Name at all, if an
alternative subject field is present.

(Relying on OpenSSL's hostname-checking function is starting feel more
and more appetizing. At least it won't be our problem then.)

>> 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.

Yeah, I think a certificate without CN should be supported. See also RFC
6125, section 4.1. "Rules" [for issuers of certificates]:

> 5. Even though many deployed clients still check for the CN-ID
> within the certificate subject field, certification authorities
> are encouraged to migrate away from issuing certificates that
> represent the server's fully qualified DNS domain name in a
> CN-ID. Therefore, the certificate SHOULD NOT include a CN-ID
> unless the certification authority issues the certificate in
> accordance with a specification that reuses this one and that
> explicitly encourages continued support for the CN-ID identifier
> type in the context of a given application technology.

Certificates without a CN-ID are probably rare today, but they might
start to appear in the future.

BTW, should we also support alternative subject names in the server, in
client certificates? And if there are multiple names, which one takes
effect? Perhaps better to leave that for a separate patch.

- Heikki