Subject: PKINIT-22 comments

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Mon, 24 Jan 2005 09:31:52 -0800

Posted for Dan Simon ([email-masked]).
> - Definition of octetstring2key:  you might want to clarify that
you're taking the *first* K bits when you 
> truncate.

Agreed

> - It might be worthwhile to harmonize the language of the DH and
RSA/EncKeyPack sections. 

I think this makes sense. The current text structure is hard to read.

---

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Tue, 25 Jan 2005 10:40:49 -0800

Sam Hartman wrote:
>>    dcross> S/signature verification certificate chain/public key
>>    dcross> certificate chain/.
> No, you want signature verification in there.

David pointed out that the terminlogy we used is strange, "signature
verification certificate chain", he did not know what that meant, hence
he proposed a more "standard" term.

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Sam Hartman
Sent: Monday, January 24, 2005 3:07 PM
To: Liqiang(Larry) Zhu
Cc: [email-masked]
Subject: Re: PKINIT-22 comments

    dcross> Posted for David Cross ([email-masked]) from
    dcross> Microsoft: Section 2:
    >> The advantage afforded by the TGT is that the client need
    >> 1.  The client indicates the use of public-key authentication
    >> by including a special preauthenticator in the initial request.
    dcross> This
    >> preauthenticator contains the client's public-key data and a
    >> signature.

    dcross> Note that the public-key data does not mean raw
    dcross> public-key. It accepts only x509 certificates.

Not quite true.  In the DH case the public key (static DH value) is not
in a cert.

There is a cert involved in that case.

    dcross> s/its policy/its authentication policy/

    dcross> Section 3.2.1

    >> The certificates field MUST contain at least a signature
    >> verification certificate chain that the KDC can use to verify
    dcross> the
    >> signature over the AuthPack.

    dcross> S/signature verification certificate chain/public key
    dcross> certificate chain/.

No, you want signature verification in there.

    dcross> I think you want to be more explicit and refer to x.509
    dcross> only.

Why?

    >> The certificate chain(s) MUST NOT contain the root CA
    >> certificate.

    dcross> Will you allow only the leaf (end entity) certificate to
    dcross> be sent to the KDC and let the server build the chain?  Is
    dcross> this optional?

Speaking as an individual, I'm uncomfortable with adding more optional
things to the protocol.

OTOH, a mostly offline client may not have sufficient data to build a
cert path.

    dcross> A client MAY send only the leaf certificate to the KDC and
    dcross> it SHOULD send all certificates in the chain necessary to
    dcross> build a path to a trust acnhor on the KDC"

I'm not sure this text is sufficient to guarantee interoperability.

    >> 4.  The certificates field contains an X.509 public key
    >> certificate chain that the client will use to verify the KDC's
    >> signature over the ReplyKeyPack.  This field may only be left
    >> empty if the client included a kdcCert field in the
    >> PA-PK-AS-REQ, indicating that it has the KDC's certificate.
    >> The certificate chain MUST NOT contain the root CA certificate.

    dcross> We propose: A client MAY send only the leaf certificate to
    dcross> the KDC and it SHOULD send all certificates in the chain
    dcross> necessary to build a path to a trust anchor on the KDC.

Isn't this text kdc to client?

In conclusion, you seem to be proposing fairly significant changes to
the cert path handling for pkinit at a very late stage in the protocol.
I'm concerned about this.

--Sam

---

From: "Paul Leach" <[email-masked]>
Date: Mon, 31 Jan 2005 20:01:39 -0800

> From: Martin Rex [mailto:[email-masked]] 
> Sent: Monday, January 31, 2005 6:17 PM
> To: Paul Leach
> Cc: [email-masked]; [email-masked]; 
> Liqiang(Larry) Zhu; [email-masked]; 
> [email-masked]; [email-masked]
> I think you have it all backwards, Paul.
> 
> For interoperability, the cert with full chain must be 
> included by the client. 

No, interoperability can happen either way, or both ways. All that
interop requires is that both sides agree on what needs to be provided.

> The KDC may not even have the leaf 
> cert (which is much easier to handle if the CA and the KDC 
> are _NOT_ tightly integrated, i.e. when the user gets a new 
> cert for whatever reason.

Yes, this is possible.

> 
> Only if the KDC happens to have not only the users 
> certificate, but also all certificates from intermediate CAs 
> in the KDC database, then the optimization of the client not 
> sending the full path will not cause a PKINIT failure.  So if 
> you can propose a means for the client to reliably know the 
> KDC has full access to those certificates (read *NO* 
> (directory) lookup of intermediate CA certs), then such an 
> optimization is OK for the PKINIT spec.

Out of band configuration is a reliable way to know.

> 
> The client shouldn't guess about the KDCs capabilities; if it 
> doesn't know for sure that the KDC has access to those certs, 
> it MUST send the full path.
> 
> I consider is entirely inappropriate for PKINIT to require a 
> KDC to either store all those certs in the KDC database and 
> retrieve them from there or to have the KDC look them up in 
> directories.

I specifically said that I thought both options are valid: client sends
leaf certs only or full cert chain.

Why are you setting up a strawman?

> 
> PKINIT should NOT mandate implementation characteristics from 
> the KDC, and it should be up to KDC implementors to design 
> how the actual mapping from user certificates into KDC 
> database entries is performed.

What entries? In the "open mode" you defined, there would no entries for
clients -- just a list of trusted CA roots. 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.)

> 
> Why should PKINIT preclude a mapping based on a 
> subjectAltName extension that does not require user 
> certificates to be stored in the KDC database?

I am not trying to preclude antying. I repeat that I am not requiring
user certs to be stored in the KDC database. I only asserted that
storing certs was no more complex than storing symmetric keys, nor did
it create a bigger attack surface.

> 
> Just because Microsoft is (already) stuck with a particular 
> design shouldn't mean that we require their design and (KDC) 
> complexity from all other implementors.

If you weren't attributing malign motives to me, maybe you'd understand
what I wrote.

> -Martin
> Paul Leach wrote:
> > > From: Nicolas Williams [mailto:[email-masked]]
> > > Sent: Monday, January 31, 2005 1:48 PM
> > > To: Paul Leach
> > > 
> > > But imagine a "open" PK mode where the KDC will issue a TGT to 
> > > anyone
> > > with: a) a valid cert for many, or any paths in a very 
> large PKI, b) 
> > > a cname authorized, explicitly or otherwise, by their cert.
> > > 
> > > In this case the KDC might have to find a client cert's 
> cert chain, 
> > > unless the client furnished it.
> > 
> > In this mode, the client would have to send all of the certs.
> > 
> > I think this is a valid mode, but clients will have to be 
> configured for it.
> > 
> > I also think this won't be anywhere near the most common 
> mode, and we 
> > shouldn't make all clients pay for it all the time.
> > 
> > I also think we would have to specify how the cname and crealm are 
> > derived from the cert in order to make this work (so that CAs know 
> > what kind of certs to issue to enable it), and I'm not 
> aware that the 
> > spec currently does this (or at least not well enough).
>