nickray

Google's proposal for filtering: https://google.aip.dev/160

Specifically, https://google.aip.dev/assets/misc/ebnf-filtering.txt which is a modification of their common expression language https://github.com/google/cel-spec

How do you map KMU Konten to ledger accounts (can you rollup?), and do you automate VAT accounting?

Nonnegative always includes zero, unless the author had muddled thinking themselves. Since positive is >0 and negative is <0, their negations are nonpositive for <=0 and nonnegative for >=0.

I see your point too, and we're looking forward to a world in which low-power (to enable NFC) open source chips with security features exist. For instance, https://tropicsquare.com is a project that is working towards that.

For now, what we mean by open source hardware is on the one hand that all components are freely available (without NDAs, which nearly all secure elements entail), and on the other that the schematic of the device is open source and passes OSHWA Certification (the CERN license https://ohwr.org/project/cernohl/wikis/Documents/CERN-OHL-ve... is relevant here). This means that you can in principle build a device yourself. The certification will be done post-campaign (we want to avoid copycat products appearing before ours is available in the open market). Like we did with our three previous keys (e.g., https://certification.oshwa.org/us000155.html and https://github.com/solokeys/solo-hw).

Website can distinguish via the optional attestation key.

In terms of features, CTAP v2.1 (https://fidoalliance.org/specs/fido2/) is still draft only, but yes both v1 and v2 keys support hmac-secret and credential management. We could add authnSelection and authnConfig, but not clear if any browsers actually implement/use it.

The major new feature is PIV.

No, they cannot. This is an explicit design goal of FIDO (https://fidoalliance.org/specs/fido-security-requirements/fi...).

The actual public key used for logging in to a specific site is completely random.

Optionally, the website can ask for "attestation", which is intended to prove that the public key is from a specific vendor/model. To make this also unlinkable, devices are supposed to share attestation keys in batches of 100k units.

We hope and think that PIV can replace all the practical use cases for PGP. Specifically among those mentioned, `age` for file encryption, and either FIDO resident keys with hmac-secret for password managers, or something like `passage` (fork of `pass` using, again, `age` for encryption). For SSH you can use FIDO for newer OpenSSH, and either `pivy` or `yubikey-agent` via PIV. Cheers!

Anybody have an actual quote of Burnside's doubt? Article etc.

Keybase's "Crypto tools" tab can do this, with "known destination" determined via social proof.

https://keys.pub is a re-implementation of this use case without the messenger/cryptocurrency baggage that some dislike about Keybase.

First, that's a limitation of git.

Second, it's easy to fake PGP: https://boats.gitlab.io/blog/post/signing-commits-without-gp...

Third, we're adding support to SoloKeys to do this using a hardware token: https://github.com/solokeys/solo/issues/395#issuecomment-612...

We're also collaborating with https://keys.pub/ to make "sign/verify" use cases easily usable with a GUI for everyone. So I'd say there's hope?

As Stavros mentions, you can, and if you feel qualified, you should manage your own keys. Be that with some software authenticator you deem safe or write yourself, or with e.g. our keys that are open source, so you can modify anything to your liking, etc. etc.

I sense a bit of 90s security thinking from your arguments though, where every end user and mid-level admin handles security decisions they're frankly not qualified for.

This is what I meant by "safe defaults". Yes some people use e.g. password managers, but no, most people don't. Yes, some people manage to use GPG to manage their ssh keys, but no most people, even qualified, don't/can't/won't.

"Bad defaults with patches hopefully making it safe" is just not the way we should be heading.

Yes, WebAuthn is about getting rid of passwords. They're a bad idea, for most people, in most situations.

In FIDO-speak, "platform" authenticators are your laptop or phone, using their contained secure storage, vs "roaming" authnrs like our SoloKeys. Most people assume that the former will be the main way to use WebAuthn. Consumers using keys are mostly enthusiasts/early adopters/special needs.

Mainly in a corporate setting, a separate hardware key may provide a root of trust (and audit trail if the key is modified to be trackable) , with which you can then unlock your devices in a self-service manner.

You're right that software authnrs are a bad idea.

For services that don't want the security to be pierced by such unsafe fallbacks, initial key attestation can whitelist the acceptable authenticators.

One thing that is too infrequently highlighted is that FIDO2 is decentral authentication between you and the services, unlike "login with big-corp".

The point is that ssh keys lying around on your laptop aren't the greatest idea either. Where is the root of trust? The password you type to terminal if you encrypt them?

FIDO2 starts with the idea of safe defaults, where either client devices (Android, laptop TPM,...) store the keys safely, or dongle vendors (like us, SoloKeys). These have a business interest in doing their job properly.

But there's nothing preventing software implementations, it's an open standard in that respect (I do have other issues with it but your specific concern is unfounded imho).

SoloKeys person here ;) You can implement software authenticators (listening on local USB port), I imagine some password manager people will do so eventually, or have a direct way to hook into requests. Krypton did this for U2F.

Hardware keys are for if you want hardware security, obviously they can't be free unless you want someone with a different business model to subsidise them.

There's an ascending signature counter that's intended to prevent cloned devices (replay attacks are prevented seperately with server generated challenge). One way around it is clone (backup key) having very high initial signature counter set, so first use invalidates original (on loss). But yeah it's a UX problem that hopefully will find a better/non-hacky solution than "register multiple keys for each site".

As I'm currently working on possible options to expose on-device keys and cryptography for our open source FIDO2 key (SoloKeys) beyond the FIDO use case, I'd be curious about opinions on just exposing and using the PKCS#11 API (Cryptoki) [0] directly.

Envisioned setup would entail: download (custom) `libsolo-pk11.so`, generate RSA or ECDSA key on the USB key, get public key via `ssh-keygen -D libsolo-pk11.so`, use via `ssh -I libsolo-pk11.so [email protected]`.

The equivalent thing can be done for TPMs with simple-tpm-pk11 [1] today.

Technically, I'd extend the FIDO2 CTAPHID transport with "vendor commands" [2] mapping the basic Cryptoki API, and call that from the custom PKCS#11 shared library, which is then just a simple shim/wrapper. No additional drivers needed (everyone has HID).

Issues I can foresee: Users too attached to GPG workflow. Installation of custom shared library. No SSH support (via PKCS#11) for Ed25519 yet. SSH support for ECDSA only in about-to-be-released OpenSSH 8.0. Vanilla PuTTY on Windows has no PKCS#11 support. Bad rap of PKCS#11 due to existing vendors adding proprietary and closed source extensions. And the fact that SSH (currently) presents all keys to the host - I'd really like to be able to specify which key to use.

Personally, I'm a bit allergic to the GPG/PCSC/PIV/CCID way of doing things... My itch-to-scratch is just having a few keys off my computers (in particular, portable), and perform (infrequent) signatures on the separate device. And do this via a (comparatively) sane, open standard.

[0] http://docs.oasis-open.org/pkcs11/pkcs11-base/v2.40/os/pkcs1...

[1] https://github.com/ThomasHabets/simple-tpm-pk11

[2] https://fidoalliance.org/specs/fido-v2.0-rd-20180702/fido-cl...

You register more than one key, and use your backup. If the site lets you in without one of the keys you registered, it's a security theater :)

privacy.

https://login.swissid.ch does this too: disallow password managers from filling out the login. Upon asking them to fix: "Autofill completion is not allowed by us for security reasons. First, if that's the case, if someone gets to your PC, we can stop a hacking attempt and that's one of many reasons. For other questions, we are at your disposal."

They also only enforce SMS as two-factor authentication.

The idea of this SwissID is to become a nation-wide identity service, yet they manage to do everything wrong. Yeah, this annoys me to no end :(

Is there any English translation of the original? Would be curious to see the actual recipes!

It implements FIDO2: https://www.yubico.com/2018/05/what-is-fido2/

Should? That does mean: purchasing a bunch of tokens, each of which could be lost, and registering them all. I don't think online security has normative/prescriptive rules, just tradeoffs :)

Yes :) Personally, I would just start replacing credentials upon loss in descending order of importance.

I am considering adding this to my European distribution of U2F Zero, but the problem here is that as the vendor I then know your secret key. As mentioned in another comment, the uncloneability of Yubikeys is a feature (similar to Google Authenticator vs Authy).

Yes, the vast majority of users just worry about losing or breaking their U2F token. Such a user just wants to be able to log in and replace credentials. The proposed solution, which I find surprisingly elegant, in comparison to regular two tokens offers ease of use: avoiding registering a second token everywhere (and possibly the invalidation of the lost key at first login). Compared to the usual TOTP fallback, it keeps the phishing protection.

I think Johnny Neumann said it best: "There's no sense in being precise when you don't even know what you're talking about."

Regarding your second question, I suggest reading this classic article by Leslie Lamport: http://www.google.com/url?sa=t&rct=j&q=&esrc=s&#...