Hej alla på eleg-projekt-listan!
Vi håller ju på med att ta fram en "proof-of-concept" för att kunna visa
hur en fri e-legitimation kan utfädras och användas. Vi har en
CA-programvara för utfäraden som kan användas för att skapa certifikat,
och vi vill också kunna visa exempel på hur en "förlitande part" kan funka.
Nu finns en lite annorlunda test-sida som exempel på hur en "förlitande
part" kan fungera, alltså en webbsida där det krävs ett
klient-certifikat (e-leg) för att komma in på sidan och där sidan kan
använda information från certifikatet (som personnummer för användaren
som anslutit).
Det är en server som kör Debian GNU/Linux och använder programvarorna
nginx, gunicorn och flask, på följande vis.
I nginx-konfigurationen finns då bl.a. de här raderna:
---------------------------------------------------------
# Here, specify the CA certificate from the issuer
ssl_client_certificate /home/elias/ca-cert/issuingca.crt.pem;
ssl_verify_client on;
location / {
if ($ssl_client_verify != "SUCCESS") { return 401; }
proxy_redirect off;
proxy_set_header X-EID-CERT $ssl_client_escaped_cert;
proxy_pass http://127.0.0.1:8000;
}
---------------------------------------------------------
där filen issuingca.crt.pem är certifikatet för utfärdaren, som vi
alltså har skapat med vår CA-programvara. Förlitande part behöver få det
certifikatet från utfäraden och installera det på sin server.
Raden med "proxy_pass" betyder att man skickar vidare till applikationen
som finns på port 8000 och "proxy_set_header X-EID-CERT
$ssl_client_escaped_cert" betyder att klientcertifikatet skickas vidare
dit i form av en header med namnet "X-EID-CERT".
Sen körs gunicorn (körs som en systemd-tjänst) som lyssnar på port 8000
och som kör en Flask-applikation såhär:
/usr/bin/gunicorn eid-flask-app:app
och själva applikationen är ett litet python-program som ser ut såhär:
---------------------------------------------------------
from flask import Flask
from flask import request
from cryptography import x509
from cryptography.hazmat.backends import default_backend
from urllib.parse import unquote
app = Flask(__name__)
@app.route('/')
def hello():
cert = request.headers.get('X-EID-CERT')
cert_unquoted = unquote(cert)
cert_decoded = x509.load_pem_x509_certificate(bytes(cert_unquoted,
'utf-8'), default_backend())
cert_subject=cert_decoded.subject
oid = x509.ObjectIdentifier("1.3.6.1.4.1.55594.1.3.121")
attrs = cert_subject.get_attributes_for_oid(oid)
personnummer = attrs[0].value
return 'Hej! personnummer = {}\n'.format(personnummer)
---------------------------------------------------------
Python-programmet använder alltså headern 'X-EID-CERT' med
klientcertifikatet som nginx skickade vidare och plockar därifrån fram
personnumret som finns i ett visst fält i certifikatet.
Nu gör programmet inget mer än att skriva personnumret vilket inte är så
spännande, men poängen är att programmet kan implementera vilken
funktionalitet man vill, programmet körs för en identifierad användare
och kan göra olika saker beroende på peronnumret. Till exempel kan
programmet visa information som bara just den personen ska få se, eller
ge tillgång till funktioner som just den personen ska få använda.
Det verkar fungera, kan testas med curl:
$ curl --cert eid_200007777777.crt.pem --key eid.key.pem
https://eid-test-2.eliasrudberg.se/
Hej! personnummer = 200007777777
Texten "Hej! personnummer = 200007777777" som visas har alltså skapats
av sista raden i python-programmet.
Det går även att testa i webbläsare om användaren först lägger in sitt
klientcert webbläsaren.
Filerna finns i git-repot här:
https://codeberg.org/DFRI-eID/go-eid-test-ca/src/branch/main/nginx-test
Vad tror ni om det här, är den här sortens test ett vettigt sätt att
visa hur en fri och öppen e-legitimation skulle kunna fungera?
/ Elias
PS
Alla som vill testa är välkomna att höra av sig till mig.
PS2
Nästa möte är 2024-07-22 klockan 18
Sammanfattning av öppet möte nr 18 om att bygga egen e-leg-lösning, 24
juni 2024:
- Implementation av en första version av CA-programvara för utgivaren
Nu finns funktionalitet för att spara i databas och återkalla
certifikat, och skapa revokeringslista utifrån det. Vi diskuterade
några detaljer kring det, som i vilken katalog databas-filen som
default bör skapas.
Vi diskuterade också en del kring var gränsen ska dras för vilken
funktionalitet som behöver finnas i en första proof-of-concept.
- Fortsättning av test med nginx
Har inte hunnit något mer här sedan sist, nästa steg är fortfarande att
kunna få fram och använda information från klient-certifikatet, t.ex.
få test-webbsidan att säga "Hej <personnummer>" där personnumret som
visas kommer från certifikatet som användaren anslutit med.
- OpenPGP-kort, hårdvarunycklar osv, hur har testningen gått?
Testanvändare har fått hårdvarunyckel att kunna testa med, vi hoppas på
resultat från det snart.
- Beskrivningar av arbetsflöden för utfärdande, användning,
återkallande osv.
Arbetet med vanliga frågor och svar (FAQ) mm fortsätter.
- Arbetsfördelning
Som tidigare.
- Slutbetänkandet av Utredningen om säker och tillgänglig digital
identitet har kommit
Slutbetänkandet av den utredningen har alltså kommit nu (SOU 2024:45)
och den handlar mest om den "digitala identitetsplånbok" som snart ska
behöva finnas i varje EU-land. Delbetänkandet som kom i oktober (SOU
2023:61) handlade om statlig e-legitimation som sen ska kunna användas
i kombination med den "digitala plånboken".
Positivt är att EU-förordningen 2024/1183 som ligger med som Bilaga 2 i
slutbetänkandet innehåller skrivningar om att det ska vara öppen
källkod.
- När blir nästa möte?
Nästa möte blir måndagen 2024-07-22 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
Hej!
Utredningen om säker och tillgänglig digital identitet (särskild
utredare Henrik Ardhede som var med på SamNet-konferensen) blev klar
nyligen, slutbetänkandet "Kompletterande bestämmelser till EU:s
reviderade förordning om elektronisk identifiering" finns här, en pdf på
394 sidor, publicerat 17 juni 2024:
https://www.regeringen.se/rattsliga-dokument/statens-offentliga-utredningar…
När det gäller tidsplan nämns att en "digital europeisk
identitets-plånbok" ska finnas senast i december 2026:
"Som tidigare redovisats förutsätter den reviderade eIDAS-förordningen
att det finns tillgång till minst en digital europeisk
identitets-plånbok i varje medlemsland. Detta krav ska vara uppfyllt
inom 24 månader från och med ikraftträdande av genomförandeakter som
fastställer de tekniska specifikationerna för identitetsplånboken och
dess certifiering. Givet att rättsakterna antas i tid och i anslutning
därtill publiceras i Europeiska unionens tidning, ska europeiska
digitala identitetsplånböcker finnas tillgängliga senast i december 2026."
I bilaga 2 finns "EUROPAPARLAMENTETS OCH RÅDETS FÖRORDNING (EU)
2024/1183" där det står om öppen källkod:
"(33) Transparensen i europeiska digitala identitetsplånböcker och
tillhandahållarnas ansvarsskyldighet är viktiga faktorer för att skapa
social tillit och få till stånd acceptans för ramverket. De europeiska
digitala identitetsplånböckernas funktionssätt bör därför vara
transparent och i synnerhet medge kontrollerbar behandling av
personuppgifter. För att uppnå detta bör medlemsstaterna lämna ut
källkoden för programvarukomponenter i användartillämpningen av
europeiska digitala identitetsplånböcker, inbegripet dem som rör
behandling av personuppgifter och uppgifter om europeiska digitala
identitetsplånböcker, inbegripet dem som rör behandling av
personuppgifter och uppgifter om samhället, inbegripet användare och
utvecklare, att förstå hur koden fungerar samt revidera och granska
koden. Detta skulle öka användarnas förtroende för ekosystemet och bidra
till de europeiska digitala identitetsplånböckernas säkerhet genom att
göra det möjligt för vem som helst att rapportera sårbarheter och fel i
koden. På det hela taget bör detta ge leverantörerna incitament att
leverera och upprätthålla en mycket säker produkt. I vissa fall kan dock
offentliggörandet av källkoden för bibliotek, kommunikationskanaler
eller andra element som inte finns på användarenheten begränsas av
medlemsstaterna, av vederbörligen motiverade skäl, särskilt med hänsyn
till den allmänna säkerheten."
Det kan alltså finnas undantag från kravet på öppen källkod, men
undantag verkar bara gälla "källkoden för bibliotek,
kommunikationskanaler eller andra element som inte finns på
användarenheten". Förhoppningsvis betyder det att allt som installeras
på användarenheten måste ha öppen källkod.
/ Elias
Hej!
Välkomna till distans-möte nummer 18 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 24 juni 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, hur har testningen gått?
- Beskrivningar av arbetsflöden för utfärdande, användning, återkallande
osv.
- Arbetsfördelning
- Slutbetänkandet av Utredningen om säker och tillgänglig digital
identitet har kommit
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
Sammanfattning av öppet möte nr 17 om att bygga egen e-leg-lösning, 29
maj 2024:
- Implementation av en första version av CA-programvara för utgivaren
Den senaste koden med databas för utfärdade certifikat ska testas,
bl.a. testa hur revokeringslista kan skapas och användas. Jobb med att
snygga till koden och förtydliga med kommentarer osv fortsätter.
- Fortsättning av test med nginx
Test-sidan https://lab.joxaren.se fungerar om ens certifikat är inlagt.
För att testa, följ instruktion i separat mejl till e-postlistan [1].
Nästa steg när det gäller nginx-testet med mTLS är att få sidan att
kunna använda information (personnummer) från det personliga
certifikatet för den person som anslutit. Har inte hunnits med ännu.
Alla som vill hjälpa till med den delen är mycket välkomna. Fler
testpersoner skulle vara bra också, hör av dig om du vill testa.
- OpenPGP-kort, hårdvarunycklar osv, vilka varianter kan och bör vi
pröva?
Några möjliga alternativ:
- OpenPGP-kort för kortläsare
- Yubikey eller liknande
- Tillitis TKey
Den som har något av ovanstående kan testa på egen hand. Vi har också
några stycken Yubikey och TKey som de personer som vill testa kan få
använda, de kan lånas ut till olika personer efter behov. Obs att
Tillitis TKey kan kräva lite mer jobb, se tidigare mejl till e-
postlistan om det [2].
Vi diskuterade att det kan verka förvirrande att det finns så många
olika alternativ, men att det i grunden är bra att det går att göra på
olika sätt, så länge man följer specifikationen. Senare kan vi kanske
välja en metod som "huvudmetod".
- Beskrivningar av arbetsflöden för utfärdande, användning,
återkallande osv.
Senaste versionen av "vanliga frågor och svar" (FAQ) med schema.org-
FAQ-stöd visades och diskuterades.
- Arbetsfördelning
Olika typer av arbete som pågår, olika personer gör olika delar:
- fortsatt utveckling av CA-programvara för utgivaren
- testa senaste CA-programvaran inkl. skapa och använda
revokeringslista
- fortsättning med nginx-testet
- fortsatt jobb med beskrivningar av användningsfall och FAQ osv.
- Övrig fråga: tidsplan?
Vi diskuterade vad som är en rimlig uppskattning av när vår proof-of-
concept kan förväntas vara klar i någon sorts lite mer officiell första
version. Tidigare har "hösten 2024" nämnts, men med tanke på att allt
sker ideellt och vi inte vet hur mycket tid olika personer kommer att
ha, kanske "under 2025" är mer realistiskt? Svårt att säga, vi
diskuterade det lite fram och tillbaka. I vilket fall som helst går det
snabbare om fler hjälper till, den som tycker det går långsamt
uppmuntras att vara med så blir vi klara snabbare! :-)
- När blir nästa möte?
Nästa möte blir måndagen 2024-06-24 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]
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…