[openssl.org #2351] PATCH: Remove obsolete ipsec extended key usages

2010-09-29 Thread Micah Anderson via RT

Hi,

The extended key usages id-kp-ipsecEndSystem, id-kp-ipsecTunnel and
id-kp-ipsecUser are obsoleted as per RFC 4945 § 5.1.3.12 section title
ExtendedKeyUsage:

...  Note that there were three IPsecrelated object identifiers in EKU
that were assigned in 1999. The semantics of these values were never
clearly defined. The use of these three EKU values in IKE/IPsec is
obsolete and explicitly deprecated by this specification. CAs SHOULD NOT
issue certificates for use in IKE with them. (For historical reference
only, those values were id-kp-ipsecEndSystem, id-kp-ipsecTunnel, and
id-kpipsecUser.)  ...

I believe that the attached patch removes these extendedkey usages to
comply with the SHOULD NOT assertion in RFC 4945.

Note: A new extended key usage has been created for the Internet Key
Exchange (IKE) called id-kp-ipsecIKE has been added. A follow-up issue
will be created for that.

Micah




diff --git a/crypto/objects/obj_dat.h b/crypto/objects/obj_dat.h
index fe46624..e2345fb 100644
--- a/crypto/objects/obj_dat.h
+++ b/crypto/objects/obj_dat.h
@@ -334,9 +336,6 @@ static const unsigned char lvalues[5824]={
 0x2B,0x06,0x01,0x05,0x05,0x07,0x01,0x08, /* [2129] OBJ_sbgp_autonomousSysNum */
 0x2B,0x06,0x01,0x05,0x05,0x07,0x01,0x09, /* [2137] OBJ_sbgp_routerIdentifier */
 0x2B,0x06,0x01,0x05,0x05,0x07,0x02,0x03, /* [2145] OBJ_textNotice */
-0x2B,0x06,0x01,0x05,0x05,0x07,0x03,0x05, /* [2153] OBJ_ipsecEndSystem */
-0x2B,0x06,0x01,0x05,0x05,0x07,0x03,0x06, /* [2161] OBJ_ipsecTunnel */
-0x2B,0x06,0x01,0x05,0x05,0x07,0x03,0x07, /* [2169] OBJ_ipsecUser */
 0x2B,0x06,0x01,0x05,0x05,0x07,0x03,0x0A, /* [2177] OBJ_dvcs */
 0x2B,0x06,0x01,0x05,0x05,0x07,0x04,0x01, /* [2185] OBJ_id_it_caProtEncCert */
 0x2B,0x06,0x01,0x05,0x05,0x07,0x04,0x02, /* [2193] OBJ_id_it_signKeyPairTypes */
@@ -1357,10 +1358,6 @@ static const ASN1_OBJECT nid_objs[NUM_NID]={
 {sbgp-routerIdentifier,sbgp-routerIdentifier,
 	NID_sbgp_routerIdentifier,8,(lvalues[2137]),0},
 {textNotice,textNotice,NID_textNotice,8,(lvalues[2145]),0},
-{ipsecEndSystem,IPSec End System,NID_ipsecEndSystem,8,
-	(lvalues[2153]),0},
-{ipsecTunnel,IPSec Tunnel,NID_ipsecTunnel,8,(lvalues[2161]),0},
-{ipsecUser,IPSec User,NID_ipsecUser,8,(lvalues[2169]),0},
 {DVCS,dvcs,NID_dvcs,8,(lvalues[2177]),0},
 {id-it-caProtEncCert,id-it-caProtEncCert,NID_id_it_caProtEncCert,
 	8,(lvalues[2185]),0},
@@ -2897,9 +2894,6 @@ static const unsigned int sn_objs[NUM_SN]={
 647,	/* international-organizations */
 869,	/* internationaliSDNNumber */
 142,	/* invalidityDate */
-294,	/* ipsecEndSystem */
-295,	/* ipsecTunnel */
-296,	/* ipsecUser */
 86,	/* issuerAltName */
 770,	/* issuingDistributionPoint */
 492,	/* janetMailbox */
@@ -4629,7 +4623,4 @@ static const unsigned int obj_objs[NUM_OBJ]={
 130,	/* OBJ_client_auth  1 3 6 1 5 5 7 3 2 */
 131,	/* OBJ_code_sign1 3 6 1 5 5 7 3 3 */
 132,	/* OBJ_email_protect1 3 6 1 5 5 7 3 4 */
-294,	/* OBJ_ipsecEndSystem   1 3 6 1 5 5 7 3 5 */
-295,	/* OBJ_ipsecTunnel  1 3 6 1 5 5 7 3 6 */
-296,	/* OBJ_ipsecUser1 3 6 1 5 5 7 3 7 */
 133,	/* OBJ_time_stamp   1 3 6 1 5 5 7 3 8 */
diff --git a/crypto/objects/obj_mac.h b/crypto/objects/obj_mac.h
index 27304e1..decf0cc 100644
--- a/crypto/objects/obj_mac.h
+++ b/crypto/objects/obj_mac.h
@@ -1500,21 +1500,6 @@
 #define NID_email_protect		132
 #define OBJ_email_protect		OBJ_id_kp,4L
 
-#define SN_ipsecEndSystem		ipsecEndSystem
-#define LN_ipsecEndSystem		IPSec End System
-#define NID_ipsecEndSystem		294
-#define OBJ_ipsecEndSystem		OBJ_id_kp,5L
-
-#define SN_ipsecTunnel		ipsecTunnel
-#define LN_ipsecTunnel		IPSec Tunnel
-#define NID_ipsecTunnel		295
-#define OBJ_ipsecTunnel		OBJ_id_kp,6L
-
-#define SN_ipsecUser		ipsecUser
-#define LN_ipsecUser		IPSec User
-#define NID_ipsecUser		296
-#define OBJ_ipsecUser		OBJ_id_kp,7L
-
 #define SN_time_stamp		timeStamping
 #define LN_time_stamp		Time Stamping
 #define NID_time_stamp		133
diff --git a/crypto/objects/obj_mac.num b/crypto/objects/obj_mac.num
index 8c50aac..4bc3dfb 100644
--- a/crypto/objects/obj_mac.num
+++ b/crypto/objects/obj_mac.num
@@ -291,9 +291,6 @@ sbgp_ipAddrBlock		290
 sbgp_autonomousSysNum		291
 sbgp_routerIdentifier		292
 textNotice		293
-ipsecEndSystem		294
-ipsecTunnel		295
-ipsecUser		296
 dvcs		297
 id_it_caProtEncCert		298
 id_it_signKeyPairTypes		299
\ No newline at end of file
diff --git a/crypto/objects/objects.txt b/crypto/objects/objects.txt
index 52ac0a6..f477aa5 100644
--- a/crypto/objects/objects.txt
+++ b/crypto/objects/objects.txt
@@ -481,8 +481,5 @@ id-kp 2			: clientAuth		: TLS Web Client Authentication
 id-kp 3			: codeSigning		: Code Signing
 !Cname email-protect
 id-kp 4			: emailProtection	: E-mail Protection
-id-kp 5			: ipsecEndSystem	: IPSec End System
-id-kp 6			: ipsecTunnel		: IPSec Tunnel
-id-kp 7			: ipsecUser		: IPSec User
 !Cname time-stamp
 id-kp 8			: timeStamping		: Time 

[openssl.org #2352] PATCH: Add new extended key usage ipsecIKE

2010-09-29 Thread Micah Anderson via RT

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


-- 




diff --git a/crypto/objects/obj_dat.h b/crypto/objects/obj_dat.h
index fe46624..e2345fb 100644
--- a/crypto/objects/obj_dat.h
+++ b/crypto/objects/obj_dat.h
@@ -175,6 +175,8 @@ static const unsigned char lvalues[5824]={
 0x2B,0x06,0x01,0x05,0x05,0x07,0x03,0x03, /* [666] OBJ_code_sign */
 0x2B,0x06,0x01,0x05,0x05,0x07,0x03,0x04, /* [674] OBJ_email_protect */
 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},
 {msCodeInd,Microsoft Individual Code Signing,NID_ms_code_ind,10,
 	(lvalues[690]),0},
 {msCodeCom,Microsoft Commercial Code Signing,NID_ms_code_com,10,
@@ -4636,5 +4627,6 @@
 180,	/* OBJ_OCSP_sign1 3 6 1 5 5 7 3 9 */
 297,	/* OBJ_dvcs 1 3 6 1 5 5 7 3 10 */
+893,	/* OBJ_ipsec_IKE1 3 6 1 5 5 7 3 17 */
 298,	/* OBJ_id_it_caProtEncCert  1 3 6 1 5 5 7 4 1 */
 299,	/* OBJ_id_it_signKeyPairTypes   1 3 6 1 5 5 7 4 2 */
 300,	/* OBJ_id_it_encKeyPairTypes1 3 6 1 5 5 7 4 3 */
diff --git a/crypto/objects/obj_mac.h b/crypto/objects/obj_mac.h
index 27304e1..decf0cc 100644
--- a/crypto/objects/obj_mac.h
+++ b/crypto/objects/obj_mac.h
@@ -1530,6 +1515,11 @@
 #define NID_dvcs		297
 #define OBJ_dvcs		OBJ_id_kp,10L
 
+#define SN_ipsec_IKE		ipsecIKE
+#define LN_ipsec_IKE		ipsec Internet Key Exchange (IKE)
+#define NID_ipsec_IKE		893
+#define OBJ_ipsec_IKE		OBJ_id_kp,17L
+
 #define SN_id_it_caProtEncCert		id-it-caProtEncCert
 #define NID_id_it_caProtEncCert		298
 #define OBJ_id_it_caProtEncCert		OBJ_id_it,1L
diff --git a/crypto/objects/obj_mac.num b/crypto/objects/obj_mac.num
index 8c50aac..4bc3dfb 100644
--- a/crypto/objects/obj_mac.num
+++ b/crypto/objects/obj_mac.num
@@ -890,3 +887,4 @@ houseIdentifier		889
 supportedAlgorithms		890
 deltaRevocationList		891
 dmdName		892
+ipsecIKE	893
\ No newline at end of file
diff --git a/crypto/objects/objects.h b/crypto/objects/objects.h
index bd0ee52..191c895 100644
--- a/crypto/objects/objects.h
+++ b/crypto/objects/objects.h
@@ -714,6 +714,16 @@
 #define NID_time_stamp			133
 #define OBJ_time_stamp			OBJ_id_kp,8L
 
+#define SN_OCSP_sign			OCSPSigning
+#define LN_OCSP_sign			OCSP Signing
+#define NID_OCSP_sign			180
+#define OBJ_OCSP_sign			OBJ_id_kp,9L
+
+#define SN_ipsec_IKE			ipsecIKE
+#define LN_ipsec_IKE			ipsec Internet Key Exchange (IKE)
+#define NID_ipsec_IKE			893	
+#define OBJ_ipsec_IKE			OBJ_id_kp,17L
+
 /* Additional extended key usage OIDs: Microsoft */
 
 #define SN_ms_code_ind			msCodeInd

[openssl.org #2353] PATCH: add missing OSCPSigning bits

2010-09-29 Thread Micah Anderson via RT

In a recent attempt to add missing extended key usage pieces, I noticed
that the OCSPSigning extended key usage was not fully implemented. It is
perfectly possible that I am not fully cognizant of how the code works,
and it is properly implemented. It is however, clearly not documented. 

The attached patch adds the bits that to my relatively uneducated eye
are missing for OSCPSigning extended key usage, including the missing
documentation update. 

Micah





diff --git a/crypto/objects/obj_dat.h b/crypto/objects/obj_dat.h
index fe46624..e2345fb 100644
--- a/crypto/objects/obj_dat.h
+++ b/crypto/objects/obj_dat.h
@@ -175,3 +175,4 @@ static const unsigned char lvalues[5824]={
 0x2B,0x06,0x01,0x05,0x05,0x07,0x03,0x03, /* [666] OBJ_code_sign */
 0x2B,0x06,0x01,0x05,0x05,0x07,0x03,0x04, /* [674] OBJ_email_protect */
 0x2B,0x06,0x01,0x05,0x05,0x07,0x03,0x08, /* [682] OBJ_time_stamp */
+0x2B,0x06,0x01,0x05,0x05,0x07,0x03,0x09, /* [682] OBJ_OSCPSigning */
@@ -1091,3 +1090,4 @@ 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},
diff --git a/crypto/objects/objects.h b/crypto/objects/objects.h
index bd0ee52..191c895 100644
--- a/crypto/objects/objects.h
+++ b/crypto/objects/objects.h
@@ -714,3 +714,7 @@
 #define NID_time_stamp			133
 #define OBJ_time_stamp			OBJ_id_kp,8L
 
+#define SN_OCSP_sign			OCSPSigning
+#define LN_OCSP_sign			OCSP Signing
+#define NID_OCSP_sign			180
+#define OBJ_OCSP_sign			OBJ_id_kp,9L
diff --git a/doc/apps/x509v3_config.pod b/doc/apps/x509v3_config.pod
index 0450067..e138eb3 100644
--- a/doc/apps/x509v3_config.pod
+++ b/doc/apps/x509v3_config.pod
@@ -115,3 +115,4 @@ following PKIX, NS and MS values are meaningful:
  codeSigning		Code signing.
  emailProtection	E-mail Protection (S/MIME).
  timeStamping		Trusted Timestamping
+ OCSPSigning		OCSP Signing


Re: [openssl.org #2352] PATCH: Add new extended key usage ipsecIKE

2010-09-29 Thread Gregory Bellier
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},


[openssl.org #2354] [PATCH] Increase Default RSA Key Size to 2048-bits

2010-09-29 Thread Rob Stradling via RT
NIST (SP800-57 Part 1) recommends a minimum RSA key size of 2048-bits beyond 
2010.  From January 1st 2011, in order to comply with the current Microsoft[1] 
and Mozilla[2] CA Policies, Commercial CAs will no longer be permitted to 
issue certificates with RSA key sizes of 2048-bit.

Please accept the attached patch, which increases the default RSA key size to 
2048-bits for the req, genrsa and genpkey apps.

Thanks.

[1] http://technet.microsoft.com/en-us/library/cc751157.aspx says:
we have advised Certificate Authorities...to transition their subordinate and 
end-certificates to 2048-bit RSA certificates, and to complete this transition 
for any root certificate distributed by the Program no later than December 31, 
2010.

[2] https://wiki.mozilla.org/CA:MD5and1024 says:
December 31, 2010 – CAs should stop issuing intermediate and end-entity 
certificates from roots with RSA key sizes smaller than 2048 bits. All CAs 
should stop issuing intermediate and end-entity certificates with RSA key size 
smaller than 2048 bits under any root.

Rob Stradling
Senior Research  Development Scientist
COMODO - Creating Trust Online
Office Tel: +44.(0)1274.730505
Office Fax: +44.(0)1274.730909
www.comodo.com

COMODO CA Limited, Registered in England No. 04058690
Registered Office:
  3rd Floor, 26 Office Village, Exchange Quay,
  Trafford Road, Salford, Manchester M5 3EQ

This e-mail and any files transmitted with it are confidential and intended
solely for the use of the individual or entity to whom they are addressed.
If you have received this email in error please notify the sender by replying
to the e-mail containing this attachment. Replies to this email may be
monitored by Comodo for operational or business reasons. Whilst every
endeavour is taken to ensure that e-mails are free from viruses, no liability
can be accepted and the recipient is requested to use their own virus checking
software.

Index: apps/genrsa.c
===
RCS file: /v/openssl/cvs/openssl/apps/genrsa.c,v
retrieving revision 1.40
diff -U 5 -r1.40 genrsa.c
--- apps/genrsa.c	1 Mar 2010 14:22:21 -	1.40
+++ apps/genrsa.c	28 Sep 2010 14:44:44 -
@@ -76,11 +76,11 @@
 #include openssl/evp.h
 #include openssl/x509.h
 #include openssl/pem.h
 #include openssl/rand.h
 
-#define DEFBITS	512
+#define DEFBITS	2048
 #undef PROG
 #define PROG genrsa_main
 
 static int MS_CALLBACK genrsa_cb(int p, int n, BN_GENCB *cb);
 
Index: apps/openssl-vms.cnf
===
RCS file: /v/openssl/cvs/openssl/apps/openssl-vms.cnf,v
retrieving revision 1.11
diff -U 5 -r1.11 openssl-vms.cnf
--- apps/openssl-vms.cnf	23 Apr 2009 16:32:37 -	1.11
+++ apps/openssl-vms.cnf	28 Sep 2010 14:44:44 -
@@ -101,11 +101,11 @@
 commonName		= supplied
 emailAddress		= optional
 
 
 [ req ]
-default_bits		= 1024
+default_bits		= 2048
 default_keyfile 	= privkey.pem
 distinguished_name	= req_distinguished_name
 attributes		= req_attributes
 x509_extensions	= v3_ca	# The extentions to add to the self signed cert
 
Index: apps/openssl.cnf
===
RCS file: /v/openssl/cvs/openssl/apps/openssl.cnf,v
retrieving revision 1.32
diff -U 5 -r1.32 openssl.cnf
--- apps/openssl.cnf	4 Apr 2009 19:54:02 -	1.32
+++ apps/openssl.cnf	28 Sep 2010 14:44:44 -
@@ -101,11 +101,11 @@
 commonName		= supplied
 emailAddress		= optional
 
 
 [ req ]
-default_bits		= 1024
+default_bits		= 2048
 default_keyfile 	= privkey.pem
 distinguished_name	= req_distinguished_name
 attributes		= req_attributes
 x509_extensions	= v3_ca	# The extentions to add to the self signed cert
 
Index: apps/req.c
===
RCS file: /v/openssl/cvs/openssl/apps/req.c,v
retrieving revision 1.146
diff -U 5 -r1.146 req.c
--- apps/req.c	14 Mar 2010 12:54:45 -	1.146
+++ apps/req.c	28 Sep 2010 14:44:44 -
@@ -97,11 +97,11 @@
 #define V3_EXTENSIONS	x509_extensions
 #define REQ_EXTENSIONS	req_extensions
 #define STRING_MASK	string_mask
 #define UTF8_IN		utf8
 
-#define DEFAULT_KEY_LENGTH	512
+#define DEFAULT_KEY_LENGTH	2048
 #define MIN_KEY_LENGTH		384
 
 #undef PROG
 #define PROG	req_main
 
Index: crypto/rsa/rsa_pmeth.c
===
RCS file: /v/openssl/cvs/openssl/crypto/rsa/rsa_pmeth.c,v
retrieving revision 1.39
diff -U 5 -r1.39 rsa_pmeth.c
--- crypto/rsa/rsa_pmeth.c	1 Jun 2010 14:39:01 -	1.39
+++ crypto/rsa/rsa_pmeth.c	28 Sep 2010 14:44:44 -
@@ -91,11 +91,11 @@
 	{
 	RSA_PKEY_CTX *rctx;
 	rctx = OPENSSL_malloc(sizeof(RSA_PKEY_CTX));
 	if (!rctx)
 		return 0;
-	rctx-nbits = 1024;
+	rctx-nbits = 2048;
 	rctx-pub_exp = NULL;
 	rctx-pad_mode = RSA_PKCS1_PADDING;
 	rctx-md = NULL;
 	rctx-mgf1md = NULL;
 	

[openssl.org #2316] Build issue on Tru64 (Dl_info must specify a type)

2010-09-29 Thread Ingersoll, Nelson via RT


   I am also attempting to build OpenSSL 1.0.0a on an antique OSF1 
system-name-here V4.0 1530 alpha alpha Tru64 system running Alpha 4.0G.  I 
also get the error about dli not being declared.  This is the last of the 
compile log where it fails:

cc -I.. -I../.. -I../asn1 -I../evp -I../../include  -DOPENSSL_THREADS -pthread 
-DDSO_DLFCN -DHAVE_DLFCN_H -std1 -tune host -fast -readonly_strings 
-DOPENSSL_BN_ASM_MONT   -c -o dso_dlfcn.o dso_dlfcn.c
cc: Error: dso_dlfcn.c, line 445: In this declaration, Dl_info must specify a 
type. (badparsedecl)
Dl_info dli;
^
cc: Error: dso_dlfcn.c, line 455: In this statement, dli is not declared. 
(undeclared)
if (dladdr(addr,dli))

---

I looked at the page http://cvs.openssl.org/chngview?cn=19501 and saw that the 
change to dso_dlfcn.c was:

+# ifdef __osf__
+#  define __EXTENSIONS__
+# endif

I validated that the version of dso_dlfcn.c has this change.  It still gets 
this compiler error.  I looked a bit deeper and determined that the struct 
Dl_info is not being created because __sgi is NOT defined.

As a test I defined __sgi temporarily and the dso_dlfcn.c module compiled.  I 
have no clue as to where __sgi might correctly be defined or what it means.  To 
the best of my knowledge currently, its meaning must be make Nelson work 
harder.

My mod is a TEST ONLY to validate my troubleshooting.  Here's the diff from 
original March 2010 (v1.35) dso_dlfcn.c code and my mods.

##
a402
#define __sgi
.
a440
#undef __sgi
.
##

Don't worry too much.  The compile fails later on in b_sock.c.  I'll look into 
that later if I can.  Thanks for your attention.  

Nelson E. Ingersoll
I.T. Senior Systems Engineer
ATMEL Corporation


__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org