Should common.PublicKey contain key_id?

[kommendorkapten]

Description

Determine if there is any real-world need/use-case for keeping the (public) key id to the concrete in-memory representation of the key itself. See this discussion for more context: #5 (comment)

[woodruffw]

Assuming that PublicKey.key_id would be defined as it is in RFC 6962 Ss. 3.2 (hash of the DER encoding), my vote is to not include it per the "dual state" principle: anything that is trivially recomputable should be computed by the verifier, rather than retrieving it and potentially having a confusable mismatch between the key ID and the actual key.

[znewman01]

+1 to omitting it for the reasons state above, plus the following: key IDs aren't actually a property of the key, they're an agreed-upon hint for identifying keys.

So they really belong to a "keyring" message which is a map<string, PublicKey>. But I don't think the bundle format needs to know about that.

Proposing to close since that's the current state.

[kommendorkapten]

Makes sense. @znewman01 's comment on the "keyring" is spot on my interpretation of this too, and keeping that out of the bundle seems reasonable, as it's application specific.