- Eleg-projekt

Välkomna på öppet möte nr 25 om att bygga egen e-leg-lösning, 9 dec klockan 18
by Elias Rudberg 09 Dec '24

09 Dec '24

Hej! Välkomna till distans-möte nummer 25 om hur vi kan bygga en egen decentraliserad lösning för fri och öppen e-legitimation. Vi fortsätter med kravspecifikation, design, implementation och testning av de olika komponenter som kommer behövas. Tid: måndag 9 december 2024 klockan 18:00. Vi siktar på att hålla på i upp till en timme. Plats: https://jitsi.eliasrudberg.se/e-id-meeting Förslag till agenda: - Implementation av en första version av CA-programvara för utgivaren - Fortsättning av test med nginx - OpenPGP-kort, hårdvarunycklar osv. Nitrokey? TPM2-chip i laptop? - Beskrivningar av arbetsflöden för utfärdande, användning, återkallande osv. - Möte med DIGG? Alla är välkomna, både ni som varit med tidigare och alla nya som vill vara med och diskutera och hjälpa till med det här. Svara gärna här på mejllistan med alla frågor och funderingar inför mötet. Välkomna! Vänliga hälsningar Projektets styrgrupp genom Elias

1 0

websida som ger ut e-ID på fil
by Christian Häggström 27 Nov '24

27 Nov '24

Hej kära vänner! Jag har blåst liv i en gammal kod som vi körde på jobbet för att skapa klientcertifikat i webbläsaren, se https://codeberg.org/DFRI-eID/dfri-eid/pulls/5 Funktionen <genkey> är dock borttagen i nyare Firefox så skulle behöva någon skarp Javascript-kodare som ersätter klientsidan med javascript. Det innebär att skapa ett nyckelpar, och skicka publika delen till serversidan, läsa tillbaka certifikatet. På något vis få certifikatet in i webläsaren, alternativt spara ner en .p12 fil som man sedan kan importera manuellt. Debian-utvecklare använde också <genkey> när det begav sig, men har nu gått över till kommandoraden, see https://wiki.debian.org/DebianSingleSignOn#line-49 Hälsningar / Christian Häggström

1 0

Sammanfattning av öppet möte nr 24 om att bygga egen e-leg-lösning, 11 nov 2024
by Elias Rudberg 14 Nov '24

14 Nov '24

Sammanfattning av öppet möte nr 24 om att bygga egen e-leg-lösning, 11 nov 2024: Tack till alla som var med på mötet! - Implementation av en första version av CA-programvara för utgivaren Kod finns [0]. Bra om vi kan få till det med hårdvarunyckel. Inget nytt på denna punkt. Flera har testat och verifierat att det fungerar, det är bra. - Fortsättning av test med nginx En sak att lägga till här är systematisk hantering av revokeringslista, t.ex. med ett cron-jobb som regelbundet hämtar senaste revokeringslista. Behöver även hantera fallet att man inte lyckas hämta. Filer för test med nginx, gunicorn and flask finns i git-repot [1]. Bra om fler är med och testar detta, om någon vill ha nya subdomäner för test kan vi hjälpas åt med det, säg till så löser vi det. - OpenPGP-kort, hårdvarunycklar osv. Nitrokey? TPM2-chip i laptop? Test med Nitrokey har gjorts och fungerar, git-repot har uppdaterats med info om det [2]. Flera ska testa den biten också. OpenPGP-kort återstår, hoppas vi kan få till det också snart. Test med TPM2-chip i laptop är på gång också. En fråga som kom upp är att för vissa saker som testats med openssl-kommandot hade det varit bra att ta med också hur man kan göra motsvarande med curl, t.ex. hur man anger en "engine" beroende på hur man hanterar den privata nyckeln kan se olika ut beroende på om man använder openssl eller curl. - git-repo Det gamla git-repot är arkiverat nu. Det nya git-repot som är det som gäller nu är https://codeberg.org/DFRI-eID/dfri-eid - Beskrivningar av arbetsflöden för utfärdande, användning, återkallande osv. Det jobbas vidare med detta, bl.a. längre text-beskrivningar och andra typer av diagram. - Möte med DIGG? Inget nytt här ännu, vi ska försöka få till ett möte med DIGG om processen kring den statliga e-legitimationen (även efter att uppdraget gått över till Polismyndigheten). - Övrigt Problemet med utloggning kan eventuellt lösas genom att använda en slumpmässig sträng som subdomän som man använder klientcertifikatet mot. När man loggar ut kastas subdomänen bort. - När blir nästa möte? Nästa möte blir måndagen 2024-12-09 klockan 18 till 19 (en timme) Alla är välkomna att vara med på kommande möten. OBS även du som inte varit med förut är mycket välkommen att vara med! / Elias [0] https://codeberg.org/DFRI-eID/dfri-eid/src/branch/main/go-eid-test-ca [1] https://codeberg.org/DFRI-eID/dfri-eid/src/branch/main/nginx-test [2] https://codeberg.org/DFRI-eID/dfri-eid/src/branch/main/go-eid-test-ca/USING… PS Läs gärna om projektet här: https://www.dfri.se/projekt/e-legitimation/ PS 2 Alla som är intresserade är välkomna att höra av sig via projektets mejllista

1 0

Välkomna på öppet möte nr 24 om att bygga egen e-leg-lösning, 11 nov klockan 18
by Elias Rudberg 10 Nov '24

10 Nov '24

Hej! Välkomna till distans-möte nummer 24 om hur vi kan bygga en egen decentraliserad lösning för fri och öppen e-legitimation. Vi fortsätter med kravspecifikation, design, implementation och testning av de olika komponenter som kommer behövas. Tid: måndag 11 november 2024 klockan 18:00. Vi siktar på att hålla på i upp till en timme. Plats: https://jitsi.eliasrudberg.se/e-id-meeting Förslag till agenda: - Implementation av en första version av CA-programvara för utgivaren - Fortsättning av test med nginx - OpenPGP-kort, hårdvarunycklar osv. Nitrokey? TPM2-chip i laptop? - git-repo - Beskrivningar av arbetsflöden för utfärdande, användning, återkallande osv. - Möte med DIGG? Alla är välkomna, både ni som varit med tidigare och alla nya som vill vara med och diskutera och hjälpa till med det här. Svara gärna här på mejllistan med alla frågor och funderingar inför mötet. Välkomna! Vänliga hälsningar Projektets styrgrupp genom Elias

1 0

Sammanfattning av öppet möte nr 23 om att bygga egen e-leg-lösning, 21 okt 2024
by Elias Rudberg 03 Nov '24

