limiting scope of signing subkeys [was: Re: OpenPGP Secret Key Transfer]

Daniel Kahn Gillmor dkg at fifthhorseman.net
Mon Jun 5 22:34:57 CEST 2017


On Mon 2017-06-05 16:12:15 +0200, Guilhem Moulin wrote:
> For signature verification I think we would need some mechanism to tell
> GnuPG to limit the scope of this or that subkey.  FWIW I brought that up
> to gnupg-devel in autumn 2015, and proposed to use certification
> notation to limit subkey scopes:
>
>     https://lists.gnupg.org/pipermail/gnupg-devel/2015-November/030576.html
>
> (I wish I could limit the scope of the signing subkey I use for Debian
> packages for instance, and take it offline. ;-)

I think this is an entirely different feature request than the one that
Werner was talking about, which is why i've changed the Subject: line
here.

If i understand you correctly, i think you want more than just limiting
the scope of your debian package signing subkey -- i think you want to
limit the scope of your e-mail signing subkey so that it will not be
considered acceptable for signing debian packages.  is that right?

to make a new subkey and mark it as capable only for package signing is
just a matter of making up a new notation and marking it with *no*
capabilities otherwise (or to mark it as just package-signing).  But to
get you the security constraints you want, you'll need to mark the
*other* subkeys as incapable of signing packages.

I'm happy to talk this over further -- the other approach would be to
have a capability that means "signing software" as distinct from
"signing messages" or "certifying identities".  From an API perspective,
i'm not sure how you'd phase that in on top of the existing signature
verification API.  How should GnuPG learn that the thing you're
verifying is in the "software" domain as opposed to the "e-mail message"
domain?

        --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: </pipermail/attachments/20170605/4b385337/attachment.sig>


More information about the Gnupg-devel mailing list