Re: Certs bearing simple host names and public IP addresses OK?
[EMAIL PROTECTED] wrote: On Jun 9, 2:55 pm, Michael Ströder [EMAIL PROTECTED] wrote: I really wonder what makes a host name an unqualified hostname? One workable definition is a host name without a dot . (ignoring any trailing dots). This would exclude issuing certs for a top-level hostname. This could be a valid assumption though. No doubt that https://www/looks like a valid example to us humans. But how about https://com/(top-level domain)? It doesn't really matter what looks like a valid host name to humans. That's exactly what I meant. ;-) What matters is the policy under which certificates are issued. If a CA is willing to issue certs for com or www to anyone, then the certificate does not guarantee who you're talking to. It depends: If the CA states that the hostname MUST be a fully-qualified domain name then even a hostname without a dot has a well-defined meaning without extra magic. As I noted in a previous posting technically you can't tell without actually trying to lookup a hostname in DNS (without search suffix automagic). It doesn't matter what DNS tells you. But it does matter what the browser asks for. In this threat model, DNS is under the control of the attacker. Yes. What matters is what the browser can deduce from the CA's signature on the certificate. But the browser does the connect based on DNS resolving. Ciao, Michael. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Certs bearing simple host names and public IP addresses OK?
Jean-Marc Desperrier wrote: Michael Ströder wrote: [...] RFC 2818 (only INFORMATIONAL) references RFC 2459 concerning matching rules which was obsoleted by RFC 3280 which was recently obsoleted by RFC 5280. RFC 5280 references Preferred name syntax in RFC 1034. Glancing over these documents I found no provision that the dNSName in subjectAltName MUST specify a fully-qualified domain name. But maybe this issue should raised on the ietf-pkix mailing list. There's no reason to forbid at that level issuance of certificates that are intended to be used only on an intranet. Well, if there are doubts whether https://de/ points to a A/CNAME record in the .de top-level domain or resolves to a local server (by DNS adding search suffix) and is therefore treated as equivalent to https://de.example.test/ then the TLS standard should say something about this. Also matching rules for dNSName are affected. It should be more the policy of the CA that should either refuse to issue such certificates, or require a written agreement that they are intended only for intranet use. Nelson was asking for adding an additional provision to Mozilla's policy. Ciao, Michael. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Certs bearing simple host names and public IP addresses OK?
Michael Ströder wrote: [...] RFC 2818 (only INFORMATIONAL) references RFC 2459 concerning matching rules which was obsoleted by RFC 3280 which was recently obsoleted by RFC 5280. RFC 5280 references Preferred name syntax in RFC 1034. Glancing over these documents I found no provision that the dNSName in subjectAltName MUST specify a fully-qualified domain name. But maybe this issue should raised on the ietf-pkix mailing list. There's no reason to forbid at that level issuance of certificates that are intended to be used only on an intranet. It should be more the policy of the CA that should either refuse to issue such certificates, or require a written agreement that they are intended only for intranet use. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Certs bearing simple host names and public IP addresses OK?
Eddy Nigg (StartCom Ltd.) wrote: For internal networks, internally assigned domain names should be used, like NETWORK = intern.domain.com Thinking further about this whole stuff: I consider the hostname checking to be a very important validation of whether the browser really connects to a host to which the user really wanted to connect to. The user cannot distinguish whether the hostname in https://com is a fully-qualified domain name or not. If DNS resolving with automagic suffix search is conducted then some disambiguation has to be made. So I'd recommend either one of these two solutions: 1. If the user enters https://hostname (hostname without dots) then the DNS resolver should in case of SSL/TLS connects not apply any DNS suffix search list when resolving hostname. 2. If the user enters https://hostname (hostname without dots) and DNS suffix search is conducted the fully-qualified domain name used to connect to the host must be displayed to the user and must be verified to be in the cert. I'd prefer 1. For both solutions only fully-qualified domain names are needed in the certs. Ciao, Michael. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Certs bearing simple host names and public IP addresses OK?
On Sun, Jun 8, 2008 at 6:54 PM, Nelson B Bolyard [EMAIL PROTECTED] wrote: I recently encountered a web site with a certificate that chained through two intermediate CAs to one of Mozilla's trusted roots. This cert's Subject Alt Name (SAN) extension included: - 43 wildcard domain names (e.g. of the form *.something.tld) - 1 non-wildcard DNS name (of the form something.tld) - 4 binary IP addresses (all fully routable and accessible on the Internet) - 4 DNS name strings that were the ASCII dotted decimal form of those 8 IP addresses - 12 simple host names (e.g. such as home, test, www01, www02, ... etc.) The cert's subject name included 60 Common Name (CN=) attributes whose attribute string values matched the 60 name strings in the SAN extension (as if multiple CN attributes each containing a DNS name was conformant). One of the cert's subject name OU attributes contained a string claiming the cert was domain validated. The 44 DNS names don't bother me any. I'm quite willing to believe that the issuer verified that all those domains had the same registrant. But the 12 simple host names and the 4 routable IP addresses (each of which appears twice) bother me. If I go to a url such as https://12.34.56.78/ and get a page with a lock icon claiming to be a bank or financial institution, or even a well known merchant, what assurances has that cert actually offered me? Likewise, if I go to https://home/ and get a home page for some enterprise, what assurances have I really been offered? Does this bother any one else ? There is a bug on certs containing unqualified host names: https://bugzilla.mozilla.org/show_bug.cgi?id=401317 Wan-Teh ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Certs bearing simple host names and public IP addresses OK?
Wan-Teh Chang wrote: There is a bug on certs containing unqualified host names: https://bugzilla.mozilla.org/show_bug.cgi?id=401317 I really wonder what makes a host name an unqualified hostname? No doubt that https://www/ looks like a valid example to us humans. But how about https://com/ (top-level domain)? As I noted in a previous posting technically you can't tell without actually trying to lookup a hostname in DNS (without search suffix automagic). Ciao, Michael. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
