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
285      the key and attach it to ->description, ->payload[asym_subtype] should be
286      set to point to the subtype to be used, ->payload[asym_crypto] should be
289      quotalen should be updated to indicate how much quota this key should
293      ->description will be kfree()'d and the data attached to
294      ->payload[asm_crypto] will be passed to the subtype's ->destroy() method
295      to be disposed of.  A module reference for the subtype pointed to by
296      ->payload[asym_subtype] will be put.
299      If the data format is not recognised, -EBADMSG should be returned.  If it
300      is recognised, but the key cannot for some reason be set up, some other
301      negative error code should be returned.  On success, 0 should be returned.
303      The key's fingerprint string may be partially matched upon.  For a
304      public-key algorithm such as RSA and DSA this will likely be a printable