Peter Saint-Andre wrote: > On 3/23/10 8:44 AM, Ludwig Nussel wrote: > > | If and only if the identity set does not include subjectAltName > > | extensions of type dNSName, SRVName, uniformResourceIdentifier (or > > | other application-specific subjectAltName extensions), the client MAY > > | as a fallback check the value of the Common Name (CN) > > > > What about rewording that to the following? > > > > | If and only if the certificate does not include any subjectAltName > > | extensions, the client MAY as a fallback check the value of the > > | Common Name (CN) > > I don't see a strong reason to change that text. This specification is > about checking domain names, not IP addresses. > > As an aside, I must say that I'm tempted to move everything about CNs to > a separate section, or to remove it entirely, because I don't think it's > a best current practice for secure authentication. > > > That would avoid having generic implementations look into the CN as > > fallback when it doesn't make sense. iPAddress for example isn't > > specified by the I-D (why anyways?). > > 1. Do certification authorities issue certificates to IP addresses? The > ones I work with don't (probably because they base their certification > decision on control over the whois data or reserved email addresses for > a domain name).
I don't know. Think of private CA's used internally by companies. Software that implements the I-D isn't used exclusively on the Internet after all. > 2. If so, is that a best current practice for secure authentication? I > don't think so. > > 3. Users don't expect to connect to "192.0.2.7", they expect to connect > to "example.com". That, at least, is one assumption of this I-D. You are > free to write an I-D that specifies rules for representation and > verification of IP addresses in certificates, but that's out of scope > for this I-D. The problem is that someone actually implementing the identity checks for a program will come across iPAddress sooner or later. Generic implementations like gnutls' gnutls_x509_crt_check_hostname() also have to deal with IP addresses somehow. That RFC you are drafting is such a wonderful chance to have this clarified as well :-) > > So a conforming implementation > > could use the CN when looking for a hostname even if a > > subjectAltName of type iPAddress is present. > > Right. But I don't think that is consistent with your proposed text. Confusing wording, sorry. The above cited sentence refers to the current I-D. My proposal was meant to change that so a conforming implentation must not fall back to CN checking if any subjectAltName is present. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) _______________________________________________ certid mailing list [email protected] https://www.ietf.org/mailman/listinfo/certid
