Subject: RE: PKINIT-22 comments

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Tue, 1 Feb 2005 06:18:44 -0800

Folks, here is the text in RFC 3852.

       certificates is a collection of certificates.  It is intended
that
      the set of certificates be sufficient to contain certification
      paths from a recognized "root" or "top-level certification
      authority" to all of the signers in the signerInfos field.  There
      may be more certificates than necessary, and there may be
      certificates sufficient to contain certification paths from two or
      more independent top-level certification authorities.  There may
      also be fewer certificates than necessary, if it is expected that
      recipients have an alternate means of obtaining necessary
      certificates (e.g., from a previous set of certificates).  The
      signer's certificate MAY be included. 

Do you think we need to constrain this further other than saying the
signer's certificate must be included (which is basically what -23
says)?

I can add that the client MUST send the full path (excluding the trust
anchor) when it retries based on the TD-TRUSTED-CERTIFIERS. Would that
be reasonable?

Here is the proposed text:

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

Martin, this would match with what TLS does: the TLS client certificates
are sent based on the CertificateRequest message. 

-- Larry

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 1 Feb 2005 10:50:02 -0600

> signer's certificate must be included (which is basically what -23

Yes.  There are not enough SHOULDs or MUSTs in the text you quote.

> anchor) when it retries based on the TD-TRUSTED-CERTIFIERS. Would that

That's reasonable.  However, I would still like to see:

 - a recommendation that the client's default behaviour be configurable,
   and, when it can't be, a recommendation as to what the default should
   be (send full chain)

 - a recommendation that the KDC be configurable so as to be able to
   find some or all the cert chains that it might need.

Nico
--