Mailing List Archive

On Tue, 13 Dec 2022 09:35:22 +0100,
Bernhard Reiter wrote:
> (Same as you did when you have decided to made keys.openpgp.org incompatible
> to the existing OpenPGP standard, by not adding the necessary signature, see
> https://dev.gnupg.org/T4393 and blame it as defect on your page
> https://keys.openpgp.org/about/faq)

I think you are misreading the standard here. My reading of 4880 is
the grammar for certificates explicitly says that self signatures on
User ID packets are optional:

- One or more User ID packets

- After each User ID packet, zero or more Signature packets
(certifications)

...

Immediately following each User ID packet, there are zero or more
Signature packets.

https://www.rfc-editor.org/rfc/rfc4880#section-11.1

So, I think gpg's behavior diverges from the standard here.

Can you point me to the text in 4880 that supports your view that User
IDs must have self signatures?

Thanks,

Neal

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-devel

Hi, Bernhard.

On 13 Dec 2022, at 08:35, Bernhard Reiter <bernhard@intevation.de> wrote:
>
> Hi Vincent,
>
>> Given that this commit was merged roughly two weeks after the
>> aforementioned decision, should this be
>> understood that GnuPG intends to focus on its own packet format instead
>> of standardized OpenPGP?
>
> the working group has not yet come up with a needed refresh for many years.
> It has to be seen if whatever the IETF workgroup comes up with
> is a good update to RFC4880. (At least this is my personal view on this, I am
> not really involved in GnuPG's nor in the working group's work in this area.)

“It remains to be seen” is the crucial phrase there. Making 4880-bis the default behaviour in master appears to be prejudging the outcome of the standardisation process, with potentially damaging consequences for the wider ecosystem. 4880-bis differs in some crucial places, making it incompatible with the current WG draft.

If GnuPG chose 4880-bis instead of the new RFC (whatever it may be), then other implementations would have to choose whether to support 4880-bis as an extra compatibility mode, break compatibility with GnuPG going forward, or find themselves bounced into abandoning the RFC process. None of those outcomes would be desirable.

Several people have asked for clarification on a number of occasions but none appears to be forthcoming. Vincent’s question is valid, and we should be careful not to derail this thread with other arguments.

A

Hey Bernhard,

On 13.12.22 09:35, Bernhard Reiter wrote:
> the working group has not yet come up with a needed refresh for many years.
> It has to be seen if whatever the IETF workgroup comes up with
> is a good update to RFC4880. (At least this is my personal view on this, I am
> not really involved in GnuPG's nor in the working group's work in this area.)

I'm not sure how you would qualify a "good" update here? If there is a new
revision it'll be the standard by definition, and you can conform to it
or not.

If you have doubts it will be a "good" update, they are currently asking for
a last round of feedback on it.

> In previous IETF OpenPGP standardisation processes, it seems that well working
> practice was considered to a large extend, it seems natural up to a point to
> try and see if new things are needed and useful.
Agreed. That's what the --rfc4880bis flag did, and reasonably so. But unless
I misread the commit, we're talking about GnuPG emitting a GnuPG-specific
certificate format by default here, so no experiment by any means?
> (Same as you did when you have decided to made keys.openpgp.org incompatible
> to the existing OpenPGP standard

Indeed, so I did. Notably the way we made it incompatible was fairly widely
discussed and thought acceptable, so much so that it was included in the
[rfc4880bis-05] draft Werner specified at the time, and is now also so
in the
[crypto-refresh-07] draft. Should also mention that the breakage here is
something that can be adapted to in GnuPG by a five lines patch, which is
not quite the same as a major version step of the OpenPGP message format.

What's more important however is that we were always open about this
decision, gave the specific reasoning and plans, and discussed it with
anyone who was interested, and did active outreach about it. Doesn't
mean we ended up agreeing on the issue, but c'est la vie.

> I am referring to this, because I do not like the insinuation of your email
> that GnuPG would be aiming to be incompatible

I'm not insinuating anything, I'm openly pointing out a commit that changes
GnuPG default behavior in a significant way, and asking what the plans here
are.

Cheers

 - V

[rfc4880bis-05]:
https://gitlab.com/openpgp-wg/rfc4880bis/-/blob/main/old-drafts/draft-ietf-openpgp-rfc4880bis-05.txt#L4587

[T4393]: https://dev.gnupg.org/T4393#136751

[crypto-refresh-07]:
https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-07.html#section-11.1.2


_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-devel

On Tue, 13 Dec 2022 10:07:07 +0100,
Neal H. Walfield wrote:
>
> On Tue, 13 Dec 2022 09:35:22 +0100,
> Bernhard Reiter wrote:
> > (Same as you did when you have decided to made keys.openpgp.org incompatible
> > to the existing OpenPGP standard, by not adding the necessary signature, see
> > https://dev.gnupg.org/T4393 and blame it as defect on your page
> > https://keys.openpgp.org/about/faq)
>
> I think you are misreading the standard here. My reading of 4880 is
> the grammar for certificates explicitly says that self signatures on
> User ID packets are optional:
>
> - One or more User ID packets
>
> - After each User ID packet, zero or more Signature packets
> (certifications)
>
> ...
>
> Immediately following each User ID packet, there are zero or more
> Signature packets.
>
> https://www.rfc-editor.org/rfc/rfc4880#section-11.1
>
> So, I think gpg's behavior diverges from the standard here.
>
> Can you point me to the text in 4880 that supports your view that User
> IDs must have self signatures?

It was pointed out to me privately that there are actually two issues:

1. User ID-less certificates (out of spec)
2. User IDs without self signatures (in spec)

4880 allows User IDs without self signatures (2), but it does require
that a certificate include at least one User ID, which needn't have a
self-signature.

koo is out of spec, because it delivers certificates without User IDs
(1). It come into spec by inserting a null User ID without a self
signature (2). As I understand it, gpg would treat that (2) the same
way as it treats a certificate without any User IDs (1).

Neal

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-devel

Am Dienstag 13 Dezember 2022 12:33:35 schrieb Neal H. Walfield:
> koo is out of spec, because it delivers certificates without User IDs
> (1). ?It come into spec by inserting a null User ID without a self
> signature (2).

Though that seems to be a mechanistic compliance, which does not make
much sense. So I'd still consider this out of speficiation because
the user ID would be useless and obviously not performing the intentions
expressed in RFC4880.

> As I understand it, gpg would treat that (2) the same
> way as it treats a certificate without any User IDs (1).

If this is the case (which I do not know for sure), it looks like a good
decision for an implementation which stays in line with the purpose of
what the User ID was meant for in the specification (and real use).

Regards
Bernhard

--
https://intevation.de/~bernhard ? +49 541 33 508 3-3
Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998
Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter

Hi Andrew,

Am Dienstag 13 Dezember 2022 12:02:41 schrieb Andrew Gallagher via
Gnupg-devel:
> “It remains to be seen” is the crucial phrase there. Making 4880-bis the
> default behaviour in master appears to be prejudging the outcome of the
> standardisation process, with potentially damaging consequences for the
> wider ecosystem. 4880-bis differs in some crucial places, making it
> incompatible with the current WG draft.

however you could ask the same questions to the WG: Why are they attempting to
standardise variants that one of the main contributor to OpenPGP does not see
as favourable to OpenPGP? Real usage has been an important factor to
standardisation.

The very long process of the WG let me conclude that there were some problems
with it. I have not put in the time to look into the details, so I do not
know, but just with a bit of distance something does not work out there.
I do not know how much technical need there is to go beyond RFC4880
(and other RFCs) and if standardisation processes do not work out,
implementations will go ahead, sometimes they even must.
It can be a good thing.

Dragging something out in a committee in genernal can also wear those players
thin that care more for the technical part and are less well funded.
Again I do not know if this is happening with the IETF WG, just pointing
to a general pattern and that would match to sime extend to that what is
observable from a distance.

> If GnuPG chose 4880-bis instead of the new RFC (whatever it may be), then
> other implementations would have to choose whether to support 4880-bis as
> an extra compatibility mode, break compatibility with GnuPG going forward,
> or find themselves bounced into abandoning the RFC process. None of those
> outcomes would be desirable.

It is in my interest to have an interoperable specification and get good
end-to-end crypto implementations to users. Being associated with
GnuPG/Gpg4win on the business side via my company as well, I want it to be
treated fairly. I welcome competition, especially if it is Free Software
and we work together towards makeing the work better for users.

In recent years the field has gotten more difficult with some exchanges
that I did not find fair. This is why I've jumped on this question, I am not
sure that I, if I was Werner, would put in the time to answer it. Partly
because it is placed and framed in a way that does not seem to seek
understanding and cooperation, but to make GnuPG look bad.
Why would someone answer that?

> Several people have asked for clarification on a number of occasions but
> none appears to be forthcoming.

(BTW if those exchanges are publically available, can you point me to them?)

> Vincent’s question is valid, and we should
> be careful not to derail this thread with other arguments.

I assume Werner has explained his plans to the WG over many years.
(At least he wrote a lot of the drafts and participated.)
Why does he has the burden to explain why this technically does not go
together anymore? Overal I believe the way how this is asked and understood
from the persons begin asked, is decisive for how they answer.

Regards
Bernhard
--
https://intevation.de/~bernhard   +49 541 33 508 3-3
Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998
Geschäftsführer Frank Koormann, Bernhard Reiter

Hey Vincent,

Am Dienstag 13 Dezember 2022 12:07:20 schrieb Vincent Breitmoser via
Gnupg-devel:
> On 13.12.22 09:35, Bernhard Reiter wrote:
> > It has to be seen if whatever the IETF workgroup comes up with
> > is a good update to RFC4880.

> I'm not sure how you would qualify a "good" update here?

something that is useful to users (in the end) and updated RFC4880
in an interoperable and technical good way for asychronous, end-to-end
cryptopgraphy. (Rough, I know, but maybe good enough for this post.)

> If there is a new revision it'll be the standard by definition,
> and you can conform to it or not.

It still maybe a bad revision.
And yes, this comes down to the question of who will be able to shape and
define what OpenPGP is. Usage has always had an important influence on
evolving standards, this is why I have added the case of your koo deliberate
incompatibility to RFC4480 as an example.

> If you have doubts it will be a "good" update, they are currently asking
> for a last round of feedback on it.

To put time into the committee work personally I would need to be convinced
that it is well invested time. Given that Werner, Niibe-San and others will
have given technical feedback already, I am not sure if it is worth the time.
(See my answer to Andrew for more elaboration.)

> > In previous IETF OpenPGP standardisation processes, it seems that well
> > working practice was considered to a large extend, it seems natural up to
> > a point to try and see if new things are needed and useful.
>
> Agreed. That's what the --rfc4880bis flag did, and reasonably so. But
> unless I misread the commit, we're talking about GnuPG emitting a
> GnuPG-specific certificate format by default here, so no experiment by any
> means?

I don't know. But what were the reasons the current working group did decide
to go with a different package format? Do you think it was the better choice?

> > (Same as you did when you have decided to made keys.openpgp.org
> > incompatible to the existing OpenPGP standard
>
> Indeed, so I did.
[rest of the example cut out]

> I'm not insinuating anything, I'm openly pointing out a commit that changes
> GnuPG default behavior in a significant way, and asking what the plans here
> are.

When I have read your email, the subject and the
"will be incompatible with the upcoming OpenPGP standard."
and your remark at
https://dev.gnupg.org/rG4583f4fe2e11b3dd070066628c3f16776cc74f72#75449
leans my understanding towards a non constructive question, because it frames
the burden of answering it onto GnuPG's devs.

It is the little things in your phrasing
a) The WG does not yet has a new spec on "OpenPGP" only proposal.
b) The WG does not define alone what "OpenPGP" is in the wild.

And the framing and omissions:
c) you do understand that there are good reasons
for going ahead in an implementation, even if it is not ahereing to the
standardised protocols. But you are not displaying that you have given the
potential reasons a deep thought in the question or on the list here.
d) You do not explain or ask what and why the WG is going a way to be
incompatible to a useful and widely deployed implementation (and long time
contributors to the WGs.)

Regards
Bernhard
--
https://intevation.de/~bernhard   +49 541 33 508 3-3
Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998
Geschäftsführer Frank Koormann, Bernhard Reiter

On 15 Dec 2022, at 08:44, Bernhard Reiter <bernhard@intevation.de> wrote:
>
> In recent years the field has gotten more difficult with some exchanges
> that I did not find fair. This is why I've jumped on this question, I am not
> sure that I, if I was Werner, would put in the time to answer it. Partly
> because it is placed and framed in a way that does not seem to seek
> understanding and cooperation, but to make GnuPG look bad.
> Why would someone answer that?

I agree, the tone of some exchanges recently has been less than ideal. I’m involved in the WG mainly to speak up for the keyservers, and to offer native-English-speaking proofreading whenever I have the time. I’m also agnostic on many of the technical arguments leading up to this particular incident. I’m *not* agnostic on the need for a unified spec, or the need to get crypto-refresh resolved so we can finalise sig attestations (which are vital for the survival of the keyservers but are currently out of scope in the WG). If all the implementors are still invested in the standardisation process, then let’s find a way to work through whatever disagreements remain. Otherwise, let’s (reluctantly) accept that and manage the consequences. But we should know which of these cases applies. At the moment there is a lot of wild speculation, accusations of bad faith, and unprofessional language going around which is not helping.

>> Several people have asked for clarification on a number of occasions but
>> none appears to be forthcoming.
>
> (BTW if those exchanges are publically available, can you point me to them?)

https://mailarchive.ietf.org/arch/msg/openpgp/q7wl70rBx1I89ThFc-o2zOIPez0/?

A

On Thu, Dec 15, 2022 at 09:21:41AM +0100, Bernhard Reiter wrote:
> Am Dienstag 13 Dezember 2022 12:33:35 schrieb Neal H. Walfield:
> > koo is out of spec, because it delivers certificates without User IDs
> > (1). ?It come into spec by inserting a null User ID without a self
> > signature (2).

That is interesting. Where then would things like user preferences, which are
normally kept in the self signatures, reside?

Bruce

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-devel

Hey Bernhard,

we can spend a long time arguing about context here, but I'd rather not
remove the thread further from the core of it:

The quoted commit is a big decision for GnuPG.

It will have a large effect on GnuPG, its users, and the wider ecosystem.

This justifiably leaves people wondering what GnuPG's plans are for the
future.

 - V


_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-devel

Hey Vincent,

Am Donnerstag 15 Dezember 2022 15:05:38 schrieb Vincent Breitmoser via
Gnupg-devel:
> The quoted commit is a big decision for GnuPG.

and the WG decision to become incompatible with the previous drafts
were a big decision for the working group affecting
OpenPGP users, implementations and the wider ecosystem.

What are their plans for this problem?

Regards
Bernhard

--
https://intevation.de/~bernhard   +49 541 33 508 3-3
Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998
Geschäftsführer Frank Koormann, Bernhard Reiter

On 19 Dec 2022, at 09:19, Bernhard Reiter <bernhard@intevation.de> wrote:
>
> Signed PGP part
> Hey Vincent,
>
> Am Donnerstag 15 Dezember 2022 15:05:38 schrieb Vincent Breitmoser via
> Gnupg-devel:
>> The quoted commit is a big decision for GnuPG.
>
> and the WG decision to become incompatible with the previous drafts
> were a big decision for the working group affecting
> OpenPGP users, implementations and the wider ecosystem.
>
> What are their plans for this problem?

To be fair to Vincent, he doesn’t answer for the WG (and neither do I). The chairs have recommended that all reasonable effort be made to remove breaking incompatibilities between -bis and crypto-refresh:

https://mailarchive.ietf.org/arch/msg/openpgp/yayGaIen3DW6ixwrJkP-QcAcFSQ/?

However this has not prevented a lot of unhelpful and premature speculation about forking the standard or skipping version numbers to avoid dealing with the issue.

A

This entire shit is disgusting to the core, in the IETF group and
anywhere else. My wish would be that noone is able to hammer its
piolet sufficiently deep due to all this.

--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)

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-devel

Hi Bernhard and list,

> and the WG decision to become incompatible with the previous drafts
> were a big decision for the working group affecting
> OpenPGP users, implementations and the wider ecosystem.

That is true. And the decision has not been made lightly.
As any WG work, this is a public process: There has been a lot of
discussion,
over a lengthy period of time, with input from many individuals and
projects.

https://mailarchive.ietf.org/arch/msg/openpgp/PWp3ZcZ_qnDNLhuT-zR7gA2ddeg/

It's a complex topic and hard to do justice in summary.

In particular for Werner's side I'll admit I didn't really understand
what's going on.
Hence the concrete question here what the plans are for the future of
his concrete project.

Cheers

 - V


_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-devel

On Tue, 20 Dec 2022 11:38, Vincent Breitmoser said:

> As any WG work, this is a public process: There has been a lot of

Which is not entirely true. The crypto-refresh folks worked in a closed
design team and presented their results to the WG. Comments from WG
members which challenged the outcome were mostly rejected or ignored.

For the records:

I had been part of the design team. Actually Stephen called me once to
setup this DT so to solve the blocks we mainly had due to some bike
shedding. It took a bit longer then expected to set it up but we were
then able to solve the blocking issues in a way which all participants
could agreed on - including me (as GnuPG author and assigned editor of
the WG). Due to time constrains I quiet the DT which had only editorial
tasks open. Unfortunately they the started to revamp the entire
specification and presented that as the new crypto-refresh.

> In particular for Werner's side I'll admit I didn't really understand
> what's going on.

I described this too often to repeat it again. But anyway in short: The
OpenPGP WG turned into design-by-commitee mode. Which is yet another
tombstone for the IETF.



Shalom-Salam,

Werner


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

On 12/20/22 15:55, Werner Koch via Gnupg-devel wrote:
> On Tue, 20 Dec 2022 11:38, Vincent Breitmoser said:
>
>> As any WG work, this is a public process: There has been a lot of
> Which is not entirely true. The crypto-refresh folks worked in a closed
> design team and presented their results to the WG. Comments from WG
> members which challenged the outcome were mostly rejected or ignored.

I'm confused by the characterization of the work as "closed". As an
interested outside observer I could easily follow the group's process
via the mailing list
(https://mailarchive.ietf.org/arch/browse/openpgp/), and I notice that
you have also posted to that list on a number of occasions.

Obviously a consensus-based process will reject some inputs. That fact
by itself does not seem unusual to me.
If you have pointers to important input that you feel was unreasonably
rejected on the mailing list, I'd be interested to see those.

Thanks,
Heiko

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-devel

On Mittwoch, 21. Dezember 2022 01:40:28 CET Heiko Sch?fer via Gnupg-devel
wrote:
> On 12/20/22 15:55, Werner Koch via Gnupg-devel wrote:
> > On Tue, 20 Dec 2022 11:38, Vincent Breitmoser said:
> >> As any WG work, this is a public process: There has been a lot of
> >
> > Which is not entirely true. The crypto-refresh folks worked in a closed
> > design team and presented their results to the WG. Comments from WG
> > members which challenged the outcome were mostly rejected or ignored.
>
> I'm confused by the characterization of the work as "closed". As an
> interested outside observer I could easily follow the group's process
> via the mailing list
> (https://mailarchive.ietf.org/arch/browse/openpgp/),

That's the mailing list of the WG and not the closed one (with open archive)
used by the DT.

> and I notice that
> you have also posted to that list on a number of occasions.

https://mailarchive.ietf.org/arch/msg/openpgp/9uPRgtbWMQZoho-AfxdBlSpGPZc/
reads
"
For those less familiar with the IETF's design team (DT)
concept, a DT is a group selected by chairs who do some work
that is then an input to the WG - whether or not the WG have
rough consensus on the DT output is up to the WG and not the
DT. For this DT, we'll have a closed mailing list with an
open archive, and, as stated, roughly monthly calls.
"

Regards,
Ingo

On Wed, 21 Dec 2022 10:30, Ingo Klöcker said:

> That's the mailing list of the WG and not the closed one (with open archive)
> used by the DT.

And lots of video calls not all covered by the minutes.


Shalom-Salam,

Werner

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

Hi Justus,

On Donnerstag, 22. Dezember 2022 13:01:08 CET Justus Winter wrote:
> Werner Koch via Gnupg-devel <gnupg-devel@gnupg.org> writes:
> > On Wed, 21 Dec 2022 10:30, Ingo Kl?cker said:
> >> That's the mailing list of the WG and not the closed one (with open
> >> archive) used by the DT.
>
> For the record, said archive is here:
> https://mailarchive.ietf.org/arch/browse/openpgp-dt/
>
> I'm not sure why the list has been characterized as closed.

The DT itself has characterized their mailing list as closed:
"
For this DT, we'll have a closed mailing list with an
open archive, and, as stated, roughly monthly calls.
"
https://mailarchive.ietf.org/arch/msg/openpgp/9uPRgtbWMQZoho-AfxdBlSpGPZc/

Regards,
Ingo

(Resent, earlier mail got lost in somewhere in the mail server
configuration jungle.)

Moin Werner :)

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

> On Wed, 21 Dec 2022 10:30, Ingo Klöcker said:
>
>> That's the mailing list of the WG and not the closed one (with open archive)
>> used by the DT.

For the record, said archive is here:
https://mailarchive.ietf.org/arch/browse/openpgp-dt/

I'm not sure why the list has been characterized as closed. It is true
that you could not self-subscribe, but everyone was able to post to that
list. We did add people to the design team after its inception
(Jeffrey), and I'm not aware that anyone was denied access to the design
team or the corresponding mailing list.

> And lots of video calls not all covered by the minutes.

I'm saddened that your trust in the process has been shaken. However,
it is not true that there were design team meetings not covered by
public notes. In fact, I made a list of every meeting and corresponding
notes:

https://mailarchive.ietf.org/arch/msg/openpgp/9-WktrFNuZVYZVwlAKl0J56k5Vc/

If you think there were meetings not covered by the notes, I'd be
interested to hear which ones you are thinking of.

Best,
Justus