openssl/doc
Richard Levitte 14c8a3d118 CORE: Define provider-native abstract objects
This is placed as CORE because the core of libcrypto is the authority
for what is possible to do and what's required to make these abstract
objects work.

In essence, an abstract object is an OSSL_PARAM array with well
defined parameter keys and values:

-   an object type, which is a number indicating what kind of
    libcrypto structure the object in question can be used with.  The
    currently possible numbers are defined in <openssl/core_object.h>.
-   an object data type, which is a string that indicates more closely
    what the contents of the object are.
-   the object data, an octet string.  The exact encoding used depends
    on the context in which it's used.  For example, the decoder
    sub-system accepts any encoding, as long as there is a decoder
    implementation that takes that as input.  If central code is to
    handle the data directly, DER encoding is assumed. (*)
-   an object reference, also an octet string.  This octet string is
    not the object contents, just a mere reference to a provider-native
    object. (**)
-   an object description, which is a human readable text string that
    can be displayed if some software desires to do so.

The intent is that certain provider-native operations (called X
here) are able to return any sort of object that belong with other
operations, or an object that has no provider support otherwise.

(*) A future extension might be to be able to specify encoding.

(**) The possible mechanisms for dealing with object references are:

-   An object loading function in the target operation.  The exact
    target operation is determined by the object type (for example,
    OSSL_OBJECT_PKEY implies that the target operation is a KEYMGMT)
    and the implementation to be fetched by its object data type (for
    an OSSL_OBJECT_PKEY, that's the KEYMGMT keytype to be fetched).
    This loading function is only useful for this if the implementations
    that are involved (X and KEYMGMT, for example) are from the same
    provider.

-   An object exporter function in the operation X implementation.
    That exporter function can be used to export the object data in
    OSSL_PARAM form that can be imported by a target operation's
    import function.  This can be used when it's not possible to fetch
    the target operation implementation from the same provider.

Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/12512)
2020-08-24 10:02:25 +02:00
..
HOWTO
images
internal Use in CMP+CRMF libctx and propq param added to sign/verify/HMAC/decrypt 2020-08-21 09:04:13 +02:00
man1 Rename OSSL_SERIALIZER / OSSL_DESERIALIZER to OSSL_ENCODE / OSSL_DECODE 2020-08-21 09:23:58 +02:00
man3 CORE: Define provider-native abstract objects 2020-08-24 10:02:25 +02:00
man5 Align documentation with recommendations of Linux Documentation Project 2020-07-22 09:15:00 +02:00
man7 CORE: Define provider-native abstract objects 2020-08-24 10:02:25 +02:00
build.info
dir-locals.example.el
fingerprints.txt
openssl-c-indent.el
perlvars.pm Apps: change provider_path option to provider-path. 2020-08-18 19:31:42 +10:00
README.md Fix many MarkDown issues in {NOTES*,README*,HACKING,LICENSE}.md files 2020-07-05 11:29:43 +02:00

OpenSSL Documentation

README.md This file

fingerprints.txt PGP fingerprints of authorised release signers

standards.txt standards.txt Moved to the web, https://www.openssl.org/docs/standards.html

HOWTO/ A few how-to documents; not necessarily up-to-date

man1/ The openssl command-line tools; start with openssl.pod

man3/ The SSL library and the crypto library

man5/ File formats

man7/ Overviews; start with crypto.pod and ssl.pod, for example Algorithm specific EVP_PKEY documentation.

Formatted versions of the manpages (apps,ssl,crypto) can be found at https://www.openssl.org/docs/manpages.html