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
smime(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/smime