Brian Minard | 1 Nov 2006 18:20

PKIX Design Survey: ECC Public Keys in Subject Public Key Info

Looking for input on the two questions at the end of this
message.

ECC Design Team Survey

Background

The PKIX WG has been presented with two different proposals
for the specification of ECC public keys in the subject public
key info field of X.509 certificates.

Proposal #1: A current PKIX ID
(http://www.ietf.org/internet-drafts/draft-ietf-pkix-ecc-pkalgs-03.txt)
based on the ANSI X9.62-2005 standard specifies a structured
a public key info field with (up to) four components:

* the algorithm family (i.e., ECC),

* the public key,

* an explicit or implicit specification of ECC parameters
  (implicit specifications include inheritance from the CA
  and OIDs that specify a named curve), and

* an optional set of OIDs specifying the supported modes
(e.g., 1 pass DH or full MQV).

The set of supported modes is very granular, and includes
ancillary cryptographic functions. For signature algorithms,
the mode specifies supported hash algorithms.  For example,
(Continue reading)

Camp, TracyX E | 2 Nov 2006 17:52
Picon
Favicon

RE: OpenSSL and LSB (patch)

 
I really didn't hear much back on this topic, but what I did hear seemed to support the approach I have been taking thus far.  Please see my previous message in this thread for the details.
 
So in hopes of moving this topic along in a practical sense, I have attached two patches that implement all the macro to function conversion that I believe would be necessary to support OpenSSL ABI stability from an LSB perspective going forward by allowing applications to always treat OpenSSL data structures as opaque types.
 
One patch is against the released OpenSSL 0.9.8d and another is against the development snapshot from October 16th.
 
As far as I can tell, these conversions should not present any sort of noticeable performance impact since they are almost all related to protocol setup in some manner.  I also believe the changes should not impact binary compatibility with applications that where build using the macro versions of these routines.  Where possible I've also attempted to preserve the coding style in use.
 
To get OpenSSL into the LSB either a different approach would need to be proposed, or some form of the attached patches would need to make it into an OpenSSL release, followed by a significant number of Linux distributions picking up that release or later.  There is an upcoming early next-year LSB 3.2 release that potentially could be the release vehicle for OpenSSL in LSB.
 
Comments, etc. welcomed.
 
Thanks,
 
Tracy Camp
Attachment (openssl_macrobegone_0.9.8d.patch): application/octet-stream, 23 KiB
Ben Laurie | 2 Nov 2006 18:12
Picon

Re: OpenSSL and LSB (patch)

Camp, TracyX E wrote:
>  
> I really didn't hear much back on this topic, but what I did hear seemed
> to support the approach I have been taking thus far.  Please see my
> previous message in this thread for the details.
>  
> So in hopes of moving this topic along in a practical sense, I have
> attached two patches that implement all the macro to function conversion
> that I believe would be necessary to support OpenSSL ABI stability from
> an LSB perspective going forward by allowing applications to always
> treat OpenSSL data structures as opaque types.
>  
> One patch is against the released OpenSSL 0.9.8d and another is against
> the development snapshot from October 16th.
>  
> As far as I can tell, these conversions should not present any sort of
> noticeable performance impact since they are almost all related to
> protocol setup in some manner.  I also believe the changes should not
> impact binary compatibility with applications that where build using the
> macro versions of these routines.  Where possible I've also attempted to
> preserve the coding style in use.
>  
> To get OpenSSL into the LSB either a different approach would need to be
> proposed, or some form of the attached patches would need to make it
> into an OpenSSL release, followed by a significant number of Linux
> distributions picking up that release or later.  There is an upcoming
> early next-year LSB 3.2 release that potentially could be the release
> vehicle for OpenSSL in LSB.
>  
> Comments, etc. welcomed.

I'm very much in favour of this. One comment, though - if you're going
to make structure opaque, then why not make them truly opaque  by
removing their definitions from the public headers?

>  
> Thanks,
>  
> Tracy Camp

--

-- 
http://www.apache-ssl.org/ben.html           http://www.links.org/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       openssl-dev <at> openssl.org
Automated List Manager                           majordomo <at> openssl.org

Camp, TracyX E | 2 Nov 2006 18:51
Picon
Favicon

RE: OpenSSL and LSB (patch)


>
>I'm very much in favour of this. One comment, though - if you're going
>to make structure opaque, then why not make them truly opaque  by
>removing their definitions from the public headers?

In LSB they would be truly opaque.  LSB works by producing a set of stub
libraries and generated headers that contain the defined interfaces.  In
those generated headers, the types would be opaque.  These stub libs and
headers however are only used by applications attempting to build with
the LSB environment, the real openssl remains unchanged and is utilized
at runtime.  I don't really see changing all of openssl directly as a
reasonable solution however since a vast mountain of software is already
written with those structures defined.

Tracy Camp

>
>
>-- 
>http://www.apache-ssl.org/ben.html           http://www.links.org/
>
>"There is no limit to what a man can do or how far he can go if he
>doesn't mind who gets the credit." - Robert Woodruff
>______________________________________________________________________
>OpenSSL Project                                 http://www.openssl.org
>Development Mailing List                       openssl-dev <at> openssl.org
>Automated List Manager                           majordomo <at> openssl.org
>
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       openssl-dev <at> openssl.org
Automated List Manager                           majordomo <at> openssl.org

Ben Laurie | 2 Nov 2006 19:05
Picon

Re: OpenSSL and LSB (patch)

Camp, TracyX E wrote:
>  
>> I'm very much in favour of this. One comment, though - if you're going
>> to make structure opaque, then why not make them truly opaque  by
>> removing their definitions from the public headers?
> 
> In LSB they would be truly opaque.  LSB works by producing a set of stub
> libraries and generated headers that contain the defined interfaces.  In
> those generated headers, the types would be opaque.  These stub libs and
> headers however are only used by applications attempting to build with
> the LSB environment, the real openssl remains unchanged and is utilized
> at runtime.  I don't really see changing all of openssl directly as a
> reasonable solution however since a vast mountain of software is already
> written with those structures defined.

How is that vast amount of software going to work under LSB, then?

In any case, ABI stability is not a problem unique to LSB, and I'm not
sure why we'd want to solve it for only that project.

Cheers,

Ben.

--

-- 
http://www.apache-ssl.org/ben.html           http://www.links.org/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       openssl-dev <at> openssl.org
Automated List Manager                           majordomo <at> openssl.org

Camp, TracyX E | 2 Nov 2006 19:22
Picon
Favicon

RE: OpenSSL and LSB (patch)


>How is that vast amount of software going to work under LSB, then?

LSB does not support all applications anyways (for example, anything
that has a direct kernel dependency is not a LSB application), and we
are not trying to do so here either.  Instead I'm attempting to be able
to support something close to 70% of existing applications (i.e. they
will 'just work' or only require minor tweaks to be LSB compliant),
whereas it might be a bit rude to entirely break the last 30% in the
more general openssl distribution case.

>In any case, ABI stability is not a problem unique to LSB, and I'm not
>sure why we'd want to solve it for only that project.

I'm personally totally okay with that, but I'm also really motived from
an LSB perspective and presume minimally invasive change would be the
most acceptable in the upstread OpenSSL distributions.  The difference
really is that with this patch you are more able to create ABI stable
applications by following good practice, but the choice is really yours,
but when using LSB you have to because LSB would force that upon you.

Tracy Camp

>
>Cheers,
>
>Ben.
>
>-- 
>http://www.apache-ssl.org/ben.html           http://www.links.org/
>
>"There is no limit to what a man can do or how far he can go if he
>doesn't mind who gets the credit." - Robert Woodruff
>______________________________________________________________________
>OpenSSL Project                                 http://www.openssl.org
>Development Mailing List                       openssl-dev <at> openssl.org
>Automated List Manager                           majordomo <at> openssl.org
>
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       openssl-dev <at> openssl.org
Automated List Manager                           majordomo <at> openssl.org

Vincenzo Sciarra | 2 Nov 2006 22:33
Picon

Re: HI

Credo che sei italiano quindi ti rispondo in italiano.
Il problema fondamentale di OpenSSL sta proprio nella documentazione.

E' scarsa e mal ridotta.

Dovresti "procurarti" qualche libro sul TLS programming oppure SSL programming
ti potrebbero essere di grande aiuto come sono stati per me.
Per le chiamate di sistema ti consiglio il developers forum di MacOSx
che stranamente è fatto meglio della documentazione di OpenSSL

Ciao

2006/10/31, stefano landucci <marlonbasta <at> gmail.com>:
> Hi,
> This is my first message.
> I find information about ECC and OpenSSL, I don't find anything in the web
> site of openSSL.
> I registered to mailing list to find information and documentation about it.
>
> Thank's
>
> Sorry for bad english
>
> --
> Stefano Landucci
>
> blog:    http://marlonbando.blogspot.com/
> icq:      318651357
> skype:  senzacanone

--

-- 
Vincenzo Sciarra
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       openssl-dev <at> openssl.org
Automated List Manager                           majordomo <at> openssl.org

Marlonbasta | 2 Nov 2006 22:47
Picon

Re: HI

In tanto grazie per la risposta.
Poi vorrei farti capire meglio la mia situazione...Io dovrei provare a 
fare uan comunicazione tra PDA e PC, basandomi sulla crittografia a 
Curve Ellittiche,
solo che prima di dover implementare qualcosa da capo, vole vedere se 
riuscivo ad utilizzare qualcosa che già c'è.

Grazie

Stefano

Vincenzo Sciarra ha scritto:
> Credo che sei italiano quindi ti rispondo in italiano.
> Il problema fondamentale di OpenSSL sta proprio nella documentazione.
>
> E' scarsa e mal ridotta.
>
> Dovresti "procurarti" qualche libro sul TLS programming oppure SSL 
> programming
> ti potrebbero essere di grande aiuto come sono stati per me.
> Per le chiamate di sistema ti consiglio il developers forum di MacOSx
> che stranamente è fatto meglio della documentazione di OpenSSL
>
> Ciao
>
>
>
> 2006/10/31, stefano landucci <marlonbasta <at> gmail.com>:
>> Hi,
>> This is my first message.
>> I find information about ECC and OpenSSL, I don't find anything in 
>> the web
>> site of openSSL.
>> I registered to mailing list to find information and documentation 
>> about it.
>>
>> Thank's
>>
>> Sorry for bad english
>>
>> -- 
>> Stefano Landucci
>>
>> blog:    http://marlonbando.blogspot.com/
>> icq:      318651357
>> skype:  senzacanone
>
>

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       openssl-dev <at> openssl.org
Automated List Manager                           majordomo <at> openssl.org

John Doe via RT | 3 Nov 2006 10:04
Picon
Favicon

[openssl.org #1422] Bug in X509_NAME_cmp


In openssl-0.9.7e and before, X509_NAME_cmp() returned the value 'j' at
this section:
	
  na=sk_X509_NAME_ENTRY_value(a->entries,i);
  nb=sk_X509_NAME_ENTRY_value(b->entries,i);
  j=na->value->type-nb-≥value->type;
  if (j) return(j);
	
Starting with openssl-0.9.7f, X509_NAME_cmp() now calls the new
asn1_string_memcmp() function even when 'j' is non-zero and it will
return the return-value of asn1_string_memcmp() as opposed to 'j'.
	
X509_NAME_cmp() is used by functions such as qsort() and bsearch() 
and so it's important that it returns a negative value when the 
first argument is smaller and a positive one when the second argument 
is greater. The problem now is that X509_NAME_cmp() may return the
return value of asn1_string_memcmp() which does a

 	int j;
 	j = a->length - b->length;
 	if (j)
 		return j;
	
before calling memcmp(). The comparison on the length of the strings
may result in a different return value sign than what memcmp() would
return. This may in turn mess up qsort() and bsearch() later.

My fix is to return the original value of 'j' without allowing
asn1_string_memcmp() to override it. This essentially restores the
original return value of X509_NAME_cmp() without modifying the new
additions.
	
Details of the bug:
	
>From the openssl-0.9.7f CHANGES file:
	
+  *) Perform some character comparisons of different types in X509_NAME_cmp:
+     this is needed for some certificates that reencode DNs into UTF8Strings
+     (in violation of RFC3280) and can't or wont issue name rollover
+     certificates.
+     [Steve Henson]
	
diff -rbB -U 6 openssl-0.9.7e/crypto/x509/x509_cmp.c openssl-0.9.7f/crypto/x509/x509_cmp.c
--- openssl-0.9.7e/crypto/x509/x509_cmp.c	Tue Nov 12 05:23:01 2002
+++ openssl-0.9.7f/crypto/x509/x509_cmp.c	Wed Jan 26 12:00:38 2005
 <at>  <at>  -251,39 +251,55  <at>  <at> 
 	if (la > 0 || lb > 0)
 		return la - lb;

 	return 0;
 }
	
