I'm new to GPG signing and the intricacies are dizzying, as my other, overly-broad question indicates. So let me try to distill my current doubts into a simple question.
Let's say that a company Acme wants to sign some artifacts for publishing on Maven Central. From much research from various sources I glean the following best practices:
- Acme should have one single primary key, e.g. for
id@acme.example.com
. - Acme should generate subkeys for general day-to-day use, such as signing Maven artifacts.
- There are hardly any legitimate uses for the "comment" portion of a GPG user ID, and this field should be left blank.
Unfortunately Maven tools do not work with signing using a subkey. So that means Maven is forcing Acme to change how they manage their central identity, id@acme.example.com
! Acme can no longer follow best practices. Most problematic is that Acme risks compromise of its central identity (e.g. for signing financial statements) if it gives the development team access to the primary key in order to sign Maven artifacts.
So to simulate subkeys, Acme could create a key for a different email address, such as software@acme.example.com
, and give that primary key to the development team for signing Maven artifacts. But then when listing keys on a public key server, a search for "Acme" would show up like this:
Acme <id@acme.example.com>
Acme <software@acme.example.com>
To me this seems confusing. I could therefore use the comment field "software" to indicate "this is the key we are using to sign software artifacts because Maven is so dense that it won't let us use subkeys of our main identity for this purpose". Thus the two Acme keys would be listed like so on a public key server:
Acme <id@acme.example.com>
Acme (software) <id@acme.example.com>
Because several writers are very adamant that most uses of the comment field are not legitimate, I ask: Is this sort of "key-purpose" designation a legitimate use of the comment of a GPG user ID? Or would it be more appropriate to use separate id@acme.example.com
and software@acme.example.com
keys? Or simply use one primary id@acme.example.com
key and let the development team have access to it?