Re: [openpgp] a new draft overlapping the WG draft

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

Hi Kai--

Thanks for proposing some technical paths for consideration.

I'd like to try to clarify some details of what you're proposing, and
to identify how they are related to the current siutation the WG finds
itself in.

First, i should note that no matter what we decide here, there will be a
multi-year transition process from RFC 4880 to whatever the new standard
ends up being.  (This WG does need to decide on a singular new standard,
not a plural -- if i were a new developer considering whether to add
OpenPGP support, i would be very wary of approaching a mess where there
are multiple divergent "new" standards)  No matter what, messages formed
in compliance to RFC 4880 will also continue to persist indefinitely.
This is just the reality of having a deployed base in a
store-and-forward communications medium.

Your message talks a lot about dealing with RFC4880 and whatever new
standard comes out.  For those who haven't read the draft in detail,
draft-ietf-openpgp-crypto-refresh (hereafter "crypto-refresh") already
captures a lot of this thinking, as the design-team was very focused on
what deployment should actually look like given the deployed base of
implementations compliant with RFC 4880.

draft-koch-openpgp-2015-rfc4880bis-00 (hereafter "draft-koch")
represents a very small revision of the much older
draft-ietf-openpgp-rfc4880bis-10 (hereafter "rfc4880bis-10"), which had
been abandoned when the previous incarnation of the WG failed to reach
consensus and was dissolved.

crypto-refresh represents the re-incorporation into rfc4880 of many of
the changes from rfc4880bis-10, via review by the design-team of all of
the outstanding changes, as augmented by active discussion and
additional concerns that were raised as well.

On Sat 2022-10-08 01:39:44 +0200, Kai Engert wrote:
> * introduce the concepts of openpgp specification versions, and minimum 
> supported openpgp versions

All of the internet-drafts under discussion here have explicit
versioning in the wire formats that they contain.  OpenPGP (RFC 4880)
provides version information in at least these locations (perhaps
someone with a more comprehensive understanding of OpenPGP can identify
additional version numbers):

 - public key packets and their close cousin, secret key packets
 - public key encrypted session key packets (PKESK)
 - symmetric key encrypted session key packets (SKESK)
 - signature packets and the related "one-pass signature" (OPS) packet
 - symmetrically-encrypted integrity-protected data packet (SEIPD)
 - user attribute packet's image attribute subpacket header is versioned

These version numbers are *not* synchronized between each other.  For
example, a v4 key typically makes a v4 signature, but precedes it with a
v3 OPS packet.  And someone encrypting (with integrity-protection) to a
v4 key will use a v1 SEIPD packet.

Also, not every one of these version numbers is under consideration for
revision: no one has raised any interest in trying to bump the version
number for the user attribute packet's image attribute subpacket header.

> * Declare that a public key packet can specify the minimum OpenPGP 
> version the key owner's software supports (define how public key packets 
> could signal that). Find a way to encode that in a way that doesn't make 
> public key packets incompatible with current GnuPG. If it's necessary to 
> define an evolution of public key packets, try to reach consensus with 
> GnuPG developers on how to do that.

Note that advertisements for "supported versions" are already present in
places where *this makes sense to do*.  But it does not make sense to
require signalling support in all possible contexts.  For example, an
implementation that does not know how to interpret a v9 key cannot
possibly verify a signature from such a key, regardless of what version
that signature is.

The primary form of version-supported advertisement is noted in the
"Features" subpacket, found in a self-sig, where bit 0x01 indicates that
the keyholder supports v1 of SEIPD (a.k.a. "Modification Detection Code"
or MDC).  In crypto-refresh, bit 0x08 indicates support for v2 of SEIPD,
which uses AEAD mechanisms instead of MDC for integrity protection.

> * Release crypto-refresh as a new OpenPGP version 5, not as a successor 
> for RFC 4880.

Any document released by this working group will be a successor for RFC
4880.  This is what the working group is explicitly chartered to do.  We
will not release a WG document that is not a successor to RFC 4880
without explicitly re-chartering.  I don't think we should re-charter
until we demonstrate that we are capable of completing our current
charter.

> * For public keys that lack the new OpenPGP version flag, assume the key 
> owner is limited to RFC 4880 features, only.

This is already not the case.  For example, there are thousands of
explicitly-marked v4 keys that support curve 25519, which is not in RFC
4880 (my own OpenPGP certificate, which this message is signed with,
uses this algorithm).  It's not clear what the ecosystem would gain from
implementations assuming something that is clearly untrue.

Both crypto-refresh and draft-koch agree on how curve25519 is specified
for wire format, though crypto-refresh has been through several rounds
of revision and clarification that make the specification less ambiguous
and easier to understand.

> * Declare that for messages that are signed, only, the signature packet 
> should be limited to RFC 4880, or a future universally accepted 
> successor (which is currently not in sight). The reason is that for 
> signed-only messages, it isn't necessary to have public keys for all 
> recipients, and thus the version signaling information may be absent. 
> (Optionally the presence of public keys for all message recipients could 
> be used to conclude that a newer signature package can be used.)