03 Nov '24

Sammanfattning av öppet möte nr 23 om att bygga egen e-leg-lösning, 21 okt 2024: Tack till alla som var med på mötet! - Implementation av en första version av CA-programvara för utgivaren Bra om vi kan få till det med hårdvarunyckel. Inget nytt på denna punkt. - Fortsättning av test med nginx Alla uppmuntras att testa, observera att det går bra att testa alla de olika delarna, man kan testa att agera utgivare, att agera förlitande part, och som privatperson som använder e-leg. - OpenPGP-kort, hårdvarunycklar osv. Använda TPM2-chip i laptop? Att använda TPM2-chip i en laptop är en möjlighet som också kan vara intressant att testa. Det bör fungera som en hårdvarunyckel som finns inbyggd i datorn, om den fungerar rätt ska det betyda att det inte går att kopiera ut den privata nyckeln så man vet att den inte kan komma på avvägar. Testa gärna med andra typer av kort. - Förvirring kring olika git-repon? Det git-repo som ska användas nu är https://codeberg.org/DFRI-eID/dfri-eid och vi kom fram till att det gamla repot som hette "go-eid-test-ca" ska frysas så att man inte råkar göra ändringar på fel ställe. Ändringar som råkat hamna fel ska flyttas över till det rätta repot. Tanken är att allt som fanns i repot "go-eid-test-ca" ska nu istället finnas i en katalog med det namnet inne i det nya repot, så att allt finns samlat i samma repo. - Beskrivningar av arbetsflöden för utfärdande, användning, återkallande osv. Inget nytt här sedan sist på grund av att vissa personer varit upptagna av annat, men kommer fortsätta arbetet till nästa gång. - Diskussion om hur saker ska fungera i praktiken När man använder det här idt, har vi pratat om att använda ett mTLS-certifikat i browsern. Frågor kring det: Går det vara selektiv med certifikatet i webbläsaren? Hur blir det med inloggningssessionen, hur länge varar den? Vi diskuterade kring de sakerna och konstaterade att även om användargränssnittet inte blir perfekt, delvis beroende på vad webbläsare stöder för tillfället, så är det ändå stor fördel för oss att använda mTLS till att börja med eftersom vi då kan använda saker som redan finns. - Möte med DIGG? Mötet vi hade inplanerat med DIGG blev uppskjutet, det är nu oklart om det blir av, vi kanske ska fortsätta försöka ändå. En av frågorna som skulle vara intressant att ställa till DIGG på ett sånt möte är: även om DIGG inte implementerar, är det väl fortfarande DIGG som ska se till att regler följs och så? Kommer polisens implementation att få särbehandling eller kommer den att behöva godkännas som vilken e-leg som helst? Med andra ord, har DIGG fortfarande ansvar, i godkännande-fasen? - När blir nästa möte? Nästa möte blir måndagen 2024-11-11 klockan 18 till 19 (en timme) Alla är välkomna att vara med på kommande möten. OBS även du som inte varit med förut är mycket välkommen att vara med! / Elias PS Läs gärna om projektet här: https://www.dfri.se/projekt/e-legitimation/ PS 2 Alla som är intresserade är välkomna att höra av sig via projektets mejllista

1 0

Välkomna på öppet möte nr 23 om att bygga egen e-leg-lösning, 21 okt klockan 18
by Elias Rudberg 19 Oct '24

19 Oct '24

Hej! Välkomna till distans-möte nummer 23 om hur vi kan bygga en egen decentraliserad lösning för fri och öppen e-legitimation. Vi fortsätter med kravspecifikation, design, implementation och testning av de olika komponenter som kommer behövas. Tid: måndag 21 oktober 2024 klockan 18:00. Vi siktar på att hålla på i upp till en timme. Plats: https://jitsi.eliasrudberg.se/e-id-meeting Förslag till agenda: - Implementation av en första version av CA-programvara för utgivaren - Fortsättning av test med nginx - OpenPGP-kort, hårdvarunycklar osv. Använda TPM2-chip i laptop? - Förvirring kring olika git-repon? - Beskrivningar av arbetsflöden för utfärdande, användning, återkallande osv. Alla är välkomna, både ni som varit med tidigare och alla nya som vill vara med och diskutera och hjälpa till med det här. Svara gärna här på mejllistan med alla frågor och funderingar inför mötet. Välkomna! Vänliga hälsningar Projektets styrgrupp genom Elias

1 0

Resultat av TPM2-experimentet
by Christian Häggström 19 Oct '24

19 Oct '24

Hej, till att börja med vill jag tacka Andrew Dalke för att du delade med dig av ditt inspirerande meddelande till kommunen på seniorträffen! Jag sa under förra mötet att jag skulle kolla på att använda TPM2-chippet i datorn som hårdvarunyckel. Jag började med att skriva några kommandon [2] man kan använda för att testa Elias go-implementation med openssl CLI istället för nginx/letsencrypt. Sedan modifierade jag de kommandona för att prata med TPM2-chippet istället [2]. Fick inte det att fungera helt med min dator så vore bra om någon annan vill provköra som kör Linux på en modern laptop. Har tyvärr förhinder på nästa möte 21/10. Trevlig decentraliserad söndagkväll! önskar Christian [1] https://codeberg.org/DFRI-eID/go-eid-test-ca/pulls/2 [2] https://codeberg.org/DFRI-eID/go-eid-test-ca/pulls/3

2 1

BankID, seniorer, och jag
by Andrew Dalke 19 Oct '24

19 Oct '24

