Subject: RE: PKINIT-24: Path validation proposal

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Sun, 6 Feb 2005 21:11:02 -0800

Ok, try it again:
 
A) if the client sends all the X.509 certificates on a certification
path to a trust anchor acceptable by the KDC, and the KDC can not verify
the client's public key without using these certificates, the KDC MUST
then process path validation  for the client's certificate based on
these certificates in the request.

B) if the KDC sends all the X.509 certificates on a certification path
to a trust anchor acceptable by the client, and the client can not
verify the KDC's public key without using these certificates, the client
MUST then process path validation for the KDC's certificate based on
these certificates in the reply.

-- Larry

-----Original Message-----
From: Nicolas Williams [mailto:[email-masked]] 
Sent: Sunday, February 06, 2005 8:30 PM
To: Liqiang(Larry) Zhu
Cc: [email-masked]
Subject: Re: PKINIT-24: Path validation proposal

On Sun, Feb 06, 2005 at 08:26:33PM -0800, Liqiang(Larry) Zhu wrote:
> 
> In the interest of moving the draft forward, I propose:
> 
> 
> A) The client's certificate MUST pass the KDC's path validation if the

> client sends all the certificates on a certification path to a trust 
> anchor acceptable by the KDC.
> 
> B)  The KDC's certificate MUST pass the client's path validation if 
> the KDC sends all the certificates on a certification path to a trust 
> anchor acceptable by the client.
> 
> If we can settle with this, I will add these into draft -24. thanks,

But not that text please -- it's confusing, at least to me.

The text has to say who must do what, and note that certificates do
nothing...

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 07 Feb 2005 20:53:45 -0500

> these certificates in the reply.

Hm.  The phrasing there is a little funny, but it's basically good.  Just 
to make sure you're proposing what I think you are, let me rephrase (this 
is NOT proposed text)

If the client sends enough good certificates to construct a valid chain 
from its certificate back to one of the KDC's trust anchors, then the KDC 
MUST accept the client's certificate as legitimate.  Of course, the KDC is 
still allowed to reject the cert for other reasons, including bad 
signatures, invalid, expired, or revoked certificates, missing EKU, missing 
incorrect name, or whatever other local policy it wants to apply.

And, the same rules apply in the other direction.

Is that right?

If that is what you intended to say, then I think the answer to Sam's 
question is that this alone is not sufficient to meet his requirement, but 
it is one component of a solution.  Specifically, Larry's proposed text 
imposes sufficient requirements on the _recipient_ of a certificate, but no 
requirements on the _sender_ of a certificate.

I propose something akin to the following, IN ADDITION to the text Larry 
has already proposed (again, this is conceptual, not text):

        The client MUST be capable of sending a set of certificates
        sufficient to allow the KDC to construct a path back to one of its
        trust anchors, if the correct set of certificates is provided
        through configuration or policy. Again, the same rule applies in
        the reverse direction.

Note that I don't say here what form configuration must take, or what steps 
the client has to take to decide what certificates to send.  A client which 
allows the user to provide an arbitrary set of supporting certificates and 
always sends all of them meets the requirement.  So does a client which 
finds out what the KDC's trust anchors are, uses some directory service to 
compute a path from the user's cert back to one of those anchors, and then 
fetches the required certificates from the directory.  So does a client 
which tries different combinations of supporting certificates until it 
finds one that works.

Comments?

-- Jeff

---

From: Sam Hartman <[email-masked]>
Date: Mon, 07 Feb 2005 22:50:48 -0500

There's probably another approach people might want to consider for
meeting my requirement.

I don't think it is a requirement that all clients and KDCs support
all infrastructures.  I believe that we could decide that the
configuration that must work is the one where the client sends only
the leaf cert and the KDC sends a full cert chain to the client.

You would need to require that KDCs be configurable with a mapping
from client leaf cert to full cert path for this to be sufficient.

I'd prefer that if you adopt this approach you recommend that clients
support configuration of a full cert path.

I don't care whether you take this approach or Jeff's approach; both
support my requirement.  I'm making this suggestion because I believe
it meets Larry's needs better than Jeff's approach.  I am happy with
either proposal and do not express a preference.

--Sam

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 8 Feb 2005 00:10:01 -0600

> either proposal and do not express a preference.

I too am happy with either proposal.

In general it will be easier to implement PKINIT clients and KDCs that
can rely on each other to send full cert chains, but I suspect the
user/admin experience will be better if we take Sam's suggestion.

Nico
--

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 08 Feb 2005 11:35:20 -0500

> from client leaf cert to full cert path for this to be sufficient.

Well, KDC's would have to be able to construct the path somehow.  It would 
be sufficient to have the per-client configurability that Sam describes. 
It would also be sufficient for the KDC to be able to construct a path out 
of a single certificate store containing all the certs that might be needed.

> support configuration of a full cert path.

As would I.

> either proposal and do not express a preference.

I also am happy with either approach.

-- Jeff

---

From: Martin Rex <[email-masked]>
Date: Tue, 8 Feb 2005 19:43:15 +0100 (MET)

> of a single certificate store containing all the certs that might be needed.

I think that is would be an unjustified burden for KDCs to have
access to all client certs.  A client will have to have access to
those certs in order to do anything useful within a PKI, *NOT* a KDC.

If the KDC and the leaf cert issuing CA are not tightly integrated,
then updating the KDC with the new certificate (path) if any of
the certificate(s) are renewed/replaced for whatever reasen
is a royal PITA.  

With all the PKI and CMS stuff that people here want to require for
PKINIT, thin clients are far out of reach anyways, that's only doable
for fat clients.  Fat clients do have plenty of space for certificates,
its probably only the most braindead hardware tokens that will not
be capable to store certificates--and in that case they cannot store
a larger set of trust anchors either; in which case another protocol
extension to securely store the trust anchors on the KDC as well
would be required to make those braindead hardware tokens anywhere
near secure.  I consider the partial support of braindead hardware
tokens a security problem.

> > support configuration of a full cert path.

So would I.

-Martin