Re: strangeness in `x509 -noout -text` output

[Dr S N Henson]

Lutz Jaenicke wrote:
 
 On Fri, Apr 26, 2002 at 12:38:05PM +0200, Robert Joop wrote:
  `x509 -noout -text` prints inconsistent output.
 
  ... openssl x509 -noout -text -in old.pem | grep Issuer:
  Issuer: [EMAIL PROTECTED], CN=CA UCO, O=Universidad de Cordoba, C=ES
  ... openssl x509 -noout -text -in new.pem | grep Issuer:
  Issuer: C=ES, O=Universidad de Cordoba, CN=AC [EMAIL PROTECTED]
 
  see the / that magically appears, instead of a , ?
  if found the place that does this magic and commented it out:
 
  ... openssl x509 -noout -text -in old.pem | grep Issuer:
  Issuer: [EMAIL PROTECTED], CN=CA UCO, O=Universidad de Cordoba, C=ES
  ... openssl x509 -noout -text -in new.pem | grep Issuer:
  Issuer: C=ES, O=Universidad de Cordoba, CN=AC UCO, [EMAIL PROTECTED]
 
  it does it because the type emailAddress starts lower case!
 
 Your analysis is technically correct. If the object name is starting with
 an uppercase letter, the / is replaced with the , , otherwise it is
 not.
 However: the section you are essentially removing (by commenting out)
 may be there for a reason. I have not used this functionality myself,
 so I don't know why this distinction is made. Therefore I am reluctant
 to touch it. Steve, could you kindly have a look into this?
 

By default the code ultimately uses the old X509_NAME_print function to
display DNs. This results in the weirdness mentioned and all manner of
odd output if the DN contains things like BMPStrings.

X509_NAME_print is only retained for compatibility. Changing it might do
odd things if anyone parses or hashes its output for some reason: that
isn't advisable but something might.

If appropriate flags are passed to the X509_print_ex function then much
more sensible output is produced using the X509_NAME_print_ex function.
The -nameopt option can be used for this (see manual page): -nameopt
oneline is a good place to start.

I'd say that X509_NAME_print shouldn't be touched because new code
should call X509_NAME_print_ex() 

However a new FAQ entry might be in order or possibly changing the
default display options so that the old behaviour is no longer the
default and adding a -nameopt old option is explicitly needed instead.

Steve.
-- 
Dr Stephen N. Henson.   http://www.drh-consultancy.demon.co.uk/
Personal Email: [EMAIL PROTECTED] 
Senior crypto engineer, Gemplus: http://www.gemplus.com/
Core developer of the   OpenSSL project: http://www.openssl.org/
Business Email: [EMAIL PROTECTED] PGP key: via homepage.
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: API functions for ASN1 on openssl

[Dr S N Henson]

Benzy Gabay wrote:
 
 Dr S N Henson,
 
 First I want to thank you for the answer.
 Secondly, you mentioned in your answer that I should use version 0.9.7.
 I can't seem to find the 0.9.7 on openssl.org.
 where can I get d/l it from?
 

It hasn't been released yet but you can get development snapshots.

Steve.
-- 
Dr Stephen N. Henson.   http://www.drh-consultancy.demon.co.uk/
Personal Email: [EMAIL PROTECTED] 
Senior crypto engineer, Gemplus: http://www.gemplus.com/
Core developer of the   OpenSSL project: http://www.openssl.org/
Business Email: [EMAIL PROTECTED] PGP key: via homepage.
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: manpage of EVP_SealFinal

[Dr S N Henson]

thomas poindessous wrote:
 
 Hi,
 in manpage (version 0.9.6b et version 0.9.7-stable-SNAP-20020317),
 there is :
 --
 int EVP_SealFinal(EVP_CIPHER_CTX *ctx, unsigned char *out,
 int *outl);
 
 and
   EVP_SealUpdate() and EVP_SealFinal() return 1 for success and 0 for
failure.
 -
 
 But in p_seal.c, there is :
 
 void EVP_SealFinal(EVP_CIPHER_CTX *ctx, unsigned char *out, int *outl)
 
 So, there is a problem.
 

Yes, it should return a value in 0.9.7. I'll commit a fix.

Steve.
-- 
Dr Stephen N. Henson.   http://www.drh-consultancy.demon.co.uk/
Personal Email: [EMAIL PROTECTED] 
Senior crypto engineer, Gemplus: http://www.gemplus.com/
Core developer of the   OpenSSL project: http://www.openssl.org/
Business Email: [EMAIL PROTECTED] PGP key: via homepage.

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: DES...

[Dr S N Henson]

Jeffrey Altman wrote:
 
  From: Jeffrey Altman [EMAIL PROTECTED]
 
  jaltman I prefer that des_old.h be compatible with libdes since that apps that
  jaltman are built using it assume that the api they were using was constant
  jaltman and unchanging.
 
  The way things work now, there is at least no clash with libdes on the
  symbol level.
 
  The whole situation is otherwise a lose-lose one.  There will always
  be someone loseing from the changes we make.  Either we lose libdes
  compatibility by default or we lose the openssl 0.9.6 one.  Take your
  pick.  It has been pointed out (and I think I agree) that OpenSSL
  should prefer to be as compatible with the previous version of itself
  before being compatible with anything external (like libdes).
 
 Yes, but let's remember the reason this whole situation came up in the
 first place.  There are a large number of applications that link to
 both Kerberos 4 and OpenSSL in place of libdes.a.  These applications
 are not likely to be updated nor supported and yet we don't want to
 see all of them break simply because they load des.h.
 

Is there some particular reason why such applications couldn't use the
EVP layer? An attempt has been made to keep this consistent and to make
any enhancements backwards compatible. In fact some of the more recent
changes would have been substantially easier if EVP compatibility wasn't
an issue.

Steve.






-- 
Dr Stephen N. Henson.   http://www.drh-consultancy.demon.co.uk/
Personal Email: [EMAIL PROTECTED] 
Senior crypto engineer, Gemplus: http://www.gemplus.com/
Core developer of the   OpenSSL project: http://www.openssl.org/
Business Email: [EMAIL PROTECTED] PGP key: via homepage.
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: use evp? (was DES...)

[Dr S N Henson]

Rodney Thayer wrote:
 
 At 09:29 PM 3/21/2002 +, S.Henson wrote:
 Is there some particular reason why such applications couldn't use the
 EVP layer? An attempt has been made to keep this consistent and to make
 any enhancements backwards compatible. In fact some of the more recent
 changes would have been substantially easier if EVP compatibility wasn't
 an issue.
 
 EVP is yet another opportunity to abuse OpenSSL by pretending it's
 a crypto library.  It doesn't do public key operations, and it doesn't
 let you access the engines.  

Indeed it doesn't allow public key operations. However my query was
related to why application use low level symmetric cipher and digest
routines instead of EVP.

Steve.
-- 
Dr Stephen N. Henson.   http://www.drh-consultancy.demon.co.uk/
Personal Email: [EMAIL PROTECTED] 
Senior crypto engineer, Gemplus: http://www.gemplus.com/
Core developer of the   OpenSSL project: http://www.openssl.org/
Business Email: [EMAIL PROTECTED] PGP key: via homepage.
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: Question about PKCS12_parse()

[Dr S N Henson]

Masanori Satake wrote:
 
 I tried parsing the PFX file attached(passphrase:test) using PKCS12_parse()
 function.
 However I cannot get the right value of DSA private key parameter x.
 
 And I  tried executing open-ssl command following
  openssl -in target.pfx -out target.key -nocerts -nodes.
 I found that this case also resulted in that target.key outputfile has wrong
 private key parameter x.
 
 I suppose that wrong parameter x is outputted only when MSB of parameter x
 is ON.
 
 If there are any information on this issue, please let me know.
 Thank you in advance,
 

Thanks for the file. I've analysed it and its yet another broken DSA key
format. What it is doing is as I suspected. It is incorrectly encoding
the ASN1 integer by not including an additional zero if the MSB is set.
Without the zero its a negative integer.

You can see this for yourself if you enable the DEBUG_DECRYPT option in
p12_decr.c then dumpasn1 or asn1parse (with -strparse option ) the DER1
file. The key component shows as negative.

You can make OpenSSL tolerate this broken format (which I'll add to
OpenSSL core code: it tolerates all manner of other broken ones too) by
changing line 162 (or thereabouts) in evp_pkey.c:

  } else {
-- if (!(privkey=d2i_ASN1_INTEGER (NULL, p, pkeylen))) {
  EVPerr(EVP_F_EVP_PKCS82PKEY,
EVP_R_DECODE_ERROR);
  goto dsaerr;
  }
  param = p8-pkeyalg-parameter;
  }
change the d2i_ASN1_INTEGER to d2i_ASN1_UINTEGER.

Steve.
-- 
Dr Stephen N. Henson.   http://www.drh-consultancy.demon.co.uk/
Personal Email: [EMAIL PROTECTED] 
Senior crypto engineer, Gemplus: http://www.gemplus.com/
Core developer of the   OpenSSL project: http://www.openssl.org/
Business Email: [EMAIL PROTECTED] PGP key: via homepage.

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: Question about PKCS12_parse()

[Dr S N Henson]

Masanori Satake wrote:
 
 I tried parsing the PFX file attached(passphrase:test) using PKCS12_parse()
 function.
 However I cannot get the right value of DSA private key parameter x.
 
 And I  tried executing open-ssl command following
  openssl -in target.pfx -out target.key -nocerts -nodes.
 I found that this case also resulted in that target.key outputfile has wrong
 private key parameter x.
 
 I suppose that wrong parameter x is outputted only when MSB of parameter x
 is ON.
 
 If there are any information on this issue, please let me know.
 Thank you in advance,
 

What makes you think its the wrong value if the MSB is set? Does it
include a leading zero or does the value just look wrong?

If so it may be the MS PKCS#12 export stuff using an invalid ASN1
INTEGER encoding. If the MSB is set it should prepend a zero otherwise
it is negative.

BTW what MSIE.OS are you using to create that PKCS#12 file? I tried this
a while ago and it wouldn't export a DSA key to a PKCS#12 file.

Steve.
-- 
Dr Stephen N. Henson.   http://www.drh-consultancy.demon.co.uk/
Personal Email: [EMAIL PROTECTED] 
Senior crypto engineer, Gemplus: http://www.gemplus.com/
Core developer of the   OpenSSL project: http://www.openssl.org/
Business Email: [EMAIL PROTECTED] PGP key: via homepage.

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: openssl ca sets wrong authorityKeyIdentifier

[Dr S N Henson]

Michael Bell wrote:
 
 Hi,
 
 I found a bug in openssl ca. If you set authorityKeyIdentifier to
 keyid and issuer always then the keyid will be set correctly but the
 issuer is wrong.
 
 Example:
 
 Root-CA -- Sub-Level 1 CA -- Sub-Level 2 CA -- User
 
 If I issue a certificate for a user then the issuer of the CA-cert
 is the DN of the Root-CA.
 

What do you mean here? Are you saying that the authorityKeyIdentifier in
Sub-Level 2 CA issuer name is the root CA? If so that's correct because
its telling you the issuer and serial number of the CA that issued it.


 I found a problem in two files:
 

description deleted

The i2v functions convert the internal for (C structure) into a stack of
name+value pairs and are used to produce a human readable version of the
extension. That's actually not connected with the way the authority key
identifier is automatically generated. 

The code to do that is in v2i_AUTHORITY_KEYID().

Steve.
-- 
Dr Stephen N. Henson.   http://www.drh-consultancy.demon.co.uk/
Personal Email: [EMAIL PROTECTED] 
Senior crypto engineer, Gemplus: http://www.gemplus.com/
Core developer of the   OpenSSL project: http://www.openssl.org/
Business Email: [EMAIL PROTECTED] PGP key: via homepage.

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: API functions for ASN1 on openssl

[Dr S N Henson]

 Benzy Gabay wrote:
 
 Hi,
 
 I'm trying programmatically to code / decode ASN1 streams.
 - Could someone tell me what are the set of API functions that I can
 use to code / decode ASN1 streams.
 
 

Applications use the i2d/d2i functions to encode or decode data between
memory and C structures containing each field. Currently the ASN1
functions are memory based: that is the whole encoding needs to be in
memory.

The old ASN1 code (pre 0.9.7) was buggy and an absolute nightmare to
write. I must have spent a couple of months coding the PKCS#12
structures in there some years back.

You really need to use OpenSSL 0.9.7 development snapshots for this, the
ASN1 code has been completely rewritten (by me!) and vastly easier to
use. The old stuff is obsolete and will be phased out at some point.
Also any structures written using the new ASN1 code should retain
compatibility with any future extensions such as streaming I/O based
encoders and decoders.

If you want to create your own ASN1 structures then the best thing to do
is look at some examples like those in ocsp_asn.c and the corresponding
structures in ocsp.h . There isn't any documentation yet but several
people have picked it up from just browsing the source code.

Steve.
-- 
Dr Stephen N. Henson.   http://www.drh-consultancy.demon.co.uk/
Personal Email: [EMAIL PROTECTED] 
Senior crypto engineer, Gemplus: http://www.gemplus.com/
Core developer of the   OpenSSL project: http://www.openssl.org/
Business Email: [EMAIL PROTECTED] PGP key: via homepage.

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: cvs commit: openssl/ssl kssl.c

[Dr S N Henson]

Jeffrey Altman wrote:
 
 To make it very clear, the locations that I'm seeing warnings are:
 
 ssl\kssl.c:
 
 In print_krb5_data() kdata-length is unsigned
 
 In print_krb5_keyblock() keyblk-length is unsigned
 
 In print_krb5_princ() princ-realm.length and
 princ-realm.data[i].length are unsigned.
 
 and then in ssltest.c (not related to kerberos) I'm seeing an unsigned
 vs signed comparison on line 1058:  r  num
 

As I mentioned I got kerberos 1.2.4 sources from:

http://non-us.debian.org/debian-non-US/pool/non-US/main/k/krb5

kdata is of type krb5_data and in my version the kerberos header file
krb5.h contains:

typedef struct _krb5_data {
krb5_magic magic;
int length;
char FAR *data;
} krb5_data;

This is in kerbsrc.zip generated from Unix. I've checked the linux
headers and the same thing is in there. Maybe there are different
versions of the source with different types for this field?

I'll just cast it to (int) in the above cases, that should shut the
compiler up.

Steve.
-- 
Dr Stephen N. Henson.   http://www.drh-consultancy.demon.co.uk/
Personal Email: [EMAIL PROTECTED] 
Senior crypto engineer, Gemplus: http://www.gemplus.com/
Core developer of the   OpenSSL project: http://www.openssl.org/
Business Email: [EMAIL PROTECTED] PGP key: via homepage.

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: openssl ca sets wrong authorityKeyIdentifier

[Dr S N Henson]

Michael Bell wrote:
 
 Dr S N Henson schrieb:
 
  Michael Bell wrote:
  
   Hi,
  
   I found a bug in openssl ca. If you set authorityKeyIdentifier to
   keyid and issuer always then the keyid will be set correctly but the
   issuer is wrong.
  
   Example:
  
   Root-CA -- Sub-Level 1 CA -- Sub-Level 2 CA -- User
  
   If I issue a certificate for a user then the issuer of the CA-cert
   is the DN of the Root-CA.
  
 
  What do you mean here? Are you saying that the authorityKeyIdentifier in
  Sub-Level 2 CA issuer name is the root CA? If so that's correct because
  its telling you the issuer and serial number of the CA that issued it.
 
 If the new cert is for a user then the authorityKeyIdentifier issuer
 must be the DN from Sub-Level 1 CA but the DN is from the Root-CA.
 
 The issuer of the CA-certificate of Sub-Level 2 CA is the Sub-Level 1
 CA. The issuer and serial number of the CA that issued the Sublevel 1 CA
 must be from Sublevel 2 CA but OpenSSL use the DN of the Root-CA for the
 issuer.
 

I can't see how that can happen. The ca command only passes the issuing
CA certificate to the extension routines. It does not have access to any
other CA certificate. It fills in the authority key identifier by
extracting the issuer name of that issuing authority and its serial
number.

Is the issuer name of the CA correct?

If there's nothing obviously wrong can you send me an example of a user
certificate exhibiting this behaviour and all the CA certificates too?

Steve.
-- 
Dr Stephen N. Henson.   http://www.drh-consultancy.demon.co.uk/
Personal Email: [EMAIL PROTECTED] 
Senior crypto engineer, Gemplus: http://www.gemplus.com/
Core developer of the   OpenSSL project: http://www.openssl.org/
Business Email: [EMAIL PROTECTED] PGP key: via homepage.
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: How to add a new X.509 v3 extension id?

[Dr S N Henson]

Kiyoshi Watanabe wrote:
 
 Dear All,
 
 I am writing a code to add my private extension. For the extesion id,
 where I should look at and add it? Each standard extension has the id
 like NID_basic_constraints.
 
 If I want to write this,
 ex = X509V3_EXT_conf_nid(NULL, NULL,NID_my_private_extensin,
 My Test Extension);
 
 Which file I need to add my id? Or any temporaril function to add it ?
 
 Sorry if this question is asked many times.
 

It has been asked a few times. The apparent simplicity of the high level
API hides a lot of things going on under the hood. The actual string you
pass to X509V3_EXT_conf_nid is translated to a C structure by one
function then the DER encoded extension by another.

If you just want a simple string extension then you can create an
alias which is effetively saying an extension is identical to another
except it has a different object ID.

The nid you create corresponds to an ASN1 OBJECT IDENTIFIER which can be
dynamically created with OBJ_create().

There's some info in doc/openssl.txt but some of it has been changed
with the new ASN1 code. The d2i/i2d/free/new functions have been
superseded by an ASN1_ITEM structure.

In outline for a simple string you'd create a NID with OBJ_create() and
and alias using X509V3_EXT_add_alias(). A suitable string extension to
use as an alias is NID_netscape_comment.

Steve.
-- 
Dr Stephen N. Henson.   http://www.drh-consultancy.demon.co.uk/
Personal Email: [EMAIL PROTECTED] 
Senior crypto engineer, Gemplus: http://www.gemplus.com/
Core developer of the   OpenSSL project: http://www.openssl.org/
Business Email: [EMAIL PROTECTED] PGP key: via homepage.
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: openssl ca sets wrong authorityKeyIdentifier

[Dr S N Henson]

Robert Joop wrote:
 
 
 the user cert has the user CA's DN in the issuer DN (CN=User CA) and
 the root CA's DN in the authority key identifier DirName (CN=Test-CA
 (G4)), see the attached example.
 but the user cert's authority key identifier keyid is the user CA
 cert's subject key identifier and the user cert's authority key identifier
 serial is the user CA cert's serial.
 ((i ask myself) what's that X509v3 Authority Key Identifier exactly
 anyway...?)
 

The extension is meant as a way of uniquely identifying the issuing
authority of a certificate. The subject and issuer names don't have to
be unique and this extension is to resolve ambiguity.

Two ways to identify a certificate are by its subject key identifier
extension or its issuer name and serial number. The relevant standards
say that issuer name and serial number *must* be unique.

What you've got in those certificates is exactly as it should be.

For the end user certicate there is:

X509v3 Authority Key Identifier:
keyid:6B:2B:4B:20:1D:72:8F:1E:B7:9E:98:BC:6B:9F:D4:09:D7:EB:72:AD
DirName:/C=DE/L=Berlin/O=Fraunhofer-Gesellschaft/OU=FOKUS/OU=PLATIN/CN=Test-CA
(G4)[EMAIL PROTECTED]
serial:02

If you then look at the CA that signed this certificate using:

