ssleay.txt

passed hash table.  These numbers are all kept in the lhash structure.

void lh_stats(
LHASH *lh,
FILE *out);
	This function prints out statistics on the size of the hash table,
	how many entries are in it, and the number and result of calls to
	the routines in this library.

void lh_node_stats(
LHASH *lh,
FILE *out);
	For each 'bucket' in the hash table, the number of entries is
	printed.
	
void lh_node_usage_stats(
LHASH *lh,
FILE *out);
	This function prints out a short summary of the state of the hash
	table.  It prints what I call the 'load' and the 'actual load'.
	The load is the average number of data items per 'bucket' in the
	hash table.  The 'actual load' is the average number of items per
	'bucket', but only for buckets which contain entries.  So the
	'actual load' is the average number of searches that will need to
	find an item in the hash table, while the 'load' is the average number
	that will be done to record a miss.

==== md2.doc ========================================================

The MD2 library.
MD2 is a message digest algorithm that can be used to condense an arbitrary
length message down to a 16 byte hash.  The functions all need to be passed
a MD2_CTX which is used to hold the MD2 context during multiple MD2_Update()
function calls.  The normal method of use for this library is as follows

MD2_Init(...);
MD2_Update(...);
...
MD2_Update(...);
MD2_Final(...);

This library requires the inclusion of 'md2.h'.

The main negative about MD2 is that it is slow, especially when compared
to MD5.

The functions are as follows:

void MD2_Init(
MD2_CTX *c);
	This function needs to be called to initiate a MD2_CTX structure for
	use.
	
void MD2_Update(
MD2_CTX *c;
unsigned char *data;
unsigned long len);
	This updates the message digest context being generated with 'len'
	bytes from the 'data' pointer.  The number of bytes can be any
	length.

void MD2_Final(
unsigned char *md;
MD2_CTX *c;
	This function is called when a message digest of the data digested
	with MD2_Update() is wanted.  The message digest is put in the 'md'
	array and is MD2_DIGEST_LENGTH (16) bytes long.

unsigned char *MD2(
unsigned long n;
unsigned char *d;
unsigned char *md;
	This function performs a MD2_Init(), followed by a MD2_Update()
	followed by a MD2_Final() (using a local MD2_CTX).
	The resulting digest is put into 'md' if it is not NULL.
	Regardless of the value of 'md', the message
	digest is returned from the function.  If 'md' was NULL, the message
	digest returned is being stored in a static structure.

==== md5.doc ========================================================

The MD5 library.
MD5 is a message digest algorithm that can be used to condense an arbitrary
length message down to a 16 byte hash.  The functions all need to be passed
a MD5_CTX which is used to hold the MD5 context during multiple MD5_Update()
function calls.  This library also contains random number routines that are
based on MD5

The normal method of use for this library is as follows

MD5_Init(...);
MD5_Update(...);
...
MD5_Update(...);
MD5_Final(...);

This library requires the inclusion of 'md5.h'.

The functions are as follows:

void MD5_Init(
MD5_CTX *c);
	This function needs to be called to initiate a MD5_CTX structure for
	use.
	
void MD5_Update(
MD5_CTX *c;
unsigned char *data;
unsigned long len);
	This updates the message digest context being generated with 'len'
	bytes from the 'data' pointer.  The number of bytes can be any
	length.

void MD5_Final(
unsigned char *md;
MD5_CTX *c;
	This function is called when a message digest of the data digested
	with MD5_Update() is wanted.  The message digest is put in the 'md'
	array and is MD5_DIGEST_LENGTH (16) bytes long.

unsigned char *MD5(
unsigned char *d;
unsigned long n;
unsigned char *md;
	This function performs a MD5_Init(), followed by a MD5_Update()
	followed by a MD5_Final() (using a local MD5_CTX).
	The resulting digest is put into 'md' if it is not NULL.
	Regardless of the value of 'md', the message
	digest is returned from the function.  If 'md' was NULL, the message
	digest returned is being stored in a static structure.


==== memory.doc ========================================================

In the interests of debugging SSLeay, there is an option to compile
using some simple memory leak checking.

All malloc(), free() and realloc() calls in SSLeay now go via
Malloc(), Free() and Realloc() (except those in crypto/lhash).

If CRYPTO_MDEBUG is defined, these calls are #defined to
CRYPTO_malloc(), CRYPTO_free() and CRYPTO_realloc().
If it is not defined, they are #defined to malloc(), free() and realloc().

the CRYPTO_malloc() routines by default just call the underlying library
functons.

If CRYPTO_mem_ctrl(CRYPTO_MEM_CHECK_ON) is called, memory leak detection is
turned on.  CRYPTO_mem_ctrl(CRYPTO_MEM_CHECK_OFF) turns it off.

When turned on, each Malloc() or Realloc() call is recored along with the file
and line number from where the call was made.   (This is done using the
lhash library which always uses normal system malloc(3) routines).

void CRYPTO_mem_leaks(BIO *b);
void CRYPTO_mem_leaks_fp(FILE *fp);
These both print out the list of memory that has not been free()ed.
This will probably be rather hard to read, but if you look for the 'top level'
structure allocation, this will often give an idea as to what is not being
free()ed.  I don't expect people to use this stuff normally.

==== ca.1 ========================================================

From eay@orb.mincom.oz.au Thu Dec 28 23:56:45 1995
Received: by orb.mincom.oz.au id AA07374
  (5.65c/IDA-1.4.4 for eay); Thu, 28 Dec 1995 13:56:45 +1000
Date: Thu, 28 Dec 1995 13:56:45 +1000 (EST)
From: Eric Young <eay@mincom.oz.au>
X-Sender: eay@orb
To: sameer <sameer@c2.org>
Cc: ssleay@mincom.oz.au
Subject: Re: 'ca'
In-Reply-To: <199512230440.UAA23410@infinity.c2.org>
Message-Id: <Pine.SOL.3.91.951228133525.7269A-100000@orb>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Status: RO
X-Status: 

On Fri, 22 Dec 1995, sameer wrote:
> 	I could use documentation on 'ca'. Thanks.

Very quickly.
The ca program uses the ssleay.conf file for most of its configuration

./ca -help

 -verbose        - Talk alot while doing things
 -config file    - A config file. If you don't want to use the
		   default config file
 -name arg       - The particular CA definition to use
	In the config file, the section to use for parameters.  This lets 
	multiple setups to be contained in the one file.  By default, the 
	default_ca variable is looked up in the [ ca ] section.  So in the 
	shipped ssleay.conf, the CA definition used is CA_default.  It could be 
	any other name.
 -gencrl days    - Generate a new CRL, days is when the next CRL is due
	This will generate a new certificate revocion list.
 -days arg       - number of days to certify the certificate for
	When certifiying certificates, this is the number of days to use.
 -md arg         - md to use, one of md2, md5, sha or sha1
 -policy arg     - The CA 'policy' to support
	I'll describe this later, but there are 2 policies definied in the 
	shipped ssleay.conf
 -keyfile arg    - PEM RSA private key file
 -key arg        - key to decode the RSA private key if it is encrypted
	since we need to keep the CA's RSA key encrypted
 -cert           - The CA certificate
 -in file        - The input PEM encoded certificate request(s)
 -out file       - Where to put the output file(s)
 -outdir dir     - Where to put output certificates
	The -out options concatinates all the output certificied
	certificates to one file, -outdir puts them in a directory,
	named by serial number.
 -infiles ....   - The last argument, requests to process
	The certificate requests to process, -in is the same.

Just about all the above have default values defined in ssleay.conf.

The key variables in ssleay.conf are (for the pariticular '-name' being 
used, in the default, it is CA_default).

dir is where all the CA database stuff is kept.
certs is where all the previously issued certificates are kept.
The database is a simple text database containing the following tab separated 
fields.
status: a value of 'R' - revoked, 'E' -expired or 'V' valid.
issued date:  When the certificate was certified.
revoked date:  When it was revoked, blank if not revoked.
serial number:  The certificate serial number.
certificate:	Where the certificate is located.
CN:	The name of the certificate.

The demo file has quite a few made up values it it.  The last 2 were 
added by the ca program and are acurate.
The CA program does not update the 'certificate' file correctly right now.
The serial field should be unique as should the CN/status combination.
The ca program checks these at startup.  What still needs to be 
wrtten is a program to 'regenerate' the data base file from the issued 
certificate list (and a CRL list).

Back to the CA_default variables.

Most of the variables are commented.

policy is the default policy.

Ok for policies, they define the order and which fields must be present 
in the certificate request and what gets filled in.

So a value of
countryName             = match
means that the country name must match the CA certificate.
organizationalUnitName  = optional
The org.Unit,Name does not have to be present and
commonName              = supplied
commonName must be supplied in the certificate request.

For the 'policy_match' polocy, the order of the attributes in the 
generated certiticate would be
countryName
stateOrProvinceName
organizationName
organizationalUnitName
commonName
emailAddress

Have a play, it sort of makes sense.  If you think about how the persona 
requests operate, it is similar to the 'policy_match' policy and the
'policy_anything' is similar to what versign is doing.

I hope this helps a bit.  Some backend scripts are definitly needed to 
update the database and to make certificate revocion easy.  All 
certificates issued should also be kept forever (or until they expire?)

hope this helps
eric (who has to run off an buy some cheap knee pads for the caving in 4 
days time :-)

--
Eric Young                  | Signature removed since it was generating
AARNet: eay@mincom.oz.au    | more followups than the message contents :-)


==== ms3-ca.doc ========================================================

Date: Mon, 9 Jun 97 08:00:33 +0200
From: Holger.Reif@PrakInf.TU-Ilmenau.DE (Holger Reif)
Subject: ms3-ca.doc
Organization: TU Ilmenau, Fak. IA, FG Telematik
Content-Length: 14575
Status: RO
X-Status: 

Loading client certs into MSIE 3.01
===================================

This document contains all the information necessary to successfully set up 
some scripts to issue client certs to Microsoft Internet Explorer. It 
includes the required knowledge about the model MSIE uses for client 
certification and includes complete sample scripts ready to play with. The 
scripts were tested against a modified ca program of SSLeay 0.6.6 and should 
work with the regular ca program that comes with version 0.8.0. I haven't 
tested against MSIE 4.0

You can use the information contained in this document in either way you 
want. However if you feel it saved you a lot of time I ask you to be as fair 
as to mention my name: Holger Reif <reif@prakinf.tu-ilmenau.de>.

1.) The model used by MSIE
--------------------------

The Internet Explorer doesn't come with a embedded engine for installing 
client certs like Netscape's Navigator. It rather uses the CryptoAPI (CAPI) 
defined by Microsoft. CAPI comes with WindowsNT 4.0 or is installed together 
with Internet Explorer since 3.01. The advantage of this approach is a higher 
flexibility because the certificates in the (per user) system open 
certificate store may be used by other applications as well. The drawback 
however is that you need to do a bit more work to get a client cert issued.

CAPI defines functions which will handle basic cryptographic work, eg. 
generating keys, encrypting some data, signing text or building a certificate 
request. The procedure is as follows: A CAPI function generates you a key 
pair and saves it into the certificate store. After that one builds a 
Distinguished Name. Together with that key pair another CAPI function forms a 
PKCS#10 request which you somehow need to submit to a CA. Finally the issued 
cert is given to a yet another CAPI function which saves it into the 
certificate store.

The certificate store with the user's keys and certs is in the registry. You 
will find it under HKEY_CURRENT_USER/Software/Microsoft/Cryptography/ (I 
leave it to you as a little exercise to figure out what all the entries mean 
;-). Note that the keys are protected only with the user's usual Windows 
login password.

2.) The practical usage
-----------------------

Unfortunatly since CAPI is a system API you can't access its functions from 
HTML code directly. For this purpose Microsoft provides a wrapper called 
certenr3.dll. This DLL accesses the CAPI functions and provides an interface 
usable from Visual Basic Script. One needs to install that library on the 
computer which wants to have client cert. The easiest way is to load it as an 
ActiveX control (certenr3.dll is properly authenticode signed by MS ;-). If 
you have ever enrolled e cert request at a CA you will have installed it.

At time of writing certenr3.dll is contained in 
http://www.microsoft.com/workshop/prog/security/csa/certenr3.exe. It comes 
with an README file which explains the available functions. It is labeled 
beta but every CA seems to use it anyway. The license.txt allows you the 
usage for your own purposes (as far as I understood) and a somehow limited 
distribution. 

The two functions of main interest are GenerateKeyPair and AcceptCredentials. 
For complete explanation of all possible parameters see the README file. Here 
are only minimal required parameters and their values.

GenerateKeyPair(sessionID, FASLE, szName, 0, "ClientAuth", TRUE, FALSE, 1)
- sessionID is a (locally to that computer) unique string to correlate the 
generated key pair with a cert installed later.
- szName is the DN of the form "C=DE; S=Thueringen; L=Ilmenau; CN=Holger 
Reif; 1.2.840.113549.1.9.1=reif@prakinf.tu-ilmenau.de". Note that S is the 
abreviation for StateOrProvince. The recognized abreviation include CN, O, C, 
OU, G, I, L, S, T. If the abreviation is unknown (eg. for PKCS#9 email addr) 
you need to use the full object identifier. The starting point for searching 
them could be crypto/objects.h since all OIDs know to SSLeay are listed 
there.
- note: the possible ninth parameter which should give a default name to the 
certificate storage location doesn't seem to work. Changes to the constant 
values in the call above doesn't seem to make sense. You can't generate 
PKCS#10 extensions with that function.

The result of GenerateKeyPair is the base64 encoded PKCS#10 request. However 
it has a little strange format that SSLeay doesn't accept. (BTW I feel the 
decision of rejecting that format as standard conforming.) It looks like 
follows:
	1st line with 76 chars
	2nd line with 76 chars
	...
	(n-2)th line with 76 chars
	(n-1)th line contains a multiple of 4 chars less then 76 (possible 
empty)
	(n)th line has zero or 4 chars (then with 1 or 2 equal signs - the 
		original text's lenght wasn'T a multiple of 3) 
	The line separator has two chars: 0x0d 0x0a

AcceptCredentials(sessionID, credentials, 0, FALSE)
- sessionID needs to be the same as while generating the key pair
- credentials is the base64 encoded PKCS#7 object containing the cert. 

CRL's and CA certs are not required simply just the client cert. (It seems to 
me that both are not even checked somehow.) The only format of the base64 
encoded object I succesfully used was all characters in a very long string 
without line feeds or carriage returns. (Hey, it doesn't matter, only a 
computer reads it!)