Hej allihopa, Jag delar lite om min aktivism. Jag skulle hellre kunna leva utan smartmobil och utan företag som portalväktare till mitt privatliv. För mig är en FOSS alternativ till BankID, som funkar på en vanlig dator med GNU/Linux, *BSD, Haiku, osv, kanske med kortläsare, funkar helt okej. Jag var på en Seniormässa igår. Arrangören var stadens "Omsorgsförvaltningens verksamhet för digitalisering och välfärd". Den startades för ungefär 8 månader sen för att stödja seniorer som har problem med den nya tekniska världen. Till example, de kan göra ett hembesök för att fixa lätta problem, och hitta ett sätt att kunna betala med faktura istället för Swish. Jag gick ditt inte för att jag är senior, utan för att kunna prata med någon från staden om antagandet att bara seniorer har problem med landets sätt att digitalisera. Jag skrev texten nedan, som jag delade med den tvåa som var där. Chefen lovade att den kommer att diskuteras med stadens IT-avdelningens chef. Jag hade chans att prata med killen som gör hembesöken. Han tycker väldigt mycket om FOSS, men det största problemet för de flesta seniorer är kunna använda BankID. En kvinna berättade att hon hade en gammal dator hemma, men den funkar inte med den nyaste Windows, så behövde hon köpa ny. Självklart bidrar BankID till e-skrott, och försämrar livet för våra äldre. Med vänliga hälsningar, Andrew Dalke dalke(a)dalkescientific.com När ni pratar om ett digitalt samhälle, finns det plats for oss som har viss digital media och enheter men inte alls skulle vilja ha Google, Apple, Microsoft, Facebook, PayPal, och så vidare i sitt privatliv? Jag är 55 år gammal, och lite yngre än dem flesta här. Jag representerar den första generationen som hade TV-spel och datorer hemma i sin barndom. Jag lärde mig att programmera när jag var 12 år gammal. Jag utbildade mig inom dator vetenskap. Jag var på webben redan 1994. Jag bodde i Silicon Valley under DotCom tiden. Jag är en av de programmerarna som har skrivit en del av mjukvaran som användas dagligen av de flesta som är online. Jag har varit online nästan dagligen i decennier, och nu jag är trött, och deprimerad, och frustrerad, att framtiden att jag hjälpte utveckla, är nu koloniserad av stora företag. Dessa företag skapar en reklamprofil, samlar person uppgifter, förstör samhället och miljön. De stödjer fascister, kämpar emot fackföreningar, sprider ljuger, och suger pengar ur vårt ekonomi. De vill ha kontroll över internet, våra enheter och vårt liv. Jag är frustrerad på staden och regionen som har skapat digitala lösningar och förväntar sig att alla har en smartmobil. Samt att alla har undertecknat ett avtal med dessa amerikanska företag. Jag är arg att vår regering verkar vilja ha en spion på varje mobil, som smyglyssnar på vårt privat liv för att informera myndigheterna - för att rädda barnen, förstås. Efter 25 år online började jag att bli utbränd på grund av notiser, reklam och memes. Nu efter 35 år vill jag hellre avstå från ett digitalt liv. Rädslan för att gå miste om något, och behovet att ha koll på allt hela tiden vilket dessa förtag utnyttjar har bidragit till min dåliga mentala hälsa. Min lösning har varit att leva utan smartmobil. Jag läser mina nyheter i (pappers)tidningarna. Jag använder konto laddning på bussen. Jag använder kontanter eller kort för att handla. Jag avstår alla tjänsterna som kräver att jag ge upp min sekretess för att mata övervaknings kapitalismen. Jag har bestämt mig att den ända moraliska lösningen är att byta till ett så-kallad Open Source system, typ Linux, för att hålla vinstdrivande företag på armlängds avstånd. Jag har redan upptäckt att kommunen inte är förberedda för människor som mig. BankID krävs för att kunna logga in till webbportalarna till mina barns skolor, och BankID kräver ju att man måste ha undertecknat avtal med Microsoft, Apple, eller Google. Jag har provat i drygt en månad för att hitta ett bra alternativt för att kunna logga in till ItsLearning, utan lösning. BankID krävs för att logga in digitalt på Maria Alberts, därför måste jag ringa dem istället. BankID krävs för att använda Swish, därför använder jag helst kontant eller kort. Det blir mer och mer krångligt, men om digitalisering innebär att jag måste minska min sekretess, är problemet mig, eller digitaliserings processen ni har valt? Kommer kommunen vara redo för min generation, blivande seniorer som är medvetna om problemen med vårt beroende av utländska företag, och som har kunskap om datorer för att kunde skapa eller hitta en annan digital lösning själva? Regeringen skulle inte att tvinga oss att använda dessa opålitliga företag och ha tillit på den amerikanska regeringen bakom dem. Kommunen förväntar redan ibland att alla har en smartmobil med sig hela tiden, till exempel, på notiser med QR-kod länk och ingen annan möjlighet att läsa mer. Kanske vet du en människa som tar en "digital detox" efter ha blivit en scrollande mobilzombie för länge. Vad har ni för tankar om en framtid där ännu mer människor blir lika mental utbrända som jag, som skulle vilja gå på promenad utan att känner sig isolerade på grund av allmänna skyltar som bara är läsbara med smartmobil? Är det en framtid där man måste ha Facebook, Instagram, eller X konto för att kunna lära sig mer om kommunens aktiviteter detta ska väl vara tillgängligt för alla? Finns plats i Trollhättans digitala framtid för människor som mig?

2 2

Sammanfattning av öppet möte nr 22 om att bygga egen e-leg-lösning, 30 sept 2024
by Elias Rudberg 01 Oct '24

01 Oct '24

