Subject: CONSENSUS CALL - #842 - Certificate path validation

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 18 Apr 2005 18:34:52 -0400

Based on earlier list traffic and on off-list discussion with the document 
editors, I suspect that we may have a consensus on a solution to this 
issue.  I am going to summarize the two concrete proposals I've seen, and 
then ask for the sense of the WG on one of them.  Please bear in mind that 
in the following descriptions, it is the semantics that is at issue, and 
not the specific text.

*** Approach A ***

Larry wrote:
> 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.

I rephrased this as;

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

and added this additional requirement:

        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.

*** Approach B ***

Sam Hartman wrote:

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

******************

Both approaches were discussed to some extent, and several parties 
indicated they would be happy with adopting either approach.  However, 
based on the comments I've seen so far, I think it is fairly likely that we 
already have a fairly strong consensus for approach A.  For that reason, I 
am issuing this consensus call to see if I am right.

I would like to see answers to the following questions:

- Does the WG agree that certificate chains should be sent and validated
  as described for "approach A" ?
- Is there anyone who would prefer "approach B" over "approach A"?

Please send your comments, even if you have commented on this issue before. 
Again, it is much easier for me to evaluate responses to a specific binary 
question than to try to interpret past messages.

-- Jeff

---

From: Brian Tung <[email-masked]>
Date: Mon, 18 Apr 2005 15:45:56 -0700

> question than to try to interpret past messages.

Yes to first question, no to second question; B is acceptable but not
preferable.

Brian Tung <[email-masked]>

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 18 Apr 2005 17:45:02 -0500

Question: in approach (A) the client and KDC then MUST send each other
their full certificate chains, yes?

Nico
--

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 18 Apr 2005 19:07:11 -0400

> their full certificate chains, yes?

The additional requirement should clarify this.  The client and KDC MUST 
each be capable of sending each other their full certificate chains, if 
provided those chains through configuration.  The interoperable 
configuration, then, is one in which every client and KDC has been provided 
with a copy of its certificate chain.

-- Jeff

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 18 Apr 2005 18:16:08 -0500

> with a copy of its certificate chain.

Then they MUST also be so configurable.  Text please :)

I like both approaches equally.

Nico
--

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 18 Apr 2005 19:24:32 -0400

On Monday, April 18, 2005 06:16:08 PM -0500 Nicolas Williams 
<[email-masked]> wrote:

>> configuration, then, is one in which every client and KDC has been
>> provided  with a copy of its certificate chain.
>

I believe the text Larry has written up for this covers this issue.
Most of the relevant text actually already appears in pkinit-25.

-- Jeff

---

From: Sam Hartman <[email-masked]>
Date: Mon, 18 Apr 2005 21:40:16 -0400

>>>>> "Jeffrey" == Jeffrey Hutzelman <[email-masked]> writes:

    Jeffrey> I would like to see answers to the following questions:

    Jeffrey> - Does the WG agree that certificate chains should be
    Jeffrey> sent and validated as described for "approach A" ?  - Is
    Jeffrey> there anyone who would prefer "approach B" over "approach
    Jeffrey> A"?

I prefer approach A.  I suggested approach B because I thought it was
better aligned with some requirements I was hearing.

---

From: Love Hörnquist Åstrand <[email-masked]>
Date: Tue, 19 Apr 2005 18:12:28 +0200

Jeffrey Hutzelman <[email-masked]> writes:

> Based on earlier list traffic and on off-list discussion with the
> document editors, I suspect that we may have a consensus on a solution
> to this issue.  I am going to summarize the two concrete proposals
> I've seen, and then ask for the sense of the WG on one of them.
> Please bear in mind that in the following descriptions, it is the
> semantics that is at issue, and not the specific text.
>
> *** Approach A ***

> *** Approach B ***

I parse both options allows the client just to send a leaf certificate. It
doesn't matter for me then. A is somewhat stricter, but in real life it
doesn't matter, if the interfaces isn't there in the libraries, the
intermediate certs is not going to be sent.

Love

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 19 Apr 2005 15:18:29 -0400

> intermediate certs is not going to be sent.

Approach A requires the client be capable of sending a full chain, if 
provided the chain through local configuration.  It also effectively 
requires that such configuration be possible.

---

From: Love Hörnquist Åstrand <[email-masked]>
Date: Tue, 19 Apr 2005 21:51:01 +0200

> requires that such configuration be possible.

But if there are limitation in, lets say hardware, to store more then 1
certificate, it not going to matter how capable the client is.

All I'm saying there isn't much diffrence between the options and doesn't
really matter which one we pick.

Love

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 19 Apr 2005 15:01:55 -0500

> really matter which one we pick.

Are you sure?  If PKINIT REQUIREs that clients be configurable with
their whole cert chain, and a library your implementation depends on
makes this not possible, then your client wouldn't be compliant.

As long as the KDC is also REQUIRED to be able to cope with clients that
provide only leaf certs this should not be a real problem, just a
semantic one of non-compliance.

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 19 Apr 2005 16:22:59 -0400

> semantic one of non-compliance.

Neither of the proposals under discussion contains both requirements; in 
fact, this is the fundamental difference between them.  The Approach A 
proposal REQUIREs that clients be able to send their full chain; the 
Approach B proposal REQUIRES that KDC's be able to build a chain from local 
information for clients that send only a leaf cert.  Of course, in both 
cases there is a dependence on correct local configuration.

-- Jeff

---

From: Sam Hartman <[email-masked]>
Date: Tue, 26 Apr 2005 01:01:45 -0400

>>>>> "Love" == Love Hörnquist Åstrand <[email-masked]> writes:

    Love> Jeffrey Hutzelman <[email-masked]> writes:

    >> Approach A requires the client be capable of sending a full
    >> chain, if provided the chain through local configuration.  It
    >> also effectively requires that such configuration be possible.

    Love> But if there are limitation in, lets say hardware, to store
    Love> more then 1 certificate, it not going to matter how capable
    Love> the client is.

Such a client would not comply with pkinit.