Re: [netconf] crypto-types and keystore comments

[Kent Watsen <[e-mail]>]

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.


> 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>).  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>`).

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. 



> 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.



> 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