The result should be S_OK. For error handling see the example that comes with 
certenr3.dll.

A note about ASN.1 character encodings. certenr3.dll seems to know only about 
2 of them: UniversalString and PrintableString. First it is definitely wrong 
for an email address which is IA5STRING (checked by ssleay's ca). Second 
unfortunately MSIE (at least until version 3.02) can't handle UniversalString 
correctly - they just blow up you cert store! Therefore ssleay's ca (starting 
from version 0.8.0) tries to convert the encodings automatically to IA5STRING 
or TeletexString. The beef is it will work only for the latin-1 (western) 
charset. Microsoft still has to do abit of homework...

3.) An example
--------------

At least you need two steps: generating the key & request and then installing 
the certificate. A real world CA would have some more steps involved, eg. 
accepting some license. Note that both scripts shown below are just 
experimental state without any warrenty!

First how to generate a request. Note that we can't use a static page because 
of the sessionID. I generate it from system time plus pid and hope it is 
unique enough. Your are free to feed it through md5 to get more impressive 
ID's ;-) Then the intended text is read in with sed which inserts the 
sessionID. 

-----BEGIN ms-enroll.cgi-----
#!/bin/sh
SESSION_ID=`date '+%y%m%d%H%M%S'`$$
echo Content-type: text/html
echo
sed s/template_for_sessId/$SESSION_ID/ <<EOF
<HTML><HEAD>
<TITLE>Certificate Enrollment Test Page</TITLE>
</HEAD><BODY>

