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

From: Leif Johansson <[email-masked]>
Date: Tue, 15 Mar 2005 20:03:52 +0100

Liqiang(Larry) Zhu wrote:
> When the client deploys PKI using a bridge CA, it does not know all the
> CAs that have been cross-certified. 
> 
> We have a situation where the client has listed all the trust anchors,
> and the client may be able to validate the KDC certificate, the KDC can
> not build a validation path based on trust anchors listed by the client,
> but the KDC's CA is cross-certified by the client's BCA. Is this case
> interesting?
> 
> I agree to strike out the whole paragraph on the other hand.

I believe the situation is very interesting. I have no opinion on the
language (leaving that to Love).

	MVH leifj

---

From: Chaskiel M Grundman <[email-masked]>
Date: Tue, 15 Mar 2005 14:05:07 -0500

I am not objecting to the core 839 issue -- if the kdc cannot find a path 
using the client's trust anchors, then it is a good idea for it to go ahead 
and return a response in the hope that the client can verify it. I was 
objecting to the new text:

                -- The information contained in the
                -- trustedCertifiers MAY be used by the KDC as hints
                -- to guide its selection of an appropriate
                -- certificate chain to return to the client.

...which jeff (properly) split out into a new issue. If the client provides 
trustedCertifiers, and the kdc can produce a path to one of those trust 
anchors, then it should use that path. So something like:

                -- The information contained in the
                -- trustedCertifiers SHOULD be used by the KDC
                -- to guide its selection of an appropriate
                -- certificate chain to return to the client.

---

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Tue, 15 Mar 2005 10:40:00 -0800

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Chaskiel M
Grundman
Sent: Monday, March 14, 2005 8:52 PM
To: [email-masked]
Subject: Re: CALL FOR DISCUSSION - #839 - KDC_ERR_KDC_NOT_TRUSTED

--On Monday, March 14, 2005 06:20:35 PM -0500 Jeffrey Hutzelman 
<[email-masked]> wrote:

> 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.

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:13:57 -0500

Chaskiel M Grundman wrote:

> I am not objecting to the core 839 issue -- if the kdc cannot find a 
> path using the client's trust anchors, then it is a good idea for it to 
> go ahead and return a response in the hope that the client can verify 
> it. I was objecting to the new text:
> 
> ...which jeff (properly) split out into a new issue. If the client 
> provides trustedCertifiers, and the kdc can produce a path to one of 
> those trust anchors, then it should use that path. So something like:
> 

I support Chas' text.  I prefer the SHOULD to a MAY in this instance.

---

From: Sam Hartman <[email-masked]>
Date: Wed, 16 Mar 2005 19:48:40 -0500

>>>>> "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.