{"id":26600472,"url":"https://github.com/sftcd/sasl-passkeys-testing","last_synced_at":"2025-03-23T18:19:51.259Z","repository":{"id":281948986,"uuid":"946978778","full_name":"sftcd/SASL-passkeys-testing","owner":"sftcd","description":"A re-usable setup for testing SASL passkeys stuff","archived":false,"fork":false,"pushed_at":"2025-03-12T01:06:37.000Z","size":7,"stargazers_count":0,"open_issues_count":0,"forks_count":0,"subscribers_count":1,"default_branch":"main","last_synced_at":"2025-03-12T02:23:42.801Z","etag":null,"topics":[],"latest_commit_sha":null,"homepage":null,"language":null,"has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"mit","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/sftcd.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2025-03-12T01:05:48.000Z","updated_at":"2025-03-12T01:06:40.000Z","dependencies_parsed_at":"2025-03-12T02:23:44.437Z","dependency_job_id":"23a25ead-e9c9-43ad-827e-bda082896db4","html_url":"https://github.com/sftcd/SASL-passkeys-testing","commit_stats":null,"previous_names":["sftcd/sasl-passkeys-testing"],"tags_count":0,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/sftcd%2FSASL-passkeys-testing","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/sftcd%2FSASL-passkeys-testing/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/sftcd%2FSASL-passkeys-testing/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/sftcd%2FSASL-passkeys-testing/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/sftcd","download_url":"https://codeload.github.com/sftcd/SASL-passkeys-testing/tar.gz/refs/heads/main","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":245145234,"owners_count":20568094,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":[],"created_at":"2025-03-23T18:19:50.560Z","updated_at":"2025-03-23T18:19:51.225Z","avatar_url":"https://github.com/sftcd.png","language":null,"funding_links":[],"categories":[],"sub_categories":[],"readme":"\n# Setting up a test setup for SASL/passkeys\n\nstephen.farrell@cs.tcd.ie, 2025-03-13\nwork-in-progress\n\nAs part of the work on\n[SASL Remember Me](https://datatracker.ietf.org/doc/draft-ietf-kitten-sasl-rememberme/)\nand [SASL Passkey](https://datatracker.ietf.org/doc/draft-bucksch-sasl-passkey/),\nI wanted to setup a test environment that wouldn't interere with my daily-driver\ndesktop (Ubuntu 24.04), and that allows me to play with an old(ish) yubikey 4 nano\nI had lying about, (firmware version 4.3.3), and some new solokeys and yubikey\n5's I recently acquired, so the plan was/is:\n\n- setup a guest VM also running Ubuntu 24.04 with graphics (DONE)\n- figure out how to access the yubikey/solokey from the guest (DONE)\n- do some basic tests to see if passkeys demos work there (DONE)\n- setup a test mail setup on the guest (DONE)\n- figure out how to integrate passkeys and rememberme into the mail test setup\n- evolve that as the Internet-drafts mature\n\nA goal is for this to be replicable so that others can re-use or come up with\nvariants. There seem to be many and varied ways in which passkeys/webauthn can\nbe used and I'm sure they'll have different wrinkles, so for this to be useful,\nit'll need to be reusable by others. (Hence all the details:-)\n\n## Guest VM creation:\n\nI've used [`debvm`](https://manpages.ubuntu.com/manpages/noble/man1/debvm-create.1.html)\nfor setting up and running the guest VM. That ultimately runs [`qemu`](https://www.qemu.org/).\n\n```bash\n$ debvm-create --size=20G --release=noble --output ubuntu.ext4 -- --components=main,universe --include=e2fsprogs --hook-dir=/usr/share/mmdebstrap/hooks/useradd --aptopt='Apt::Install-Recommends \"true\"' --include=linux-image-generic,task-gnome-desktop\n```\n\nThe 20GB disk is needed, I started with 10G but quickly hit 90% with this\nsetup.  Creating the VM takes maybe 5-10 minutes. You can also make the\ndisk bigger though if needed:\n\n```bash\n$ e2fsck -f \n$ resize2fs ubuntu.ext4 20G\nresize2fs 1.47.0 (5-Feb-2023)\nResizing the filesystem on ubuntu.ext4 to 20971520 (1k) blocks.\nThe filesystem on ubuntu.ext4 is now 20971520 (1k) blocks long.\n$ \n```\n\n## Yubikey/Solokey on host\n\nWhen I insert a yubikey/solokey, I need to pass on USB details to the guest OS\nand to do that we need to know the bus and device/hostaddr, so, e.g.:\n\n```bash\n$ lsusb\n...\nBus 001 Device 004: ID 1050:0407 Yubico.com Yubikey 4/5 OTP+U2F+CCID\n...\n```\n\nI have to be careful where the mouse focus is when near the Yubikey 4 nano as\ntouching it, either in passing or when pulling it from the USB socket generates\nsome garbage looking text on (I guess) stdin - in one case that deleted a\nmessage from my mail client:-) That doesn't seem to happen with the solokey.\n\nExtracting the yubikey/solokey with this setup seems to require rebooting the\nguest VM to allow it see the device again.\n\n## Running the guest\n\nI could have done more package installs and added an SSH public key during VM\ncreation but didn't. So I initially booted the VM then installed a bunch of the\nusual dev packages, chromium-browser and an openssh-server via:\n\n```bash\n$ debvm-run -g -i ubuntu.ext4 -- -m 16G\n```\n\nThat has a wrinkle - the mouse pointer is offset in the guest when the guest OS\nwindow is displayed on my highish-res laptop screen, but works fine when I move\nthe window to a secondary screen connected via HDMI. After much mucking about,\nit turns out adding the following seems to fix this:\n\n```bash\n    -vga none -device virtio-vga-gl -display sdl,gl=on \n```\n\nAfter basic packages are installed and the SSH server is running I'm currently\nstarting the guest VM via, e.g.:\n\n```bash\n$ debvm-run -g -s 2222 -i ubuntu.ext4 -- -m 16G -usb -device usb-host,hostbus=1,hostaddr=4\n```\n\nThe USB details above allow the guest to access the yubikey/solokey. Note that\nthose will change as you (dis/re)connect USB devices so you'd have to check\n`lsusb` for the `Bus/hostbus` and `Device/hostaddr` before each boot. As those\nvalues change, I wrote the [`bootvm.sh`](./bootvm.sh) script to grab 'em and\npass 'em on to the guest:\n\nThen I can login as `user` via the graphics window, or SSH in via:\n\n```bash\n$ ssh -o NoHostAuthenticationForLocalhost=yes -p 2222  user@127.0.0.1\n```\n\n## Trying out passkeys in browsers\n\nI next followed the instructions\n[here](https://support.yubico.com/hc/en-us/articles/360016649039-Installing-Yubico-Software-on-Linux)\nto install the required Yubikey s/w in the guest OS. I took the option to\ndownload the `Yubikey authenticator` from the vendor's site rather than take\nthe distro's package.  (Since this is experimental stuff, maybe better to be\ncloser to bleeding edge.)\n\nNext step was to try a passkeys [test site](https://webauthn.io/profile) in the\nguest OS.  I registered (the site says it scrubs accounts after 24 hours), and\nlogged into a test account using chromium, which worked fine with the expected\n\"touch the device\" interactions. I then confirmed that I could login to the\nsame account via firefox, again with the expected \"touch the device\"\ninteraction.  I also checked that authenticating via firefox after a guest\nreboot worked too which is nice.\n\nOn a 2nd (old) laptop, also running Ubuntu 24.04, I tried to authenticate with\nthe same account (moving the Yubikey) and it also worked. On that machine,\nbefore installing the Yubikey authenticator, I also had to add a new smartcard\nhandling package:\n\n```bash\n$ sudo apt install pcscd\n```\n\nSo... so far so good!\n\nWith the yubikey 5 (firmware 5.7.1), the yubikey authenticator has a better\nuser inferface - you can see and manage the passkeys (up to 100 allowed on the\ndevice I'm using). The yubikey 5 also seems to require a PIN before our\n`mech_u2f.py` script will work. That can be set via the yubikey authenticator.\n(And maybe also when accessing the passkey demo site, but didn't test that.)\n\n## Solokeys in browser\n\nAs it's always better to not be dependent on one vendor, I acquired a few\n[SoloKeys](https://solokeys.com) that also claim to be passkeys compatible.\nBottom line: turns out that's true, for our scenario, which is nice!\n\nSolokeys are [open-source](https://github.com/solokeys) which is great, but the\nrepos don't seem to be active, which is less good. It could be that the\ndevelopers are focussing more on a \"next gen\" thing\n(called [trussed](https://github.com/trussed-dev)) that's also intended to work with\n[nitrokeys](https://www.nitrokey.com/), but \"trussed\" doesn't seem to have matured\njust yet, hard to tell.\n\nWhen I tried to use our python `mech_u2f.py register` before having set\na PIN I got an exception (trace [here](./solo-no-pin-except.md) in\ncase that's useful later).\n\nThe SoloKey device (or something;-) insisted on setting a PIN the first time I\ntried it out via a browser (with the usual\n[test site](https://webauthn.io/profile)).  After that, our `mech_u2f.py` script\nworks fine for registration and authentication with the device, prompting for\nPIN entry and then to touch the authenticator.\n\nThere is a command line tool for SoloKeys, that first needs the\nrust environment installed, then the tool itself. The online\ndocumentation (that I found) wasn't quite correct but what worked\nfor me is below:\n\n```bash\n$ curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh\n...\n$ sudo apt install libusb-dev libudev-dev libpcsclite-dev\n$ . $HOME/.cargo/env\n$ cargo init\n$ cargo install solo2\n```\n\nThat all seems to work, though the `solo2` tool doesn't do so much\nthat's useful for my purposes, e.g. I've yet to find a way to unset\nthe PIN.\n\n## DNS and PKI\n \nI needed a DNS name for the guest VM so I used `pk.jell.ie` (`jell.ie` is a\nvanity domain I control) and added that to `/etc/hosts` in the guest with\na localhost IP. I also needed a fake CA that mail and web clients can believe.\n\nFrom another project I used a bash script\n[`make-example-ca.sh`](https://github.com/defo-project/ech-dev-utils/blob/main/scripts/make-example-ca.sh)\nthat creates a fake CA and (wild-card) certificates for `example.com`.\nModifying that to replace `example.com` with `pk.jell.ie` is obvious enough and\nonce run I ended up with:\n\n-  `$HOME/cadir/pk.jell.ie.pem` containing our wildcard cert\n-  `$HOME/cadir/pk.jell.ie.priv` containing our private key\n-  `$HOME/cadir/oe.csr` containing our fake CA public key \n\nAs needed, I copied those certificate/key files into dovecot and nginx\nconfigurations and installed the CA public key in firefox and thunderbird.\n\n## Dovecot\n\nI'll likely need a modified version of dovecot at some point so forked \nthat, and since I'm used to it and it might be handy, I also did a local\nbuild of openssl for the fun too, in the guest:\n\n```bash\n$ sudo apt install gettext bison flex libtool-bin pkgconf\n$ cd $HOME/code\n$ mkdir defo-project-org\n$ cd defo-project-org\n$ git clone https://github.com/defo-project/openssl\n$ cd openssl\n$ ./config --libdir=lib --prefix=$HOME/code/openssl-local-inst\n$ make -j8\n$ make install_sw\n$ mdkir $HOME/code/dovecot\n$ cd $HOME/code/dovecot\n$ git clone https://github.com/sftcd/core.git\n$ sudo apt install libpam0g-dev # needed for the --with-pam below\n$ cd core\n$ ./autogen.sh\n$ export LD_LIBRARY_PATH=$HOME/code/openssl-local-inst/lib\n$  EXTRA_CFLAGS=-O0 CPPFLAGS=-I$HOME/code/openssl-local-inst/include LDFLAGS=-L$HOME/code/openssl-local-inst/lib ./configure --enable-maintainer-mode --prefix=/usr/local/dovecot --with-pam\n$ make -j8\n```\n\nThe dovecot build is somewhat odd - it sometimes fails but then succeeds on a 2nd\nattempt. Haven't investigated, but the error seems to be some test checking\nonline for something thing, so we'll see.\n\nAlso worth noting are some\n[debugging tips](https://doc.dovecot.org/2.3/developer_manual/development_tips/debugging_tips/).\n\n## A simplified postfix/dovecot/thunderbird setup\n\nNext I installed a simple postfix/dovecot setup on the guest with postfix,\ndovecot-imapd, dovecot-lmtpd and thunderbird.  Getting that all working in the\nguest was finickkity, but copying from other setups eventually worked.  That\nsetup can send mail externally or to itself, and thunderbird can do IMAP\noperations, so I should be able to play with SASL autentication for submission\nand IMAP operations.\n\nThe postfix `main.cf` config things I changed are below\n(I think;-):\n\n```bash\nmydestination = pk.jell.ie, $myhostname, localhost, localhost.localdomain, localhost\nmyhostname = pk.jell.ie\nmynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128\nsmtpd_sasl_type = dovecot\nsmtpd_tls_cert_file = /etc/dovecot/private/pk.jell.ie.pem\nsmtpd_tls_key_file = /etc/dovecot/private/pk.jell.ie.priv\nvirtual_transport = lmtp:unix:private/dovecot-lmtp\n```\n\nAnd (I think, again;-) the only change in `master.cf` was the addition of:\n\n```bash\nsubmission inet  n       -       -       -       -       smtpd\n    -o syslog_name=postfix/submission -o smtpd_tls_security_level=encrypt\n    -o smtpd_sasl_auth_enable=yes -o smtpd_sasl_type=dovecot\n    -o smtpd_sasl_path=private/auth -o smtpd_sasl_security_options=noanonymous\n    -o smtpd_sasl_local_domain= -o smtpd_client_restrictions=permit_sasl_authenticated,reject\n    -o smtpd_recipient_restrictions=reject_non_fqdn_recipient,reject_unknown_recipient_domain,permit_sasl_authenticated,reject\n    -o smtpd_relay_restrictions=permit_sasl_authenticated,rejec\n```\n\n## Installing the local dovecot build \n\nIt's not sure if first using the disto's version of dovecot is a good plan, but\nthat's what I did:-) Next was to replace that with the locally built dovecot.\nThe bleeding-edge config files were a little different from the distros.\n\n```bash\n$ cd $HOME/code/dovecot/core\n$ sudo make install\n...\n```\n\nEach time one does that you zap some files that systemd needs to run the\ndistro's dovecot so going back and forth seems to be non-trivial, but hopefully\nI won't need to.\n\nMy dovecot config is then:\n\n```bash\n$ dovecot/sbin/dovecot -n\n# 0.0.0-35009+61e3708fb5 (b153621271): /usr/local/dovecot/etc/dovecot/dovecot.conf\n# OS: Linux 6.8.0-55-generic x86_64 Ubuntu 24.04.2 LTS \n# Hostname: localhost\n# 4 default setting changes since version 0.0.0\ndovecot_config_version = 0.0.0\ndovecot_storage_version = 2.3.0\nmail_driver = sdbox\nmail_gid = mail\nmail_path = ~/mail\nmail_uid = mail\nprotocols = imap lmtp\nrecipient_delimiter = +_\nssl = required\nservice auth {\n  unix_listener /var/spool/postfix/private/auth {\n    group = postfix\n    mode = 0660\n    user = postfix\n  }\n}\nservice lmtp {\n  user = mail\n  unix_listener /var/spool/postfix/private/dovecot-lmtp {\n    group = postfix\n    mode = 0600\n    user = postfix\n  }\n}\nprotocol lmtp {\n  postmaster_address = user@pk.jell.ie\n}\ndict dict {\n}\npassdb pdb {\n  driver = pam\n}\nuserdb udb {\n  driver = passwd\n}\nssl_server {\n  cert_file = /etc/dovecot/private/pk.jell.ie.pem\n  key_file = /etc/dovecot/private/pk.jell.ie.priv\n}\n```\n\nNote that the dovecot upstream seems to change fairly rapidly, e.g. the \nname of the config entries for the TLS files changed between the first\nand second commits to this repo. I figured out the new names by moving\n`/usr/local/dovevot` aside, then doing another `make install` with \nthe latest upstream, which allowed me to see what was now expected to\nbe in `/usr/local/dovecot/etc/dovecot/dovecot.conf`. Not sure if\ndoing that'll be a common thing or exceptional.\n\nWith the above setup, mail content is stored in `$HOME/mail/mailboxes/`\nin I'm not sure what format - not mbox or Maildir anyway, presumably\nsomething more modern.\n\n## A PoC dovecot passkeys mechanism\n\nAki Tuomi (impressively quickly) did up a\n[PoC implementation](https://github.com/cmouse/dovecot-mech-passkey/)\nof the passkeys authentication method for dovecot, so trying that\nmade sense.\n\n## Python client test\n\nI can use a bit of python in Aki's repo as a test, the\nexample below uses a solokey (with a PIN) rather than the\nyubikey (without a PIN) but both work:\n\n```bash\n$ python mech_u2f.py register\nDEBUG:PASSKEYAuthenticator:Use USB HID channel.\nCtapHidDevice('/dev/hidraw0')\nDEBUG:PASSKEYAuthenticator:Use USB HID channel.\nCtapHidDevice('/dev/hidraw0')\nDEBUG:fido2.server:Fido2Server initialized for RP: PublicKeyCredentialRpEntity(name='Example RP', id='imap.example.com')\nDEBUG:fido2.server:Starting new registration, existing credentials: \nDEBUG:fido2.client:Register a new credential for RP ID: imap.example.com\nEnter PIN: \nDEBUG:fido2.ctap2.pin:Got PIN token for permissions: None\nDEBUG:fido2.ctap2.base:Calling CTAP2 make_credential\nDEBUG:fido2.hid:Got keepalive status: 01\nDEBUG:fido2.hid:Got keepalive status: 02\n\nTouch your authenticator device now...\n\nDEBUG:fido2.hid:Got keepalive status: 01\nDEBUG:fido2.hid:Got keepalive status: 01\nDEBUG:fido2.hid:Got keepalive status: 01\nDEBUG:fido2.hid:Got keepalive status: 01\nDEBUG:fido2.hid:Got keepalive status: 01\nDEBUG:fido2.server:Verifying attestation of type packed\nINFO:fido2.server:New credential registered: a300589ee0f0b3c58410d3c4058a4589171f5564949ea5d6693452d67142f01315cdaea3f18381ccbbafcf20c23aa29d866b061509aba7d16937b1bff3a3561a4f1f6f21847edfeeb9e987aaab8dc04559b4ba3c22fe644d52a276fa28ae328de3447b8ddfea942e9487e168dc2f70d121a5ca2dc9d8dd5d4a3d0d9534d9f9aedefd36c1e7683fef4ba8e5818c55bbcab87439dfa916339ff67c8d4b99252a4f8a79014cf37608acbb9b1d0cd19c4fb902502f75ea123e6f1c7c026c833275f1bad4\n{PASSKEY}i8VJaAexTV+ySWB/XVJ9ogDCowBYnuDws8WEENPEBYpFiRcfVWSUnqXWaTRS1nFC8BMVza6j8YOBzLuvzyDCOqKdhmsGFQmrp9FpN7G/86NWGk8fbyGEft/uuemHqquNwEVZtLo8Iv5kTVKidvoorjKN40R7jd/qlC6Uh+Fo3C9w0SGlyi3J2N1dSj0NlTTZ+a7e/TbB52g/70uo5YGMVbvKuHQ536kWM5/2fI1LmSUqT4p5AUzzdgisu5sdDNGcT7kCUC916hI+bxx8AmyDMnXxutSkAQEDJyAGIVggI7w2IZUEQDsDFSVvlro1HazmOkc7YFV3HQtrzWf07W8=\nuser@pk:~/code/dovecot/dovecot-mech-passkey$ python mech_u2f.py auth {PASSKEY}i8VJaAexTV+ySWB/XVJ9ogDCowBYnuDws8WEENPEBYpFiRcfVWSUnqXWaTRS1nFC8BMVza6j8YOBzLuvzyDCOqKdhmsGFQmrp9FpN7G/86NWGk8fbyGEft/uuemHqquNwEVZtLo8Iv5kTVKidvoorjKN40R7jd/qlC6Uh+Fo3C9w0SGlyi3J2N1dSj0NlTTZ+a7e/TbB52g/70uo5YGMVbvKuHQ536kWM5/2fI1LmSUqT4p5AUzzdgisu5sdDNGcT7kCUC916hI+bxx8AmyDMnXxutSkAQEDJyAGIVggI7w2IZUEQDsDFSVvlro1HazmOkc7YFV3HQtrzWf07W8=\nCtapHidDevice('/dev/hidraw0')\nEnter PIN: \n\nTouch your authenticator device now...\n\nAuthentication finished\n\n```\n\nThe registration output (`{PASSKEY}...`) can be saved as a credential\nand used in a test with the PoC code.\n\n## Building the PoC\n\n```bash\n$ sudo apt install libfido2-dev libcbor-dev\n$ cd $HOME/code/dovecot\n$ git clone https://github.com/cmouse/dovecot-mech-passkey/\n$ cd dovecot-mech-passkey\n$ ./autogen.sh\n$ ./configure  --with-dovecot=../core\n$ make -j12\n...currently some warnings but builds...\n```\n\nThen we can pass in the credential produced by `mech_u2f.py` and see\nhow that goes. Currently, it looks ok for the yubikey but we get an\nerror for the solokey that looks like an algorithm mis-match maybe.\n\n```\n$ ./src/test ~/cred-yubi4 \nDebug: got guid 00000000-0000-0000-0000-000000000000\nDebug: cred size = 64, size = 143\nDebug: Got credential id 33a280212144cdeef03fca17892f5f7f5a5a87e8be9478220a3b7b748bd654d23473ff671db8549c77b45ec552a8636bc6d11ec77ae397911878d005830125be\nDebug: item is 5\nDebug: key is 1\nDebug: Key type = 2\nDebug: item is 5\nDebug: key is 3\nDebug: algorithm = -7\nDebug: item is 5\nDebug: key is -1\nDebug: curve = 1\nDebug: item is 5\nDebug: key is -2\nDebug: x = 32 bytes\nDebug: item is 5\nDebug: key is -3\nDebug: y = 32 bytes\nDebug: R: a564727049646b6578616d706c652e636f6d696368616c6c656e676558203fd8753eb1003843287ee8ef84646982a2e07e8bf248c6850e8830caae8702796774696d656f75741b000000000000ea6070616c6c6f7743726564656e7469616c7381a2626964584033a280212144cdeef03fca17892f5f7f5a5a87e8be9478220a3b7b748bd654d23473ff671db8549c77b45ec552a8636bc6d11ec77ae397911878d005830125be64747970656a7075626c69632d6b65797075736572566572696669636174696f6e687265717569726564\nmech passkey ......................................................... : ok\n0 / 1 tests failed\n$ ./src/test ~/cred-solo \nDebug: got guid 8bc54968-07b1-4d5f-b249-607f5d527da2\nDebug: cred size = 194, size = 238\nDebug: Got credential id a300589e0585c5e1d938355fb006ae2feacd37832493b6950f0aaed6d57719496a477b528b2b2c9be38ae743c6933223ca7fec4b276ed8ab6482d242cfa3edaac1f1304723997442d7a75fef01f9dd0054b62e4187df4c98ea0f92d2882d935ee12fa106c3e33b33dcbac8df0b48216bfb35e487a4a761bdcedbd2eac68801d0193ad78e261067fd40e37783cf6fdb0d6733fa879303aadb683ed1f2dbb263c19ec5014c7fadcc4a74eb4eb47a15cc9f0250e5a1c986e1c5f4376b5432a7631b5418\nDebug: item is 5\nDebug: key is 1\nDebug: Key type = 1\nDebug: item is 5\nDebug: key is 3\nDebug: algorithm = -8\nDebug: item is 5\nDebug: key is -1\nDebug: curve = 6\nDebug: item is 5\nDebug: key is -2\nDebug: x = 32 bytes\nDebug: error:08000066:elliptic curve routines::invalid encoding\nDebug: R: \nmech passkey ......................................................... : ok\n0 / 1 tests failed\n```\n\nThe yubikey 5 seems to use the same algorithms as the yubikey 4 as\nshown above. \n\nIt looks like the `algorithm` is the difference here - `-7` is the\n[CBOR code point](https://www.iana.org/assignments/cose/cose.xhtml)\nfor ES256 (or ECDSA with SHA-256), and `1` means NIST P256 for the curve,\nwhereas `-8` is the CBOR code point for EdDSA, with `6` meaning ed25519 for the\ncurve, so I guess the solokeys is using the latter and that's either not\nsupported or configured in our dovecot build.\n\nI don't see a way to change algorithm/curve preferences (so far) with either\nyubikeys or solokeys.\n\n## A local passkeys registration site/relying party \n\nI'll want some more complex registration scheme so will need a web server\nthat does that. \n\nTo start I need an nginx and to make that work with a (guest VM) browser for\nhttps, based on my DNS/PKI setup, that means uncommenting the port 443 server\nlines and adding the `pk.jell.ie` cert and private key ending up with the\nfollowing lines in the `server` stanzas of `/etc/nginx/sites-enabled/default`:\n\n```bash\n        listen 443 ssl default_server;\n        listen [::]:443 ssl default_server;\n        ssl_certificate /etc/nginx/pk.jell.ie.pem;\n        ssl_certificate_key /etc/nginx/pk.jell.ie.priv;\n```\n\nI've yet to get a passkeys reg/auth setup working with that nginx instance.\n\n## State of play\n\nAnd that's where I'm at (as of 2025-03-13). Things to do in future are:\n\n- get the local nginx setup working for passkeys registration/auth\n- probably get some simple command line demo of the passkeys auth with dovecot\n- hack thunderbird to do the same (or some of it, or choose an easier IMAP\n  capable MUA, maybe)\n\n\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fsftcd%2Fsasl-passkeys-testing","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fsftcd%2Fsasl-passkeys-testing","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fsftcd%2Fsasl-passkeys-testing/lists"}