Re: [yang-doctors] [Netconf] last call review of draft-ietf-netconf-keystore-02

[Kent Watsen <[e-mail]>]

Hi Tom,


> My model is that are different ways of arriving at a public key but that
> once you have, then the cryptography is the same, with a choice of
> algorithms.

A good first-approximation  :)


> If you are a SSH client, then likely you have a stash of public host
> keys associated with one or more SSH servers, and, apart from
> algorithms, no more.
>
>
> If you are a TLS client, then likely you are using X.509 and will have a
> pre-configured trust anchor, in the shape of a public key or a
> certificate (which may or may not be root).

The clients also need their own private keys (which may be a password for
SSH) and associated public-key/certificate.


> If you are a SSH server, then likely you will have stash of
> private/public key pairs, perhaps with constraints on their usage, and
> the ability to generate further private/public key pairs.
>
> If you are a TLS server, then you will have one or more X.509
> certificates with your public keys, a chain of X.509 certificates back
> to an anchor that the client will trust, the corresponding private keys
> and perhaps the ability to generate a X.509 certificate with a
> public/private key pair; this may or may not chain back to a trusted
> root.

The servers also need information for how to authenticate the clients
(hashed password, pinned public-key or cert, pinned trust-anchor, etc.)
and how to map them to application-level usernames (e.g., via cert-maps)


> There are other TLS options but I think that their usage is limited, but
> in the context of network management, one or more could be significant
> although I don't have a specific example in mind ( I like PAKE but do
> not see it in use).
>
> So the only part in common is what you do once you have the public key,
> which is not much.

I'm unsure what change you're looking for with this comment.


Thanks,
Kent