[netconf] crypto-types and keystore comments

[Martin Bjorklund <[e-mail]>]

Hi,

I have some comments on draft-ietf-netconf-crypto-types-12 and
draft-ietf-netconf-keystore-14.


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?


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

   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.

   With the current design it is not obvious to me how I can find all
   ssh keys, for example.

   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.


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.

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


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)


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)



/martin