<OBJECT
    classid="clsid:33BEC9E0-F78F-11cf-B782-00C04FD7BF43"
    codebase=certenr3.dll
    id=certHelper
    >
</OBJECT>

<CENTER>
<H2>enrollment for a personal cert</H2>
<BR><HR WIDTH=50%><BR><P>
<FORM NAME="MSIE_Enrollment" ACTION="ms-gencert.cgi" ENCTYPE=x-www-form-
encoded METHOD=POST>
<TABLE>
    <TR><TD>Country</TD><TD><INPUT NAME="Country" VALUE=""></TD></TR>
    <TR><TD>State</TD><TD><INPUT NAME="StateOrProvince" VALUE=""></TD></TR>
    <TR><TD>Location</TD><TD><INPUT NAME="Location" VALUE=""></TD></TR>
    <TR><TD>Organization</TD><TD><INPUT NAME="Organization" 
VALUE=""></TD></TR>
    <TR><TD>Organizational Unit</TD>
        <TD><INPUT NAME="OrganizationalUnit" VALUE=""></TD></TR>
    <TR><TD>Name</TD><TD><INPUT NAME="CommonName" VALUE=""></TD></TR>
    <TR><TD>eMail Address</TD>
        <TD><INPUT NAME="EmailAddress" VALUE=""></TD></TR>
    <TR><TD></TD>
        <TD><INPUT TYPE="BUTTON" NAME="submit" VALUE="Beantragen"></TD></TR>
</TABLE>
	<INPUT TYPE="hidden" NAME="SessionId" VALUE="template_for_sessId">
	<INPUT TYPE="hidden" NAME="Request" VALUE="">
</FORM>
<BR><HR WIDTH=50%><BR><P>
</CENTER>

<SCRIPT LANGUAGE=VBS>
    Dim DN

    Sub Submit_OnClick
	Dim TheForm
	Set TheForm = Document.MSIE_Enrollment
	sessionId	= TheForm.SessionId.value
	reqHardware     = FALSE
	C		= TheForm.Country.value
	SP		= TheForm.StateOrProvince.value
	L		= TheForm.Location.value
	O		= TheForm.Organization.value
	OU		= TheForm.OrganizationalUnit.value
	CN              = TheForm.CommonName.value
	Email		= TheForm.EmailAddress.value
        szPurpose       = "ClientAuth"
        doAcceptanceUINow   = FALSE
        doOnline        = TRUE

	DN = ""

	Call Add_RDN("C", C)
	Call Add_RDN("S", SP)
	Call Add_RDN("L", L)
	Call Add_RDN("O", O)
	Call Add_RDN("OU", OU)
	Call Add_RDN("CN", CN)
	Call Add_RDN("1.2.840.113549.1.9.1", Email)
		      ' rsadsi
				     ' pkcs
				       ' pkcs9
					 ' eMailAddress
        On Error Resume Next
        sz10 = certHelper.GenerateKeyPair(sessionId, _
                FALSE, DN, 0, ClientAuth, FASLE, TRUE, 1)_
        theError = Err.Number
        On Error Goto 0
        if (sz10 = Empty OR theError <> 0) Then
            sz = "The error '" & Hex(theError) & "' occurred." & chr(13) & _
                chr(10) & "Your credentials could not be generated."
            result = MsgBox(sz, 0, "Credentials Enrollment")
            Exit Sub
	else 
	    TheForm.Request.value = sz10
	    TheForm.Submit
        end if
    End Sub

    Sub Add_RDN(sn, value)
	if (value <> "") then
	    if (DN <> "") then
		DN = DN & "; "
	    end if
	    DN = DN & sn & "=" & value
	end if
    End Sub
