On 4/19/19 7:10 PM, Wietse Venema wrote:
Michael Str?der:On 4/18/19 9:45 PM, Viktor Dukhovni wrote:On Apr 18, 2019, at 12:01 PM, Wietse Venema <wie...@porcupine.org> wrote:Eventually there will be a postfix-xxxx-nonprod release that combines all the code (jay) and none of the guarantees (bleh). I am not convinced that stuffing arbitrary PKI identities into a SASL identity is necessarily a good idea. Maybe it is safer to solve this problem without PKI-to-SASL cross-talk.I would expect the mapping to be indirect. That is, a table lookup key of either the client public key fingerprint to a SASL name (roughly what we have now, but with an explicit RHS indicating the desired SASL identity), or else the client's subject name in a standard (likely RFC2254) form, again mapped to the desired identity, provided the client certificate is from a trusted PKI issuer.Using a name instead of cert fingerprint also requires revocation checking.Cert revocation is not needed, as long as there is an an explicit mapping like: certificate identity -> permit/etc action certificate identity -> ersatz SASL login name By removing such a mapping, one can 'revoke' the privileges that were associated with the certificate.
If a cert's key get compromised (e.g. laptop lost/stolen) I expect the user's cert to be revoked and a new cert to be issued for the *same* subject name. How to deal with that without revocation check?
I think that people are asking for this feature because they just want to issue a new cert and *not* deal with any postfix map update.
Maybe I'm missing something though. Ciao, Michael.
smime.p7s
Description: S/MIME Cryptographic Signature
