Sammanfattning av öppet möte 31 om att bygga egen e-leg-lösning, 26 maj 2025:
Tack till alla som var med på mötet!
Länkar [1] till [6] finns längst ner i det här mejlet.
- CA-programvara för utgivaren och test med nginx, status? Procedur för att förnya utgivarens cert?
Vår kod finns här: [1]
När det gäller utfärdarens certifikat finns ett root-cert (skapat med kommandot "genroot", se README-filen [2]) och ett issuingca-cert (skapat med kommandot "genica", se README-filen). De kan ha olika giltighetstid, "Not before", "Not after". Kedjebyggandet behöver vi ev tänka på.
- Testat med "Nitrokey HSM", det fungerar, men "Nitrokey 3" funkar inte
Christian testade först och Elias har nu testat och verifierat det med samma resultat, alltså "Nitrokey HSM" fungerar.
Det gör att vi har åtminstone två olika typer av hårdvarunycklar där vi testat att det fungerar, yubikey och nitrokey. Vill gärna ha fler.
- OpenPGP-kort, testat men inte fått det att fungera ännu
Elias har skaffat ett "Open PGP SmartCard" från cryptoshop [3] och kopplat in till dator via kortläsare, det fungerar så långt att kommandot "gpg --card-status" visar information om kortet, men har inte ännu lyckats använda certifikat med nyckel i kortet så som vi skulle behöva. Du som läser detta och är bra på sånt för gärna hjälpa till med det!
Vi pratade lite om olika ord som används för "hårdvarunyckel", som "hardware key", "security key", "hardware token", osv. Ett "smartcard" som det där OpenPGP-kortet är en annan variant. Poängen är i alla fall att den privata nyckeln kan finnas lagrad i en hårdvarunyckel/smartkort på ett sätt som gör att nyckeln inte kan kopieras ut därifrån.
- Sätta upp server med revokeringslista, ordna domän och webbserver för det?
Nu har ljo fixat en url vi kan använda för det, för test: [4]
Utfärdaren (t.ex. Elias kanske, eller vem det nu är som agerar utfärdare) behöver kunna ladda upp ny revokeringslista dit, det får vi lösa, som vi sa så är det att manuellt byta till att börja med.
OBS 1: om man har revokeringslistan på ett enda ställe vlir ju det en central punkt som går att slåut, så det är inte bra för robustheten i systemet. En utfärdare kan välja att ha många redundanta ställen som listan kan hämtas från. Men för tidiga test och demo kan vi ha ett ställe, det räcker ju för att få till ett system som fungerar, så att förlitande part kan hämta revokeringslista någonstans ifrån.
OBS 2: vi borde sätta upp både "labbmiljö 1" och "labbmiljö 2" för att undvika att någon tror att det hela är en centraliserad lösning. Tror inte det är nåt större problem eftersom varje utfärdare har sin egen lista.
Man kan också ha stället där revokeringslistan finns inkluderat i certifikat som utfärdas.
- Börja använda vårt system internt inom DFRI för medlemmar?
Vi tror inte det är en bra idé nu innan PoC (proof-of-concept) men det kan vara del av PoC.
Absolut ett framtidsscenario att göra det efter PoC, vilka attribut, och lyfta de olika användningsfallen i olika installationer.
- Skriva debattartikel om robusthet apropå BankID-problemen nyligen?
Det var ett utkast på gång men glömdes bort lite, ska ta upp det igen.
BankID har sagt något i stil med att "det spelar ingen roll vem som driver en sån här lösning, det blir ändå samma svårigheter", alltså de pratar som om det inte går att ha en decentraliserad lösning, det kan vi skriva om. Se tidigare tråd på mejllistan om det: [5]
Var ska vi publicera? Hitta nån som accepterar, skriva om ett antal varianter
- "Remiss av Uppgiftsskyldighet för vissa e-legitimationsföretag": [6] -- senaste dag att svara är den 8 juli.
DFRI var inte med på listan av remissinstanser på den, men man får ju svara ändå så vi kan göra det.
Verkar som om de vill använda e-leg som ett sätt för polisen att spåra folk. Det borde inte vara så.
Kanske, istället för att klanka ner på förslaget i stort, kan man förklara att det här inte är tekniskt möjligt om man ska ha ett decentraliserat system som man behöver ha i ett framtida robust system. Kravet måste i så fall riktas till de olika förlitande parterna. Lagstiftning bör inte förutsätta att det finns en centraliserad punkt som allt går genom.
För att inte vara för negativ, kan man påpeka andra sätt, att det behöver inte vara en inbyggd funktion i id-systemet utan det kan vara något polisen försöker få från vissa förlitande parter, det skulle kunna vara möjligt för polisen att kunna få information den vägen utan att det behöver vara inbyggt i systemet och därmed drabba all användning oavsett syfte.
Om polisen vill tvinga fram att det installeras spion-programvara på varje ställe där folk loggar in, då får de säga att det är det de vill (men det låter inte så trevligt).
Spårning borde inte vara inbyggt i systemet.
Vi planerar att ta upp det på mejllistan, kanske ett senare tillfälle där vi kan ha ett möte om att skriva ett sånt remiss-svar.
- När blir nästa möte?
Nästa möte hålls måndag 2025-06-23 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
Länkar:
[1] https://codeberg.org/DFRI-eID/dfri-eid
[2] https://codeberg.org/DFRI-eID/dfri-eid/src/branch/main/go-eid-test-ca/README...
[3] https://en.cryptoshop.com/products/smartcards/proprietary-solution-cards/ope...
[4] https://fritt-e-leg.se/crl/crl.pem
[5] https://mailman.dfri.se/mailman3/hyperkitty/list/eleg-projekt@lists.dfri.se/...
[6] https://www.regeringen.se/remisser/2025/04/remiss-av-uppgiftsskyldighet-for-...