</SCRIPT>
</BODY>
</HTML>
EOF
-----END ms-enroll.cgi-----

Second, how to extract the request and feed the certificate back? We need to 
"normalize" the base64 encoding of the PKCS#10 format which means 
regenerating the lines and wrapping with BEGIN and END line. This is done by 
gawk. The request is taken by ca the normal way. Then the cert needs to be 
packed into a PKCS#7 structure (note: the use of a CRL is necessary for 
crl2pkcs7 as of version 0.6.6. Starting with 0.8.0 it it might probably be 
ommited). Finally we need to format the PKCS#7 object and generate the HTML 
text. I use two templates to have a clearer script.

1st note: postit2 is slightly modified from a program I found at ncsa's ftp 
site. Grab it from http://www.easterngraphics.com/certs/IX9704/postit2.c. You 
need utils.c from there too.

2nd note: I'm note quite sure wether the gawk script really handles all 
possible inputs for the request right! Today I don't use this construction 
anymore myself.

3d note: the cert must be of version 3! This could be done with the nsComment 
line in ssleay.cnf...

------BEGIN ms-gencert.cgi-----
#!/bin/sh
FILE="/tmp/"`date '+%y%m%d%H%M%S'-`$$
rm -f "$FILE".*

HOME=`pwd`; export HOME  # as ssleay.cnf insists on having such an env var
cd /usr/local/ssl #where demoCA (as named in ssleay.conf) is located

postit2 -s " " -i 0x0d > "$FILE".inp  # process the FORM vars

SESSION_ID=`gawk '$1 == "SessionId" { print $2; exit }' "$FILE".inp`

gawk \
	'BEGIN { \
		OFS = ""; \
		print "-----BEGIN CERTIFICATE REQUEST-----"; \
		req_seen=0 \
	} \
	$1 == "Request" { \
		req_seen=1; \
		if (length($2) == 72) print($2); \
		lastline=$2; \
		next; \
	} \
	{ \
		if (req_seen == 1) { \
			if (length($1) >= 72) print($1); \
			else if (length(lastline) < 72) { \
				req_seen=0; \
				print (lastline,$1); \
			} \
		lastline=$1; \
		} \
	} \
	END { \
		print "-----END CERTIFICATE REQUEST-----"; \
	}' > "$FILE".pem < "$FILE".inp 

ssleay ca -batch -in "$FILE".pem -key passwd -out "$FILE".out
ssleay crl2pkcs7 -certfile "$FILE".out -out "$FILE".pkcs7 -in demoCA/crl.pem

sed s/template_for_sessId/$SESSION_ID/ <ms-enroll2a.html >"$FILE".cert
/usr/local/bin/gawk \
	'BEGIN	{ \
		OFS = ""; \
		dq = sprintf("%c",34); \
	} \
	$0 ~ "PKCS7" { next; } \
	{ \
		print dq$0dq" & _"; \
	}' <"$FILE".pkcs7 >> "$FILE".cert
cat  ms-enroll2b.html >>"$FILE".cert

echo Content-type: text/html
echo Content-length: `wc -c "$FILE".cert`
echo
cat "$FILE".cert
rm -f "$FILE".*
-----END ms-gencert.cgi-----

----BEGIN ms-enroll2a.html----
<HTML><HEAD><TITLE>Certificate Acceptance Test Page</TITLE></HEAD><BODY>

<OBJECT
    classid="clsid:33BEC9E0-F78F-11cf-B782-00C04FD7BF43"
    codebase=certenr3.dll
    id=certHelper
    >
</OBJECT>

<CENTER>
<H2>Your personal certificate</H2>
<BR><HR WIDTH=50%><BR><P>
Press the button!
<P><INPUT TYPE=BUTTON VALUE="Nimm mich!" NAME="InstallCert">
</CENTER>
<BR><HR WIDTH=50%><BR>

<SCRIPT LANGUAGE=VBS>
    Sub InstallCert_OnClick

	sessionId	= "template_for_sessId"
credentials = "" & _
----END ms-enroll2a.html----

