Lines Matching refs:be

19 The "asymmetric" key type is designed to be a container for the keys used in
25 However, no requirement is made that the key data actually be stored in the
28 A completely in-kernel key retention and operation subtype can be defined, but
29 it would also be possible to provide access to cryptographic hardware (such as
30 a TPM) that might be used to both retain the relevant key and perform
32 merely be an interface to the TPM driver.
37 subtype of the key and define the operations that can be done on that key.
50 should be given from the content of the key.
52 This can then be used to refer to the key, either by complete match or by
71      only keys of the specified subtype (e.g. tpm) will be matched.  For
143 The algorithm used must be noted in sig->pkey_hash_algo, and all the MPIs that
144 make up the actual signature must be stored in sig->mpi[] and the count of MPIs
148 hash must be pointed to by sig->digest and the size of the hash be placed in
157 data; or -ENOMEM if an allocation can't be performed.  -EINVAL can be returned
165 Asymmetric keys have a subtype that defines the set of operations that can be
173 The subtype definition structure can be found in:
191 The owner and name fields should be set to the owning module and the name of
200      could be displayed.  The key type will display the tail of the key
212      Currently there is only the one defined.  If not set, the caller will be
224 have various checks that can be performed on it (eg. self-signatures, validity
230 Examples of blob formats for which parsers could be implemented include:
240 The parser definition structure can be found in:
253 The owner and name fields should be set to the owning module and the name of
286      the key and attach it to ->description, ->type_data[0] should be set to
287      point to the subtype to be used, ->payload should be set to point to the
289      fingerprint and quotalen should be updated to indicate how much quota this
293      will be kfree()'d and the data attached to ->payload will be passed to the
294      subtype's ->destroy() method to be disposed of.  A module reference for
295      the subtype pointed to by ->type_data[0] will be put.
298      If the data format is not recognised, -EBADMSG should be returned.  If it
299      is recognised, but the key cannot for some reason be set up, some other
300      negative error code should be returned.  On success, 0 should be returned.
302      The key's fingerprint string may be partially matched upon.  For a
303      public-key algorithm such as RSA and DSA this will likely be a printable