Replies: 12 comments
-
I think we should be somewhat careful with this. Imagine you have the following key: Sequoia Dump
And imagine that the User ID binding signature failed to parse, due to a bug or unsupported feature in OpenPGP.js, or due to an unknown notation, for example; so that we would skip the packet, and consider the User ID invalid. The key has a direct key signature, so implementing the proposal here in the most straightforward way would mean that we'd still use the key. However, the direct key signature doesn't specify any preferences, and was only added to set a Revocation Key, as required by RFC4880bis:
So in that case we would be using the key without its preferences, which is probably not intended. Of course, then you could say "ok, maybe we could require that the self-signature specifies preferences". But does any key out there actually do that? What's the benefit over requiring a User ID + User ID binding signature? |
Beta Was this translation helpful? Give feedback.
-
I'm thinking in a scenario where payload is asymmetrically encrypted, but the identity is managed (published or not) by the website providing the app' (and the key itself). The fact that the encrypted payload does not contains identifiable information (in particular the recipient) can be an advantage in a couple of contexts. |
Beta Was this translation helpful? Give feedback.
-
Hmhm, fair enough. I mean, the User ID packet could also say something like "Anonymous", but I agree that it's a bit of a hack.
Yeah, it's just that (at least how the code currently is) these things happen at different levels of abstraction; unparsable packets are skipped during parsing, whereas invalid keys (e.g. without a User ID) are rejected during encryption. So if you solve this the most straightforward way, you would end up with "store the fact that a packet failed to parse, and then later, if there's no UID, reject the key", or something like that, which also seems quite hacky. So I don't really know what a clean way to implement this would be. |
Beta Was this translation helpful? Give feedback.
-
This is a good point. In practice, I'm weary of the preferences. They are brittle. When there are multiple recipients, it is hard to choose the best option (what if Alice lists: A, B and Bob lists B, A?). They are rarely updated. And, they don't work well in the multi-device (multi-implementation) case. The RFC says about the Features subpacket:
I think it makes sense to do the same for algorithmic preferences. In Sequoia, we infer from 2020 that all OpenPGP implementations support SHA-256, SHA-512, AES-128 and AES-256, and use them unconditionally in our mid-level API. |
Beta Was this translation helpful? Give feedback.
-
Also, the RFC does not actually require that a User ID have a self-signature, this is a GnuPG convention:
|
Beta Was this translation helpful? Give feedback.
-
Some implementations such as Symantec PGP generated (still generate?) self-sig-less User IDs. IIRC there was a ticket for support of this kind of scenarios for OpenPGP.js
Isn't this just a way to put prefs? (So for each User-ID a different set of prefs can be used). I don't see any other way (except for direct key sigs that'd be less fine grained... for better or worse :) ). |
Beta Was this translation helpful? Give feedback.
-
The idea of putting the preferences on the User ID was that Alice might have two User IDs: "alice@work.com" and "alice@home.org". At work, she has a desktop and only checks her work email with MUA #1 and OpenPGP implementation #1. At home, she has a desktop and only checks her home email with MUA #2 and OpenPGP implementation #2. When I send Alice a mail, my MUA & OpenPGP implementation look at the identity to find the capabilities of her MUA / OpenPGP implementation. Today, this setup is atypical. First, if the two identities are really separate, it would be better to have different certificates. Second, it is more common to have a MUA configured to check all all emails accounts (home, work, clubs, etc.). Since the different devices have different capabilities (on my phone, I might use a trusted enclave that supports RSA, and on my desktop a Gnuk that uses ECC), I really want per-device keys and the preferences associated with the key. OpenPGP's preference system doesn't really support this scenario. As per the RFC, GnuPG falls back to the direct signatures, but it does not, as the RFC leaves open, look for preferences on the subkeys. |
Beta Was this translation helpful? Give feedback.
-
Yeah, this is fair enough. We also assume support of AES-128 and SHA-256 in OpenPGP.js, anticipating RFC4880bis. Still, it may make some sense to keep the preference system, for example in case some weaknesses in SHA2 are theorized, and we all want to switch to SHA3, without waiting for a new spec, and without waiting for all implementations to support it?
I agree that, if it were designed today, the preference system would be designed very differently. But now that it is as it is, and everyone (I think) puts their preferences in the User ID binding sig, I'm just wondering if it's worth it to push for this to change? OpenPGP.js currently doesn't look for them anywhere else, and I feel like adding that would just make the preference system even more complicated. |
Beta Was this translation helpful? Give feedback.
-
I think it would be faster for implementations to switch their default and for distributions like Debian to ship those changes than to wait for users to update their preferences :D.
GnuPG falls back to the direct signature, as described in 4880. As far as I know no implementation looks for preferences on subkey binding signatures. |
Beta Was this translation helpful? Give feedback.
-
You may be right. I guess we have a slightly different frame of reference, since e.g. in ProtonMail most of our keys are generated by our own client applications, so then I feel like we can update the preferences in our keys faster than waiting for Debian ^.^
Hmhm. Are you aware of any implementations that put preferences in the direct key signature? |
Beta Was this translation helpful? Give feedback.
-
In Sequoia we do. I haven't investigated what others do. |
Beta Was this translation helpful? Give feedback.
-
Worth mentioning: |
Beta Was this translation helpful? Give feedback.
-
Quoting @nwalfield in #1144
(@wiktor-k)
Beta Was this translation helpful? Give feedback.
All reactions