Skip to content
  • David Howells's avatar
    KEYS: Asymmetric key pluggable data parsers · 46c6f177
    David Howells authored
    
    
    The instantiation data passed to the asymmetric key type are expected to be
    formatted in some way, and there are several possible standard ways to format
    the data.
    
    The two obvious standards are OpenPGP keys and X.509 certificates.  The latter
    is especially useful when dealing with UEFI, and the former might be useful
    when dealing with, say, eCryptfs.
    
    Further, it might be desirable to provide formatted blobs that indicate
    hardware is to be accessed to retrieve the keys or that the keys live
    unretrievably in a hardware store, but that the keys can be used by means of
    the hardware.
    
    From userspace, the keys can be loaded using the keyctl command, for example,
    an X.509 binary certificate:
    
    	keyctl padd asymmetric foo @s <dhowells.pem
    
    or a PGP key:
    
    	keyctl padd asymmetric bar @s <dhowells.pub
    
    or a pointer into the contents of the TPM:
    
    	keyctl add asymmetric zebra "TPM:04982390582905f8" @s
    
    Inside the kernel, pluggable parsers register themselves and then get to
    examine the payload data to see if they can handle it.  If they can, they get
    to:
    
      (1) Propose a name for the key, to be used it the name is "" or NULL.
    
      (2) Specify the key subtype.
    
      (3) Provide the data for the subtype.
    
    The key type asks the parser to do its stuff before a key is allocated and thus
    before the name is set.  If successful, the parser stores the suggested data
    into the key_preparsed_payload struct, which will be either used (if the key is
    successfully created and instantiated or updated) or discarded.
    
    Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
    Signed-off-by: default avatarRusty Russell <rusty@rustcorp.com.au>
    46c6f177