Re: Certification/Endpoint Identification

Ran Atkinson <rja@inet.org> Tue, 09 September 1997 01:14 UTC

Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id VAA22660 for ipsec-outgoing; Mon, 8 Sep 1997 21:14:38 -0400 (EDT)
Date: Tue, 09 Sep 1997 00:59:00 +0000
From: Ran Atkinson <rja@inet.org>
Subject: Re: Certification/Endpoint Identification
To: EKR <ekr@terisa.com>, ipsec@tis.com
X-Mailer: Chameleon ATX 6.0, Standards Based IntraNet Solutions, NetManage Inc.
X-Priority: 3 (Normal)
References: <199709082138.OAA17029@itech.terisa.com>
Message-ID: <Chameleon.873763578.rja@c8-a.snvl1.sfba.home.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
Sender: owner-ipsec@ex.tis.com
Precedence: bulk

--- On Mon, 08 Sep 1997 14:39:00 -0700  EKR <ekr@terisa.com> wrote:

> I don't want this to turn into a naming problem, but I think
> we're going to need to describe some canonical rules to map
> IPSEC DOI style names (as represented in the Identification
> payload) to certificates. 

Please consider that not all of the identities were designed with
X.509 in mind -- several of them were quite explicitly designed
to work well with signed KEY records from Secure DNS.  Details
below.

> So, for instance, we might have the following text in the
> IPSEC DOI:

The IPsec DOI is probably the wrong place to put it 
since your proposed new text (below) is very X.509-centric 
and the IPsec DOI should be _neutral_ with respect to 
which certificate/signed-key technology is used.

Note also that X.509/PKIX is not yet a standards-track RFC,
while Secure DNS is a Proposed Standard (RFC-2065).  This
seems pretty germane since we're working in the IETF.

> The Identification payload SHOULD be checked against the 
> subjectAltName field of the end-entity certificate. The 
> following table describes the correspondence between 
> Identification types and subjectAltName types
> 
>    ID_IPV4_ADDR                        ipAddress

	OR use a KEY record bound to a DNS A record.

>    ID_FQDN                             dNSName
	OR use a KEY record bound to a FQDN in the DNS.

>    ID_USER_FQDN                        rfc822Name
	OR use a KEY record bound to a DNS MB record.

>    ID_IPV6_ADDR                        ????
	OR use a KEY record bound to a DNS AAAA record.


> Unfortunately, there don't seem to be correspondences in
> PKIX Part I for wildcarding of the ipAddress name, so I'm
> not sure how to deal with those. But I think this is generally
> the right approach to follow. Mainly, though, it's important
> that the drafts say something concrete about this topic.

Perhaps there should be a separate (very short) draft on
(bidirectionally) mapping X.509/PKIX certificates 
into the IPsec DOI context.  That could reasonably be a
PKIX WG item or an IPsec WG item.

However, given that some of us plan to use Secure DNS to
distribute the signed keys and don't plan to use X.509,
please don't put text into the IPsec DOI that is X.509-centric.

Thanks,

Ran
rja@inet.org