[certid] open issue: iPAddress

Peter Saint-Andre <stpeter@stpeter.im> Fri, 09 April 2010 16:40 UTC

Return-Path: <stpeter@stpeter.im>
X-Original-To: certid@core3.amsl.com
Delivered-To: certid@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0758F3A680E for <certid@core3.amsl.com>; Fri, 9 Apr 2010 09:40:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.307
X-Spam-Level:
X-Spam-Status: No, score=-2.307 tagged_above=-999 required=5 tests=[AWL=0.292, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cbGGOnhyh5CO for <certid@core3.amsl.com>; Fri, 9 Apr 2010 09:40:14 -0700 (PDT)
Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 293C23A6972 for <certid@ietf.org>; Fri, 9 Apr 2010 09:40:14 -0700 (PDT)
Received: from dhcp-64-101-72-158.cisco.com (dhcp-64-101-72-158.cisco.com [64.101.72.158]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 6198B40E15 for <certid@ietf.org>; Fri, 9 Apr 2010 10:40:10 -0600 (MDT)
Message-ID: <4BBF5868.2070202@stpeter.im>
Date: Fri, 09 Apr 2010 10:40:08 -0600
From: Peter Saint-Andre <stpeter@stpeter.im>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4
MIME-Version: 1.0
To: certid@ietf.org
References: <201003231544.05651.ludwig.nussel@suse.de> <4BB3C21E.90502@stpeter.im> <201004091443.52205.ludwig.nussel@suse.de>
In-Reply-To: <201004091443.52205.ludwig.nussel@suse.de>
X-Enigmail-Version: 1.0.1
OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms080409040102040108050609"
Subject: [certid] open issue: iPAddress
X-BeenThere: certid@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Representation and verification of identity in certificates <certid.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/certid>, <mailto:certid-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/certid>
List-Post: <mailto:certid@ietf.org>
List-Help: <mailto:certid-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/certid>, <mailto:certid-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 09 Apr 2010 16:40:16 -0000

Regarding inclusion of iPAddress identifiers, Ludwig Nussel and I had
the following exchange...

On 4/9/10 6:43 AM, Ludwig Nussel wrote:
> Peter Saint-Andre wrote:
>> On 3/23/10 8:44 AM, Ludwig Nussel wrote:

<snip/>

>>> 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.

Good point.

However, here again I'm not saying that it's bad to include or check
iPAddress in a cert, only that we're not trying to tackle *that* problem
in *this* spec.

>> 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 :-)

Well, since you've asked so nicely... :)

I'd like more feedback on this issue. I'm open to adding text about
iPAddress because Ludwig is probably right that certificates (e.g.,
certs issued by private CAs) sometimes include iPAddress, but on the
other hand I've never seen a public CA do that.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/