http://tools.ietf.org/html/draft-friedl-uta-smtp-mta-certs
I read the above quickly and few others, looked at postfix code ( https://github.com/vdukhovni/postfix/tree/master/postfix/src/tls ) quickly too, some other docs.... Some comments, questions: 1) it does not seem all implementations use the DNS tag in Subject Alternative Header, and only match the CN or DNS: with the hostname as per the MX connected to... The above draft brings some identifier selection and rules, but I don't know what are the rules today. RFC3207 remains vague: - A SMTP client would probably only want to authenticate an SMTP server whose server certificate has a domain name that is the domain name that the client thought it was connecting to. - A publicly-referenced SMTP server would probably want to accept any verifiable certificate from an SMTP client, and would possibly want to put distinguishing information about the certificate in the Received header of messages that were relayed or submitted from the client. Is it required per RFCs to now use the subjectAltName DNS: to do the matching instead of the CN if present? Is it an exact match? What should be the identifiers to match against? What is the RFC that specify it for SMTP? RFC3207 says only domain name should be used for the match, but implementations tend to use hostnames. 2) While the client will authenticate the server it connects to. It does not seem the server will authenticate the client, at best if there is a certificate it will record it. What identifier on the client side the server should use to identify the client? the hostname in the helo? The hostname from the rDNS of the connecting IP? What to do if there is no match? Reading, draft-friedl-uta-smtp-mta-certs I think it should not specify what are the identifiers in the certificate to be used, I think it is defined in the TLS RFCs (just reference to it), but it should just specify the identifiers on server and client side to do the match SMTP identifiers/certificate identifier. More I read about TLS and SMTP, more I get confused.... :P
_______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
