diff options
author | Ralf S. Engelschall <rse@openssl.org> | 1998-12-21 10:52:47 +0000 |
---|---|---|
committer | Ralf S. Engelschall <rse@openssl.org> | 1998-12-21 10:52:47 +0000 |
commit | d02b48c63a58ea4367a0e905979f140b7d090f86 (patch) | |
tree | 504f62ed3d84799f785b9cd9fab255a21b0e1b0e /doc |
Import of old SSLeay release: SSLeay 0.8.1b
Diffstat (limited to 'doc')
-rw-r--r-- | doc/API.doc | 24 | ||||
-rw-r--r-- | doc/a_verify.doc | 85 | ||||
-rw-r--r-- | doc/apps.doc | 53 | ||||
-rw-r--r-- | doc/asn1.doc | 401 | ||||
-rw-r--r-- | doc/bio.doc | 423 | ||||
-rw-r--r-- | doc/blowfish.doc | 149 | ||||
-rw-r--r-- | doc/bn.doc | 379 | ||||
-rw-r--r-- | doc/ca.1 | 121 | ||||
-rw-r--r-- | doc/callback.doc | 240 | ||||
-rw-r--r-- | doc/cipher.doc | 345 | ||||
-rw-r--r-- | doc/cipher.m | 128 | ||||
-rw-r--r-- | doc/conf.doc | 89 | ||||
-rw-r--r-- | doc/danger | 8 | ||||
-rw-r--r-- | doc/des.doc | 505 | ||||
-rw-r--r-- | doc/digest.doc | 94 | ||||
-rw-r--r-- | doc/encode.doc | 15 | ||||
-rw-r--r-- | doc/envelope.doc | 67 | ||||
-rw-r--r-- | doc/error.doc | 115 | ||||
-rw-r--r-- | doc/idea.doc | 176 | ||||
-rw-r--r-- | doc/legal.doc | 117 | ||||
-rw-r--r-- | doc/lhash.doc | 151 | ||||
-rw-r--r-- | doc/md2.doc | 49 | ||||
-rw-r--r-- | doc/md5.doc | 50 | ||||
-rw-r--r-- | doc/memory.doc | 27 | ||||
-rw-r--r-- | doc/ms3-ca.doc | 398 | ||||
-rw-r--r-- | doc/ns-ca.doc | 154 | ||||
-rw-r--r-- | doc/obj.doc | 69 | ||||
-rw-r--r-- | doc/rand.doc | 141 | ||||
-rw-r--r-- | doc/rc2.doc | 165 | ||||
-rw-r--r-- | doc/rc4.doc | 44 | ||||
-rw-r--r-- | doc/readme | 6 | ||||
-rw-r--r-- | doc/ref.doc | 48 | ||||
-rw-r--r-- | doc/req.1 | 137 | ||||
-rw-r--r-- | doc/rsa.doc | 133 | ||||
-rw-r--r-- | doc/rsaref.doc | 35 | ||||
-rw-r--r-- | doc/s_mult.doc | 17 | ||||
-rw-r--r-- | doc/session.doc | 297 | ||||
-rw-r--r-- | doc/sha.doc | 52 | ||||
-rw-r--r-- | doc/speed.doc | 96 | ||||
-rw-r--r-- | doc/ssl-ciph.doc | 84 | ||||
-rw-r--r-- | doc/ssl.doc | 172 | ||||
-rw-r--r-- | doc/ssl_ctx.doc | 68 | ||||
-rw-r--r-- | doc/ssleay.doc | 213 | ||||
-rw-r--r-- | doc/ssluse.doc | 45 | ||||
-rw-r--r-- | doc/stack.doc | 96 | ||||
-rw-r--r-- | doc/threads.doc | 90 | ||||
-rw-r--r-- | doc/txt_db.doc | 4 | ||||
-rw-r--r-- | doc/verify | 22 | ||||
-rw-r--r-- | doc/why.doc | 79 |
49 files changed, 6476 insertions, 0 deletions
diff --git a/doc/API.doc b/doc/API.doc new file mode 100644 index 0000000000..fe2820259a --- /dev/null +++ b/doc/API.doc @@ -0,0 +1,24 @@ +SSL - SSLv2/v3/v23 etc. + +BIO - methods and how they plug together + +MEM - memory allocation callback + +CRYPTO - locking for threads + +EVP - Ciphers/Digests/signatures + +RSA - methods + +X509 - certificate retrieval + +X509 - validation + +X509 - X509v3 extensions + +Objects - adding object identifiers + +ASN.1 - parsing + +PEM - parsing + diff --git a/doc/a_verify.doc b/doc/a_verify.doc new file mode 100644 index 0000000000..06eec17c2b --- /dev/null +++ b/doc/a_verify.doc @@ -0,0 +1,85 @@ +From eay@mincom.com Fri Oct 4 18:29:06 1996 +Received: by orb.mincom.oz.au id AA29080 + (5.65c/IDA-1.4.4 for eay); Fri, 4 Oct 1996 08:29:07 +1000 +Date: Fri, 4 Oct 1996 08:29:06 +1000 (EST) +From: Eric Young <eay@mincom.oz.au> +X-Sender: eay@orb +To: wplatzer <wplatzer@iaik.tu-graz.ac.at> +Cc: Eric Young <eay@mincom.oz.au>, SSL Mailing List <ssl-users@mincom.com> +Subject: Re: Netscape's Public Key +In-Reply-To: <19961003134837.NTM0049@iaik.tu-graz.ac.at> +Message-Id: <Pine.SOL.3.91.961004081346.8018K-100000@orb> +Mime-Version: 1.0 +Content-Type: TEXT/PLAIN; charset=US-ASCII +Status: RO +X-Status: + +On Thu, 3 Oct 1996, wplatzer wrote: +> I get Public Key from Netscape (Gold 3.0b4), but cannot do anything +> with it... It looks like (asn1parse): +> +> 0:d=0 hl=3 l=180 cons: SEQUENCE +> 3:d=1 hl=2 l= 96 cons: SEQUENCE +> 5:d=2 hl=2 l= 92 cons: SEQUENCE +> 7:d=3 hl=2 l= 13 cons: SEQUENCE +> 9:d=4 hl=2 l= 9 prim: OBJECT :rsaEncryption +> 20:d=4 hl=2 l= 0 prim: NULL +> 22:d=3 hl=2 l= 75 prim: BIT STRING +> 99:d=2 hl=2 l= 0 prim: IA5STRING : +> 101:d=1 hl=2 l= 13 cons: SEQUENCE +> 103:d=2 hl=2 l= 9 prim: OBJECT :md5withRSAEncryption +> 114:d=2 hl=2 l= 0 prim: NULL +> 116:d=1 hl=2 l= 65 prim: BIT STRING +> +> The first BIT STRING is the public key and the second BIT STRING is +> the signature. +> But a public key consists of the public exponent and the modulus. Are +> both numbers in the first BIT STRING? +> Is there a document simply describing this coding stuff (checking +> signature, get the public key, etc.)? + +Minimal in SSLeay. If you want to see what the modulus and exponent are, +try asn1parse -offset 25 -length 75 <key.pem +asn1parse will currently stuff up on the 'length 75' part (fixed in next +release) but it will print the stuff. If you are after more +documentation on ASN.1, have a look at www.rsa.com and get their PKCS +documents, most of my initial work on SSLeay was done using them. + +As for SSLeay, +util/crypto.num and util/ssl.num are lists of all exported functions in +the library (but not macros :-(. + +The ones for extracting public keys from certificates and certificate +requests are EVP_PKEY * X509_REQ_extract_key(X509_REQ *req); +EVP_PKEY * X509_extract_key(X509 *x509); + +To verify a signature on a signed ASN.1 object +int X509_verify(X509 *a,EVP_PKEY *key); +int X509_REQ_verify(X509_REQ *a,EVP_PKEY *key); +int X509_CRL_verify(X509_CRL *a,EVP_PKEY *key); +int NETSCAPE_SPKI_verify(NETSCAPE_SPKI *a,EVP_PKEY *key); + +I should mention that EVP_PKEY can be used to hold a public or a private key, +since for things like RSA and DSS, a public key is just a subset of what +is stored for the private key. + +To sign any of the above structures + +int X509_sign(X509 *a,EVP_PKEY *key,EVP_MD *md); +int X509_REQ_sign(X509_REQ *a,EVP_PKEY *key,EVP_MD *md); +int X509_CRL_sign(X509_CRL *a,EVP_PKEY *key,EVP_MD *md); +int NETSCAPE_SPKI_sign(NETSCAPE_SPKI *a,EVP_PKEY *key,EVP_MD *md); + +where md is the message digest to sign with. + +There are all defined in x509.h and all the _sign and _verify functions are +actually macros to the ASN1_sign() and ASN1_verify() functions. +These functions will put the correct algorithm identifiers in the correct +places in the structures. + +eric +-- +Eric Young | BOOL is tri-state according to Bill Gates. +AARNet: eay@mincom.oz.au | RTFM Win32 GetMessage(). + + diff --git a/doc/apps.doc b/doc/apps.doc new file mode 100644 index 0000000000..a2a4e0de72 --- /dev/null +++ b/doc/apps.doc @@ -0,0 +1,53 @@ +The applications + +Ok, where to begin.... +In the begining, when SSLeay was small (April 1995), there +were but few applications, they did happily cohabit in +the one bin directory. Then over time, they did multiply and grow, +and they started to look like microsoft software; 500k to print 'hello world'. +A new approach was needed. They were coalessed into one 'Monolithic' +application, ssleay. This one program is composed of many programs that +can all be compiled independantly. + +ssleay has 3 modes of operation. +1) If the ssleay binaray has the name of one of its component programs, it +executes that program and then exits. This can be achieve by using hard or +symbolic links, or failing that, just renaming the binary. +2) If the first argument to ssleay is the name of one of the component +programs, that program runs that program and then exits. +3) If there are no arguments, ssleay enters a 'command' mode. Each line is +interpreted as a program name plus arguments. After each 'program' is run, +ssleay returns to the comand line. + +dgst - message digests +enc - encryption and base64 encoding + +ans1parse - 'pulls' appart ASN.1 encoded objects like certificates. + +dh - Diffle-Hellman parameter manipulation. +rsa - RSA manipulations. +crl - Certificate revokion list manipulations +x509 - X509 cert fiddles, including signing. +pkcs7 - pkcs7 manipulation, only DER versions right now. + +genrsa - generate an RSA private key. +gendh - Generate a set of Diffle-Hellman parameters. +req - Generate a PKCS#10 object, a certificate request. + +s_client - SSL client program +s_server - SSL server program +s_time - A SSL protocol timing program +s_mult - Another SSL server, but it multiplexes + connections. +s_filter - under development + +errstr - Convert SSLeay error numbers to strings. +ca - Sign certificate requests, and generate + certificate revokion lists +crl2pkcs7 - put a crl and certifcates into a pkcs7 object. +speed - Benchmark the ciphers. +verify - Check certificates +hashdir - under development + +[ there a now a few more options, play with the program to see what they + are ] diff --git a/doc/asn1.doc b/doc/asn1.doc new file mode 100644 index 0000000000..fdad17c05c --- /dev/null +++ b/doc/asn1.doc @@ -0,0 +1,401 @@ +The ASN.1 Routines. + +ASN.1 is a specification for how to encode structured 'data' in binary form. +The approach I have take to the manipulation of structures and their encoding +into ASN.1 is as follows. + +For each distinct structure there are 4 function of the following form +TYPE *TYPE_new(void); +void TYPE_free(TYPE *); +TYPE *d2i_TYPE(TYPE **a,unsigned char **pp,long length); +long i2d_TYPE(TYPE *a,unsigned char **pp); /* CHECK RETURN VALUE */ + +where TYPE is the type of the 'object'. The TYPE that have these functions +can be in one of 2 forms, either the internal C malloc()ed data structure +or in the DER (a variant of ASN.1 encoding) binary encoding which is just +an array of unsigned bytes. The 'i2d' functions converts from the internal +form to the DER form and the 'd2i' functions convert from the DER form to +the internal form. + +The 'new' function returns a malloc()ed version of the structure with all +substructures either created or left as NULL pointers. For 'optional' +fields, they are normally left as NULL to indicate no value. For variable +size sub structures (often 'SET OF' or 'SEQUENCE OF' in ASN.1 syntax) the +STACK data type is used to hold the values. Have a read of stack.doc +and have a look at the relevant header files to see what I mean. If there +is an error while malloc()ing the structure, NULL is returned. + +The 'free' function will free() all the sub components of a particular +structure. If any of those sub components have been 'removed', replace +them with NULL pointers, the 'free' functions are tolerant of NULL fields. + +The 'd2i' function copies a binary representation into a C structure. It +operates as follows. 'a' is a pointer to a pointer to +the structure to populate, 'pp' is a pointer to a pointer to where the DER +byte string is located and 'length' is the length of the '*pp' data. +If there are no errors, a pointer to the populated structure is returned. +If there is an error, NULL is returned. Errors can occur because of +malloc() failures but normally they will be due to syntax errors in the DER +encoded data being parsed. It is also an error if there was an +attempt to read more that 'length' bytes from '*p'. If +everything works correctly, the value in '*p' is updated +to point at the location just beyond where the DER +structure was read from. In this way, chained calls to 'd2i' type +functions can be made, with the pointer into the 'data' array being +'walked' along the input byte array. +Depending on the value passed for 'a', different things will be done. If +'a' is NULL, a new structure will be malloc()ed and returned. If '*a' is +NULL, a new structure will be malloc()ed and put into '*a' and returned. +If '*a' is not NULL, the structure in '*a' will be populated, or in the +case of an error, free()ed and then returned. +Having these semantics means that a structure +can call a 'd2i' function to populate a field and if the field is currently +NULL, the structure will be created. + +The 'i2d' function type is used to copy a C structure to a byte array. +The parameter 'a' is the structure to convert and '*p' is where to put it. +As for the 'd2i' type structure, 'p' is updated to point after the last +byte written. If p is NULL, no data is written. The function also returns +the number of bytes written. Where this becomes useful is that if the +function is called with a NULL 'p' value, the length is returned. This can +then be used to malloc() an array of bytes and then the same function can +be recalled passing the malloced array to be written to. e.g. + +int len; +unsigned char *bytes,*p; +len=i2d_X509(x,NULL); /* get the size of the ASN1 encoding of 'x' */ +if ((bytes=(unsigned char *)malloc(len)) == NULL) + goto err; +p=bytes; +i2d_X509(x,&p); + +Please note that a new variable, 'p' was passed to i2d_X509. After the +call to i2d_X509 p has been incremented by len bytes. + +Now the reason for this functional organisation is that it allows nested +structures to be built up by calling these functions as required. There +are various macros used to help write the general 'i2d', 'd2i', 'new' and +'free' functions. They are discussed in another file and would only be +used by some-one wanting to add new structures to the library. As you +might be able to guess, the process of writing ASN.1 files can be a bit CPU +expensive for complex structures. I'm willing to live with this since the +simpler library code make my life easier and hopefully most programs using +these routines will have their execution profiles dominated by cipher or +message digest routines. +What follows is a list of 'TYPE' values and the corresponding ASN.1 +structure and where it is used. + +TYPE ASN.1 +ASN1_INTEGER INTEGER +ASN1_BIT_STRING BIT STRING +ASN1_OCTET_STRING OCTET STRING +ASN1_OBJECT OBJECT IDENTIFIER +ASN1_PRINTABLESTRING PrintableString +ASN1_T61STRING T61String +ASN1_IA5STRING IA5String +ASN1_UTCTIME UTCTime +ASN1_TYPE Any of the above mentioned types plus SEQUENCE and SET + +Most of the above mentioned types are actualled stored in the +ASN1_BIT_STRING type and macros are used to differentiate between them. +The 3 types used are + +typedef struct asn1_object_st + { + /* both null if a dynamic ASN1_OBJECT, one is + * defined if a 'static' ASN1_OBJECT */ + char *sn,*ln; + int nid; + int length; + unsigned char *data; + } ASN1_OBJECT; +This is used to store ASN1 OBJECTS. Read 'objects.doc' for details ono +routines to manipulate this structure. 'sn' and 'ln' are used to hold text +strings that represent the object (short name and long or lower case name). +These are used by the 'OBJ' library. 'nid' is a number used by the OBJ +library to uniquely identify objects. The ASN1 routines will populate the +'length' and 'data' fields which will contain the bit string representing +the object. + +typedef struct asn1_bit_string_st + { + int length; + int type; + unsigned char *data; + } ASN1_BIT_STRING; +This structure is used to hold all the other base ASN1 types except for +ASN1_UTCTIME (which is really just a 'char *'). Length is the number of +bytes held in data and type is the ASN1 type of the object (there is a list +in asn1.h). + +typedef struct asn1_type_st + { + int type; + union { + char *ptr; + ASN1_INTEGER * integer; + ASN1_BIT_STRING * bit_string; + ASN1_OCTET_STRING * octet_string; + ASN1_OBJECT * object; + ASN1_PRINTABLESTRING * printablestring; + ASN1_T61STRING * t61string; + ASN1_IA5STRING * ia5string; + ASN1_UTCTIME * utctime; + ASN1_BIT_STRING * set; + ASN1_BIT_STRING * sequence; + } value; + } ASN1_TYPE; +This structure is used in a few places when 'any' type of object can be +expected. + +X509 Certificate +X509_CINF CertificateInfo +X509_ALGOR AlgorithmIdentifier +X509_NAME Name +X509_NAME_ENTRY A single sub component of the name. +X509_VAL Validity +X509_PUBKEY SubjectPublicKeyInfo +The above mentioned types are declared in x509.h. They are all quite +straight forward except for the X509_NAME/X509_NAME_ENTRY pair. +A X509_NAME is a STACK (see stack.doc) of X509_NAME_ENTRY's. +typedef struct X509_name_entry_st + { + ASN1_OBJECT *object; + ASN1_BIT_STRING *value; + int set; + int size; /* temp variable */ + } X509_NAME_ENTRY; +The size is a temporary variable used by i2d_NAME and set is the set number +for the particular NAME_ENTRY. A X509_NAME is encoded as a sequence of +sequence of sets. Normally each set contains only a single item. +Sometimes it contains more. Normally throughout this library there will be +only one item per set. The set field contains the 'set' that this entry is +a member of. So if you have just created a X509_NAME structure and +populated it with X509_NAME_ENTRYs, you should then traverse the X509_NAME +(which is just a STACK) and set the 'set/' field to incrementing numbers. +For more details on why this is done, read the ASN.1 spec for Distinguished +Names. + +X509_REQ CertificateRequest +X509_REQ_INFO CertificateRequestInfo +These are used to hold certificate requests. + +X509_CRL CertificateRevocationList +These are used to hold a certificate revocation list + +RSAPrivateKey PrivateKeyInfo +RSAPublicKey PublicKeyInfo +Both these 'function groups' operate on 'RSA' structures (see rsa.doc). +The difference is that the RSAPublicKey operations only manipulate the m +and e fields in the RSA structure. + +DSAPrivateKey DSS private key +DSAPublicKey DSS public key +Both these 'function groups' operate on 'DSS' structures (see dsa.doc). +The difference is that the RSAPublicKey operations only manipulate the +XXX fields in the DSA structure. + +DHparams DHParameter +This is used to hold the p and g value for The Diffie-Hellman operation. +The function deal with the 'DH' strucure (see dh.doc). + +Now all of these function types can be used with several other functions to give +quite useful set of general manipulation routines. Normally one would +not uses these functions directly but use them via macros. + +char *ASN1_dup(int (*i2d)(),char *(*d2i)(),char *x); +'x' is the input structure case to a 'char *', 'i2d' is the 'i2d_TYPE' +function for the type that 'x' is and d2i is the 'd2i_TYPE' function for the +type that 'x' is. As is obvious from the parameters, this function +duplicates the strucutre by transforming it into the DER form and then +re-loading it into a new strucutre and returning the new strucutre. This +is obviously a bit cpu intensive but when faced with a complex dynamic +structure this is the simplest programming approach. There are macros for +duplicating the major data types but is simple to add extras. + +char *ASN1_d2i_fp(char *(*new)(),char *(*d2i)(),FILE *fp,unsigned char **x); +'x' is a pointer to a pointer of the 'desired type'. new and d2i are the +corresponding 'TYPE_new' and 'd2i_TYPE' functions for the type and 'fp' is +an open file pointer to read from. This function reads from 'fp' as much +data as it can and then uses 'd2i' to parse the bytes to load and return +the parsed strucutre in 'x' (if it was non-NULL) and to actually return the +strucutre. The behavior of 'x' is as per all the other d2i functions. + +char *ASN1_d2i_bio(char *(*new)(),char *(*d2i)(),BIO *fp,unsigned char **x); +The 'BIO' is the new IO type being used in SSLeay (see bio.doc). This +function is the same as ASN1_d2i_fp() except for the BIO argument. +ASN1_d2i_fp() actually calls this function. + +int ASN1_i2d_fp(int (*i2d)(),FILE *out,unsigned char *x); +'x' is converted to bytes by 'i2d' and then written to 'out'. ASN1_i2d_fp +and ASN1_d2i_fp are not really symetric since ASN1_i2d_fp will read all +available data from the file pointer before parsing a single item while +ASN1_i2d_fp can be used to write a sequence of data objects. To read a +series of objects from a file I would sugest loading the file into a buffer +and calling the relevent 'd2i' functions. + +char *ASN1_d2i_bio(char *(*new)(),char *(*d2i)(),BIO *fp,unsigned char **x); +This function is the same as ASN1_i2d_fp() except for the BIO argument. +ASN1_i2d_fp() actually calls this function. + +char * PEM_ASN1_read(char *(*d2i)(),char *name,FILE *fp,char **x,int (*cb)()); +This function will read the next PEM encoded (base64) object of the same +type as 'x' (loaded by the d2i function). 'name' is the name that is in +the '-----BEGIN name-----' that designates the start of that object type. +If the data is encrypted, 'cb' will be called to prompt for a password. If +it is NULL a default function will be used to prompt from the password. +'x' is delt with as per the standard 'd2i' function interface. This +function can be used to read a series of objects from a file. While any +data type can be encrypted (see PEM_ASN1_write) only RSA private keys tend +to be encrypted. + +char * PEM_ASN1_read_bio(char *(*d2i)(),char *name,BIO *fp, + char **x,int (*cb)()); +Same as PEM_ASN1_read() except using a BIO. This is called by +PEM_ASN1_read(). + +int PEM_ASN1_write(int (*i2d)(),char *name,FILE *fp,char *x,EVP_CIPHER *enc, + unsigned char *kstr,int klen,int (*callback)()); + +int PEM_ASN1_write_bio(int (*i2d)(),char *name,BIO *fp, + char *x,EVP_CIPHER *enc,unsigned char *kstr,int klen, + int (*callback)()); + +int ASN1_sign(int (*i2d)(), X509_ALGOR *algor1, X509_ALGOR *algor2, + ASN1_BIT_STRING *signature, char *data, RSA *rsa, EVP_MD *type); +int ASN1_verify(int (*i2d)(), X509_ALGOR *algor1, + ASN1_BIT_STRING *signature,char *data, RSA *rsa); + +int ASN1_BIT_STRING_cmp(ASN1_BIT_STRING *a, ASN1_BIT_STRING *b); +ASN1_BIT_STRING *ASN1_BIT_STRING_type_new(int type ); + +int ASN1_UTCTIME_check(ASN1_UTCTIME *a); +void ASN1_UTCTIME_print(BIO *fp,ASN1_UTCTIME *a); +ASN1_UTCTIME *ASN1_UTCTIME_dup(ASN1_UTCTIME *a); + +ASN1_BIT_STRING *d2i_asn1_print_type(ASN1_BIT_STRING **a,unsigned char **pp, + long length,int type); + +int i2d_ASN1_SET(STACK *a, unsigned char **pp, + int (*func)(), int ex_tag, int ex_class); +STACK * d2i_ASN1_SET(STACK **a, unsigned char **pp, long length, + char *(*func)(), int ex_tag, int ex_class); + +int i2a_ASN1_OBJECT(BIO *bp,ASN1_OBJECT *object); +int i2a_ASN1_INTEGER(BIO *bp, ASN1_INTEGER *a); +int a2i_ASN1_INTEGER(BIO *bp,ASN1_INTEGER *bs,char *buf,int size); + +int ASN1_INTEGER_set(ASN1_INTEGER *a, long v); +long ASN1_INTEGER_get(ASN1_INTEGER *a); +ASN1_INTEGER *BN_to_ASN1_INTEGER(BIGNUM *bn, ASN1_INTEGER *ai); +BIGNUM *ASN1_INTEGER_to_BN(ASN1_INTEGER *ai,BIGNUM *bn); + +/* given a string, return the correct type. Max is the maximum number + * of bytes to parse. It stops parsing when 'max' bytes have been + * processed or a '\0' is hit */ +int ASN1_PRINTABLE_type(unsigned char *s,int max); + +void ASN1_parse(BIO *fp,unsigned char *pp,long len); + +int i2d_ASN1_bytes(ASN1_BIT_STRING *a, unsigned char **pp, int tag, int class); +ASN1_BIT_STRING *d2i_ASN1_bytes(ASN1_OCTET_STRING **a, unsigned char **pp, + long length, int Ptag, int Pclass); + +/* PARSING */ +int asn1_Finish(ASN1_CTX *c); + +/* SPECIALS */ +int ASN1_get_object(unsigned char **pp, long *plength, int *ptag, + int *pclass, long omax); +int ASN1_check_infinite_end(unsigned char **p,long len); +void ASN1_put_object(unsigned char **pp, int constructed, int length, + int tag, int class); +int ASN1_object_size(int constructed, int length, int tag); + +X509 * X509_get_cert(CERTIFICATE_CTX *ctx,X509_NAME * name,X509 *tmp_x509); +int X509_add_cert(CERTIFICATE_CTX *ctx,X509 *); + +char * X509_cert_verify_error_string(int n); +int X509_add_cert_file(CERTIFICATE_CTX *c,char *file, int type); +char * X509_gmtime (char *s, long adj); +int X509_add_cert_dir (CERTIFICATE_CTX *c,char *dir, int type); +int X509_load_verify_locations (CERTIFICATE_CTX *ctx, + char *file_env, char *dir_env); +int X509_set_default_verify_paths(CERTIFICATE_CTX *cts); +X509 * X509_new_D2i_X509(int len, unsigned char *p); +char * X509_get_default_cert_area(void ); +char * X509_get_default_cert_dir(void ); +char * X509_get_default_cert_file(void ); +char * X509_get_default_cert_dir_env(void ); +char * X509_get_default_cert_file_env(void ); +char * X509_get_default_private_dir(void ); +X509_REQ *X509_X509_TO_req(X509 *x, RSA *rsa); +int X509_cert_verify(CERTIFICATE_CTX *ctx,X509 *xs, int (*cb)()); + +CERTIFICATE_CTX *CERTIFICATE_CTX_new(); +void CERTIFICATE_CTX_free(CERTIFICATE_CTX *c); + +void X509_NAME_print(BIO *fp, X509_NAME *name, int obase); +int X509_print_fp(FILE *fp,X509 *x); +int X509_print(BIO *fp,X509 *x); + +X509_INFO * X509_INFO_new(void); +void X509_INFO_free(X509_INFO *a); + +char * X509_NAME_oneline(X509_NAME *a); + +#define X509_verify(x,rsa) +#define X509_REQ_verify(x,rsa) +#define X509_CRL_verify(x,rsa) + +#define X509_sign(x,rsa,md) +#define X509_REQ_sign(x,rsa,md) +#define X509_CRL_sign(x,rsa,md) + +#define X509_dup(x509) +#define d2i_X509_fp(fp,x509) +#define i2d_X509_fp(fp,x509) +#define d2i_X509_bio(bp,x509) +#define i2d_X509_bio(bp,x509) + +#define X509_CRL_dup(crl) +#define d2i_X509_CRL_fp(fp,crl) +#define i2d_X509_CRL_fp(fp,crl) +#define d2i_X509_CRL_bio(bp,crl) +#define i2d_X509_CRL_bio(bp,crl) + +#define X509_REQ_dup(req) +#define d2i_X509_REQ_fp(fp,req) +#define i2d_X509_REQ_fp(fp,req) +#define d2i_X509_REQ_bio(bp,req) +#define i2d_X509_REQ_bio(bp,req) + +#define RSAPrivateKey_dup(rsa) +#define d2i_RSAPrivateKey_fp(fp,rsa) +#define i2d_RSAPrivateKey_fp(fp,rsa) +#define d2i_RSAPrivateKey_bio(bp,rsa) +#define i2d_RSAPrivateKey_bio(bp,rsa) + +#define X509_NAME_dup(xn) +#define X509_NAME_ENTRY_dup(ne) + +void X509_REQ_print_fp(FILE *fp,X509_REQ *req); +void X509_REQ_print(BIO *fp,X509_REQ *req); + +RSA *X509_REQ_extract_key(X509_REQ *req); +RSA *X509_extract_key(X509 *x509); + +int X509_issuer_and_serial_cmp(X509 *a, X509 *b); +unsigned long X509_issuer_and_serial_hash(X509 *a); + +X509_NAME * X509_get_issuer_name(X509 *a); +int X509_issuer_name_cmp(X509 *a, X509 *b); +unsigned long X509_issuer_name_hash(X509 *a); + +X509_NAME * X509_get_subject_name(X509 *a); +int X509_subject_name_cmp(X509 *a,X509 *b); +unsigned long X509_subject_name_hash(X509 *x); + +int X509_NAME_cmp (X509_NAME *a, X509_NAME *b); +unsigned long X509_NAME_hash(X509_NAME *x); + diff --git a/doc/bio.doc b/doc/bio.doc new file mode 100644 index 0000000000..545a57cdff --- /dev/null +++ b/doc/bio.doc @@ -0,0 +1,423 @@ +BIO Routines + +This documentation is rather sparse, you are probably best +off looking at the code for specific details. + +The BIO library is a IO abstraction that was originally +inspired by the need to have callbacks to perform IO to FILE +pointers when using Windows 3.1 DLLs. There are two types +of BIO; a source/sink type and a filter type. +The source/sink methods are as follows: +- BIO_s_mem() memory buffer - a read/write byte array that |