Subject: New CONSENSUS CALL - KDC cert naming

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 29 Aug 2005 20:04:21 -0400

On Wednesday, August 10, 2005 07:18:15 PM +0200 Jeffrey Hutzelman 
<[email-masked]> wrote:

>
>
> On Monday, August 01, 2005 15:53:36 +0200 Jeffrey Hutzelman
> <[email-masked]> wrote:
>
>>>> 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.
>>>
>>> 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 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.
>
> This means that for question 2, the only specified tests are and will
> continue to be 2a and 2e.  For question 1, test 1a is clearly permitted;
> resolution of which of tests 1b and 1c to permit in what circumstances is
> unresolved.  The REQUIRED tests are 1a and 2a.
>
> This is a consensus call to validate the above decisions as made during
> the working group meeting.  Please comment on whether you agree or
> disagree with the above decisions.  Note that the EKU issue is still
> outstanding and will be handled separately.

This is part of ticket #837

Ok; here's what I see...

The EKU issue is resolved, and how to deal with question (1) along with it. 
We decided to require the presence of the EKU "unless the client knows by 
some other means that the KDC certificate is intended for a Kerberos KDC". 
I believe we all agree that test 1a meets that requirement, though as I 
noted in a separate message, I think we might need to call that out 
explicitly.

I believe the issue of question (2) is probably also resolved, based on 
what happened during the meeting.  Specifically, clients are required to 
support test 2a or some form of local policy.

I tried to do a consensus call on this a while back, and Sam suggested that 
with the EKU issue unresolved, that might be premature.  Also, there were 
few other comments.  So, I'm going to try again...

I believe the following are true:

- The sense of the WG is that tests 2a (id-pksan) and 2e (local policy) are
  sufficient, and that PKINIT not need explicitly specify any other tests
  of the KDC's identity.

- The sense of the WG is that support for test 2a (id-pksan) should be
  REQUIRED, such that all clients will support certificates which use
  this name type to identify a KDC.

I would like comments from members of the working group indicating whether 
they agree with these two statements.

-- Jeff

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 31 Aug 2005 17:03:42 -0400

On Monday, August 29, 2005 08:04:21 PM -0400 Jeffrey Hutzelman 
<[email-masked]> wrote:

> I would like comments from members of the working group indicating
> whether they agree with these two statements.

And yet, all I hear is a deafening silence.  Anyone???