On Thu, Jul 03, 2014 at 12:28:20PM -0400, Jeffrey Walton wrote:
> Right, but what is the baseline behavior with (and without) wild cards
> in a certificate's DNS name?
The opposite of each flag bit. Wildcards are supported, match only
in the left-most label, but may match a part of that label with an
explicit prefix or suffix.
> Does the entire RFC 6125 apply for hostname matching? If so, two points:
>
> (1) X509_check_host(3)'s description only references tRFC 6125
> for IDNs presentation, and not the entirety of hostname
> matching.
6125 is a litany of woes, not a fixed standard. The flag bits determine
which of the malignancies you tolerate or avoid.
> (2) The certificates being issued for many sites and services use
> CA/B Forums Baseline Requirement (and EV Guide); and *not*
> the IETF's documents.
The responsibility to not issue wildcard EV certs is on the CA.
> In my naiveness, it seems to beg for an API that allows one to load a
> profile for matching (IETF vs CA/B). That is, if my client visits a
> public website, then I'm probably dealing with a certificate from the
> CA/Browser cartel and one set of policies would apply. if I am using a
> VPN from an organization's internal PKI , then another set of policies
> would apply.
Set the flag bits accordingy for each connection.
> > No, it is exactly what is described. When the bit is clear such partial
> > wildcards are allowed.
>
> So I'm clear (and forgive my ignorance): wildcards will be allowed in
> places other than the leftmost label?
No.
> >> What is the purpose of allowing a leading dot for a hostname? I.e.,
> >> why is ".example.com" allowed?
> >
> > It allows the verifier to specify a parent domain, rather than a
> > particular host. Any host in that domain or sub-domain matches.
>
> So I'm clear (and forgive my ignorance): is that like ** in some other
> languages? I.e., *.example.com would match www.example.com,
> mail.example.com, etc; while **.example.com would match
> www.sub.example.com, www.sub1.sub2.example.com, mail.sub.example.com,
> mail.sub1.sub2.example.com, etc.
No, ".example.com" matches at any depth by default, by IIRC I added
a flag to restrict this to direct child-only matches.
> >> Is there an intersection with EV OIDs? Or is it out of scope for host
> >> name matching?
> >
> > EV is about whether the certificate is trusted by browsers. It
> > has nothing to do with namechecks.
>
> >> According to the CA/B EV Guide, wildcards are not
> >> allowed in EV certificates. So I would expect a wilcarded cert to be
> >> rejected as malformed if its an EV certificate.
> >
> > Applications that process EV certs can disable wildcards in name checks
> > via the appropriate flag.
>
> OK, is that something that should be left to the application
> developer? Does an application developer expect the functionality?
Nobody other than browser vendors needs to worry about EV. The EV
CA is responsible for applying the CA/B policy. Applications are
free to require EV certs if they know how via the verification
callback.
> > The specified reference identity either matches or not.
>
> Well, I believe its much more than simple matching. If an application
> naively approaches name matching, then the adversaries will thank
> them.
This statement lacks any factual content.
> > This is too complex an interface. You specify how matching is to
> > be done, and then it either works or does not. Keep in mind that
> > you should not explicitly use X509_check_host() if at all possible.
>
> Then shouldn't it be a priavte interface named x509_check_host that's
> only available internally and exported in test configurations for
> testing?
No, some applications want a bit more control.
> > Instead use X509_VERIFY_PARAM_set1_host(), then name checks are
> > performed as needed. The verify callback is called with an error status
> > if the fail.
>
> If a client application calls `SSL_set_tlsext_host_name`, does it also
> need to call `X509_VERIFY_PARAM_set1_host()`? Or do we need to call
> both? Is there a SSL_* function to set the X509 hostname verification
> flags?
Yes. And please read the related documentation linked from the manpage.
--
Viktor.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
