Subject: RE: PKINIT-22 comments

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Tue, 1 Feb 2005 10:02:09 -0800

I missed the key word "new", so try it again here:

<t>

    These certificates SHOULD be sufficient to construct at least a
certification
    path from the client certificate to one trust anchor acceptable by
the KDC.

<t>

Similar text for the KDC cert.

 <t> Upon receiving this error, the client SHOULD retry only if it can
construct a new certification path from one of the trust anchors
selected by
the KDC to its own certificate.  The client MUST send all available
certificates 
on that certification path (excluding the trust anchor itself) when it
retries
the request.</t>

The text in 3852 allows a bag of multiple paths. Do we have a good
reason to forbid that?

-- Larry

---

From: "Paul Leach" <[email-masked]>
Date: Tue, 1 Feb 2005 10:14:06 -0800

> -----Original Message-----
> From: Liqiang(Larry) Zhu
> Sent: Tuesday, February 01, 2005 10:02 AM

> construct a new certification path from one of the trust anchors
selected
> by
[Paul Leach] This is not required and not feasibly enforceable. (The KDC
isn't going to remember what the client sent and reject a partial chain
even though it could complete it.)  The client should just try something
different than it tried before. It can send a different partial chain as
long as it is one that it thinks will lead to one of the trust anchors
sent by the KDC.

<t> Upon receiving this error, the client SHOULD retry only if has
certificates that form part of a certification path from one of the
trust anchors selected by the KDC to its own certificate.  The client
MAY retry with partial paths, but eventually MUST send all available
certificates on that certification path (excluding the trust anchor
itself) when it retries the request.</t>

---

From: "Paul Leach" <[email-masked]>
Date: Tue, 1 Feb 2005 19:19:11 -0800

Sorry, I missed the specification of the mapping. I'm glad its there.

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Jeffrey
Hutzelman
Sent: Tuesday, February 01, 2005 9:11 AM

Paul said:
> That's why, if you want an
> interoperable "open mode", the spec should define the form of certs
> those CAs should issue in order to get the expected cname/crealm in
the
> TGT -- because the KDC could issue TGTs based on certs issued by lots
of
> CAs. (An implementation could also have side agreements with CAs and
> privately agreed upon mappings, but there needs to be a
> mandatory-to-implement one as well.)

Which it does:

   In addition to validating the client's certificate, the KDC MUST also
   check that this certificate properly maps to the client's principal
   name as specified in the AS-REQ as follows:
[Paul Leach] <etc>

---

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Wed, 2 Feb 2005 20:38:41 -0800

These suggested changes are now in -24.

-- Larry

-----Original Message-----
From: Sam Hartman [mailto:[email-masked]] 
Sent: Wednesday, February 02, 2005 6:36 AM
To: Liqiang(Larry) Zhu
Cc: [email-masked]
Subject: Re: PKINIT-22 comments

>>>>> "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: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Thu, 3 Feb 2005 11:07:35 -0800

Upon request, draft -24 is attached. There are 3 relevant places: page
8, page 15 and page 17.

-- larry

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Liqiang(Larry)
Zhu
Sent: Wednesday, February 02, 2005 8:39 PM
To: Sam Hartman
Cc: [email-masked]
Subject: RE: PKINIT-22 comments

-- Larry

-----Original Message-----
From: Sam Hartman [mailto:[email-masked]]
Sent: Wednesday, February 02, 2005 6:36 AM
To: Liqiang(Larry) Zhu
Cc: [email-masked]
Subject: Re: PKINIT-22 comments

T

--Sam

---

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

Sam Hartman wrote:

> Adopting pre-3280 text is not sufficient. 
Agreed. More specifically, I do not feel comfortable forbidding the use
of AIA/SIA extension in RFC 3280. 

-- Larry

-----Original Message-----
From: Sam Hartman [mailto:[email-masked]] 
Sent: Sunday, February 06, 2005 12:29 PM
To: [email-masked]
Cc: Liqiang(Larry) Zhu; [email-masked]
Subject: Re: PKINIT-22 comments

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

    Martin> Liqiang wrote:
    >> 
    >> 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.

    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