2019-05-21 01:08:01 +08:00
|
|
|
/* SPDX-License-Identifier: GPL-2.0-or-later */
|
KEYS: Asymmetric key pluggable data parsers
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: David Howells <dhowells@redhat.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2012-09-13 22:17:32 +08:00
|
|
|
/* Asymmetric public-key cryptography data parser
|
|
|
|
|
*
|
2020-06-15 14:50:08 +08:00
|
|
|
* See Documentation/crypto/asymmetric-keys.rst
|
KEYS: Asymmetric key pluggable data parsers
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: David Howells <dhowells@redhat.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2012-09-13 22:17:32 +08:00
|
|
|
*
|
|
|
|
|
* Copyright (C) 2012 Red Hat, Inc. All Rights Reserved.
|
|
|
|
|
* Written by David Howells (dhowells@redhat.com)
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
#ifndef _KEYS_ASYMMETRIC_PARSER_H
|
|
|
|
|
#define _KEYS_ASYMMETRIC_PARSER_H
|
|
|
|
|
|
2023-06-15 18:28:50 +08:00
|
|
|
struct key_preparsed_payload;
|
|
|
|
|
|
KEYS: Asymmetric key pluggable data parsers
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: David Howells <dhowells@redhat.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2012-09-13 22:17:32 +08:00
|
|
|
/*
|
|
|
|
|
* Key data parser. Called during key instantiation.
|
|
|
|
|
*/
|
|
|
|
|
struct asymmetric_key_parser {
|
|
|
|
|
struct list_head link;
|
|
|
|
|
struct module *owner;
|
|
|
|
|
const char *name;
|
|
|
|
|
|
|
|
|
|
/* Attempt to parse a key from the data blob passed to add_key() or
|
|
|
|
|
* keyctl_instantiate(). Should also generate a proposed description
|
|
|
|
|
* that the caller can optionally use for the key.
|
|
|
|
|
*
|
|
|
|
|
* Return EBADMSG if not recognised.
|
|
|
|
|
*/
|
|
|
|
|
int (*parse)(struct key_preparsed_payload *prep);
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
extern int register_asymmetric_key_parser(struct asymmetric_key_parser *);
|
|
|
|
|
extern void unregister_asymmetric_key_parser(struct asymmetric_key_parser *);
|
|
|
|
|
|
|
|
|
|
#endif /* _KEYS_ASYMMETRIC_PARSER_H */
|
