On Tue, Oct 10, 2017 at 10:03:29PM +0100, Ivan Ristic wrote:
> I think dropping CNs altogether would bring this RFC in line with how PKI
> is used elsewhere and reduce complexities and opportunities for security
> issues without losing any functionality.
No objections to that, provided that CNs are in practice being
deprecated from HTTPS (which I would applaud).
> - The other thing I found unusual is that (unless I am reading it
> incorrectly), certificate validation is done in a kind-of round-about way:
> when connecting to an MX server, the certificate is considered valid if it
> matches any MX pattern from the policy. This is very unusual and requires a
> custom hostname matching algorithm.
See the list archives, this is deliberate. The idea is to not
override MX selection, and to support sites with UCC certifcates
where the identity is the receiving domain name and not the MX
host.
> I am afraid that this custom approach is dangerous and
> might contain hidden problems, but also that increases the amount of
> potentially tricky code that needs to be written.
OpenSSL already supports matching the peer certificate against any
of a list of reference identifiers. Perhaps other libraries will
add similar support.
--
Viktor.
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
