Lines Matching refs:to

19 The "asymmetric" key type is designed to be a container for the keys used in
24 associated with the key and provides operations to describe and destroy it.
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.
35 for extracting information from the blobs of data passed to the instantiation
36 function.  The first data parser that recognises the blob gets to set the
40 key, or it may interpret it as a reference to a key held somewhere else in the
49 the opportunity to pre-parse a key and to determine the description the key
52 This can then be used to refer to the key, either by complete match or by
53 partial match.  The key type may also use other criteria to refer to a key.
60      function will examine a key's fingerprint to see if the hex digits given
86 For general access to asymmetric keys from within the kernel, the following
91 This gives access to functions for dealing with asymmetric / public keys.
122 An operation is provided to perform cryptographic signature verification, using
123 an asymmetric key to provide or to provide access to the public key.
129 it to check the signature.  The caller must have parsed the signature and
130 transferred the relevant bits to the structure pointed to by sig.
148 hash must be pointed to by sig->digest and the size of the hash be placed in
189 Asymmetric keys point to this with their payload[asym_subtype] member.
191 The owner and name fields should be set to the owning module and the name of
198      Mandatory.  This allows the subtype to display something in /proc/keys
213      given -ENOTSUPP.  The subtype may do anything it likes to implement an
214      operation, including offloading to hardware.
221 The asymmetric key type doesn't generally want to store or to deal with a raw
222 blob of data that holds the key data.  It would have to parse it and error
223 check it each time it wanted to use it.  Further, the contents of the blob may
227 Also, the blob may represent a pointer to some hardware containing the key
234  - Pointer to TPM key.
235  - Pointer to UEFI key.
253 The owner and name fields should be set to the owning module and the name of
261      This is called to preparse the key from the key creation and update paths.
263      allocated, and as such, is permitted to provide the key's description in
264      the case that the caller declines to do so.
266      The caller passes a pointer to the following struct with all of the fields
278      The instantiation data is in a blob pointed to by data and is datalen in
279      size.  The parse() function is not permitted to change these two values at
281      recognise the blob format and will not return -EBADMSG to indicate it is
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
287      set to point to the initialised data for that subtype,
288      ->payload[asym_key_ids] should point to one or more hex fingerprints and
289      quotalen should be updated to indicate how much quota this key should
292      When clearing up, the data attached to ->payload[asym_key_ids] and
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
307 Functions are provided to register and unregister parsers: