* Keep private the initial conversation
Peter's (I think it's his, at least he's the first person I heard it from)
GETSMIME concept achieves the same result.
Personally I prefer keeping discovery as a metaprotocol so only the MUA needs
to implement it independent of MTAs, recognizing that this trades off against
user convenience when the receiver is intermittently connected.
The plus is that the MUA *always* has the current key, whereas all repositories
get out of date quickly. We have extensive experience with this in the
DoD--expired userSMIMECertificate attributes in the Exchange GAL (effectively
an LDAP directory) are a constant problem. Keeping userCertificate attributes
sync'd with the CA publication directory is also a royal PITA.
Reduce the moving parts and the system will be more robust. Direct
client-to-client key discovery will be more accurate, more easily deployed, and
can be semi or fully automated.
* Certificate renewal upon expiry or similarly when revoked
No. Renewal is security sensitive, so automation is really not a great idea.
In certain niches--e.g., non-person autorenewal within an enterprise
authentication domain like Active Directory--it's acceptable, but for persons I
would recommend against it.
Revocation--in the commercial world and consumer PKI use case, anyway--is rare
enough to just ignore. Key continuity is a safer approach.
* Describe the allowed trust anchor (for verification which shouldn't be all
the time)
Why does the *cert repository* get to say who my CA is?
* Potentially handle email address name variants e.g. subaddressing,
capitalization
Too hard a problem to address external to the mail system, as we've seen.
OTOH, direct client-to-client discovery doesn't have this problem *at all*.
-- T
_______________________________________________
smime mailing list
smime(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/smime