On 20/4/12 11:17 AM, Paul Bakker wrote:
>
> On 19-4-2012 15:42, Daniel Stenberg wrote:
>> I'm not an TLS/x509 expert but I don't think so. Also, you'll see that
>> for example GnuTLS agrees with my view here and this is how we do it
>> for OpenSSL (for all TLS-using protocols). I haven't checked how the
>> other libs like cyassl or axtls think of this.
>>
>> Are you saying someone actually wants PolarSSL to work the way it
>> works now?
> No not specifically, but never heard issues before either.
>> RFC 6125 is quite specific in section 6.3:
>>
>> Security Warning: 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.
>>
>> (DNS-ID being the name used there for Subject Alternative Name)
>>
> Thanks a lot. That is the RFC that I missed apparently. I'll fix the
> behavior in the upcoming release.
>
> Best regards,
> Paul Bakker

RFC6125 is pretty much re-stating RFC2818's view on how you can match he
information.

RFC2818 has three success opportunities. You match the subject altnames
(dnsname) first _XOR_ take the (most significant) CN field. The special
third option is to let the client check the service certificate on specific
information to conclude that its talking to the expected service, i.e.
matching the certificate against external information.

regards,

        Oscar

-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html