Subject: id-pkekuoid

From: Jeffrey Hutzelman <[email-masked]>
Date: Fri, 28 Jan 2005 19:32:07 -0500

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: Jeffrey Hutzelman <[email-masked]>
Date: Fri, 28 Jan 2005 19:41:42 -0500

> showed me, but I'd like to propose some additional refinements...

Of course, I then forgot to copy in the reasons for my proposal. 
Basically, this takes the "example" EKU and actually specifies that this is 
what that OID is for (without actually requiring its use).  It also allows 
the KDC to reject certificates based on policy other than EKU requirements, 
which was permitted by the text in -21 but became less clear in -22 (this 
is #767).

As I understand Microsoft's arguments wrt 1.3.6.1.4.1.311.20.2.2, they are 
already using that OID for this purpose, and would want any KDC requiring 
an io-pkekuoid EKU to treat the Microsoft OID as satisfying the requirement 
(because it is already widely deployed).  Personally, I would not object to 
adding a sentence like...

  KDC's implementing this requirement SHOULD also accept KeyPurposeId
  XXX (1.3.6.1.4.1.311.20.2.2) as meeting this requirement, as there are
  a large number of client certificates deployed for use with PKINIT
  which have this EKU.

Of course, it would be up to the WG whether to accept this.

-- Jeff

---

From: Sam Hartman <[email-masked]>
Date: Sun, 30 Jan 2005 21:35:19 -0500

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

    Jeffrey> Personally, I would not object to adding a sentence
    Jeffrey> like...

    Jeffrey>   KDC's implementing this requirement SHOULD also accept
    Jeffrey> KeyPurposeId XXX (1.3.6.1.4.1.311.20.2.2) as meeting this
    Jeffrey> requirement, as there are a large number of client
    Jeffrey> certificates deployed for use with PKINIT which have this
    Jeffrey> EKU.

I support this sentence as well as Jeff's proposed EKU text.

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 31 Jan 2005 10:18:30 -0600

> Of course, it would be up to the WG whether to accept this.

Fine with me.

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 31 Jan 2005 12:42:34 -0500

As submitted, pkinit-23 contains essentially the text I proposed, including 
the Microsoft alternate OID sentence.  Unfortunately, the ordering suggests 
something that I don't think is what any of us mean:

PKINIT-23:
   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.  KDCs
   implementing this requirement SHOULD also accept the EKU KeyPurposeId
   id-ms-sc-logon (1.3.6.1.4.1.311.20.2.2) as meeting the requirement,
   as there are a large number of client certificates deployed for use
   with PKINIT which have this EKU.

Writing it this way makes it look like we are recommending that KDC's 
should accept id-ms-sc-logon as satisfying _any_ EKU requirement.  I'm 
pretty sure the intent is only that it should satisfy the id-pkekuoid 
requirement.

BETTER:
   KDC's implementing this requirement SHOULD also accept the EKU
   KeyPurposeId id-ms-sc-logon (1.3.6.1.4.1.311.20.2.2) as meeting
   the requirement, as there are a large number of client certificates
   deployed for use with PKINIT which have this EKU.

   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 OID's.

Comments?

-- Jeff