Re: [netconf] crypto-types and keystore comments

[Martin Bjorklund <[e-mail]>]

Kent Watsen <[e-mail]> wrote:
> 
> 
> Hi Martin,
> 
> 
> > o  Is the key-format there to support multiple formats for the same
> >   kind of key (e.g., ssh key), or is it there to be able to have
> >   different kinds of keys in the same list?  (Or both?)
> > 
> >   I.e., is the intentation that a client can freely pick any
> >   private-key-format (that is supported by the server), regardless of
> >   how the key is used?
> 
> Firstly, see:
> https://mailarchive.ietf.org/arch/msg/netconf/5Zpj8Xxh7bHvAJeQf2Lj0t6h8hg
> <https://mailarchive.ietf.org/arch/msg/netconf/5Zpj8Xxh7bHvAJeQf2Lj0t6h8hg>
> 
> That said, there are some limitations that are likely not represented
> yet.  For instance, an encrypted private key must use "identity
> encrypted-private-key-format" and an encrypted symmetric key must use
> "identity encrypted-symmetric-key-format", as there is no way to
> express it otherwise.
> 
> But your question is likely more regarding the other direction, for an
> *unencrypted" asymmetric key, can a client arbitrarily choose one of
> the *-private-key-format identities or "identity
> one-asymmetric-key-format"; likewise, for an *unencrypted* symmetric
> key, can a client arbitrarily use either "identity
> octet-string-key-format" or "identity one-symmetric-key-format".
> 
> The goal is for the use of OneAsymmetricKey and OneSymmetricKey
> formats to be an advanced feature.  As said above, these structures
> must be used for encrypted keys, and should be used for unencrypted
> key (as the structure carries security attributes not present in the
> raw formats), but it's more likely that implementations will support
> the raw formats.
> 
> My thoughts are that, if an implementation is updated to support for
> One[A]SymmetricKey for encrypted keys, then letting a client
> optionally use One[A]SymmetricKey for unencrypted keys isn't that big
> of an implementation effort.  Thus I suggest adding features called
> "one-symmetric-key" and "one-asymmetric-key", and place if-feature
> statements under these identities so that servers can express when
> they support them.

Suppose I want to configure a ssh host-key as the server-identity for
my NETCONF server.  Is the intention that a client can pick either
"ssh-public-key-format" or "subject-public-key-info-format", and the
server must support both?


> > o  One idea that was floating around was to have separate keystore
> >   lists for different things (see the ML archives, e.g. some mails in
> >   the thread "crypto-types fallback strategy").  I.e. instead of the
> >   current:
> > 
> >   +--rw keystore
> >      +--rw asymmetric-keys
> >      |  +--rw asymmetric-key* [name]
> > 
> > 
> >   we would have something like:
> > 
> >   +--rw keystores
> >      +--rw ssh-keystore
> >      |  ...
> >      +--rw tls-keystore  // x509-keystore?
> >         ...
> 
> Right, but that approach was deemed not viable before.
> 
> 
> >   If we don't have to support multiple formats for the same kind
> >   of key, I don't think we need the key-format in this case.
> 
> Maybe.
> 
> 
> >   With the current design it is not obvious to me how I can find all
> >   ssh keys, for example.
> 
> That's because keys don't have to have a set purpose.  For instance,
> an IDevID shipped with the device could be used for either SSH or TLS.
> 
> 
> >   This said, *if* we use a single generic list, I think the list in
> >   the current model works fine.  It is a bit complicated, but some
> >   complexity is inevitable with a generic model like this.
> 
> Yes and yes.
> 
> 
> 
> 
> > o   iana- modules
> > 
> >  The iana modules have a list of supported algorithms, e.g.:
> > 
> >       list supported-asymmetric-algorithm
> > 
> >  I mentioned this before - I don't think a global list like this is
> >  sufficient.  For example, perhaps my TLS code supports "secp521r1",
> >  but my SSH code does not.
> 
> Yes, well, this is a known problem (e.g.,
> https://github.com/netmod-wg/yang-next/issues/82
> <https://github.com/netmod-wg/yang-next/issues/82>).

That is quite different.

You're using a normal config false list for this (which is fine), but
I don't think you can use a single global list like this.


> I realize that
> you're not specifically talking about feature statements, but it's
> similar.  One difference between #82 and this is that here, the
> capabilities are presented in "config false" lists instead, which
> might bring us to https://github.com/netmod-wg/yang-next/issues/41
> <https://github.com/netmod-wg/yang-next/issues/41> again...
> 
> 
> 
> > And some random small things I noticed:
> > 
> > o  ssh-public-key-format
> > 
> >  The crypto model has:
> > 
> >    identity ssh-public-key-formatp {
> >      base "public-key-format";
> >      description
> >        "The public key format described by RFC 4716.";
> >    }
> > 
> >  I think that this should be:
> > 
> >    description
> >      "The binary public key data for an SSH key, as
> >       specified by RFC 4253, Section 6.6, i.e.:
> > 
> >         string    certificate or public key format
> >                   identifier
> >         byte[n]   key/certificate data.";
> >    reference
> >      "RFC 4253: The Secure Shell (SSH) Transport Layer
> >                 Protocol";
> > 
> >  Note that the public key format in 4716 is textual:
> > 
> >    ---- BEGIN SSH2 PUBLIC KEY ----
> >    Header-tag ':' ' ' Header-value
> >    BODY
> >    ---- END SSH2 PUBLIC KEY ----
> > 
> >  Where BODY is:
> > 
> >   The body of a public key file is the base64 encoded ([RFC2045])
> >   public key data as specified by [RFC4253], Section 6.6:
> > 
> >         string    certificate or public key format identifier
> >         byte[n]   key/certificate data
> > 
> >  So with your current definition we would take this textual format
> >  (that has the key base64-encoded), and base64 encode the whole
> >  thing (includign the already base64-encoded key).
> 
> I will say that the definition above was given because it is the only
> *standards* based key that `openssh` can output (i.e., `ssh-keygen -e
> [-m RFC4716] -f <private-key-file>`).

With my proposal you can take the output of this openssh command and
copy & paste the base64-encoded data from this output to a YANG node
using ssh-public-key-format.

With your proposal you have to copy the entire output, base64 encode
it *again*, and then copy & paste that result to the YANG node.


> That said, if you refer to the link I provided at top, it is my belief
> that the "key-format" node may be extended to support alternate
> encodings (e.g., DER vs PEM and, potentially, CMS vs multi-part PEM).
> To this end, perhaps we could support both the 4716 and 4253 formats.

Do we really want to go there?  This is already quite complex, and
having a multitude of optional formats for the same thing may make
things even more complex, to understand and get right.

> > o  subject-public-key-info-format
> > 
> >  The crypto model has:
> > 
> >    identity subject-public-key-info-format {
> >      base "public-key-format";
> >      description
> >        "A SubjectPublicKeyInfo (from RFC 5280).";
> >    }
> > 
> >  Should this be "DER encoded"?
> > 
> >  (this and other defintions have references to RFCs in the
> >  description; they should be moved to proper "reference" statements)
> 
> Yes.  I put together these definitions in as a test/protocol to gauge
> viability with the plan to enhance the definitions if the WG committed
> to the approach.  I just added some "FIXME" comments to my local copy.

Ok.


> > o  iana-hash-algs
> > 
> >  This module has a bunch of shake-*:
> > 
> >      enum shake-224 {
> >        value 7;
> >        description
> >          "The SHA3 algorithm with 224-bits output.";
> > 
> >  I think this should be "sha3-224" etc.
> > 
> >  (there are just two shake hash functions defined; shake 128 & 256,
> >  and they have variable output)
> > 
> >  (and BTW, FIPS PUB 202 doesn't define sha3-128)
> 
> I don't know.  These are are/were specified by my co-author Haiguang
> (CC-ed).  Haiguang, can you comment?
> 
> 
> Kent // contributor
> 
> 



/martin