path: root/doc/man3/CMS_verify.pod
diff options
authorJung-uk Kim <jkim@FreeBSD.org>2018-09-13 19:18:07 +0000
committerJung-uk Kim <jkim@FreeBSD.org>2018-09-13 19:18:07 +0000
commita43ce912fc025d11e1395506111f75fc194d7ba5 (patch)
tree9794cf7720d75938ed0ea4f499c0dcd4b6eacdda /doc/man3/CMS_verify.pod
parent02be298e504b8554caca6dc85af450e1ea44d19d (diff)
Import OpenSSL 1.1.1.vendor/openssl/1.1.1
Notes: svn path=/vendor-crypto/openssl/dist/; revision=338658 svn path=/vendor-crypto/openssl/1.1.1/; revision=338659; tag=vendor/openssl/1.1.1
Diffstat (limited to 'doc/man3/CMS_verify.pod')
1 files changed, 132 insertions, 0 deletions
diff --git a/doc/man3/CMS_verify.pod b/doc/man3/CMS_verify.pod
new file mode 100644
index 000000000000..7187d9840ab6
--- /dev/null
+++ b/doc/man3/CMS_verify.pod
@@ -0,0 +1,132 @@
+=head1 NAME
+CMS_verify, CMS_get0_signers - verify a CMS SignedData structure
+=head1 SYNOPSIS
+ #include <openssl/cms.h>
+ int CMS_verify(CMS_ContentInfo *cms, STACK_OF(X509) *certs, X509_STORE *store,
+ BIO *indata, BIO *out, unsigned int flags);
+ STACK_OF(X509) *CMS_get0_signers(CMS_ContentInfo *cms);
+CMS_verify() verifies a CMS SignedData structure. B<cms> is the CMS_ContentInfo
+structure to verify. B<certs> is a set of certificates in which to search for
+the signing certificate(s). B<store> is a trusted certificate store used for
+chain verification. B<indata> is the detached content if the content is not
+present in B<cms>. The content is written to B<out> if it is not NULL.
+B<flags> is an optional set of flags, which can be used to modify the verify
+CMS_get0_signers() retrieves the signing certificate(s) from B<cms>, it must
+be called after a successful CMS_verify() operation.
+Normally the verify process proceeds as follows.
+Initially some sanity checks are performed on B<cms>. The type of B<cms> must
+be SignedData. There must be at least one signature on the data and if
+the content is detached B<indata> cannot be B<NULL>.
+An attempt is made to locate all the signing certificate(s), first looking in
+the B<certs> parameter (if it is not NULL) and then looking in any
+certificates contained in the B<cms> structure itself. If any signing
+certificate cannot be located the operation fails.
+Each signing certificate is chain verified using the B<smimesign> purpose and
+the supplied trusted certificate store. Any internal certificates in the message
+are used as untrusted CAs. If CRL checking is enabled in B<store> any internal
+CRLs are used in addition to attempting to look them up in B<store>. If any
+chain verify fails an error code is returned.
+Finally the signed content is read (and written to B<out> is it is not NULL)
+and the signature's checked.
+If all signature's verify correctly then the function is successful.
+Any of the following flags (ored together) can be passed in the B<flags>
+parameter to change the default verify behaviour.
+If B<CMS_NOINTERN> is set the certificates in the message itself are not
+searched when locating the signing certificate(s). This means that all the
+signing certificates must be in the B<certs> parameter.
+If B<CMS_NOCRL> is set and CRL checking is enabled in B<store> then any
+CRLs in the message itself are ignored.
+If the B<CMS_TEXT> flag is set MIME headers for type B<text/plain> are deleted
+from the content. If the content is not of type B<text/plain> then an error is
+If B<CMS_NO_SIGNER_CERT_VERIFY> is set the signing certificates are not
+If B<CMS_NO_ATTR_VERIFY> is set the signed attributes signature is not
+If B<CMS_NO_CONTENT_VERIFY> is set then the content digest is not checked.
+=head1 NOTES
+One application of B<CMS_NOINTERN> is to only accept messages signed by
+a small number of certificates. The acceptable certificates would be passed
+in the B<certs> parameter. In this case if the signer is not one of the
+certificates supplied in B<certs> then the verify will fail because the
+signer cannot be found.
+In some cases the standard techniques for looking up and validating
+certificates are not appropriate: for example an application may wish to
+lookup certificates in a database or perform customised verification. This
+can be achieved by setting and verifying the signers certificates manually
+using the signed data utility functions.
+Care should be taken when modifying the default verify behaviour, for example
+setting B<CMS_NO_CONTENT_VERIFY> will totally disable all content verification
+and any modified content will be considered valid. This combination is however
+useful if one merely wishes to write the content to B<out> and its validity
+is not considered important.
+Chain verification should arguably be performed using the signing time rather
+than the current time. However since the signing time is supplied by the
+signer it cannot be trusted without additional evidence (such as a trusted
+CMS_verify() returns 1 for a successful verification and zero if an error
+CMS_get0_signers() returns all signers or NULL if an error occurred.
+The error can be obtained from L<ERR_get_error(3)>
+=head1 BUGS
+The trusted certificate store is not searched for the signing certificate,
+this is primarily due to the inadequacies of the current B<X509_STORE>
+The lack of single pass processing means that the signed content must all
+be held in memory if it is not detached.
+=head1 SEE ALSO
+L<ERR_get_error(3)>, L<CMS_sign(3)>
+Copyright 2008-2016 The OpenSSL Project Authors. All Rights Reserved.
+Licensed under the OpenSSL license (the "License"). You may not use
+this file except in compliance with the License. You can obtain a copy
+in the file LICENSE in the source distribution or at