Sammanfattning av öppet möte 32 om att bygga egen e-leg-lösning, 23 juni
2025:
Tack till alla som var med på mötet!
- CA-programvara för utgivaren och test med nginx, status? Procedur för
att förnya utgivarens cert?
Elias har inte hunnit komma till det än. Bra att få till att utgivaren
kan använda hårdvarunyckel.
Christian har tänkt sätta upp en webbsida där man kan sätta upp
e-legitimation på fil, är på gång men har inte hunnit riktigt ännu.
Har även provat EJBCA som är en open-source web-tjänst.
https://www.ejbca.org/use-cases/issue-tls-and-mtls-certificates/
Har testkört deras docker-image med framgång men inte fått igång en
utvecklingsmiljö för att lägga till nyckelpargenerering i browsern.
- OpenPGP-kort, testat mer. pkcs11, olika kort har olika uppsättning av
"mechanisms" som stöds
Verkar gå bra att skapa nyckel på kortet, skapa csr, och generera cert.
Återstår att få användningen av cert att fungera, alltså kommunikationen
med förlitande part. Testar med curl.
Olika versioner av OpenPGP-kort, så kanske en nyare version kan funka.
Ska undersökas mer, för att se vad som funkar och inte, och varför.
- Sätta upp server med revokeringslista, ordna domän och webbserver för det?
Den som agerar utfärdare behöver något sätt att kunna lägga upp en
uppdaterad revokeringslista. Utfärdare ska kunna lägga upp, så att
förlitande part sen kan hämta listan. ljo fortsätter kolla på det
utifrån önskemålen möte 31 efter den här veckan när det börjat lugna ner
sej på arbetet.
- Skriva debattartikel om robusthet apropå BankID-problemen nyligen?
Ingen har hunnit. Fortfarande en bra idé att skriva något!
Vi siktar på en "skrivarstuga" snart för att få ihop något. Någon gång
från den 7e juli kan funka tror vi. Alla som vill hjälpa till med att
skriva får gärna höra av sig via projektets mejllista.
- "Invitation: Participatory Requirements Workshop for eIDAS Oversight
Platform", se projektets mejllista.
Vem/vilka kan vara med vid tillfället 2/7? Ch är med.
- "Remiss av Uppgiftsskyldighet för vissa e-legitimationsföretag"
Senaste dag att svara är den 8 juli.
Några instanser har redan svarat, ca 7 stycken.
https://www.regeringen.se/remisser/2025/04/remiss-av-uppgiftsskyldighet-for…
Viktiga är att vi får fram våra synpunkter. Vi borde därför skriva nåt
också, även om vi håller det ganska kort.
Ch är gärna med och skriver ett utkast.
- Paneldiskussion om certifikat
Ch berättar: jag var där, i stan, det var fyra föredragshållare och sen
ett litet mingel.
När vi gick runt bordet, ca 20-25 personer och jag sa att jag var från
DFRI så blev folk intresserade och kom och frågade saker sen under minglet.
Många verkar tycka att det är jobbigt att förnya certifikat och det
fanns produkter för att göra det automatiskt.
Acme-protokollet som Let's Encrypt m fl använder, går att använda för
att förnya certifikat.
Det diskuterades en del om smartcards. Om man har ett smartcard som
stöder pkcs11 är det skillnad mot ett kort som stöder PIV.
Det var en som förklarade att de har levererat något för bilar som
ringer hem och ska identifiera sig, där det behövde uppdateras inom
några dagar, där det kanske var risk att bilen blir "brickad" om bilen
är undanställd några dagar.
Korttids-certifikat: För webb-certifikat går de ner från ca 300 dagar
till 47 dagar (helt arbiträrt valt) och sen vidare ner till 7 dagar. För
att de vill komma bort från revokerings-systemet för att det inte funkar
bra.
Det finns protokoll för att revokera (återkalla) certifikat.
Lösningen vi gör kanske ska stödja att man som e-leg-innehavara kan
skicka med senaste revokerings-listan för att det ska kunna fungera även
om förlitande part inte har en tillräckligt färsk lista.
Läsnyttigt om att ha med egen revokeringslista:
https://blog.cloudflare.com/high-reliability-ocsp-stapling/#ocspstapling
- En till punkt: Ch ska vara med i ett hackaton den 1 juli, där det ska
tas fram en e-legitimation som tema för hackatonet, med tema "resilience"!
Kan ha många kopior av revokeringslistan, med hjälp av en databaslösning
som stöder replikering.
https://cillers.com/hackathons/couchbase-disaster-resilience-hackathon
- När blir nästa möte?
Nästa möte hålls måndag 2025-07-14 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!
Försöker få vår proof-of-concept att fungera med OpenPGP-kort (sedan
tidigare funkar det med YubiKey och NitroKey HSM, men inte ännu med
OpenPGP-kort).
Några länkar om bakgrunden finns längst ner i mejlet.
Allt som används nedan är fri programvara, de olika kommandona finns som
Debian-paket till exempel.
Det jag vill kunna göra är följande tre saker:
(1) Skapa nyckelpar på smartkortet
(2) Skapa en motsvarande CSR-fil (som sen kan ges till utfärdaren som då
kan skapa ett motsvarande personligt certifikat)
(3) Använda det personliga certifikatet för att identifiera sig mot en
test-webbsida
Försöker få det att fungera med ett OpenPGP-kort av den här typen:
https://www.cryptoshop.com/products/smartcards/proprietary-solution-cards/o…
Kommandon som kan användas för att visa info om smartkort (oavsett om
det är ett OpenPGP-kort eller en YubiKey eller NitroKey eller liknande):
gpg --card-status
pkcs11-tool --list-slots
p11tool --list-tokens
Kommandot "p11tool --list-tokens" visar bland annat en "URL" för varje
token, som kan användas som input till vissa andra kommandon för att
säga vilken token man vill använda.
Man kan även köra det här för att visa bara just token url och inget annat:
p11tool --list-token-urls
Om man har ett cert (skapat med vår utfärdar-programvara) kan man
använda det för att identifiera sig mot test-sidan
https://eid-test-2.eliasrudberg.se/ med curl såhär:
curl --cert eid_200001012384.crt.pem --key $url
https://eid-test-2.eliasrudberg.se/
Enter PKCS#11 token PIN for SmartCard-HSM (UserPIN):
Hej 200001012384! Välkommen till Test-sajten :-)
(Alltså ovanstående "Välkommen till Test-sajten" är hur det ser ut om
det fungerar, just nu kan jag få det att fungera med Nitrokey HSM men
inte med OpenPGP-kortet, mer om det här nedanför)
Följande kan hjälpa för att undvika konflikter när olika programvaror
försöker dra i smartkortet samtidigt:
echo disable-ccid >> ~/.gnupg/scdaemon.conf
Se
https://support.yubico.com/hc/en-us/articles/4819584884124-Resolving-GPG-s-…
Ett sätt att skapa nyckelpar på kortet är det här:
gpgsm --generate-key > my-openpgp-card.csr
(men kanske inte bästa sättet)
Ett annat sätt är det här:
pkcs11-tool --module /usr/lib/x86_64-linux-gnu/opensc-pkcs11.so --login
--login-type so --keypairgen --key-type rsa:2048 --id 3 --so-pin 12345678
Valet av "id" spelar roll, alltså "--id 3" ovan. Det går att köra med id
1 eller 2 också, men då blir det problem senare så jag tror att 3 är bäst.
Outputen från kommandot ovan ser ut såhär:
Using slot 0 with a present token (0x0)
Key pair generated:
Private Key Object; RSA
label: Private Key
ID: 03
Usage: decrypt, sign
Access: none
Public Key Object; RSA 16384 bits
label: Private Key
ID: 03
Usage: encrypt, verify
Access: none
Om man kör "gpg --card-status" i det läget kan man se att en
"Authentication key" har skapats på OpenPGP-kortet.
Sen kan man skapa CSR såhär:
openssl req -new -engine pkcs11 -subj "/C=GB/CN=foo" -key id_3 -keyform
engine -out openpgpcard_id3.csr.pem
Den CSR-filen kan ges till utfärdaren, praktiskt nog i detta test är
utfärdaren jag själv :-)
(Den som vill testa kan själv vara utfärdare om man vill, koden finns
här https://codeberg.org/DFRI-eID/dfri-eid)
Utfärdaren skapar cert och sen kan man försöka använda sitt cert.
curl --cert eid_200001012394.crt.pem --key $url
https://eid-test-2.eliasrudberg.se/
(där $url ovan är en url man fått fram med t.ex. "p11tool
--list-token-urls")
Då blir det dock problem:
curl --cert eid_200001012394.crt.pem --key $url
https://eid-test-2.eliasrudberg.se/
Enter PKCS#11 token PIN for OpenPGP card (User PIN):
curl: (35) error:8207A070:PKCS#11
module:pkcs11_private_encrypt:Mechanism invalid
Felmeddelandet säger "Mechanism invalid" alltså.
Genom att lägga till OPENSC_DEBUG=9 kan man få en massa debug-loggning:
OPENSC_DEBUG=9 PKCS11SPY=/usr/lib/x86_64-linux-gnu/opensc-pkcs11.so curl
-vvvv --cert eid_200001012394.crt.pem --key $url
https://eid-test-2.eliasrudberg.se/
Då ser man bland annat följande som verkar intressant:
P:16041; T:0x140368933964096 19:47:35.351 [opensc-pkcs11]
framework-pkcs15.c:3689:pkcs15_prkey_get_attribute:
pkcs15_prkey_get_attribute() called
P:16041; T:0x140368933964096 19:47:35.351 [opensc-pkcs11]
framework-pkcs15.c:3689:pkcs15_prkey_get_attribute:
pkcs15_prkey_get_attribute() called
P:16041; T:0x140368933964096 19:47:35.351 [opensc-pkcs11]
mechanism.c:251:sc_pkcs11_sign_init: called
P:16041; T:0x140368933964096 19:47:35.352 [opensc-pkcs11]
mechanism.c:256:sc_pkcs11_sign_init: mechanism 0xD, key-type 0x0
P:16041; T:0x140368933964096 19:47:35.352 [opensc-pkcs11]
mechanism.c:260:sc_pkcs11_sign_init: returning with: 112
P:16041; T:0x140368933964096 19:47:35.352 [opensc-pkcs11]
pkcs11-object.c:679:C_SignInit: C_SignInit() = CKR_MECHANISM_INVALID
P:16041; T:0x140368933964096 19:47:35.352 [opensc-pkcs11]
framework-pkcs15.c:3689:pkcs15_prkey_get_attribute:
pkcs15_prkey_get_attribute() called
P:16041; T:0x140368933964096 19:47:35.352 [opensc-pkcs11]
framework-pkcs15.c:3689:pkcs15_prkey_get_attribute:
pkcs15_prkey_get_attribute() called
P:16041; T:0x140368933964096 19:47:35.352 [opensc-pkcs11]
mechanism.c:251:sc_pkcs11_sign_init: called
P:16041; T:0x140368933964096 19:47:35.352 [opensc-pkcs11]
mechanism.c:256:sc_pkcs11_sign_init: mechanism 0x3, key-type 0x0
P:16041; T:0x140368933964096 19:47:35.353 [opensc-pkcs11]
mechanism.c:260:sc_pkcs11_sign_init: returning with: 112
P:16041; T:0x140368933964096 19:47:35.353 [opensc-pkcs11]
pkcs11-object.c:679:C_SignInit: C_SignInit() = CKR_MECHANISM_INVALID
Alltså, den försöker använda "mechanism 0xD" och sen "mechanism 0x3" och
sen ger den upp.
Det går att lista vilka mechanisms som ett smartkort har stöd för såhär:
p11tool --list-mechanisms $url
[0x0220] CKM_SHA_1 digest
[0x0255] CKM_SHA224 digest
[0x0250] CKM_SHA256 digest
[0x0260] CKM_SHA384 digest
[0x0270] CKM_SHA512 digest
[0x0210] CKM_MD5 digest
[0x0240] CKM_RIPEMD160 digest
[0x1210] CKM_GOSTR3411 digest
[0x0001] CKM_RSA_PKCS keysize range (2048, 2048) hw decrypt sign verify
[0x0006] CKM_SHA1_RSA_PKCS keysize range (2048, 2048) sign verify
[0x0046] CKM_SHA224_RSA_PKCS keysize range (2048, 2048) sign verify
[0x0040] CKM_SHA256_RSA_PKCS keysize range (2048, 2048) sign verify
[0x0041] CKM_SHA384_RSA_PKCS keysize range (2048, 2048) sign verify
[0x0042] CKM_SHA512_RSA_PKCS keysize range (2048, 2048) sign verify
[0x0005] CKM_MD5_RSA_PKCS keysize range (2048, 2048) sign verify
[0x0008] CKM_RIPEMD160_RSA_PKCS keysize range (2048, 2048) sign verify
[0x0000] CKM_RSA_PKCS_KEY_PAIR_GEN keysize range (2048, 2048)
generate_key_pair
Kollar samma sak "p11tool --list-mechanisms" for Nitrokey HSM:
p11tool --list-mechanisms $url2
[0x0220] CKM_SHA_1 digest
[0x0255] CKM_SHA224 digest
[0x0250] CKM_SHA256 digest
[0x0260] CKM_SHA384 digest
[0x0270] CKM_SHA512 digest
[0x0210] CKM_MD5 digest
[0x0240] CKM_RIPEMD160 digest
[0x1210] CKM_GOSTR3411 digest
[0x1041] CKM_ECDSA keysize range (192, 521) hw sign ec_f_p ec_namedcurve
ec_uncompress
[0x1042] CKM_ECDSA_SHA1 keysize range (192, 521) hw sign ec_f_p
ec_namedcurve ec_uncompress
[0x1051] CKM_ECDH1_COFACTOR_DERIVE keysize range (192, 521) hw derive
ec_f_p ec_namedcurve ec_uncompress
[0x1050] CKM_ECDH1_DERIVE keysize range (192, 521) hw derive ec_f_p
ec_namedcurve ec_uncompress
[0x1040] CKM_ECDSA_KEY_PAIR_GEN keysize range (192, 521) hw
generate_key_pair ec_f_p ec_namedcurve ec_uncompress
[0x0003] CKM_RSA_X_509 keysize range (1024, 4096) hw decrypt sign verify
[0x0001] CKM_RSA_PKCS keysize range (1024, 4096) hw decrypt sign verify
[0x0006] CKM_SHA1_RSA_PKCS keysize range (1024, 4096) sign verify
[0x0046] CKM_SHA224_RSA_PKCS keysize range (1024, 4096) sign verify
[0x0040] CKM_SHA256_RSA_PKCS keysize range (1024, 4096) sign verify
[0x0041] CKM_SHA384_RSA_PKCS keysize range (1024, 4096) sign verify
[0x0042] CKM_SHA512_RSA_PKCS keysize range (1024, 4096) sign verify
[0x0005] CKM_MD5_RSA_PKCS keysize range (1024, 4096) sign verify
[0x0008] CKM_RIPEMD160_RSA_PKCS keysize range (1024, 4096) sign verify
[0x000d] CKM_RSA_PKCS_PSS keysize range (1024, 4096) hw sign verify
[0x000e] CKM_SHA1_RSA_PKCS_PSS keysize range (1024, 4096) sign verify
[0x0047] CKM_SHA224_RSA_PKCS_PSS keysize range (1024, 4096) sign verify
[0x0043] CKM_SHA256_RSA_PKCS_PSS keysize range (1024, 4096) sign verify
[0x0044] CKM_SHA384_RSA_PKCS_PSS keysize range (1024, 4096) sign verify
[0x0045] CKM_SHA512_RSA_PKCS_PSS keysize range (1024, 4096) sign verify
[0x0000] CKM_RSA_PKCS_KEY_PAIR_GEN keysize range (1024, 4096)
generate_key_pair
Då ser man att för Nitrokey HSM finns både "mechanism 0xD" och sen
"mechanism 0x3"
[0x000d] CKM_RSA_PKCS_PSS keysize range (1024, 4096) hw sign verify
[0x0003] CKM_RSA_X_509 keysize range (1024, 4096) hw decrypt sign verify
Men för OpenPGP-kortet saknas de två.
Alltså:
mechanism 0xD
-->
[0x000d] CKM_RSA_PKCS_PSS keysize range (1024, 4096) hw sign verify
--> finns för nitrokey HSM
--> finns INTE för openpgp-kortet
mechanism 0x3
-->
[0x0003] CKM_RSA_X_509 keysize range (1024, 4096) hw decrypt sign verify
--> finns för nitrokey HSM
--> finns INTE för openpgp-kortet
Nar det gäller "mechanism 0xD" CKM_RSA_PKCS_PSS finns det liknande i
alla fall:
Det finns en som heter CKM_RSA_PKCS på openpgp-kortet:
[0x0001] CKM_RSA_PKCS keysize range (2048, 2048) hw decrypt sign verify
Funderingar:
Kan det gå att göra någon inställning (eller annan version av curl eller
SSL-bibliotek eller så) så att CKM_RSA_PKCS används istället för
CKM_RSA_PKCS_PSS (alltså att välja att använda det som stöds av
OpenPGP-kortet)?
Kan det vara så att någon annan variant av OpenPGP-kort (nyare version
kanske) skulle kunna ha stöd för någon av de "mechanisms" som verkar
behövas?
Tacksam för alla tips och idéer om hur man kommer vidare!
/ Elias
PS
Länkar till tidigare mejl om liknande saker:
https://mailman.dfri.se/mailman3/hyperkitty/list/eleg-projekt@lists.dfri.se…https://mailman.dfri.se/mailman3/hyperkitty/list/eleg-projekt@lists.dfri.se…https://mailman.dfri.se/mailman3/hyperkitty/list/eleg-projekt@lists.dfri.se…https://mailman.dfri.se/mailman3/hyperkitty/list/eleg-projekt@lists.dfri.se…
Hej!
Välkomna till distans-möte nummer 32 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 23 juni 2025 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:
- CA-programvara för utgivaren och test med nginx, status? Procedur för
att förnya utgivarens cert?
- OpenPGP-kort, testat mer
- Sätta upp server med revokeringslista, ordna domän och webbserver för det?
- Skriva debattartikel om robusthet apropå BankID-problemen nyligen?
- "Invitation: Participatory Requirements Workshop for eIDAS Oversight
Platform", se projektets mejllista
- "Remiss av Uppgiftsskyldighet för vissa e-legitimationsföretag":
https://www.regeringen.se/remisser/2025/04/remiss-av-uppgiftsskyldighet-for…
-- senaste dag att svara är den 8 juli.
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, och förslag på fler saker vi borde ta upp.
Välkomna!
Vänliga hälsningar
Projektets styrgrupp genom Elias
Som jag skrivit tidigare var jag med på en paneldiskussion i Stockholm
den 10 Juni:
https://info.knowit.se/automation_av_pki
Huvudfokuset var CA/Browser Forum's beslut att förkorta
websides-certifikats giltighetstid till 47 dagar, vilket ställer större
krav på automatiserad förnyelse av websides-certifikat.
---
Henrik Andersson från Abero Security berättade om de olika protokoll som
finns för automatisk certifkat-uppdatering;
* SCEP - Simple Certificate Enrollment Protocol
* CMP/EST - lite modernare variant av SCEP
* ACME - det nya som bl.a. Let's Encrypt använder
Körde ett live-demo av ACME med smallstep-ca som server och certbot som
klient.
ACME har en plugin-arktitektur där det jobbas på hårdvaru-tokens (TPM
och SecureEnclave) under namnet device-attest-01. Se acmeprotocol.dev
---
Sedan följde en session där vi skulle reflektera över om
certifikathanteringen var på väg att försvinna till förmån för
ssh-nycklar, wireguard och openpgp. Det gnälldes också över att
constraints i X.509 är kasst implementerat och krashar vissa mjukvaror,
samt att ingen slår på CRL (revokeringslistor).
---
Tomas Gustavsson tog sedan över och pratade om EJBCA och de olika
entiteterna som finns i ett komplett system:
* CA - Certification Authority
* RA - Registration Authrorty
* VA - Validation Authority
* TSA - Timestamp Authority
Kom in på post-quantum algorithmer och nämde att MLDSA är både vacker
matematiskt och godkänd enligt NIST.
---
Sedan följde mingel och folk var allmänt intresserade av vårt e-leg
användningsområde. En smartcard-expert vid namn Pål Ragnarson nämnde
massor av hårdvarutokens, där jag febrilt antecknade buzzwords som jag
tänkte kolla upp senare (inte hunnit än):
* Fortify: webb-baserad smartcard enrollment
* TPM: om man har problem ska man kolla att man slagit på "Enhanced TPM"
i BIOS
* Yubikey: använder PIV, har plats för 24 tokens, FIDO for enterprise
* Thales MD830 / MD940 använder pksc15.
* SafeNET Etoken
* secure channel - global platform keys
* signature creation device
* JCOB-kort med hemmaskriven Applet
---
Vidare har jag anmält mig till ett resiliance-hackaton
https://cillers.com/hackathons/couchbase-disaster-resilience-hackathon
och försöker få till att min grupp ska utveckla vårt e-id :)
Ses på online-mötet på måndag!
/ Christian
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/READM…
[3]
https://en.cryptoshop.com/products/smartcards/proprietary-solution-cards/op…
[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…
Hej!
Välkomna till distans-möte nummer 31 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 26 maj 2025 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:
- CA-programvara för utgivaren och test med nginx, status? Procedur för
att förnya utgivarens cert?
- Testat med "Nitrokey HSM", det fungerar, men "Nitrokey 3" funkar inte
- OpenPGP-kort, testat men inte fått det att fungera ännu
- Sätta upp server med revokeringslista, ordna domän och webbserver för det?
- Börja använda vårt system internt inom DFRI för medlemmar?
- Skriva debattartikel om robusthet apropå BankID-problemen nyligen?
- "Remiss av Uppgiftsskyldighet för vissa e-legitimationsföretag":
https://www.regeringen.se/remisser/2025/04/remiss-av-uppgiftsskyldighet-for…
-- senaste dag att svara är den 8 juli.
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, och förslag på fler saker vi borde ta upp.
Välkomna!
Vänliga hälsningar
Projektets styrgrupp genom Elias