----BEGIN ms-enroll2b.html----
""
        On Error Resume Next
        result = certHelper.AcceptCredentials(sessionId, credentials, 0, 
FALSE)
        if (IsEmpty(result)) Then
           sz = "The error '" & Err.Number & "' occurred." & chr(13) & 
chr(10) & "This Digital ID could not be registered."
           msgOut = MsgBox(sz, 0, "Credentials Registration Error")
           navigate "error.html"
        else
           sz = "Digital ID successfully registered."
           msgOut = MsgBox(sz, 0, "Credentials Registration")
           navigate "success.html"
        end if
	Exit Sub
    End Sub
</SCRIPT>
</BODY>
</HTML>
----END ms-enroll2b.html----

4.) What do do with the cert?
-----------------------------

The cert is visible (without restarting MSIE) under the following menu:
View->Options->Security->Personal certs. You can examine it's contents at 
least partially.

To use it for client authentication you need to use SSL3.0 (fortunately 
SSLeay supports it with 0.8.0). Furthermore MSIE is told to only supports a 
kind of automatic selection of certs (I personally wasn't able to test it 
myself). But there is a requirement that the issuer of the server cert and 
the issuer of the client cert needs to be the same (according to a developer 
from MS). Which means: you need may more then one cert to talk to all 
servers...

I'm sure we will get a bit more experience after ApacheSSL is available for 
SSLeay 0.8.8.


I hope you enjoyed reading and that in future questions on this topic will 
rarely appear on ssl-users@moncom.com ;-)

Ilmenau, 9th of June 1997
Holger Reif <reif@prakinf.tu-ilmenau.de>
-- 
read you later  -  Holger Reif
----------------------------------------  Signaturprojekt Deutsche Einheit
TU Ilmenau - Informatik - Telematik                      (Verdamp lang her)
Holger.Reif@PrakInf.TU-Ilmenau.DE         Alt wie ein Baum werden, um ueber
http://Remus.PrakInf.TU-Ilmenau.DE/Reif/  alle 7 Bruecken gehen zu koennen


==== ns-ca.doc ========================================================

The following documentation was supplied by Jeff Barber, who provided the
patch to the CA program to add this functionality.

eric
--
Jeff Barber                                Email: jeffb@issl.atl.hp.com

Hewlett Packard                            Phone: (404) 648-9503
Internet and System Security Lab           Fax:   (404) 648-9516

                         oo
---------------------cut /\ here for ns-ca.doc ------------------------------

This document briefly describes how to use SSLeay to implement a 
certificate authority capable of dynamically serving up client
certificates for version 3.0 beta 5 (and presumably later) versions of
the Netscape Navigator.  Before describing how this is done, it's
important to understand a little about how the browser implements its
client certificate support.  This is documented in some detail in the
URLs based at <URL:http://home.netscape.com/eng/security/certs.html>.
Here's a brief overview:

