4

In some contexts (PKCS#12) key management is done through human readable key aliases, where the alias uniquely identifies the key, in others, it is done through key IDs (JWK sets, GPG, ...) with non-human readable UUID/hexadecimal/.. identifiers, while yet there are others (PKCS#11,...) we there is some overlapping (key ids and labels acting like human-readable aliases).

My intuition tells me that working with human readable aliases is the way to go to avoid using the wrong key by mistake, but my intuition can fail.

Is there any "best pattern" to use key-ids vs key aliases or some common criteria or is it just the result of different projects/working-groups using a different nomenclature, maybe "key ids" being the result of "simple hardware" not supporting ASCII charts or some other weird reason I just ignore.

Is there any well-defined formal definition for key-id and key-alias or are both terms used "at random" in different projects/specs?

Improve this question

1 Answer 1

Reset to default
6

IMHO what you describe are different and mostly non-overlapping use cases.

What you describe as key ids are usually directly derived shorter representations of a key/certificate, typically using some (shortened) hash and then some encoding (hex, base64, ...) but could also be encoded another way. These are used to quickly identify a specific key or compare it with a given one (like SSH fingerprint on first connect, public key fingerprint in pinning, ...).

Key aliases are instead manually associated with a key to reference it later. While the term "alias" is common for key stores having a file name for a certificate/key is basically the same. Contrary to key ids such aliases are not usable for key comparison since they could stay the same even if the key has changed.

But, at the end "identifier" (as in key id) is a vague term which just says that it is something which identifies the key, no matter if directly derived from the key or manually assigned. Thus it might be used in both contexts. For example in JWK the kid (key id) can refer to an assigned name but could also be a derived id, it's implementation dependent.

Improve this answer
3
  • I wondering if it is safe to suppose that "directly derived" can be assumed in any/most context (protocol or application), This looks to be the case for RSA and PGP key ids. Using a strong derived kid is a "best pattern", but not sure if this is the case in the real world. Some testking with SoftToken generates 8-digits key. Also in C&P from <rfc-editor.org/rfc/rfc7517#section-4.5> "The structure of the "kid" value is unspecified" with "kid" examples "1", "2011-04-29". In such scenarios, "low entropy" kids looks to me just as non human friendly alias.
    – earizon
    Commented Dec 3 at 17:19
  • 1
    @earizon: My answer focused on the use cases you've described in your question. But true, the kid you mention from RFC 7517 is not a derived key but a just a name for the key, i.e. same as an alias. Terminology is vague, especially since "id" just says some kind of identifier which is both true for derived and manually assigned.
    – Steffen Ullrich
    Commented Dec 3 at 22:00
  • 2
    I'd be hesitant to claim 'usually'; there are probably more implementations that don't do this than implementations which do. PGP and DNSSEC derive their key IDs from the public key, but those are the only ones I know of which do that. (As opposed to the term fingerprint, which is practically always derived.) Object IDs in PKCS#11 tokens are arbitrary hex strings unrelated to the key.
    – grawity
    Commented Dec 4 at 7:33

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .