Re: [openpgp] 1PA3PC: first-party attested third-party certifications (making Key Server Prefs no-modify actionable)

[Daniel Kahn Gillmor <[e-mail]>]

Hi Werner--

Thanks for the prompt feedback.  I've updated the merge request to
account for these suggestions.  I've pushed my changes to gitlab, i'd be
happy for any review, either on the merge request or here.

The overall patch is also attached below, along with some discussion.

On Wed 2019-08-28 09:53:39 +0200, Werner Koch wrote:
> Putting this into a standard-self signature is troublesome because this
> requires to update and distribute the self-signature as soon as one
> uploads to a keyserver.

I agree with you that moving it to its own, dedicated signature class
helps to keep the concepts and updates separate, and that's a win.  In
particular, it allows the keyholder to make a distinct set of
attestations without having to worry that some legacy implementation
that updates the traditional self-sigs (e.g. updating the expiration
date) will accidentally drop the attestations in the meantime.  It also
lets clients update their self-sigs and their attestations in a
different cadence.

In my revised merge request, i've added a dedicated signature class
(0x16: Attestation Key Signature) which is the only thing that holds the
Attested Certifications subpacket.

> We need to have a way do include more key signatures.  This can easily
> be done with several of such self-signatures using the same creation
> date or another mechanism to connect them. An upper limit on the number
> of such self-signatures may be suggested in the implementation nits.

I am not convinced that anyone has a meaningful need to attest to more
than two thousand third-party certifications (a 64K-octet subpacket
containing 2K 32-octet SHA256 digests), but you're right that we can use
this "matching creation timestamp" approach to extend such a mechanism
to arbitrary numbers of attestations.  I've included those semantics in
my revision.

> The requirement to sort the hashes is not really helpful because that
> requires that the implementation must check the order and decide what to
> do if they are not sorted. In practice the implementation will sort them
> anyway (in particular if several self-signatures are required).

You're right that this MUST was too strict, and that implementations
will end up sorting them anyway.  I've reduced it to a SHOULD because it
can be handy, but obviously things shouldn't break if they're not
sorted.  Thanks for catching this.

> It should also be up to the implementation on how to match them.

I'm not sure what you mean by this -- it seems very important to me that
there is a clear and unambiguous way to match an attestation to a
third-party certification.  These attestations are not merely pointers
to certifications, they are cryptographic assertions about them.

> The subpacket definition should include a version number or digest
> algorithm to be future prove.

I think that including a version number in the subpacket is premature
optimization.  If we decide to do something different in the future, we
can use a new subpacket definition, and just deprecate this one.  We
have lots of room to spare, and making something simple and fixed is
better.

If we start running out of subpacket identifiers, we can designate one
last remaining subpacket identifier to be a multiplexer into a new space
of subpacket IDs, but i don't want every existing subpacket to itself be
multiplexed internally.

> We should of course use SHA-256 and not SHA-512.

I agree with you that we want the choice of digest fixed in the
subpacket -- and all attestations in the signature should use the same
digest.  And i don't want to include any sort of explicit digest field
identifier in the subpacket, because i don't want consumers of these
things to have to reason about "is it going to be OK to have a signature
made over blake2b covering a series of MD5-based attestations".

But rather than hard-code SHA-256 (or SHA-512 or something else), I've
bound the digest used in the Attested Certifications subpacket to the
digest used in the Attestation Key Signature itself.  This means:

 * we don't have to get into any arguments about the relative strength
   of a digest in one place or another.  if you're ok with it for the
   signature, you should be ok with it as the attestation.

 * if the certficate holder is uncomfortable with the properties of any
   particular digest (or they're deploying in a highly-opinionated or
   constrained environment), they can just choose to make their
   Attestation Key Signature with a digest that meets their needs.
   Their certificate as a whole can depend on one specific digest,
   without having accidentally introduced a hard-coded dependency.

FWIW, i agree that SHA256 sense to use today, but if someone wants to
make a certificate that is entirely free of SHA256, this lets them do
it, without providing enough rope to get tangled up in.

I've made some new demonstration certificates with this new approach
(and my example does use SHA256):

The signer's certificate (the "third party"):

-----BEGIN PGP PUBLIC KEY BLOCK-----

xjMEXWcuXBYJKwYBBAHaRw8BAQdAIjn6AW4wgrQ7hI66BZkaCzL2X/bRX+yf1tm8
4OxSkULNJkNlcnRpZmljYXRlIEF1dGhvcml0eSA8Y2FAZXhhbXBsZS5jb20+woQE
ExYIACwFAl1m9hwCGwECFQgCF4ACGQECHgEWIQTBvMlvJO6/G++jDVQ953dEaeBc
DQAKCRA953dEaeBcDc8hAP9it7GkIgG1Sisa8e46SJIZRfWAcT1vzAmv8k57jY/P
HAEAizCu8jGLKp5AHWLNIU2ah9tEEEch5q4GI7tqMbu5IQU=
=rn/T
-----END PGP PUBLIC KEY BLOCK-----

The first party, along with a standard self-sig, a third-party
certification, and an Attestation Key Signature attesting to the
third-party certification:

-----BEGIN PGP PUBLIC KEY BLOCK-----

xjMEXWcuXBYJKwYBBAHaRw8BAQdAPeDThwKKsiEAR8GwQBzv94FnDhyc9+NtXoH+
4LGxhh7NHFRlc3QgVXNlciA8dGVzdEBleGFtcGxlLmNvbT7ChAQTFggALAUCXWb2
HAIbAQIVCAIXgAIZAQIeARYhBHZ7/PJBbYUZS/wOEE/bnIu8dqmjAAoJEE/bnIu8
dqmjYvcA+wbxprn1NQfP6uY19plBu/WRPnCAj6Tnte4KUThl48dMAQCuIURYGmK4
znKmav/bnDgp+bLSrfo/4tE1SK1/fudRAMJ1BBAWCAAdBQJdZvYmFiEEwbzJbyTu
vxvvow1UPed3RGngXA0ACgkQPed3RGngXA3pGAEAzyIb8BtrLb6Oi1eY/JLje/i/
lmWO46EoWe0Rh8J8gC8BAPV6/txR65Qa4DaMw26GyHk8uGTzxiRyH6q62Xpwcx8K
wpcEFhYIAD8FAl1m9jAhJTA+FEO+y68KkjvvIGaLNBfj/pHb2IeYj2/C6ecXEJgy
FiEEdnv88kFthRlL/A4QT9uci7x2qaMACgkQT9uci7x2qaOxNwD/SLpQxMKZX4ys
nmjuV2+VwpwOhlBBAZsX+eRkqDlPUicBAI9EZo/fmuzXzG3D6FrUB0rfgVdiDTy6
EB6DaIpVWGQJ
=FDhV
-----END PGP PUBLIC KEY BLOCK-----

Please let me know what you think!

       --dkg