openssl x509 -in userCA\cacert.pem -noout -issuer -serial 

issuer=
/C=DE/L=Berlin/O=Fraunhofer-Gesellschaft/OU=FOKUS/OU=PLATIN/CN=Test-CA
(G4)[EMAIL PROTECTED]
serial=02

it matches what you get above. Because this CA is signed by the root CA
what you get in here is also the subject and issuer DNs of the root CA.

Steve.
-- 
Dr Stephen N. Henson.   http://www.drh-consultancy.demon.co.uk/
Personal Email: [EMAIL PROTECTED] 
Senior crypto engineer, Gemplus: http://www.gemplus.com/
Core developer of the   OpenSSL project: http://www.openssl.org/
Business Email: [EMAIL PROTECTED] PGP key: via homepage.

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: cvs commit: openssl/ssl kssl.c

[Dr S N Henson]

Jeffrey Altman wrote:
 
  Update on this. I've now got hold of MIT 1.2.4 sources from:
 
  http://non-us.debian.org/debian-non-US/pool/non-US/main/k/krb5
 
  I tested compiling OpenSSL with KRB options under Linux (RHL 6.2) and it
  showed no warnings at all (my options are to use the -Wall -pedantic
  -Werrors which will halt on error).
 
  Kerberos 1.2.4 sources using the traditional method (use a Unix box to
  generat kerbsrc.zip) wont compile due to various dependencies being
  missing. For example early on it exits with:
 
   .\\obj\i386\dbg\wconfig  config  Makefile.in  Makefile
   NMAKE : fatal error U1073: don't know how to make 'appl\gss-sample\Makefile.in'
   Stop.
 
  when I deleted these references (and one other which produced a similar
  error) it compiled OK. Maybe the Unix part that builds kerbsrc.zip
  doesn't include all the files it needs to?
 
 You need to use the Kerberos for Windows distribution to build the
 Kerberos 5 sources on the Windows platform.  KfW 2.1.2 includes Krb5
 1.2.4.
 

Is there anywhere I can get hold of that outside the US?

Steve.
-- 
Dr Stephen N. Henson.   http://www.drh-consultancy.demon.co.uk/
Personal Email: [EMAIL PROTECTED] 
Senior crypto engineer, Gemplus: http://www.gemplus.com/
Core developer of the   OpenSSL project: http://www.openssl.org/
Business Email: [EMAIL PROTECTED] PGP key: via homepage.
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: cvs commit: openssl/ssl kssl.c

[Dr S N Henson]

Jeffrey Altman wrote:
 
 Steve:
 
 Which flavor of Kerberos 5 are you using?
 Which release?
 
 I have a feeling the reasons that you are I are seeing different
 warnings is because the types of the fields in different flavors or
 versions are different.
 
 I'm compiling against MIT 1.2.4 which is the current release.
 
 Some of your changes are producing warnings which are of course
 treated as fatal when compiling OpenSSL.
 

I'm using 1.2.3 which compiles cleanly under Linux but wont compile
under Windows. The source as it was before these changes produced lots
of warnings under Linux and several additional ones under Windows. 

I've so far had to rely on external reports one of which said that after
these changes 1.2.4 did compile cleanly under Windows. It would be much
better if I could confirm this myself.

I can't find a way to download 1.2.4 that isn't covered by US export
restrictions. Do you have a URL I can get it from?

Steve.
-- 
Dr Stephen N. Henson.   http://www.drh-consultancy.demon.co.uk/
Personal Email: [EMAIL PROTECTED] 
Senior crypto engineer, Gemplus: http://www.gemplus.com/
Core developer of the   OpenSSL project: http://www.openssl.org/
Business Email: [EMAIL PROTECTED] PGP key: via homepage.
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: Memory Leak

[Dr S N Henson]

James Yonan wrote:
 
 I have an application which creates and destroys many SSL objects using
 SSL_new and SSL_free.  The SSL objects are bound to memory BIOs rather
 than sockets.  Here is a brief annotation of the relevent sections of code
 (with error checks removed):
 
   ks-ssl = SSL_new (ssl_ctx);
 
   ks-ssl_bio = BIO_new (BIO_f_ssl());
   ks-ciphertext_in = BIO_new (BIO_s_mem ());
   ks-ciphertext_out = BIO_new (BIO_s_mem ());
 
   if (server)
 SSL_set_accept_state (ks-ssl);
   else
 SSL_set_connect_state (ks-ssl);
 
   SSL_set_bio (ks-ssl, ks-ciphertext_in, ks-ciphertext_out);
   BIO_set_ssl (ks-ssl_bio, ks-ssl, BIO_NOCLOSE);
 
   /* DO SOMETHING */
 
   SSL_free (ks-ssl);
 
 The problem is that each of these iterations causes OpenSSL to leak 10K or
 more.  At first I thought that maybe the BIOs returned by BIO_new need to
 be explicitly freed, but then I saw that OpenSSL is freeing them on the
 SSL_free call.
 
 98212 file=buffer.c, line=67, number=12, address=0815D738
 71750 file=bio_ssl.c, line=108, number=24, address=081B3AB8
 32120 file=buffer.c, line=110, number=1868, address=08199A50
 72332 file=bio_lib.c, line=73, number=64, address=08170740
 701884 bytes leaked in 1960 chunks
 
 After many iterations, the amount of memory leaked is substantial.  All of
 the leaks are occurring at one of these 4 locations (above) in the code
 (openssl-0.9.6c) which I obtained by building OpenSSL with CRYPTO_MDEBUG
 defined.
 

If you are just iterating that code then you aren't freeing those BIOs
you created.

Steve.
-- 
Dr Stephen N. Henson.   http://www.drh-consultancy.demon.co.uk/
Personal Email: [EMAIL PROTECTED] 
Senior crypto engineer, Gemplus: http://www.gemplus.com/
Core developer of the   OpenSSL project: http://www.openssl.org/
Business Email: [EMAIL PROTECTED] PGP key: via homepage.
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: cvs commit: openssl/ssl kssl.c s3_srvr.c

[Dr S N Henson]

Jeffrey Altman wrote:
 
 Just wondering.  What are you compiling with that you are seeing
 warnings?
 

VC++ 6.0 SP1, Kerberos 1.2.3 headers. I couldn't get the Kerberos 1.2.3
distribution to compile under Windows though. Can 1.2.4 sources/binaries
be downloaded from anywhere outside the US?

The first patches fixes avoided some warnings under Linux (which 1.2.3
compiled under with no problems) and fixed the Kerberos ASN1 session
code which was rather broken.

 I compile this code without any warnings without these modifications.
 

Do you get any warnings after those changes?

Steve.
-- 
Dr Stephen N. Henson.   http://www.drh-consultancy.demon.co.uk/
Personal Email: [EMAIL PROTECTED] 
Senior crypto engineer, Gemplus: http://www.gemplus.com/
Core developer of the   OpenSSL project: http://www.openssl.org/
Business Email: [EMAIL PROTECTED] PGP key: via homepage.
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: cvs commit: openssl/ssl kssl.c s3_srvr.c

[Dr S N Henson]

Richard Levitte - VMS Whacker wrote:
 
 From: Jeffrey Altman [EMAIL PROTECTED]
 
 jaltman Just wondering.  What are you compiling with that you are seeing
 jaltman warnings?
 jaltman
 jaltman I compile this code without any warnings without these modifications.
 
 On Linux, with the target debug-levitte-linux-elf, I got some of those
 warnings (-wall -pedantic -ansi...  I think those are the big
 generators).  I just didn't dare hack too much into it, since my KRB
 knowledge is pretty minimal.
 

I don't know too much either but the changes I made were fairly obvious
casts and the occasional change of a variable type which should be
harmless. There were a couple areas which caused compiler errors with
-DDEBUG_SAFESTACK which were caused by some attempts to access the STACK
structure directly rather than through the sk_*() function. There were a
few other things that could be fixed as well like casting away const in
ciphers.

The ASN1 Kerberos SESSION stuff (which added an extra field) didn't work
the way it was and was crashing the sess_id command. I've changed it now
so that the new field seems to work as intended: its optional, is
presented properly when its there and it prints out OK.

Steve.
-- 
Dr Stephen N. Henson.   http://www.drh-consultancy.demon.co.uk/
Personal Email: [EMAIL PROTECTED] 
Senior crypto engineer, Gemplus: http://www.gemplus.com/
Core developer of the   OpenSSL project: http://www.openssl.org/
Business Email: [EMAIL PROTECTED] PGP key: via homepage.
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: CSR Question

[Dr S N Henson]

[EMAIL PROTECTED] wrote:
 
 Hello,
 After generating CSR with openssl 0.9.8-dev, 0.9.7-dev or 0.9.6
 'asn1dump' says that:
 
  261 023: INTEGER 65537
 : }
 :   }
 :   }
  266 A00: [0]
 :   Error: Object has zero length.
 : }
  268 30   13:   SEQUENCE {
  270 069: OBJECT IDENTIFIER md5withRSAEncryption (1 2 840 113549 1 1 4)
  281 050: NULL
 : }
 
 What's going on with this error?
 

I presume you mean Peter Gutmann's dumpasn1? 

This is the attributes field which is a SET OF Attribute. If there
aren't any attributes it has to be encoded as an empty SET OF structure.

This isn't an error, though it is arguably an oddity in the
specification: such things are normally OPTIONAL.

You'll get a similar error message with some OCSP responses which can
include an implicitly tagged NULL type.

Steve.
-- 
Dr Stephen N. Henson.   http://www.drh-consultancy.demon.co.uk/
Personal Email: [EMAIL PROTECTED] 
Senior crypto engineer, Gemplus: http://www.gemplus.com/
Core developer of the   OpenSSL project: http://www.openssl.org/
Business Email: [EMAIL PROTECTED] PGP key: via homepage.
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: libeay.num

[Dr S N Henson]

Jeffrey Altman wrote:
 
  When compiling an application with OPENSSL_LOAD_CONF defined, the
  macro maps to OPENSSL_add_all_algorithms_conf(), which additionally
  calls OPENSSL_config(NULL).  This will automatically load the
  openssl.cnf file for engine configuration.  The idea behind all this
  is that it is not necessary to change the source code for enabling
  engine configuration via openssl.cnf; it suffices to recompile with
  the application with OPENSSL_LOAD_CONF.
 
 Where is the openssl.cnf file expected to be found on Windows?
 

The actual location is now determined by the function
CONF_get1_default_config_file() and the openssl utility will be modified
so everything goes through it.

Currently this follows the same logic for finding openssl.cnf as the
utilities. This results in the rather silly default of
/usr/local/ssl/openssl.cnf but it can be overridden with the
OPENSSL_CONF environment variable. 

CONF_get1_default_config_file() could be modified to do something more
sensible under Windows: querying the registry perhaps?

Steve.
-- 
Dr Stephen N. Henson.   http://www.drh-consultancy.demon.co.uk/
Personal Email: [EMAIL PROTECTED] 
Senior crypto engineer, Gemplus: http://www.gemplus.com/
Core developer of the   OpenSSL project: http://www.openssl.org/
Business Email: [EMAIL PROTECTED] PGP key: via homepage.
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: libeay.num

[Dr S N Henson]

Jeffrey Altman wrote:
 
   Where is the openssl.cnf file expected to be found on Windows?
  
 
  The actual location is now determined by the function
  CONF_get1_default_config_file() and the openssl utility will be modified
  so everything goes through it.
 
  Currently this follows the same logic for finding openssl.cnf as the
  utilities. This results in the rather silly default of
  /usr/local/ssl/openssl.cnf but it can be overridden with the
  OPENSSL_CONF environment variable.
 
  CONF_get1_default_config_file() could be modified to do something more
  sensible under Windows: querying the registry perhaps?
 
 There should certainly be a
 
   CONF_set_default_config_file(..)
 
 function to allow applications to set this value.  Unlike on Unix, I
 expect that most Windows applications provide their own copy of
 OpenSSL and do not share a single copy.  So having a specific location
 would be inappropriate.
 

But most applications will share the same config file settings, at least
as far as ENGINEs are concerned. 

It isn't really appropriate to provide a function to set the config file
location. OPENSSL_config() is meant as a simple solution for existing
applications and it does rather horrible things (like writing error
messages to standard output and calling exit(1) for fatal errors). An 
application could provide more appropriate behaviour using the
CONF_modules_load_file() (which OPENSSL_config() calls).

Steve.
-- 
Dr Stephen N. Henson.   http://www.drh-consultancy.demon.co.uk/
Personal Email: [EMAIL PROTECTED] 
Senior crypto engineer, Gemplus: http://www.gemplus.com/
Core developer of the   OpenSSL project: http://www.openssl.org/
Business Email: [EMAIL PROTECTED] PGP key: via homepage.

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: aes_init_key() broken for enc==-1

[Dr S N Henson]

Markus Friedl wrote:
 
 This patch is needed for EVP+AES
 
 --- crypto/evp/e_aes.c  Sat Feb 16 13:39:53 2002
 +++ crypto/evp/e_aes.c  Sun Feb 24 16:54:59 2002
 @@ -88,6 +88,8 @@
  static int aes_init_key(EVP_CIPHER_CTX *ctx, const unsigned char *key,
const unsigned char *iv, int enc) {
 
 +   if (enc == -1)
 +   enc = ctx-encrypt;
 if (enc)
 AES_set_encrypt_key(key, ctx-key_len * 8, ctx-cipher_data);
 else
 
 otherwise code similar to this will break:
 
 EVP_CIPHER_CTX c;
 
 EVP_CIPHER_CTX_init(c);
 EVP_CipherInit(c, cipher, NULL, iv, enc);
 /* adjust keylength */
 EVP_CIPHER_CTX_set_key_length(c, keylen)
 EVP_CipherInit(c, NULL, key, NULL, -1);
 
 There could be problems in other ciphers, too.

You can't do that with AES anyway because its treated as a fixed key
length cipher with the key length determined by the EVP_CIPHER
structure. It has to be handled that way because unlike other cases
(e.g. RC2) the ASN1 OIDs are different for each key length.

I don't think any other ciphers are currently affected but it would be
an idea to have equivalent functionality in the EVP_CipherInit_ex()
function.

Steve.
-- 
Dr Stephen N. Henson.   http://www.drh-consultancy.demon.co.uk/
Personal Email: [EMAIL PROTECTED] 
Senior crypto engineer, Gemplus: http://www.gemplus.com/
Core developer of the   OpenSSL project: http://www.openssl.org/
Business Email: [EMAIL PROTECTED] PGP key: via homepage.

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: smime segfault on redhat 7.2

[Dr S N Henson]

alexandru matei wrote:
 
 Hello,
 I complied latest snaps (all snaps from 2002) on a Redhat 7.2 system.
 Make test finished succesfully. But on trying openssl smime -sign
 -encrypt  command, it segfaults. The rest of commands (as far as I
 tested) are OK.
 Can you give me some advice?
 

I'll look into it. Do you mean separate openssl smime -sign and
openssl smime -encrypt commands or openssl smime -sign -encrypt
which isn't a valid command?

Steve.
-- 
Dr Stephen N. Henson.   http://www.drh-consultancy.demon.co.uk/
Personal Email: [EMAIL PROTECTED] 
Senior crypto engineer, Gemplus: http://www.gemplus.com/
Core developer of the   OpenSSL project: http://www.openssl.org/
Business Email: [EMAIL PROTECTED] PGP key: via homepage.


__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: key file

[Dr S N Henson]

Imran Badr wrote:
 
 Hi,
 
 The keyfile, representing an ecrypted private key, generated by openssl is
 ASN.1 type RSAPrivateKey (PKCS#1), ecrypted using DES-EDE3-CBC and then PEM
 encoded. Is that right ?
 

It doesn't have to be triple DES encrypted.

The traditional format involves adding some information in the PEM
headers and deriving a key and IV from the password using a algorithm
unique to OpenSSL. This is documented in detail in the 0.9.7 docs. This
format should really be avoided for new applications because it is non
standard.

The preferred format is PKCS#8 and any of a variety of password based
encryption algorithms including those of PKCS#5 (v1.5 and v2.0) and
PKCS#12.

Steve.
-- 
Dr Stephen N. Henson.   http://www.drh-consultancy.demon.co.uk/
Personal Email: [EMAIL PROTECTED] 
Senior crypto engineer, Gemplus: http://www.gemplus.com/
Core developer of the   OpenSSL project: http://www.openssl.org/
Business Email: [EMAIL PROTECTED] PGP key: via homepage.


__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: [PATCH] argument passing to app_verify_callback

[Dr S N Henson]

Bodo Moeller wrote:
 
 On Sat, Feb 16, 2002 at 11:16:23AM +0100, Richard Levitte - VMS Whacker wrote:
 
  I see no problem adding this patch.  Queued.
 
 The problem is that the application callback prototype is incompatibly
 changed.  Otherwise I would have added the argument instead of simply
 adding comments pointing out the inconsistency.  To maintain backwards
 compatibilty, it looks like we need a new function for registering
 callback functions expecting this additional argument.
 

If its likely to be a problem then I suggest we don't bother with this
patch at all. Its not needed because its possible to access application
specific data in the verify callback via the relevant SSL structure as I
indicated in another message.

Steve.
-- 
Dr Stephen N. Henson.   http://www.drh-consultancy.demon.co.uk/
Personal Email: [EMAIL PROTECTED] 
Senior crypto engineer, Gemplus: http://www.gemplus.com/
Core developer of the   OpenSSL project: http://www.openssl.org/
Business Email: [EMAIL PROTECTED] PGP key: via homepage.

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: EVP macros for AES

[Dr S N Henson]

Stephen Sprunk wrote:
 
 Thus spake Dr S N Henson:
 
  Maybe. It would be good to the the CFB and OFB modes working properly in
  general for other numbers of bits.
 
 The code for this is trivial; define me an API and I'll write the code
 underneath.
 

Well I was thinking of something almost identical to the variable key
length code. Have a call EVP_CIPHER_CTX_set_feedback_bits() or whatever
to allow it to be set to a non default value.

  I thought about moving the whole cipher mode handling to the EVP layer
  and trimming down the individual block ciphers to just encrypt/decrypt a
  single block at one point. However tests suggested that this would have
  a considerably impact on performance so we're probably stuck with the
  duplicate mode code for now.
 
 I'd like to see exactly where the performace problem was; I can't
 imagien it'd be statistically significant.
 

Well you can get some idea of the overhead using 'openssl speed' and
comparing the times for the low level routines and the EVP wrappers.
You'd expect some kind of slowdown with fast ciphers like RC4 but the
slowdown for things like DES is also significant.

 
  I wonder if we could do better by moving some of the mode handling to
  the assembly language routines and take advantage of some special cases
  to avoid function call overhead.
 
 I tried this for AES and got ~10% speed increase for CBC in about 5
 minutes using some generic assembly.  Another 17% by throwing some MMX
 stuff in over my lunch hour.  And I haven't even touched the C
 algorithm itself :)
 
 Again, it's not worth doing this for each algorithm/mode, but if we
 had either a mode API or at least macro sets, it would be.
 

Maybe could be done by adding some perl functions in the perl assembly
language generator?

Steve.
-- 
Dr Stephen N. Henson.   http://www.drh-consultancy.demon.co.uk/
Personal Email: [EMAIL PROTECTED] 
Senior crypto engineer, Gemplus: http://www.gemplus.com/
Core developer of the   OpenSSL project: http://www.openssl.org/
Business Email: [EMAIL PROTECTED] PGP key: via homepage.
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: [PATCH] argument passing to app_verify_callback

[Dr S N Henson]

D. K. Smetters wrote:
 
 
 This is a patch to actually hand the user-supplied argument
 into calls to app_verify_callback. It affects the following 5
 files:
 

I've no objections to this patch. As long as there's an argument there
we might as well use it.

There is a way to pass application specific data to the verify callback
without this patch. The X509_STORE_CTX makes use of the ex_data code to
pass a reference to the parents SSL context. Therefore by adding user
supplied data to the parent SSL structure the verify callback can make
use of it by first finding the SSL structure and then the ex_data
attached to it.

Steve.
-- 
Dr Stephen N. Henson.   http://www.drh-consultancy.demon.co.uk/
Personal Email: [EMAIL PROTECTED] 
Senior crypto engineer, Gemplus: http://www.gemplus.com/
Core developer of the   OpenSSL project: http://www.openssl.org/
Business Email: [EMAIL PROTECTED] PGP key: via homepage.

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: cvs commit: openssl/crypto/objects obj_dat.h obj_mac.h obj_mac.num objects.txt

[Dr S N Henson]

[EMAIL PROTECTED] wrote:
 
 levitte 16-Feb-2002 13:17:14
 
   Modified:crypto/objects Tag: OpenSSL_0_9_7-stable obj_dat.h obj_mac.h
 obj_mac.num objects.txt
   Log:
   Adjust the NID names for the AES modes OFB and CFB to contain the number
   of feedback bits
 

While this is what is done with other ciphers I'd argue that it isn't
strictly speaking correct. The NID is tied to an ASN1 OBJECT
IDENTIFIER (OID). The OID (at least for CFB mode) doesn't represent the
number of feedback bits just the cipher+mode combination.

IMHO what we should really be doing is to provide get/set ctrls for the
number of feedback bits in the same way this is done for some variable
key length ciphers where the NID doesn't specify the key size. The set
would give an error if an unsupported number of bits was requested:
which would be anything other than the default number with the current
code.

Steve.
-- 
Dr Stephen N. Henson.   http://www.drh-consultancy.demon.co.uk/
Personal Email: [EMAIL PROTECTED] 
Senior crypto engineer, Gemplus: http://www.gemplus.com/
Core developer of the   OpenSSL project: http://www.openssl.org/
Business Email: [EMAIL PROTECTED] PGP key: via homepage.

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: 0.9.7 approaching

[Dr S N Henson]

Harald Koch wrote:
 
  Are you in the US BTW if so can you resend you patch with a CC: to
  [EMAIL PROTECTED]
 
 I'm in Canada...
 

OK, I've checked in a fix which should do what you want. Let me know of
any problems.

Steve.
-- 
Dr Stephen N. Henson.   http://www.drh-consultancy.demon.co.uk/
Personal Email: [EMAIL PROTECTED] 
Senior crypto engineer, Gemplus: http://www.gemplus.com/
Core developer of the   OpenSSL project: http://www.openssl.org/
Business Email: [EMAIL PROTECTED] PGP key: via homepage.
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: cvs commit: openssl/crypto/err err.c

[Dr S N Henson]

Bodo Moeller wrote:
 
 On Fri, Feb 15, 2002 at 10:55:13AM +, Ben Laurie wrote:
 
  This fix for err.c is correct.
 
  But evp_test.c should never have called OPENSSL_config() because
  OPENSSL_config() uses the configuration file found in an OpenSSL
  *installation*.  If we want to use a configuration file during
  'make test', we should use one located in the source tree.
 
  It may be a good idea to test that configuration works, somehow. And
  yeah, I shouldn't have put config in evp_test, it was a mistake.
 
 Now with Steve's change (add a file name parameter to OPENSSL_config())
 the OPENSSL_config() call can be put back into evp_test -- it just
 should use a file in the source code tree.
 

Its not a file name parameter it is the config section to use in order
to use something other than openssl_conf. I thought that was one of
the requested features. If I've misinterpreted it I can change it to
specify an alternative config file. I'm not sure either is really needed
if I move some more of the handling over to CONF_modules_load_file().

It isn't too hard to specify an alternative filename at present anyway
just doing:

if (CONF_modules_load_file(filename, section, flags) = 0)
/* Some error occurred */

instead of calling OPENSSL_config() should do the trick. Doing things
that way allows it to exit and tidy up gracefully rather than the abrupt
exit(1) of OPENSSL_config().

Steve.
-- 
Dr Stephen N. Henson.   http://www.drh-consultancy.demon.co.uk/
Personal Email: [EMAIL PROTECTED] 
Senior crypto engineer, Gemplus: http://www.gemplus.com/
Core developer of the   OpenSSL project: http://www.openssl.org/
Business Email: [EMAIL PROTECTED] PGP key: via homepage.

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: cvs commit: openssl/crypto/engine hw_sureware.c

[Dr S N Henson]

Ben Laurie wrote:
 
 Hmm. You did this with a different name from me (idx instead of index_)
 - isn't that going to be irritating?
 

I hadn't realised someone else had come across this. It should be
consistent I suppose. Personally I always find variable names with
appended underscores a little odd looking.

Steve.
-- 
Dr Stephen N. Henson.   http://www.drh-consultancy.demon.co.uk/
Personal Email: [EMAIL PROTECTED] 
Senior crypto engineer, Gemplus: http://www.gemplus.com/
Core developer of the   OpenSSL project: http://www.openssl.org/
Business Email: [EMAIL PROTECTED] PGP key: via homepage.
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: EVP macros for AES

[Dr S N Henson]

Stephen Sprunk wrote:
 
 Thus spake Richard Levitte - VMS Whacker:
 
  The current state is EAY legacy.  His idea was that one should be able
  to pick out any of the algorithm directories and create a separate
  library for them (the old libdes is actually exactly the same as
  crypto/des/).
 
 First of all, do we still think that's necessary, given the wide
 acceptance of OpenSSL and libcrypto?
 

I'm not too bothered by that. We've been advising people to avoid the
low level API where possible for a while now.

 In either case, it shouldn't be that difficult to develop a macro set
 that implements various modes.  Pass in some function names, block
 size, types for casts, and let it generate the boilerplate.  Worth
 doing?
 

Maybe. It would be good to the the CFB and OFB modes working properly in
general for other numbers of bits.

I thought about moving the whole cipher mode handling to the EVP layer
and trimming down the individual block ciphers to just encrypt/decrypt a
single block at one point. However tests suggested that this would have
a considerably impact on performance so we're probably stuck with the
duplicate mode code for now.

There is some duplication in individual cipher modes and some macros
might help though there is some variation where some cipher optimize the
storing of things like the IV in the most effective internal format.

I wonder if we could do better by moving some of the mode handling to
the assembly language routines and take advantage of some special cases
to avoid function call overhead.

Steve.
-- 
Dr Stephen N. Henson.   http://www.drh-consultancy.demon.co.uk/
Personal Email: [EMAIL PROTECTED] 
Senior crypto engineer, Gemplus: http://www.gemplus.com/
Core developer of the   OpenSSL project: http://www.openssl.org/
Business Email: [EMAIL PROTECTED] PGP key: via homepage.
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: AES, counter mode, etc.

[Dr S N Henson]

John Viega wrote:
 
 
 Additionally, with respect to counter mode, it might be best to
 implement external to the EVP proper interface, just like HMAC.  There
 are a few issues I see that make counter mode a bit different from
 other modes:
 
 1) You should be able to insert your own function for choosing a
 stream of counters.  They don't have to be simple incrementing
 counters.
 
 2) Counter mode can be used in a random-access manner.  For example,
 if you encrypt a file with counter mode, you can then access the
 blocks of that file independently, as long as you know the counter
 value.
 

That could be handled by passing the relevant info in a cipher ctrl call
in the same way that other cipher parameters can be changed.

The HMAC stuff could conceivable also be handled with ctrls at the
digest level. However the ctrl functionality doesn't exist at the digest
level at present and the HMAC stuff has been around since the SSLeay
days.

Steve.
-- 
Dr Stephen N. Henson.   http://www.drh-consultancy.demon.co.uk/
Personal Email: [EMAIL PROTECTED] 
Senior crypto engineer, Gemplus: http://www.gemplus.com/
Core developer of the   OpenSSL project: http://www.openssl.org/
Business Email: [EMAIL PROTECTED] PGP key: via homepage.
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: cvs commit: openssl/util libeay.num mkdef.pl mkerr.pl

[Dr S N Henson]

Any reason for this:

 /* Override the default new methods */
   static int sig_cb(int operation, ASN1_VALUE **pval, const ASN1_ITEM *it)
   {
 if(operation == ASN1_OP_NEW_PRE) {
 ECDSA_SIG *sig;
 sig = OPENSSL_malloc(sizeof(ECDSA_SIG));
 if (sig == NULL)
 {
 ECDSAerr(ECDSA_F_SIG_CB, ERR_R_MALLOC_FAILURE);
 return 0;
 }
 sig-r = NULL;
 sig-s = NULL;
 *pval = (ASN1_VALUE *)sig;
 return 2;
 }
 return 1;
   }
   
   ASN1_SEQUENCE_cb(ECDSA_SIG, sig_cb) = {
 ASN1_SIMPLE(ECDSA_SIG, r, CBIGNUM),
 ASN1_SIMPLE(ECDSA_SIG, s, CBIGNUM)
   } ASN1_SEQUENCE_END_cb(ECDSA_SIG, ECDSA_SIG)
  

What this actually does is to override the default ASN1 new behaviour:
this should be avoided in new code where possible. If the original new
behaviour is retained it will be identical except it will populate
sig-r, sig-s using BN_new(). Shouldn't be a problem provided the
relevant assignment code takes note of this.

This actually looks identical to the DSA_SIG code. In that case
DSA_new() already existed and didn't allocate BIGNUMs for 'r' and 's' so
it has to override the default behaviour to avoid breaking existing
code.

Steve.
-- 
Dr Stephen N. Henson.   http://www.drh-consultancy.demon.co.uk/
Personal Email: [EMAIL PROTECTED] 
Senior crypto engineer, Gemplus: http://www.gemplus.com/
Core developer of the   OpenSSL project: http://www.openssl.org/
Business Email: [EMAIL PROTECTED] PGP key: via homepage.

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: 0.9.7 approaching

[Dr S N Henson]

Harald Koch wrote:
 
  Please test the 0.9.7-dev snapshots and report any problems that you
  found, even if they have been reported before (it's a good reminder
  for us), or even better, send us patches!
 
 It used to be possible to call X509_STORE_CTX_init() with a NULL
 X509_STORE pointer, in order to use the verifier without using the
 builtin certificate store. (I am using X509_STORE_CTX_trusted_stack()
 instead).
 

OK, I'll look into that.

Are you in the US BTW if so can you resend you patch with a CC: to
[EMAIL PROTECTED]

Steve.
-- 
Dr Stephen N. Henson.   http://www.drh-consultancy.demon.co.uk/
Personal Email: [EMAIL PROTECTED] 
Senior crypto engineer, Gemplus: http://www.gemplus.com/
Core developer of the   OpenSSL project: http://www.openssl.org/
Business Email: [EMAIL PROTECTED] PGP key: via homepage.

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: EVP_CipherInit() and similar API changes

[Dr S N Henson]

Markus Friedl wrote:
 
 
 There could be more problems with other XXX_Init() or similar
 functions, so all semantic changes to functions from the 0.9.6 API
 should be reconsidered.  All such changes could be a threat to existing
 applications and break them in subtle ways -- and this must be
 avoided.
 

The aim of the API changes was to retain compatibility with existing
code, there may be some places where it doesn't which need to be
addressed.

 
 As to EVP_CipherInit(): I think EVP_CipherInit should not cause
 EVP_CipherInit_ex() to look for an engine, as this deviates from the
 0.9.6 behaviour.  Perhaps is better to pass 'engine==NO_ENGINE',
 instead of 'engine==NULL' to EVP_CipherInit_ex().
 

The aim of this was to allow the EVP_XXX functions to be able to use a
replacement default implementation without needing to rewrite existing
code. If no default implementation is loaded it should retain the 0.9.6
behaviour.

Steve.
-- 
Dr Stephen N. Henson.   http://www.drh-consultancy.demon.co.uk/
Personal Email: [EMAIL PROTECTED] 
Senior crypto engineer, Gemplus: http://www.gemplus.com/
Core developer of the   OpenSSL project: http://www.openssl.org/
Business Email: [EMAIL PROTECTED] PGP key: via homepage.
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: EVP macros for AES

[Dr S N Henson]

Stephen Sprunk wrote:
 
 Can someone help me implement the EVP macros for AES 128-bit CFB and
 OFB modes?  It's too messy for me to figure out.
 
 I've got non-EVP versions written, but it appears the EVP macros do
 their own implementation of the various modes and only call the base
 ECB function.
 
 I've also got a trial implementation of CTR mode, but I don't see
 where that would fit into EVP or the ASN.1 stuff.
 

The ASN.1 stuff you can largely ignore. Most of the existing CFB and OFB
modes do and nothing really uses the ASN.1 stuff with those modes.

The macros can also be ignored and you can populate the EVP_CIPHER
structure manually if you wish.

The reason for the macros was that when the EVP layer was being revised
it was an absolute nightmare to change anything. IIRC at one point I had
to add an additional field to the EVP_CIPHER structure. I then spent the
next couple of hours modifying lots of almost identical EVP_CIPHER
definitions spread over zillions of little files. So I rewrote the files
to use macros so that any future changes could largely be handled by
just changing the macros and the odd exception manually.

Steve.
-- 
Dr Stephen N. Henson.   http://www.drh-consultancy.demon.co.uk/
Personal Email: [EMAIL PROTECTED] 
Senior crypto engineer, Gemplus: http://www.gemplus.com/
Core developer of the   OpenSSL project: http://www.openssl.org/
Business Email: [EMAIL PROTECTED] PGP key: via homepage.
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: EVP_CipherInit() and similar API changes

[Dr S N Henson]

Markus Friedl wrote:
 
 I think this change is needed if you want EVP_CipherInit() to have a
 similar semantic as in OpenSSL 0.9.6.
 
 Index: evp/evp_enc.c
 ===
 RCS file: /cvs/openssl/crypto/evp/evp_enc.c,v
 retrieving revision 1.28
 diff -u -r1.28 evp_enc.c
 --- evp/evp_enc.c   17 Oct 2001 00:36:34 -  1.28
 +++ evp/evp_enc.c   13 Feb 2002 10:28:05 -
 @@ -77,7 +77,8 @@
  int EVP_CipherInit(EVP_CIPHER_CTX *ctx, const EVP_CIPHER *cipher,
  const unsigned char *key, const unsigned char *iv, int enc)
 {
 -   EVP_CIPHER_CTX_init(ctx);
 +   if (cipher)
 +   EVP_CIPHER_CTX_init(ctx);
 return EVP_CipherInit_ex(ctx,cipher,NULL,key,iv,enc);
 }
 
 
 Otherwise you will break code like:
 
 EVP_CIPHER_CTX c;
 
 EVP_CIPHER_CTX_init(c);
 EVP_CipherInit(c, cipher, NULL, iv, enc);
 /* adjust keylength */
 EVP_CIPHER_CTX_set_key_length(c, keylen)
 EVP_CipherInit(c, NULL, key, NULL, -1);
 

Oops, forgot to comment on that. Yes its definitely a bug, good catch!

Steve.
-- 
Dr Stephen N. Henson.   http://www.drh-consultancy.demon.co.uk/
Personal Email: [EMAIL PROTECTED] 
Senior crypto engineer, Gemplus: http://www.gemplus.com/
Core developer of the   OpenSSL project: http://www.openssl.org/
Business Email: [EMAIL PROTECTED] PGP key: via homepage.
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: make report

[Dr S N Henson]

Charles McCabe wrote:
 
 I'm a complete Linux newbie here, submitting this report for the common
 good.  I'm trying to get sshd working on my RedHat 7.2 box and this
 openssl install was the last in a series of frustrations.  Hope it helps
 someone somewhere.
 
[snip]
 gcc -I.. -I../../include -fPIC -DTHREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H 
-DL_ENDIAN -DTERMIO -O3 -fomit-frame-pointer -m486 -Wall -DSHA1_ASM -DMD5_ASM 
-DRMD160_ASM   -c -o p12_init.o p12_init.c
 p12_init.c: In function `PKCS12_init':
 p12_init.c:98: Internal error: Segmentation fault.
 Please submit a full bug report.
 See URL:http://bugzilla.redhat.com/bugzilla/ for instructions.
 make[3]: *** [p12_init.o] Error 1
 make[3]: Leaving directory `/root/openssl-0.9.6c/crypto/pkcs12'
 make[2]: *** [subdirs] Error 1
 make[2]: Leaving directory `/root/openssl-0.9.6c/crypto'
 make[1]: *** [sub_all] Error 1
 make[1]: Leaving directory `/root/openssl-0.9.6c'

That looks suspiciously like a C compiler bug. See if you can get an
updated version.

Steve.
-- 
Dr Stephen N. Henson.   http://www.drh-consultancy.demon.co.uk/
Personal Email: [EMAIL PROTECTED] 
Senior crypto engineer, Gemplus: http://www.gemplus.com/
Core developer of the   OpenSSL project: http://www.openssl.org/
Business Email: [EMAIL PROTECTED] PGP key: via homepage.
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: SQL DB instead of index.txt

[Dr S N Henson]

Ben Laurie wrote:
 
 Dr S N Henson wrote:
 
 
  The self signed cert was only an example. There are other cases which
  could apply as well. An example would be explicit trust of an EE
  certificate. That isn't supported in OpenSSL yet but it will be at some
  point. It would however have a similar criteria: only an exact match
  would be acceptable.
 
 I believe this is supported (by writing appropriate callbacks) - I'm
 sure I remember doing it at some point.
 

Well yes you can do most things with callbacks. I was referring to a
method where you could (for example) place an EE certificate in a
trusted store, set a trust this certificate for some purpose setting
on it and a certificate verify would automatically succeed even though
the rest of the chain was absent.

Steve.
-- 
Dr Stephen N. Henson.   http://www.drh-consultancy.demon.co.uk/
Personal Email: [EMAIL PROTECTED] 
Senior crypto engineer, Gemplus: http://www.gemplus.com/
Core developer of the   OpenSSL project: http://www.openssl.org/
Business Email: [EMAIL PROTECTED] PGP key: via homepage.
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: SQL DB instead of index.txt

[Dr S N Henson]

Richard Levitte - VMS Whacker wrote:
 
 
 I assume this must be a bit confusing, because we all seem to have
 different ideas on what the different layers are supposed to do.
 
 My idea is that we have three layers:
 
 0. The application
 1. The DB framework (which may or may not be part of the ENGINE framework)
 2. The DB plugin
 
 The plugin doen't really know what the hell we're storing.  All it has
 is some simple schema that could fulfill most of our needs (and that's
 flexible enough, I think I've outlined some ideas, but I haven't been
 very specific yet).

Ah now that's a point where we differ. The system I'm considering would
include cases where it would have to know what it was storing at the
plugin level. 

An example would be a smart card where when its told to lookup private
key by key id would return an appropriate EVP_PKEY structure to the
layer above using the smart card ENGINE.

A PKCS#11 plugin (or a more elaborate one) would translate the lookup
attributes into their PKCS#11 equivalents and translate the returned
PKCS#11 objects attributes into OpenSSL equivalents.

 
 Are the above ideas along the line of what you've done Stephen (I
 don't dare misspell your last name again :-))?
 

That's not quite how I'd see things. Here's a rough example of how
things might got at the application level, with some error checking
omitted:

OBJDB *db;
STACK_OF(OBJDB_ATTR) *search_attrs = NULL;
OBJDB_SEARCH_CTX *ctx;
STACK_OF(X509_OBJECT) *items = NULL;

db = OBJDB_open(/* various parameters */);
/* we are looking up private keys */
OBJDB_add_search_type(search_attrs, OBJDB_TYPE_PKEY);

/* set lookup alias */
OBJDB_add_search_alias(search_attrs, Steve private key);
/* Initialize search for a given database */
OBJDB_search_init(ctx, db, search_attrs);
/* Just return one match */
if (!OBJDB_search_next(ctx, items, 1))
/* Search failure */
OBJDB_search_final(ctx);

/* Get EVP_PKEY from items and do somthing with it... */

The above code is effectively doing what ENGINE_load_private_key() does
now.

At the plugin level this stuff is translated into some calls to the
plugins search_init, search_update, search_final calls. At this level
the plugin looks up the attributes and returns zero or more (up to the
search_next imposed limit) matching items. How it actually does the
lookup is totally up to the plugin itself.

As it stands this has the problem that every database would have to
implement some complex searching algorithms making plugin development a
difficult task. 

We can solve this in a manner similar to that used by public key
algorithms: where an implementation can just implement modular
exponentiation instead of the full algorithm. This is like having
standard classes of plugins which implement a lot of the necessary
functionality and reduce the development required considerably.

One class could be an in memory database which just stores all the
objects in memory and retrieves whichever ones match the search
criteria.

An example which could make use of the in memory class would be a smart
card. It would not do any smart card lookups on the card and just add
all stored objects when the card is inserted and invalidate them when
its removed. 

A second class could be a hash database class. Here it could store and
retrieve a name+value pair and the database would have no idea what it
was storing. Below this we could have drivers for gdb, Berkeley DB or
some simple file based database (which would work on any platform). This
would be the equivalent of the Netscape database.

Steve.
-- 
Dr Stephen N. Henson.   http://www.drh-consultancy.demon.co.uk/
Personal Email: [EMAIL PROTECTED] 
Senior crypto engineer, Gemplus: http://www.gemplus.com/
Core developer of the   OpenSSL project: http://www.openssl.org/
Business Email: [EMAIL PROTECTED] PGP key: via homepage.

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: SQL DB instead of index.txt

[Dr S N Henson]

Oscar Jacobsson wrote:
 
 Dr S N Henson wrote:
  I'd be reluctant to have multiple APIs handling each case. What we could
  have is flags or profiles saying what a certain kind of database should
  support.
 
 OpenSSL currently has separate APIs, as opposed to flags or profiles,
 for handling EVP_PKEYs, X509s and X509_CRLs because they are
 fundamentally different types supporting fundamentally different
 operations. The stores they reside in will mirror this disparity: a key
 store's (e.g. a smart card's or cryptographic hardware's) very raison
 d'être is to keep its keys hidden, a PKI repository's (e.g. a directory
 server's or RDBMS's) is to make its certificates and CRLs known.
 
 I'm not saying we *could not* consolidate both of these feature sets
 into a single API -- I've stumbled upon private keys in public
 directories more than once. I'm merely trying to point out that it might
 not necessarily be the optimal approach.
 

Yes they all have separate APIs to actually use the things. However they
all have the same API to lookup them up namely X509_LOOKUP or they would
if it worked properly which it doesn't: it handles certificates and CRLs
(badly) and has some partial private key code which doesn't do much at
all.

What I'm saying is this. All three structure wrt storage can be treated
in a similar way. They all have some properties which we would want to
search a database on. This might be finding the certificate with a given
issuer and serial number then finding the corresponding private key
based on its key id.

What I'm saying is that IMHO it would be a mistake to have completely
different APIs for lookup certificate by I+SN and lookup private key
by key id.

What its returning is a structure, how it gets the structure is not
defined at this level: it will be defined by individual databases.

Also the profiles I'm referring to could include things like I don't
handle private keys for a public directory.

 
 I'm not exactly sure how a layered structure would be different from
 having separate APIs. Maybe this is just a case of using different
 terminology for the same things? Please feel free to elaborate. I'm much
 more comfortable discussing class and interface design. :-/
 

I'll expand on that when I reply to one of Richard's messages to avoid
duplication.

Steve.
-- 
Dr Stephen N. Henson.   http://www.drh-consultancy.demon.co.uk/
Personal Email: [EMAIL PROTECTED] 
Senior crypto engineer, Gemplus: http://www.gemplus.com/
Core developer of the   OpenSSL project: http://www.openssl.org/
Business Email: [EMAIL PROTECTED] PGP key: via homepage.


__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: SQL DB instead of index.txt

[Dr S N Henson]

Richard Levitte - VMS Whacker wrote:
 
 
 The only thing that troubles me then is that the plug-in (dynamically
 loadable, right?) would have to share certain structures with OpenSSL,
 which means that we'd better define those structures in a way that
 they won't need change after they are set in stone, or that something
 clever is done so they can extend without breaking compatibility.
 That, or have the plug-ins keep a very sharp eye on the version of the
 loading OpenSSL to avoid version clashes (something we do with engines
 today, sadly).
 

Well they don't have to be dynamically loadable. At least one plug-in or
plug-in class should be built in. The in memory plug-in would be a good
candidate for that or the hash class: whichever one is used to emulate
the current PEM file/directory/index mess.

[Now I come to think of it the in memory plug-in could be an instance of
the hash class which used LHASH for its hash database... however using
that for a typical one or two certificate smart card is a bit of
overkill.]

Usually though they will be dynamically loadable. It appears, at least
on the face of it, that the actual parts of the library they would
use (ASN1 is one case) are hard to set in stone so we may be stuck with
checking versions, at least before OpenSSL 1.0 .

Some of the plug-in classes could themselves load DSOs where the
functionality could be made backwards compatible though. The hash class
could have an API which makes little or no reference to OpenSSL
insternal structures at all.

Steve.
-- 
Dr Stephen N. Henson.   http://www.drh-consultancy.demon.co.uk/
Personal Email: [EMAIL PROTECTED] 
Senior crypto engineer, Gemplus: http://www.gemplus.com/
Core developer of the   OpenSSL project: http://www.openssl.org/
Business Email: [EMAIL PROTECTED] PGP key: via homepage.

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: Another proposed DB API

[Dr S N Henson]

Richard Levitte - VMS Whacker wrote:
 
 From: Bear Giles [EMAIL PROTECTED]
 
 bear The primary key is an opaque string henceforce known as the alias.
 bear The plugin may treat this as a primary key, but must not attempt to
 bear interpret it as a hash, email address, keyid, serial number, etc.
 
 I think I like the idea.  Let's see what Dr Genson has to say.
 

Dr Genson, who he?

Well let me mention a variation on the API of the partial work I'd done
which avoids some of the problems I'd noticed with it. I'll stick to the
search details for now.

The stuff was called an object database OBJDB. An object would be a
certificate, CRL, private key or perhaps opaque data objects too.

Each object is a set of attributes. For certificates this would include
an alias (a human readable version of the object: e.g. Steve's
Certificate) key id (opaque binary data intended to allow the private
key to be looked up) subject name, issuer name, serial number, subject
key ID, email address and several others... Private keys would typically
have less info such as just an alias and key id.

In PKCS#11 the object type is also an attribute. Not sure whether we
need to do that or not. This would allow us for example to do a single
lookup by key id and get back a mixture of types (certificates and keys)
matching this.

Now a few structures. If we allow object types to be included then we
could use the existing X509_OBJECT to represent the matching structures,
it currently looks like this:

typedef struct x509_object_st
{
/* one of the above types */
int type;
union   {
char *ptr;
X509 *x509;
X509_CRL *crl;
EVP_PKEY *pkey;
/* others */
} data;
} X509_OBJECT;

We could also have the attribute use a similar structure:

typedef struct objdb_attr_st
{
/* one of the above types */
int type;
union   {
unsigned char *hash;
ASN1_INTEGER *serialNumber;
X509_NAME *subjectName;
X509_NAME *issuerName;
/* Lots more in here */
} data;
} OBJDB_ATTR;

[note: we could alternatively have a single attribute for issuer and
serial number PKCS7_ISSUER_AND_SERIAL_NUMBER]

Now the lookup mechanism. This is done by exact matches of attribute.
Whether we need to handle matches of multiple attributes is debatable.
PKCS#11 can do that though and it isn't too hard to handle. I'll stick
with the more complex multiple attribute stuff and multiple object types
for now...

Each object database would support a triple of lookup functions which
look like this:

int search_init(OBJDB_SEARCH *ctx, STACK_OF(OBJDB_ATTR) *search_attr);
int search_next(OBJDB_SEARCH *ctx, STACK_OF(X509_OBJECT)
**matching_objects, int *count);
int search_final(OBJDB_SEARCH *ctx);

This is effectively an OpenSSL friendly variant of the PKCS#11 API. In
outline this is how a search looks at the object database level (the
application would use a friendly API on top of this)...

search_init() is called to intialize a search context.

search_next() is called repeatedly to retrieve succesive matching
objects. count is an input/output parameter. The application will set
it to the maximum number of objects to retrieve and the object database
sets it to the number actually retrieved. The object database can return
less matching objects that requested (for example some database specific
imposed limit to avoid having to return a huge number of matching
objects). When count is zero the search is complete.

search_final() is called to terminate the search. This can be done at
any point and need not necessarily be done after retrieving all matching
objects.

This API makes not mention of how the objects are stored, how they are
retrieved and how the search mechanism works. The database can do this
in whatever way it finds convenient whether an in looking in an in
memory database, Berkeley db lookup or hand transribed by Tibetan monks.

Now *internally* the database could do lots of different things. The
OBJDB_SEARCH parameter will have (among other things) database specific
data stored in it.
 
An in memory database might store all the matching STACK_OF(X509_OBJECT)
structures directly in here and just pop them in search_next() until the
stack is empty.

A different database (to use the earlier API example) could store a
stack of matching keys in here and perform a pop+lookup when search_next
is called.

A huge database might store some kind of upto context to avoid having
to satisfy a huge request in one go.

Steve.
-- 
Dr Stephen N. Henson.   http://www.drh-consultancy.demon.co.uk/
Personal Email: [EMAIL PROTECTED] 
Senior crypto engineer, Gemplus: http://www.gemplus.com/
Core developer of the   OpenSSL project: http://www.openssl.org/
Business Email: [EMAIL PROTECTED] PGP key: via homepage.

Re: SQL DB instead of index.txt

[Dr S N Henson]

Oscar Jacobsson wrote:
 
 Bear Giles wrote:
  But a plug-in that transparently updated a smart card would be extremely
  handy. :-)  That's what makes the design so hard - it needs to be able
  to handle everything from 8k smart cards holding a single veiled key and
  cert to RDBMS databases with 50,000+ entries.
 
 I think the design would be made needlessly complex by mandating this
 scalability.
 

I'd be reluctant to have multiple APIs handling each case. What we could
have is flags or profiles saying what a certain kind of database should
support.

 The use cases needed for your smart card API would be, say: encrypt
 this, decrypt this, sign this, verify this. This is what Cryptoki
 (PKCS#11) does, and does quite well, in my experience.
 

There are unfortunately some problems with PKCS#11. Its tantalisingly
close to whats needed but falls down in some areas. 

 The use cases for a full-blown PKI repository, which I honestly thought
 was what we were discussing, should probably include: find me the issuer
 of this, give me the status of this, enumerate all my revoked
 certificates. None of these would make much sense to the humble 8k card.
 

Indeed it wouldn't, but full lookup need not be a complex task. The way
I'm considering this would be a layered structure which could allow some
things like smart cards to have a KISS approach.

A standard database type would be an in memory database with full
lookup. A smartcard could build on this by just stuffing all the card
certificates in memory when its inserted and updating those on card as
needed. That would remove most of the lookup burden.

Steve.
-- 
Dr Stephen N. Henson.   http://www.drh-consultancy.demon.co.uk/
Personal Email: [EMAIL PROTECTED] 
Senior crypto engineer, Gemplus: http://www.gemplus.com/
Core developer of the   OpenSSL project: http://www.openssl.org/
Business Email: [EMAIL PROTECTED] PGP key: via homepage.

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: SQL DB instead of index.txt

[Dr S N Henson]

Bear Giles wrote:
 
 
  If it only did an I+SN match then an attacker could readily generate a
  self-signed certificate using its own key with matching I+SN.
 
 But a self-signed cert is easily identified and could be flagged
 for special handling.  By removing them from the standard population
 we may be able to simplify rules for all other certs.

The self signed cert was only an example. There are other cases which
could apply as well. An example would be explicit trust of an EE
certificate. That isn't supported in OpenSSL yet but it will be at some
point. It would however have a similar criteria: only an exact match
would be acceptable.

Steve.
-- 
Dr Stephen N. Henson.   http://www.drh-consultancy.demon.co.uk/
Personal Email: [EMAIL PROTECTED] 
Senior crypto engineer, Gemplus: http://www.gemplus.com/
Core developer of the   OpenSSL project: http://www.openssl.org/
BusX-Mozilla-Status: [EMAIL PROTECTED] PGP key: via homepage.


__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: SQL DB instead of index.txt

[Dr S N Henson]

Bear Giles wrote:
 
  Nothing. The trust settings aren't part of the certificate encoding. The
  current trust handling stores these after the main encoding only if the
  *TRUST() functions are used.
 
 As an aside my postgresql stuff currently uses the standard X509 routines
 when converting from internal to external format (DER to PEM).  Handling
 TRUSTED certificates is on my TO-DO list, but there were too many unknowns.
 
 I guess the two questions come down to:
 
 1) how do I determine this extra information is present?  Is a non-null
 x-aux value sufficient?
 

That wil normally be sufficient but you don't really need to worry about
whether its present or not.

 2) how do I encoded it - which i2d function?  (Almost all of my I/O uses
 macros calling a handful of generic functions, and I've found it much
 easier to maintain the occasional exception in the same format.)

You can use the d2i_X509_AUX() and i2d_X509_AUX() functions. These will
handle the certificate and any trust information.

Steve.
-- 
Dr Stephen N. Henson.   http://www.drh-consultancy.demon.co.uk/
Personal Email: [EMAIL PROTECTED] 
Senior crypto engineer, Gemplus: http://www.gemplus.com/
Core developer of the   OpenSSL project: http://www.openssl.org/
Business Email: [EMAIL PROTECTED] PGP key: via homepage.

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: SQL DB instead of index.txt

[Dr S N Henson]

Bear Giles wrote:
 
  What would you classify as bad data in this case?
 
 A fake root cert and HTTPS certs.  Then you do a DNS attack, the victims
 get the blackhat HTTPS site but when they check the public cert respository
 it comes back with a full cert chain.
 
 Ditto bad object signing certs, bad S/MIME certs, etc.
 
 Prime example: the bogus Microsoft cert Verisign issued a while back.
 That's precisely the type of thing I have in mind.  (I doubt Verisign
 would use my postgresql extensions and these plugins, but a university
 or midsized company might.  Want to get a quick A average, or sidestep
 a difficult course?)
 

So how would protection against such bad data be done at the database
level?

  What I meant to say was that some checks are easier to perform outside
  the plugin and may be application specific.
 
 I agree that some checks are easier to perform outside the plugin, but
 my point is that sometimes a plugin may be designed for a specific role
 that requires it be more aggressive about checking the data for itself.
 Weakest link in the chain and all that.
 

Yes I suppose so. For some applications either a simple file based or
memory based database would be appropriate. Its not that appropriate for
a big CA, though that hasn't stopped some people using the index.txt
stuff for that purpose.

  Is there some specific reason why the API should return a key at all
  and not just the certificate (or whatever) it corresponds to?
 
 As I've mentioned elsewhere, Enterprise Jave Beans.  I know this is C,
 not java, but it isn't hard to write a JNI layer to bind the two and
 a lot of routine chores are a lot easier in java than in C.
 

I'm not sure where that Java reference fits in, but I don't use Java
much.

 There's also the issue of memory requirements.  If your plugin is
 covering the cert store for, oh, a major state university you may have
 50,000+ certs in it.   Do you really want the system to try to allocate
 sufficient space to hold *that* response?

Actually I wouldn't want the API to be designed such that it would have
to return 50,000+ matches at all. PKCS#11 for example handles this by
system where the first/next n matches can be retrieved and the search
can be terminated without retrieving all matches.

Steve.
-- 
Dr Stephen N. Henson.   http://www.drh-consultancy.demon.co.uk/
Personal Email: [EMAIL PROTECTED] 
Senior crypto engineer, Gemplus: http://www.gemplus.com/
Core developer of the   OpenSSL project: http://www.openssl.org/
Business Email: [EMAIL PROTECTED] PX-Mozilla-Status: 0009


__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: SQL DB instead of index.txt

[Dr S N Henson]

Bear Giles wrote:
 
  To avoid duplication of code I'd say such concerns should be addressed
  either at the application level or on top of whatever OpenSSL plugin API
  is adopted.
 
 I think that would be a serious mistake.  I'm specifically thinking
 of something like the CA cert repository/JSP code in my postgresql
 library - it's designed to be the store that's published to the world
 as THE official repository for a CA.  If it gets bad data stuffed into
 it, the security of an entire organization can be quickly compromised.
 

What would you classify as bad data in this case? 

Actually I didn't word that comment too well. The database shouldn't
accept everything thrown at it by any means. The API will to some extent
restrict everything in that the data passed has to be in valid
structure.

What I meant to say was that some checks are easier to perform outside
the plugin and may be application specific.

For example a duplicate issuer an serial number in S/MIME may be the
result of a broken certificate sent in a signed message or malicious
intent and it should be possible to resolve this.

A duplicate I+SN in a CA application is likely to be much more serious
and may be a result of a fatal error in the serial number allocation.

 
  I'd say that the actual plugin API should not concern itself with such
  details.
 
 I agree, but that doesn't mean there's no connection between the
 two.
 
 As a specific example, I think it's now clear that any key returned
 from a 'findByX' command must be considered opaque.  Some backends may
 use hash-of-certificate, others hash-of-issuer-and-serial-number.
 This in turn restricts the type of caching that the application itself
 can do.

Is there some specific reason why the API should return a key at all
and not just the certificate (or whatever) it corresponds to?

Steve.
-- 
Dr Stephen N. Henson.   http://www.drh-consultancy.demon.co.uk/
Personal Email: [EMAIL PROTECTED] 
Senior crypto engineer, Gemplus: http://www.gemplus.com/
Core developer of the   OpenSSL project: http://www.openssl.org/
Business Email: [EMAIL PROTECTED] PGP key: via homepage.

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: SQL DB instead of index.txt

[Dr S N Henson]

Richard Levitte - VMS Whacker wrote:
 
 From: Dr S N Henson [EMAIL PROTECTED]
 
 stephen.henson Is there some specific reason why the API should
 stephen.henson return a key at all and not just the certificate (or
 stephen.henson whatever) it corresponds to?
 
 You might want to store keys alone for different reasons.  Let's
 remember that OpenSSL isn't just used by SSL and X.509 applications.
 
 I see this a little like hardware-protected keys, they are also just
 keys with no specific certificate tied to them.
 

When I said key I didn't mean a private key. It would be a requirement
of the API that private keys, certificates, CRLs and maybe other things
like opaque data objects, attribute certificates etc could be stored.

My comment was to a database key and that findbyX might return some
kind of opaque reference to a database key. What I was saying was that
some implementations might not have an equivalent to a database key
and would have to fake one. Also if all you can do with the key is
lookup the object it corresponds to then findbyX might as well return
the object directly and have the key lookup in the plugin implementation
and not at the API level.

Steve.
-- 
Dr Stephen N. Henson.   http://www.drh-consultancy.demon.co.uk/
Personal Email: [EMAIL PROTECTED] 
Senior crypto engineer, Gemplus: http://www.gemplus.com/
Core developer of the   OpenSSL project: http://www.openssl.org/
Business Email: [EMAIL PROTECTED] PGP key: via homepage.
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: SQL DB instead of index.txt

[Dr S N Henson]

Bear Giles wrote:
 
 Of course, this opens the whole can-o-worms of what constitutes
 a duplicate cert?  Is it an exact match, or matching I+SN, or
 some other criteria?
 

There are some cases where only an exact match is acceptable. An example
is how OpenSSL performs a verify operation on a single self-signed
certificate. It looks up the certificate from the trusted certificate
store and trusts it *only* if the certificate precisely matches the one
from the store: this is done by comparing the hashes of the whole
certificate.

If it only did an I+SN match then an attacker could readily generate a
self-signed certificate using its own key with matching I+SN.

If an when OpenSSL verify permist trust explicit trust of an EE
certificate without trusting the chain a similar criteria will need to
be applied.

Steve.
-- 
Dr Stephen N. Henson.   http://www.drh-consultancy.demon.co.uk/
Personal Email: [EMAIL PROTECTED] 
Senior crypto engineer, Gemplus: http://www.gemplus.com/
Core developer of the   OpenSSL project: http://www.openssl.org/
Business Email: [EMAIL PROTECTED] PGP key: via homepage.

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: SQL DB instead of index.txt

[Dr S N Henson]

Bear Giles wrote:
 
   Issuer and subject number should also be unique, and it's a common
   search pattern.  I don't think anyone searches on the hash of the
   entire certificate.
 
  It should be unique but it might not be, either by accident or malicious
  intent.
 
 This indirectly raises a question we've been skirting: is this a
 dumb store that accepts anything passed to it, or is it an intelligent
 store that attempts to enforce some minimal level of internal consistency?
 
 Flipping the question around, I think there's no doubt that it would be
 desirable to allow plug-ins to implement various levels of checking,
 both during the initial insertion of a record and during subsequent
 internal consistency checks.  An application may use a simple store,
 while a CA cert repository may use a very strict one.
 
 But this begs the question of what's the minimum standard expected of
 all stores?  Should they ever be accomodating of malicious intent?
 

To avoid duplication of code I'd say such concerns should be addressed
either at the application level or on top of whatever OpenSSL plugin API
is adopted.

My point was that in some applications certificates may be added from an
untrusted source. An example would be an S/MIME application which adds
certificates for later use from S/MIME messages. It may add certificates
even though it doesn't trust the issuer so that a user might trust a
certificate by out of band means. This is the kind of thing that
Netscape messenger and other S/MIME clients can do. In such a case
things like duplicate issuer and serial numbers may occur and should be
protected against (at whatever level).

  There are a couple of cases that use the hash of the whole certificate.
  The OCSP v2 draft for example.
 
 I'm not arguing that the database shouldn't support searches on this
 hash, just that it may not be the best primary key.  I would expect
 there are more requests for cert chains (which are extremely efficient
 with issuer-and-serial-number indexing) than full-cert hash values.

I'd say that the actual plugin API should not concern itself with such
details. It should just send a request to the plugin requesting all the
objects (certificates, CRLs, private keys etc) that match certain
criteria and it would be up to the plugin itself to decide the most
efficient way to satisfy the request.

Steve.
-- 
Dr Stephen N. Henson.   http://www.drh-consultancy.demon.co.uk/
Personal Email: [EMAIL PROTECTED] 
Senior crypto engineer, Gemplus: http://www.gemplus.com/
Core developer of the   OpenSSL project: http://www.openssl.org/
Business Email: [EMAIL PROTECTED] PGP key: via homepage.
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: SQL DB instead of index.txt

[Dr S N Henson]

Bear Giles wrote:
 
   One classic approach is to have all lookup functions return a
   list of unique keys.  The caller then requests each object individually
   via a lookup that guarantees uniqueness.  Uniqueness is easy to guarantee
   on any hashed or relational store - make it the primary key!
 
  An earlier attempt used a hash of the entire certificate which, if it
  isn't unique would be the least of your worries...
 
 Issuer and subject number should also be unique, and it's a common
 search pattern.  I don't think anyone searches on the hash of the
 entire certificate.
 

It should be unique but it might not be, either by accident or malicious
intent.

There are a couple of cases that use the hash of the whole certificate.
The OCSP v2 draft for example.

 
  That's the kind of thing I looked at when I started on a revision ages
  ago. One problem with that is how to add additional lookup methods when
  they are needed without breaking existing code.
 
 I got a key db about 80% implemented on Monday... then got hit
 with a nasty virus making the rounds.  Maybe I'll be able to finish
 by this weekend - at least I can no longer toast marshmellows on my
 forehead.
 
 But support for additional lookup methods isn't a problem.  You just
 have a version number in the plug-in and the loader links in an
 unsupported operation function if the versions don't match.  The
 caller should check the error code... but it should be doing that anyway. :-)

I'd rather not have the OpenSSL core code have to keep track of which
version supported which lookup techniques. An alternative is to have one
lookup function and a parameter specifying the lookup type. If a version
then doesn't recognise the lookup technique it can return an error
saying it doesn't understand the method. This maps well to the ASN1
CHOICE type which is represented as:

struct {
int type;
union {
TYPE1 *a;
TYPE2 *b;
TYPE3 *c;
/* etc */
} d;
}

Steve.
-- 
Dr Stephen N. Henson.   http://www.drh-consultancy.demon.co.uk/
Personal Email: [EMAIL PROTECTED] 
Senior crypto engineer, Gemplus: http://www.gemplus.com/
Core developer of the   OpenSSL project: http://www.openssl.org/
Business Email: [EMAIL PROTECTED] PGP key: via homepage.
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: SQL DB instead of index.txt

[Dr S N Henson]

Bear Giles wrote:
 
  I'll dig out the code. It was largely based around the PKCS#11
  functionality but with an OpenSSL flavour. That is you have a load of
  objects each of which is a set of attributes. You can then lookup based
  on exact matches of each attribute.
 
 This is query by example.  It has some benefits, but can be a real
 pain to implement.
 

Yes I noticed that :-) Its what PKCS#11 uses and it was *almost* what
OpenSSL could use. I was originally thinking in terms of a database
looking up based on matches on one attribute (whichever matched an index
or would likely result in the smallest list) and then running a generic
matching function to prune the rest.

I realised OpenSSL only really needs single matching for just about
everything.

  One problem was that it returned matching entries as STACK_OF. That
  would work for small numbers of matches but would be awkward for huge
  databases with large numbers of matches for which some kind of get
  first n matching and get next n matching (with n =1) might be more
  appropriate.
 
 One classic approach is to have all lookup functions return a
 list of unique keys.  The caller then requests each object individually
 via a lookup that guarantees uniqueness.  Uniqueness is easy to guarantee
 on any hashed or relational store - make it the primary key!
 
 A good candidate for this is the issuer-and-serial-number hash.  (The
 full 20 bytes, not a 4 byte variant.)  Even if you base64-encode it so
 the keys will be 7-bit safe, you're only talking about 28 bytes per key.
 

An earlier attempt used a hash of the entire certificate which, if it
isn't unique would be the least of your worries...

In any case the problem with returning a list is the amount of work that
might be involved in satisfying a huge query. If it were simply a matter
of space then returning keys would indeed be OK. 

  I'd got one of the databases partly going which was a simple memory
  based database.
 
 If I have an API, I could probably knock out a simple Berkerley DB 1.x
 store for certs and private keys pretty quickly, complete with dynamic
 library binding.  This is good enough for a single user, with multiple
 users you would want to go to 2.x with transaction handling.
 
 The schema I had in mind was:
 
 certs:
 
 key:
   char iands[28];  // base64 encoded SHA-1 hash of issuer DN + SN
 
 data:
   struct {
 char version[2];   // { 0, 0 }
 char state;// V)alid, E)xpired, R)evoked, other?
 char dateRevoked[16];  // MMDDHHMMSS, GMT
 //  maybe a list of hashes, for efficienciency?
 char cert[0];  // ASN.1 encoded cert
   };
 
 the date is split out, not time_t, because this is Y2038 safe and
 eliminates byte ordering issues.
 
 private keys:
 
 key:
   char kid[28];   // base-64 encoded SHA-1 hash of public key
 
 data:
struct {
  char version[2]; // { 0, 0 }
  char cert[0];// ASN.1 encoded key, normally PKCS8
}
 
 The Cert API could be:
 
   struct CertDB {
  int (*close)(CertDB *);
 
  int (*store)(CertDB *, const X509 *x);
 
  int (*revoke)(CertDB *, const char *iands);
 
  int (*remove)(CertDB *, const char *iands);
 
  X509 (*lookup)(CertDB *, const char *iands);
  char (*getStatus)(CertDB *, const char *iands);
  char (*getDateRevoked)(CertDB *, const char *iands);
 
  int (*findBySubject)(CertDB *, const X509_NAME *, char **results);
  int (*findByIssuer)(CertDB *, const X509_NAME *, char **results);
  int (*findBySubjectHash)(CertDB *, const char *, char **results);
  int (*findByIssuerHash)(CertDB *, const char *, char **results);
  int (*findByKeyID)(CertDB *, const char *, char **results);
 
  int (*listRevoked)(CertDB *, char **results);
 
  int (*expire)(CertDB *);
   };
   typedef struct CertDB CertDB;
 
   CertDB * certdb_open(parameters to be determined...)
 

That's the kind of thing I looked at when I started on a revision ages
ago. One problem with that is how to add additional lookup methods when
they are needed without breaking existing code.

For general OpenSSL use quite a few other lookup types would be needed
anyway such as lookup by email address, issuer and serial number etc.
Additional info would also need to be added to certificates such as
trust settings and S/MIME capabilities, though that's partly covered by
the X509_TRUSTED stuff.

Steve.
-- 
Dr Stephen N. Henson.   http://www.drh-consultancy.demon.co.uk/
Personal Email: [EMAIL PROTECTED] 
Senior crypto engineer, Gemplus: http://www.gemplus.com/
Core developer of the   OpenSSL project: http://www.openssl.org/
Business Email: [EMAIL PROTECTED] PGP key: via homepage.

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List 

Re: SQL DB instead of index.txt

[Dr S N Henson]

Discussion moved from openssl-users...

Bear Giles wrote:
 
   I can think of multiple
   common storage formats: text files, DBM files, LDAP, RDBMS.
 
  why not use an existing database abstraction layer such as libdbi or ODBC?
 
 Too abstract - queries are done with SQL statements.  That's not a
 problem with a RDBMS backend, but requires a lot of extra code with
 everything else.  Even if you identify a set of standard query strings
 and use hardcoded strcmp(), maintenance is a nightmare.
 

Whatever we do needs to work on all platforms OpenSSL does and not add a
substantial overhead. There should ideally be a means of using a
lightweight text, file and memory based databases but pluggable with a
more sophisticated database where necessary/possible.

 All you really need is a simple api: store(), remove(), lookup(),
 revoke() (or update()?), maybe a few more, and a dynamic library
 loader.  And some configuration code that allows the user to specify
 which dynamic library to load.  (Then again, in this case it may be
 okay to just create a symlink from some standard name to the desired
 dynamic library.)

The fun arises when you get to individual details and how to handle
them.

For example lookup() would end up looking up a variety of things and
return multiple matching entities. The multiple entities raises the
issue of whether matching number of entities should be handled or if its
OK to just return a STACK_OF matching entities.

Common lookup methods and their uses include...

Issuer name: SSL client authentication, ca application.
Issuer name and serial number: S/MIME
Subject Name: 'ca' application.
Alias: to display a human readable list of certificates.
Key ID: to find matching certificate and key.
Email address: S/MIME.

Adding OCSP and in particular OCSP v2 adds lots of other options to
that.

All sorts of possibilities arise when loading private keys too. Ideally
information should be available about a private key (its key ID for
example) without entering a password. That's something none of the
standard formats support, unfortunately.

While it isn't necessary to handle all of this lot at first, the API
should be written in such a way that it can be extended without breaking
those version which use older versions of the API.

Steve.
-- 
Dr Stephen N. Henson.   http://www.drh-consultancy.demon.co.uk/
Personal Email: [EMAIL PROTECTED] 
Senior crypto engineer, Gemplus: http://www.gemplus.com/
Core developer of the   OpenSSL project: http://www.openssl.org/
Business Email: [EMAIL PROTECTED] PGP key: via homepage.
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: SQL DB instead of index.txt

[Dr S N Henson]

H, this doesn't seem to have made it to the list. No doubt there
will be two copies now :-)

Bear Giles wrote:
 
   I can think of multiple
   common storage formats: text files, DBM files, LDAP, RDBMS.
 
  why not use an existing database abstraction layer such as libdbi or ODBC?
 
 Too abstract - queries are done with SQL statements.  That's not a
 problem with a RDBMS backend, but requires a lot of extra code with
 everything else.  Even if you identify a set of standard query strings
 and use hardcoded strcmp(), maintenance is a nightmare.
 

Whatever we do needs to work on all platforms OpenSSL does and not add a
substantial overhead. There should ideally be a means of using a
lightweight text, file and memory based databases but pluggable with a
more sophisticated database where necessary/possible.

 All you really need is a simple api: store(), remove(), lookup(),
 revoke() (or update()?), maybe a few more, and a dynamic library
 loader.  And some configuration code that allows the user to specify
 which dynamic library to load.  (Then again, in this case it may be
 okay to just create a symlink from some standard name to the desired
 dynamic library.)

The fun arises when you get to individual details and how to handle
them.

For example lookup() would end up looking up a variety of things and
return multiple matching entities. The multiple entities raises the
issue of whether matching number of entities should be handled or if its
OK to just return a STACK_OF matching entities.

Common lookup methods and their uses include...

Issuer name: SSL client authentication, ca application.
Issuer name and serial number: S/MIME
Subject Name: 'ca' application.
Alias: to display a human readable list of certificates.
Key ID: to find matching certificate and key.
Email address: S/MIME.

Adding OCSP and in particular OCSP v2 adds lots of other options to
that.

All sorts of possibilities arise when loading private keys too. Ideally
information should be available about a private key (its key ID for
example) without entering a password. That's something none of the
standard formats support, unfortunately.

While it isn't necessary to handle all of this lot at first, the API
should be written in such a way that it can be extended without breaking
those version which use older versions of the API.

Steve.
-- 
Dr Stephen N. Henson.   http://www.drh-consultancy.demon.co.uk/
Personal Email: [EMAIL PROTECTED] 
Senior crypto engineer, Gemplus: http://www.gemplus.com/
Core developer of the   OpenSSL project: http://www.openssl.org/
Business Email: [EMAIL PROTECTED] PGP key: via homepage.
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: SQL DB instead of index.txt

[Dr S N Henson]

Richard Levitte - VMS Whacker wrote:
 
 From: Dr S N Henson [EMAIL PROTECTED]
 
 stephen.henson I've done some work on this but its only partly
 stephen.henson complete and sitting in a dark corner of my hard
 stephen.henson drive...
 
 I'm curious to see what you've come up with so far.
 

I'll dig out the code. It was largely based around the PKCS#11
functionality but with an OpenSSL flavour. That is you have a load of
objects each of which is a set of attributes. You can then lookup based
on exact matches of each attribute.

However since all OpenSSL needs is a match on a single attribute it was
a bit of overkill. If multiple atttribute searches were needed it could
always pull everything matching one attribute and weed out the rest.

One problem was that it returned matching entries as STACK_OF. That
would work for small numbers of matches but would be awkward for huge
databases with large numbers of matches for which some kind of get
first n matching and get next n matching (with n =1) might be more
appropriate.

The way I'd intended it to be used would be to allow various database
types which would implement the top level API. Implementing the whole
API would be excessively painful and unnecessary for some cases.

I'd got one of the databases partly going which was a simple memory
based database. This is the kind of thing a simple applications could
use with a small number of certificates: call some add() function and
let the supplied code handle all the lookups. This would probably be OK
for the existing directory and file based stuff.

Other database types could be some kind of hash based database (which
could use gdb or Berkeley db) or indeed some SQL stuff.

Steve.
-- 
Dr Stephen N. Henson.   http://www.drh-consultancy.demon.co.uk/
Personal Email: [EMAIL PROTECTED] 
Senior crypto engineer, Gemplus: http://www.gemplus.com/
Core developer of the   OpenSSL project: http://www.openssl.org/
Business Email: [EMAIL PROTECTED] PGP key: via homepage.

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: check_purpose_ssl_server|client

[Dr S N Henson]

francoise lacambre wrote:
 
 hello,
 I have a little question about check_purpose_ssl_server
 and check_purpose_ssl_client.
 check_chain_purpose function calls X509_check_purpose
 for all untrusted certificats in the chain.
 This function calls a check_purpose function.
 In SSL_SERVER (or SSL_CLIENT) case,
 check_purpose_ssl_server (or check_purpose_ssl_client)
 function verifies that, if ExtendedKeyUsage attribut is
 set, it contents the XKU_SSL_SERVER or XKU_SGC (or
 XKU_SSL_CLIENT) attribut bit.
 This test is meaningfull on the end user certificate but not
 on the intermediaite CA certificat.
 Do you agree ?

In CA certficates the extended key usage extension is used (AFAIK) to
restrict what kinds of end user and CA certificates can be signed by it.

Steve.
-- 
Dr Stephen N. Henson.   http://www.drh-consultancy.demon.co.uk/
Personal Email: [EMAIL PROTECTED] 
Senior crypto engineer, Gemplus: http://www.gemplus.com/
Core developer of the   OpenSSL project: http://www.openssl.org/
Business Email: [EMAIL PROTECTED] PGP key: via homepage.
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: [PATCH] PKCS#11 code update

[Dr S N Henson]

