Reformat, fix typos and clarify CMS API docs.

=head1 DESCRIPTION

BIO_new_CMS() returns a streaming filter BIO chain based on B<cms>. The output

of the filter is written to B<out>. Any data written to the returned BIO

is automatically translated to a BER format CMS structure.

of the filter is written to B<out>. Any data written to the chain is

automatically translated to a BER format CMS structure of the appropriate type.

=head1 NOTES

The BIO returned by this functions behaves like a standard filter BIO. It

supports non blocking I/O. Content is processes and streamed on the fly and not

The chain returned by this function behaves like a standard filter BIO. It

supports non blocking I/O. Content is processed and streamed on the fly and not

all held in memory at once: so it is possible to encode very large structures.

After all content has been written through the BIO BIO_flush() must be called

After all content has been written through the chain BIO_flush() must be called

to finalise the structure.

The B<CMS_STREAM> flag must be included in the corresponding B<flags>

parameter of the B<cms> creation function.

After use BIOs should be removed from the filter using BIO_pop() until

the output BIO B<out> is reached.

If an application wishes to write additional data to B<out> BIOs should be

removed from the chain using BIO_pop() and freed with BIO_free() until B<out>

is reached. If no additional data needs to be written BIO_free_all() can be

called to free up the whole chain.

Any content written through the filter is uses "as-is" and no canonical

Any content written through the filter is used verbatim: no canonical

translation is performed.

It is possible to chain multiple BIOs to for example create a triple wrapped

signed, enveloped signed structure. In this case it is the applications

It is possible to chain multiple BIOs to, for example, create a triple wrapped

signed, enveloped, signed structure. In this case it is the applications

responsibility to set the inner content type of any outer CMS_ContentInfo

structures.

=head1 DESCRIPTION

CMS_add0_cert() and CMS_add1_cert() add certificate B<cert> to B<cms> which

CMS_add0_cert() and CMS_add1_cert() add certificate B<cert> to B<cms>.

must be of type signed data or enveloped data. 

CMS_get1_certs() returns all certificates in B<cms>.

CMS_add0_crl() adds CRL B<crl> to B<cms> which must be of type signed data or

enveloped data. CMS_get1_crls() returns any CRLs in B<cms>.

CMS_add0_crl() adds CRL B<crl> to B<cms>. CMS_get1_crls() returns any CRLs in

B<cms>.

=head1 NOTES

The CMS_ContentInfo structure B<cms> must be of type signed data or enveloped

data or an error will be returned.

For signed data certificates and CRLs are added to the B<certificates> and

B<crls> fields of SignedData structure. For enveloped data they are added to

B<OriginatorInfo>.

As the B<0> implies CMS_add0_cert() adds B<cert> internally to B<cms> and it

must not be freed up after the call as opposed to CMS_add1_cert() where B<cert>

must be freed up.

The same certificate or CRL must not be added to the same cms structure more

than once.

For signed data CMS types certificates and CRLs are added to the

B<certificates> and B<crls> fields of the SignedData structure. For enveloped

data they are added to B<OriginatorInfo>.

=head1 RETURN VALUES

CMS_add0_cert(), CMS_add1_cert() and CMS_add0_crl() return 1 for success and

=head1 SEE ALSO

L<ERR_get_error(3)|ERR_get_error(3)>

L<ERR_get_error(3)|ERR_get_error(3)>,

L<CMS_sign(3)|CMS_sign(3)>,

L<CMS_encrypt(3)|CMS_encrypt(3)>

=head1 HISTORY

=head1 DESCRIPTION

CMS_add1_recipient_cert() adds a recipient certificate B<recip> 

CMS_ContentInfo enveloped data structure B<cms> as a KeyTransRecipientInfo

structure.

CMS_add1_recipient_cert() adds recipient B<recip> to CMS_ContentInfo enveloped

data structure B<cms> as a KeyTransRecipientInfo structure.

CMS_add0_recipient_key() adds symmetric key B<key> of length B<keylen> using

wrapping algorithm B<nid>, identifier B<id> or length B<idlen> and optional

wrapping algorithm B<nid>, identifier B<id> of length B<idlen> and optional

values B<date>, B<otherTypeId> and B<otherType> to CMS_ContentInfo enveloped

data structure B<cms> as a KEKRecipientInfo structure.

CMS_compress() creates and returns a CMS CompressedData structure. B<comp_nid>

is the compression algorithm to use or B<NID_undef> to use the default

algorithms (zlib compression). B<in> is the content to be compressed.

algorithm (zlib compression). B<in> is the content to be compressed.

B<flags> is an optional set of flags.

=head1 NOTES

The only currently supported compression algorithm is zlib using the NID

NID_zlib_compression.

If zlib support is not compiled into OpenSSL this CMS_compress() will return

If zlib support is not compiled into OpenSSL then CMS_compress() will return

an error.

If the B<CMS_TEXT> flag is set MIME headers for type B<text/plain> are

=head1 DESCRIPTION

CMS_decrypt() extracts and decrypts the content from a CMS envelopedData

CMS_decrypt() extracts and decrypts the content from a CMS EnvelopedData

structure. B<pkey> is the private key of the recipient, B<cert> is the

recipients certificate, B<data> is a BIO to write the content to and

recipient's certificate, B<data> is a BIO to write the content to and

B<flags> is an optional set of flags.

The B<dcont> parameter is used in the rare case where the encrypted content

in advance using the CMS utility functions such as CMS_set1_pkey(). In this

case both B<cert> and B<pkey> should be set to NULL.

To process KEKRecipientInfo types CMS_set1_key() should be used and B<cert>

and B<pkey> set to NULL.

To process KEKRecipientInfo types CMS_set1_key() or CMS_RecipientInfo_set0_key()

and CMS_ReceipientInfo_decrypt() should be called before CMS_decrypt() and

B<cert> and B<pkey> set to NULL.

The following flags can be passed in the B<flags> parameter.