Re: x488 vs all other : keyid flip
On 2 Apr 2024, at 15:24, Werner Koch 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
Re: x488 vs all other : keyid flip
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. > 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. > 3. The term “OpenPGP” does not belong to GnuPG. 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. 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. > And I notice that you have not addressed the most important point in > my last email: > >> 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? 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. Shalom-Salam, Werner -- The pioneers of a warless world are the youth that refuse military service. - A. Einstein openpgp-digital-signature.asc Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
[OFF-TOPIC] gpg-agent, sshd and/or SELinux (was Re: Get the private portion of subkeys)
Hi, Werner, all. Please let me take this opportunity to ask you for trustable documentation, or any other resource, which could help interested users like myself in providing the gpg-agent with ssh client and daemon errands, on both fresh and not-so-fresh OS installs. Please consider SELinux contexts if possible. Regards, Marcio Barbado, Jr. On Thu, 28 Mar 2024 at 07:01 Werner Koch via Gnupg-users < gnupg-users@gnupg.org> wrote: > On Thu, 28 Mar 2024 08:26, Damien Cassou said: > > > Is that a problem? Am I missing something important? It seems this > > causes me the troubles mentioned at [1]. > > Your subkeys are all stored on a smartcard. The primary key is online. > This is as intended. If you remove the the primary private key > (.key) You should see a '#' mark for the primary key. > > > My private master key is symlinked in ~/.gnupg/private-keys-v1.d: > > That is intended to work but has not been thoroughly tested. > > > [1] https://github.com/pinpox/pgp2ssh/issues/6 > > That reminds me that we have a function export_secret_ssh_key but it > will always fail with a not-implemented error ;-). Noone of the core > hackers felt a need for it. For example I have not used anything else > than gpg-agent based ssh access since 2005. > > > Shalom-Salam, > >Werner > > > -- > The pioneers of a warless world are the youth that > refuse military service. - A. Einstein > ___ > Gnupg-users mailing list > Gnupg-users@gnupg.org > https://lists.gnupg.org/mailman/listinfo/gnupg-users > ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: x488 vs all other : keyid flip
On 2 Apr 2024, at 11:58, Werner Koch wrote: > > On Fri, 29 Mar 2024 13:00, Andrew Gallagher said: > >> V5 subkeys of v4 primary keys would appear to introduce a novel >> failure mode. It should be noted that in crypto-refresh, adding a > > Nope. Are you saying that this is *not* a novel failure mode? Because we’ve never before had a key of one version number with a subkey of a different version number (since v3 did not support subkeys). Have you interop-tested this with other implementations? Besides RNP? What were the results? > A v5 key has nothing to do a v4 signature and having different > algorithm on the primary key and the subkeys is really common and > allowed us once to slowly introduce RSA and ECC without any major > problems. This is why we will do the same for PQC encryption. Yes, but a subkey of a different *algorithm* is anticipated by the spec and should work (in principle). A subkey of a different *version* is a different matter. Or is it specified somewhere that I have overlooked? > All in all a really minor changes and not worth a long debate. It may be a minor change, but if it breaks interop it is still worth debating the consequences. > The crypto-refresh has a lot of things which breaks OpenPGP and that > draft, or soon to be RFC, does not care about backward compatibility. > They should not have used the term OpenPGP for this. You keep repeating these talking points, but they are simply not true. 1. crypto-refresh defines a *different* set of extensions to OpenPGP than GnuPG supports, but these do not “break” OpenPGP. 2. crypto-refresh has bumped all of its packet version numbers specifically to avoid compatibility issues. Just because the WG have a different opinion does not mean that they don’t care. 3. The term “OpenPGP” does not belong to GnuPG. And I notice that you have not addressed the most important point in my last email: > how should an implementation behave if it wants to support both the librepgp > and crypto-refresh specs? A signature.asc Description: Message signed with OpenPGP ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: x488 vs all other : keyid flip
On Fri, 29 Mar 2024 13:00, Andrew Gallagher said: > V5 subkeys of v4 primary keys would appear to introduce a novel > failure mode. It should be noted that in crypto-refresh, adding a Nope. A v5 key has nothing to do a v4 signature and having different algorithm on the primary key and the subkeys is really common and allowed us once to slowly introduce RSA and ECC without any major problems. This is why we will do the same for PQC encryption. To repeat: The *v5 key format* merely adds a four-octet count of the public key material to the v4 format. There are also minor chnages for the (not so import) secret key exchange format. And - more important - it defines that the fingerprint is now done using SHA-256. The latter is the whole point why we once decided to use add a v5 format - to make it clear tha a SHA-256 fingerprint is used. All in all a really minor changes and not worth a long debate. The crypto-refresh has a lot of things which breaks OpenPGP and that draft, or soon to be RFC, does not care about backward compatibility. They should not have used the term OpenPGP for this. Salam-Shalom, Werner -- The pioneers of a warless world are the youth that refuse military service. - A. Einstein openpgp-digital-signature.asc Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
