Met andere woorden: een backdoor.

Dus ze zijn eindelijk gezwicht. Toen die "feature" geintroduceerd werd was men nog mordiceus tegen.

Nou het klopt inderdaad wel dat end-to-end mail encryptie binnen bedrijven meestal onwerkbaar is (dit geldt net zo goed voor S/MIME!) omdat de keys gekoppeld zijn aan personen, en personen in bedrijven inwisselbaar zijn.

en


Als je je eigen sleutel beheer niet op orde hebt, dan is het een risico, en geen backdoor. Een backdoor is iets wat in het product "ingebakken" zit. Een ADSK moet je zelf instellen.

Een adk kan de eigenaar van de key instellen. En ik heb nog geen optie gezien in gpg om adk's te negeren dus voorlopig zie ik het als backdoor.

En ik kreeg op de GnuPG mailinglist de bevestiging van Werer Koch, de hoofdontwikkelaar van GnuG, dat zo'n optie ook niet bestaat en er vorlopig ook niet komt omdat hij er het nut niet van inziet:

> What I'm missing (maybe I just didn't found it?) is an option in my
> config file to ignore adk requests and just don't encrypt to those keys

It does not make any sense so have such an option. If a user wants to
allow colleagues or an archive system to decrypt her mails that is her
decision.

Dat wordt forken, al is die source code vreselijk ingewikkeld opgezet.

Je hoeft maar op een plaats de code te veranderen. En dat is de code die Public-Key Encrypted Session Key Packets genereert https://datatracker.ietf.org/doc/html/rfc4880#section-5.1. De ADSK kan dan per ongeluk een session key bevatten waar een hoop bits van zijn omgevallen.

Niet dat ik het ga doen, ik kan onmogelijk mijn systeem veilig houden tegen TLA. Zelf zal ik gewoon de meest officiële versie blijven gebruiken van Werner Koch.

Om eerlijk te zien : ik vind je hier een enorme eigenwijze zeurpiet .

De ontvanger van je bericht zegt expliciet (zichtbaar via de ADSK key) Ik WIL en GA dit bericht delen met deze andere personen - namelijk die andere keys.

En jij gaat dan die boel aan de ontvangstkant vernaggelen door dat toch maar niet te doen ?

Lekker dan : gaat iemand op vakantie (of langdurig ziek), alles geregeld, out of office, collega's in de adsk key, en gaat Ir Wevers weer eigenwijs doen .

In welk scenario weet jij beter dan degene op je antwoord (of van wie je een adsk key hebt) dat je toch 1:1 wilt encrypten ?

Stuur dan gewoon een bericht : "ik ga niet met die andere personen communiceren, ik wil een persoonlijke key van je" .

Ik schreef al dat ik johanw's wens niet handig vind.
Het lijkt me wel lelijk om het hele mechanisme te gebruiken en dan alleen in de definitieve sessie output een aantal stromen te verminken.

Mocht hij (of iemand) het toch willen lijkt dit een handvat voor de plaatsen in de code :

https://dev.gnupg.org/rGe4f61df8509e

Overigens :

Met de erg natte en amper gefunderde vinger *denk* ik dat een andere (en misschien handiger) manier om dit te bereiken is het (als) ontvanger van zo'n pubkey editen van de pubkey-met-additional-subkeys , en daarvan die additionele subkeys verwijderen .
Misschien dat het ook een ander type key is , maar het lijkt me mogelijk om van iemands pubkey key+subkeys een "nieuwe" solo-pubkey te maken . (of meerdere. voor de andere subkeys).
Waarschijnlijk verlies je daarin dan wel signatures, maar uiteindelijk - als je die eerst gecontroleerd hebt, en om de één of andere onmogelijke reden _wel_ de eigenaar van een key vertrouwd maar niet diens keuze om wat extra subkeys toe te voegen , dan zie ik geen principiële technische reden waarom je niet in je eigen verzameling van pubkeys van mensen met je wilt corresponderen zo'n adsk key (of een subkey ervan) tot "losse" pubkeys om te vormen.

De 'web-of-trust' validatie moet je dan maar offline gedaan hebben op de key+subkeys zoals die oorspronkelijk beschikbaar waren.

Voordeel lijkt me dat je niet hoeft te roeren in de gpg sources, maar evt alleen een pubkey extract/convert/import script (eenmalig) hoeft te maken. Of te vinden.

In de praktijk is die adk meestal verplicht toegevoegd door de werkgever, niet door de ontvanger zelf.

Terecht, voor zo'n bedrijfssituatie .
Zakelijk gezien heeft de 'eigenaar' (feitelijk gebruiker, beheerder, operator) van een zakelijke key ook weinig _zelf_ te willen .

Het alternatief is dat "de" zakelijke key gewoon met passphrase en al in een gedeelde share, (of keepass , hoop je) van het team of de ontvanger en z'n backup-collega's staat .

Net als alle privé-zaken : die doe beter in je in eigen tijd met eigen apparatuur , en je werk-gerelateerde zaken doe je op werk devices, met een werk-identiteit (cert@, support@, devs@ ), en deel je met aangewezen vervangers of opvolgers.

Als je de persoon echt privé - zodanig dat je ook gpg nuttig en nodig vindt - wilt benaderen is z'n werk-key (cq gesaboteerde adsk key) gewoon echt niet handig.

adsk is een mechanisme om (met name in zakelijke settings) zichtbaar te maken dat berichten aan "deze" key gedeeld worden met meerdere andere key-owners.

Het voorbeeld bij gpg dat een enkele gebruiker meerdere devices heeft - wellicht niet allemaal even high-security is misschien ook wel een use case , hoewel dat wel veel alertheid vraagt wanneer je primair de "meest secure" key gebruikt en wanneer het ook goed genoeg is voor een key die op een minder trusted device gebruikt wordt.