Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Clarification for the field "keyid" and usage #5

Open
be-a-panther opened this issue Nov 19, 2024 · 0 comments
Open

Clarification for the field "keyid" and usage #5

be-a-panther opened this issue Nov 19, 2024 · 0 comments

Comments

@be-a-panther
Copy link

You wrote in the description for the meta format:

|keyid|string|The reference to the key used in the keyed-hash message authentication algorithm. If the default value is used, then the private shared key infected.|✓|
|openpgp-encrypted-key|string|Base64 OpenPGP message encrypting the reference keyid. This is optional as the key can be distributed in different means such as dedicated MISP API key or other secure channel.|-|

And in the example this:

"keyid": "tor-csam-lea",

Just to clarify the usage of this field:

  • the keyid can be the static key, which was used to generate the hashed keying?
  • as long as it is a printable string, this is the cleartext static key?
  • tor-csam-lea would be then the static key? Or is it just a reference, where the recipient has to do other stuff to get the static key?
  • if the field openpgp-encrypted-key is used, it contains the static key as string only encrypted with the public key of the recipient. The keyid contains then which value? infected? Or is the keyid field ignored?
  • Or do you have the openpgp key ID in mind The Key ID is the low-order 64 bits of the fingerprint. ?

And another questions:

  • Does it make sense that the keyid string gets inserted into the PSS as fast check whether the static key is valid?

  • Any reason to limit the encryption to openpgp? Despite the clash with librepgp/openpgp.

I would suggest to rename openpgp-encrypted-key to encrypted-key. Due the fact, that both parties need to establish a secure link somehow, they know how to deal with that. (The idea is to use age https://github.com/FiloSottile/age or tang https://github.com/latchset/tang ). If this field exists, the recipient can/must ignore the keyid field? Base64 encoded String should be sufficient.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant