From simon at josefsson.org  Wed May  1 20:24:25 2024
From: simon at josefsson.org (Simon Josefsson)
Date: Wed, 01 May 2024 20:24:25 +0200
Subject: Very first Beta of GnuPG 2.6 available
In-Reply-To: <87jzkg8uh7.fsf@jacob.g10code.de> (Werner Koch via Gnupg-devel's
 message of "Mon, 29 Apr 2024 10:05:08 +0200")
References: <87jzkg8uh7.fsf@jacob.g10code.de>
Message-ID: <87v83xv19i.fsf@kaka.sjd.se>

Werner Koch via Gnupg-devel <gnupg-devel at gnupg.org> writes:

> Hi!
>
> Gniibe and me have been working on PQC Support in GnuPG for some time
> now.  Now we have a first Beta version available.  Because we have done
> no releases of the supporting libraries yet, a tarball with all sources is
> available:
>
> https://gnupg.org/ftp/gcrypt/snapshots/gnupg/gnupg-w32-2.5.0-beta465_20240426.tar.xz
>
> https://gnupg.org/ftp/gcrypt/snapshots/gnupg/gnupg-w32-2.5.0-beta465_20240426.tar.xz.sig

I had several problems building/running this and eventually became tired
of fixing small issues (mostly build environment related) -- is it
possible to build from git instead?  Which branches were used?

Will you support sntrup761 and/or mceliece6688128?  I would like to see
some alternative to kyber early on.

/Simon
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 255 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20240501/d6cce717/attachment.sig>

From dgouttegattat at incenp.org  Wed May  1 21:57:20 2024
From: dgouttegattat at incenp.org (Damien Goutte-Gattat)
Date: Wed, 01 May 2024 20:57:20 +0100
Subject: Very first Beta of GnuPG 2.6 available
In-Reply-To: <87v83xv19i.fsf@kaka.sjd.se>
References: <87jzkg8uh7.fsf@jacob.g10code.de> <87v83xv19i.fsf@kaka.sjd.se>
Message-ID: <26403280.1r3eYUQgxm@borealin.local.incenp.org>

On Wednesday, 1 May 2024 19:24:25 BST Simon Josefsson via Gnupg-devel wrote:
> Werner Koch via Gnupg-devel <gnupg-devel at gnupg.org> writes:
> I had several problems building/running this and eventually became tired
> of fixing small issues (mostly build environment related)

FWIW I also ran into a few problems when trying to build the beta.

I believe the correct build instruction should have been

  make -f build-aux/speedo.mk this-native

At least that?s what I had to use on my machine. With `native`, Speedo attempted to use the latest *released* versions of Libassuan and Libgcrypt, resulting in GnuPG itself failing to build since it depends on newer versions of those libraries that have not been released yet.

With `this-native`, Speedo will use the already unpacked sources provided in the tarball (in PLAY/src).

Another problem is that when building bzip2, it would try to install a header in /usr/local, instead of the PLAY root. Not sure why, but I didn?t investigate further. I just removed bzip2 from the list of packages (variable `speedo_spkgs`) and let GnuPG use my system-wide bzip2 instead.

Hope this helps.

- Damien
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20240501/31a7209d/attachment.sig>

From ben+freesoftware at benfinney.id.au  Thu May  2 05:55:47 2024
From: ben+freesoftware at benfinney.id.au (Ben Finney)
Date: Thu, 02 May 2024 13:55:47 +1000
Subject: GPGME: What does =?utf-8?B?4oCYMOKAmQ==?= (zero)
 =?utf-8?Q?=E2=80=98signature=2Esummary=E2=80=99?= value mean?
References: <87jzl36nry.fsf@benfinney.id.au> <8734romgfr.fsf@jacob.g10code.de>
 <87frvn5l66.fsf@benfinney.id.au>
Message-ID: <878r0sx3y4.fsf@benfinney.id.au>

Ben Finney <ben+freesoftware at benfinney.id.au> writes:

> Werner Koch via Gnupg-devel <gnupg-devel at gnupg.org> writes:
>
> > Do you have an example?
>
> Included in this message is a Python program ?verify_test.py?. [?]
>
> You can see that the ?verify? call succeeds (no error is raised), and
> there is a single attached Signature.
>
> That Signature, though it has a valid timestamp and fingerprint, has ?0?
> for all of ?pka_trust?, ?status?, ?summary?, ?validity?, and
> ?validity_reason?.

Has this helped understand the problem? What more diagnostic information
can I provide?

I am trying to make use of GPGME (via the Python wrapper) to verify
signatures and interpret the result using the documented API.

-- 
 \       ?If you always want the latest and greatest, then you have to |
  `\          buy a new iPod at least once a year.? ?Steve Jobs, MSNBC |
_o__)                                             interview 2006-05-25 |
Ben Finney



From wk at gnupg.org  Thu May  2 08:42:44 2024
From: wk at gnupg.org (Werner Koch)
Date: Thu, 02 May 2024 08:42:44 +0200
Subject: Specification for Kyber in GnuPG
 (was: Very first Beta of GnuPG 2.6 available)
In-Reply-To: <87jzkg8uh7.fsf@jacob.g10code.de> (Werner Koch via Gnupg-devel's
 message of "Mon, 29 Apr 2024 10:05:08 +0200")
References: <87jzkg8uh7.fsf@jacob.g10code.de>
Message-ID: <87y18s67ff.fsf@jacob.g10code.de>

Hi!

Please find attached a diff towards the LibrePGP specification which
describes the new KEM algorithms used for quantum-resistant encryption.
Before a new draft is published some minor things need to be fixed but
it should nevertheless allow to implement the same thing as we did in
GnuPG master.  The SHOULD and MAYs in the table of ECC-KEM and ML-KEM
are up to discussion.  In particular whether a 256 bit or a 384 bit
curve should go with ML-KEM-768.

Note that in GnuPG we use the term "Kyber" instead of "ML-KEM" because
that is easier to remember.  The abbreviation is ky768 or ky1024
followed by the ECC curve name with Brainpool curves abbreviated as
bp256 et.  For example ky1024_cv448 stands for the composite of
ML-KEM-1024 with X448.

A description on how to add Kyber support to an existing OpenPGP
implementation will follow.  As long as the crypto primitives are
available adding that support is straightforward because existing parser
code may partly be re-used and all variants are covered by just one
algorithm id.

Support for quantum-resistant signature schemes is not not yet available
and far less urgent than encryption: The goal is to protect encrypted
data at rest (or being wiretapped).  Also new signature schemes need
more real world experience before they can be taken in use.

The migration plan to quantum-resistant encryption is to add new Kyber
subkeys so that implementation with support for them can start to use
them.  If at some point in the future a wide deployment as been
achieved, the new gpg option --require-pqc-encryption can be used to
force encryption with a quantum-resistant algorithm (i.e. Kyber).

Many thanks to Stavros Kousidis, Falko Strenzke, and Aron Wussler for
their draft on adding PQC to OpenPGP.  The algorithms used by LibgrePGP
are the same except for the fixed info.  I took the freedom to remove
the rationale parts which are not helpful for an implementer and was
thus able to make the description more concise.



Shalom-Salam,

   Werner


-- 
The pioneers of a warless world are the youth that
refuse military service.             - A. Einstein
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Describe-the-KEM-algorithms.patch
Type: text/x-diff
Size: 11877 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20240502/6d111fb2/attachment-0001.patch>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: openpgp-digital-signature.asc
Type: application/pgp-signature
Size: 247 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20240502/6d111fb2/attachment-0001.sig>

From wk at gnupg.org  Thu May  2 08:56:45 2024
From: wk at gnupg.org (Werner Koch)
Date: Thu, 02 May 2024 08:56:45 +0200
Subject: Very first Beta of GnuPG 2.6 available
In-Reply-To: <87v83xv19i.fsf@kaka.sjd.se> (Simon Josefsson via Gnupg-devel's
 message of "Wed, 01 May 2024 20:24:25 +0200")
References: <87jzkg8uh7.fsf@jacob.g10code.de> <87v83xv19i.fsf@kaka.sjd.se>
Message-ID: <87ttjg66s2.fsf@jacob.g10code.de>

Hi!

> I had several problems building/running this and eventually became tired
> of fixing small issues (mostly build environment related) -- is it
> possible to build from git instead?  Which branches were used?

Actually it as been taken from Git and I tried it on a separate box
without problems.   But as Damien mentioned my  description was wrong:
You need to use the this-native target.

You can also build from Gut.  You need to use the latest Libgcrypt and
gnupg master.  Everything else has been released.  The speedo things is
good because you don't need to mess with an existing gnupg installation.

> Will you support sntrup761 and/or mceliece6688128?  I would like to see
> some alternative to kyber early on.

No.  We need to avoid algorithm proliferation.  That is also why I don't
care about PC signatures right now.

Thanks for trying to build.


Shalom-Salam,

   Werner

-- 
The pioneers of a warless world are the youth that
refuse military service.             - A. Einstein
-------------- next part --------------
A non-text attachment was scrubbed...
Name: openpgp-digital-signature.asc
Type: application/pgp-signature
Size: 247 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20240502/2105db0f/attachment.sig>

From wk at gnupg.org  Thu May  2 08:58:27 2024
From: wk at gnupg.org (Werner Koch)
Date: Thu, 02 May 2024 08:58:27 +0200
Subject: Very first Beta of GnuPG 2.6 available
In-Reply-To: <26403280.1r3eYUQgxm@borealin.local.incenp.org> (Damien
 Goutte-Gattat via Gnupg-devel's message of "Wed, 01 May 2024 20:57:20
 +0100")
References: <87jzkg8uh7.fsf@jacob.g10code.de> <87v83xv19i.fsf@kaka.sjd.se>
 <26403280.1r3eYUQgxm@borealin.local.incenp.org>
Message-ID: <87plu466p8.fsf@jacob.g10code.de>

On Wed,  1 May 2024 20:57, Damien Goutte-Gattat said:

> Another problem is that when building bzip2, it would try to install a
> header in /usr/local, instead of the PLAY root. Not sure why, but I

It is possible that there is no bzip2-dev package on my test building
box.  This would explain why it worked for me.

I'll investigate.


Salam-Shalom,

   Werner

-- 
The pioneers of a warless world are the youth that
refuse military service.             - A. Einstein
-------------- next part --------------
A non-text attachment was scrubbed...
Name: openpgp-digital-signature.asc
Type: application/pgp-signature
Size: 247 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20240502/6d1cf03d/attachment.sig>

From kloecker at kde.org  Thu May  2 09:21:01 2024
From: kloecker at kde.org (Ingo =?ISO-8859-1?Q?Kl=F6cker?=)
Date: Thu, 02 May 2024 09:21:01 +0200
Subject: GPGME: What does
 =?UTF-8?B?4oCYMOKAmSAoemVybykg4oCYc2lnbmF0dXJlLnN1bW1hcnnigJk=?= value mean?
In-Reply-To: <8734rk68s3.fsf@benfinney.id.au>
References: <87jzl36nry.fsf@benfinney.id.au> <12421620.O9o76ZdvQC@daneel>
 <8734rk68s3.fsf@benfinney.id.au>
Message-ID: <4567689.LvFx2qVVIh@daneel>

On Mittwoch, 17. April 2024 04:08:12 CEST Ben Finney wrote:
> Ingo Kl?cker <kloecker at kde.org> writes:
> > It would be helpful if you also gave us the public key.
> 
> Oh, I had expected a GnuPG client would fetch the key? It's part of the
> signed message metadata, so it should be automatically fetched from the
> key servers, I'd expect.

Only if auto?key?retrieve is enabled.

> Regardless, here is the URL to download that public key:
> 
>     <URL:
> https://keys.openpgp.org/search?q=517C+F14B+B2F3+98B0+CB35++4855+B8B2+4C06+
> AC12+8405>

$ curl https://keys.openpgp.org/vks/v1/by-fingerprint/
517CF14BB2F398B0CB354855B8B24C06AC128405 | gpg --import
gpg: key B8B24C06AC128405: no user ID
gpg: Total number processed: 1

gpg doesn't import keys without user ID. I found the key on another keyserver, 
but when I try to verify the test message Kleopatra tells me:

Signature created on Montag, 15. April 2024 01:32:13 CEST
With unavailable certificate:
ID: 0x6159E0F29E2FA412E0795C73F9B46AAC84420C82
You can search the certificate on a keyserver or import it from a file.

I guess the required subkey is missing on the certificate I could import. 
Searching the certificate 0x6159E0F29E2FA412E0795C73F9B46AAC84420C82 didn't 
yield any results.

> $ gpg --status-fd 2 foo.txt.asc
[...]
> [GNUPG:] TRUST_UNDEFINED 0 pgp
> gpg: WARNING: This key is not certified with a trusted signature!

I think this is the important bit. If you look at the code snippet that Werner 
pasted then you'll see why `sum` isn't changed in this snippet. So, in this 
case 0 means good signature by an uncertified key. It's up to you to decide 
what to make of this.

Regards,
Ingo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20240502/4fd9b087/attachment.sig>

From andrewg at andrewg.com  Thu May  2 15:27:27 2024
From: andrewg at andrewg.com (Andrew Gallagher)
Date: Thu, 2 May 2024 14:27:27 +0100
Subject: Specification for Kyber in GnuPG (was: Very first Beta of GnuPG
 2.6 available)
In-Reply-To: <87y18s67ff.fsf@jacob.g10code.de>
References: <87jzkg8uh7.fsf@jacob.g10code.de> <87y18s67ff.fsf@jacob.g10code.de>
Message-ID: <BE4A733A-68D8-4489-998F-802456AAA844@andrewg.com>

On 2 May 2024, at 07:42, Werner Koch via Gnupg-devel <gnupg-devel at gnupg.org> wrote:

> +Curve           | ML-KEM | ECC-KEM | SHAFunc  | Requirement
> +---------------:|--------|---------|----------|------------
> +X25519          | 768    | XKem    | SHA3-256 | SHOULD
> +X448            | 768    | XKem    | SHA3-512 | MAY
> +X25519          | 1024   | XKem    | SHA3-256 | MAY
> +X448            | 1024   | XKem    | SHA3-512 | SHOULD
> +brainpoolP256r1 | 768    | ecdhKem | SHA3-256 | MAY
> +brainpoolP384r1 | 768    | ecdhKem | SHA3-512 | SHOULD
> +brainpoolP512r1 | 768    | ecdhKem | SHA3-512 | MAY
> +brainpoolP512r1 | 1024   | ecdhKem | SHA3-512 | SHOULD
> +brainpoolP256r1 | 1024   | ecdhKem | SHA3-256 | MAY
> +brainpoolP384r1 | 1024   | ecdhKem | SHA3-512 | MAY
> +NIST P-256      | 768    | ecdhKem | SHA3-256 | MAY
> +NIST P-384      | 768    | ecdhKem | SHA3-512 | MAY
> +NIST P-521      | 768    | ecdhKem | SHA3-512 | MAY
> +NIST P-256      | 1024   | ecdhKem | SHA3-256 | MAY
> +NIST P-384      | 1024   | ecdhKem | SHA3-512 | MAY
> +NIST P-521      | 1024   | ecdhKem | SHA3-512 | MAY

This is an enormous set of initial combinations, not all of which make any sense. Why suggest pairing P-256 curves with kyber1024? Do we need all three grades of brainpool and NIST? The four SHOULDs and the corresponding two NIST equivalents are plenty.

Once again I?ll beg you to please implement the Kousidis, Strenzke and Wussler spec instead of making trivial changes to their assigned numbers in order to start a pointless and exhausting fight with the IETF WG over ownership of the registry. If we need to allocate four more code points for the brainpool and nist alternatives, what?s the harm? The registry is SPECIFICATION REQUIRED (or will be shortly) and the use of brainpool/nist curves in PQC is not controversial. Why reinvent the wheel?

A

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20240502/71c04c28/attachment.sig>

From wk at gnupg.org  Thu May  2 20:10:34 2024
From: wk at gnupg.org (Werner Koch)
Date: Thu, 02 May 2024 20:10:34 +0200
Subject: Specification for Kyber in GnuPG
In-Reply-To: <BE4A733A-68D8-4489-998F-802456AAA844@andrewg.com> (Andrew
 Gallagher's message of "Thu, 2 May 2024 14:27:27 +0100")
References: <87jzkg8uh7.fsf@jacob.g10code.de> <87y18s67ff.fsf@jacob.g10code.de>
 <BE4A733A-68D8-4489-998F-802456AAA844@andrewg.com>
Message-ID: <875xvw5bl1.fsf@jacob.g10code.de>

On Thu,  2 May 2024 14:27, Andrew Gallagher said:

> This is an enormous set of initial combinations, not all of which make
> any sense. Why suggest pairing P-256 curves with kyber1024? Do we need

I already mentipned that this list is up for discussion.  Well, except
for the SHOULDs which at least need to stay in the list.  There are no
MUSTs here because PQC algorithms are not mandatory and needed for all
applications.  Instead implementations should decide what to do.

> all three grades of brainpool and NIST? The four SHOULDs and the
> corresponding two NIST equivalents are plenty.

The Brainpool curves are needed and not subject to discussion.  Adding
different codepoints for the same algorithm (ECC-KEM + ML-KEM aka Kyber)
is a major implementation hassle and diverts from existing OpenPGP
protocol behaviour.  There is one code point for RSA, one for DSA, one
for Elgamal, one for ECDH, one for ECDSA, one for EdDSA, and now one for
Kyber.  They all have different parameters: either length of parameters
or an OID for the curev parameters (which are too large to include in
all keys).   Thus it is natural to do the same for Kyber.

After all we are not TLS with its hunderds of codepoints for algorithms.
Adding more codepoints to TLS is also the natural way - for TLS.

> Once again I?ll beg you to please implement the Kousidis, Strenzke and
> Wussler spec instead of making trivial changes to their assigned

The changes might sound trivial but I explained them above.  They come
from an implementer with a specific and practical knowledge of OpenPGP
protocol needs.  The actual algorithm and cryptography has not changed
because that is not my specific knowledge.  That is how OpenPGP has
always been extended - let the crypto folks do the math and the coders
the implementation.

> numbers in order to start a pointless and exhausting fight with the
> IETF WG over ownership of the registry. If we need to allocate four

We can't wait another 9 years for a simple crypto enhancement.  We need
a new identifier NOW and need to get it used.  After a discussion with
the BSI we will temporary add a notification to Kyber keys created
according to the current ML-KEM draft.  Just in case the NIST decides to
do some final changes we can the detect keys created according to the
current draft and sort them out.


Salam-Shalom,

   Werner

-- 
The pioneers of a warless world are the youth that
refuse military service.             - A. Einstein
-------------- next part --------------
A non-text attachment was scrubbed...
Name: openpgp-digital-signature.asc
Type: application/pgp-signature
Size: 247 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20240502/373b308b/attachment.sig>

From andrewg at andrewg.com  Fri May  3 14:09:29 2024
From: andrewg at andrewg.com (Andrew Gallagher)
Date: Fri, 3 May 2024 13:09:29 +0100
Subject: Specification for Kyber in GnuPG
In-Reply-To: <875xvw5bl1.fsf@jacob.g10code.de>
References: <87jzkg8uh7.fsf@jacob.g10code.de> <87y18s67ff.fsf@jacob.g10code.de>
 <BE4A733A-68D8-4489-998F-802456AAA844@andrewg.com>
 <875xvw5bl1.fsf@jacob.g10code.de>
Message-ID: <73FDDD64-F433-4D99-A119-0EFB832EC4DE@andrewg.com>

On 2 May 2024, at 19:10, Werner Koch <wk at gnupg.org> wrote:
> 
> The Brainpool curves are needed and not subject to discussion.

Is this a BSI requirement? Are there any other aspects of the list which are not subject to discussion?

> Adding
> different codepoints for the same algorithm (ECC-KEM + ML-KEM aka Kyber)
> is a major implementation hassle

Hassle for who though? Supporting both this proposal and the BSI/IETF PQC draft is a major implementation hassle. Supporting an arbitrary combination of algorithms that your underlying crypto library does not expose in its API is a major implementation hassle. Mapping a set of fixed code points to OIDs is a Friday afternoon job by comparison.

If you want other implementations to be interoperable with you, then you need to consider their concerns sometimes. (I?m thinking particularly about gopenpgp and hockeypuck here, although it applies to others also). I *want* to stay compatible with GnuPG, but it feels like every concern I raise is being dismissed out of hand. This is not how open standards are supposed to work.

> After all we are not TLS with its hunderds of codepoints for algorithms.
> Adding more codepoints to TLS is also the natural way - for TLS.

The OpenPGP asymmetric algorithms registry currently has 16 assigned code points out of 255, some of which have been reserved for years and never implemented. That?s less than 10% usage in over 30 years of PGP. Even if we?d always had separate code points for the various (recommended) sizes of RSA and the individual curves, we still wouldn't have filled up the unused block between code points 3 and 16. In the unlikely event we?re all still alive when the registry runs out, we can define new packet versions with a two byte algorithm ID area. This is a non issue.

I simply don?t understand how a difference of opinion over how to organise a numbering convention is sufficient justification for defining two completely separate standards that differ only in that numbering convention (and the knock-on effects thereof). The only explanation that makes sense is that it is a deliberate strategy to avoid having to discuss algorithm details with other implementations before shipping them in GnuPG. Which is very convenient for GnuPG, but not so convenient for the rest of us.

>> Once again I?ll beg you to please implement the Kousidis, Strenzke and
>> Wussler spec instead of making trivial changes to their assigned
> 
> The changes might sound trivial but I explained them above.  They come
> from an implementer with a specific and practical knowledge of OpenPGP
> protocol needs. The actual algorithm and cryptography has not changed
> because that is not my specific knowledge.  That is how OpenPGP has
> always been extended - let the crypto folks do the math and the coders
> the implementation.

Sorry, are you seriously claiming here that the authors of the IETF PQC draft, which include one of the principal developers of gopenpgp, do not have practical knowledge of OpenPGP protocol needs?

>> numbers in order to start a pointless and exhausting fight with the
>> IETF WG over ownership of the registry. If we need to allocate four
> 
> We can't wait another 9 years for a simple crypto enhancement. We need
> a new identifier NOW and need to get it used.

On this we agree, but I don?t believe that doing the same work twice helps us achieve it.

> After a discussion with
> the BSI we will temporary add a notification to Kyber keys created
> according to the current ML-KEM draft.  Just in case the NIST decides to
> do some final changes we can the detect keys created according to the
> current draft and sort them out.

Is this a GnuPG-specific proposal? It hasn?t been mentioned in any of the calls or emails I?ve been in with the authors of the IETF PQC draft, and the first author of that draft is a BSI employee.

I?m seriously worried now that the BSI appear to be funding and/or directing two separate instances of the same project. Is this a conscious decision by the BSI or just a failure of communication between departments?

A

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20240503/d705446f/attachment-0001.sig>

From meep at meeps.dev  Sat May  4 15:55:40 2024
From: meep at meeps.dev (meep)
Date: Sat, 04 May 2024 15:55:40 +0200
Subject: Possible bug in GPGME Python
Message-ID: <1c2471ada3be762ea02f8e4fa8cc601c7860e6be.camel@meeps.dev>

Good day.

I would like to report what I believe to be an oversight in the Python
wrapper of GPGME.

I am reporting it here as it is a minor thing, and account creation is
disabled on the bug tracker at dev.gnupg.org. I would also prefer not
to make an account if possible.

In the interact(...) function of the Context class on line 1089 in
core.py it is checked whether a key is actually passed in to the
function:

if key is None:
    raise ValueError("First argument cannot be None")

Which is fine when editing a key, but when interacting with a smart
card (setting the flag INTERACT_CARD) - for example to generate a key
on it - there is not necessarily a key to be edited.

In interact_start(...) on line 131 of edit.c the presence of the key is
only checked if card_edit isn't set:

if ((card_edit == 0 && !key) || !fnc || !out)
  return gpg_error (GPG_ERR_INV_VALUE);

This functions is called by gpgme_op_interact(...) in the same file
which is called from Python in the aforementioned interact(...)
function.

Thus I believe that the intended behavior in Python would be to mirror
the C code and only check whether the key is None if INTERACT_CARD is
not set.

Please correct me if I am wrong and point me in the right direction.

Thanks in advance
- meep
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 854 bytes
Desc: This is a digitally signed message part
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20240504/8f391b92/attachment.sig>

From ben+freesoftware at benfinney.id.au  Sun May  5 08:47:03 2024
From: ben+freesoftware at benfinney.id.au (Ben Finney)
Date: Sun, 05 May 2024 16:47:03 +1000
Subject: GPGME: What does =?utf-8?B?4oCYMOKAmQ==?= (zero)
 =?utf-8?Q?=E2=80=98signature=2Esummary=E2=80=99?= value mean?
References: <87jzl36nry.fsf@benfinney.id.au> <12421620.O9o76ZdvQC@daneel>
 <8734rk68s3.fsf@benfinney.id.au> <4567689.LvFx2qVVIh@daneel>
Message-ID: <87cyq021so.fsf@benfinney.id.au>

Ingo Kl?cker <kloecker at kde.org> writes:

> On Mittwoch, 17. April 2024 04:08:12 CEST Ben Finney wrote:
> > $ gpg --status-fd 2 foo.txt.asc
> [...]
> > [GNUPG:] TRUST_UNDEFINED 0 pgp
> > gpg: WARNING: This key is not certified with a trusted signature!
>
> I think this is the important bit. If you look at the code snippet
> that Werner pasted then you'll see why `sum` isn't changed in this
> snippet. So, in this case 0 means good signature by an uncertified
> key.

If that's the meaning, surely this should be unambiguously encoded with
the Signature result attributes? Rather than "everything is zero", which
(as you point out) just seems to be some default when the conditions
were not as expected.

> It's up to you to decide what to make of this.

I make of this, that GPGME has a bug: It does not handle this normal
condition well. The message emitted shows GnuPG understands what
happened; but the result object from the GPGME API does not communicate
that information unambiguously.

So, please consider this thread a bug report to that effect. How do I
formalise this so it can be addressed as such?

-- 
 \        ?Most people, I think, don't even know what a rootkit is, so |
  `\     why should they care about it?? ?Thomas Hesse, Sony BMG, 2006 |
_o__)                                                                  |
Ben Finney



From wk at gnupg.org  Mon May  6 13:40:16 2024
From: wk at gnupg.org (Werner Koch)
Date: Mon, 06 May 2024 13:40:16 +0200
Subject: Specification for Kyber in GnuPG
In-Reply-To: <73FDDD64-F433-4D99-A119-0EFB832EC4DE@andrewg.com> (Andrew
 Gallagher via Gnupg-devel's message of "Fri, 3 May 2024 13:09:29
 +0100")
References: <87jzkg8uh7.fsf@jacob.g10code.de> <87y18s67ff.fsf@jacob.g10code.de>
 <BE4A733A-68D8-4489-998F-802456AAA844@andrewg.com>
 <875xvw5bl1.fsf@jacob.g10code.de>
 <73FDDD64-F433-4D99-A119-0EFB832EC4DE@andrewg.com>
Message-ID: <87v83r2mov.fsf@jacob.g10code.de>

Hi!

Sorry Andrew, I won't follow up on your mail.  I gave a rationale for
the changes in replies here and on the librepgp-discuss list [1].  I
also posted a new draft for an updated Librepgp draft today [2].

If you have any problems implementing any of this in your OpenPGP
implementation, please let us know and we see how we can help in coding.


Shalom-Salam,

   Werner


ps.  Let me remark that this is not the IETF OpenPGP WG which
unfortunately had been hijacked in 2022 by a small group of people
trying to undermine the stability of the OpenPGP protocol with their
irresponsible changes (aka crypto-refresh).  They reused the term
OpenPGP for something very different and thus we had to established the
term LibrePGP for a responsible update to the crypto algorithms used in
OpenPGP.


[1] https://lists.gnupg.org/pipermail/librepgp-discuss/2024/000043.html
[2] https://lists.gnupg.org/pipermail/librepgp-discuss/2024/000068.html
-- 
The pioneers of a warless world are the youth that
refuse military service.             - A. Einstein
-------------- next part --------------
A non-text attachment was scrubbed...
Name: openpgp-digital-signature.asc
Type: application/pgp-signature
Size: 247 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20240506/9559a152/attachment.sig>

From wk at gnupg.org  Mon May  6 13:51:48 2024
From: wk at gnupg.org (Werner Koch)
Date: Mon, 06 May 2024 13:51:48 +0200
Subject: GPGME: What does =?utf-8?B?4oCYMOKAmQ==?= (zero)
 =?utf-8?Q?=E2=80=98signature=2Esummary=E2=80=99?= value mean?
In-Reply-To: <87cyq021so.fsf@benfinney.id.au> (Ben Finney's message of "Sun,
 05 May 2024 16:47:03 +1000")
References: <87jzl36nry.fsf@benfinney.id.au> <12421620.O9o76ZdvQC@daneel>
 <8734rk68s3.fsf@benfinney.id.au> <4567689.LvFx2qVVIh@daneel>
 <87cyq021so.fsf@benfinney.id.au>
Message-ID: <87r0ef2m5n.fsf@jacob.g10code.de>

On Sun,  5 May 2024 16:47, Ben Finney said:

> the Signature result attributes? Rather than "everything is zero", which
> (as you point out) just seems to be some default when the conditions
> were not as expected.

Let's have a look at the docs:

     ?gpgme_sigsum_t summary?
          This is a bit vector giving a summary of the signature status.
          It provides an easy interface to a defined semantic of the
          signature status.  Checking just one bit is sufficient to see
          whether a signature is valid without any restrictions.  This
          means that you can check for GPGME_SIGSUM_VALID like this:

               if ((sig.summary & GPGME_SIGSUM_VALID))
               {
                  ..do stuff if valid..
               }
               else
               {
                  ..do stuff if not fully valid..
               }

VALID is not set and this is the basic informaion you need.  After all
this is a summary and does not give deatils informaion on the reason why
a signature is not valid.  The whole point here is easily see whether
you can accept a signature.  There are other flags which allow you to
further investigate thinsg.  For example:

          ?GPGME_SIGSUM_GREEN?
               The signature is good but one might want to display some
               extra information.  Check the other bits.

Note the "might". It is not required as per the policy implemented
currently be GPGME.  Just go ahead and display the signature with a
green frame or similar.

          ?GPGME_SIGSUM_RED?
               The signature is bad.  It might be useful to check other
               bits and display more information, i.e., a revoked
               certificate might not render a signature invalid when the
               message was received prior to the cause for the
               revocation.

Same here - the signature is definitely bad.  Display with a red frame.

There are no other colors but some MUAs will use a yellow or uncolored
frame if they don't see the green or red bit.  This is a UI decision
which for example depends on whether you expect signed messages or not.

> I make of this, that GPGME has a bug: It does not handle this normal
> condition well. The message emitted shows GnuPG understands what
> happened; but the result object from the GPGME API does not communicate

GPGME policy is not to set the green flag in this case.  If you want
something elease check out the detailed results and act upon them.

> So, please consider this thread a bug report to that effect. How do I
> formalise this so it can be addressed as such?

What should we do? Add another bit flag "other_problem"?


Salam-Shalom,

   Werner

-- 
The pioneers of a warless world are the youth that
refuse military service.             - A. Einstein
-------------- next part --------------
A non-text attachment was scrubbed...
Name: openpgp-digital-signature.asc
Type: application/pgp-signature
Size: 247 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20240506/6733665c/attachment.sig>

From simon at josefsson.org  Mon May  6 14:49:46 2024
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 06 May 2024 14:49:46 +0200
Subject: Specification for Kyber in GnuPG
In-Reply-To: <87y18s67ff.fsf@jacob.g10code.de> (Werner Koch via Gnupg-devel's
 message of "Thu, 02 May 2024 08:42:44 +0200")
References: <87jzkg8uh7.fsf@jacob.g10code.de> <87y18s67ff.fsf@jacob.g10code.de>
Message-ID: <8734qvt89h.fsf@kaka.sjd.se>

Werner Koch via Gnupg-devel <gnupg-devel at gnupg.org> writes:

> +  - Prepare fixedInfo as specified above
>  
>    - Compute KEK := multiKeyCombine(eccKeyShare, eccCipherText,
>      mlkemKeyShare, mlkemCipherText, fixedInfo, 256) as defined in
> -    Section [](#KEM-Key-Combiner).
> +    Section [](#kem-key-combiner).

Where is multiKeyCombine defined?  I can't find it in
draft-koch-librepgp-00 nor in your patch.  I'm happy you included the
ciphertext in the combiner, but I'm trying to work out how strong the
binding to the Kyber public key material this has.

Is the source code of the file this patch is against public?  It is
easier to review a patched version of an entire document than a patch
against an unknown file.

/Simon
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 255 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20240506/fa652de0/attachment.sig>

From wk at gnupg.org  Mon May  6 14:59:08 2024
From: wk at gnupg.org (Werner Koch)
Date: Mon, 06 May 2024 14:59:08 +0200
Subject: Specification for Kyber in GnuPG
In-Reply-To: <8734qvt89h.fsf@kaka.sjd.se> (Simon Josefsson via Gnupg-devel's
 message of "Mon, 06 May 2024 14:49:46 +0200")
References: <87jzkg8uh7.fsf@jacob.g10code.de>
 <87y18s67ff.fsf@jacob.g10code.de> <8734qvt89h.fsf@kaka.sjd.se>
Message-ID: <87edaf2j1f.fsf@jacob.g10code.de>

On Mon,  6 May 2024 14:49, Simon Josefsson said:
> Werner Koch via Gnupg-devel <gnupg-devel at gnupg.org> writes:
>
>> +  - Prepare fixedInfo as specified above
>>  
>>    - Compute KEK := multiKeyCombine(eccKeyShare, eccCipherText,
>>      mlkemKeyShare, mlkemCipherText, fixedInfo, 256) as defined in
>> -    Section [](#KEM-Key-Combiner).
>> +    Section [](#kem-key-combiner).
>
> Where is multiKeyCombine defined?  I can't find it in

Line 6133 in the draft I posted today to librepgp-discuss
https://lists.gnupg.org/pipermail/librepgp-discuss/2024/000068.html

> draft-koch-librepgp-00 nor in your patch.  I'm happy you included the
> ciphertext in the combiner, but I'm trying to work out how strong the
> binding to the Kyber public key material this has.

That is the same as in draft-wussler-openpgp-pqc-03.txt.

> Is the source code of the file this patch is against public?  It is
> easier to review a patched version of an entire document than a patch
> against an unknown file.

git://git.gnupg.org/people/wk/rfc4880bis.git

and take rfc4880bis.md


Shalom-Salam,

   Werner

-- 
The pioneers of a warless world are the youth that
refuse military service.             - A. Einstein
-------------- next part --------------
A non-text attachment was scrubbed...
Name: openpgp-digital-signature.asc
Type: application/pgp-signature
Size: 247 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20240506/47fdb385/attachment.sig>

From heiko.schaefer at posteo.de  Mon May  6 14:37:55 2024
From: heiko.schaefer at posteo.de (=?UTF-8?Q?Heiko_Sch=C3=A4fer?=)
Date: Mon,  6 May 2024 12:37:55 +0000
Subject: Specification for Kyber in GnuPG
In-Reply-To: <87v83r2mov.fsf@jacob.g10code.de>
References: <87jzkg8uh7.fsf@jacob.g10code.de> <87y18s67ff.fsf@jacob.g10code.de>
 <BE4A733A-68D8-4489-998F-802456AAA844@andrewg.com>
 <875xvw5bl1.fsf@jacob.g10code.de>
 <73FDDD64-F433-4D99-A119-0EFB832EC4DE@andrewg.com>
 <87v83r2mov.fsf@jacob.g10code.de>
Message-ID: <ae6c8e61-2aba-4e1b-ab80-410a64666d45@posteo.de>

On 5/6/24 1:40 PM, Werner Koch via Gnupg-devel wrote:
> ps. Let me remark that this is not the IETF OpenPGP WG which
> unfortunately had been hijacked in 2022 by a small group of people
> trying to undermine the stability of the OpenPGP protocol with their
> irresponsible changes (aka crypto-refresh).

All of this is a very odd thing to write, from my perspective.

I'd like to point out for the record that this so-called "small group" 
included very active participation by Proton AG, who are the main 
implementers of both OpenPGP.js and GopenPGP (and who deploy one of the 
bigger OpenPGP-based products on the planet).

Also: "trying to undermine". Really?

Extraordinary claims require extraordinary evidence.
I'd love to see the evidence for that claim.

You seem to be saying that you believe a group of people has colluded to 
spend very many person years in the IETF process, just to make the 
OpenPGP standard worse? That does not sound like a very plausible 
assertion to me.

Maybe what you are actually trying to say is that there is a technical 
difference of opinion regarding the future direction of the standard.
And that you believe your judgment for a good future direction is more 
valid than that of some other group of people. Which ... sure, it's fair 
if that is your subjective assessment of the situation.
However, it almost appears to me as though you are attempting to 
underhandedly smear the parties on the other side of that difference of 
opinion.
Which, to my mind, wouldn't be a very good look.



From KaiE at kuix.de  Mon May  6 15:12:31 2024
From: KaiE at kuix.de (Kai Engert)
Date: Mon, 6 May 2024 15:12:31 +0200
Subject: Specification for Kyber in GnuPG
In-Reply-To: <8734qvt89h.fsf@kaka.sjd.se>
References: <87jzkg8uh7.fsf@jacob.g10code.de>
 <87y18s67ff.fsf@jacob.g10code.de> <8734qvt89h.fsf@kaka.sjd.se>
Message-ID: <055ec4c0-f230-417f-937c-ab5c135e4494@kuix.de>

On 06.05.24 14:49, Simon Josefsson via Gnupg-devel wrote:
> Is the source code of the file this patch is against public?  It is
> easier to review a patched version of an entire document than a patch
> against an unknown file.

The patch from Werner's email applies on this revision:
https://git.gnupg.org/cgi-bin/gitweb.cgi?p=people/wk/rfc4880bis.git;a=tree

of file rfc4880bis which can be found here:
https://git.gnupg.org/cgi-bin/gitweb.cgi?p=people/wk/rfc4880bis.git;a=tree

Kai



From simon at josefsson.org  Mon May  6 17:06:32 2024
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 06 May 2024 17:06:32 +0200
Subject: Specification for Kyber in GnuPG
In-Reply-To: <87edaf2j1f.fsf@jacob.g10code.de> (Werner Koch via Gnupg-devel's
 message of "Mon, 06 May 2024 14:59:08 +0200")
References: <87jzkg8uh7.fsf@jacob.g10code.de>
 <87y18s67ff.fsf@jacob.g10code.de> <8734qvt89h.fsf@kaka.sjd.se>
 <87edaf2j1f.fsf@jacob.g10code.de>
Message-ID: <87ttjbrnd3.fsf@kaka.sjd.se>

Werner Koch via Gnupg-devel <gnupg-devel at gnupg.org> writes:

> On Mon,  6 May 2024 14:49, Simon Josefsson said:
>> Werner Koch via Gnupg-devel <gnupg-devel at gnupg.org> writes:
>>
>>> +  - Prepare fixedInfo as specified above
>>>  
>>>    - Compute KEK := multiKeyCombine(eccKeyShare, eccCipherText,
>>>      mlkemKeyShare, mlkemCipherText, fixedInfo, 256) as defined in
>>> -    Section [](#KEM-Key-Combiner).
>>> +    Section [](#kem-key-combiner).
>>
>> Where is multiKeyCombine defined?  I can't find it in
>
> Line 6133 in the draft I posted today to librepgp-discuss
> https://lists.gnupg.org/pipermail/librepgp-discuss/2024/000068.html

Thank you!  As far as I can tell this doesn't strongly bind eccPublicKey
and mlkemPublicKey to the KEK which may complicate a security proof.

/Simon
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 255 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20240506/ed5a1c1c/attachment.sig>

From wk at gnupg.org  Mon May  6 17:09:24 2024
From: wk at gnupg.org (Werner Koch)
Date: Mon, 06 May 2024 17:09:24 +0200
Subject: Specification for Kyber in GnuPG
In-Reply-To: <ae6c8e61-2aba-4e1b-ab80-410a64666d45@posteo.de> ("Heiko
 =?utf-8?Q?Sch=C3=A4fer?=
 via Gnupg-devel"'s message of "Mon, 6 May 2024 12:37:55 +0000")
References: <87jzkg8uh7.fsf@jacob.g10code.de> <87y18s67ff.fsf@jacob.g10code.de>
 <BE4A733A-68D8-4489-998F-802456AAA844@andrewg.com>
 <875xvw5bl1.fsf@jacob.g10code.de>
 <73FDDD64-F433-4D99-A119-0EFB832EC4DE@andrewg.com>
 <87v83r2mov.fsf@jacob.g10code.de>
 <ae6c8e61-2aba-4e1b-ab80-410a64666d45@posteo.de>
Message-ID: <875xvr2d0b.fsf@jacob.g10code.de>

On Mon,  6 May 2024 12:37, Heiko Sch?fer said:

> to spend very many person years in the IETF process, just to make the
> OpenPGP standard worse? That does not sound like a very plausible

It took only a few month to destroy all work done in the 6 years before.
See our timeline over at http://librepgp.org/#timeline .

In short: I started the update of OpenPGP in 2015, the WG agreed 2018 on
everything in 4880bis, a few people started some bike shedding which
required another 3 years to solve.  Right after that in fall 2021, a
small group started to entirely rework everything.  In fact, Proton (who
don't really do E2E) introduced GCM as an additional encryption mode and
thus large changes to the protocol were required.  Nobody except them
needs or wants that brittle GCM anyway.  All comments from the major
implementers (GnuPG and RNP) were either ignored or as insubstantial
rejected.

Pretty please: Stop discussing this here.  We spent way to much time
with that IETF group's behaviour.  That group does not consider working
and deployed code as important but prefers a dev-ops strategy.


Shalom-Salam,

   Werner

-- 
The pioneers of a warless world are the youth that
refuse military service.             - A. Einstein
-------------- next part --------------
A non-text attachment was scrubbed...
Name: openpgp-digital-signature.asc
Type: application/pgp-signature
Size: 247 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20240506/d76537f6/attachment.sig>

From wk at gnupg.org  Mon May  6 17:13:24 2024
From: wk at gnupg.org (Werner Koch)
Date: Mon, 06 May 2024 17:13:24 +0200
Subject: Specification for Kyber in GnuPG
In-Reply-To: <87ttjbrnd3.fsf@kaka.sjd.se> (Simon Josefsson via Gnupg-devel's
 message of "Mon, 06 May 2024 17:06:32 +0200")
References: <87jzkg8uh7.fsf@jacob.g10code.de>
 <87y18s67ff.fsf@jacob.g10code.de> <8734qvt89h.fsf@kaka.sjd.se>
 <87edaf2j1f.fsf@jacob.g10code.de> <87ttjbrnd3.fsf@kaka.sjd.se>
Message-ID: <871q6f2ctn.fsf@jacob.g10code.de>

On Mon,  6 May 2024 17:06, Simon Josefsson said:

> Thank you!  As far as I can tell this doesn't strongly bind eccPublicKey
> and mlkemPublicKey to the KEK which may complicate a security proof.

Can you give a reason for this?  The fingerprint binds the two public
keys and it is an input to the key combiner.


Salam-Shalom,

   Werner

-- 
The pioneers of a warless world are the youth that
refuse military service.             - A. Einstein
-------------- next part --------------
A non-text attachment was scrubbed...
Name: openpgp-digital-signature.asc
Type: application/pgp-signature
Size: 247 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20240506/15b8d882/attachment.sig>

From simon at josefsson.org  Mon May  6 17:24:06 2024
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 06 May 2024 17:24:06 +0200
Subject: Specification for Kyber in GnuPG
In-Reply-To: <871q6f2ctn.fsf@jacob.g10code.de> (Werner Koch's message of "Mon, 
 06 May 2024 17:13:24 +0200")
References: <87jzkg8uh7.fsf@jacob.g10code.de>
 <87y18s67ff.fsf@jacob.g10code.de> <8734qvt89h.fsf@kaka.sjd.se>
 <87edaf2j1f.fsf@jacob.g10code.de> <87ttjbrnd3.fsf@kaka.sjd.se>
 <871q6f2ctn.fsf@jacob.g10code.de>
Message-ID: <87pltzrmjt.fsf@kaka.sjd.se>

Werner Koch <wk at gnupg.org> writes:

> On Mon,  6 May 2024 17:06, Simon Josefsson said:
>
>> Thank you!  As far as I can tell this doesn't strongly bind eccPublicKey
>> and mlkemPublicKey to the KEK which may complicate a security proof.
>
> Can you give a reason for this?  The fingerprint binds the two public
> keys and it is an input to the key combiner.

I haven't chaised the entire chain -- does it bind to the master key
fingerprint only, or to the Ecc+Kyber subkey too?

Including the public key in the KEK binding has been discussed before,
some references:

https://mailarchive.ietf.org/arch/msg/cfrg/84TUdtD0w12qFSNPpdV5ArS4-IE/

I'm not saying it is critical for security for the entire ECC+Kyber in
LibrePGP (I can't fit all of it in my head), but it makes it easier to
reason about security properties of the combiner on its own.

/Simon
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 255 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20240506/5c099588/attachment.sig>

From dave at sleepmap.de  Mon May  6 21:17:01 2024
From: dave at sleepmap.de (David Runge)
Date: Mon, 6 May 2024 21:17:01 +0200
Subject: Specification for Kyber in GnuPG
In-Reply-To: <875xvr2d0b.fsf@jacob.g10code.de>
References: <87jzkg8uh7.fsf@jacob.g10code.de> <87y18s67ff.fsf@jacob.g10code.de>
 <BE4A733A-68D8-4489-998F-802456AAA844@andrewg.com>
 <875xvw5bl1.fsf@jacob.g10code.de>
 <73FDDD64-F433-4D99-A119-0EFB832EC4DE@andrewg.com>
 <87v83r2mov.fsf@jacob.g10code.de>
 <ae6c8e61-2aba-4e1b-ab80-410a64666d45@posteo.de>
 <875xvr2d0b.fsf@jacob.g10code.de>
Message-ID: <Zjkst_z7dfBrpCdc@hmbx>

On 2024-05-06 17:09:24 (+0200), Werner Koch via Gnupg-devel wrote:
> Pretty please: Stop discussing this here.

Yet you are the one that keeps bringing this topic up over and over again.
Have you considered to stop doing so? That way you would not have to complain
that someone is asking you for actual facts for your claims.
And by facts I do not mean a marketing website full of inaccurate material such
as the one for LibrePGP.

I am not interested in your personal vendetta with your ex-employees (now
Sequoia-GPG), and I can not imagine anyone else on this list is.

I had hoped we were here to collaborate on technical matters, but it doesn't
seem that you are willing or able to do that at all.

> We spent way to much time with that IETF group's behaviour.

It's ironic, I keep thinking about how we all have to deal with yours, and it
saddens me that you are apparently unable to let your grudges go.

Quite frankly, this mailing list has become unbearable to read due to your
spiteful tirades, condescencion towards others and sheer unwillingness to
collaborate.

I don't think there is much to gain here for anyone anymore that isn't aligned
with what you dictate.
You are clearly no longer interested in a healthy OpenPGP ecosystem.

Hence, this is my last message to this list.

Bye
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20240506/59e0b1c8/attachment.sig>

From wk at gnupg.org  Tue May  7 09:26:01 2024
From: wk at gnupg.org (Werner Koch)
Date: Tue, 07 May 2024 09:26:01 +0200
Subject: Specification for Kyber in GnuPG
In-Reply-To: <87pltzrmjt.fsf@kaka.sjd.se> (Simon Josefsson via Gnupg-devel's
 message of "Mon, 06 May 2024 17:24:06 +0200")
References: <87jzkg8uh7.fsf@jacob.g10code.de>
 <87y18s67ff.fsf@jacob.g10code.de> <8734qvt89h.fsf@kaka.sjd.se>
 <87edaf2j1f.fsf@jacob.g10code.de> <87ttjbrnd3.fsf@kaka.sjd.se>
 <871q6f2ctn.fsf@jacob.g10code.de> <87pltzrmjt.fsf@kaka.sjd.se>
Message-ID: <87seyu13sm.fsf@jacob.g10code.de>

On Mon,  6 May 2024 17:24, Simon Josefsson said:

> I haven't chaised the entire chain -- does it bind to the master key
> fingerprint only, or to the Ecc+Kyber subkey too?

You mean the primary key?  No, it does not because that is not intended
by OpenPGP.  Doing so would not allow to move a subkey to another master
key.

> Including the public key in the KEK binding has been discussed before,
> some references:

Only taking the algorithm id is good iff there is one algorithm id per
ECC+ML-KEM combination.  This is not the case here and thus we need to
adjust for it.  Frankly, keeping the algo id is superfluous as it it
also part of the fingerprint but it does not harm either.

The other choice, would be to include the entire public key as in an
early draft, but the fingerprint is easier to describe.


Shalom-Salam,

   Werner

-- 
The pioneers of a warless world are the youth that
refuse military service.             - A. Einstein
-------------- next part --------------
A non-text attachment was scrubbed...
Name: openpgp-digital-signature.asc
Type: application/pgp-signature
Size: 247 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20240507/5832d00b/attachment.sig>

From KaiE at kuix.de  Wed May  8 00:32:19 2024
From: KaiE at kuix.de (Kai Engert)
Date: Wed, 8 May 2024 00:32:19 +0200
Subject: Specification for Kyber in GnuPG
In-Reply-To: <87y18s67ff.fsf@jacob.g10code.de>
References: <87jzkg8uh7.fsf@jacob.g10code.de> <87y18s67ff.fsf@jacob.g10code.de>
Message-ID: <2f3ac45e-97c2-46a7-8d37-bc7eac45592a@kuix.de>

On 02.05.24 08:42, Werner Koch via Gnupg-devel wrote:
> Many thanks to Stavros Kousidis, Falko Strenzke, and Aron Wussler for
> their draft on adding PQC to OpenPGP.  The algorithms used by LibgrePGP
> are the same except for the fixed info.  I took the freedom to remove
> the rationale parts which are not helpful for an implementer and was
> thus able to make the description more concise.

Hi Werner,

is my understanding correct, LibrePGP reuses most of the PQC 
specification from draft-ietf-openpgp-pqc, and your only concerns are 
about the algorithm IDs and the fixed info?

If that's correct, I think it's exciting that your views are so close to 
each other!

I wonder if the authors of draft-ietf-openpgp-pqc might be willing to 
accept these changes, for the sake of a common specification.

Would you be open to a shared specification for the PQC subkey format?

Furthermore, as I understand it, the v5 key format and the v6 key format 
are very close to each other (thanks a lot to Andrew Gallagher for 
enlightening me about this detail).

I wonder if we could find a way to introduce the specification of a v5 
format subkey (only) into an IETF specification, to allow the 
draft-ietf-openpgp-pqc specification to use it.

Actually, I think it would be better if there was a common 
specification, agreed to by both the LibrePGP and IETF groups. How could 
such a common specification be defined? Do you have ideas or suggestions?

I'm dreaming here, but I think it would be great to see a base 
specification, that extracts the common denominator of draft-librepgp 
and crypto-refresh, and which could be extended to contain the v5 subkey 
format. Then, draft-librepgp (and ideally crypto-refresh) could 
potentially be rewritten to be incremental specifications on top of the 
common denominator spec.

Thanks
Kai


From steffen at sdaoden.eu  Wed May  8 02:31:34 2024
From: steffen at sdaoden.eu (Steffen Nurpmeso)
Date: Wed, 08 May 2024 02:31:34 +0200
Subject: Fwd: Re: Specification for Kyber in GnuPG
Message-ID: <20240508003134.f3KdR3In@steffen%sdaoden.eu>

Unfortunately i got

  <gnupg-devel at gnupg.org>: host ellsberg.gnupg.com[176.9.119.14] said: 550 [SPF]
      217.144.132.164 is not allowed to send mail from sdaoden.eu. (in reply to
      MAIL FROM command)

which seems a bit square given that i DKIM sign my messages now,
and the SPF cannot have anything else but ~all because i speak to
people behind forwarders which do not use SRS rewriting, and what
is a SPF record of ~all worth, thus i had thrown it away.
(Worked for almost two months without problems.)

--- Forwarded from Steffen Nurpmeso <steffen at sdaoden.eu> ---
Date: Wed, 08 May 2024 02:13:53 +0200
Author: Steffen Nurpmeso <steffen at sdaoden.eu>
From: Steffen Nurpmeso <steffen at sdaoden.eu>
To: Kai Engert via Gnupg-devel <gnupg-devel at gnupg.org>
Subject: Re: Specification for Kyber in GnuPG
Message-ID: <20240508001353.Kz1gyZ6F at steffen%sdaoden.eu>
Mail-Followup-To: Kai Engert via Gnupg-devel <gnupg-devel at gnupg.org>
OpenPGP: id=EE19E1C1F2F7054F8D3954D8308964B51883A0DD; url=https://ftp.sdaoden.eu/steffen.asc; preference=signencrypt

Kai Engert via Gnupg-devel wrote in
 <2f3ac45e-97c2-46a7-8d37-bc7eac45592a at kuix.de>:
 |On 02.05.24 08:42, Werner Koch via Gnupg-devel wrote:
 |> Many thanks to Stavros Kousidis, Falko Strenzke, and Aron Wussler for
 |> their draft on adding PQC to OpenPGP.  The algorithms used by LibgrePGP
 |> are the same except for the fixed info.  I took the freedom to remove
 |> the rationale parts which are not helpful for an implementer and was
 |> thus able to make the description more concise.
 |
 |Hi Werner,
 |
 |is my understanding correct, LibrePGP reuses most of the PQC 
 |specification from draft-ietf-openpgp-pqc, and your only concerns are 
 |about the algorithm IDs and the fixed info?
 |
 |If that's correct, I think it's exciting that your views are so close to 
 |each other!
 |
 |I wonder if the authors of draft-ietf-openpgp-pqc might be willing to 
 |accept these changes, for the sake of a common specification.
 |
 |Would you be open to a shared specification for the PQC subkey format?
 |
 |Furthermore, as I understand it, the v5 key format and the v6 key format 
 |are very close to each other (thanks a lot to Andrew Gallagher for 
 |enlightening me about this detail).
 |
 |I wonder if we could find a way to introduce the specification of a v5 
 |format subkey (only) into an IETF specification, to allow the 
 |draft-ietf-openpgp-pqc specification to use it.
 |
 |Actually, I think it would be better if there was a common 
 |specification, agreed to by both the LibrePGP and IETF groups. How could 
 |such a common specification be defined? Do you have ideas or suggestions?
 |
 |I'm dreaming here, but I think it would be great to see a base 

I wholeheartly agree and would think that nearby a hundred percent
of all persons using OpenPGP of whatever kind do, too.  (And would
be surprised if not.)

 |specification, that extracts the common denominator of draft-librepgp 
 |and crypto-refresh, and which could be extended to contain the v5 subkey 
 |format. Then, draft-librepgp (and ideally crypto-refresh) could 
 |potentially be rewritten to be incremental specifications on top of the 
 |common denominator spec.
 --End of <2f3ac45e-97c2-46a7-8d37-bc7eac45592a at kuix.de>
...
 -- End forward <20240508001353.Kz1gyZ6F at steffen%sdaoden.eu>

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)


From wk at gnupg.org  Wed May  8 11:33:57 2024
From: wk at gnupg.org (Werner Koch)
Date: Wed, 08 May 2024 11:33:57 +0200
Subject: Specification for Kyber in GnuPG
In-Reply-To: <2f3ac45e-97c2-46a7-8d37-bc7eac45592a@kuix.de> (Kai Engert via
 Gnupg-devel's message of "Wed, 8 May 2024 00:32:19 +0200")
References: <87jzkg8uh7.fsf@jacob.g10code.de> <87y18s67ff.fsf@jacob.g10code.de>
 <2f3ac45e-97c2-46a7-8d37-bc7eac45592a@kuix.de>
Message-ID: <87a5l0zlyy.fsf@jacob.g10code.de>

Hi Kai,

On Wed,  8 May 2024 00:32, Kai Engert said:

> Furthermore, as I understand it, the v5 key format and the v6 key
> format are very close to each other (thanks a lot to Andrew Gallagher

It is not alone about the key packet version (which also flags some
other behaviour) but on the algorithm specific fields for the public key
system.  For the the same public key algorithm (e.g. EdDSA) they defined
new algorithms named after the curve (27 = Ed25519 and 28 = Ed448) and
deprecated the long established algorithm 22 (now called EdDSALegacy).
The obvious intention is to merge the parameters of the algorithm into
the algorithm id.  In their PQC draft they did the same and ended up
with a bunch of new algorithm ids for just 3 new algorithms.

Merging algorithms and their parameters into one algorithm id is the way
it is done in SSL/TLS but it is not the way it is done in PGP/OpenPGP.



Salam-Shalom,

   Werner


p.s.
We should eventually face the fact that crypto-refresh has ?hijacked?
the term OpenPGP for an entire new protocol.  This is why I started to
use ?*PGP? or ?LibrePGP?.  After 25 years of popularizing the term
?OpenPGP? over of GPG or PGP that is not easy ;-)

-- 
The pioneers of a warless world are the youth that
refuse military service.             - A. Einstein
-------------- next part --------------
A non-text attachment was scrubbed...
Name: openpgp-digital-signature.asc
Type: application/pgp-signature
Size: 247 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20240508/6f01dade/attachment.sig>

From KaiE at kuix.de  Sun May 12 16:49:34 2024
From: KaiE at kuix.de (Kai Engert)
Date: Sun, 12 May 2024 16:49:34 +0200
Subject: Specification for Kyber in GnuPG
In-Reply-To: <87a5l0zlyy.fsf@jacob.g10code.de>
References: <87jzkg8uh7.fsf@jacob.g10code.de> <87y18s67ff.fsf@jacob.g10code.de>
 <2f3ac45e-97c2-46a7-8d37-bc7eac45592a@kuix.de>
 <87a5l0zlyy.fsf@jacob.g10code.de>
Message-ID: <27e37d7d-c09e-45f4-adcc-beac94f863d0@kuix.de>

Hi Werner,

I understand you have strong opinions what's better, but I think the 
overall goal to protect users has the highest priority. I'd consider the 
encoding strategy of transport metadata, like the algorithm identifier 
or parameters, as a rather unimportant detail that shouldn't justify a 
schism.

If more users and implementations can share a single interoperable 
specification, the overall protection of users will be better, because 
it increases the chance that fallbacks to weaker, classic algorithms is 
unnecessary.

I would kindly ask for more willingness to compromise on the protocol 
level, for the sake of protecting users.

I recently saw a political cartoon, which reminded me of the term 
"Divide and Conquer".

I don't know if there is any actor who's actively playing that political 
game and is sowing discord, in order to weaking the OpenPGP protocol. 
But if someone is, we shouldn't let them win.

Kai


From jcb62281 at gmail.com  Mon May 13 03:18:13 2024
From: jcb62281 at gmail.com (Jacob Bachmeyer)
Date: Sun, 12 May 2024 20:18:13 -0500
Subject: Specification for Kyber in GnuPG
In-Reply-To: <27e37d7d-c09e-45f4-adcc-beac94f863d0@kuix.de>
References: <87jzkg8uh7.fsf@jacob.g10code.de> <87y18s67ff.fsf@jacob.g10code.de>
 <2f3ac45e-97c2-46a7-8d37-bc7eac45592a@kuix.de>
 <87a5l0zlyy.fsf@jacob.g10code.de>
 <27e37d7d-c09e-45f4-adcc-beac94f863d0@kuix.de>
Message-ID: <66416A55.7040505@gmail.com>

Kai Engert via Gnupg-devel wrote:
> [...]
>
> I recently saw a political cartoon, which reminded me of the term 
> "Divide and Conquer".
>
> I don't know if there is any actor who's actively playing that 
> political game and is sowing discord, in order to weaking the OpenPGP 
> protocol. But if someone is, we shouldn't let them win.

Observing the recent discussion on these mailing lists, and assuming 
that all comments (especially those about the way OpenPGP has previously 
handled parameterized algorithms) are accurate and truthful, it appears 
to me that the culpable parties are probably *not* on this mailing 
list.  In other words, OpenPGP algorithm IDs should refer to algorithm 
types (RSA, DSA, EC-RSA, McEliece, Kyber, etc.) with details (key 
length, curve parameters, etc.) included in type-specific fields in the 
key packets.  The other side of this debate is attempting to treat 
OpenPGP algorithm IDs like TLS ciphersuite IDs, which attach all of the 
details to each codepoint.

If someone is sowing discord, I presently believe that it is not the GPG 
maintainers.  If someone is trying to weaken the OpenPGP protocol, I 
believe it to be the parties pushing for less flexibility, where OpenPGP 
has historically allowed wide flexibility.


-- Jacob


From KaiE at kuix.de  Mon May 13 06:53:43 2024
From: KaiE at kuix.de (Kai Engert)
Date: Mon, 13 May 2024 06:53:43 +0200
Subject: Specification for Kyber in GnuPG
In-Reply-To: <66416A55.7040505@gmail.com>
References: <87jzkg8uh7.fsf@jacob.g10code.de> <87y18s67ff.fsf@jacob.g10code.de>
 <2f3ac45e-97c2-46a7-8d37-bc7eac45592a@kuix.de>
 <87a5l0zlyy.fsf@jacob.g10code.de>
 <27e37d7d-c09e-45f4-adcc-beac94f863d0@kuix.de> <66416A55.7040505@gmail.com>
Message-ID: <22f20d87-2435-4f59-a45d-a73a24f7cb1a@kuix.de>

On 13.05.24 03:18, Jacob Bachmeyer wrote:
> The other side of this debate is attempting to treat 
> OpenPGP algorithm IDs like TLS ciphersuite IDs, which attach all of the 
> details to each codepoint.
> 
> If someone is sowing discord, I presently believe that it is not the GPG 
> maintainers.? If someone is trying to weaken the OpenPGP protocol, I 
> believe it to be the parties pushing for less flexibility, where OpenPGP 
> has historically allowed wide flexibility.

In my understanding, the others argue that being less flexible is a benefit.

I cannot judge who's right. My point is, an attempt should be made to 
negotiate, rather than insisting on one approach being better. It 
doesn't seem that important.

For example, if the GnuPG developers said, that this detail is really 
important to them, and that it is the only remaining disagreement 
regarding the use of PQC with v4 primary keys, then the GnuPG developers 
could reach out of the others, and suggest to change this detail in 
order to reach a common specification.

That's what I suggest to do.

Thanks,
Kai


From andrewg at andrewg.com  Mon May 13 11:41:31 2024
From: andrewg at andrewg.com (Andrew Gallagher)
Date: Mon, 13 May 2024 10:41:31 +0100
Subject: Specification for Kyber in GnuPG
In-Reply-To: <66416A55.7040505@gmail.com>
References: <87jzkg8uh7.fsf@jacob.g10code.de> <87y18s67ff.fsf@jacob.g10code.de>
 <2f3ac45e-97c2-46a7-8d37-bc7eac45592a@kuix.de>
 <87a5l0zlyy.fsf@jacob.g10code.de>
 <27e37d7d-c09e-45f4-adcc-beac94f863d0@kuix.de> <66416A55.7040505@gmail.com>
Message-ID: <FA13A02A-2951-40C8-B334-A5CD36D7ACAA@andrewg.com>

On 13 May 2024, at 02:18, Jacob Bachmeyer via Gnupg-devel <gnupg-devel at gnupg.org> wrote:
> 
> it appears to me that the culpable parties are probably *not* on this mailing list.  In other words, OpenPGP algorithm IDs should refer to algorithm types (RSA, DSA, EC-RSA, McEliece, Kyber, etc.) with details (key length, curve parameters, etc.) included in type-specific fields in the key packets.  The other side of this debate is attempting to treat OpenPGP algorithm IDs like TLS ciphersuite IDs, which attach all of the details to each codepoint.

OpenPGP algorithm IDs have historically referred to broad algorithm types. I think the crucial part of this disagreement is whether historical practice should be continued in this instance, or whether it is preferable to limit the number of free parameters for future algorithms.

(BTW this is not the same code point allocation model as TLS. TLS ciphersuites also include the AEAD mode, which remains a separate registry in *PGP)

A

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20240513/4f9ab5b2/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20240513/4f9ab5b2/attachment.sig>

From team at token2.ch  Mon May 20 11:41:02 2024
From: team at token2.ch (TOKEN2 Support Team)
Date: Mon, 20 May 2024 09:41:02 +0000
Subject: OpenPGP Card manufacturer id
Message-ID: <DB9PR07MB8539D4A40DB5113F49B14D4F8BE92@DB9PR07MB8539.eurprd07.prod.outlook.com>

Hello,

We are planning to add OpenPGP functionality to one of our products, and it seems we need to obtain a manufacturer ID. Could anyone assist us in getting such an ID assigned?

The only reference we found for this procedure was on this mailing list. Therefore, in addition to requesting this by email from FSFE, we are also posting here. We apologize if this results in a duplicate message.

Regards,
TOKEN2 Team



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20240520/3f648e58/attachment-0001.html>

From team at token2.ch  Mon May 20 11:48:49 2024
From: team at token2.ch (TOKEN2 Support Team)
Date: Mon, 20 May 2024 09:48:49 +0000
Subject: OpenPGP Card manufacturer id
In-Reply-To: <DB9PR07MB8539D4A40DB5113F49B14D4F8BE92@DB9PR07MB8539.eurprd07.prod.outlook.com>
References: <DB9PR07MB8539D4A40DB5113F49B14D4F8BE92@DB9PR07MB8539.eurprd07.prod.outlook.com>
Message-ID: <DB9PR07MB8539981F23AF9FB39E1D8E188BE92@DB9PR07MB8539.eurprd07.prod.outlook.com>


Hello,

We are planning to add OpenPGP functionality to one of our products, and it seems we need to obtain a manufacturer ID. Could anyone assist us in getting such an ID assigned?

The only reference we found for this procedure was on this mailing list. Therefore, in addition to requesting this by email from FSFE, we are also posting here. We apologize if this results in a duplicate message.

Regards,
TOKEN2 Team



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20240520/937ff375/attachment.html>

From wk at gnupg.org  Tue May 21 10:48:17 2024
From: wk at gnupg.org (Werner Koch)
Date: Tue, 21 May 2024 10:48:17 +0200
Subject: OpenPGP Card manufacturer id
In-Reply-To: <DB9PR07MB8539D4A40DB5113F49B14D4F8BE92@DB9PR07MB8539.eurprd07.prod.outlook.com>
 (TOKEN's message of "Mon, 20 May 2024 09:41:02 +0000")
References: <DB9PR07MB8539D4A40DB5113F49B14D4F8BE92@DB9PR07MB8539.eurprd07.prod.outlook.com>
Message-ID: <877cfnv9da.fsf@jacob.g10code.de>

Hi!

On Mon, 20 May 2024 09:41, TOKEN2 Support Team said:

> and it seems we need to obtain a manufacturer ID. Could anyone assist
> us in getting such an ID assigned?

The easiest way is to write me a private mail including your mail
address, web address, and a brief reason why you need a vendor id.  No
HTML mail parts please.  Note that we don't assign them for experiments
or small scale deployments - therefore it is better to take the id from
the random range

   0xFF00..FFFE - Range reserved for randomly assigned serial numbers.

   Serialnumbers with manufacturer ID in this range are an exception
   to the rule that they should be unique.  It is expected that such a
   serialnumber is assigned using a true random function which
   generates 5 bytes (4 for the actual serial number and one to select
   a manufacturer ID out of this range). Note, that the 0xffff is not
   part of this range.  Implementers using serial numbers as a unique
   ID should keep in mind that duplicates may happen.  Using the of
   manufacturer IDs out of this range should only be done if no other
   way of obtaining a manufacturer ID is possible.



Shalom-Salam,

   Werner

-- 
The pioneers of a warless world are the youth that
refuse military service.             - A. Einstein
-------------- next part --------------
A non-text attachment was scrubbed...
Name: openpgp-digital-signature.asc
Type: application/pgp-signature
Size: 247 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20240521/039531da/attachment.sig>