Correct, as I already denoted these are from the obsolete RFC2459.

As the IETF/PKIX charter could not define a consenting set of flags, 
Steve Kent had suggested to drop them and leave it to the IPsec WG. 
This has been done by RFC4809: Its recommendation is not to use any 
extKeyUsage and, if necessary now to use: 

   id-kp-ipsecIKE OBJECT IDENTIFIER ::= { id-kp 17 }

As RFC4809 just over 2 years old and till now its OID is not in the 
databases from Alvestrand or the ITU, it is very likely that products 
in the field still support the former ones. This is ok, as long as 
it is done in conformance with X509's extKeyUsage definition: 

If the extension is flagged critical, then the certificate 
shall be used only for one of the purposes indicated. 

If the extension is flagged non-critical, then it indicates 
the intended purpose or purposes of the key, and may be used 
in finding the correct key/certificate of an entity that has 
multiple keys/certificates...

Such an advisory field has been very useful for me to design 
multi purpose corporate smart cards.  

-----Original Message-----
From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] 
On Behalf Of Kyle Hamilton
Sent: Friday, July 17, 2009 7:11 PM
To: openssl-users@openssl.org
Subject: Re: One CA for many clients (a silly question)

kp-ipsec* has been formally deprecated by the IETF ipsec working
group, and thus if any implementation demands that they're there it's
a bug in that software.

-Kyle H

On Fri, Jul 17, 2009 at 12:46 AM, PMHager<h...@prima.de> wrote:
>
> Extract from obsoleted RFC2459:
>
> -- extended key purpose OIDs
> id-kp-serverAuth     OBJECT IDENTIFIER ::= { id-kp 1 }
> id-kp-clientAuth     OBJECT IDENTIFIER ::= { id-kp 2 }
> id-kp-ipsecEndSystem OBJECT IDENTIFIER ::= { id-kp 5 }
> id-kp-ipsecTunnel    OBJECT IDENTIFIER ::= { id-kp 6 }
> id-kp-ipsecUser      OBJECT IDENTIFIER ::= { id-kp 7 }
> ...
>
> So, id-kp-clientAuth (1.3.6.1.5.5.7.3.2) should be as extended key usage
> in TLS/SSL client certificates, and id-kp-ipsecUser (1.3.6.1.5.5.7.3.7)
> should be in IKE user certificates. As the id-kp-ipsec OIDs are removed
> in the current release [RFC5280], you will need to test whether your
> implementation does support them.
>
> Peter
>
> -----Original Message-----
> From: owner-openssl-us...@openssl.org 
> [mailto:owner-openssl-us...@openssl.org] On Behalf
> Of Dr. Stephen Henson
> Sent: Thursday, July 16, 2009 6:24 PM
> To: openssl-users@openssl.org
> Subject: Re: One CA for many clients (a silly question)
>
> On Wed, Jul 15, 2009, stortoaranci wrote:
>
>>
>> Hi All,
>>
>> I just have a silly question on Openssl.
>>
>> I use a self-signed CA to sign several server/clients cert.
>>
>> For example I could use signed certs to implement an OpenVPN LAN and one
>> Wi-FI RADIUS auth for different clients.
>>
>> The question is: "how to be sure that a client allowed to use the wifi do
>> not use the same cert on the OpenVPN LAN"?
>>
>> In other words, how could I segratate clients using the same CA?
>>
>> thank you and sorry for my poor english.
>>
>
> I'm not certain if there are any specific extended key usage OIDs for those
> two purposes. If there are you can set thos in the appropriate end entity
> certificates but the software then has to check for their presence.
>
> Certificate policies is also usable for this. Again though the software has to
> check for an appropriate policy.
>
> Steve.
> --
> Dr Stephen N. Henson. OpenSSL project core developer.
> Commercial tech support now available see: http://www.openssl.org
> ______________________________________________________________________
> OpenSSL Project                                 http://www.openssl.org
> User Support Mailing List                    openssl-users@openssl.org
> Automated List Manager                           majord...@openssl.org
>
> ______________________________________________________________________
> OpenSSL Project                                 http://www.openssl.org
> User Support Mailing List                    openssl-users@openssl.org
> Automated List Manager                           majord...@openssl.org
>
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    openssl-users@openssl.org
Automated List Manager                           majord...@openssl.org

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    openssl-users@openssl.org
Automated List Manager                           majord...@openssl.org

Reply via email to