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 <levitte@openssl.org>
This commit is contained in:
Rich Salz
parent
a258afaf7c
commit
9f7f8eced5
@ -12,16 +12,16 @@ or current significant support of the OpenSSL project:
|
||||
|
||||
Major support:
|
||||
|
||||
Qualys http://www.qualys.com/
|
||||
Qualys http://www.qualys.com/
|
||||
|
||||
Very significant support:
|
||||
|
||||
OpenGear: http://www.opengear.com/
|
||||
OpenGear: http://www.opengear.com/
|
||||
|
||||
Significant support:
|
||||
|
||||
PSW Group: http://www.psw.net/
|
||||
Acano Ltd. http://acano.com/
|
||||
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.
|
||||
187
README.ASN1
187
README.ASN1
@ -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.
|
||||
@ -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
|
||||
|
||||
To search for internet-drafts, you can start at http://www.ietf.org/id-info/
|
||||
|
||||
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
|
||||
|
||||
|
||||
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
|
||||
whole or at least great parts) 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)
|
||||
|
||||
2315 PKCS 7: Cryptographic Message Syntax Version 1.5. B. Kaliski.
|
||||
March 1998. (Format: TXT=69679 bytes) (Status: INFORMATIONAL)
|
||||
Implemented
|
||||
-----------
|
||||
|
||||
PKCS#8: Private-Key Information Syntax Standard
|
||||
|
||||
PKCS#12: Personal Information Exchange Syntax Standard, version 1.0.
|
||||
|
||||
1319 The MD2 Message-Digest Algorithm
|
||||
|
||||
1320 The MD4 Message-Digest Algorithm
|
||||
|
||||
1321 The MD5 Message-Digest Algorithm
|
||||
|
||||
2246 The TLS Protocol Version 1
|
||||
|
||||
2268 A Description of the RC2(r) Encryption Algorithm
|
||||
|
||||
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)
|
||||
(TLS)
|
||||
|
||||
2898 PKCS #5: Password-Based Cryptography Specification Version 2.0.
|
||||
B. Kaliski. September 2000. (Format: TXT=68692 bytes) (Status:
|
||||
INFORMATIONAL)
|
||||
2898 PKCS #5: Password-Based Cryptography Specification Version 2.0
|
||||
|
||||
2986 PKCS #10: Certification Request Syntax Specification Version 1.7.
|
||||
M. Nystrom, B. Kaliski. November 2000. (Format: TXT=27794 bytes)
|
||||
(Obsoletes RFC2314) (Status: INFORMATIONAL)
|
||||
|
||||
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, <draft-murray-auth-ftp-ssl-05.txt>
|
||||
|
||||
|
||||
To be implemented:
|
||||
------------------
|
||||
|
||||
These are documents that describe things that are planed to be
|
||||
implemented in the hopefully short future.
|
||||
|
||||
Message Syntax (CMS)
|
||||
|
||||
Loading…
Reference in New Issue
Block a user