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>
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
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
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
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
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