Subject: RE: CALL FOR DISCUSSION - #839 - KDC_ERR_KDC_NOT_TRUSTED

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Wed, 16 Mar 2005 17:40:41 -0800

Sam Hartman wrote:
>  The client can clearly retry with out trust anchors specified.

this client is penalized for providing additional information to the
KDC.

-- Larry 

-----Original Message-----
From: Sam Hartman [mailto:[email-masked]] 
Sent: Wednesday, March 16, 2005 4:49 PM
To: Liqiang(Larry) Zhu
Cc: Chaskiel M Grundman; [email-masked]
Subject: Re: CALL FOR DISCUSSION - #839 - KDC_ERR_KDC_NOT_TRUSTED

>>>>> "Liqiang(Larry)" == Liqiang(Larry) Zhu
<[email-masked]> writes:

    Liqiang(Larry)> When the client deploys PKI using a bridge CA, it
    Liqiang(Larry)> does not know all the CAs that have been
    Liqiang(Larry)> cross-certified.

    Liqiang(Larry)> We have a situation where the client has listed
    Liqiang(Larry)> all the trust anchors, and the client may be able
    Liqiang(Larry)> to validate the KDC certificate, the KDC can not
    Liqiang(Larry)> build a validation path based on trust anchors
    Liqiang(Larry)> listed by the client, but the KDC's CA is
    Liqiang(Larry)> cross-certified by the client's BCA. Is this case
    Liqiang(Larry)> interesting?

So you have a case where the client is going to be doing a better job
of cert path building than the KDC?  If so, this case is very
interesting because it's a significant difference from what we
normally assume.  

If I'm understanding you correctly here the KDC could actually build a
path back to a trust anchor; it just doesn't know what certs to use.

I'm not at all sure how this example is related to the error handling.
The client can clearly retry with out trust anchors specified.