-	The Navigator supports a new HTML tag "KEYGEN" which will cause
	the browser to generate an RSA key pair when you submit a form
	containing the tag.  The public key, along with an optional
	challenge (supposedly provided for use in certificate revocation
	but I don't use it) is signed, DER-encoded, base-64 encoded
	and sent to the web server as the value of the variable
	whose NAME is provided in the KEYGEN tag.  The private key is
	stored by the browser in a local key database.

	This "Signed Public Key And Challenge" (SPKAC) arrives formatted
	into 64 character lines (which are of course URL-encoded when 
	sent via HTTP -- i.e. spaces, newlines and most punctuatation are
	encoded as "%HH" where HH is the hex equivalent of the ASCII code).
	Note that the SPKAC does not contain the other usual attributes
	of a certificate request, especially the subject name fields.
	These must be otherwise encoded in the form for submission along
	with the SPKAC.

-	Either immediately (in response to this form submission), or at
	some later date (a real CA will probably verify your identity in
	some way before issuing the certificate), a web server can send a
	certificate based on the public key and other attributes back to
	the browser by encoding it in DER (the binary form) and sending it
	to the browser as MIME type:
	"Content-type: application/x-x509-user-cert"

	The browser uses the public key encoded in the certificate to
	associate the certificate with the appropriate private key in
	its local key database.  Now, the certificate is "installed".

-	When a server wants to require authentication based on client
	certificates, it uses the right signals via the SSL protocol to
	trigger the Navigator to ask you which certificate you want to
	send.  Whether the certificate is accepted is dependent on CA
	certificates and so forth installed in the server and is beyond
	the scope of this document.


Now, here's how the SSLeay package can be used to provide client 
certficates:

-	You prepare a file for input to the SSLeay ca application.
	The file contains a number of "name = value" pairs that identify
	the subject.  The names here are the same subject name component
	identifiers used in the CA section of the lib/ssleay.conf file,
	such as "emailAddress", "commonName" "organizationName" and so
	forth.  Both the long version and the short version (e.g. "Email",
	"CN", "O") can be used.

	One more name is supported: this one is "SPKAC".  Its value
	is simply the value of the base-64 encoded SPKAC sent by the
	browser (with all the newlines and other space charaters
	removed -- and newline escapes are NOT supported).

	[ As of SSLeay 0.6.4, multiple lines are supported.
	  Put a \ at the end of each line and it will be joined with the
	  previous line with the '\n' removed - eay ]
	
	Here's a sample input file:

C = US
SP = Georgia
O = Some Organization, Inc.
OU = Netscape Compatibility Group
CN = John X. Doe
Email = jxdoe@someorg.com
SPKAC = MIG0MGAwXDANBgkqhkiG9w0BAQEFAANLADBIAkEAwmk6FMJ4uAVIYbcvIOx5+bDGTfvL8X5gE+R67ccMk6rCSGbVQz2cetyQtnI+VIs0NwdD6wjuSuVtVFbLoHonowIDAQABFgAwDQYJKoZIhvcNAQEEBQADQQBFZDUWFl6BJdomtN1Bi53mwijy1rRgJ4YirF15yBEDM3DjAQkKXHYOIX+qpz4KXKnl6EYxTnGSFL5wWt8X2iyx

-	You execute the ca command (either from a CGI program run out of
	the web server, or as a later manual task) giving it the above
	file as input.  For example, if the file were named /tmp/cert.req,
	you'd run:
	$SSLDIR/bin/ca -spkac /tmp/cert.req -out /tmp/cert

	The output is in DER format (binary) if a -out argument is 
	provided, as above; otherwise, it's in the PEM format (base-64
	encoded DER).  Also, the "-batch" switch is implied by the
	"-spkac" so you don't get asked whether to complete the signing
	(probably it shouldn't work this way but I was only interested
	in hacking together an online CA that could be used for issuing
	test certificates).

	The "-spkac" capability doesn't support multiple files (I think).

	Any CHALLENGE provided in the SPKAC is simply ignored.

	The interactions between the identification fields you provide
	and those identified in your lib/ssleay.conf are the same as if
	you did an ordinary "ca -in infile -out outfile" -- that is, if
	something is marked as required in the ssleay.conf file and it
	isn't found in the -spkac file, the certificate won't be issued.

-	Now, you pick up the output from /tmp/cert and pass it back to
	the Navigator prepending the Content-type string described earlier.

-	In order to run the ca command out of a CGI program, you must
	provide a password to decrypt the CA's private key.  You can
	do this by using "echo MyKeyPassword | $SSLDIR/bin/ca ..."
	I think there's a way to not encrypt the key file in the first
	place, but I didn't see how to do that, so I made a small change
	to the library that allows the password to be accepted from a pipe.
	Either way is UTTERLY INSECURE and a real CA would never do that.

	[ You can use the 'ssleay rsa' command to remove the password
	  from the private key, or you can use the '-key' option to the
	  ca command to specify the decryption key on the command line
	  or use the -nodes option when generating the key.
	  ca will try to clear the command line version of the password
	  but for quite a few operating systems, this is not possible.
	  - eric ]

So, what do you have to do to make use of this stuff to create an online 
demo CA capability with SSLeay?

1	Create an HTML form for your users.  The form should contain
	fields for all of the required or optional fields in ssleay.conf.
	The form must contain a KEYGEN tag somewhere with at least a NAME
	attribute.

2	Create a CGI program to process the form input submitted by the
	browser.  The CGI program must URL-decode the variables and create
	the file described above, containing subject identification info
	as well as the SPKAC block.  It should then run the the ca program
	with the -spkac option.  If it works (check the exit status),
	return the new certificate with the appropriate MIME type.  If not,
	return the output of the ca command with MIME type "text/plain".

3	Set up your web server to accept connections signed by your demo
	CA.  This probably involves obtaining the PEM-encoded CA certificate
	(ordinarily in $SSLDIR/CA/cacert.pem) and installing it into a
	server database.  See your server manual for instructions.


==== obj.doc ========================================================

The Object library.

As part of my Crypto library, I found I required a method of identifying various
objects.  These objects normally had 3 different values associated with
them, a short text name, a long (or lower case) text name, and an
ASN.1 Object Identifier (which is a sequence of numbers).
This library contains a static list of objects and functions to lookup
according to one type and to return the other types.

To use these routines, 'Object.h' needs to be included.

For each supported object, #define entries are defined as follows
#define SN_Algorithm			"Algorithm"
#define LN_algorithm			"algorithm"
#define NID_algorithm			38
#define OBJ_algorithm			1L,3L,14L,3L,2L

SN_  stands for short name.
LN_  stands for either long name or lowercase name.
NID_ stands for Numeric ID.  I each object has a unique NID and this
     should be used internally to identify objects.
OBJ_ stands for ASN.1 Object Identifier or ASN1_OBJECT as defined in the
     ASN1 routines.  These values are used in ASN1 encoding.

The following functions are to be used to return pointers into a static
definition of these types.  What this means is "don't try to free() any
pointers returned from these functions.

ASN1_OBJECT *OBJ_nid2obj(
int n);
	Return the ASN1_OBJECT that corresponds to a NID of n.
	
char *OBJ_nid2ln(
int n);
	Return the long/lower case name of the object represented by the
	NID of n.
	
char *OBJ_nid2sn(
int n);
	Return the short name for the object represented by the NID of n.

ASN1_OBJECT *OBJ_dup(
ASN1_OBJECT *o);
	Duplicate and return a new ASN1_OBJECT that is the same as the
	passed parameter.
	
int OBJ_obj2nid(
ASN1_OBJECT *o);
	Given ASN1_OBJECT o, return the NID that corresponds.
	
int OBJ_ln2nid(
char *s);
	Given the long/lower case name 's', return the NID of the object.
	
int OBJ_sn2nid(
char *s);
	Given the short name 's', return the NID of the object.
	
char *OBJ_bsearch(
char *key,
char *base,
int num,
int size,
int (*cmp)());
	Since I have come across a few platforms that do not have the
	bsearch() function, OBJ_bsearch is my version of that function.
	Feel free to use this function, but you may as well just use the
	normal system bsearch(3) if it is present.  This version also
	has tolerance of being passed NULL pointers.

==== keys ===========================================================

EVP_PKEY_DSA
EVP_PKEY_DSA2
EVP_PKEY_DSA3
EVP_PKEY_DSA4

EVP_PKEY_RSA
EVP_PKEY_RSA2

valid DSA pkey types
	NID_dsa
	NID_dsaWithSHA
	NID_dsaWithSHA1
	NID_dsaWithSHA1_2

valid RSA pkey types
	NID_rsaEncryption
	NID_rsa

NID_dsaWithSHA	NID_dsaWithSHA			DSA		SHA
NID_dsa		NID_dsaWithSHA1			DSA		SHA1
NID_md2		NID_md2WithRSAEncryption	RSA-pkcs1	MD2
NID_md5		NID_md5WithRSAEncryption	RSA-pkcs1	MD5
NID_mdc2	NID_mdc2WithRSA			RSA-none	MDC2
NID_ripemd160	NID_ripemd160WithRSA		RSA-pkcs1	RIPEMD160
NID_sha		NID_shaWithRSAEncryption	RSA-pkcs1	SHA
NID_sha1	NID_sha1WithRSAEncryption	RSA-pkcs1	SHA1

==== rand.doc ========================================================

My Random number library.

These routines can be used to generate pseudo random numbers and can be
used to 'seed' the pseudo random number generator (RNG).  The RNG make no
effort to reproduce the same random number stream with each execution.
Various other routines in the SSLeay library 'seed' the RNG when suitable
'random' input data is available.  Read the section at the end for details
on the design of the RNG.

void RAND_bytes(
unsigned char *buf,
int num);
	This routine puts 'num' random bytes into 'buf'.  One should make
	sure RAND_seed() has been called before using this routine.
	
void RAND_seed(
unsigned char *buf,
int num);
	This routine adds more 'seed' data the RNG state.  'num' bytes
	are added to the RNG state, they are taken from 'buf'.  This
	routine can be called with sensitive data such as user entered
	passwords.  This sensitive data is in no way recoverable from
	the RAND library routines or state.  Try to pass as much data
	from 'random' sources as possible into the RNG via this function.
	Also strongly consider using the RAND_load_file() and
	RAND_write_file() routines.

void RAND_cleanup();
	When a program has finished with the RAND library, if it so
	desires, it can 'zero' all RNG state.
	
The following 3 routines are convenience routines that can be used to
'save' and 'restore' data from/to the RNG and it's state.
Since the more 'random' data that is feed as seed data the better, why not
keep it around between executions of the program?  Of course the
application should pass more 'random' data in via RAND_seed() and 
make sure no-one can read the 'random' data file.
	
char *RAND_file_name(
char *buf,
int size);
	This routine returns a 'default' name for the location of a 'rand'
	file.  The 'rand' file should keep a sequence of random bytes used
	to initialise the RNG.  The filename is put in 'buf'.  Buf is 'size'
	bytes long.  Buf is returned if things go well, if they do not,
	NULL is returned.  The 'rand' file name is generated in the
	following way.  First, if there is a 'RANDFILE' environment
	variable, it is returned.  Second, if there is a 'HOME' environment
	variable, $HOME/.rand is returned.  Third, NULL is returned.  NULL
	is also returned if a buf would overflow.

int RAND_load_file(
char *file,
long number);
	This function 'adds' the 'file' into the RNG state.  It does this by