key distribution/verification/update mechanisms other than keyservers

[Daniel Kahn Gillmor]

On Wed 2018-01-17 09:58:21 +0100, Werner Koch wrote:
> On Tue, 16 Jan 2018 22:56, kristian.fiskerstrand at sumptuouscapital.com
> said:
>
>>>  (c) rejected all third-party certifications -- so data attached to a
>>>      given primary key is only accepted when certified by that primary
>>>      key.
>>> 
>>
>> thanks for this post Daniel, my primary question would be what advantage
>> is gained by this verification being done by an arbitrary third party
>
> This can help to avoid DoS attacks.  I would love to see that to get my
> key down to a reasonable size. 
>
> OpenPGP specifies Key Server Preferences (5.2.3.17) with just one flag:
>
>    First octet: 0x80 = No-modify the key holder requests that this key
>    only be modified or updated by the key holder or an administrator of
>    the key server.
>
> By default GnuPG sets this flag but unfortunately it has no effect
> because it is not defined on how the keyserver can check this condition.

please see also the thread on sks-devel from december 2016 with the
subject "nokeyserver annotation" -- if we're designing a new, parallel,
more narrowly-focused keyserver network we should make sure to include
that as well.

> A way to implement this without requiring an external protocol would be
> an extension to OpenPGP to either allow an Embedded Signature (5.2.3.26)
> in a key signature.  With ECC this would not increase the size of a key
> signature too much.  It puts a burden on the keyservers to check this
> signature during an upload, though.

I think you're describing a way to permit such a narrowly-scoped
keyserver to be slightly more broad -- to allow third-party
certifications to be published.

i don't think you need an extension to OpenPGP at all to do this -- you
just need policy.  The policy could be (for example):

 * if a third-party certification is present, discard it unless all of
   the following are true:

   a) it has the "issuer fingerprint" subpacket in the hashed subpackets
   
   b) the issuing key is itself is known to the keyserver
   
   c) the certification is cryptographically correct

   d) there is an Embedded Signature subpacket in the unhashed
      subpackets from the primary key, over the existing signature
      *with unhashed subpackets discarded*

   e) the embedded signature is cryptographically valid

but the simplest thing would be to start without third-party
certifications at all -- making this strictly for self-certification
updates (expiry, revocation, key-rotation).

wdyt?

        --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180117/4ebbc00a/attachment-0001.sig>