Subject: Re: [netconf] truststore: merging the “ssh-public-key” and “raw-public-key” lists

From: Balázs Kovács <[email-masked]>
Date: Tue, 3 Mar 2020 13:30:19 +0000

Hi Kent,

Sound ok from my side.
Br,
Balazs

-----Original Message-----
From: netconf <[email-masked]> On Behalf Of Kent Watsen
Sent: Wednesday, February 19, 2020 4:32 PM
To: [email-masked]
Subject: [netconf] truststore: merging the “ssh-public-key” and “raw-public-key” lists

Slide 12 in my 106 presentation contained this snippet:

	module: ietf-truststore
	   +--rw truststore
	        +--rw certificates* [name] {x509-certificates}?
	         |     +-- …
	        +--rw ssh-host-keys* [name] {ssh-host-keys}?
	         |     +-- …
	         +--rw raw-public-keys* [name] {raw-public-keys}?
	               +-- ... 

The slide asked if the “ssh-public-key” and “raw-public-key” lists should be merged.  No comments were received during the meeting, so I said that it might require trying out, and folks can look forward to that discussion later….and here were are!

Looking at truststore's YANG, it turns out that the “ssh-public-key” and “raw-public-key” lists are *identical* with one exception, which is that each refines a common crypto-types grouping with a slightly different “must" expression regarding the “key-format".  Specifically, the ssh-public-key format must be “ct:ssh-public-key-format" and raw-public-key format must be “ct:subject-public-key-info-format”.

However, these "must” statements are low-value as already (at least in my local copy), the SSH and TLS client/server modules have the equivalent “must” expressions.  This being the case, it appears that these two lists should be merged, with the resulting trees-diagram being:

	module: ietf-truststore
	   +--rw truststore
	        +--rw certificates* [name] {x509-certificates}?
	         |     +-- …
	         +--rw public-keys* [name] {public-keys}?
	               +-- … 

In my view, the optics on this are better, as having protocol-specific entries in the truststore (e.g., ssh-host-keys) always seemed wrong to me...

Any objection to this change being made?

PS: this is the last post-106 item I needed to address, in case you’re wondering how many more might be coming...

Kent // contributor

_______________________________________________
netconf mailing list
[email-masked]
https://protect2.fireeye.com/v1/url?k=14d73d81-485e920c-14d77d1a-0cc47ad93de2-8d2c74085f0b9aff&q=1&e=1962dafc-d4d4-496a-acbd-62da48fe7ab7&u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fnetconf