The primary issue is where to find the tlsa. For oob, it will have to be based on whatever autentication info which the initiator provides to the listen(8)er at the application level.
For x509 certs, there are several additional possibilities. The CommonName (CN) field often has either a dns name or something which looks like an email address. But it might also be an actual, real-world common name. The Subject Alternative Name can have a set of dns names, email addresses, URIs, IP addresses, et cetera. The appliation might ask for a specific association when an application- layer authentication is used or tried. Or may tell the tls code to prefer email, dns or whatever names. Converting the selected string to a lookup needs specification for each type of string. For dns names, we could specify an indentity transformation, or add a simple prefix, such as _client, _$ProtoName._(tcp|udp|etc) or _$ProtoName. The prefix SHOULD NOT involve port numbers. That is appropriate for a listen(8)er on a well-known port or found via SRV or the like, but not for initiator tlsas. For email-like strings, we should specify the same transformation we specify for smime. The current draft looks mostly OK for that, but an _at between the h(H(left)) part and the right part may be in order. For URIs like $proto:$hostname or $proto://$hostname, a lookup like either _$proto.$hosname, _$proto._client.$hostname seems reasonable. For URIs like $proto:$email or $proto://$username@$hostname either following the email transformation or adding an additional _$proto before the results of that transformation seems right. All of 0,1,2,3 should be OK if the intitiator sends a set of certs, but the EE cert SHOULD be the one used to find the tlsa set. The OOB case should follow the same advice as for OOB listen(8)ers, wrt types of tlsa. IP address SANs should map to where the ptr is, provided it matches the IP from which the socket originated. And even without an explicit IP address SAN, the originaing IP probably SHOULD be checked. A prefix in that case probably is unneeded; the tlsa can be parallel to the ptr. Other types of SAN data probably need their own RFC to map to tlsa locations. CNs probably should be checked only as a fallback, if it is different from any of the SANs and if none of them worked. The application SHOULD get to know exactly which SAN/CN verified, so that it can match that to its ideas about aaa. I think that is everthing I've been considering recently. (I had planned on a missive about this; but the above is written from memory, with minimal editing.) -JimC -- James Cloos <[email protected]> OpenPGP: 0x997A9F17ED7DAEA6 _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
