From: Rich Salz Date: Mon, 2 Mar 2015 01:46:38 +0000 (-0500) Subject: Cleanup some doc files X-Git-Tag: OpenSSL_1_1_0-pre1~1588 X-Git-Url: https://git.librecmc.org/?a=commitdiff_plain;h=9f7f8eced5f0c3744203dad461b7e8373f9833e3;p=oweals%2Fopenssl.git Cleanup some doc files ACKNOWLEDGEMENTS is now spelled correctly :) README.ASN1 talked about 0.9.6, so it's deleted. I turned doc/standards.txt into a set of one-line summaries of RFCs, and also updated the pointers to original sources (to be web links) Reviewed-by: Richard Levitte --- diff --git a/ACKNOWLEDGEMENTS b/ACKNOWLEDGEMENTS new file mode 100644 index 0000000000..cb9ece5932 --- /dev/null +++ b/ACKNOWLEDGEMENTS @@ -0,0 +1,30 @@ +The OpenSSL project depends on volunteer efforts and financial support from +the end user community. That support comes in the form of donations and paid +sponsorships, software support contracts, paid consulting services +and commissioned software development. + +Since all these activities support the continued development and improvement +of OpenSSL we consider all these clients and customers as sponsors of the +OpenSSL project. + +We would like to identify and thank the following such sponsors for their past +or current significant support of the OpenSSL project: + +Major support: + + Qualys http://www.qualys.com/ + +Very significant support: + + OpenGear: http://www.opengear.com/ + +Significant support: + + PSW Group: http://www.psw.net/ + Acano Ltd. http://acano.com/ + +Please note that we ask permission to identify sponsors and that some sponsors +we consider eligible for inclusion here have requested to remain anonymous. + +Additional sponsorship or financial support is always welcome: for more +information please contact the OpenSSL Software Foundation. diff --git a/ACKNOWLEDGMENTS b/ACKNOWLEDGMENTS deleted file mode 100644 index 59c6f01f97..0000000000 --- a/ACKNOWLEDGMENTS +++ /dev/null @@ -1,30 +0,0 @@ -The OpenSSL project depends on volunteer efforts and financial support from -the end user community. That support comes in the form of donations and paid -sponsorships, software support contracts, paid consulting services -and commissioned software development. - -Since all these activities support the continued development and improvement -of OpenSSL we consider all these clients and customers as sponsors of the -OpenSSL project. - -We would like to identify and thank the following such sponsors for their past -or current significant support of the OpenSSL project: - -Major support: - - Qualys http://www.qualys.com/ - -Very significant support: - - OpenGear: http://www.opengear.com/ - -Significant support: - - PSW Group: http://www.psw.net/ - Acano Ltd. http://acano.com/ - -Please note that we ask permission to identify sponsors and that some sponsors -we consider eligible for inclusion here have requested to remain anonymous. - -Additional sponsorship or financial support is always welcome: for more -information please contact the OpenSSL Software Foundation. diff --git a/README.ASN1 b/README.ASN1 deleted file mode 100644 index 11bcfaf4dd..0000000000 --- a/README.ASN1 +++ /dev/null @@ -1,187 +0,0 @@ - -OpenSSL ASN1 Revision -===================== - -This document describes some of the issues relating to the new ASN1 code. - -Previous OpenSSL ASN1 problems -============================= - -OK why did the OpenSSL ASN1 code need revising in the first place? Well -there are lots of reasons some of which are included below... - -1. The code is difficult to read and write. For every single ASN1 structure -(e.g. SEQUENCE) four functions need to be written for new, free, encode and -decode operations. This is a very painful and error prone operation. Very few -people have ever written any OpenSSL ASN1 and those that have usually wish -they hadn't. - -2. Partly because of 1. the code is bloated and takes up a disproportionate -amount of space. The SEQUENCE encoder is particularly bad: it essentially -contains two copies of the same operation, one to compute the SEQUENCE length -and the other to encode it. - -3. The code is memory based: that is it expects to be able to read the whole -structure from memory. This is fine for small structures but if you have a -(say) 1Gb PKCS#7 signedData structure it isn't such a good idea... - -4. The code for the ASN1 IMPLICIT tag is evil. It is handled by temporarily -changing the tag to the expected one, attempting to read it, then changing it -back again. This means that decode buffers have to be writable even though they -are ultimately unchanged. This gets in the way of constification. - -5. The handling of EXPLICIT isn't much better. It adds a chunk of code into -the decoder and encoder for every EXPLICIT tag. - -6. APPLICATION and PRIVATE tags aren't even supported at all. - -7. Even IMPLICIT isn't complete: there is no support for implicitly tagged -types that are not OPTIONAL. - -8. Much of the code assumes that a tag will fit in a single octet. This is -only true if the tag is 30 or less (mercifully tags over 30 are rare). - -9. The ASN1 CHOICE type has to be largely handled manually, there aren't any -macros that properly support it. - -10. Encoders have no concept of OPTIONAL and have no error checking. If the -passed structure contains a NULL in a mandatory field it will not be encoded, -resulting in an invalid structure. - -11. It is tricky to add ASN1 encoders and decoders to external applications. - -Template model -============== - -One of the major problems with revision is the sheer volume of the ASN1 code. -Attempts to change (for example) the IMPLICIT behaviour would result in a -modification of *every* single decode function. - -I decided to adopt a template based approach. I'm using the term 'template' -in a manner similar to SNACC templates: it has nothing to do with C++ -templates. - -A template is a description of an ASN1 module as several constant C structures. -It describes in a machine readable way exactly how the ASN1 structure should -behave. If this template contains enough detail then it is possible to write -versions of new, free, encode, decode (and possibly others operations) that -operate on templates. - -Instead of having to write code to handle each operation only a single -template needs to be written. If new operations are needed (such as a 'print' -operation) only a single new template based function needs to be written -which will then automatically handle all existing templates. - -Plans for revision -================== - -The revision will consist of the following steps. Other than the first two -these can be handled in any order. - -o Design and write template new, free, encode and decode operations, initially -memory based. *DONE* - -o Convert existing ASN1 code to template form. *IN PROGRESS* - -o Convert an existing ASN1 compiler (probably SNACC) to output templates -in OpenSSL form. - -o Add support for BIO based ASN1 encoders and decoders to handle large -structures, initially blocking I/O. - -o Add support for non blocking I/O: this is quite a bit harder than blocking -I/O. - -o Add new ASN1 structures, such as OCSP, CRMF, S/MIME v3 (CMS), attribute -certificates etc etc. - -Description of major changes -============================ - -The BOOLEAN type now takes three values. 0xff is TRUE, 0 is FALSE and -1 is -absent. The meaning of absent depends on the context. If for example the -boolean type is DEFAULT FALSE (as in the case of the critical flag for -certificate extensions) then -1 is FALSE, if DEFAULT TRUE then -1 is TRUE. -Usually the value will only ever be read via an API which will hide this from -an application. - -There is an evil bug in the old ASN1 code that mishandles OPTIONAL with -SEQUENCE OF or SET OF. These are both implemented as a STACK structure. The -old code would omit the structure if the STACK was NULL (which is fine) or if -it had zero elements (which is NOT OK). This causes problems because an empty -SEQUENCE OF or SET OF will result in an empty STACK when it is decoded but when -it is encoded it will be omitted resulting in different encodings. The new code -only omits the encoding if the STACK is NULL, if it contains zero elements it -is encoded and empty. There is an additional problem though: because an empty -STACK was omitted, sometimes the corresponding *_new() function would -initialize the STACK to empty so an application could immediately use it, if -this is done with the new code (i.e. a NULL) it wont work. Therefore a new -STACK should be allocated first. One instance of this is the X509_CRL list of -revoked certificates: a helper function X509_CRL_add0_revoked() has been added -for this purpose. - -The X509_ATTRIBUTE structure used to have an element called 'set' which took -the value 1 if the attribute value was a SET OF or 0 if it was a single. Due -to the behaviour of CHOICE in the new code this has been changed to a field -called 'single' which is 0 for a SET OF and 1 for single. The old field has -been deleted to deliberately break source compatibility. Since this structure -is normally accessed via higher level functions this shouldn't break too much. - -The X509_REQ_INFO certificate request info structure no longer has a field -called 'req_kludge'. This used to be set to 1 if the attributes field was -(incorrectly) omitted. You can check to see if the field is omitted now by -checking if the attributes field is NULL. Similarly if you need to omit -the field then free attributes and set it to NULL. - -The top level 'detached' field in the PKCS7 structure is no longer set when -a PKCS#7 structure is read in. PKCS7_is_detached() should be called instead. -The behaviour of PKCS7_get_detached() is unaffected. - -The values of 'type' in the GENERAL_NAME structure have changed. This is -because the old code use the ASN1 initial octet as the selector. The new -code uses the index in the ASN1_CHOICE template. - -The DIST_POINT_NAME structure has changed to be a true CHOICE type. - -typedef struct DIST_POINT_NAME_st { -int type; -union { - STACK_OF(GENERAL_NAME) *fullname; - STACK_OF(X509_NAME_ENTRY) *relativename; -} name; -} DIST_POINT_NAME; - -This means that name.fullname or name.relativename should be set -and type reflects the option. That is if name.fullname is set then -type is 0 and if name.relativename is set type is 1. - -With the old code using the i2d functions would typically involve: - -unsigned char *buf, *p; -int len; -/* Find length of encoding */ -len = i2d_SOMETHING(x, NULL); -/* Allocate buffer */ -buf = OPENSSL_malloc(len); -if(buf == NULL) { - /* Malloc error */ -} -/* Use temp variable because &p gets updated to point to end of - * encoding. - */ -p = buf; -i2d_SOMETHING(x, &p); - - -Using the new i2d you can also do: - -unsigned char *buf = NULL; -int len; -len = i2d_SOMETHING(x, &buf); -if(len < 0) { - /* Malloc error */ -} - -and it will automatically allocate and populate a buffer with the -encoding. After this call 'buf' will point to the start of the -encoding which is len bytes long. diff --git a/doc/standards.txt b/doc/standards.txt index 7bada8d35f..146525e129 100644 --- a/doc/standards.txt +++ b/doc/standards.txt @@ -1,285 +1,168 @@ 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] +This is a work in progress. These are documents that describe things that +are implemented (in whole or at least great parts) in OpenSSL. +To search for RFCs, you can start at http://www.ietf.org/rfc.html -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 search for internet-drafts, you can start at http://www.ietf.org/id-info/ -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/. +Many PKCS standards are now RFC's; PKCS#11 is now at Oasis and can be +found at https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=pkcs11 -Implemented: ------------- +Implemented +----------- -These are documents that describe things that are implemented (in -whole or at least great parts) in OpenSSL. +PKCS#8: Private-Key Information Syntax Standard -1319 The MD2 Message-Digest Algorithm. B. Kaliski. April 1992. - (Format: TXT=25661 bytes) (Status: INFORMATIONAL) +PKCS#12: Personal Information Exchange Syntax Standard, version 1.0. -1320 The MD4 Message-Digest Algorithm. R. Rivest. April 1992. (Format: - TXT=32407 bytes) (Status: INFORMATIONAL) +1319 The MD2 Message-Digest Algorithm -1321 The MD5 Message-Digest Algorithm. R. Rivest. April 1992. (Format: - TXT=35222 bytes) (Status: INFORMATIONAL) +1320 The MD4 Message-Digest Algorithm -2246 The TLS Protocol Version 1.0. T. Dierks, C. Allen. January 1999. - (Format: TXT=170401 bytes) (Status: PROPOSED STANDARD) +1321 The MD5 Message-Digest Algorithm -2268 A Description of the RC2(r) Encryption Algorithm. R. Rivest. - January 1998. (Format: TXT=19048 bytes) (Status: INFORMATIONAL) +2246 The TLS Protocol Version 1 -2315 PKCS 7: Cryptographic Message Syntax Version 1.5. B. Kaliski. - March 1998. (Format: TXT=69679 bytes) (Status: INFORMATIONAL) +2268 A Description of the RC2(r) Encryption Algorithm -PKCS#8: Private-Key Information Syntax Standard - -PKCS#12: Personal Information Exchange Syntax Standard, version 1.0. +2315 PKCS 7: Cryptographic Message Syntax Version 1.5 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) + Status Protocol - OCSP 2712 Addition of Kerberos Cipher Suites to Transport Layer Security - (TLS). A. Medvinsky, M. Hur. October 1999. (Format: TXT=13763 bytes) - (Status: PROPOSED STANDARD) - -2898 PKCS #5: Password-Based Cryptography Specification Version 2.0. - B. Kaliski. September 2000. (Format: TXT=68692 bytes) (Status: - INFORMATIONAL) + (TLS) -2986 PKCS #10: Certification Request Syntax Specification Version 1.7. - M. Nystrom, B. Kaliski. November 2000. (Format: TXT=27794 bytes) - (Obsoletes RFC2314) (Status: INFORMATIONAL) +2898 PKCS #5: Password-Based Cryptography Specification Version 2.0 -3174 US Secure Hash Algorithm 1 (SHA1). D. Eastlake 3rd, P. Jones. - September 2001. (Format: TXT=35525 bytes) (Status: INFORMATIONAL) +2986 PKCS #10: Certification Request Syntax Specification Version 1.7 3161 Internet X.509 Public Key Infrastructure, Time-Stamp Protocol (TSP) - C. Adams, P. Cain, D. Pinkas, R. Zuccherato. August 2001 - (Status: PROPOSED STANDARD) + +3174 US Secure Hash Algorithm 1 (SHA1) 3268 Advanced Encryption Standard (AES) Ciphersuites for Transport - Layer Security (TLS). P. Chown. June 2002. (Format: TXT=13530 bytes) - (Status: PROPOSED STANDARD) + Layer Security (TLS) 3279 Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) - Profile. L. Bassham, W. Polk, R. Housley. April 2002. (Format: - TXT=53833 bytes) (Status: PROPOSED STANDARD) + Profile 3280 Internet X.509 Public Key Infrastructure Certificate and - Certificate Revocation List (CRL) Profile. R. Housley, W. Polk, W. - Ford, D. Solo. April 2002. (Format: TXT=295556 bytes) (Obsoletes - RFC2459) (Status: PROPOSED STANDARD) + Certificate Revocation List (CRL) Profile 3447 Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography - Specifications Version 2.1. J. Jonsson, B. Kaliski. February 2003. - (Format: TXT=143173 bytes) (Obsoletes RFC2437) (Status: - INFORMATIONAL) + Specifications Version 2.1 -3713 A Description of the Camellia Encryption Algorithm. M. Matsui, - J. Nakajima, S. Moriai. April 2004. (Format: TXT=25031 bytes) - (Status: INFORMATIONAL) +3713 A Description of the Camellia Encryption Algorithm 3820 Internet X.509 Public Key Infrastructure (PKI) Proxy Certificate - Profile. S. Tuecke, V. Welch, D. Engert, L. Pearlman, M. Thompson. - June 2004. (Format: TXT=86374 bytes) (Status: PROPOSED STANDARD) + Profile 4132 Addition of Camellia Cipher Suites to Transport Layer Security - (TLS). S. Moriai, A. Kato, M. Kanda. July 2005. (Format: TXT=13590 - bytes) (Status: PROPOSED STANDARD) + (TLS) -4162 Addition of SEED Cipher Suites to Transport Layer Security (TLS). - H.J. Lee, J.H. Yoon, J.I. Lee. August 2005. (Format: TXT=10578 bytes) - (Status: PROPOSED STANDARD) +4162 Addition of SEED Cipher Suites to Transport Layer Security (TLS) -4269 The SEED Encryption Algorithm. H.J. Lee, S.J. Lee, J.H. Yoon, - D.H. Cheon, J.I. Lee. December 2005. (Format: TXT=34390 bytes) - (Obsoletes RFC4009) (Status: INFORMATIONAL) +4269 The SEED Encryption Algorithm -Related: --------- +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) + Encryption and Authentication Procedures 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) + Certificate-Based Key Management 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) + Algorithms, Modes, and Identifiers 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) + Certification and Related Services -2025 The Simple Public-Key GSS-API Mechanism (SPKM). C. Adams. October - 1996. (Format: TXT=101692 bytes) (Status: PROPOSED STANDARD) +2025 The Simple Public-Key GSS-API Mechanism (SPKM) 2510 Internet X.509 Public Key Infrastructure Certificate Management - Protocols. C. Adams, S. Farrell. March 1999. (Format: TXT=158178 - bytes) (Status: PROPOSED STANDARD) + Protocols -2511 Internet X.509 Certificate Request Message Format. M. Myers, C. - Adams, D. Solo, D. Kemp. March 1999. (Format: TXT=48278 bytes) - (Status: PROPOSED STANDARD) +2511 Internet X.509 Certificate Request Message Format 2527 Internet X.509 Public Key Infrastructure Certificate Policy and - Certification Practices Framework. S. Chokhani, W. Ford. March 1999. - (Format: TXT=91860 bytes) (Status: INFORMATIONAL) + Certification Practices Framework -2538 Storing Certificates in the Domain Name System (DNS). D. Eastlake - 3rd, O. Gudmundsson. March 1999. (Format: TXT=19857 bytes) (Status: - PROPOSED STANDARD) +2538 Storing Certificates in the Domain Name System (DNS) -2539 Storage of Diffie-Hellman Keys in the Domain Name System (DNS). - D. Eastlake 3rd. March 1999. (Format: TXT=21049 bytes) (Status: - PROPOSED STANDARD) +2539 Storage of Diffie-Hellman Keys in the Domain Name System (DNS) 2559 Internet X.509 Public Key Infrastructure Operational Protocols - - LDAPv2. S. Boeyen, T. Howes, P. Richard. April 1999. (Format: - TXT=22889 bytes) (Updates RFC1778) (Status: PROPOSED STANDARD) + LDAPv2 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) + FTP and HTTP -2587 Internet X.509 Public Key Infrastructure LDAPv2 Schema. S. - Boeyen, T. Howes, P. Richard. June 1999. (Format: TXT=15102 bytes) - (Status: PROPOSED STANDARD) +2587 Internet X.509 Public Key Infrastructure LDAPv2 Schema -2595 Using TLS with IMAP, POP3 and ACAP. C. Newman. June 1999. - (Format: TXT=32440 bytes) (Status: PROPOSED STANDARD) +2595 Using TLS with IMAP, POP3 and ACAP -2631 Diffie-Hellman Key Agreement Method. E. Rescorla. June 1999. - (Format: TXT=25932 bytes) (Status: PROPOSED STANDARD) +2631 Diffie-Hellman Key Agreement Method -2632 S/MIME Version 3 Certificate Handling. B. Ramsdell, Ed.. June - 1999. (Format: TXT=27925 bytes) (Status: PROPOSED STANDARD) +2632 S/MIME Version 3 Certificate Handling -2716 PPP EAP TLS Authentication Protocol. B. Aboba, D. Simon. October - 1999. (Format: TXT=50108 bytes) (Status: EXPERIMENTAL) +2716 PPP EAP TLS Authentication Protocol -2773 Encryption using KEA and SKIPJACK. R. Housley, P. Yee, W. Nace. - February 2000. (Format: TXT=20008 bytes) (Updates RFC0959) (Status: - EXPERIMENTAL) +2797 Certificate Management Messages over CMS -2797 Certificate Management Messages over CMS. M. Myers, X. Liu, J. - Schaad, J. Weinstein. April 2000. (Format: TXT=103357 bytes) (Status: - PROPOSED STANDARD) +2817 Upgrading to TLS Within HTTP/1.1 -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 -2818 HTTP Over TLS. E. Rescorla. May 2000. (Format: TXT=15170 bytes) - (Status: INFORMATIONAL) +2984 Use of the CAST-128 Encryption Algorithm in CMS -2876 Use of the KEA and SKIPJACK Algorithms in CMS. J. Pawling. July - 2000. (Format: TXT=29265 bytes) (Status: INFORMATIONAL) - -2984 Use of the CAST-128 Encryption Algorithm in CMS. C. Adams. - October 2000. (Format: TXT=11591 bytes) (Status: PROPOSED STANDARD) - -2985 PKCS #9: Selected Object Classes and Attribute Types Version 2.0. - M. Nystrom, B. Kaliski. November 2000. (Format: TXT=70703 bytes) - (Status: INFORMATIONAL) +2985 PKCS #9: Selected Object Classes and Attribute Types Version 2.0 3029 Internet X.509 Public Key Infrastructure Data Validation and - Certification Server Protocols. C. Adams, P. Sylvester, M. Zolotarev, - R. Zuccherato. February 2001. (Format: TXT=107347 bytes) (Status: - EXPERIMENTAL) + Certification Server Protocols 3039 Internet X.509 Public Key Infrastructure Qualified Certificates - Profile. S. Santesson, W. Polk, P. Barzin, M. Nystrom. January 2001. - (Format: TXT=67619 bytes) (Status: PROPOSED STANDARD) + Profile -3058 Use of the IDEA Encryption Algorithm in CMS. S. Teiwes, P. - Hartmann, D. Kuenzi. February 2001. (Format: TXT=17257 bytes) - (Status: INFORMATIONAL) +3058 Use of the IDEA Encryption Algorithm in CMS 3161 Internet X.509 Public Key Infrastructure Time-Stamp Protocol - (TSP). C. Adams, P. Cain, D. Pinkas, R. Zuccherato. August 2001. - (Format: TXT=54585 bytes) (Status: PROPOSED STANDARD) + (TSP) -3185 Reuse of CMS Content Encryption Keys. S. Farrell, S. Turner. - October 2001. (Format: TXT=20404 bytes) (Status: PROPOSED STANDARD) +3185 Reuse of CMS Content Encryption Keys 3207 SMTP Service Extension for Secure SMTP over Transport Layer - Security. P. Hoffman. February 2002. (Format: TXT=18679 bytes) - (Obsoletes RFC2487) (Status: PROPOSED STANDARD) + Security -3217 Triple-DES and RC2 Key Wrapping. R. Housley. December 2001. - (Format: TXT=19855 bytes) (Status: INFORMATIONAL) +3217 Triple-DES and RC2 Key Wrapping 3274 Compressed Data Content Type for Cryptographic Message Syntax - (CMS). P. Gutmann. June 2002. (Format: TXT=11276 bytes) (Status: - PROPOSED STANDARD) + (CMS) 3278 Use of Elliptic Curve Cryptography (ECC) Algorithms in - Cryptographic Message Syntax (CMS). S. Blake-Wilson, D. Brown, P. - Lambert. April 2002. (Format: TXT=33779 bytes) (Status: - INFORMATIONAL) + Cryptographic Message Syntax (CMS) -3281 An Internet Attribute Certificate Profile for Authorization. S. - Farrell, R. Housley. April 2002. (Format: TXT=90580 bytes) (Status: - PROPOSED STANDARD) +3281 An Internet Attribute Certificate Profile for Authorization -3369 Cryptographic Message Syntax (CMS). R. Housley. August 2002. - (Format: TXT=113975 bytes) (Obsoletes RFC2630, RFC3211) (Status: - PROPOSED STANDARD) +3369 Cryptographic Message Syntax (CMS) -3370 Cryptographic Message Syntax (CMS) Algorithms. R. Housley. August - 2002. (Format: TXT=51001 bytes) (Obsoletes RFC2630, RFC3211) (Status: - PROPOSED STANDARD) +3370 Cryptographic Message Syntax (CMS) Algorithms -3377 Lightweight Directory Access Protocol (v3): Technical - Specification. J. Hodges, R. Morgan. September 2002. (Format: - TXT=9981 bytes) (Updates RFC2251, RFC2252, RFC2253, RFC2254, RFC2255, - RFC2256, RFC2829, RFC2830) (Status: PROPOSED STANDARD) - -3394 Advanced Encryption Standard (AES) Key Wrap Algorithm. J. Schaad, - R. Housley. September 2002. (Format: TXT=73072 bytes) (Status: - INFORMATIONAL) +3394 Advanced Encryption Standard (AES) Key Wrap Algorithm 3436 Transport Layer Security over Stream Control Transmission - Protocol. A. Jungmaier, E. Rescorla, M. Tuexen. December 2002. - (Format: TXT=16333 bytes) (Status: PROPOSED STANDARD) + Protocol 3657 Use of the Camellia Encryption Algorithm in Cryptographic - Message Syntax (CMS). S. Moriai, A. Kato. January 2004. - (Format: TXT=26282 bytes) (Status: PROPOSED STANDARD) - -"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. - + Message Syntax (CMS)