SMIME Support

[vaibhavb]

Any thoughts on what it would take to support S/MIME? Looking to adopt it for healthcare.

I guess adding support to X.509 certificates would be the missing part, rest of the pgp crypto would work.

[zQueal]

There has been massive interest in the community already for keybase to additionally serve as a keyserver using public keys uploaded by authenticated users. This would mean that simply configuring your email client like I did in the example would be possible, and would make sending crypto-compliant email very simple and we'd no longer need S/MIME support.

[bgpugh]

@Xanza: S/MIME (X.509) is pretty different from https://github.com/keybase/keybase-issues/issues/327

@vaibhavb: Were you looking for the ability to post S/MIME public certificates to keybase, or to have keybase issue certificates?

[emory]

my interpretation of the original request is that keybase manage not only gnupg keys but s/mime certificates -- the industry has broad adoption of s/mime in email software but the enrollment process and trust model is no better than gnupg.

eg iOS mail.app natively uses s/mime but not gnupg, and there isn't a graceful way to handle encrypted mail that isn't s/mime signed or encrypted -- and personally I think the current model of certificate mills are providing no value and are arguably less secure and trustworthy than self-signed certificates would be.

[emory]

(I would trust a keybase.io cert as much as a VERISIGN or Comodo cert if it were signed for a user based on the same Proofs currently used for gnupg keys)

[vaibhavb]

@dametenshi : Both would be great, but lets start with keybase supporting X.509 Certs.

@emory: Keybase can add a lot of value to PKI using Proofs. I'm particularly looking at healthcare where the X.509 Certs are being used to do secure communications between physicians and other health participants (via a technology suite called the Direct Project).

[bgpugh]

@emory But to use your example, iOS Mail would throw big scary warnings and red text if the user received a certificate signed by an unknown CA. Is walking through installing either a root cert or trusting each user's self-signed cert for every "track" something keybase wants to maintain?

Option A: Keybase creates a self-signed root certificate and as part of key generation issues S/MIME certificates for use with Outlook, Mail, Thunderbird, etc. This can be problematic because Keybase user Alice sends an email to non-Keybase user Bob and Bob is warned about not trusting the message because it might be an impersonator. Bob bails and is left with a negative feeling toward keybase (their email client told them not to trust it)

Option B: Keybase allows users to upload a copy of their S/MIME public certificate (Could be issued, could be self-signed. Doesn't matter. More similar to the GPG model in play already). When Bob does keybase track Alice this certificate is downloaded and the user is instructed how to mark it as trusted in their client of choice. This way you no users get scary warnings and marking someone as tracked denotes trust (as it does currently with GPG keys)

In the case of Option B, Alice may still be sending emails with a self-signed S/MIME certificate. There's nothing keybase can do about that, but it would mean that if you got a free S/MIME cert from VeriSign or Comodo, you could send "accepted" signed/encrypted emails and still use Keybase as an additional layer of trust on top of the traditional CA trust model.

[emory]

@emory But to use your example, iOS Mail would throw big scary warnings and red text if the user received a certificate signed by an unknown CA.

Yes, signing and trusting is something that would need to be figured out, but at present I don't think accepting a cert is outside the capabilities of a user of keybase.

Could also have a mobile app that negotiates and interacts with keystore? iCloud Keychain sync may be a way to ensure trust propagates for a user's devices? (I don't know capabilities of the relevant Apis.)

Option B:

Keybase allows users to upload a copy of their S/MIME public certificate (Could be issued, could be self-signed. Doesn't matter. More similar to the GPG model in play already).

I like this scenario better than the first. When Bob does keybase track Alice this certificate is downloaded and the user is instructed how to mark it as trusted in their client of choice. This way you no users get scary warnings and marking someone as tracked denotes trust (as it does currently with GPG keys)

But the trust isn't propagated is it? Are keybase follows now detached signatures that assert the identity? (I'm new, not busting balls) but it would mean that if you got a free S/MIME cert from VeriSign

good one ;) emails and still use Keybase as an additional layer of trust on top of the traditional CA trust model.

I like keybase as an Introducer. the public keyservers have been around for a long time and there is bad data there. either intentional or accidental, there are old keys that can't be revoked, etc. something like keybase is a great possible replacement for that method and an evolutionary step that needs to occur.

[bgpugh]

Are keybase follows now detached signatures that assert the identity? (I'm new, not busting balls)

AFAIK, because the root CA is the one who deigns total certificate trust, this is where the differences between S/MIME and GPG/OpenPGP rear their head. There is no concept of "signing with your own trust to vouch for others" with S/MIME. You either trust the root cert or your local trust database. In this scenario, "tracking" would be the equivalent of "locally signing" in GPG parlance. S/MIME has no mechanism to do web of trust.

[vaibhavb]

@dametenshi What would it take for KeyBase to serve X.509 Certificates, and perhaps have javascript binding to encrypt and decrypt these messages? I'm looking to do the following:

1. Upload a S/MIME certificate from Verisign, Verizon, Digicert etc. to keybase. Lets say >key-base add-cert [cert-name].[pfx|p12]
2. Use key-base api or have messages be encrypted or decrypted using these cert. >key-base -smime-cert encrypt [message.eml] or >key-base smime-cert decrypt [message.eml]. Note for decrpt the sender could be a non-keybase user and the cert resolution should follow SMIME PKI to decrypt it.

Thoughts? I'm willing to contribute.

[bgpugh]

@vaibhavb That sounds much more like the Option B I outlined above. GPG already has native S/MIME support, so the command-line client should be able to adopt it fairly easily, but I'm not so sure about the javascript/web client. @maxtaco and/or @malgorithms would be better posed to answer that question.

I should also note that I can't vouch for the regulations or requirements of the healthcare industry nor comment on keybase's adherence to such. That's really a whole 'nother ball of wax and I am not affiliated with keybase nor providing legal counsel. (← That's what we call C.O.A. 😜)

[olea]

I see as a pretty obvious next step to add support for X509 keys too. At least for publishing the public keys.

[vjeantet]

any update ?

[ghost]

+1

[FroehlichMarcel]

+1

[cjemorton]

Any new thoughts on this ?

[chrstphrbrns]

This would be valuable ✅

What I want is a certificate that is cryptographically linked to a Keybase identity, so if Keybase is as successful as it hopes to be in establishing identity trust, the certificate derives its value from that. Who needs a CA in that case?

[shioyama]

+1

[markwhiting]

+1

[virtugon]

+1

[FranklinYu]

Related Reddit post

[celi28]

+1