Re: [netconf] ssh/tls key generation support

[Jürgen Schönwälder <[e-mail]>]

On Tue, Mar 22, 2022 at 06:09:44PM +0000, Kent Watsen wrote:
 
> > - Generating server key pairs is just a step of a more complex
> >  process. In SSH, clients traditionally built trust into hostkeys
> >  using an ad-hoc process, in TLS this is traditionally done using
> >  certificates. Hence, at least for TLS, we get into the territory of
> >  generating certificates, either creating self-signed certs, hooking
> >  into an automated certification system like lets encrypt, or
> >  handling a full blown cert process (generating csrs etc).
> 
> The "crypto-types" draft already defines a "generate-certificate-signing-request":
> 
>  - overview: https://datatracker.ietf.org/doc/html/draft-ietf-netconf-crypto-types#section-2.1.4.
>  - example usage: https://datatracker.ietf.org/doc/html/draft-ietf-netconf-crypto-types#section-2.2.2
> 

Sectiopn 3.2 is insightful as well:

   Early revisions of this document included "rpc" statements for
   generating symmetric and asymmetric keys.  These statements were
   removed due to an inability to obtain consensus for how to identify
   the key-algorithm to use.  Thusly, the solution presented in this
   document only supports keys to be configured via an external client,
   which does not support Security best practice.

Apparently we can generate a csr but not the underlying key pair,
which indeed is half-done. Should key generation actually fall into
the crypto types module and not be TLS/SSH specific? And would that
mean that a client invoces a yet-to-define generate-key-pair rpc,
which is then followed by a generate-certificate-signing-request
action in case an explicitely signed certificate is needed? Given that
I look at these I-Ds every N months, it is somewhat of a challenge for
me to keep the context...
 
> > - The SSH and TLS documents started as WG documents in July 2016, we
> >  are getting close to 6 years in the WG and it is somewhat unclear
> >  what the uptake of these documents will be. If we get into
> >  certificate territory, I fear we add at least another year of delay.
> 
> The uptake/demand is notable.  In addition to the PCEP WG dependency, both the BBF and O-RAN are waiting for completion, and IEEE said that they're about to start looking into using.

Progress has been made in waves with a low frequency between the
waves. I do not mind to give this a final try but then there ought to
be a hard deadline - either the details have been figured out by $date
or we move ahead without this feature addressed.

/js
 
-- 
Jürgen Schönwälder              Jacobs University Bremen gGmbH
Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
Fax:   [phone]         <https://www.jacobs-university.de/>