Hey OpenPGP folks--
As the Design Team converges on the draft we hope to send to the WG for
last call, we wanted to raise placement of subpackets like algorithm
preferences (and other cert-wide or primary-key-specific metadata) in
OpenPGP certificates ("transferable public keys").
In v4 certificates, those subpackets have typically been stored in the
binding self-signatures for each User ID. In v5 certificates, the DT
intends to indicate that the algorithm preferences are stored entirely
on a direct-key signature on the primary key, and not on the UID
self-sig.
This will likely include the following subpackets whose meaning is only
relevant in a self-sig anyway:
- Preferred Symmetric Ciphers for v1 SEIPD
- Preferred Hash Algorithms
- Preferred Compression Algorithms
- Preferred AEAD Ciphersuites
- Key Expiration Time
- Key Flags (for primary key)
- Features
There are different reasons for this change, but the primary motivation
for the DT was simplicity.
While RFC 4880 and RFC 2440 both contain text describing disambiguation
between conflicting preferences based on which User ID binding signature
the preference packet was found in, and how the key was located, no one
in the DT identified a single real-world scenario where that was useful,
yet could not have been resolved by the user simply having two different
certificates, with separated user IDs.
These older RFCs themselves acknowledge that resolution of
ambiguously-stated preferences across differing signatures is not
fully-specified. This under-specification could lead to
interoperability problems when two distinct implementations make
different choices based on the same bytes on the wire. The fact that
self-indicated preferences could differ across User IDs was more of a
problem to be solved than a solution to a problem.
Looking for these subpackets only in a direct-key self-sig avoids the
need for a relying party to disambiguate between different points, and
permits a User ID self-sig to act explicitly as an independent assertion
of identity, orthogonally to claims about anything else in the
certificate.
Furthermore, when two OpenPGP implementations share access to a secret
key, they can reason more clearly about the announced preferences for a
given key when they know that they have access to the set of key
signatures (instead of another implementation managing a distinct -- and
possibly overriding -- user ID binding signature that the first doesn't
know about but the relying parties may see).
As a result of this set of changes, an OpenPGP v5 certificate MUST have
a direct-key self-signature if it wants to indicate any of these
preferences. This is also now reflected in the editor's copy of the
draft:
https://openpgp-wg.gitlab.io/rfc4880bis/#name-key-structures
The DT asked me to give the WG an early heads-up on this because it
represents a change from the way we've handled v4 certificates. We hope
it's a simplifying change that will make life easier for future
implementers and users of OpenPGP.
Feedback welcome, as always,
--dkg
PS here are some discussion points and relevant merge requests for those
interested in the history of this process.
https://gitlab.com/openpgp-wg/rfc4880bis/-/issues/42
https://gitlab.com/openpgp-wg/rfc4880bis/-/issues/95
https://gitlab.com/openpgp-wg/rfc4880bis/-/issues/103
https://gitlab.com/openpgp-wg/rfc4880bis/-/merge_requests/134
https://gitlab.com/openpgp-wg/rfc4880bis/-/merge_requests/153
https://gitlab.com/openpgp-wg/rfc4880bis/-/merge_requests/168
signature.asc
Description: PGP signature
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp