On 2 Apr 2024, at 15:24, Werner Koch <w...@gnupg.org> wrote: > > On Tue, 2 Apr 2024 12:39, Andrew Gallagher said: > >> Are you saying that this is *not* a novel failure mode? Because we’ve > > No. We had v2, v3 and v4 keyes in all kind of combinations in the past > (even as part of subkeys) and back then the two OpenPGP implementations > had no problems with that. The whole point of packet version numbers is > to be able to ignore such packets.
This intrigued me, so I went back through the SKS dataset and found exactly four (4) v4 primary keys with v3 subkeys. This was quite a technical challenge since no modern software supports them, and gnupg1 doesn’t implement --list-packets :-) But I have to admit they do exist… and rfc4880 technically doesn’t forbid them. Still, I’m sure most people would find their existence as surprising as that of v3 sbinds over v4 subkeys (which are several orders of magnitude more common). >> different version number (since v3 did not support subkeys). Have you >> interop-tested this with other implementations? Besides RNP? What were > > If there are new implementaions they should check interop with the > de-facto standards which are PGP, GnuPG and later RNP. There is also > the widely used BouncyCastle library and we have not seen problems with > it except when ppl ignore features of these library. BouncyCastle is quite low level, and AFAICT does not enforce much in the way of packet grammar etc., so may not be the best comparison. And surely the entire point of a written specification is to avoid "de-facto standard” reference implementations? > But let me remark for the records that GnuPG has been the entity which > always used the term /OpenPGP/ instead of /PGP/ or - as many Linux > people did - the term /GPG/ keys. Thus we, and in particular me, > stressed that this is the OpenPGP standard which GnuPG implements, > popularized, took care, and pride of. Sure it does no "belong" to us or > anyone - it is term without having a trademark. This is fair, and thank you. Not everyone is so careful. > OTOH, tehre is a > respoisbility here to keep the repudiation of that standard high - this > is what the /current OpenPGP WG participants/ don't a do anymore since > fall 2021. Reputation is a matter of publicly expressed opinion, and by far the greatest amount of text declaring that OpenPGP no longer has a good reputation has been written by you. So this is a circular argument. >>> how should an implementation behave if it wants to support both the >>> librepgp and crypto-refresh specs? > > That is up to those implementaions who want to destroy a solid standard. > Why should I help them? Let us be clear here: you appear to be saying that if I want to update hockeypuck to support both librepgp and crypto-refresh artifacts, I am helping to destroy a solid standard? Or have I misunderstood your position? > This is a GnuPG mailing list and you are > welcome to discuss technical details of stuff relevant to GnuPG and > OpenPGP (up to fall 2021). Everything else is better addressed to the > crypto-refresh commitee. I will bring this to the WG, with your comments. Thanks, A
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
