Re: Common Name and IDNA

2004-06-21 Thread Joe Orton
On Fri, Jun 18, 2004 at 06:14:41AM -0700, Lev Walkin wrote:
 Gisle Vanem wrote:
 Lev Walkin [EMAIL PROTECTED] said:
 
 
 No, fnmatch() is fairly portable across Unixes though.
 
 
 Please note that fnmatch() use is against RFC2818.
 
 
 Please explain why.
 
 Because *.domain.com shouldn't match abc.def.ghi.domain.com
 per RFC2818#3.1, as it does with fnmatch().

Good point.  I didn't really mean to advocate use of fnmatch; in my own
code I simply check for a leading *. matching any leading component in
the hostname which is safe and seems to be sufficient for most deployed
certs.

joe
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]


Re: Common Name and IDNA

2004-06-18 Thread Gisle Vanem
Lev Walkin [EMAIL PROTECTED] said:

  No, fnmatch() is fairly portable across Unixes though.
 
 
 Please note that fnmatch() use is against RFC2818.

Please explain why.

--gv

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]


Re: Common Name and IDNA

2004-06-18 Thread Lev Walkin
Gisle Vanem wrote:
Lev Walkin [EMAIL PROTECTED] said:

No, fnmatch() is fairly portable across Unixes though.

Please note that fnmatch() use is against RFC2818.

Please explain why.
Because *.domain.com shouldn't match abc.def.ghi.domain.com
per RFC2818#3.1, as it does with fnmatch().
However, most application programmers, including IE ones, seem
to ignore this.
But for this reason alone, I don't think my comment should be
taken too seriously. It is one of the many discrepancies between
RFCs and the real world we have to deal with.
--
Lev Walkin
[EMAIL PROTECTED]
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]


Re: Common Name and IDNA

2004-06-16 Thread Lev Walkin
Joe Orton wrote:
On Sat, Jun 12, 2004 at 07:38:42PM +0200, Gisle Vanem wrote:
How is the /CN= supposed to be encoded for a host/domain-
name using international characters? In some specified charset
(utf8?) or in the ASCII Compatible Encoded form?
I ask since in an application here (using libidn), I get the subject
with X509_get_subject_name() and check the CN (or wildcard
mask) against the host I connect to. If they don't match, that's
an error.
E.g. if I connect to www.troms.no, it's registered in DNS as
www.xn--troms-zua.no. Should the CN be the same also? Is it
an error to match the CN against www.troms.no too? Guessing
beeing liberal is okay...

I think it's correct to put the ACE form in the commonName, and that's
what applications should compare against.  IDNA is after all supposed to
be an *application*-layer encoding; at the protocol layer, nothing
changes, normal ASCII DNS names are used.  This is true at HTTP level as
well as at DNS level, so there's no reason why SSL should be special.

BTW. is there any function in OpenSSL that can match
e.g. x*.foo.com against xxx.foo.com?

No, fnmatch() is fairly portable across Unixes though.

Please note that fnmatch() use is against RFC2818.
--
Lev Walkin
[EMAIL PROTECTED]
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]


Re: Common Name and IDNA

2004-06-15 Thread Joe Orton
On Sat, Jun 12, 2004 at 07:38:42PM +0200, Gisle Vanem wrote:
 How is the /CN= supposed to be encoded for a host/domain-
 name using international characters? In some specified charset
 (utf8?) or in the ASCII Compatible Encoded form?
 
 I ask since in an application here (using libidn), I get the subject
 with X509_get_subject_name() and check the CN (or wildcard
 mask) against the host I connect to. If they don't match, that's
 an error.
 
 E.g. if I connect to www.troms.no, it's registered in DNS as
 www.xn--troms-zua.no. Should the CN be the same also? Is it
 an error to match the CN against www.troms.no too? Guessing
 beeing liberal is okay...

I think it's correct to put the ACE form in the commonName, and that's
what applications should compare against.  IDNA is after all supposed to
be an *application*-layer encoding; at the protocol layer, nothing
changes, normal ASCII DNS names are used.  This is true at HTTP level as
well as at DNS level, so there's no reason why SSL should be special.

 BTW. is there any function in OpenSSL that can match
 e.g. x*.foo.com against xxx.foo.com?

No, fnmatch() is fairly portable across Unixes though.

Regards,

joe
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]


Re: Common Name and IDNA

2004-06-15 Thread Joe Orton
On Mon, Jun 14, 2004 at 12:11:33PM -0400, Jeffrey Altman wrote:
 What follows is simply my opinion but I believe it to be correct:
 
 The name must match the text the user entered when specifying the
 desired host. As such there are multiple input forms which resolve to
 the same name.  Instead of using Common Name you should use
 subjectAltName and provide two entries; one for each of the UTF8
 representation and the ACE representation.

But subjectAltName's dNSName is an IA5String (similarly for the URI), so
you *cannot* put anything but ASCII in there currently.  This is all
covered in RFC3280 with an arrgh, i18n DNS, let's solve that later
proviso :)

Regards,

joe
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]


Re: Common Name and IDNA

2004-06-14 Thread Jeffrey Altman
What follows is simply my opinion but I believe it to be correct:
The name must match the text the user entered when specifying the 
desired host.
As such there are multiple input forms which resolve to the same name.  
Instead of
using Common Name you should use subjectAltName and provide two entries; one
for each of the UTF8 representation and the ACE representation.

Jeffrey Altman
Gisle Vanem wrote:
How is the /CN= supposed to be encoded for a host/domain-
name using international characters? In some specified charset
(utf8?) or in the ASCII Compatible Encoded form?
I ask since in an application here (using libidn), I get the subject
with X509_get_subject_name() and check the CN (or wildcard
mask) against the host I connect to. If they don't match, that's
an error.
E.g. if I connect to www.tromsø.no, it's registered in DNS as
www.xn--troms-zua.no. Should the CN be the same also? Is it
an error to match the CN against www.tromsø.no too? Guessing
beeing liberal is okay...
BTW. is there any function in OpenSSL that can match
e.g. x*.foo.com against xxx.foo.com?
IDNA = Internationalizing Domain Names in Applications, RFC-3490.
--gv
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]
 



smime.p7s
Description: S/MIME Cryptographic Signature