Subject: RE: PKINIT-22 comments

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Wed, 2 Feb 2005 01:45:11 -0800

Sam Hartman wrote:
> \exists c\in{client_configs} \exists  k\in{kdc_configs}\forall
x\in{clients}
>    \forall y\in{kdcs}: x_c \interop y_k

The difficulty is then how to describe such configuration.

My point here is that it does not help to say the client MUST send the
full chain, because I do not know the term "the full chain" means. 

This reminds another point, we say that the client must not send the
root CA cert, but what does the term "root CA" mean. 

I could not find a reference to either term in RFC3280 & RFC3852.  If
one can provide the references, I would gladly accept Nico's proposals.

-- larry 

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Sam Hartman
Sent: Tuesday, February 01, 2005 7:50 PM
To: [email-masked]
Subject: Re: PKINIT-22 comments

>>>>> "Sam" == Sam Hartman <[email-masked]> writes:
    Nicolas> Oh, and, even small footprint clients?

    Nicolas> I.e., should that be a MUST or a SHOULD?

    Sam> interoperability cannot be a should.  We are required to
    Sam> deliver interoperable specs.  All clients must support a
    Sam> configuration that interoperates with a configuration of all
    Sam> servers.

    Sam> Or with more qualifiers:

    Sam> \forall x \in {clients}\exists y {client_configs}\forall a
    Sam> \in {servers} \exists b\in{server_configs}: x_y\interop a_b

I wrote that out mostly as a joke but managed to get something important
wrong and in the process realize that I am unclear in what I ask for.
The statement above only requires pair-wise interoperability.  Each KDC
and client must work together, but for example the configuration that a
Microsoft client and Heimdal KDC share may be different than the
configuration that a MIT client and Heimdal KDC share.  That's no good.
So restated:

\exists c\in{client_configs} \exists  k\in{kdc_configs}\forall
x\in{clients}
    \forall y\in{kdcs}: x_c \interop y_k

---

From: Sam Hartman <[email-masked]>
Date: Wed, 02 Feb 2005 09:36:18 -0500

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

    Liqiang(Larry)> The difficulty is then how to describe such
    Liqiang(Larry)> configuration.

    Liqiang(Larry)> My point here is that it does not help to say the
    Liqiang(Larry)> client MUST send the full chain, because I do not
    Liqiang(Larry)> know the term "the full chain" means.

First, you don't want to say send the full chain because your client
doesn't do that.

It seems like you probably want to argue for an interoperable configuration  where the KDC does the lookups.
Some people here will probably argue for client SHOULD send full chain.

So you would say something like The client SHOULD send enough
certificates to build a path from its signing certificate to one of
the KDC's trust anchors.  You can include an informative reference to
the pkix certificate path building draft (already approved) although
3280 does include enough information to make this statement
normatively useful.

T
    Liqiang(Larry)> This reminds another point, we say that the client
    Liqiang(Larry)> must not send the root CA cert, but what does the
    Liqiang(Larry)> term "root CA" mean.

    Liqiang(Larry)> I could not find a reference to either term in
    Liqiang(Larry)> RFC3280 & RF

s/root cert/trust anchor/

--Sam

---

From: Martin Rex <[email-masked]>
Date: Thu, 3 Feb 2005 00:07:46 +0100 (MET)

> full chain, because I do not know the term "the full chain" means. 

Just adopt the solution and text from rfc2246 (TLS v1.0 spec),
from "certificate_list" of section 7.4.2 Server Certificate
which I quoted in a prior Email and be done with it.

> one can provide the references, I would gladly accept Nico's proposals.

Coincidentally, this is already covered in the text from the TLS v1.0 spec.

-Martin

---

From: Sam Hartman <[email-masked]>
Date: Sun, 06 Feb 2005 15:28:33 -0500

>>>>> "Martin" == Martin Rex <[email-masked]> writes:

    Martin> Liqiang wrote:
    >> x\in{clients} > \forall y\in{kdcs}: x_c \interop y_k
    >> 
    >> My point here is that it does not help to say the client MUST
    >> send the full chain, because I do not know the term "the full
    >> chain" means.

    Martin> Just adopt the solution and text from rfc2246 (TLS v1.0
    Martin> spec), from "certificate_list" of section 7.4.2 Server
    Martin> Certificate which I quoted in a prior Email and be done
    Martin> with it.

Adopting pre-3280 text is not sufficient.

--Sam