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

Kent Watsen <> Mon, 05 June 2023 12:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 929CBC15109B for <>; Mon, 5 Jun 2023 05:38:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.896
X-Spam-Status: No, score=-6.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 0VtMt4ikNF7u for <>; Mon, 5 Jun 2023 05:38:49 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9EFE9C151093 for <>; Mon, 5 Jun 2023 05:38:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono;; t=1685968728; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=0lpyug7YkK5zWDR1fueaW5Zh3OrftAK03TJmNUIGQ7w=; b=X3K5Wqgw/Fq6mXkgg0j8uMMhqqoLfsdRWGq5x/r0m6wmqRHRe7vDBUYwmx0ykZaY l0X6rl0yDT7+MQ9yfC0TCVOCVqbDvQTfIXbuGEah+/PYKi+QtDpjUNx6Ab2SbVqhBr3 e6fwWjCNJj6IMdzBrVbU61Q66if4mff8hSWVv+8E=
From: Kent Watsen <>
Message-ID: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_43ADAB70-AD98-4BB5-A422-1AB6DA49EC17"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.400.51.1.1\))
Date: Mon, 05 Jun 2023 12:38:48 +0000
In-Reply-To: <>
Cc: "" <>
To: Michal Vasko <>
References: <>
X-Mailer: Apple Mail (2.3731.400.51.1.1)
X-SES-Outgoing: 2023.06.05-
Archived-At: <>
Subject: Re: [netconf] ietf-ssh-server host key
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: NETCONF WG list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 05 Jun 2023 12:38:51 -0000

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