- Eleg-projekt

Försöker använda OpenPGP-kort, vad som funkar och inte funkar, hittills
by Elias Rudberg 24 Jun '25

24 Jun '25

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…

1 0

Välkomna på öppet möte nr 32 om att bygga egen e-leg-lösning, 23 juni klockan 18
by Elias Rudberg 22 Jun '25

22 Jun '25

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

1 0

Anteckningar från paneldiskussion om certifikat
by Christian Häggström 19 Jun '25

19 Jun '25

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

1 0

Taler och ID
by Mikael Odhage 09 Jun '25

09 Jun '25

Fann denna länk i min läsning apropå att Gnu Taler blivit myndigt: https://nlnet.nl/project/TALER-LookupService/ -- Vänliga hälsningar Mikael Odhage +46(0)709933651 Jabber/XMPP: odhagemikael(a)xabber.de Lite Fediversum: Friendica: https://libranet.de/profile/mikaelodhage/profile Bilder på: https://pixelfed.de/OdhageMikael Min publika nyckel hittas på hkp://keys.gnupg.net eller keys.gnupg.net

1 0

Fwd: [EDRi-members] Invitation: Participatory Requirements Workshop for eIDAS Oversight Platform
by Börje Ohlman 06 Jun '25

06 Jun '25

2 1

Sammanfattning av öppet möte 31 om att bygga egen e-leg-lösning, 26 maj 2025
by Elias Rudberg 27 May '25

27 May '25

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…

1 0

Välkomna på öppet möte nr 31 om att bygga egen e-leg-lösning, 26 maj klockan 18
by Elias Rudberg 26 May '25

26 May '25

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

2 1

Google FIDO säkerhetsnyckel 35kr
by Thomas Svensson 08 May '25

08 May '25

Vill bara tipsa om https://store.google.com/product/titan_security_key?hl=sv Passade på och köpte både USB-C och USB-A varianterna. 70 spänn och fraktfritt. Funkar de med vad vi jobbar på? /thomas @tsvenson <https://mastodon.online/@tsvenson>

3 3

Från Digg: Möjlighet att lämna synpunkter på genomförandeakter för EU:s digitala identitetsplånböcker
by Patrik Wallström 30 Apr '25

30 Apr '25

"Arbetet med genomförandeakterna för EU:s digitala identitetsplånböcker pågår för fullt. Nu finns möjligheten att lämna synpunkter på en ny omgång av förslag från EU-kommissionen. Synpunkter kan lämnas fram till den 13 maj 2025. https://www.digg.se/5.2ee6167319626c05540c66.html Du får det här mejlet eftersom du valt att prenumerera på nyheter från Digg. Vill du ändra eller avsluta din prenumeration? https://www.digg.se/om-oss/nyheter/mina-prenumerationer "

1 0

några tankar
by bengt.jonsson＠zetein.se 24 Apr '25

24 Apr '25

Det bästa är nog att så många som möjligt bara kort noterar "dåligheter" i förslaget, så att det finns en lista av synpunkter att sedan skriva på. Det finns ju gott om tid, och det går nog att hitta saker att reagera på redan efter en snabbtitt. Själv reagerar jag spontant på att de tycks förutsätta att e-leg skall ha en tredje part, tycker direkt verifiering utan inblandning av tredje part (förutom initialt) är att föredra. Det här förslaget tycks förutsätta en (övervakningsbar) tredje part och målar därmed in utvecklingen i ett hörn. Lägger också för kännedom in regeringens uppdrag till Polismyndigheten att utveckla statligt eID https://www.regeringen.se/regeringsuppdrag/2025/04/uppdrag-att-utfarda-en-s…

2 1

2025

2024

2023

2022

2021

Eleg-projekt