Eric Laroche wrote:
 
 Dr S N Henson wrote:
 
 Eric Laroche wrote:
 
  Yes, I am aware of the OpenSSL engine interface.  Our code applies
  quite similar mechanisms of feeding 'configuration' information (name/
  value pairs) from application code.  However, the engine command
  definitions affect the whole engine setting, whereas our configuration
  affects an abstraction called (key) 'object specification'.  Each key
  or certificate may have quite different settings concerning where to
  accomplish encryption and which password callbacks to be applied, etc.
 
  The PKCS#11 object specification / configuration seems to me to be a
  different concept compared to the engine configuration.  However, the
  PKCS#11 interface may be seen as a 'PKCS#11' engine.
 
 
  How could crypto acceleration or querying capabilities be handled in
  this model?
 
 Querying capabilities (PKCS#11 calls them 'mechanisms') is already
 implemented in the code's lower level routines.  However, since at the
 moment, only asymmetric ciphers access is implemented, a protocol of
 asking all capabilities and setting methods accordingly wasn't yet so
 much an issue.
 

I was thinking that this works fairly well if an OpenSSL ENGINE is
mapped to a specific PKCS#11 library and token. The capabilities would
then map to the supported PKCS#11 methods of that token. 

Its not so clear how this would be handled if multiple libraries or
tokens are mapped onto a single ENGINE, perhaps with the same mechanism
supported by multiple tokens.

 
  I was thinking that a possible way to handle this is to map a specific
  PKCS#11 library+token to an ENGINE. This would behave a bit like the
  dynamic ENGINE in that the PKCS#11 ENGINE would be called with a set of
  init commands which would then produce a second ENGINE which would refer
  to the actual PKCS#11 implementation.
 
 This sounds like a reasonable approach to a part of the desired
 OpenSSL PKCS#11 - ENGINE integration.
 
 The dynamic engine method resolution may need to be extended or
 complemented, to allow method dispatching on a key basis.  This has,
 in our code, been done outside the actual engine code, but the
 (dynamic) engine code might be a more suited place for that.
 

Well I wasn't thinking of modifying the dynamic ENGINE as such just
using a method analagous to the dynamic approach. For example any
application which would use such an PKCS#11 ENGINE might do something
like this:

Lookup engine called PKCS11, this would give the application a copy of
the PKCS#11 ENGINE.

Send ctrl commands to the copy, giving details of the token name, ENGINE
name to use(if needed), whether to add to list, PKCS#11 library location
etc. With some defaults like using the first token found if none
specified.

Send a LOAD ctrl command, this would load the PKCS#11 library, look for
the token name and map such things as mechanisms to OpenSSL methods.

At this point the ENGINE would become a real engine which would map
onto a specific PKCS#11 library and token.

This would enable things like ENGINE_load_private_key() to lookup a
specific key based solely on its CKA_LABEL for example, rather than
requiring all the parameters in the key_id argument. 

Steve.
-- 
Dr Stephen N. Henson.   http://www.drh-consultancy.demon.co.uk/
Personal Email: [EMAIL PROTECTED] 
Senior crypto engineer, Gemplus: http://www.gemplus.com/
Core developer of the   OpenSSL project: http://www.openssl.org/
Business Email: [EMAIL PROTECTED] PGP key: via homepage.
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: X509_NAME ASN.1 encoding

[Dr S N Henson]

Stefan Kotes wrote:
 
 All,
 The ASN.1 DER encoding rules for SET OF collection say that the values of
 the occurrences in this collection should be lexicographically ordered. I
 have noticed that i2d_X509_NAME function omits this sorting for the
 RelativeDistinguishedName member of the X509-NAME. BTW, I saw the same
 behavior in other libraries (for example getEncoded method of
 X509Certificate class in Java 2 SDK), but could not find an explanation for
 this exception.
 Can somebody explain this exception from asn.1 encoding rules ?

I think this will only be OpenSSL 0.9.6X and before, the new ASN1 code
should handle this properly.

Its a bug. However multiple members in SET OF for RDNs are very rare:
I've only come across a couple of examples in the field. 

They can't be produced with the commmand line tools but can be by use of
the API.

Steve.
-- 
Dr Stephen N. Henson.   http://www.drh-consultancy.demon.co.uk/
Personal Email: [EMAIL PROTECTED] 
Senior crypto engineer, Gemplus: http://www.gemplus.com/
Core developer of the   OpenSSL project: http://www.openssl.org/
Business Email: [EMAIL PROTECTED] PGP key: via homepage.
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: multiple calls on DecryptUpdate

[Dr S N Henson]

Cristina Nita-Rotaru wrote:
 
 Hello.
 
 There might be a problem with EVP_DecryptUpdate.
 
 My understanding was that EVP_EncryptUpdate can be called
 multiple times and then conclude the encryption by calling
 EVP_EncryptFinal. A similar mechanism applies for
 EVP_DecryptUpdate and EVP_DecryptFinal.
 
 In a test that I am running where two blocks of 16 bytes
 are encrypted by calling EVP_EncryptUpdate twice (each on 16 bytes)
 and then EVP_EncryptFinal, when I want to perform the
 decryption in a similar manner, the first call of EVP_DecryptUpdate
 on the first 16 bytes reports that only 8 bytes where decrypted.
 Shouldn't this be 16?
 

I've recently answered this in more detail in openssl-users. No its not
a bug because the decrypt routines have to store up to one block of
decrypted data internally due to the padding checking.

Steve.
-- 
Dr Stephen N. Henson.   http://www.drh-consultancy.demon.co.uk/
Personal Email: [EMAIL PROTECTED] 
Senior crypto engineer, Gemplus: http://www.gemplus.com/
Core developer of the   OpenSSL project: http://www.openssl.org/
Business Email: [EMAIL PROTECTED] PGP key: via homepage.
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: openssl-0.9.6 compile problem under win2000+vc6.0

[Dr S N Henson]

²Ü¸Ú ([EMAIL PROTECTED])  wrote:
 
 Hello,
 openssl-0.9.6, openssl-0.9.6a, openssl-0.9.6-stable-snap-20020103,
 openssl-engine-0.9.6c, openssl-0.9.6c, openssl-snap-20020103, these versions
 can not be compiled under windows2000 + VC6.0.
 Whenever I use perl Configure VC-WIN32 or perl Configure VC-NT,
 run ms\do_ms or ms\do_nt, the following errors will be meeting:
 Use of uninitialized value at util\mkdef.pl line 516
 Use of uninitialized value at util\mkdef.pl line 517
 Use of uninitialized value at util\mkdef.pl line 516
 Use of uninitialized value at util\mkdef.pl line 517
 Use of uninitialized value at util\mkdef.pl line 516
 Use of uninitialized value at util\mkdef.pl line 517
 Use of uninitialized value at util\mkdef.pl line 516
 ...
 
 I have to use openssl-0.9.5a. It's awful!
 Can you give me some suggestions? Thank you.
 

These are actually warnings and not errors. Have you tried ignoring them
and trying to compile anyway?

What version of perl are you using?

Steve.
-- 
Dr Stephen N. Henson.   http://www.drh-consultancy.demon.co.uk/
Personal Email: [EMAIL PROTECTED] 
Senior crypto engineer, Gemplus: http://www.gemplus.com/
Core developer of the   OpenSSL project: http://www.openssl.org/
Business Email: [EMAIL PROTECTED] PGP key: via homepage.
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: [PATCH] PKCS#11 code update

[Dr S N Henson]

Eric Laroche wrote:
 
 Hi,
 
 
 Yes, I am aware of the OpenSSL engine interface.  Our code applies
 quite similar mechanisms of feeding 'configuration' information (name/
 value pairs) from application code.  However, the engine command
 definitions affect the whole engine setting, whereas our configuration
 affects an abstraction called (key) 'object specification'.  Each key
 or certificate may have quite different settings concerning where to
 accomplish encryption and which password callbacks to be applied, etc.
 
 The PKCS#11 object specification / configuration seems to me to be a
 different concept compared to the engine configuration.  However, the
 PKCS#11 interface may be seen as a 'PKCS#11' engine.
 

How could crypto acceleration or querying capabilities be handled in
this model?

I was thinking that a possible way to handle this is to map a specific
PKCS#11 library+token to an ENGINE. This would behave a bit like the
dynamic ENGINE in that the PKCS#11 ENGINE would be called with a set of
init commands which would then produce a second ENGINE which would refer
to the actual PKCS#11 implementation.

Steve.
-- 
Dr Stephen N. Henson.   http://www.drh-consultancy.demon.co.uk/
Personal Email: [EMAIL PROTECTED] 
Senior crypto engineer, Gemplus: http://www.gemplus.com/
Core developer of the   OpenSSL project: http://www.openssl.org/
Business Email: [EMAIL PROTECTED] PGP key: via homepage.

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: [PATCH] PKCS#11 code update

[Dr S N Henson]

Eric Laroche wrote:
 
 Hi,
 
 
 Yes, I am aware of the OpenSSL engine interface.  Our code applies
 quite similar mechanisms of feeding 'configuration' information (name/
 value pairs) from application code.  However, the engine command
 definitions affect the whole engine setting, whereas our configuration
 affects an abstraction called (key) 'object specification'.  Each key
 or certificate may have quite different settings concerning where to
 accomplish encryption and which password callbacks to be applied, etc.
 
 The PKCS#11 object specification / configuration seems to me to be a
 different concept compared to the engine configuration.  However, the
 PKCS#11 interface may be seen as a 'PKCS#11' engine.
 

How could crypto acceleration or querying capabilities be handled in
this model?

I was thinking that a possible way to handle this is to map a specific
PKCS#11 library+token to an ENGINE. This would behave a bit like the
dynamic ENGINE in that the PKCS#11 ENGINE would be called with a set of
init commands which would then produce a second ENGINE which would refer
to the actual PKCS#11 implementation.

Steve.
-- 
Dr Stephen N. Henson.   http://www.drh-consultancy.demon.co.uk/
Personal Email: [EMAIL PROTECTED] 
Senior crypto engineer, Gemplus: http://www.gemplus.com/
Core developer of the   OpenSSL project: http://www.openssl.org/
Business Email: [EMAIL PROTECTED] PGP key: via homepage.
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: DC= fields (subject NID) in 9.7?

[Dr S N Henson]

Oscar Jacobsson wrote:
 
 
 Having them in obj_mac.h should mean they are recognized by default,
 shouldn't it? I'm not sure exactly what a_strnid.c does, but it looks
 like a collection of convenience functions. I'm sure DC could be added,
 as long as some kind soul could point out what its upper bound and
 string type are.
 

The stuff in a_strnid.c is set of definitions for string like DN
components and some related helper functions. For each supported
component maximum and minimum lenghts can be added and a set of
permissible string types.

If a type is not in the table then no limits are placed on its length
and its type is a DirectoryString except it doesn't use
UniversalStrings.

Some types can have the permitted string types modified by a global
mask. This allows things like BMPStrings and UTF8Strings to be avoided
in cases where they could be a problem (older versions of Netscape for
example).

Steve.
-- 
Dr Stephen N. Henson.   http://www.drh-consultancy.demon.co.uk/
Personal Email: [EMAIL PROTECTED] 
Senior crypto engineer, Gemplus: http://www.gemplus.com/
Core developer of the   OpenSSL project: http://www.openssl.org/
Business Email: [EMAIL PROTECTED] PGP key: via homepage.
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: Problem loading public key

[Dr S N Henson]

 Filipe Custódio wrote:
 
 Hi!
 
 I've been having some problems trying to load a PEM formated public
 key into an RSA structure. The key I want to load is:
 
 -BEGIN PUBLIC KEY-
 MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC7514kyrphs8TdJIh9KqUpgWSZ
 M17LcfJMLaJxLP/Dglf4vkFNyOZkAug1fhP+pXxR+AecWUFifg3bVt+JJz3MkSr9
 uXaBD4CScBUHzUqtcVENdjX4JkP+FzatVARN5QjnLFjif+G5Wltk5Ek7i2wfGZ8z
 zAise955pM3h7yNmyQIDAQAB
 -END PUBLIC KEY-
 
 To read the key I'm using the PEM_read_RSAPublicKey() function.
 
 The first problem I ran into was a no start line error. I tracked
 this to the check_pem() function at pem_lib.c failing to recognize the
 start line as it was written by openssl -pubout.
 
 I changed the start and end line to read BEGIN RSA PUBLIC KEY and
 END RSA PUBLIC KEY. Now the errors I am receiving are:
 
 error:0D118071:asn1 encoding routines:d2i_ASN1_UINTEGER:expecting an
 integer
 error:0D09E082:asn1 encoding routines:d2i_RSAPublicKey:parsing
 error:0906700D:PEM routines:PEM_ASN1_read_bio:ASN1 lib
 
 What am I doing wrong? Can anyone point me to a working example?
 

You are using the wrong function: use PEM_read_RSA_PUBKEY instead.

Steve.
-- 
Dr Stephen N. Henson.   http://www.drh-consultancy.demon.co.uk/
Personal Email: [EMAIL PROTECTED] 
Senior crypto engineer, Gemplus: http://www.gemplus.com/
Core developer of the   OpenSSL project: http://www.openssl.org/
Business Email: [EMAIL PROTECTED] PGP key: via homepage.

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: PEM_ASN1_read question

[Dr S N Henson]

I was trying to compile test scripts (openssl-0.9.6b)
 ~/openssl-0.9.6b/demos/Maurice/*.c
When I try to make the file, I get the following error:
Too few arguments to function PEM_ASN1_read

Yes you will get that. The stuff in demos/Maurice/*.c is way out of
date. Applications shouldn't even call PEM_ASN1_read() directly any
more.

Try downloading an OpenSSL 0.9.7 snapshot and using the demos from
there: they've been modernized.

Steve.
-- 
Dr Stephen N. Henson.   http://www.drh-consultancy.demon.co.uk/
Personal Email: [EMAIL PROTECTED] 
Senior crypto engineer, Gemplus: http://www.gemplus.com/
Core developer of the   OpenSSL project: http://www.openssl.org/
Business Email: [EMAIL PROTECTED] PGP key: via homepage.

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: OpenSSL libraries on Windows, reworked.

[Dr S N Henson]

Rich Salz wrote:
 
 When are you going to drop Win16 support?
 How about 0.9.7 being the last 16bit platform release?
 

I'm not sure if OpenSSL still compiles under Win16 anyway. There's some
legacy Win16 code and build options but it hasn't been tested for some
time.

Steve.
-- 
Dr Stephen N. Henson.   http://www.drh-consultancy.demon.co.uk/
Personal Email: [EMAIL PROTECTED] 
Senior crypto engineer, Gemplus: http://www.gemplus.com/
Core developer of the   OpenSSL project: http://www.openssl.org/
Business Email: [EMAIL PROTECTED] PGP key: via homepage.
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: OpenSSL libraries on Windows, reworked.

[Dr S N Henson]

Doug Kaufman wrote:
 
 On Tue, 4 Dec 2001, Richard Levitte - VMS Whacker wrote:
 
  From: Dr S N Henson [EMAIL PROTECTED]
 
  drh I'm not sure if OpenSSL still compiles under Win16 anyway. There's some
  drh legacy Win16 code and build options but it hasn't been tested for some
  drh time.
 
  And nobody has complained?  If noone is interested, I don't see a
  reason for us to keep pretending we support it.
 
  Folks, it's up to you to make the call!  Unless I hear that Win16
  support is needed and still working (at least with OpenSSL 0.9.6b), I
  might just drop it as part of my haulover.
 
 What compiler is used under Win16? I still have openssl compiling under
 plain DOS using the DJGPP port of GCC and the bash shell.

You should be OK with DJGPP because it evades all the yucky Win16
restrictions. 

The true Win16 version IIRC used an ancient version of VC++ (1.52?). I
tried compiling SSLeay (yes SSLeay it was *that* long ago) with this
ages ago and it sort of worked with a horribly broken pseudo console.
The MS-DOS version choked saying it had run out of memory. I'd be very
surprised if the Win16 version could be made to work without major
surgery.

Steve.
-- 
Dr Stephen N. Henson.   http://www.drh-consultancy.demon.co.uk/
Personal Email: [EMAIL PROTECTED] 
Senior crypto engineer, Gemplus: http://www.gemplus.com/
Core developer of the   OpenSSL project: http://www.openssl.org/
Business Email: [EMAIL PROTECTED] PGP key: via homepage.

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: Trying to understand the Windows build

[Dr S N Henson]

Richard Levitte - VMS Whacker wrote:
 
 I've looked at util/mk1mf.pl and wondered for a long time why it does
 it's own configuration stuff (from all the util/pl/*.pl files) instead
 of relying on data created by Configure.  When one looks in Configure,
 one can find entries for the Windows targets all right, but with no C
 flags or anything like that.  Those things are instead in the
 util/pl/*.pl files.
 
 This can be terribly confusing when one tries to find out what options
 are actually used in a build.  Too many places to look around in.
 
 Is there any reason for this?  If not, I'll work on unifying this (not
 immediately, however).
 

No reason at all. Now I come to think of it a lot of that stuff could be
unified or called directly from the Configure script and do things in a
more standard way such as writing the Windows makefile to Makefile at
the top level like all the others. Then you could do something like:

perl Configure VC-WIN32
nmake

and it would work or say...

perl Configure VC-WIN32-debug
nmake

On the subject of Windows builds I had this idea of generating VC++
workspaces automagically by getting a perl script to get dev studio to
create one of the beasts using OLE. This is left as an exercise to the
reader :-)

Steve.
-- 
Dr Stephen N. Henson.   http://www.drh-consultancy.demon.co.uk/
Personal Email: [EMAIL PROTECTED] 
Senior crypto engineer, Gemplus: http://www.gemplus.com/
Core developer of the   OpenSSL project: http://www.openssl.org/
Business Email: [EMAIL PROTECTED] PGP key: via homepage.

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: How to use other character in certificate

[Dr S N Henson]

 blue wrote:
 
 Dear all
 
 I try many times in BMPString which I think it can show my
 character(not english) but It show 
 So please suggest me the way to show other character.
 

This depends on what you are trying to display the characters with. If
your terminal supports UTF8 then you should be able to display the
characters using the relevant -nameopt options in OpenSSL x509 utility
for example.

Steve.
-- 
Dr Stephen N. Henson.   http://www.drh-consultancy.demon.co.uk/
Personal Email: [EMAIL PROTECTED] 
Senior crypto engineer, Gemplus: http://www.gemplus.com/
Core developer of the   OpenSSL project: http://www.openssl.org/
Business Email: [EMAIL PROTECTED] PGP key: via homepage.


__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: load_verify_locations(ctx,NULL,path) failed.

[Dr S N Henson]

Oscar Jacobsson wrote:
 
 Hi!
 
 From the SSL_CTX_load_verify_locations manpage:
 
 If CApath is not NULL, it points to a directory containing CA certificates in
 PEM format. The files each contain one CA certificate. The files are looked up
 by the CA subject name hash value, which must hence be available. If more than
 one CA certificate with the same name hash value exist, the extension must be
 different (e.g. 9d66eef0.0, 9d66eef0.1 etc). The search is performed in the
 ordering of the extension number, regardless of other properties of the
 certificates. Use the c_rehash utility to create the necessary links.
 
 Regards,
 
 //oscar
 
 Glenn wrote:
 
  I have a trusted cert, say c:\path\file.pem on
  Windows FAT32. Using
  SSL_CTX_load_verify_locations(ctx,c:\\path\\file.pem,NULL),
  I managed to verify the peer cert correctly.
 

Only problem is that this is on Windows and the standard c_rehash wont
work.

Steve.
-- 
Dr Stephen N. Henson.   http://www.drh-consultancy.demon.co.uk/
Personal Email: [EMAIL PROTECTED] 
Senior crypto engineer, Gemplus: http://www.gemplus.com/
Core developer of the   OpenSSL project: http://www.openssl.org/
Business Email: [EMAIL PROTECTED] PGP key: via homepage.


__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: X509_STORE_get_by_subject

[Dr S N Henson]

Ben Laurie wrote:
 
 Ben Laurie wrote:
 
  francoise lacambre wrote:
  
   Don't you think, in the X509_STORE_get_by_subject function, that the following
   line
   vs-current_method=j;
   would be replaced by :
   vs-current_method=i;
 
  Yes!
 
 Hmm ... still looks wrong to me ... I suspect it should do this, but it
 isn't my code - Steve?
 
 Index: crypto/x509/x509_lu.c
 ===
 RCS file: /e/openssl/cvs/openssl/crypto/x509/x509_lu.c,v
 retrieving revision 1.24
 diff -u -r1.24 x509_lu.c
 --- crypto/x509/x509_lu.c   2001/09/01 20:01:58 1.24
 +++ crypto/x509/x509_lu.c   2001/11/20 13:58:10
 @@ -285,19 +285,21 @@
 X509_STORE *ctx=vs-ctx;
 X509_LOOKUP *lu;
 X509_OBJECT stmp,*tmp;
 -   int i,j;
 +   int i,j,k;
 
 tmp=X509_OBJECT_retrieve_by_subject(ctx-objs,type,name);
 
 if (tmp == NULL)
 {
 -   for (i=vs-current_method;
 isk_X509_LOOKUP_num(ctx-get_cert_methods); i++)
 +   for (i=vs-current_method,k=0;
 ksk_X509_LOOKUP_num(ctx-get_cert_methods); i++,k++)
 {
 +   if(k ==
 sk_X509_LOOKUP_num(ctx-get_cert_methods))
 +   k=0;
 
 lu=sk_X509_LOOKUP_value(ctx-get_cert_methods,i);
 j=X509_LOOKUP_by_subject(lu,type,name,stmp);
 if (j  0)
 {
 -   vs-current_method=j;
 +   vs-current_method=k;
 return j;
 }
 else if (j)
 @@ -306,7 +308,6 @@
 break;
 }
 }
 -   vs-current_method=0;
 if (tmp == NULL)
 return 0;
 }
 

Well it isn't my code either :-)

I think the original change is probably correct. The only reason this
kind of error hasn't been noticed is that no internal X509_LOOKUPs can
ever signal a retry.

I *think* the logic is that after a retry is signalled the next call
will continue where the old one left off until its tried all of them
whereupon it will signal a not found error.

Steve.
-- 
Dr Stephen N. Henson.   http://www.drh-consultancy.demon.co.uk/
Personal Email: [EMAIL PROTECTED] 
Senior crypto engineer, Gemplus: http://www.gemplus.com/
Core developer of the   OpenSSL project: http://www.openssl.org/
Business Email: [EMAIL PROTECTED] PGP key: via homepage.
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: Is 'openssl-users' dead?

[Dr S N Henson]

J. Johnson wrote:
 
 The archives show a lot of queries posted to 'openssl-users'--with no
 responses.  Anyone know of any particular reasons?
 
 I thought OpenSSL looked pretty viable, but it won't be if no one will
 help support possible users.
 

The OpenSSL mailing lists have been down for the last week. This should
be fixed now.

Wrt queries I used to answer almost all of them, this took a ridiculous
amount of time and seriously hampered my OpenSSL development work. Now I
assign a lower priority to certain classes of query for example:

1. Those answered in the FAQ.
2. Those clearly answered in the documentation.
3. Those that have been covered before in the mailing lists.
4. Those which don't relate to OpenSSL but packages that use OpenSSL
(mod_ssl, Apache-SSL etc).
5. Those where incomplete or no information is given.

The last category is very annoying. Some people seem to think that it
doesn't work is a complete bug report: no mention of error messages,
the OS being used, any relevant files etc.

Steve.
-- 
Dr Stephen N. Henson.   http://www.drh-consultancy.demon.co.uk/
Personal Email: [EMAIL PROTECTED] 
Senior crypto engineer, Gemplus: http://www.gemplus.com/
Core developer of the   OpenSSL project: http://www.openssl.org/
Business Email: [EMAIL PROTECTED] PGP key: via homepage.

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: OpenSSL and Patches for CAs

[Dr S N Henson]

Massimiliano Pala wrote:
 
 Hi all,
 
 I am ri-posting this message as I have received no replies to it.
 If no one is interested in the proposals then simply ignore this
 message.
 
 -----
 
 [ openssl ca command improve ]
 Some work could be initially done by
 introducing another switch (and conf keyword) to enable/disable the
 usage of the index.txt backend during certificate issuing -- this
 would enable using ca command with unsupported certificate profiles
 (such as duplicate DNs).
 
 Then, with patience, it should be a good thing starting a rewriting of
 the backend db support ... and then, only then, we could start adding
 new RFCs supported certificate profiles (empty DNs, etc... )...
 This is a quite big work to be done.
 I am not sure but I think it can be done without backward compatibility
 issues rising...
 
 [ libca development ]
 Another idea worth exploring could be the writing of a libca where ca
 functions are held as most of them are getting quite big and important
 and having in one large ca.c should be avoided.
 
 I am not sure this is the scope of the openssl project but as this lib
 will be strictly tied with openssl library itself it could be useful
 having it together with the package.
 

Personally I'd be in favour of having a replacement for the ca command.
It was never intended to be used as a full blown CA at all and its
becoming excessively large and hard to maintain.

When you consider all the things a CA might want to do its hard to write
a program flexible enough to handle everone's needs.

I mentioned before that IMHO a better idea would be to have equivalent
functionality which can be accessed from a scripting language such a
perl.

Most of the 'ca' operations are available in automatic form from the
'x509' utility except for CRL generation (but you can get 'ca' to do
that) and SPKAC certification. So most things could be handled by a
script that executes the relevant command.

A better but harder way would be to make the relevant functions
accessible to a scripting language: that is the X509, PEM, EVP and
possibly other libraries.

Steve.
-- 
Dr Stephen N. Henson.   http://www.drh-consultancy.demon.co.uk/
Personal Email: [EMAIL PROTECTED] 
Senior crypto engineer, Gemplus: http://www.gemplus.com/
Core developer of the   OpenSSL project: http://www.openssl.org/
Business Email: [EMAIL PROTECTED] PGP key: via homepage.

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: ca.c fix [-noemailDN]

[Dr S N Henson]

Massimiliano Pala wrote:
 
 Hi,
 
 I found 2 bugs in the previous patch, so here them are the fixes against
 latest SNAP (20011026).
 
 Poblems:
 
 1. the dn_subject structure was not freed at the end of
the do_body function;
 
 2. the dn_subject was not set (empty) if email_dn was set to 1.
This caused the entry in the index.txt file to report null DN
set.
 
 To apply the patchm simply copy it into the openssl/apps dir and do the
 following:
 
 $ patch ca.c.fix-20011026
 
 This will fix the bugs listed.
 

Thanks,

I noticed these when I was attempting a different patch. I think the fix
I've done is functionally equivalent to your patch, except it doesn't
delete the email_dn option from do_subject() which I'll commit
separately.

Also I've deleted emailAddress from the DN in a different way: dup the
name then delete and emailAddress entries, this should retain the
X509_NAME structure in the event of multi values AVAs being used.

Steve.
-- 
Dr Stephen N. Henson.   http://www.drh-consultancy.demon.co.uk/
Personal Email: [EMAIL PROTECTED] 
Senior crypto engineer, Gemplus: http://www.gemplus.com/
Core developer of the   OpenSSL project: http://www.openssl.org/
Business Email: [EMAIL PROTECTED] PGP key: via homepage.

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: Rejecting Certiifcates with Unknown Critical Extensions

[Dr S N Henson]

Douglas E. Engert wrote:
 
 Dr S N Henson wrote:
 
  Douglas E. Engert wrote:
  
   It does not appear there is any code in OpenSSL to make sure all critical
   extensions are checked during a verify. This could be considered a bug.
   The default behavior should be to reject any critical extensions which are
   not understood.
  
 
  There are also lots of things OpenSSL verify should do but it doesn't
  to work around various buggy certificates in common usage.
 
  I think if it followed the letter of RFC2459 it would create
  certificates which would crash a lot of software and reject at least
  half of the certificates in common usage.
 
  A flag could be added to the verify code to reject certificates with
  unsupported critical extensions or make that the default behaviour and a
  flag to tolerate certificates with unsupported critical extensions.
 
 Good idea, make the default to reject. This would then follow the spirit
 of RFC2459.
 

This functionality has been added to the development vesion of OpenSSL
and will appear in OpenSSL 0.9.7. Let me know of any problems.

Steve.
-- 
Dr Stephen N. Henson.   http://www.drh-consultancy.demon.co.uk/
Personal Email: [EMAIL PROTECTED] 
Senior crypto engineer, Gemplus: http://www.gemplus.com/
Core developer of the   OpenSSL project: http://www.openssl.org/
Business Email: [EMAIL PROTECTED] PGP key: via homepage.

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: RSA structure altered during its lifetime?

[Dr S N Henson]

Tom Biggs wrote:
 
 Our crypto accelerator uses Montgomery's Method.  Just as in OpenSSL's
 eay RSA functions, the chip has pre-calculation initialization steps.
 I can tell the chip to just do them each time, but of course it is faster
 to only do it once for each modulus (n, or p and q) and cache the results
 to use with future calculations.
 
 I noticed that eay does the BN_MONT_CTX_set() only once.  To me, that
 looks like an assumption that the modulus in the RSA structure will not
 be altered during the structure's lifetime.  Is that true?  I hope so.
 

Yes that's true.

 Another question - my understanding is that the SSL server will mostly
 be doing private key decryptions in RSA key exchange - correct?
 

For typical browser strong crypto ciphersuites (i.e. those using RSA
key exchange) that is correct. For RSA key exchange weak export
ciphersuites (also supported by browsers) and ephemeral ones using RSA
for authentication (not supported by many browsers yet) RSA signing also
occurs.

Steve.
-- 
Dr Stephen N. Henson.   http://www.drh-consultancy.demon.co.uk/
Personal Email: [EMAIL PROTECTED] 
Senior crypto engineer, Gemplus: http://www.gemplus.com/
Core developer of the   OpenSSL project: http://www.openssl.org/
Business Email: [EMAIL PROTECTED] PGP key: via homepage.
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: yack! the ca tool can't work with empty subject DNs

[Dr S N Henson]

Gunther Schadow wrote:
 
 Hi,
 
 regarding my yesterday's post to enable the apps x509 and req to work
 with empty subject DNs (as permitted, even suggested by PKIX for certs
 with non-human subjects), I found another problem that I'm going to do
 something about now. The ca tool depends on the subject DN when using
 the index.txt database [crypto/txt_db]. This is a problem. Please,
 I appreciate if someone would let me know if what I'm suggesting
 is a big mistake:
 
 I suggest defining a configuration file option index_on= where one
 can choose if indexing should use the hashed subject DN or some
 other id. I would recommend that indexing be by public key, namely
 subjectKeyIdentifier. The keyid is the one essential thing that's
 every cert has.
 
 I'll dive into this again, uh. Will find the dependency upon
 the txt_db code and hopefully I can hack this in with a few
 moderate changes.
 

Do you need the 'ca' tool to handle that? The 'x509' tool can do most
things that the 'ca' tool can but without the (allegedly) friendly
front end.

Steve.
-- 
Dr Stephen N. Henson.   http://www.drh-consultancy.demon.co.uk/
Personal Email: [EMAIL PROTECTED] 
Senior crypto engineer, Gemplus: http://www.gemplus.com/
Core developer of the   OpenSSL project: http://www.openssl.org/
Business Email: [EMAIL PROTECTED] PGP key: via homepage.

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: yack! the ca tool can't work with empty subject DNs

[Dr S N Henson]

Rich Salz wrote:
 
 
  Suggestions? Is there any interest in such changes at all?
 
 I think the CA program is proof of concept and not up to the quality
 of the rest of openssl.  Any improvement here would be good.

Yes ca.c is an example of how to write a CA and not a very good one at
that. It was never intended to be used as a production CA but that
hasn't stopped people using it for precisely that.

IMHO a better solution would be to write a friendly scripting language
version (possibly with a GUI interface) which would act as a front end
to x509, req et al. There are only a couple of facilities which ca
provides which the others can't (at present) do CRL generation and SPKAC
certification. Though its possible to generate a CRL in a scripting
language by generating a pseudo text index file and pointing ca at it.

Steve.
-- 
Dr Stephen N. Henson.   http://www.drh-consultancy.demon.co.uk/
Personal Email: [EMAIL PROTECTED] 
Senior crypto engineer, Gemplus: http://www.gemplus.com/
Core developer of the   OpenSSL project: http://www.openssl.org/
Business Email: [EMAIL PROTECTED] PGP key: via homepage.

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: How can I pass argument????

[Dr S N Henson]

 Blue wrote:
 
 
 Question??
 1 How can I pass argument (ex. country,Email,...) in one
 instruction
 2 I try find Example but few.Please suggest url fot Ex.
 

You need to create a file with the field information in it and pass that
using the -config command line option. Check out the 'prompt'
description and the examples in the req manual page.

Steve.
-- 
Dr Stephen N. Henson.   http://www.drh-consultancy.demon.co.uk/
Personal Email: [EMAIL PROTECTED] 
Senior crypto engineer, Celo Communications: http://www.celocom.com/
Core developer of the   OpenSSL project: http://www.openssl.org/
Business Email: [EMAIL PROTECTED] PGP key: via homepage.

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: NULL fields in RSA structure

[Dr S N Henson]

Michael Sierchio wrote:
 
 Ajay Nerurkar wrote:
 
  According to the doc the fields p, q, dmp1, dmq1 and iqmp
  in the RSA structure may be NULL in private keys but the
  function i2d_RSAPrivateKey() calls BN_num_bits() with each
  field of the argument RSA* a. And BN_num_bits() cannot handle
  a NULL argument. So, either BN_num_bits() or i2d_RSAPrivateKey()
  needs to check that it's not dealing with a NULL.
 
 Steve?

You called?

The format used is a PKCS#1 RSAPrivateKey structure for which all of the
fields are mandatory. What it should really do is to return an error if
any of them are NULL.

Unfortunately the i2d functions either don't return errors or the error
codes aren't checked. Its on my list of things to do in the ASN1
revision to have a standard where returning -1 is an error (since it
returns a length value 0 is a valid return code).

Steve.
-- 
Dr Stephen N. Henson.   http://www.drh-consultancy.demon.co.uk/
Personal Email: [EMAIL PROTECTED] 
Senior crypto engineer, Celo Communications: http://www.celocom.com/
Core developer of the   OpenSSL project: http://www.openssl.org/
Business Email: [EMAIL PROTECTED] PGP key: via homepage.

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: separate CA certs for certificates and CRLs

[Dr S N Henson]

Harald Koch wrote:
 
[pkix quote deleted]
 
 Any thoughts on how to go about adding support for separate CA
 certificates for certs and CRLs to the existing OpenSSL certificate
 verifier?
 

I've been meaning to look through the pkix CRL stuff to see how this lot
works in practice. The last time I looked I wasn't sure what (if
anything) restricted the CRL signing certificates path when compared to
the CA certificate. For example if you trust two root CAs A and B you
don't want B to be able to sign CRLs for A without some authorisation
from A (e.g. a CRL signing certificate chaining to A).

Steve.
-- 
Dr Stephen N. Henson.   http://www.drh-consultancy.demon.co.uk/
Personal Email: [EMAIL PROTECTED] 
Senior crypto engineer, Celo Communications: http://www.celocom.com/
Core developer of the   OpenSSL project: http://www.openssl.org/
Business Email: [EMAIL PROTECTED] PGP key: via homepage.

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: PEM_STRING_X509

[Dr S N Henson]

francoise lacambre wrote:
 
 In the file pem.h, you define  :
 #define PEM_STRING_X509_TRUSTED TRUSTED CERTIFICATE
 #define PEM_STRING_X509_REQ CERTIFICATE REQUEST
 
 In what refence document (RFC or ...) are defined these strings ?

The first is an OpenSSL invention and the second is sort of common usage
for certificate requests. I don't think any document defines the PEM
strings.

Steve.
-- 
Dr Stephen N. Henson.   http://www.drh-consultancy.demon.co.uk/
Personal Email: [EMAIL PROTECTED] 
Senior crypto engineer, Celo Communications: http://www.celocom.com/
Core developer of the   OpenSSL project: http://www.openssl.org/
Business Email: [EMAIL PROTECTED] PGP key: via homepage.

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: output format of PKCS7

[Dr S N Henson]

Wang, Kate wrote:
 
 Hi all,
 
 In my application, I called PKCS7_encrypt() to encrypt a document. When I
 call
 PEM_write_bio_PKCS7(out, p7) to write the encrypted document out to a file,
 the encrypted content always
 has
 --- BEGIN PKCS7 ---
 --- END PKCS7 ---
 
 wrapped arround it. And when I call PKCS7_decrypt(), it always need those
 headers there if the format is in PEM.
 
 Does openssl has another set of functions which can deals with BASE64
 encoded PKCS7 content without those headers?
 

You can use a base64 filter BIO and handle things that way. The S/MIME
code does this in its MIME parser.

Steve.
-- 
Dr Stephen N. Henson.   http://www.drh-consultancy.demon.co.uk/
Personal Email: [EMAIL PROTECTED] 
Senior crypto engineer, Celo Communications: http://www.celocom.com/
Core developer of the   OpenSSL project: http://www.openssl.org/
Business Email: [EMAIL PROTECTED] PGP key: via homepage.

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: openssl enc -d fixed in snapshot EXCEPT for aes (core dump)

[Dr S N Henson]

Richard Levitte - VMS Whacker wrote:
 
 From: Richard Chan [EMAIL PROTECTED]
 
 cshihpin Snapshot 20011002 has fixed the openssl enc -d problem
 cshihpin reported earlier. However with the aes algorithms
 cshihpin like aes-128-cbc etc it dumps core on exit (file is
 cshihpin decrypted correctly). Try it on the INSTALL.VMS file from
 cshihpin the distribution.
 cshihpin
 cshihpin gdb on the core file shows the segfault at CRYPTO_free () at
 cshihpin eval.c:41.
 
 eval.c?  Where did you find that file?
 
 Anyway, I tried aes-128-cbc and got a segmentation fault.  It looks
 like we've a buffer overrun somewhere...  Steve?
 

Should be fixed now. 

Steve.
-- 
Dr Stephen N. Henson.   http://www.drh-consultancy.demon.co.uk/
Personal Email: [EMAIL PROTECTED] 
Senior crypto engineer, Celo Communications: http://www.celocom.com/
Core developer of the   OpenSSL project: http://www.openssl.org/
Business Email: [EMAIL PROTECTED] PGP key: via homepage.

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: Simple openssl enc -d failing with 20011001 snapshot

[Dr S N Henson]

Richard Shih-Ping Chan wrote:
 
 openssl enc -d is failing with 20011001 snapshot.
 

Thanks for the report. I noticed that a couple of days ago. Its being
looked into.

Steve.
-- 
Dr Stephen N. Henson.   http://www.drh-consultancy.demon.co.uk/
Personal Email: [EMAIL PROTECTED] 
Senior crypto engineer, Celo Communications: http://www.celocom.com/
Core developer of the   OpenSSL project: http://www.openssl.org/
Business Email: [EMAIL PROTECTED] PGP key: via homepage.

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: Simple openssl enc -d failing with 20011001 snapshot

[Dr S N Henson]

Dr S N Henson wrote:
 
 Richard Shih-Ping Chan wrote:
 
  openssl enc -d is failing with 20011001 snapshot.
 
 
 Thanks for the report. I noticed that a couple of days ago. Its being
 looked into.
 

This should be fixed in the next snapshot.

Steve.
-- 
Dr Stephen N. Henson.   http://www.drh-consultancy.demon.co.uk/
Personal Email: [EMAIL PROTECTED] 
Senior crypto engineer, Celo Communications: http://www.celocom.com/
Core developer of the   OpenSSL project: http://www.openssl.org/
Business Email: [EMAIL PROTECTED] PGP key: via homepage.


__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: ssh2 key passphrase problems in 2.9.9 on Linux

[Dr S N Henson]

Phil Stracchino wrote:
 
 On Fri, Sep 28, 2001 at 11:00:25AM -0700, Phil Stracchino wrote:
  On Fri, Sep 28, 2001 at 06:21:26PM +0100, Dr S N Henson wrote:
   Read the bit in the FAQ about adding an ERR_print_errors_fp() call then
   see what it says is the cause.
 
 I tried using ERR_print_errors_fp() in the appropriate location and it
 reported nothing.  I therefore took a slightly different tack.  I changed
 the error detection code in key_load_private_pem() in authfile.c from
 this:
 
 pk = PEM_read_PrivateKey(fp, NULL, NULL, (char *)passphrase);
 if (pk == NULL) {
 debug(PEM_read_PrivateKey failed);
 (void)ERR_get_error();
 } else if (pk-type == EVP_PKEY_RSA  
 
 to this:
 
 pk = PEM_read_PrivateKey(fp, NULL, NULL, (char *)passphrase);
 if (pk == NULL) {
 error(PEM_read_PrivateKey failed);
 while (ERR_peek_error())
   error(PEM error %ld: %s,
 ERR_peek_error(),
 ERR_error_string(ERR_get_error(), NULL));
 } else if (pk-type == EVP_PKEY_RSA  
 
 Right up to the point at which that PEM_read_PrivateKey() call is
 executed, everything appears to be working perfectly.  At the moment of
 making this call:
 
   filename is /root/.ssh/id_dsa
   passphrase contains the correct password
   fp is valid, and _IO_read_base points at the string:
 -BEGIN DSA PRIVATE KEY-\nProc-Type: 4,ENCRYPTED\n
  DEK-Info: DES-EDE3-CBC,data
 
 The passphrase supplied is known to be correct, and successfully unlocks
 this keyfile on a Solaris 8 machine which is running the same version of
 both OpenSSH and OpenSSL.  Nevertheless, PEM_read_PrivateKey returns NULL,
 but according to ERR_peek_error(), no error has occurred.  I am unable to
 trace into the PEM_read_PrivateKey() call using gdb.
 

Strange, it should produce an error of some sort. See what happens if
you remove the pass phrase on the private key (using the rsa utility)
and also see if you get an error when you supply an incorrect pass
phrase.

Steve.
-- 
Dr Stephen N. Henson.   http://www.drh-consultancy.demon.co.uk/
Personal Email: [EMAIL PROTECTED] 
Senior crypto engineer, Celo Communications: http://www.celocom.com/
Core developer of the   OpenSSL project: http://www.openssl.org/
Business Email: [EMAIL PROTECTED] PGP key: via homepage.

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: ssh2 key passphrase problems in 2.9.9 on Linux

[Dr S N Henson]

Phil Stracchino wrote:
 
 On Thu, Sep 27, 2001 at 02:26:14PM -0700, Phil Stracchino wrote:
  I've just compiled and installed openssh-2.9.9p2 (compiled against
  openssl-0.9.6b using gcc-3.0.0) on a Slackware 7-based Linux machine
  (kernel 2.4.6ac2).  The previously installed version was 2.9p2, compiled
  against openssl-0.9.6a, also with gcc-3.0.0, but with a different build of
  gcc-3.0.0.
 
  Everything seems to work fine except for one problem:  passphrase matching
  for ssh2 keys *always* fails.  I've run ssh-add under gdb several times
  trying to see what's going wrong, so far without learning anything
  particularly enlightening.
 
 I have finally managed to isolate this down to the following:  For SSH2
 DSA and RSA keys, the OpenSSL PEM_read_PrivateKey() macro, called from
 authfile.c line 448:
 
 pk = PEM_read_PrivateKey(fp, NULL, NULL, (char *)passphrase);
 
 is consistently failing and always returns NULL, whereas it should be
 returning a EVP_PKEY struct with pk-type containing either EVP_PKEY_RSA
 or EVP_PKEY_DSA.  As far as I can see from the OpenSSL code, this means
 that BIO_new(BIO_s_file()) has to be returning NULL, but that's as far as
 I can figure it out; the internals of OpenSSL are utterly impenetrable to
 me.
 
 Any suggestions, anyone?  I think I've taken this problem about as far as
 I can diagnose it myself.
 

Yes, read the FAQ. If that doesn't solve your problem it will at least
tell you how to give more complete error information.

Steve.
-- 
Dr Stephen N. Henson.   http://www.drh-consultancy.demon.co.uk/
Personal Email: [EMAIL PROTECTED] 
Senior crypto engineer, Celo Communications: http://www.celocom.com/
Core developer of the   OpenSSL project: http://www.openssl.org/
Business Email: [EMAIL PROTECTED] PGP key: via homepage.


__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: ssh2 key passphrase problems in 2.9.9 on Linux

[Dr S N Henson]

Phil Stracchino wrote:
 
 On Fri, Sep 28, 2001 at 11:21:43PM +0100, Dr S N Henson wrote:
  Strange, it should produce an error of some sort. See what happens if
  you remove the pass phrase on the private key (using the rsa utility)
  and also see if you get an error when you supply an incorrect pass
  phrase.
 
 babylon5:root:~/.ssh:11 # openssl rsa -passin stdin -in id_rsa -out rsa_nopass
 
 read RSA key
 unable to load key
 babylon5:root:~/.ssh:12 # openssl dsa -passin stdin -in id_dsa -out dsa_nopass
 
 read DSA key
 unable to load Key
 babylon5:root:~/.ssh:13 # ssh-add id_dsa
 PEM_read_PrivateKey failed
 Enter passphrase for id_dsa: 
 PEM_read_PrivateKey failed
 Bad passphrase, try again: foo
 PEM_read_PrivateKey failed
 Bad passphrase, try again: bar
 PEM_read_PrivateKey failed
 Bad passphrase, try again:
 babylon5:root:~/.ssh:14 #
 
 It appears to me as though what's happening is that it's not encountering
 any execution errors, but it's somehow failing to decrypt the key with the
 correct passphrase and treating it as just another incorrect passphrase.
 

Well if this is the version that you modified to print out error
messages then there's another problem. I suggest you change that part
you mentioned earlier to:

  pk = PEM_read_PrivateKey(fp, NULL, NULL, (char *)passphrase);
if (pk == NULL) {
error(PEM_read_PrivateKey failed);
ERR_print_errors_fp(stderr);
} else if (pk-type == EVP_PKEY_RSA  

then do the tests before. Also add another ERR_print_errors_fp(stderr)
where it prints out unable to load key.

 As an experiment, I tried generating a test key using openssl rather than
 ssh-keygen, using the following command:
 
   openssl genrsa -rand /dev/random:random_seed -F4 128
 
 This command has so far run for ten minutes without producing any output,
 generating any visible system activity, or consuming any CPU time as
 reported by top.  (My intention was to verify, one step at a time, that I
 could create an encrypted key directly using openssl and then remove the
 passphrase from it.)  Am I using genrsa incorrectly, or is this as bad a
 sign as I think it is?
 

Yes that is wrong. It will read until EOF which will never happen with
/dev/random. You shouldn't need a -rand argument under Linux anyway.

This is starting to look like a compiler bug.

Steve.
-- 
Dr Stephen N. Henson.   http://www.drh-consultancy.demon.co.uk/
Personal Email: [EMAIL PROTECTED] 
Senior crypto engineer, Celo Communications: http://www.celocom.com/
Core developer of the   OpenSSL project: http://www.openssl.org/
Business Email: [EMAIL PROTECTED] PGP key: via homepage.

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: Incomplete implementation of ASN1 GENERALIZEDTIME ?

[Dr S N Henson]

[EMAIL PROTECTED] wrote:
 
 
 And are also mentioned the DER encoding rules of X.690 for the same case.
 Therefore we need to a little patch for
 the function ASN1_GENERALIZEDTIME_check in order to be able
 to accept time as indicated in the above example
 

I've just checked in a fix to the development version. Let me know of
any problems.

Steve.
-- 
Dr Stephen N. Henson.   http://www.drh-consultancy.demon.co.uk/
Personal Email: [EMAIL PROTECTED] 
Senior crypto engineer, Celo Communications: http://www.celocom.com/
Core developer of the   OpenSSL project: http://www.openssl.org/
Business Email: [EMAIL PROTECTED] PGP key: via homepage.
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: Error in v3_purp.c

[Dr S N Henson]

Diego R. Lopez wrote:
 
 Hi,
 
 We have found what seems an error in the X509_check_issued() function
 inside crypto/x509v3/v3_purp.c
 At the end of the checks the routine makes for deciding whether a certain
 certificate issued a second one, there is a comparison between
 the name found inside the Authority Key Identifier of the candidate
 subject certificate and the ISSUER NAME of the candidate issuer certificate.
 Since this check always fails, the certificate chain procedure that
 uses this routine is always aborted whenever a candidate subject certificate
 with Authority Key Identifier and a candidate issuer certificate that is
 not self-signed are tested. This means that the certificate verification
 procedures always fail in that case.
 
 We think that the correct comparison would be between the name found inside
 the Authority Key Identifier of the candidate subject certificate and the
 SUBJECT NAME of the candidate issuer.
 

OpenSSLs behaviour is correct.

A standard property of certificates is that the issuer name and serial
number must be unique.

The Authority Key Identifier extension is used as a means of uniquely
identifying the issuing authority. One way it does this is to use the
issuer name and serial number of the issuing authority.

The subject name of the issuer certificate is already available in the
issuer name of the subject certificate. If merely used this then it
would be duplicating information.

Steve.
-- 
Dr Stephen N. Henson.   http://www.drh-consultancy.demon.co.uk/
Personal Email: [EMAIL PROTECTED] 
Senior crypto engineer, Celo Communications: http://www.celocom.com/
Core developer of the   OpenSSL project: http://www.openssl.org/
Business Email: [EMAIL PROTECTED] PGP key: via homepage.


__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: Error in v3_purp.c

[Dr S N Henson]

Diego R. Lopez wrote:
 
 [EMAIL PROTECTED] said:
  A standard property of certificates is that the issuer name and serial
  number must be unique.
 
  The Authority Key Identifier extension is used as a means of uniquely
  identifying the issuing authority. One way it does this is to use the
  issuer name and serial number of the issuing authority.
 
  The subject name of the issuer certificate is already available in the
  issuer name of the subject certificate. If merely used this then it
  would be duplicating information.
 
 I'm sorry but I cannot get your point. I agree on that the issuer name plus
 serial number must be unique. I also agree on that the subject name of the
 issuer certificate is already in the issuer name of the subject
 certificate and there is no need to gert it again.
 
 What I cannot get is why the name inside the Authority key identifier of
 the candidate subject must match the issuer of the issuer certificate.

Because it is used as a way of uniquely identifying the issuing
authority, in cases where the candidate issuing authorities have the
same subject name.

If it contained the subject name of the issuing certificate then it
would just contain a subject name and serial number which need not be
unique.

To give a quick example:

CA1:

subject CN=sub CA
issuer  CN=Root CA number 1
serial  01

CA2:

subject CN=sub CA
issuer  CN=Root CA number 2
serial  01

is permitted. If we now have a user certificate:

user:

subject CN=my user
issuer  CN=sub CA
serial  02

Now the authority keyid in this user certificate might contain:

issuer = Root CA number 1 
serial = 01

This uniquely identifies the issuing authoritys certificate.

If instead it had the subject name of its issuing certificate it would
have:

issuer = sub CA 
serial = 01

which is identical for both candidate potential CAs.

 The certificates we are trying to verify are also generated using
 openSSL and they contain (in the Authority key identifier) the name
 of their issuer (not the one of the issuer for their issuer's cert as
 you seem to suggest).

Which version of OpenSSL was used to generate these certificates? 

Current versions certainly use the issuing authorities issuer name and
serial number. In v3_akey.c:

cert = ctx-issuer_cert;

...

if((issuer  !ikeyid) || (issuer == 2)) {
isname = X509_NAME_dup(X509_get_issuer_name(cert));
serial = M_ASN1_INTEGER_dup(X509_get_serialNumber(cert));
if(!isname || !serial) {

X509V3err(X509V3_F_V2I_AUTHORITY_KEYID,X509V3_R_UNABLE_TO_GET_ISSUER_DETAILS);
goto err;
}
}

I'm not sure whether its possible to get past the checks in the OpenSSL
utilities somehow and pass an invalid issuing certificate and get an
incorrect value in the extension that way.

 So there seems to be an error either in the extension generation functions
 (I don`t think so) or in the verification functions.
 

Although I don't recall a bug in this area I'll check to see if any
older versions of OpenSSL wrongly used the subject name of the issuer
certificate. 

 Please, would you have a look on the files and cert paths I attached to
 my previous message and tell me why (without the patch I propose) the
 verification fails?
 

OK, I'll have a look at them.

Steve.
-- 
Dr Stephen N. Henson.   http://www.drh-consultancy.demon.co.uk/
Personal Email: [EMAIL PROTECTED] 
Senior crypto engineer, Celo Communications: http://www.celocom.com/
Core developer of the   OpenSSL project: http://www.openssl.org/
Business Email: [EMAIL PROTECTED] PGP key: via homepage.

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: Error in v3_purp.c

[Dr S N Henson]

Diego R. Lopez wrote:
 
 
 Please, would you have a look on the files and cert paths I attached to
 my previous message and tell me why (without the patch I propose) the
 verification fails?
 

At least one problem is:

euroPKIBYeuroPKI.pem:

subject= /O=EuroPKI/CN=EuroPKI Root Certification Authority
issuer= /O=EuroPKI/CN=EuroPKI Root Certification Authority
serial=00

irisPCABYeuroPKISerial0.pem:

subject=
[EMAIL PROTECTED]
issuer= /O=EuroPKI/CN=EuroPKI Root Certification Authority
serial=00

As you can see they both have the same issuer name and serial number.

Steve.
-- 
Dr Stephen N. Henson.   http://www.drh-consultancy.demon.co.uk/
Personal Email: [EMAIL PROTECTED] 
Senior crypto engineer, Celo Communications: http://www.celocom.com/
Core developer of the   OpenSSL project: http://www.openssl.org/
Business Email: [EMAIL PROTECTED] PGP key: via homepage.

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: Incomplete implementation of ASN1 GENERALIZEDTIME ?

[Dr S N Henson]

[EMAIL PROTECTED] wrote:
 
 Hello, I was checking the implementation of Generalized Time in OpenSSL
 and seems to me that isn't not compliant with the X.680 specification.
 Indeed according to the specification it's possible to
 have fractional seconds. The function ASN1_GENERALIZEDTIME_check
 enforces checkings that admits (if I understand correctly) the presence
 of the
 following characters: 0..9,Z,+,-.  But for an implementation
 fully compliant with the standard the characters . or , maybe present
 in order to have fractional seconds.
 

OpenSSL doesn't fully support BER encoded GeneralizedTime however for
many of the purposes which it is used in OpenSSL (e.g. in certificates)
the full form isn't allowed. For example from RFC2259 4.1.2.5.2:

For the purposes of this profile, GeneralizedTime values MUST be
expressed Greenwich Mean Time (Zulu) and MUST include seconds (i.e.,
times are MMDDHHMMSSZ), even where the number of seconds is zero.
GeneralizedTime values MUST NOT include fractional seconds.

Steve.
-- 
Dr Stephen N. Henson.   http://www.drh-consultancy.demon.co.uk/
Personal Email: [EMAIL PROTECTED] 
Senior crypto engineer, Celo Communications: http://www.celocom.com/
Core developer of the   OpenSSL project: http://www.openssl.org/
Business Email: [EMAIL PROTECTED] PGP key: via homepage.

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: Incomplete implementation of ASN1 GENERALIZEDTIME ?

[Dr S N Henson]

[EMAIL PROTECTED] wrote:
 
 
 Thank you for your answer.
 Yes of course you're right for RFC 2459, but in the RFC 3161 that defines
 the
 Time Stamp Protocol:
The ASN.1 GeneralizedTime syntax can include fraction-of-second
details.  Such syntax, without the restrictions from [RFC 2459]
Section 4.1.2.5.2, where GeneralizedTime is limited to represent the
time with a granularity of one second, may be used here.
 
GeneralizedTime values MUST include seconds.  However, when there is
no need to have a precision better than the second, then
GeneralizedTime with a precision limited to one second SHOULD be used
(as in [RFC 2459]).
 
The syntax is: MMDDhhmmss[.s...]Z
Example: 19990609001326.34352Z
 
 And are also mentioned the DER encoding rules of X.690 for the same case.
 Therefore we need to a little patch for
 the function ASN1_GENERALIZEDTIME_check in order to be able
 to accept time as indicated in the above example
 

Fair enough. I'll look into fixing it.

Steve.
-- 
Dr Stephen N. Henson.   http://www.drh-consultancy.demon.co.uk/
Personal Email: [EMAIL PROTECTED] 
Senior crypto engineer, Celo Communications: http://www.celocom.com/
Core developer of the   OpenSSL project: http://www.openssl.org/
Business Email: [EMAIL PROTECTED] PGP key: via homepage.

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: Error creating Certificate

[Dr S N Henson]

[EMAIL PROTECTED] wrote:
 
 Hi,
 
 After I created a RSA key, I want to create a SSL Certificate with the following
 command:
 
 openssl.exe req -new -key pcniws1.key -out pcniws1.csr
 
 I get the following error message:
 
 Using configuration from /usr/local/ssl/openssl.cnf
 Unable to load config info
 Enter PEM pass phrase:
 unable to find 'distinguished_name' in config
 problems making Certificate Request

Read the FAQ.

Steve.
-- 
Dr Stephen N. Henson.   http://www.drh-consultancy.demon.co.uk/
Personal Email: [EMAIL PROTECTED] 
Senior crypto engineer, Celo Communications: http://www.celocom.com/
Core developer of the   OpenSSL project: http://www.openssl.org/
Business Email: [EMAIL PROTECTED] PGP key: via homepage.
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: Is Diffie - Hellman used anywhere?

[Dr S N Henson]

Michael Sierchio wrote:
 
 Dr S N Henson wrote:
 
  Then we'd obviously need an alternative parameter generation algorithm.
  The X9.42 version (also in RFC2631) would be usable (though better ones
  exist) except no test vectors exist which aren't obviously broken. I've
  never found anyone else who's implemented the X9.42 parameter algorithm
  other than the restricted case which is FIPS 186-1 compatible (i.e.
  q=160 bits).
 
 I haven't implemented it,  but this is also covered in RFC 2875
 

Well if someone ever does implement it and it agrees with my test
version then I'll be able to include it in OpenSSL. If that doesn't
happen there's are various other techniques which could be used or the
X9.42 seed data could be omitted since it isn't considered reliable.

  DH-POP is indeed a problem. There's a standard again but its a bit messy
  to implement in that it forces handling of DH certificate requests as a
  special case.
 
 Right, because the CA will need a cert dedicated to the key agreement.
 Certs should be signed with RSA,  it just makes verification a lot
 easier.
 

Yes thats one problem: you need to have a command line option to create
the CA cert without signing a corresponding request. Also the algorithms
for DH POP depend on various request fields in the request and need
additional DH specific steps.

Steve.
-- 
Dr Stephen N. Henson.   http://www.drh-consultancy.demon.co.uk/
Personal Email: [EMAIL PROTECTED] 
Senior crypto engineer, Celo Communications: http://www.celocom.com/
Core developer of the   OpenSSL project: http://www.openssl.org/
Business Email: [EMAIL PROTECTED] PGP key: via homepage.

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: Is Diffie - Hellman used anywhere?

[Dr S N Henson]

Michael Sierchio wrote:
 
 Dr S N Henson wrote:
 
  Michael Sierchio wrote:
  
   Dr S N Henson wrote:
  
DH certificates aren't currently supported: hardly anything uses them.
The DH algorithm itself is used by (among other things) SSL and TLS.
  
   Mobile IP does.  I suggest again that, since a DH profile exists,
   it should be supported in OpenSSL.
 
  Any sample certificates available?
 
 Wouldn't you rather have the ASN.1 profile?

I'd rather have both. If past experience is anything to go by the ASN.1
profile will show what the certificates should be like and the examples
will show what they really are like :-)

Steve.
-- 
Dr Stephen N. Henson.   http://www.drh-consultancy.demon.co.uk/
Personal Email: [EMAIL PROTECTED] 
Senior crypto engineer, Celo Communications: http://www.celocom.com/
Core developer of the   OpenSSL project: http://www.openssl.org/
Business Email: [EMAIL PROTECTED] PGP key: via homepage.


__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]