Re: [pkix] A non-compliant use of the EKU extension in Mozilla's CA Certificate Policy Version 2.1.

If you replace "1 below" with "n below" this strikes me as a really common use case.  It's a pity the standards don't address it clearly enough that standard software handles it more easily.

On Feb 20, 2013, at 10:09 AM, Michael StJohns <mstjohns@comcast.net> wrote:

> At 12:41 PM 2/20/2013, Martin Rex wrote:
>>  id-kp-clientAuth             OBJECT IDENTIFIER ::= { id-kp 2 }
>>  -- TLS WWW client authentication
>>  -- Key usage bits that may be consistent: digitalSignature
>>  -- and/or keyAgreement
> 
> I've actually used this EK oid for client certificates for TLS.  The general code for accepting (and deriving user credentials from) client certificates is mostly useless.  
> 
> I've ended up getting the raw certificate (after path processing validates the basics) and pulling it apart to see if it has what I want.  This works well when you have a standard mapping from a cert/cert chain to a user credential, but you want to make sure that you aren't  - for example - accepting an email credential.
> 
> (You can't do this without writing additional processing code: I want to accept a cert that's no more than 1 CA below a known and specific root, and I want to take the UID field from the subject name of the cert as the handle for mapping the cert to the server user/role and I want this cert to be a TLS cert, any other cert that chains to one of my acceptable roots gets the guest credential and role)
> 
> Mike
> 
> 
> _______________________________________________
> pkix mailing list
> pkix@ietf.org
> https://www.ietf.org/mailman/listinfo/pkix

------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu