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

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

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