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

> * 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
[email protected]
https://www.ietf.org/mailman/listinfo/smime