+static int asn1_string_memcmp(ASN1_STRING *a, ASN1_STRING *b)
+	{
+	int j;
+	j = a->length - b->length;
+	if (j)
+		return j;
+	return memcmp(a->data, b->data, a->length);
+	}
+
+#define STR_TYPE_CMP (B_ASN1_PRINTABLESTRING|B_ASN1_T61STRING|B_ASN1_UTF8STRING)
+
 int X509_NAME_cmp(const X509_NAME *a, const X509_NAME *b)
 	{
 	int i,j;
 	X509_NAME_ENTRY *na,*nb;

-	if (sk_X509_NAME_ENTRY_num(a->entries)
-	    != sk_X509_NAME_ENTRY_num(b->entries))
-		return sk_X509_NAME_ENTRY_num(a->entries)
-		  -sk_X509_NAME_ENTRY_num(b->entries);
+	unsigned long nabit, nbbit;
+
+	j = sk_X509_NAME_ENTRY_num(a->entries)
+		  - sk_X509_NAME_ENTRY_num(b->entries);
+	if (j)
+		return j;
 	for (i=sk_X509_NAME_ENTRY_num(a->entries)-1; i>=0; i--)
 		{
 		na=sk_X509_NAME_ENTRY_value(a->entries,i);
 		nb=sk_X509_NAME_ENTRY_value(b->entries,i);
 		j=na->value->type-nb-≥value->type;
-		if (j) return(j);
-		if (na->value->type == V_ASN1_PRINTABLESTRING)
+		if (j)
+			{
+			nabit = ASN1_tag2bit(na->value->type);
+			nbbit = ASN1_tag2bit(nb->value->type);
+			if (!(nabit & STR_TYPE_CMP) ||
+				!(nbbit & STR_TYPE_CMP))
+				return j;
+			j = asn1_string_memcmp(na->value, nb->value);
+			}
+		else if (na->value->type == V_ASN1_PRINTABLESTRING)

and my patch to fix it is by returning the value of 'j' this function returned before:
	
--- openssl-0.9.8d/crypto/x509/x509_cmp.c       Tue Nov 30 17:45:30 2004
+++ openssl-0.9.8d.new/crypto/x509/x509_cmp.c   Thu Nov  2 14:42:11 2006
 <at>  <at>  -283,12 +283,17  <at>  <at> 
                j=na->value->type-nb-≥value->type;
                if (j)
                        {
+                        int j2;
                        nabit = ASN1_tag2bit(na->value->type);
                        nbbit = ASN1_tag2bit(nb->value->type);
                        if (!(nabit & STR_TYPE_CMP) ||
                                !(nbbit & STR_TYPE_CMP))
                                return j;
-                       j = asn1_string_memcmp(na->value, nb->value);
+                       j2 = asn1_string_memcmp(na->value, nb->value);
+                        if (j2)
+                          return j;
+                        else
+                          j = 0;
                        }
                else if (na->value->type == V_ASN1_PRINTABLESTRING)
                        j=nocase_spacenorm_cmp(na->value, nb->value);

 
____________________________________________________________________________________
Everyone is raving about the all-new Yahoo! Mail 
(http://advision.webevents.yahoo.com/mailbeta/)

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       openssl-dev <at> openssl.org
Automated List Manager                           majordomo <at> openssl.org

Vincenzo Sciarra | 4 Nov 2006 09:56
Picon

Re: HI

Openssl supporta la crittografia a Curve Ellittiche.

Il contesto viene chiamato ECC. La migliore implementazione credo sia
quella della SUN dove puoi trovare un po di documentazione

http://research.sun.com/projects/crypto/FrequenlyAskedQuestions.html

In bocca al lupo

2006/11/2, Marlonbasta <marlonbasta <at> gmail.com>:
> In tanto grazie per la risposta.
> Poi vorrei farti capire meglio la mia situazione...Io dovrei provare a
> fare uan comunicazione tra PDA e PC, basandomi sulla crittografia a
> Curve Ellittiche,
> solo che prima di dover implementare qualcosa da capo, vole vedere se
> riuscivo ad utilizzare qualcosa che già c'è.
>
> Grazie
>
> Stefano
>
>
> Vincenzo Sciarra ha scritto:
> > Credo che sei italiano quindi ti rispondo in italiano.
> > Il problema fondamentale di OpenSSL sta proprio nella documentazione.
> >
> > E' scarsa e mal ridotta.
> >
> > Dovresti "procurarti" qualche libro sul TLS programming oppure SSL
> > programming
> > ti potrebbero essere di grande aiuto come sono stati per me.
> > Per le chiamate di sistema ti consiglio il developers forum di MacOSx
> > che stranamente è fatto meglio della documentazione di OpenSSL
> >
> > Ciao
> >
> >
> >
> > 2006/10/31, stefano landucci <marlonbasta <at> gmail.com>:
> >> Hi,
> >> This is my first message.
> >> I find information about ECC and OpenSSL, I don't find anything in
> >> the web
> >> site of openSSL.
> >> I registered to mailing list to find information and documentation
> >> about it.
> >>
> >> Thank's
> >>
> >> Sorry for bad english
> >>
> >> --
> >> Stefano Landucci
> >>
> >> blog:    http://marlonbando.blogspot.com/
> >> icq:      318651357
> >> skype:  senzacanone
> >
> >
>
> ______________________________________________________________________
> OpenSSL Project                                 http://www.openssl.org
> Development Mailing List                       openssl-dev <at> openssl.org
> Automated List Manager                           majordomo <at> openssl.org
>

--

-- 
Vincenzo Sciarra
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       openssl-dev <at> openssl.org
Automated List Manager                           majordomo <at> openssl.org


Gmane