limiting scope of signing subkeys
Guilhem Moulin
guilhem at fripost.org
Tue Jun 6 21:23:04 CEST 2017
On Mon, 05 Jun 2017 at 16:34:57 -0400, Daniel Kahn Gillmor wrote:
> 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.
Oops yeah, apologies for hijacking the thread :-/
> 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?
That's correct indeed.
> 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".
I recall you and I discussed that on #debian-keyring a while ago
(probably around the time I sent that mail to gnupg-devel) :-P Adding
another capability sounds neat, but IMHO that won't scale if other folks
want to limit the scope of their signing subkeys to other domains /
types of data.
> 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?
As I envisioned it that new option ‘--assert-notation=’ should make gpg
and gpgv reject signatures made with a signing (sub)key that is lacking
the given notation. With (yet :-/) another flag, the program would
relax the behavior to accept the signature when *none* of the
*non-revoked* signing (sub)keys have the given notation.
Then of course one would need to pass these options to all signature
verifiers; but when signature verification is done centrally like in the
case of Debian it sounds feasible, right?
--
Guilhem.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: </pipermail/attachments/20170606/29243585/attachment-0001.sig>
More information about the Gnupg-devel
mailing list