[netconf] "trust-anchor" usage (was: truststore usage in ietf-ssh/tls-client/server)

[Kent Watsen <[e-mail]>]

[changing the subject line]


> it may help to adopt terminology defined in RFC 4949.

Indeed, but let's start this inquisition with crypto-types:

	$ grep trust-anchor ietf-crypto-types.yang

	  typedef trust-anchor-cert-x509 {
	  typedef trust-anchor-cert-cms {
	  grouping trust-anchor-cert-grouping {
	      type trust-anchor-cert-cms;
	  grouping trust-anchor-certs-grouping {
	      type trust-anchor-cert-cms;

But also note:

	$ grep end-entity ietf-crypto-types.yang 

	  typedef end-entity-cert-x509 {
	  typedef end-entity-cert-cms {
	  grouping end-entity-cert-grouping {
	      type end-entity-cert-cms;
	  grouping end-entity-certs-grouping {
	      type end-entity-cert-cms;
	    uses end-entity-cert-grouping;
	        uses end-entity-cert-grouping;

Note in particular the "cms" types, as they hold a partial sequence of certificates.  The "trust-anchor" sequence always leads to a root certificate.  The "end-entity" sequence always leads to a "CA False" certificate.  These types are meaningfully used in the client/server suite of drafts.  For instance, a TLS server can present a partial end-entity certificate chain which the client stitches into a partial trust-anchor certificate chain.  It is important to support partial chains for operational reasons, not to mention a number of crypto libraries don't support partial certificate path validation.

In RFC 4949, "certification path" or "trust chain" or "trusted CA" seem close.


Kent // contributor