Sammanfattning av öppet möte nr 22 om att bygga egen e-leg-lösning, 30 sept 2024: Tack till alla som var med på mötet! - Rapport från vårt möte med DIGG om statlig e-legitimation (tyvärr uppskjutet) Vi skulle haft ett möte med Myndigheten för digital förvaltning (DIGG) men det blev tyvärr uppskjutet p.g.a. att någon blivit sjuk. Förhoppningsvis kommer det mötet fortfarande att kunna bli av, men försenat, vi vet inte just nu om och när det kan bli. Situationen kring den kommande statliga e-legitimationen är något oklar nu efter att regeringen nyligen beslutat att ge uppdraget till Polismyndigheten istället för DIGG [0]. Alltså uppdraget att verkligen skapa den tekniska lösningen som ska användas. Vi vet inte nu, men vill gärna veta, om det är så att det som sagts tidigare (att det ska vara öppen standard och att möjliggöra id-växling till exempel) fortfarande gäller, eller om allt blir annorlunda nu. Flera på mötet uttryckte oro över att när polisen ska skapa lösningen är det risk för mer fokus på övervakning och mindre respekt för människors rättigheter. Om och när ett möte med DIGG blir av ska vi försöka få svar på det. Tack till er som mejlat förslag om saker att ta upp på mötet med DIGG, vi tar med oss era förslag till mötet med DIGG om/när det blir av. - Implementation av en första version av CA-programvara för utgivaren Samma status som tidigare: en sak vi gärna vill lägga till är att låta utfärdaren (CA) använda hårdvarunyckel, ingen har hunnit lösa den biten ännu. (Koden för CA-programvaran och även nginx-testet nedan finns på https://codeberg.org/DFRI-eID/dfri-eid för den som vill titta och/eller testa själv men OBS att det bara är utkast/arbetsmaterial i det här läget, inget som är färdigt att visa upp. Rapportera gärna om ni hittar fel eller problem där.) - Fortsättning av test med nginx, lägga till revokeringslista - privacy kring revokeringslistan? Vi har ju ett test med nginx [1] där vi även testat att använda revokeringslista (CRL) [2] vilket fungerar, en fråga kring det är om det från revokeringslistan går att läsa ut vilka personers certifikat som har återkallats. Det verkar som om standardformatet av CRL-fil som vi använt bara innehåller serienummer för certifikat och tidpunkt för återkallande, det går alltså inte att se vilka personer det gäller, vilket är bra för privacy. Vi diskuterade lite kring att en fördel med CRL-metoden är att det inte ställs någon fråga till något centralt system för varje gång man använder sin e-legitimation så det finns inget centralt system som kan spåra en på det sättet. En alternativ lösning är ju att inte ha en CRL utan att det istället ställs en fråga varje gång, som i OCSP [3]. Om det ställs en fråga varje gång finns möjlighet för en central aktör att veta varje gång man använder sin e-legitimation, vilket är dåligt för privacy. CRL-metoden har också en fördel när det gäller robusthet i samhället vid krissituationer, eftersom det bara behövs en envägs-kommunikation där utfärdaren (CA) på valfritt sätt skickar ut (broadcast) informaitonen om nuvarande CRL till alla. Det skulle i princip kunna göras med t.ex. radio-broadcast som kan fungera mycket mer robust, alltså det kräver inte att var och en har internet-uppkoppling utan det räcker att kunna ta emot radiosändningen, sen kan certifikat användas lokalt även om internet inte fungerar för tillfället, eller om internet fungerar dåligt. - OpenPGP-kort, hårdvarunycklar osv. Som tidigare vill vi gärna kunna göra något motsvarande [4, 5] även för andra typer av hårdvarunyckel än Yubikey, andra möjliga varianter är OpenPGP-kort eller t.ex. Tillitis TKey eller Nitrokey, en möjlighet är också att använda TPM2-chippet i en laptop. Alla som kan är mycket välkomna att hjälpa till här, hör av er och berätta hur man gör motsvarande [5] för olika typer av hårdvarunycklar! En fråga kring detta är om utfärdaren kan veta att man använt en hårdvarunyckel. Vill vi det? För användarens frihet är det bäst att ha full frihet i att välja hur den privata nyckeln hanteras, då kan utfärdaren inte veta hur man gjort. Om utfärdaren ska kunna veta det kan "attestering" användas, det kan bli aktuellt senare men tyvärr troligen till priset av mindre frihet, en viss makt hamnar då hos den eller de aktörer som skapar "godkända" hårdvarunycklar, och det kan bli problem kring vem som bestämmer vilka lösningar som ska anses godkända. - Beskrivningar av arbetsflöden för utfärdande, användning, återkallande osv. Det går framåt! Bland annat har bilder lagts till, pågår arbete med att snygga till dem. Arbetet fortsätter. - När blir nästa möte? Nästa möte blir måndagen 2024-10-21 klockan 18 till 19 (en timme) Alla är välkomna att vara med på kommande möten. OBS även du som inte varit med förut är mycket välkommen att vara med! / Elias [0] https://www.digg.se/digitala-tjanster/e-legitimering/statlig-e-legitimation [1] https://mailman.dfri.se/mailman3/hyperkitty/list/eleg-projekt@lists.dfri.se… [2] https://en.wikipedia.org/wiki/Certificate_revocation_list [3] https://en.wikipedia.org/wiki/Online_Certificate_Status_Protocol [4] https://johanfagerstroem.github.io/2021/https-client-certificates-with-yubi… [5] https://mailman.dfri.se/mailman3/hyperkitty/list/eleg-projekt@lists.dfri.se… PS Läs gärna om projektet här: https://www.dfri.se/projekt/e-legitimation/ PS 2 Alla som är intresserade är välkomna att höra av sig via projektets mejllista

1 0

Anggående möte med DIGG i eftermiddag
by Tim Sandgren 30 Sep '24

30 Sep '24

Hej alla, Nu kanske detta kommer iväg lite sent, men jag tänkte ändå skriva ett par frågor som kunde vara bra att ställa till DIGG så småningom: För det första så skulle det vara bra att veta om e-legitimationen kan förverkligas i samverkan mellan flera organisationer. Så som jag läste texten nu i länken jag fick från Elias: https://www.digg.se/digitala-tjanster/e-legitimering/tillitsnivaer-for-e-le… så är det skrivet som att en organisation ensam ska ge ut. Det behöver också vara en stort företag som har gott om pengar så som jag tolker texten. Så frågan är om det kunde gå att istället ge ut legitimationen i ett öppet samverkansprojekt där flera intressenter tillsammans kan se till att uppfylla kraven i ISO 27001. Polismyndigheten kunde i sådana fall bli en viktig intressent, liksom även föreningen DFRI. Det var mitt förslag på fråga! / Tim

1 0

Möte med DIGG planerat till imorgon eftermiddag, föreslå gärna frågor att ställa
by Elias Rudberg 30 Sep '24

30 Sep '24

Hej! Det har blivit så att samtidigt som DIGG säger att de inte längre är ansvariga för att bygga den kommande statliga e-legitimationen så har vi ändå fått inbokat ett möte med dem. Inte säkert att det blir av men förhoppningsvis ska det bli imorgon eftermiddag, alltså 30 september, eftermiddagen samma dag när vi sen har vårt projektmöte på kvällen. Planen är att Cynthia och jag ska vara med på mötet med DIGG och vi ska försöka få klarhet i vad den nya situationen innebär, om det är så att alla planer från de tidigare utredningarna nu kastats i sopkorgen eller om det här att polisen ska ta över bara är en ändring av vem som gör jobbet och inte själva den tekniska lösningen i sig. Det viktigaste tänker jag är att lösningen måste vara baserad på öppen standard så att den inte är låst till vissa operativsystem och så att fri programvara kan användas, så det tänker jag ta upp och fråga om. Risken är att DIGG svarar att de inte vet och att det nu är helt upp till Polismyndigheten att bestämma hur det blir nu. Vi får se. Svara gärna med era tankar och förslag om vad vi borde ta upp på mötet med DIGG. / Elias

3 2

Välkomna på öppet möte nr 22 om att bygga egen e-leg-lösning, 30 sept klockan 18
by Elias Rudberg 29 Sep '24

29 Sep '24

Hej! Välkomna till distans-möte nummer 22 om hur vi kan bygga en egen decentraliserad lösning för fri och öppen e-legitimation. Vi fortsätter med kravspecifikation, design och implementation av de olika komponenter som kommer behövas. Tid: måndag 30 september 2024 klockan 18:00. Vi siktar på att hålla på i upp till en timme. Plats: https://jitsi.eliasrudberg.se/e-id-meeting Förslag till agenda: - Implementation av en första version av CA-programvara för utgivaren - Fortsättning av test med nginx, lägga till revokeringslista - OpenPGP-kort, hårdvarunycklar osv. - Beskrivningar av arbetsflöden för utfärdande, användning, återkallande osv. - Rapport från vårt möte med DIGG om statlig e-legitimation Alla är välkomna, både ni som varit med tidigare och alla nya som vill vara med och diskutera och hjälpa till med det här. Svara gärna här på mejllistan om du har frågor eller funderingar inför mötet. Välkomna! Vänliga hälsningar Projektets styrgrupp genom Elias

3 2

DIGG avbryter sin utveckling av statlig e-legitmation. Polismyndigheten ska göra det istället
by Elias Rudberg 25 Sep '24

25 Sep '24

Hej alla på eleg-projekt-listan! Nya bud om den kommande statliga e-legitmation, det vi trodde oss veta om den processen verkar inte gälla längre. Det är inte längre Myndigheten för digital förvaltning (DIGG) som ska ta fram den statliga e-legitmation, enligt vad DIGG skriver här: https://www.digg.se/digitala-tjanster/e-legitimering/statlig-e-legitimation Där står bland annat följande: "Digg fick i uppdrag att under 2024 utveckla en statlig e-legitimation enligt utredningen en säker och tillgänglig statlig e-legitimation. I budgetpropositionen för 2025 föreslår regeringen att överföra utvecklingsuppdraget till Polismyndigheten istället. Detta för att undvika det delade ansvar mellan Digg och Polismyndigheten som utredningens förslag innebar." "Digg avbryter utvecklingsarbetet som riktar sig mot den statliga e-legitmationen." Det här verkar vara ny information som kommit senaste dagarna, budgetpropositionen kom i torsdags, den 19 september: https://regeringen.se/rattsliga-dokument/proposition/2024/09/prop.-2024251 Vet någon av er mer om det här, om varför regeringen plötsligt gör såhär och vad det kan komma att innebära? / Elias

4 5

Sammanfattning av öppet möte nr 21 om att bygga egen e-leg-lösning, 9 sept 2024
by Elias Rudberg 10 Sep '24

10 Sep '24

Sammanfattning av öppet möte nr 21 om att bygga egen e-leg-lösning, 9 september 2024: Tack till alla som var med på mötet! - Kontakt med DIGG om statlig e-legitimation? Det finns möjlighet att lämna synpunkter på "SOU 2024:45 Kompletterande bestämmelser till EU:s reviderade förordning om elektronisk identifiering" senast den 1 november 2024 [1]. Se även vad Mattias skrev om det förra veckan [2]. DIGG säger att de gjort en övergång från förberedelse till implementationsfas, men samtidigt finns inget beslut ännu, så vi behöver försöka få in våra synpunkter till DIGG före 1a nov. Vi siktar på att försöka få till ett möte med DIGG, antingen digitalt eller fysiskt. Om de inte kan eller vill träffa oss, bör vi ändå skicka in något skriftligt. - Använda tokens för att hantera inlogg/utloggning? Vår prototyp som finns idag (https://codeberg.org/DFRI-eID/dfri-eid) som ju använder mTLS fungerar ju för att skydda en anslutning, men det är kanske inte så bra användargränssnitt och inte så bra hantering av när en anslutning öppnas och stängs, hur man loggar ut. T.ex. kan det vara ett problem om samma dator används av flera personer, vi behöver då säga att man ska stänga webbläsaren för att vara säkert utloggad vilket inte är så elegant. Fördelen med mTLS är att då är klient-sidan "redan klar", inget arbete behövs där. Vi diskuterade lite kring detta och kom fram till att för att ha enklast möjliga första version, en "minimum viable product" (MVP) som är så enkel som möjligt, siktar vi fortfarande på mTLS, men att det samtidigt är intressant att titta på hur lösningen kan förbättras senare. Vi kan komma till ett läge där vi kan visa en fungerande MVP med mTLS som kan vara klar snart, och samtidigt ha planer för kommande förbättringar som kanske inte blir klara förrän längre fram. Utöver bättre hantering av utloggning kan signering av saker kan vara bra att kunna hantera. En bra sak med att börja med mTLS är att man sen kan ha samma certifikat senare när man skapar en lösning som kan hantera mer, som signering mm. - Implementation av en första version av CA-programvara för utgivaren Den delen som är kvar där är att utgivaren ska kunna använda en hårdvarunyckel (OpenPGP-kort, yubikey eller liknande), den biten är inte klar ännu. - Fortsättning av test med nginx, lägga till revokeringslista Återkallning har testats med hjälp av CRL-fil, verkar fungera. Förlitande part måste uppdatera revokeringslistan med jämna mellanrum. Alla som vill testa får gärna testa själva, eller höra av sig så att vi kan testa tillsammans. Vem som helst kan testa att agera vilken som helst av de olika rollerna utgivare (CA), eller förlitande part, eller klient. - OpenPGP-kort, hårdvarunycklar osv. Status: inget nytt sedan förra mötet: det funkar med YubiKey [3], vi vill gärna få till det med generellt OpenPGP-kort också. - Beskrivningar av arbetsflöden för utfärdande, användning, återkallande osv. Det jobbas vidare med detta, en sak som fortfarande saknas är längre beskrivningar av saker, och bilder. Det nämndes att med "mermaid" kan man skapa illustrationer i markdown [4]. - När blir nästa möte? Nästa möte blir måndagen 2024-09-30 klockan 18 till 19 (en timme) Alla är välkomna att vara med på kommande möten. OBS även du som inte varit med förut är mycket välkommen att vara med! / Elias [1] https://www.regeringen.se/remisser/2024/07/remiss-av-sou-202445-komplettera… [2] https://mailman.dfri.se/mailman3/hyperkitty/list/eleg-projekt@lists.dfri.se… [3] https://mailman.dfri.se/mailman3/hyperkitty/list/eleg-projekt@lists.dfri.se… [4] https://mermaid.js.org/syntax/sequenceDiagram.html PS Läs gärna om projektet här: https://www.dfri.se/projekt/e-legitimation/ PS 2 Alla som är intresserade är välkomna att höra av sig via projektets mejllista

1 0

Välkomna på öppet möte nr 21 om att bygga egen e-leg-lösning, 9 sept klockan 18
by Elias Rudberg 04 Sep '24

04 Sep '24

Hej! Välkomna till distans-möte nummer 21 om hur vi kan bygga en egen decentraliserad lösning för fri och öppen e-legitimation. Vi fortsätter med kravspecifikation, design och implementation av de olika komponenter som kommer behövas. Tid: måndag 9 september 2024 klockan 18:00. Vi siktar på att hålla på i upp till en timme. Plats: https://jitsi.eliasrudberg.se/e-id-meeting Förslag till agenda: - Kontakt med DIGG om statlig e-legitimation? - Använda tokens för att hantera inlogg/utloggning? - Implementation av en första version av CA-programvara för utgivaren - Fortsättning av test med nginx, lägga till revokeringslista - OpenPGP-kort, hårdvarunycklar osv. - Beskrivningar av arbetsflöden för utfärdande, användning, återkallande osv. - Arbetsfördelning Alla är välkomna, både ni som varit med tidigare och alla nya som vill vara med och diskutera och hjälpa till med det här. Svara gärna här på mejllistan om du har frågor eller funderingar inför mötet. Välkomna! Vänliga hälsningar Projektets styrgrupp genom Elias

1 0

Information från DIGG om statlig e-legitimation
by Elias Rudberg 03 Sep '24

03 Sep '24

Hej eleg-projekt-listan! Myndigheten för digital förvaltning (DIGG) har skrivit lite om deras arbete med statlig e-legitimation, verkar ha uppdaterats ganska nyligen, juli 2024 nämns: https://www.digg.se/digitala-tjanster/e-legitimering/statlig-e-legitimation Bland annat står det: "Digg bedriver regeringsuppdraget som ett projekt och med olika aktiviteter indelade i delprojekt. Några delar startade parallellt redan från den 1 januari, medan andra delar kommer starta senare för att invänta resultaten från tidigare faser. I fokus just nu är att utveckla den tekniska lösningen och att säkerställa att den efterlever de säkerhetskrav som EU ställer upp. Digg har utvecklat en prototyp i syfte att testa olika teknikval och design- och tillgänglighetsaspekter. Parallellt pågår ett arbete med att upprätta interna processer och rutiner för säkerhet." "Projektet övergick från en analysfas till en genomförandefas i juli 2024." En sak jag inte lyckats begripa är om riksdagen fattat beslut om de lagändringar som utredningarna föreslagit, eller om det är något som återstår och som i så fall kan försena alltihop. Någon här på listan som vet? Jag har i alla fall mejlat till DIGG för att försöka få svar på det. / Elias

2 1

OpenPGP-kort, vad är det och hur skaffar man ett sånt?
by Elias Rudberg 14 Aug '24

14 Aug '24

Hej! På mötet i måndags kom frågan upp om vad ett "OpenPGP-kort" egentligen är och hur man kan skaffa ett sådant. Här står lite om vad det är för något: https://en.wikipedia.org/wiki/OpenPGP_card Poängen är att man kan ha sin privata nyckel säkert lagrad i ett sånt kort, det går då inte att kopiera ut nyckeln därifrån vilket är bra för säkerhet: så länge du själv har koll på det fysiska kortet vet du att ingen annan har din privata nyckel. Här är några ställen jag hittat där det verkar gå att köpa OpenPGP-kort: https://en.cryptoshop.com/products/smartcards/open-pgp-smartcard-v2.html https://www.floss-shop.de/en/security-privacy/smartcards/13/openpgp-smart-c… https://shop.puri.sm/shop/purism-openpgp-card/ Någon som vet om det finns någon butik i Sverige som säljer OpenPGP-kort? / Elias

1 0

Sammanfattning av öppet möte nr 20 om att bygga egen e-leg-lösning, 12 aug 2024
by Elias Rudberg 14 Aug '24

14 Aug '24

Sammanfattning av öppet möte nr 20 om att bygga egen e-leg-lösning, 12 augusti 2024: - Implementation av en första version av CA-programvara för utgivaren Status: implementation finns och fungerar, använder inte hårdvarunyckel (ännu). - Fortsättning av test med nginx, lägga till revokeringslista Vi ska testa arbetsflödet, skapa (utfärda) några certifikat, återkalla ett se att det stämmer, att revokeringslistan fungerar vid efterföljande inloggningsförsök. En FAQ-fråga har förberetts om det, "Hur gör jag för att testa vissa komponenter?" även om visa delar är utkommenterade. Några personer på mötet ställde upp som testare, så vi kan testa att utfärda certifikat till dem och sedan återkalla. - OpenPGP-kort, hårdvarunycklar osv. Status: inget nytt sedan förra mötet: det funkar med YubiKey, vi vill gärna få till det med generellt OpenPGP-kort också. - Beskrivningar av arbetsflöden för utfärdande, användning, återkallande osv. Arbete med en FAQ-sida pågår, det senaste är uppdelning i avdelningar och fler externa länkar, vi tittade på ett utkast till hur FAQ-sidan kan se ut. Arbetet fortsätter. - Projektets mejllista, ändra "Reply-To"? DFRI använder Mailman3 för mejllistorna och listan beter sig nu enligt default-beteendet som Mailman3 har. Vi diskuterade lite kring det och för- och nackdelar med reply- beteendet, ska till att börja med pröva att ändra någon inställning. - När blir nästa möte? Nästa möte: mån 9 sept klockan 18 Nästa möte blir måndagen 2024-09-09 klockan 18 till 19 (en timme) Alla är välkomna att vara med på kommande möten. OBS även du som inte varit med förut är mycket välkommen att vara med! / Elias PS Läs gärna om projektet här: https://www.dfri.se/projekt/e-legitimation/ PS 2 Alla som är intresserade är välkomna att höra av sig via projektets mejllista

1 0

Välkomna på öppet möte nr 20 om att bygga egen e-leg-lösning, 12 aug klockan 18
by Elias Rudberg 11 Aug '24

11 Aug '24

Hej! Välkomna till distans-möte nummer 20 om hur vi kan bygga en egen decentraliserad lösning för fri och öppen e-legitimation. Vi fortsätter med kravspecifikation, design och implementation av de olika komponenter som kommer behövas. Tid: måndag 12 augusti 2024 klockan 18:00. Vi siktar på att hålla på i upp till en timme. Plats: https://jitsi.eliasrudberg.se/e-id-meeting Förslag till agenda: - Implementation av en första version av CA-programvara för utgivaren - Fortsättning av test med nginx, lägga till revokeringslista - OpenPGP-kort, hårdvarunycklar osv. - Beskrivningar av arbetsflöden för utfärdande, användning, återkallande osv. - Projektets mejllista, ändra "Reply-To"? - Arbetsfördelning Alla är välkomna, både ni som varit med tidigare och alla nya som vill vara med och diskutera och hjälpa till med det här. Svara gärna här på mejllistan om du har frågor eller funderingar inför mötet. Välkomna! Vänliga hälsningar Projektets styrgrupp genom Elias

1 0

Förslag: Ändra Reply-To till listan
by Thomas Svensson 24 Jul '24

24 Jul '24

Hej listan 🖖 När jag skulle svara på Elias post till listan idag, så var det i sista sekunden jag upptäckte att klicka *svara* innebar att jag mejlade direkt till Elias och inte till listan. För att ändra till svara till listan behövde jag klicka *svara alla*, sedan ta bort Elias mejladress och flytta listans från CC-fältet till To-fältet. Från ett UX-perspektiv (jupp jag är UX-nörd också :)) så är ju det något bökigt, och åtminstone kommer jag nog nästan alltid att vilja svara till listan. Vilket innebär att jag måste komma ihåg att klicka *svara alla* och sedan pilla om adresserna varje gång. Enligt Reply to list i mailman dokumentationen <https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/handlers/d…> så går det att ändra så att klicka *svara* räcker för att svara till listan. Jag mejlade Elias och frågade om det är möjligt att ändra, och vi kom fram till att kolla med er övriga om det är något ni också är med på. Så vad tycker ni. Är ni med på att förenkla svara till listan på sättet jag beskriver ovan? /thomas @tsvenson <https://mastodon.online/@tsvenson>

7 6

OCSP vs CRL
by hmw.qayem＠aleeas.com 23 Jul '24

23 Jul '24

Blev uppmärksammad på denna artikel idag: https://letsencrypt.org/2024/07/23/replacing-ocsp-with-crls.html "We recommend that anyone relying on OCSP services today start the process of ending that reliance as soon as possible." Jag har inga preferenser åt varken det ena eller andra hållet, men det här talar onekligen *mot* OCSP. //Magnus

1 0

Sammanfattning av öppet möte nr 19 om att bygga egen e-leg-lösning, 22 juli 2024
by Elias Rudberg 23 Jul '24

23 Jul '24

Sammanfattning av öppet möte nr 19 om att bygga egen e-leg-lösning, 22 juli 2024: - Implementation av en första version av CA-programvara för utgivaren Status: implementation finns och fungerar, använder inte hårdvarunyckel (ännu). - Fortsättning av test med nginx, lägga till revokeringslista Enkel proof-of-concept "förlitande part" finns med nginx+gunicorn+flask [1], en sak som bör läggas till där är att använda revokeringslista. Fler test-personer vore bra, ni som vill vara med och testa något uppmuntras att höra av er. - OpenPGP-kort, hårdvarunycklar osv, YubiKey som exempel Viktigt att inte vara låst till någon viss lösning men vill samtidigt visa konkreta exempel på hur en användare kan göra. Ett exempel kan vara Yubikey [2] men vi vill gärna kunna visa hur det kan fungera med vanligt OpenPGP-kort också, för att ha åtminstone två exempel att visa: OpenPGP-kort och yubikey. Bra med fler än ett exempel för att undvika att någon tror att lösningen är låst till en viss typ av hårdvarunyckel. (Tillitis TKey är också en möjlighet, som diskuterats här på mejllistan tidigare.) Något motsvarande [3] men med OpenPGP-kort istället för yubikey hade varit fint. Standarden PKCS11 verkar bra att använda, standard för operationer mot någon form av key-storage som kan vara i form av ett smartkort eller annan lösning. - Beskrivningar av arbetsflöden för utfärdande, användning, återkallande osv. Arbete med vanliga frågor och svar (FAQ) fortsätter, flera har hjälpt till. Syftet är nu också på plats i inledningen som grund för alla frågorna och svaren. Interna referenser har blivit ytterligare fler för att inte upprepa text men ändå täcka in fler frågor. Så nästa stora steg är att få in bilder från arbetsflödena på ett stabilt sätt samt lite mer luft mellan stycken i inledningen och andra lite längre textavsnitt. Ett antal frågor har tillkommit, och några utvecklats. - Arbetsfördelning Vi hann inte säga mycket om det, blir nog ungefär som tidigare. - När blir nästa möte? Nästa möte blir måndagen 2024-08-12 klockan 18 till 19 (en timme) Alla är välkomna att vara med på kommande möten. OBS även du som inte varit med förut är mycket välkommen att vara med! / Elias [1] https://mailman.dfri.se/mailman3/hyperkitty/list/eleg-projekt@lists.dfri.se… [2] https://mailman.dfri.se/mailman3/hyperkitty/list/eleg-projekt@lists.dfri.se… [3] https://johanfagerstroem.github.io/2021/https-client-certificates-with-yubi… PS Läs gärna om projektet här: https://www.dfri.se/projekt/e-legitimation/ PS 2 Alla som är intresserade är välkomna att höra av sig via projektets mejllista

3 2

Välkomna på öppet möte nr 19 om att bygga egen e-leg-lösning, 22 juli klockan 18
by Elias Rudberg 21 Jul '24

21 Jul '24

Hej! Välkomna till distans-möte nummer 19 om hur vi kan bygga en egen decentraliserad lösning för fri och öppen e-legitimation. Vi fortsätter med kravspecifikation, design och implementation av de olika komponenter som kommer behövas. Tid: måndag 22 juli 2024 klockan 18:00. Vi siktar på att hålla på i upp till en timme. Plats: https://jitsi.eliasrudberg.se/e-id-meeting Förslag till agenda: - Implementation av en första version av CA-programvara för utgivaren - Fortsättning av test med nginx, lägga till revokeringslista - OpenPGP-kort, hårdvarunycklar osv, YubiKey som exempel - Beskrivningar av arbetsflöden för utfärdande, användning, återkallande osv. - Arbetsfördelning Alla är välkomna, både ni som varit med tidigare och alla nya som vill vara med och diskutera och hjälpa till med det här. Svara gärna här på mejllistan om du har frågor eller funderingar inför mötet. Välkomna! Vänliga hälsningar Projektets styrgrupp genom Elias

1 0

Hur användare kan ha sin privata nyckel i en Yubikey, ykman piv generate-key, ykman piv generate-csr osv.
by Elias Rudberg 07 Jul '24

07 Jul '24

Hej eleg-projekt-listan! Här är ett sätt som verkar fungera för en användare som väljer att ha sin privata nyckel i en Yubikey. Baserat på bland annat de här två: "HTTPS client certificates using Yubikeys" - https://johanfagerstroem.github.io/2021/https-client-certificates-with-yubi… "cURL Authentication using certificates from smartcard" - https://qwerty1q2w.medium.com/performing-client-authentication-in-curl-usin… Vi tänker oss medborgaren Alice som kör Debian på sin dator. Alice vill få ett e-id utfärdat till sig och hon vill använda en Yubikey för sin privata nyckel. Alice installerar följande, vanliga debian-paket: sudo apt install opensc libengine-pkcs11-openssl gnutls-bin sudo apt install ykcs11 sudo apt install yubikey-manager sudo apt install yubico-piv-tool När yubikeyn sitter i datorn ska det gå att se den med följande kommando: ykman info Då visas serienummer mm. för Yubikeyn. Sen kan Alice skapa ett nyckelpar där den privata nyckeln skapas på yubikeyn: ykman piv generate-key 9a alice.pub Skapa certificate signing request (CSR): ykman piv generate-csr -s alice 9a alice.pub alice.csr Då skapas filen alice.csr som Alice ger till utfärdaren, som i sin tur utfärdar ett personligt certifikat till Alice (det gör utfärdaren med hjälp CA-programvaran som vi diskuterat tidigare). Alice får sen sin certifikat-fil från utfärdaren, i detta exempel heter filen eid_200007171717.crt.pem och 200007171717 är Alice personnummer i det här testet. Nu kan hon importera certifikat-filen in till yubikeyn: ykman piv import-certificate 9a eid_200007171717.crt.pem Sen är det klart, Alice har sitt certifikat och sin privata nyckel i sin yubikey. Nu kan Alice använda sitt certifikat för att ansluta till test-sidan https://eid-test-2.eliasrudberg.se/ Två varianter av hur det kan göras: med curl eller Firefox Alternativ 1: curl Kör först "p11tool --list-tokens" för att få fram vilken "URL" som gäller för yubikeyn, det ser ut såhär: $ p11tool --list-tokens [...] Token 1: URL: <här står URL-strängen> Label: PIV_II Type: Hardware token Flags: RNG, Requires login Manufacturer: piv_II Model: PKCS#15 emulated Serial: [...] Module: opensc-pkcs11.so Den där "URL" ser ut ungefär såhär: "pkcs11:model=PKCS%2315%20emulated;manufacturer=piv_II;serial=...;token=PIV_II" Anslut sedan med curl på följande vis, där $url är den URL som visades av "p11tool --list-tokens" ovan: curl -E $url https://eid-test-2.eliasrudberg.se/ --> då kommer en fråga om PIN-koden för yubikeyn: "Enter PKCS#11 token PIN for PIV_II:" och när man fyllt i den kommer man fram: Hej! personnummer = 200007171717 Den texten, "Hej! personnummer = 200007171717", är alltså det som testsidan https://eid-test-2.eliasrudberg.se/ svarar med, så det betyder att det hela fungerar. Alternativ 2: Firefox Inställningar i Firefox: Settings --> Privacy & Security --> Certificates --> Knappen "Security Devices..." --> Knappen "Load" --> Skriv ett valfritt Module Name och ange Module filename /usr/lib/x86_64-linux-gnu/libykcs11.so --> Starta om Firefox och kolla "Security Devices..." igen för att se att den nya syns där, med namnet du satte. När man sen går till https://eid-test-2.eliasrudberg.se/ i Firefox kommer en fråga om PIN-kod för yubikeyn och sen en ruta som säger: "This site has requested that you identify yourself with a certificate" och "Choose a certificate to present as identification" och en lista där det bara finns ett cert att välja, "Stored on Yubikey PIV #[...]". Väljer man det så fungerar sidan och visar det den ska, alltså "Hej! personnummer = 200007171717" Så det verkar fungera, både med curl och med Firefox. Hittills har bara jag själv testat det det här, alltså jag är "Alice" i testet och testar med en yubikey jag har på en dator jag har. Fler testare vore bra. Vi har några till yubikeys för test, jag kan skicka en till den som vill testa, säg bara till. Vad tror ni om det här, verkar ovanstående vettigt? Har jag tänkt fel någonstans eller missat något, finns enklare och/eller bättre sätt? Vad krävs för att kunna göra motsvarande med andra typer av "Hardware token" än just yubikey? / Elias

1 0

Funderingar om hur OpenPGP-kort kan användas, gpgsm, openssl, pkcs11
by Elias Rudberg 05 Jul '24

05 Jul '24

Hej eleg-projekt-listan! När det gäller hur man som användare kan använda OpenPGP-kort (kan vara i form av yubikey eller annat) för sin privata nyckel, finns ju två delar: (1) Skapa certificate signing request (CSR) som sedan ges till utfärdaren. (2) Använda det personliga certifikatet, när man väl fått det från utfärdaren. När det gäller (1) går det att använda kommandot gpgsm på följande sätt: gpgsm --armor --output mycsr.pem --gen-key vilket då skapar filen mycsr.pem kopplad till den privata nyckeln man har i sitt OpenPGP-kort. ( se https://security.stackexchange.com/questions/82284/create-certificate-witho… ) Det är ett sätt att lösa (1) alltså, frågan är sen hur man kan göra (2). I det enklare fallet när man har sin privata nyckel på fil, då kan man ju använda curl med --cert och --key såhär, som nämnts i tidigare mejl här på listan: curl --cert my_eid.crt.pem --key my_eid.key.pem https://example.org Men när den privata nyckeln är i ett OpenPGP-kort går det ju inte, då fungerar förstås inte "--key my_eid.key.pem" (eftersom någon sån privat-nyckel-fil inte finns) utan man behöver göra på något annat sätt. "man curl" säger bland annat följande: ----- --key <key> (TLS SSH) Private key file name. Allows you to provide your private key in this separate file. For SSH, if not specified, curl tries the following candidates in or‐ der: '~/.ssh/id_rsa', '~/.ssh/id_dsa', './id_rsa', './id_dsa'. If curl is built against OpenSSL library, and the engine pkcs11 is available, then a PKCS#11 URI (RFC 7512) can be used to specify a private key located in a PKCS#11 device. A string beginning with "pkcs11:" is interpreted as a PKCS#11 URI. If a PKCS#11 URI is provided, then the --engine option is set as "pkcs11" if none was pro‐ vided and the --key-type option is set as "ENG" if none was provided. ----- Det där med "specify a private key located in a PKCS#11 device" kanske är relevant. Ett nästa steg kan vara att läsa på mer om hur det fungerar. Den som har erfarenhet av såna saker, som att använda gpg eller openssl med pkcs11 eller liknande, eller känner till andra bättre sätt att göra det här, får mycket gärna hjälpa till! / Elias

1 0

2025

2024

2023

2022

2021

Eleg-projekt