Re: Certification/Endpoint Identification

EKR <ekr@terisa.com> Tue, 09 September 1997 02:17 UTC

Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id WAA22967 for ipsec-outgoing; Mon, 8 Sep 1997 22:17:42 -0400 (EDT)
Message-Id: <199709090227.TAA18569@itech.terisa.com>
To: Ran Atkinson <rja@inet.org>
cc: ipsec@tis.com
Subject: Re: Certification/Endpoint Identification
In-reply-to: Your message of "Tue, 09 Sep 1997 00:59:00 EST." <Chameleon.873763578.rja@c8-a.snvl1.sfba.home.com>
Date: Mon, 08 Sep 1997 19:28:05 -0700
From: EKR <ekr@terisa.com>
Sender: owner-ipsec@ex.tis.com
Precedence: bulk

Ran, 

	You're right, I was only thinking of X.509 when I wrote
my message. Actually the scope of the problem is a lot worse than
I had originally thought:
      
draft-ietf-ipsec-isakmp-08.txt lists the following 
certificate types:
                __________Certificate_Type___________Value___
                 NONE                                  0
                 PKCS #7 wrapped X.509 certificate      1
                 PGP Certificate                        2
                 DNS Signed Key                         3
                 X.509 Certificate - Signature          4
                 X.509 Certificate - Key Exchange       5
                 Kerberos Tokens                        6
                 Certificate Revocation List (CRL)      7
                 Authority Revocation List (ARL)        8
                 SPKI Certificate                       9
                 RESERVED                            10- 255

Now, we can ignore PKCS#7 certs (cause they're just a wrapper for
X.509), CRLs and ARLs, but all the other certificate types
(with the possible exception of SPKI certificates) do in fact
bind keying material to Identity and they all have their own
representations of Identity.

For each of these, we need to describe how to map these to the
Identification payloads listed in the DOI. This can be
done either in the DOI draft or (as you suggest) in separate
drafts.

You write:
[...snip....]
> > 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.
This is fine as far as it goes, but it omits all the 
wildcarded types, which are really my main concern:

   ID_IPV4_ADDR_SUBNET                 ????
   ID_IPV6_ADDR_SUBNET                 ????
   ID_IPV4_ADDR_RANGE                  ????
   ID_IPV6_ADDR_RANGE                  ????

I suppose that we could simply list Identification<->Name 
mapping rules for each certificate type (loosely considering
Secure DNS KEY RRs as being certificates) and prohibit
use of any Identification payloads/Certificate combinations
where the names couldn't be mapped (e.g. if one decided
not to map the wildcarded types) but we should at least
do that, I would think.

-Ekr

[Eric Rescorla                             Terisa Systems, Inc.]
		"Put it in the top slot."