Subject: Options for pkinit KDC certificate identification

From: Sam Hartman <[email-masked]>
Date: Fri, 18 Feb 2005 11:01:20 -0500

Hi.  I discussed the desire to find a solution for identifying KDC
certificates with Russ.  I wanted to confirm my understanding of the
PKIX contstraints on what is reasonable.

To recap the problem, we are looking for two options for identifying
KDC certificates.  The first option needs to work with existing CAs;
there also seems to be a desire to use some Kerberos-specific name
form to identify the certificate.

The original proposal for the first  option was to use a dns name with
_kerberos._tcp.realm_name in the subjectAltName extension of the certificate.

I said that this was a non-starter.  My reading of RFC 3280 is that
there is a strong desire  to use the appropriate name form for
resources being named.  The text explicitly forbids an abuse of the
dns name type similar to what is being contemplated here:

  Finally, the use
     of the DNS representation for Internet mail addresses
     (wpolk.nist.gov
        instead of [email-masked]) MUST NOT be used; such identities are
     to
        be encoded as rfc822Name.

Russ said that the proposed use of dNSName would meet with objections
from the PKIX working group.

In the case of domain-based realm names, Russ and I are both OK with
the name of the realm being encoded as a dNSName and this being used
to identify the KDC certificate.  As Larry pointed out, certificates
of this type might be confused between usage as a KDC certificate and
use for some other purpose.  For example there is a concern that a web
server with the same hostname as the realm name of a Kerberos realm
might be able to pretend to act as a KDC for that realm.

The appropriate way to limit the usage of certificates is with
extended key usages.  Overloading the usage of the cert into tags
added to the front of dNSName subjectAltName extensions is not
appropriate.

The working group needs to choose between unambiguous certificates and
certificates that can be issued without support for a new EKU or
otherName; we can't have it both ways.

Keep in mind that if a CA is concerned about a particular certificate
being confused between Kerberos and some other application,
non-Kerberos uses of that name can be issued a certificate with an
EKU.