On Tue, Mar 06, 2012 at 06:19:59PM +0100, Robert Dahlem wrote:
> Default strategy for "verify": ask DNS about MX, then check if the
> servers CN matches. Check if the trust chain is valid.
Yes, though there is no promise of whether the name or the trust
chain is checked first. Both need to be acceptable.
> Default strategy for "secure": accept any CN presented by the server if
> that is the domain or a subdomain of the recipient address or the
> canonized hostname from the transport table. Do not add MX names looked
> up in DNS to the list of feasible CNs. Check if the trust chain is valid.
If the transport table specifies a nexthop, then, if I recall
correctly, it is used verbatim, I don't believe it is canonicalized
(nor canonized by the Catholic Church). As before the order of the
checks is implementation specific.
> Both can be overridden in tls_policy with the match attribute.
Once explicit match criteria are specified, the two levels become
indistinguishable, they apply the match criteria to the peer
certificate whose trust chain is verified in the same way at
either level.
--
Viktor.
