Re: [netconf] ietf-ssh-server host key

[Kent Watsen <[e-mail]>]

Hi Michal,
> Hello,
> 
> we are implementing these modules (ietf-netconf-server and imports) and I have a question regarding the container `/ietf-netconf-server:netconf-server/listen/endpoint/ssh/ssh-server-parameters/server-identity/host-key/public-key`. It looks like this
> 
> +--rw public-key 
>    +--rw (inline-or-keystore) 
>       +--:(inline) {inline-definitions-supported}? 
>       |  +--rw inline-definition 
>       |     +--rw public-key-format     identityref 
>       |     +--rw public-key            binary 
>       |     +--rw private-key-format?   identityref 
>       |     +--rw (private-key-type) 
>       |        +--:(cleartext-private-key) {cleartext-private-keys}? 
>       |        |  +--rw cleartext-private-key?   binary 
>       |        +--:(hidden-private-key) {hidden-private-keys}? 
>       |        |  +--rw hidden-private-key?   empty 
>       |        +--:(encrypted-private-key) {encrypted-private-keys}? 
>       |           +--rw encrypted-private-key 
>       |              +--rw encrypted-by 
>       |              +--rw encrypted-value-format    identityref 
>       |              +--rw encrypted-value           binary 
>       +--:(keystore) {central-keystore-supported,asymmetric-keys}? 
>          +--rw keystore-reference?   ks:asymmetric-key-ref
> 
> What is there the public key for? For a key to be used as a host key you only need the private key (technically, you can always generate the public key from the private key but the public key is not needed at all in this case) and it is causing us some problems because it is even required to be in the `ssh-public-key-format` without any information as to why. Thanks for any explanation.
> 
You are correct, the "public-key" node typically isn't needed when configuring SSH.

The reason it is in the `SSH model is because:

1) sometimes (I forget which Security person said this) a public-key cannot be extracted from a private-key, thus a generic private-key type seems to be incomplete without its public-key encoded also.  It would be good to reconfirm this claim.

2) albeit unusual, it isn't a hard thing for (my) code to encode the public-key also, so I felt it was a minor nuisance to ensure future-proofing.

3) thus the propagation of the asymmetric-key-pair-grouping (in crypto-types) makes it to the ssh-client-server draft.  FWIW, this is why it's named "asymmetric-key-pair-grouping" and not "private-key-grouping".

Can you say some more about why its presence is causing problems?

If this is a real problem (or perhaps even if just a nuisance), the crypto-types drafts could define also a "private-key-grouping" (having just the private-key) and then recast  "asymmetric-key-pair-grouping" to use it.  Or, if it turns out the claim (see #1) in unfounded, the  "asymmetric-key-pair-grouping" could be discarded altogether.

> Regards,
> Michal
> 
Kent