Subject: RE: id-pkekuoid

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Sun, 30 Jan 2005 21:06:52 -0800

I support this change.

-- Larry

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Jeffrey
Hutzelman
Sent: Friday, January 28, 2005 4:32 PM
To: [email-masked]
Subject: id-pkekuoid

The current document defines an OID id-pkekuoid (1.3.6.1.5.2.3.4) which
is obviously intended to be used as extended key usage in certificates
intended for use in identifying PKINIT clients.  Near the end of section
3.2.2 there is text about client certificate validation which uses this
OID in an example, but says little else about it.

Larry has improved this text somewhat in the early draft of pkinit-23 he
showed me, but I'd like to propose some additional refinements...

* OLD TEXT:
        Even if the certificate chain is validated, and the names in the
        certificate and the request match, the KDC may decide to reject
        requests on the basis of the absence or presence of specific EKU
        OIDs. For example, the certificate may include an Extended Key
        Usage (EKU) OID of id-pkekuoid in the extensions field:

            { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
              pkinit(3) pkekuoid(4) }

* LARRY'S TEXT:

        Even if the certification path is validated and the certificate
is
        mapped to the client's principal name, the KDC may decide not to
        trust the client's certificate.  For example, the certificate
may
        include an Extended Key Usage of KeyPurposeId [RFC3280]
id-pkekuoid
        in the extensions field:

            { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
              pkinit(3) pkekuoid(4) }

        As a matter of local policy, the KDC may decide to reject
        requests on the basis of the absence or presence of specific
        EKU OIDs.

* JHUTZ'S TEXT:
        Even if the certification path is validated and the certificate
is
        mapped to the client's principal name, the KDC may decide not to
        accept the client's certificate, depending on local policy.

        The KDC MAY require the presence of an Extended Key Usage of
        KeyPurposeId [RFC3280] id-pkekuoid in the extensions field:

            { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
              pkinit(3) pkekuoid(4) }

        As a matter of local policy, the KDC may decide to reject
requests
        on the basis of the absence or presence of other specific EKU
OIDs.

Comments?

-- Jeff

---

From: Brian Tung <[email-masked]>
Date: Sun, 30 Jan 2005 22:18:40 -0800

>         on the basis of the absence or presence of other specific EKU

Fine by me.

b