cert-to-name algo is picking rfc822-name from client.crt instead of ca.crt about netopeer2 HOT 4 OPEN

Hi, seems like you are right and it should work like you expected. I started working on the changes and they should be in the devel branch soon.

from netopeer2.

Hello,

our understanding of the cert-to-name process is that the client's username is always determined from the client's (peer's) certificate. The YANG description is not very clear in this regard. Furthermore, with your expectations different clients would be able to share the same username and we did not think this was an actual use case. Also you are using quite an old version and if I recall correctly there have been some improvements to the cert-to-name mechanism, yet this logic of obtaining the username solely from the peer's certificate remains.

We may have interpreted the YANG description incorrectly and you may be right. My question is why would you need to obtain the username from a CA certificate instead of the peer's? Are there any resources that would further support your expectations?

from netopeer2.

Thank you for response.

Security administrators are encouraged to make use of
certificates with subjectAltName fields that can be mapped to
names so that a single root CA certificate can allow all
child certificates' subjectAltName fields to map directly to
a name via a 1:1 transformation.";

RFC 6353 (section 7) and cert-to-name yang pointing to use CA to have all child certificates to have common username/privileges.

Use case is to have a common privileges if child certificates signed by CA1 for example.

from netopeer2.

@Roytak Pls let us know if you have any comments or suggestions.

Making changes in nc_tls_cert_to_name and nc_tlsclb_verify to derive name as per the RFC 6353 (section 7) and cert-to-name yang description. I will update once validated.

from netopeer2.