Allow access to peer X.509 certificate subject field CN and certain non-DNS SANs

[m-ronnblom]

Extend XCM to allow access to peer X.509 certificate subject field and non-DNS Subject Alternative Names (SANs) on established TLS sessions within a TLS, BTLS, or UTLS XCM connection.

In particular, it should be possible to retrieve

• the CN part of the subject field
• All SANs of the following types: directoryName and rfc822Name

The new API should be a natural extension to the already-existing API to access dNSName SANs (i.e., the tls.peer_names attribute).

Consider if a new list type socket attribute value type should be introduced. Such a socket attribute value type may be a good idea. Even if not strictly required to fit these X.509 SANs, it will be useful and likely also required to have for future (e.g., binary element-type) lists. This would deviate from the colon-separated string approach to list encoding used by tls.peer_names.

See RFC 5280 for more on the SAN types.

[m-ronnblom]

One could introduce a new level "tls.peer_cert", where all the certificate-related information is available. Also, the subject could be a new level.

"tls.peer_cert.subject.cn"
"tls.peer_cert.names"
"tls.peer_cert.emails"
"tls.peer_cert.directories"

For list-type nodes, it would be useful if the elements could be access directly, with something like
xcm_attr_get(conn, "tls.peer_cert.email[0]");

If "list" is added as a value type, one could also ask if a "map" (or "directory") value type should also be added. In that case, what is this map's relationship with the xcm_attr_map.h type?