Hi. I'm writing up a draft on mutual crypto binding. As such, I happened to glance at section 7.6 on server certificate validation.
The advice there is entirely inadequate for interoperable implementation and violates the tunnel method requirements: 1) . There's a SHOULD check the server name, but there are no mandatory-to-implement name forms. That is, I don't know how to map something the peer is likely to have such as the realm in a NAI to something that could be in a certificate. 2) Section 3.9 of the tunnel method requirements talks about certificateless authentication. this is incompatible with MUST verify server cert as well as the false claim that during TLS negotiation a server always sends a certificate to a client. I'd recommend resolving as follows: 1) Peers and servers MUST implement certificate modes of TLS; covered elsewhere in the doc. 2) Peers MUST implement and SHOULD validate server certs to a known trust anchor. 3) Pick a name form. Peers MUST implement validation of names against this name form. Describe where peers get the name to check against (obvious options include the NAI and separate configuration). 4) Peers SHOULD default to checking the name. 5) Describe other certificate properties such as keyusage, EKU, etc or point back to TLS if appropriate. 6) we probably need language dealing with the sort of stuff I'm writing up when some of these shoulds need to be upgraded. For example I think it's highly unadvisable to run channel bindings without checking the cert and binding back to a specific name or strong mutual crypto binding. _______________________________________________ Emu mailing list [email protected] https://www.ietf.org/mailman/listinfo/emu
