2

As discussed in this answer, gpg does not offer the capacity for subkeys to certify (eg. "sign") other keys, though there may be good reason why it should, and they do sign at least one key. As a practical matter, for those of use who keep our master secret key, in which resides the certifying capacity, offline, this is both a headache when trying to sign other peoples' keys, as well as a security risk. As a result, I would like to "cons up" a certificate that effectively has a certifying subkey. My idea is like this:

On my offline machine I generate:

Master key0 (C=certifying) - does not expire
Subkeys (E, S & A = Encrypting, Signing, Authenticating) - expires

Master key1 (C) - expires
No Subkeys

Now I do cross-signing, as discussed here:
key0 signs key1.
key1 signs key0.

I remove the key0 private key and keep it offline.

I take to my daily driver:

Master key0 (.public) + Subkeys (.public & .private) + key1 signature
Master key1 (.public & .private) + key0 signature

key1 is effectively my subkey with certifying authority.

My question is, have I missed anything here? Besides cross-signing, is there any structure to an OpenPGP Certificate that I have failed to include, and which might be a security vulnerability?

Also, if someone were to sign my key, would it not be sufficient for them to sign the certificate containing key0? Since I've cross signed with key1, trust of key0 should automatically mean trust of key1.

Diagon
  • 233
  • 1
  • 7

1 Answers1

0

While I am still looking for an answer here, I have found some clarity on how cross signatures should be done. I've given a full answer here, but basically, using --default-cert-level 3 would be sufficient. It would also be necessary to attend to the trust model, which is described at that link.

Diagon
  • 233
  • 1
  • 7