Subject: Re: PKINIT-26 changes: identifying the kdc certificates

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 01 Aug 2005 15:53:36 +0200

On Monday, July 18, 2005 08:46:44 -0400 Jeffrey Hutzelman <[email-masked]> 
wrote:

> On Wed, 25 May 2005, Sam Hartman wrote:
>
>> We seem to be binding two problems together that traditionally are not
>> bound together in RFC 3280.  I'm uncomfortable with our choice and if
>> we do this we need to have a clear justification for why.
>>
>> 1) Is this cert appropriate to use as a pkinit cert
>>
>> 2) Does this cert refer to the KDC who I as a client want to talk to.
>>
>>
>> I'm also concerned that this discussion is diverging rather than
>> converging.
>
> So am I, particularly with the benefit of a couple of months worth of
> hindsight.  So, I'd like to take a step back for a moment...
>
> As Sam noted, there are basically two problems to be answered when
> a client is evaluating a KDC's certificate (they are quoted above).  In
> order to accept the certificate, the client MUST be able to determine that
> the answers to both questions are "yes".  The issues are orthogonal, and
> should be evaluated independently by the client.  Our job in specifying
> PKINIT is to define one or more tests for each question, and to specify a
> REQUIRED test for each question.
>
> In this case, what REQUIRED means for a test is that the client MUST
> implement that test.  Put another way, if a certificate passes the
> REQUIRED test for either question, then a compliant client MUST consider
> the certificate to satisfy that question.  What REQUIRED does _not_ mean
> is that all certificates must pass the REQUIRED test, or that clients are
> not permitted to support other tests.
>
> Here are some possible tests for question (1):
> (a) Correct TGS principal name in id-pksan(*)
> (b) Presence of id-pkkdcekuoid
> (c) Local policy
>
> Here are some possible tests for question (2):
> (a) Correct TGS principal name in id-pksan
> (b) Realm name in dnsName SAN
> (c) Stefan's SRV RR SAN
> (d) Realm name in CN
> (e) Local policy
>
> The text as it appears in -26 permits any of 1A, 2B, or 1C.
> It also permits either of 2A or 2E.
> The REQUIRED tests are 1A and 2A, the presence of a correct id-pksan.
>
> Now, the questions...
> - Does anyone disagree with my statement of the problem?
> - Does anyone disagree with my interpretation of the -26 text?
> - Does anyone think the set of tests called out in -26 is not enough?
> - Does anyone think the REQUIRED tests should be something else?
>
> Of course, you are all welcome and encouraged to respond to these even if
> your answers are "no".  Lots of answers along those lines would tend to
> suggest there is a consensus...
>
>
> (*) A _correct_ princiapl name is required here because without it, the
> presence of id-pksan suggests this cert is for Kerberos, but not that it
> is for a KDC.  Particularly, consider a cert which has dnsName EXAMPLE.COM
> and id-pksan HTTP/[email-masked].  Such a cert is clearly not
> intended to be used by a KDC.

Well.

This was the subject of about 75 minutes of discussion in Paris this week, 
in which we reached some conclusions and failed to reach others.

The sense of the room was that my statement of the problem was correct, as 
was my interpretation of the language in PKINIT-26 (and now, -27).

No one proposed adding any tests which are not already described in -27.
And, no one disagreed that the 1a/2a test combination should be REQUIRED 
for clients to implement.

So much for the good news.  The bad news is, we don't seem to have 
consensus on what to do with the EKU, or even whether to have one.

It seems to me that in any given situation, we can do one of the following:

(å) Require the Kerberos KDC EKU to be present
(ä) Require the Kerberos KDC EKU, or the "any" EKU, or no EKU extension.
(ö) Make no requirements on the EKU extension or presence thereof.

I believe we have consensus that if rule 1a is satisfied, then we need not 
have any EKU requirements.  The disagreement is as to what happens in cases 
where rule 1a is _not_ satisfied.  For this situation, all three of the 
above choices have been proposed.  We need to decide which is appropriate, 
in order to resolve this ticket.

I'm not going to attempt to summarize the arguments for each of choices Å, 
Ä, and Ö (alternately, AA, AE, OE).  Instead, I will ask the proponents of 
each choice to make their arguments.

-- Jeff