diff options
120 files changed, 6492 insertions, 8178 deletions
@@ -3,6 +3,10 @@ Changes between 0.9.6 and 0.9.7 [xx XXX 2000] + *) Merge in replacement ASN1 code from the ASN1 branch. This almost + completely replaces the old ASN1 functionality. + [Steve Henson] + *) Change BN_mod_exp_recp so that negative moduli are tolerated (the sign is ignored). Similarly, ignore the sign in BN_MONT_CTX_set so that BN_mod_exp_mont and BN_mod_exp_mont_word work diff --git a/README.ASN1 b/README.ASN1 new file mode 100644 index 0000000000..11bcfaf4dd --- /dev/null +++ b/README.ASN1 @@ -0,0 +1,187 @@ + +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 |