Subject: RE: id-pkekuoid

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 14 Mar 2005 11:44:53 -0500

On Monday, January 31, 2005 09:53:02 AM -0800 "Liqiang(Larry) Zhu" 
<[email-masked]> wrote:

> 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.

Just to be clear...  This whole thread is #767, and is only awaiting 
confirmation that the text changes have made it into -25.

-- Jeff