2010/9/29 Micah Anderson via RT <r...@openssl.org>

>
> According to RFC 4945 ยง 5.1.3.12 section title "ExtendedKeyUsage"[0] the
> following extended key usage has been added:
>
>  ... this document defines an ExtendedKeyUsage keyPurposeID that MAY be
>   used to limit a certificate's use:
>
>   id-kp-ipsecIKE OBJECT IDENTIFIER ::= { id-kp 17 }
>
>   where id-kp is defined in RFC 3280 [5].  If a certificate is intended
>   to be used with both IKE and other applications, and one of the other
>   applications requires use of an EKU value, then such certificates
>   MUST contain either the keyPurposeID id-kp-ipsecIKE or
>   anyExtendedKeyUsage [5], as well as the keyPurposeID values
>   associated with the other applications.  Similarly, if a CA issues
>   multiple otherwise-similar certificates for multiple applications
>   including IKE, and it is intended that the IKE certificate NOT be
>   used with another application, the IKE certificate MAY contain an EKU
>   extension listing a keyPurposeID of id-kp-ipsecIKE to discourage its
>   use with the other application.  Recall, however, that EKU extensions
>   in certificates meant for use in IKE are NOT RECOMMENDED.
>
>   Conforming IKE implementations are not required to support EKU.  If a
>   critical EKU extension appears in a certificate and EKU is not
>   supported by the implementation, then RFC 3280 requires that the
>   certificate be rejected.  Implementations that do support EKU MUST
>   support the following logic for certificate validation:
>
>   o  If no EKU extension, continue.
>
>   o  If EKU present AND contains either id-kp-ipsecIKE or
>      anyExtendedKeyUsage, continue.
>
>   o  Otherwise, reject cert.
>
>
> I believe that the attached patch adds the ipsecIKE extended key usage
> flag to openssl.
>
> Micah
>
>
>
> 0. http://tools.ietf.org/html/rfc4945#section-5.1.3.12
>
> Hi,

I took a look at your patch just by curiosity because I can't judge it.
However, there is a wrong copy/paste in obj_dat.h, even though this file is
generated automatically :

 0x2B,0x06,0x01,0x05,0x05,0x07,0x03,0x08,     /* *[682]* OBJ_time_stamp */
+0x2B,0x06,0x01,0x05,0x05,0x07,0x03,0x09,     /* *[682]* OBJ_OSCPSigning */
+0x2B,0x06,0x01,0x05,0x05,0x07,0x03,0x17,     /* [684] OBJ_ipsecIKE */
 0x2B,0x06,0x01,0x04,0x01,0x82,0x37,0x02,0x01,0x15,/* [690] OBJ_ms_code_ind
*/
 0x2B,0x06,0x01,0x04,0x01,0x82,0x37,0x02,0x01,0x16,/* [700] OBJ_ms_code_com
*/
 0x2B,0x06,0x01,0x04,0x01,0x82,0x37,0x0A,0x03,0x01,/* [710] OBJ_ms_ctl_sign
*/
@@ -1091,6 +1090,8 @@ static const ASN1_OBJECT nid_objs[NUM_NID]={
 {"emailProtection","E-mail Protection",NID_email_protect,8,
     &(lvalues[674]),0},
 {"timeStamping","Time Stamping",NID_time_stamp,8,&(lvalues[682]),0},
+{"OSCPSigning", "OSCP Signing",NID_OSCPSigning,8,&(lvalues*[683]*),0},
+{"ipsecIKE", "ipsec Internet Key Exchange
(IKE)",NID_ipsecIKE,8,&(lvalues[684]),0},

Reply via email to