Subject: CALL FOR DISCUSSION - #839 - KDC_ERR_KDC_NOT_TRUSTED

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 14 Mar 2005 18:20:35 -0500

This is ticket #839

The PKINIT spec currently says:

   The KDC MUST return error code KDC_ERR_KDC_NOT_TRUSTED if the client
   did not include a kdcCert field, but did include a trustedCertifiers
   field, and the KDC does not possesses a certificate issued by one of
   the listed certifiers.

Larry proposed dropping this error code, and instead having the KDC behave 
in this case as if the client had not provided a list of trusted 
certifiers; the new behaviour would be REQUIRED.

The following new text appears in PKINIT-25:

   If the client included a trustedCertifiers field, and the KDC does
   not possesses the private key for any one of the listed certifiers,
   the KDC MUST ignore the trustedCertifiers field as if the client did
   not include any.

Unfortunately, I think that text is buggy -- it talks about the KDC knowing 
a certifier's private key, rather than having a cert issued by that 
certifier.  I would propose instead something like the following:

   If the client included a trustedCertifiers field, and the KDC does
   not possesses a certificate issued by one of the listed certifiers,
   the KDC MUST ignore the trustedCertifiers field as if the client did
   not include any.

In addition, Larry has just sent a proposal to the list which has the 
effect of allowing the KDC to treat trustedCertifiers as no more than a 
hint, which can be ignored whenever the KDC wishes.

So, there are really two separate issues here:

(a) Original text vs PKINIT-25 text vs my text above
(b) Whether to accept the additional change Larry proposed today.

I'd like to see comments from the working group on these two questions, so 
that we can resolve this issue.

-- Jeff

---

From: Chaskiel M Grundman <[email-masked]>
Date: Mon, 14 Mar 2005 23:52:10 -0500

> hint, which can be ignored whenever the KDC wishes.

Why not take the next step and pull the feature completely out of the 
specification?

If the kdc has multiple certificates or multiple verification paths to the 
same certificate, then there needs to be an interoperable way for the 
client to get the kdc to use one that it can validate. Otherwise, you can 
get into a situation where a client and kdc fail to communicate, even 
though they ought be able to.
This change looks to me like an excuse to allow clients to only enumerate 
some of their trust anchors. What's the advantage?

---

From: Jeffrey Altman <[email-masked]>
Date: Tue, 15 Mar 2005 15:14:41 -0500

Jeffrey Hutzelman wrote:

> Unfortunately, I think that text is buggy -- it talks about the KDC 
> knowing a certifier's private key, rather than having a cert issued by 
> that certifier.  I would propose instead something like the following:
> 

I support this text.

Jeffrey Altman

---

From: Love Hörnquist Åstrand <[email-masked]>
Date: Fri, 18 Mar 2005 01:01:22 +0100

Jeffrey Altman <[email-masked]> writes:

>> knowing a certifier's private key, rather than having a cert issued
>> by that certifier.  I would propose instead something like the
>> following:

So do I. I don't think the client should need to do retrying. I think
keeping the feature is valueble since it allows the KDC to sign with the
right certificate when there is a match.

Love