Re: Key lookup service via draft-bhjl-x509-srv-00

> I'm sorry, this makes no sense.  How is my MUA supposed to know about the
> key of someone from whom I have not yet received a message?  Based on
> the arguments I've seen, the main point of a key lookup service is to enable
> opportunistic encryption on the first message.

My MUA knows my key.  Your MUA knows your key.  All that's missing is a way to have my MUA talk to yours.  

Practically speaking, S/MIME MUAs already do this using the quintessential exchange of signed messages and automatic collection of certs when caching contact data.  However, this was never formalized into something that MUAs could actively provide; rather, it was left as a passive function.  GETSMIME was an attempt to make this active. 

> Also, your assertion that the cert repository is likely to be stale makes a
> bunch of assumptions that were reasonable in the 1990s but not now.
> For example, vast numbers of people primarily use web mail, so the MTA and
> MUA are the same, they're both attached to the web server, so the
> repository sees the same certs the users do. 

I'm hesitant to enable something as incredibly...naïve...as would give a convenient private key store for {insert your favorite Evil Agency here} to target to further their surveillance goals.  I take BCP 188 seriously, and the best way to address that threat model is to preserve the end-to-end guarantees of S/MIME.  You want S/MIME in webmail?  We need Web Crypto implemented in browsers.

Once you have Web Crypto, the private key store and the service provider are separate again, and the repository goes stale.

Also, since webmail service providers all allow fat clients (mobile mail apps are fat clients using a web API and are not fundamentally different from using a traditional mail client over POP3/IMAP4), in many (most?) use cases the client's key store is still separate from the provider, so the provider's repository still can and will go stale.

> And in domains that are authorities for their users, e.g., businesses that
> provide accounts to their employees, the domain's repository is accurate by
> definition, 

Bzzt.   Incorrect, but thank you for playing.   :)

Building and maintaining an enterprise PKI directory is actually very complex, not fully automatable, and is a right royal PITA.  For example, Outlook wants userSMIMECertificate and will ignore userCertificate in most cases, because userSMIMECertificate is a PKCS#7 object and contains the user's encryption capabilities.  However, you can't automatically generate the PKCS#7 object since it's signed and requires a user action.  So even if you have your CA publishing directly to AD, it's publishing userCert, and you have to *train your users* to drill down into Trust Center (3 to 4 clicks), re-set the S/MIME profile, and Publish to GAL *every time they get a new cert*.

Good luck with that.  :)

> and there's an argument that repository checks can detect some
> kinds of mail forgery.

An MUA using key continuity concepts can do this too.

-- T

_______________________________________________
smime mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/smime