Expected GPG user ID for Maven Central artifacts?

Question

I was going through the (seemingly intricate) procedures for getting a company's artifact on Maven Central. Then I got to the GPG signing part and entered a new world of confusion and conundrums. GPG has so many options, and it's not evident what a reasonable practice should be for signing company artifacts.

Let's say that Acme wants to publish an artifact org.example.acme:foobar:1.0.0 to Maven Central. What user ID should they use to sign it? What subkeys? How would that key be kept separate from the user's personal key?

Let me go through all the doubts to give you an idea of why it is confusing.

• What email should I use for Acme? Should I use [e-mail]? Should the identity be for Acme, or a division of Acme? Or should only individuals sign artifacts for publication on Maven?
• What about the comment? One source said we should leave comments out altogether. Should I use "Acme (software) [e-mail]"? Or just "Acme [e-mail]".
• OK, so maybe you say it doesn't matter, and that all this is opinion based, and I can use whatever works for my company---fine. But then how do I keep my company and personal ID separate? Can I have a key for Acme and a separate key for John Doe on the same keyring on the same computer? How would I then distinguish them when publishing artifacts? All of the examples seem to assume you are using a single identity.
• Should I be using subkeys? Should I create different subkeys for different departments? Or different identities for the same subkeys? Or what?
• Should I make my keys expire? Or just the main key? Or just the subkey?

I could go on and on and on... Trying to summarize, all the examples seem to assume 1) the user only has one user ID installed on their keyring, and 2) everyone signing their artifacts are individuals, not companies.

What is the expected approach for signing the Maven artifact of an organization; and how does a user manage the organization's key separately from the user's individual key?

Answer 1

What email should I use for Acme? Should I use [e-mail]? Should the identity be for Acme, or a division of Acme? Or should only individuals sign artifacts for publication on Maven?

Use the one that is used for public communication of the group/department using the key. For a smaller company, I'd probably go for some generic address like [e-mail].

Don't mix in persons. This is a company key, which identifies the company (or a specific function inside the company) and not an individual.

What about the comment? One source said we should leave comments out altogether. Should I use "Acme (software) [e-mail]"? Or just "Acme [e-mail]".

Does the "software" comment add any relevant information? I don't think so, so leave it away as it just adds noise.

Often, something like "signing key" is added as a comment for such keys. I don't consider this necessary, as the usage is obvious. If you want to prevent others sending encrypted mail using that key, better limit key usage to signing only, which enforces this limitation (and does not just ask other users not to use the key for encryption).

OK, so maybe you say it doesn't matter, and that all this is opinion based, and I can use whatever works for my company---fine. But then how do I keep my company and personal ID private? Can I have a key for Acme and a separate key for John Doe on the same keyring on the same computer? How would I then distinguish them when publishing artifacts? All of the examples seem to assume you are using a single identity.

You can have an arbitrary number of keys on your computer, that's not an issue. Maven (and other software relying on GnuPG) can be configured to use a specific key. Usually, you can either put a user ID, mail address, key ID or fingerprint in there -- as this is a one-time-configuration, better use the most specific way, the fingerprint.

Should I be using subkeys? Should I create different subkeys for different departments? Or different identities for the same subkeys? Or...

Yes, you should. This is an important key. Keep the primary key offline (in a safe, ...; with very narrow access for others but the most important people/managers in the organization). Only hand out subkeys limited to signing: you either put such a key on a build server, or hand it to the employee who is pushing the builds. If you need to exchange a key, you don't have to change the primary key, but only the subkey (which is not a lot of effort, and especially does not involve telling your customers about the new key).

To mitigate employees leaving the company taking copies of the key, take advantage of OpenPGP smart cards (which might also be a YubiKey). The key cannot be fetched from the card, so theft of the key is equal to theft of the card (and can hardly go unnoticed).