Subject: RE: Do we need KRB5PrincipalName name constraints in PKINIT

From: "Paul Leach" <[email-masked]>
Date: Sun, 11 Sep 2005 22:04:13 -0700

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Jeffrey
Hutzelman
Sent: Sunday, September 11, 2005 9:34 PM

On Friday, September 09, 2005 18:27:00 -0700 Paul Leach 
<[email-masked]> wrote:

> [Paul Leach] It isn't necessary that we suggest that they use DNS
names
> to name their realms in order to suggest that _if_ they happen to name
> their realms with DNS names they might want to use dNSName SAN in
their
> KDC certs

<chair hat on>
Except that we've already decided not to say this...

[Paul Leach] With all the talk about dNSName on the list, I didn't
realize that the draft doesn't mention it at all. (I apologize. Now I
realize why some of my name constraint comments weren't making sense to
people.)

I think that means there's an interop problem. Section 3.2.2 of the
draft says:

   "In addition to validating the client's signature, the KDC MUST also
   check that the client's public key used to verify the client's
   signature is bound to the client's principal name as specified in the
   AS-REQ as follows:

   1. If the KDC has its own binding between either the client's
      signature-verification public key or the client's certificate and
      the client's Kerberos principal name, it uses that binding.

   2. Otherwise, if the client's X.509 certificate contains a Subject
      Alternative Name (SAN) extension carrying a KRB5PrincipalName
      (defined below) in the otherName field of the type GeneralName
      [RFC3280], it binds the client's X.509 certificate to that name."

Similarly, section 3.2.4 says:
   "In addition, unless the client
   can otherwise verify that the public key used to verify the KDC's
   signature is bound to the KDC of the target realm, the KDC's X.509
   certificate MUST contain a Subject Alternative Name extension
   [RFC3280] carrying an AnotherName whose type-id is id-pksan (as
   defined in Section 3.2.2) and whose value is a KRB5PrincipalName that
   matches the name of the TGS of the target realm (as defined in
   Section 7.3 of [RFC4120])."

However, the draft does not say that support of id-pksan is
mandatory-to-implement. I.e., in both these places, private
implementation agreements are allowed, but an standard interoperable
mechanism is not required to be implemented. (At least as far as I could
see.)

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 12 Sep 2005 01:15:55 -0400

> mechanism is not required to be implemented. (At least as far as I could

Hm; indeed.
This is now ticket #1133.

-- Jeff