Again, if the signer's certificate uses a v5 key, there is no point in
requiring that the signature itself is a v4 signature (that is, a
signature of the type described in RFC 4880), as implementations that
know how to read a v5 signature must know how to interpret a v5 key
anyway.

The OpenPGP Interoperability Test Suite has several tests that aim to
ensure that when a new-version signature is placed alongside an
old-version signature, existing implementations are still capable of
verifying the old signature, and don't fail on encountering a signature
that they don't understand.

If a public-facing signing entity wants to support older verifiers that
only support RFC 4880, their best bet is to have two keys: a v4 signing
key, and a next-gen (v5?) key, based on whatever standard succeeds
RFC4880.  Then they can sign with both of them, and newer
implementations can rely on the advantages of new signatures: at the
very least, (a) the crypto-refresh's salting defense against future
failures in collision-resistance, (b) the de-aliasing of larger-sized
message content due to v5's 64-bit field for message size, and (c) v5's
larger allowed total hashed subpacket size.

> * Declare that in order to make use of any of the features from 
> crypto-refresh, it's required to have a recipient public key that 
> signals support for version 5.

Again, for message encryption, this is already specified in
crypto-refresh, based on use of the Features subpacket.  Even v4 keys
can signal their intent by setting the appropriate bit in their Features
subpacket.  I don't think it's helpful to say "any of the features from
crypto-refresh", because there are many different features, and they *do
not* need to be gated by key version information.  For example,
newly-defined subpackets that are not marked critical should already be
safely ignored by any implementation.

If anyone wants to enumerate specific features that they think *do* need
a clear signal from the potential recipient before generation that have
not been considered, i'd welcome those pointers.  This kind of work is
the work that the design team, including members from sequoia,
protonmail, gnupg, and rnp, have been doing over the last several
months.

> * If a message is to be sent to multiple recipients, which signal 
> different supported OpenPGP versions, the sender is required to produce 
> the appropriate number of different messages, one for each group of 
> recipients supporting the same version.

This sounds like a mess for implementers, and i hope that we don't end
up endorsing something like this.  For example, this means that any mail
user agent that is handling OpenPGP messages cannot simply ask the
OpenPGP implementation to produce the encrypted version of the message
and get a response that it can interpret as success or failure.
Instead, this creates a much more complex interface between the MUA and
any OpenPGP implementation.  Kai, as a MUA developer, you might be
willing to accept this additional burden; but if your goal is for your
users to be able to exchange e-mail with people using other MUAs, you
have to realize that this will make it *even harder* for other
implementations to adopt this cryptographic stack.  that's not a good
outcome for the ecosystem.

crypto-refresh already describes the expected baseline behavior here
without requiring such a dual-message output:

----crypto-refresh-----
- When encrypting to one or more public keys:

  - all recipient keys indicate support for version 2 of the
    Symmetrically Encrypted Integrity Protected Data packet in their
    Features subpacket ({{features-subpacket}}), or are v5 keys without
    a Features subpacket, or the implementation can otherwise infer that
    all recipients support v2 SEIPD packets, the implementation MUST
    encrypt using a v2 SEIPD packet.

  - If one of the recipients does not support v2 SEIPD packets, then the
    message generator MAY use a v1 SEIPD packet instead.
----crypto-refresh-----

This leaves the deprecation of v1 SEIPD as future work, of course, but
it permits the spread of keys that support v2 SEIPD without increasing
the operational burden on MUA developers.

> * For transparency reasons, each message somehow signal the additional 
> reicpients, which will be handled with a separate openpgp message 
> (different version). Maybe this could be done by reusing the existing 
> "Public-Key Encrypted Session Key Packets" with a key identifier, but 
> dummy data.

i don't fully understand this proposal, but i think it is only relevant
if implementations do create the earlier-proposed dual-copy of the
ciphertext. I hope we don't have to go there.

> This means GnuPG would continue to use its existing packets, it would 
> always use what's defined in version 4.

GnuPG has for years implemented RFC 4880 (which is what i think you're
calling "version 4").  I would hope that support for RFC 4880 would not
be removed from any implementation in the first several years, though it
would be nice if any greenfield deployment could select an OpenPGP
toolkit that is *capable* of only using "the good bits" of whatever is
published as RFC 4880's successor.

We do not have a lot of work on any sort of formalized OpenPGP API
(beyond "SOP", aka
https://datatracker.ietf.org/doc/draft-dkg-openpgp-stateless-cli/, which
does not yet cover this sort of version selector) so these choices would
likely be idiosyncratic to the specific implementation.

> Applications that support crypto-refresh would be required to also 
> support RFC 4880.

crypto-refresh makes clear that it expects the implementer to support
and interoperate with RFC 4880 implementations, as RFC 4880 is 15 years
old and there are literally millions of messages in the wild that use
the RFC 4880 data structures.

> When applications that support crypto-refresh need to send data to 
> owners of public keys that lack the version information, then data 
> that's compatible with GnuPG and old applications would be sent.

Right, as noted above, crypto-refresh explicitly indicates that
implementations will want to send RFC 4880's v1 SEIPD to recipients that
have not indicated support for v2 SEIPD.

     --dkg