[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Certification/Endpoint Identification

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. 

There are two issues here:
1. Being able to identify which certificate in the certificate
payloads is the end entity certificate and which are supporting
certificates (i.e. other parts of the cert chain such as CAs)
This is an interoperability condition.

2. Being able to verify that the certificate which the
end-entity claims is his matches the identity that the
end-entity claims to have. 
This is a security condition.

I'm separating these because it's easy to imagine satisfying 
(1) while not satisfying (2). E.g. the first certificate payload
is the end-entity.

The obvious thing here is just to use the subjectAltName field.

So, for instance, we might have the following text in the
IPSEC DOI:
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
   ID_FQDN                             dNSName
   ID_USER_FQDN                        rfc822Name
   ID_IPV4_ADDR_SUBNET                 ????
   ID_IPV6_ADDR                        ????
   ID_IPV6_ADDR_SUBNET                 ????
   ID_IPV4_ADDR_RANGE                  ????
   ID_IPV6_ADDR_RANGE                  ????

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.

-Ekr

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