Attestation root certificates as PEM

[nickray]

We should supply the certs (currently in https://docs.solokeys.io/solo/metadata-statements/) as PEM for both secure and hacker, and PR to https://github.com/duo-labs/py_webauthn/tree/master/webauthn/trusted_attestation_roots

[justinmayer]

Some background information… Having long sought a well-built WebAuthn app for Django and deciding it was time to build one, I reviewed the excellent work @woodruffw and @brainwane did to add WebAuthn support to PyPI and recruited @Natim to collaborate on a Django app for WebAuthn and TOTP.

Like the PyPI project implementation, we also chose to utilize PyWebAuthn for the WebAuthn registration/verification bits. Unless I'm misunderstanding (which is entirely possible), it seems that PyWebAuthn relies upon the presence of trusted attestation root certificates. Being interested in utilizing SoloKeys for our testing, I asked the folks at SoloKeys the questions that inspired this issue:

[PyWebAuthn] has a directory for trusted attestation root certificates:

https://github.com/duo-labs/py_webauthn/tree/master/webauthn/trusted_attestation_roots

Currently, there is only a single certificate there (yubico_u2f_device_attestation_ca.pem). Do SoloKeys work with that bundled certificate? Or is another certificate required for SoloKeys? If we need to add another trusted attestation root certificate for SoloKeys, where would we find it?

In addition to graciously offering to submit a pull request adding PEM versions of SoloKeys' certificates to the PyWebAuthn project, the SoloKeys folks asked a follow-up question:

I'd like to remark it's unusual to check key enrollments against the certificate outside of enterprise use. Would be interested how you intend to use the cert if you care to share.

Since I don't understand this topic well enough to answer this latter question, I thought this might be a good opportunity to ask @futureimperfect, if time permits, to perhaps weigh in and clarify the reasons why.

What do you think, James? (Thoughts from others mentioned in this issue are of course also most welcome!)

[nickray]

Personal opinion time: Whitelisting attestation certs lets the service decide what is safe, disregarding certs lets the user decide. I'm in the OSI and not the FSF, but I do strongly think the user should have some say here :smiley_cat:

The general issue with whitelisting is that every vendor (e.g., us) has to get on every service's list. There's also the FIDO MDS (https://fidoalliance.org/metadata), which (again, personal opinion time) is kind of centralization attempt (alternatively, going down the DAA route, untested crypto: https://paragonie.com/blog/2018/08/security-concerns-surrounding-webauthn-don-t-implement-ecdaa-yet), and also a money grab, since it's not cheap to get on this MDS.

That said, this my opinion applies only outside of enterprise use. Inside the enterprise, it seems very reasonable to have a policy about which keys are allowed. Actually, there, the usual privacy-preserving goals of how FIDO is set up, wouldn't seem to apply. Personally, in the enterprise I'd read out the serial number of each key on each use and log that server side. Since this serial isn't part of the protocol, an alternative is to have a unique attestation certificate for each individual key, making the keys individually trackable.

</personal opinion time>

On a technical level, I'm not 100% sure what https://github.com/duo-labs/py_webauthn is doing (browsing the README). In https://github.com/duo-labs/py_webauthn/blame/master/README.rst#L61-L74 it seems whether to use (in https://webauthn.io/ terms) none, indirect or direct attestation is only applied to the response after the user generated a credential (the FIDO language is so strong as to call this "generated an assertion", implied meaning: assertion about the generated credential's origin, by the attestation key specified in an attestation cert). Whereas, the server has to pre-specify this in the options passed to navigator.credentials.create (discussion at top aside, we do do this on https://update.solokeys.com since we want to use the attestation cert to verify a "Secure Solo" is genuine: https://github.com/solokeys/solo-webupdate/blob/f41417fdfcdf258aa9b63b97ca7df2ae5b40baf2/js/main.js#L122).

The difference between "direct" and "none" does manifest itself in a UX difference, e.g. Firefox shows the following popup (which is trying to tell you that you're telling the server which key you are using):

[futureimperfect]

Hi @justinmayer and @nickray,

The reason I added the trusted_attestation_roots directory to PyWebAuthn is because I wanted it to be relatively easy for someone using the module to specify which authenticator vendors are permitted without having to worry about certificate chain validation and the like. @nickray is right about attestation being more appropriate in enterprise use-cases, and I think we'll see few consumer-oriented services requiring it due to user-experience and privacy-related concerns. It's worth noting, though, that PyWebAuthn supports Basic, Self, and None attestation types, so if you don't want to enable attestation, you can disable it when creating the WebAuthnRegistrationResponse object:

webauthn_registration_response = webauthn.WebAuthnRegistrationResponse(
    RP_ID,
    ORIGIN,
    registration_response,
    challenge,
    trust_anchor_dir,
    trusted_attestation_cert_required,  # Make this `False`
    self_attestation_permitted,
    none_attestation_permitted,
    uv_required=False)  # User Verification

Also, I'd be happy to accept a PR that adds the SoloKeys attestation CA certificate to the trusted_attestation_roots directory. The reason it only has the Yubico CA in there is because it's published online and was easy for me to add when I wrote the module. :)

Hope this helps!

[My1]

Personal opinion time: Whitelisting attestation certs lets the service decide what is safe, disregarding certs lets the user decide. I'm in the OSI and not the FSF, but I do strongly think the user should have some say here

totally agree, BUT: I think it might be valid to inform the user that the website could't verify the key as a common one either due to being anonymized, uncommon or homemade (U2F Zero FTW) and to have them confirm that there may be risks adding the key if they don't know what they are doing. but yeah unless we are talking some very specific cases like enterprise fun, there shouldn't be a hard lock on the certs

[nickray]

This you'll have to suggest either to FIDO, or in the worst case each individual website..

[My1]

obviously I know solo can't do anything, just giving my reason to support this issue to get the roots for solo in an easy to use format

[nickray]

The files in https://github.com/solokeys/solo/tree/master/metadata are what server side solutions need.

[My1]

almost. quote from top:

for both secure and hacker

[Natim]

@nickray do you have them in a PEM format or do you have a command that we can use to convert them into a PEM from the json file?

[nickray]

Currently I don't; server implementations expect the above format. Also hacker keys don't have an official cert.

[My1]

well the cert of my hacker key is at least signed by something else according to XCA (why not just self-sign, lol), and at least the webauthn thing I use spits out PEMs.

[Natim]

and at least the webauthn thing I use spits out PEMs.

I was going to say the same thing. The server implementation I use (webauthn) is expecting PEM files. We might be able to contribute the kind of format you are giving us but out of the box it is PEM files.

[Natim]

I just noticed that the PEM file is actually inside the metadata json file.

solokeys_u2f_device_attestation_ca.pem

Certificate:
    Data:
        Version: 1 (0x0)
        Serial Number:
            c4:47:63:92:8f:f4:be:8c
        Signature Algorithm: ecdsa-with-SHA256
        Issuer: C = US, ST = Maryland, O = Solo Keys, OU = Root CA, CN = solokeys.com, emailAddress = hello@solokeys.com
        Validity
            Not Before: Nov 11 12:51:42 2018 GMT
            Not After : Oct 29 12:51:42 2068 GMT
        Subject: C = US, ST = Maryland, O = Solo Keys, OU = Root CA, CN = solokeys.com, emailAddress = hello@solokeys.com
        Subject Public Key Info:
            Public Key Algorithm: id-ecPublicKey
                Public-Key: (256 bit)
                pub:
                    04:58:70:0d:d0:20:89:55:97:4c:b3:4a:24:b5:9e:
                    66:f7:7b:b1:98:1d:62:ca:af:04:2d:12:ed:a9:51:
                    4b:48:e8:87:40:46:9b:e7:aa:91:4c:1f:d0:ce:ba:
                    46:01:8f:be:63:69:b0:fa:f4:6e:40:c3:61:06:25:
                    34:2b:3c:23:06
                ASN1 OID: prime256v1
                NIST CURVE: P-256
    Signature Algorithm: ecdsa-with-SHA256
         30:45:02:21:00:cf:d4:a5:ac:05:c8:94:4b:bc:ee:fa:da:e7:
         8a:c8:08:fb:3e:e1:bd:2a:86:9d:cf:77:37:13:83:ba:ef:9c:
         fd:02:20:68:f1:ce:5b:5e:41:0c:7e:8d:01:9d:ee:bc:12:66:
         e1:39:45:65:0f:57:28:18:85:4b:2d:40:ef:73:35:43:ac
-----BEGIN CERTIFICATE-----
MIIB9DCCAZoCCQDER2OSj/S+jDAKBggqhkjOPQQDAjCBgDELMAkGA1UEBhMCVVMx
ETAPBgNVBAgMCE1hcnlsYW5kMRIwEAYDVQQKDAlTb2xvIEtleXMxEDAOBgNVBAsM
B1Jvb3QgQ0ExFTATBgNVBAMMDHNvbG9rZXlzLmNvbTEhMB8GCSqGSIb3DQEJARYS
aGVsbG9Ac29sb2tleXMuY29tMCAXDTE4MTExMTEyNTE0MloYDzIwNjgxMDI5MTI1
MTQyWjCBgDELMAkGA1UEBhMCVVMxETAPBgNVBAgMCE1hcnlsYW5kMRIwEAYDVQQK
DAlTb2xvIEtleXMxEDAOBgNVBAsMB1Jvb3QgQ0ExFTATBgNVBAMMDHNvbG9rZXlz
LmNvbTEhMB8GCSqGSIb3DQEJARYSaGVsbG9Ac29sb2tleXMuY29tMFkwEwYHKoZI
zj0CAQYIKoZIzj0DAQcDQgAEWHAN0CCJVZdMs0oktZ5m93uxmB1iyq8ELRLtqVFL
SOiHQEab56qRTB/QzrpGAY++Y2mw+vRuQMNhBiU0KzwjBjAKBggqhkjOPQQDAgNI
ADBFAiEAz9SlrAXIlEu87vra54rICPs+4b0qhp3PdzcTg7rvnP0CIGjxzlteQQx+
jQGd7rwSZuE5RWUPVygYhUstQO9zNUOs
-----END CERTIFICATE-----

[merlokk]

https://lapo.it/asn1js/ here you can check. looks like it must work

btw. it here) https://github.com/RfidResearchGroup/proxmark3/blob/master/client/fido/additional_ca.c