Hi there,
The counter-argument is that such separation isn't needed
for OCB (it was added for GCM) and that OCB code has been
deployed with existing ciphertexts out there already so
this change breaks interop for no real benefit.
Just for additional context, the original motivation to add GCM
was for FIPS compliance reasons, based on a suggestion at IETF 112.
(Obviously, whether that is needed / "worth it" is up for debate.)
Additionally, at least for asymmetrically encrypted messages, the
crypto-refresh draft didn't break interop (since it specifies v2 SEIPD
instead of the AEAD packet, so implementations can still decrypt AEAD
messages if they want), also because we did see some such messages
"out there" indeed.
For symmetrically encrypted messages, we did change the definition of
v5 SKESK, but my understanding is that GnuPG 2.3 still uses v3 SKESK,
so symmetrically encrypted AEAD messages can continue to be decrypted
as well, I think? (Other implementations didn't generate AEAD messages
by default yet, I believe.)
And finally, the definition of S2K usage octet 253 (for AEAD encrypted
private keys) did change as well, but I'm not sure if that was being
used yet? And anyway it's a fairly "local" object, so I personally
don't think that should cause many issues.
Best,
Daniel
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp