From 9200bb13d15da4b2a23e6bc92c20e95b74aa2113 Mon Sep 17 00:00:00 2001 From: beck <> Date: Fri, 15 Dec 2000 02:58:47 +0000 Subject: openssl-engine-0.9.6 merge --- src/lib/libssl/doc/openssl.txt | 59 +++++++++++++++++++ src/lib/libssl/doc/standards.txt | 121 +++++++++++++++++++++++++++++++++++++++ 2 files changed, 180 insertions(+) create mode 100644 src/lib/libssl/doc/standards.txt (limited to 'src/lib/libssl/doc') diff --git a/src/lib/libssl/doc/openssl.txt b/src/lib/libssl/doc/openssl.txt index 880eace4da..5da519e7e4 100644 --- a/src/lib/libssl/doc/openssl.txt +++ b/src/lib/libssl/doc/openssl.txt @@ -355,6 +355,24 @@ that would not make sense. It does support an additional issuer:copy option that will copy all the subject alternative name values from the issuer certificate (if possible). +Example: + +issuserAltName = issuer:copy + +Authority Info Access. + +The authority information access extension gives details about how to access +certain information relating to the CA. Its syntax is accessOID;location +where 'location' has the same syntax as subject alternative name (except +that email:copy is not supported). accessOID can be any valid OID but only +certain values are meaningful for example OCSP and caIssuers. OCSP gives the +location of an OCSP responder: this is used by Netscape PSM and other software. + +Example: + +authorityInfoAccess = OCSP;URI:http://ocsp.my.host/ +authorityInfoAccess = caIssuers;URI:http://my.ca/ca.html + CRL distribution points. This is a multi-valued extension that supports all the literal options of @@ -489,6 +507,47 @@ details about the structures returned. The returned structure should be freed after use using the relevant free function, BASIC_CONSTRAINTS_free() for example. +void * X509_get_ext_d2i(X509 *x, int nid, int *crit, int *idx); +void * X509_CRL_get_ext_d2i(X509_CRL *x, int nid, int *crit, int *idx); +void * X509_REVOKED_get_ext_d2i(X509_REVOKED *x, int nid, int *crit, int *idx); +void * X509V3_get_d2i(STACK_OF(X509_EXTENSION) *x, int nid, int *crit, int *idx); + +These functions combine the operations of searching for extensions and +parsing them. They search a certificate, a CRL a CRL entry or a stack +of extensions respectively for extension whose NID is 'nid' and return +the parsed result of NULL if an error occurred. For example: + +BASIC_CONSTRAINTS *bs; +bs = X509_get_ext_d2i(cert, NID_basic_constraints, NULL, NULL); + +This will search for the basicConstraints extension and either return +it value or NULL. NULL can mean either the extension was not found, it +occurred more than once or it could not be parsed. + +If 'idx' is NULL then an extension is only parsed if it occurs precisely +once. This is standard behaviour because extensions normally cannot occur +more than once. If however more than one extension of the same type can +occur it can be used to parse successive extensions for example: + +int i; +void *ext; + +i = -1; +for(;;) { + ext = X509_get_ext_d2i(x, nid, crit, &idx); + if(ext == NULL) break; + /* Do something with ext */ +} + +If 'crit' is not NULL and the extension was found then the int it points to +is set to 1 for critical extensions and 0 for non critical. Therefore if the +function returns NULL but 'crit' is set to 0 or 1 then the extension was +found but it could not be parsed. + +The int pointed to by crit will be set to -1 if the extension was not found +and -2 if the extension occurred more than once (this will only happen if +idx is NULL). In both cases the function will return NULL. + 3. Generating extensions. An extension will typically be generated from a configuration file, or some diff --git a/src/lib/libssl/doc/standards.txt b/src/lib/libssl/doc/standards.txt new file mode 100644 index 0000000000..61ccc5d7e0 --- /dev/null +++ b/src/lib/libssl/doc/standards.txt @@ -0,0 +1,121 @@ +Standards related to OpenSSL +============================ + +[Please, this is currently a draft. I made a first try at finding + documents that describe parts of what OpenSSL implements. There are + big gaps, and I've most certainly done something wrong. Please + correct whatever is... Also, this note should be removed when this + file is reaching a somewhat correct state. -- Richard Levitte] + + +All pointers in here will be either URL's or blobs of text borrowed +from miscellaneous indexes, like rfc-index.txt (index of RFCs), +1id-index.txt (index of Internet drafts) and the like. + +To find the latest possible RFCs, it's recommended to either browse +ftp://ftp.isi.edu/in-notes/ or go to http://www.rfc-editor.org/ and +use the search mechanism found there. +To find the latest possible Internet drafts, it's recommended to +browse ftp://ftp.isi.edu/internet-drafts/. +To find the latest possible PKCS, it's recommended to browse +http://www.rsasecurity.com/rsalabs/pkcs/. + + +Implemented: +------------ + +These are documents that describe things that are implemented in OpenSSL. + +1319 The MD2 Message-Digest Algorithm. B. Kaliski. April 1992. + (Format: TXT=25661 bytes) (Status: INFORMATIONAL) + +1320 The MD4 Message-Digest Algorithm. R. Rivest. April 1992. (Format: + TXT=32407 bytes) (Status: INFORMATIONAL) + +1321 The MD5 Message-Digest Algorithm. R. Rivest. April 1992. (Format: + TXT=35222 bytes) (Status: INFORMATIONAL) + +2246 The TLS Protocol Version 1.0. T. Dierks, C. Allen. January 1999. + (Format: TXT=170401 bytes) (Status: PROPOSED STANDARD) + +2268 A Description of the RC2(r) Encryption Algorithm. R. Rivest. + January 1998. (Format: TXT=19048 bytes) (Status: INFORMATIONAL) + +2314 PKCS 10: Certification Request Syntax Version 1.5. B. Kaliski. + March 1998. (Format: TXT=15814 bytes) (Status: INFORMATIONAL) + +2315 PKCS 7: Cryptographic Message Syntax Version 1.5. B. Kaliski. + March 1998. (Format: TXT=69679 bytes) (Status: INFORMATIONAL) + +2437 PKCS #1: RSA Cryptography Specifications Version 2.0. B. Kaliski, + J. Staddon. October 1998. (Format: TXT=73529 bytes) (Obsoletes + RFC2313) (Status: INFORMATIONAL) + +2459 Internet X.509 Public Key Infrastructure Certificate and CRL + Profile. R. Housley, W. Ford, W. Polk, D. Solo. January 1999. + (Format: TXT=278438 bytes) (Status: PROPOSED STANDARD) + +PKCS#8: Private-Key Information Syntax Standard + +PKCS#12: Personal Information Exchange Syntax Standard, version 1.0. + + +Related: +-------- + +These are documents that are close to OpenSSL, for example the +STARTTLS documents. + +1421 Privacy Enhancement for Internet Electronic Mail: Part I: Message + Encryption and Authentication Procedures. J. Linn. February 1993. + (Format: TXT=103894 bytes) (Obsoletes RFC1113) (Status: PROPOSED + STANDARD) + +1422 Privacy Enhancement for Internet Electronic Mail: Part II: + Certificate-Based Key Management. S. Kent. February 1993. (Format: + TXT=86085 bytes) (Obsoletes RFC1114) (Status: PROPOSED STANDARD) + +1423 Privacy Enhancement for Internet Electronic Mail: Part III: + Algorithms, Modes, and Identifiers. D. Balenson. February 1993. + (Format: TXT=33277 bytes) (Obsoletes RFC1115) (Status: PROPOSED + STANDARD) + +1424 Privacy Enhancement for Internet Electronic Mail: Part IV: Key + Certification and Related Services. B. Kaliski. February 1993. + (Format: TXT=17537 bytes) (Status: PROPOSED STANDARD) + +2487 SMTP Service Extension for Secure SMTP over TLS. P. Hoffman. + January 1999. (Format: TXT=15120 bytes) (Status: PROPOSED STANDARD) + +2585 Internet X.509 Public Key Infrastructure Operational Protocols: + FTP and HTTP. R. Housley, P. Hoffman. May 1999. (Format: TXT=14813 + bytes) (Status: PROPOSED STANDARD) + +2595 Using TLS with IMAP, POP3 and ACAP. C. Newman. June 1999. + (Format: TXT=32440 bytes) (Status: PROPOSED STANDARD) + +2712 Addition of Kerberos Cipher Suites to Transport Layer Security + (TLS). A. Medvinsky, M. Hur. October 1999. (Format: TXT=13763 bytes) + (Status: PROPOSED STANDARD) + +2817 Upgrading to TLS Within HTTP/1.1. R. Khare, S. Lawrence. May + 2000. (Format: TXT=27598 bytes) (Updates RFC2616) (Status: PROPOSED + STANDARD) + +2818 HTTP Over TLS. E. Rescorla. May 2000. (Format: TXT=15170 bytes) + (Status: INFORMATIONAL) + + "Securing FTP with TLS", 01/27/2000, + + +To be implemented: +------------------ + +These are documents that describe things that are planed to be +implemented in the hopefully short future. + +2560 X.509 Internet Public Key Infrastructure Online Certificate + Status Protocol - OCSP. M. Myers, R. Ankney, A. Malpani, S. Galperin, + C. Adams. June 1999. (Format: TXT=43243 bytes) (Status: PROPOSED + STANDARD) + -- cgit v1.2.3-55-g6feb