# How to add a comment to gpg keys

Export it as follows:

```bash
gpg --export --armor --comment '<keyid>' <add comments for every line in ` gpg -k`> <key_name> > key_out.gpg
```

or add it manually, the supported options include (RFC4880):

- "Version", which states the OpenPGP implementation and version
  used to encode the message.

- "Comment", a user-defined comment.  OpenPGP defines all text to
  be in UTF-8.  A comment may be any UTF-8 string.  However, the
  whole point of armoring is to provide seven-bit-clean data.
  Consequently, if a comment has characters that are outside the
  US-ASCII range of UTF, they may very well not survive transport.

- "MessageID", a 32-character string of printable characters.  The
  string must be the same for all parts of a multi-part message
  that uses the "PART X" Armor Header.  MessageID strings should be
  unique enough that the recipient of the mail can associate all
  the parts of a message with each other.  A good checksum or
  cryptographic hash function is sufficient.

  The MessageID SHOULD NOT appear unless it is in a multi-part
  message.  If it appears at all, it MUST be computed from the
  finished (encrypted, signed, etc.) message in a deterministic
  fashion, rather than contain a purely random value.  This is to
  allow the legitimate recipient to determine that the MessageID
  cannot serve as a covert means of leaking cryptographic key
  information.

- "Hash", a comma-separated list of hash algorithms used in this
  message.  This is used only in cleartext signed messages.

- "Charset", a description of the character set that the plaintext
  is in.  Please note that OpenPGP defines text to be in UTF-8.  An
  implementation will get best results by translating into and out
  of UTF-8.  However, there are many instances where this is easier
  said than done.  Also, there are communities of users who have no
  need for UTF-8 because they are all happy with a character set
  like ISO Latin-5 or a Japanese character set.  In such instances,
  an implementation MAY override the UTF-8 default by using this
  header key.  An implementation MAY implement this key and any
  translations it cares to; an implementation MAY ignore it and
  assume all text is UTF-8.