[openpgp] 1PA3PC: first-party attested third-party certifications (makin

Hi OpenPGP folks--

The "No-modify" flag for Key Server Preferences has never been
particularly actionable, because the keyserver has no way to tell
whether the certificate-holder intends for third-party certifications to
be redistributed or not.

After a few discussions with other implementers offlist [0], i'm
proposing a new, simple way that the certificate holder (the "first
party") can attest to some number of specific third-party
certifications, to indicate that they're redistributable.

[0] https://gitlab.com/dkg/draft-openpgp-abuse-resistant-keystore/issues/1
    and several discussions on #hagrid on IRC

The shorthand for this "first-party attestation of third-party
certifications" is 1PA3PC.

The abuse-resistant keystores draft makes clear that such an attestation
is necessary to be able to distribute third-party certifications while
retaining first-party sovereignty over the certificate.  But that draft
(up through version -04) proposes a more-complicated mechanism using
third-party confirmation signatures embedded in unhashed subpackets.

The new mechanism i'm proposing here is just a list of digests over
third-party certifications, stored in a hashed subpacket in the
self-sig.  This has two major advantages over the more complex proposal:

 * it's simpler to specify and to implement.

 * the first party can pretty easily change their mind about their
   preferred attestations for a given User ID by issuing a new self-sig;
   no need for juggling/redistributing explicit revocations of the
   attestations from the first party, which made the abuse-resistant
   keystore draft much uglier.

There are two downsides as i see it, neither of them particularly bad:

 * there is an overall space limitation in the hashed subpackets (64KiB
   tops, probably less given other overhead), so the keyholder can't
   attest to arbitrarily many third-party certifications.  However, even
   when using SHA512 (64B per attested certification), with even tighter
   constraints (like autocrypt, where the whole cert must be < 10KiB),
   there is still room for attestation of dozens of third-party
   certifications.  That's more than enough for reasonable use.

 * It encourages/requires certificate holders to issue new self-sigs
   when they want to change their attestations.  If a certificate store
   that doesn't prune superseded self-sigs encounters a rapidly-changing
   set of attestations, this might cause a bit of bloat.  But the
   certificate store can just start pruning to fix that problem.

This new proposal (diff for RFC 4880bis attached) claims subpacket
codepoint 37 for shipping these attestations.  I've also put this
proposal as a merge request here:
https://gitlab.com/openpgp-wg/rfc4880bis/merge_requests/20

1PA3PC test vector and example
------------------------------

Below is an example of this form of 1PA3PC, using ed25519.

The third-party certifier:

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

xjMEXWYJVBYJKwYBBAHaRw8BAQdAFa8edTtqPPjjMVwac8Z+LCTbQLJv8zE7YI/8
TB8Wo7vNJkNlcnRpZmljYXRlIEF1dGhvcml0eSA8Y2FAZXhhbXBsZS5jb20+wm0E
ExYIABUFAl1l0RQCGwECFQgCF4ACGQECHgEACgkQCzDFEKWiYTfSTgEAr5HQLoxx
JLEYiEwLfixmGj5O0egfuQ8w/j+TovDvacMA/iUe9H8oyxqGKFoTn5hj0abG72mL
BWGh2++7J+BpUI8A
=W+bG
-----END PGP PUBLIC KEY BLOCK-----

The end user certificate, with the third-party certification and a
self-sig that attests to it:

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

xjMEXWYJVBYJKwYBBAHaRw8BAQdA3RPxU734ifWKfZMLChBCYYCD3Pq6mV1RFyhh
H4vSq77NHFRlc3QgVXNlciA8dGVzdEBleGFtcGxlLmNvbT7CXgQQFggABgUCXWXR
HgAKCRALMMUQpaJhN3V/AQD8tnvWlpuXEjPDX4jxJ9COhobYS3UG8Id4i0Mhe/4c
wAD8DehW+aDn7+Nv0qPJrUuyDeODHj7/MCvvEaxltrgjkQ/CjwQTFggANwUCXWXR
KAIbAQIVCAIXgAIZAQIeASElZykynZ95I3ov66EDuDZE1g6By2V0gE0Z0RlkE1DT
CsQACgkQ1NdAbG04n/QVxwEAgZ812nc7lqISocouns7Z7Zi7LHj8RyI9JrpmmDio
fXkA+wRUUxgsQ63nyWfOJDvMl5Z57IKQOvlWJrtmSZ9ORGwG
=ApYY
-----END PGP PUBLIC KEY BLOCK-----

I'd be happy to hear any feedback, both about the proposed patch to the
spec, and about the test vector i've included here.

      --dkg

From eedb828e08d48e3749757035e4b114d7ea2b6650 Mon Sep 17 00:00:00 2001
From: Daniel Kahn Gillmor <dkg(_at_)fifthhorseman(_dot_)net>
Date: Wed, 28 Aug 2019 00:01:07 -0400
Subject: [RFC4880bis PATCH] Describe "Attested Certifications" subpacket

The "no-modify" flag in the Key Server Preferences subpacket has never
had a clear indication of how a keyserver can effectively respect it.

This changeset describes an "Attested Certifications" subpacket that
makes "no-modify" actionable by a keyserver.  A keyserver that
respects this flag will only redistribute third-party certifications
that have been attested to by the certificate owner.

Signed-off-by: Daniel Kahn Gillmor <dkg(_at_)fifthhorseman(_dot_)net>
---
 middle.mkd | 69 +++++++++++++++++++++++++++++++++++++++++++++++++++---
 1 file changed, 66 insertions(+), 3 deletions(-)

diff --git a/middle.mkd b/middle.mkd
index 51f71a6..222f6ca 100644
--- a/middle.mkd
+++ b/middle.mkd
@@ -1058,6 +1058,7 @@ The value of the subpacket type octet may be:
           32   Embedded Signature
           33   Issuer Fingerprint
           34   Preferred AEAD Algorithms
+          37   Attested Certifications
   100 to 110   Private or experimental
 
 An implementation SHOULD ignore any subpacket of a type that it does
@@ -1451,9 +1452,15 @@ This is a list of one-bit flags that indicate 
preferences that the key
 holder has about how the key is handled on a key server.  All undefined
 flags MUST be zero.
 
-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.
+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.
+
+    If No-modify is set on the most recent self-sig over a user ID,
+    then a keyserver should only redistribute those third-party
+    certifications over that user ID that have been attested to within
+    the self-sig (see "Attested Certifications" below).
 
 This is found only on a self-signature.
 
@@ -1675,6 +1682,62 @@ signature, the key ID of the Issuer subpacket MUST match 
the low
 Note that the length N of the fingerprint for a version 4 key is 20
 octets; for a version 5 key N is 32.
 
+#### Attested Certifications
+
+(N octets of certification digests)
+
+This subpacket only appears in a self-signature as a hashed subpacket,
+attesting to a set of third-party certifications over the same
+underlying data that the self-signature is made.  This subpacket
+enables the holder of an OpenPGP primary key to mark specific
+third-party certifications over their User ID as re-distributable with
+the rest of the transferable public key (see the "No-modify" flag in
+"Key Server Preferences", above).  Implementations SHOULD include at
+most one Attested Certification subpacket in any generated self-sig.
+
+The contents of the subpacket consists of an ordered series of digests
+using the same hash algorithm used by the signature itself.  Each
+digest is made over one third-party signature (a Certification, of
+signature type 0x10-0x13) that covers the same Primary Key and User ID
+(or User Attribute).  For example, a self-signature made by key X over
+user ID U using hash algorithm SHA512 might contain an Attested
+Certifications subpacket of 192 octets (3*64 octets) covering three
+third-party certification Signatures over <X,U>.  They MUST be ordered
+by binary hash value, so a hash with hexadecimal value
+037a... precedes a hash with value 0392..., etc.  The length of this
+subpacket MUST be an integer multiple of the length of the hash
+algorithm used for the signature.
+
+The listed digests MUST be calculated over the third-party
+certification Signature packet as described in the "Computing
+Signatures" section, but without a trailer: the hash data starts with
+the octet 0x88, followed by the four-octet length of the Signature,
+and then the body of the Signature packet. (Note that this is an
+old-style packet header for a Signature packet with the
+length-of-length field set to zero.)  The unhashed subpacket data of
+the Signature packet being hashed is not included in the hash, and the
+unhashed subpacket data length value is set to zero.
+
+If an implementation encounters more than one such subpacket in a
+self-sig, it MUST treat it as a self-sig with a single Attested
+Certifications subpacket containing the union of all hashes.
+
+As with other subpackets, The Attested Certifications subpacket in the
+most recent self-sig over a given user ID supersedes all Attested
+Certifications subpackets from any previous self-sig.
+
+If a keyholder Alice has already attested to third-party
+certifications from Bob and Carol and she wants to add an attestation
+to a certification from David, she should issue a new self-sig (with a
+more recent Signature Creation timestamp) that contains an Attested
+Certifications subpacket covering all three third-party
+certifications.
+
+If she later decides that she does not want Carol's certification to be
+redistributed with her certificate, she can issue a new self-sig
+(again, with a more recent Signature Creation timestamp) that contains
+an Attested Certifications subpacket covering only the certifications
+from Bob and David.
 
 ### Computing Signatures
 
-- 
2.23.0.rc1

signature.asc
Description: PGP signature

_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp