path: root/include
diff options
authorDavid Howells <dhowells@redhat.com>2014-09-16 17:36:11 +0100
committerDavid Howells <dhowells@redhat.com>2014-09-16 17:36:11 +0100
commit7901c1a8effbe5f89673bfc09d6e37b8f334f1a7 (patch)
treed11b8945fe52a9973fa56d9d7aa99a5496a9115f /include
parentf93b3cc7b1e6f16aedd745a8edba64355383184c (diff)
KEYS: Implement binary asymmetric key ID handling
Implement the first step in using binary key IDs for asymmetric keys rather than hex string keys. The previously added match data preparsing will be able to convert hex criterion strings into binary which can then be compared more rapidly. Further, we actually want more then one ID string per public key. The problem is that X.509 certs refer to other X.509 certs by matching Issuer + AuthKeyId to Subject + SubjKeyId, but PKCS#7 messages match against X.509 Issuer + SerialNumber. This patch just provides facilities for a later patch to make use of. Signed-off-by: David Howells <dhowells@redhat.com> Acked-by: Vivek Goyal <vgoyal@redhat.com>
Diffstat (limited to 'include')
1 files changed, 38 insertions, 0 deletions
diff --git a/include/keys/asymmetric-type.h b/include/keys/asymmetric-type.h
index 7dd473496180..044ab0d3aa45 100644
--- a/include/keys/asymmetric-type.h
+++ b/include/keys/asymmetric-type.h
@@ -19,6 +19,44 @@
extern struct key_type key_type_asymmetric;
+ * Identifiers for an asymmetric key ID. We have three ways of looking up a
+ * key derived from an X.509 certificate:
+ *
+ * (1) Serial Number & Issuer. Non-optional. This is the only valid way to
+ * map a PKCS#7 signature to an X.509 certificate.
+ *
+ * (2) Issuer & Subject Unique IDs. Optional. These were the original way to
+ * match X.509 certificates, but have fallen into disuse in favour of (3).
+ *
+ * (3) Auth & Subject Key Identifiers. Optional. SKIDs are only provided on
+ * CA keys that are intended to sign other keys, so don't appear in end
+ * user certificates unless forced.
+ *
+ * We could also support an PGP key identifier, which is just a SHA1 sum of the
+ * public key and certain parameters, but since we don't support PGP keys at
+ * the moment, we shall ignore those.
+ *
+ * What we actually do is provide a place where binary identifiers can be
+ * stashed and then compare against them when checking for an id match.
+ */
+struct asymmetric_key_id {
+ unsigned short len;
+ unsigned char data[];
+struct asymmetric_key_ids {
+ void *id[2];
+extern bool asymmetric_key_id_same(const struct asymmetric_key_id *kid1,
+ const struct asymmetric_key_id *kid2);
+extern struct asymmetric_key_id *asymmetric_key_generate_id(const void *val_1,
+ size_t len_1,
+ const void *val_2,
+ size_t len_2);
* The payload is at the discretion of the subtype.

Privacy Policy