Re: WKD: conveying intent of encrypt-by-default?
On 2022-10-04 at 20:00 -0400, Daniel Kahn Gillmor wrote: > Autocrypt's focus is ubiquitous deployment of keying material (in the > form of OpenPGP certificates) so that people *can* encrypt when sending > mail. We found that one of the big risks is that a peer might > *automatically* encrypt when a cert is available, which becomes > burdensome for a user who does not have the ability to easily decrypt > messages. We don't want burdened users to stop distributing their cert > entirely because of this annoyance or frustration. This. > Getting clients to respect this setting if published in WKD (or that the > lack of it means "do not encrypt by default") is an entirely different > subject, of course. And i know you said "no Protonmail rants" so i > won't call them out specifically here, but MUA developers generally > really do need to take the ecosystem effects of their choices seriously. > Any MUA that promiscuously encrypts *by default* to someone who has not > clearly indicated that they are comfortable with every inbound message > being encrypted is inviting that user to see encrypted e-mail as a > hindrance and an annoyance. That's not a great way to spread the > capability of people actually being able to use encrypted mail when it > matters, or to help people through a process of gradual adoption. Exactly this. We need encryption _available_, but culturally "encrypt-by-default" is not going to fly. Almost all email usage locally is Gmail, with the browser app or the official Gmail mobile apps. That is not going to change. We have to have a sensible means of key discovery for exchanging encrypted mail _when the situation warrants it_, such as distributing sensitive data or receiving security reports. This is not about signing. This is about using encrypted content being a PITA for most people. The clients encrypting all mail by default are killing the use of OpenPGP and MIME-integrated PGP-encrypted email locally. It's another hammer in the coffin-lid of PGP's reputation as a reasonable technical solution for the problem spaces we care about. It is not hyperbole to say that this one issue has done more to drive the use of "age" encryption (with copy/paste into and out of emails as intact ASCII-armored blobs) than anything else. And age armored ciphertext pasted into Slack. It might seem clunky, but it works reliably and it aligns with cultural expectation of "only use this for things which really need the protection, otherwise just rely upon TLS and professional service operators". TLS for SMTP is not end-to-end, but it turns out to be "good enough" for most daily usage, particularly within a domain or with a few business partners. -Phil ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Subkeys renewing/expiring strategy
On Donnerstag, 13. Oktober 2022 11:39:41 CEST nect via Gnupg-users wrote: > > Since I use this key exclusively for commit signing, I can > > simply replace it with a completely different key if I change my mind. > > About this, how do you deal-or plan of dealing- with past commits signed > with a now expired key? > I created on year ago a test repo with only one commit, signed with my now > expired subkey. > Checking that commit's signature now shows an alert saying that the key is > expired (in red). > While this is correct, I guess that some users or services may see expired > signatures as invalid, even though they are valid and I just superseded > them with newer subkeys. > I can think of two choices: either resign all your past commits every time > your subkey expires, I don't think that's an option (at least not for a repo shared with others) because it would rewrite the history of the git repo. > or ignore the fact that old commits were signed with > expired subkeys. > So, I was wondering if extending the expiry is the better way to deal with > this, since you avoid showing any alert for old commits. The best option is probably to follow Teemu's advice and use a signing subkey with unlimited validity. Regards, Ingo signature.asc Description: This is a digitally signed message part. ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Subkeys renewing/expiring strategy
* 2022-10-11 17:23:49+0200, nect via Gnupg-users wrote: > Since I was struggling to choose a strategy for expiring/renewing my > subkeys [...] We should ask why do you want to expire (and rotate) your subkeys? Maybe you have good reasons but I'll remind of the basic question: why not use the default simple strategy? Keep secret keys secret so there is no need to rotate (sub)keys. Subkeys don't need expiry date at all. The primary key should (!) have expiry date which is updated as needed. That's it. No? -- /// Teemu Likonen - .-.. https://www.iki.fi/tlikonen/ // OpenPGP: 6965F03973F0D4CA22B9410F0F2CAE0E07608462 signature.asc Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Subkeys renewing/expiring strategy
Hello Ingo, Thank you for your reply. >You will still have to upload the updated key to every website you use. So, > you don't gain much if anything with this approach. You are totally right, I didn't think of that. In any case, this begs the question: is it better (best practice if you want) to have many expired subkeys in your keyring or constantly bumping the expiry date of one of your subkeys (without creating new ones every time)? > Encryption and authentication subkeys are useless for a commit > signing key, but you may of course use your key also for other purposes I made those just to be sure in case I will need them. Is it better to have authoring and encrypting subkeys with an unlimited expiry? Or is it better to not create them at all until you need them? >"Trust" is usually bound to the primary key. Expired subkeys shouldn't matter. Thank you for clarifying that. > Since I use this key exclusively for commit signing, I can > simply replace it with a completely different key if I change my mind. About this, how do you deal-or plan of dealing- with past commits signed with a now expired key? I created on year ago a test repo with only one commit, signed with my now expired subkey. Checking that commit's signature now shows an alert saying that the key is expired (in red). While this is correct, I guess that some users or services may see expired signatures as invalid, even though they are valid and I just superseded them with newer subkeys. I can think of two choices: either resign all your past commits every time your subkey expires, or ignore the fact that old commits were signed with expired subkeys. So, I was wondering if extending the expiry is the better way to deal with this, since you avoid showing any alert for old commits. Regards On Tue, Oct 11, 2022, 7:44 PM Ingo Klöcker wrote: > On Dienstag, 11. Oktober 2022 17:23:49 CEST nect via Gnupg-users wrote: > > I started using gpg relatively recently (1 year or so), mainly for > > signing git commits, and I am far from mastering it. > > > > Since I was struggling to choose a strategy for expiring/renewing my > > subkeys (more details below) I decided to seek expert advice (hopefully > > this is the right place). > > I'm far from being an expert. > > > At the moment, I have my primary key (with no expiry) stored on a > > offline drive. > > I created the key 1 year ago, alongside a set of subkeys whose expiry > > was due in 1 year. > > Since they recently expired, I created another triplet of subkeys (sign, > > author, encrypt) and started using them instead of the old ones. > > For signing git commits I recently created an OpenPGP key with a > certify-only > primary key (with long validity period) and a signing subkey (which > expires > next year). Encryption and authentication subkeys are useless for a commit > signing key, but you may of course use your key also for other purposes. > > This commit signing key is certified with my main key. > > > Now, when I was doing this I realized that this strategy is not > > particularly good, especially in the long run, > > since you have to recreate every year (or 2) the new subkeys and let the > > old ones expire (losing some trust?). > > "Trust" is usually bound to the primary key. Expired subkeys shouldn't > matter. > > > Also, uploading the new keys to every website that you use (eg GitLab) > > is quite the annoying chore. > > > > So, I was wondering what's the best strategy I can use to keep my > > (sub)keys valid without compromising on security. > > Is bumping the expiry date every year or so a better solution? > > You will still have to upload the updated key to every website you use. > So, > you don't gain much if anything with this approach. > > > Also, are subkeys with unlimited expiry bad, or am I just being carried > > away? > > The advantage of an expiring key is that you can simply let it expire to > make > it invalid (for signatures created after the expiration date). On the > other > hand, if you don't lose access to the primary key, then you can still > change > the expiry of a subkey with unlimited validity if you decide to expire it. > The > downside of setting the expiration date in retrospect is that you need to > send > the updated key everywhere. And people may still use the outdated version > without expiry. > > I'm going to experiment with 1-year-validity of the signing subkeys of my > commit signing key. Since I use this key exclusively for commit signing, I > can > simply replace it with a completely different key if I change my mind. > > Regards, > Ingo > ___ > 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
