Subject: RE: id-pkekuoid

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

I support the new text.

-- larry

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Jeffrey
Hutzelman
Sent: Monday, January 31, 2005 9:43 AM
To: [email-masked]
Subject: Re: id-pkekuoid

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