Re: [openpgp] First remarks on the last I-D

[Werner Koch <[e-mail]>]

Hi Paul,

On Tue,  7 Jun 2022 08:10, Paul Wouters said:

>>   However, OpenPGP has taken its own decisions based on technical
>>   soundness and not based on larger vendor, government or committee
>>   decision.
>
> This sentence is somewhat contradicting. OpenPGP is the work of the
> IETF, so it is in a way a "committee decision". The OpenPGP Design Team
> was meant to speed up to work and have a draft to discuss. That is
> exactly what we are starting to do now.

By "committee" I obviously meant "design by committee" which is commonly
understood as: We turn a spec into something which everyone can agree to
but is not a technically sound one or too complex to ever get right.
(classic example if is OSI with its still prominent descendants LDAP and
X.509)

When we talked about this in December/January 2020/2021 the idea was to
get out of that lock due to some folks having blocked the adoption of the
AEAD chunk size to a point where the WG was dissolved.  However, all
parts of rfc-4880bis had WG rough consensus.  Some disputed this and
those some where interestingly folks who had been silent during the
rfc-4880bis process until they stated their own OpenPGP implementation
an needed some selling points for this.

BTW, the original plan for the DT was to be ready by last summer.

> argument. But right now, GCM is the only FIPS compatible method. So I
> think removing that would be problematic.

I can't see that FIPS compliance is a chartered goal.  Good if we US
folks get this for business purposes but PGP has not only business in
mind.

> That would certainly be a good option if we got confirmation about the
> OCB status.

The Rogaway patent (US8321675B2) expired a year ago.  The Jutla/IBM
patent (US6963976B1), which may be related to OCB, will also expire this
November.  Let's ask Rogaway; actually this has been on the todo list of
the WG for years (to get a general grant like he did for OpenSSL).

> good. But we do have 25519 and x448 now for that. It seems within the
> IETF, Brainpool is not seeing a great adoption. But again, personally I
> am fine with adding these at the MAY level. I am interested in hearing

Actually 6637 allows any curve by means of an OID.  I recall that I
pledged for this as a quick fix to the idea of having just a list of
fixed NIST curves.  However, it is better for implementors to have the
deployed curves listed in the specs.  It is not just GnuPG and the
original OpenPGP card supports Brainpool, but also all Yubikeys.  it is
actually widely deployed in Europe meanwhile.

> on keeping this at the MAY level for backwards compatibility.

MAY is okay as long as NIST curves also MAY.  I am in full support to
demand 25519 as MUST and 448 as SHOULD.


Salam-Shalom,

   Werner

-- 
The pioneers of a warless world are the youth that
refuse military service.             - A. Einstein