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

From: Daniel Kahn Gillmor <[email-masked]>
Date: Sun, 01 Sep 2019 07:47:39 -0400

On Fri 2019-08-30 13:47:57 -0400, Daniel Kahn Gillmor wrote:
> If you're generally ok with the protocol mechanism for attestations
> proposed here, i'd be happy to share my notes for what i think a initial
> interface for managing attestations with GnuPG might look like -- i can
> do that on https://dev.gnupg.org/, or on [email-masked], wherever
> you prefer.

I've made some suggestions over on https://dev.gnupg.org/T4694, and
followed up on gnupg-devel as well.  happy to get feedback on the
suggestions!

         --dkg

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Sun, 01 Sep 2019 22:22:10 -0400

Hi Ben--

On Sat 2019-08-31 01:04:19 -0500, Benjamin Kaduk wrote:
> It looks like this is in an "IETF Review" registry; please please please
> consider making a request for an RFC 7120 early allocation.
> I know the risk is probably less of conflicting codepoint squatting in
> openpgp than in TLS, but in TLS we managed to have *three* different
> extensions squatting on the same codepoint, and it is pretty unpleasant to
> resolve.

Thanks for this heads-up.  While i agree that an early allocation is a
good idea, given the defunct state of the WG (which is my fault as much
as anyone's), i don't know that we meet the guidelines for IANA early
assignment.  But your perspective and opinion on as security area AD is
welcome -- if you think this is the right thing to do, i'm happy to try
to facilitate it.

Thus far, I've been trying to keep all proposed updates to rfc4880bis
that affect registries/codespace filed in gitlab, where we can track
them to try to avoid collisions:

    https://gitlab.com/openpgp-wg/rfc4880bis/merge_requests

The affected registries thus far outstanding that i'm aware of are:

 * Subpacket Type:

  - 35: Intended Recipient
      (https://gitlab.com/openpgp-wg/rfc4880bis/merge_requests/19)
  - 36: Designated Revoker
      (https://gitlab.com/openpgp-wg/rfc4880bis/merge_requests/18)
  - 37: Attested Certifications
      (https://gitlab.com/openpgp-wg/rfc4880bis/merge_requests/20)

 * Signature Class:

  - 0x16: Attestation Key Signature
      (https://gitlab.com/openpgp-wg/rfc4880bis/merge_requests/20)

I think if we want to get them into an IANA pre-allocation, the next
step is to have a new version of the Internet-Draft published where the
relevant changes are merged, right?

Of these three, it looks to me like "Intended Recipient" (MR 19) already
has multiple interoperable implementations, and "Attested
Certifications"+"Attestation Key Signature" (MR 20) appears to be
relatively uncontroversial.

"Designated Revoker" (MR 18) has raised the most objections on the list,
perhaps in part because it explicitly deprecates the old "Revocation
Key" subpacket.

Perhaps we should make a new revision of rfc4880bis with MRs 19 and 20
merged, since the jury is still out on MR 19.  Then we can use that as
the basis for the IANA pre-allocation.  Does that seem like a reasonable
next step?

     --dkg

---

From: Werner Koch <[email-masked]>
Date: Fri, 06 Sep 2019 09:49:43 +0200

> relatively uncontroversial.

I have merged these two patches.

> perhaps in part because it explicitly deprecates the old "Revocation

I didn't stepped into the discussion but I do not see a reason for it.
it adds so much complexity to this area and it seems to be out of scope
of the original goal of that WG.  In fact we already added more stuff
than planned and long winding discussion about implementaion details led
to the clsong of the WG.

The attestation thing is really useful to keep current OpenPGP workflows
alive.

> the basis for the IANA pre-allocation.  Does that seem like a reasonable

Will do so.

Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.