Re: [netconf] crypto-types fallback strategy

["Salz, Rich" <[e-mail]>]

  *   It seems that there is little appetite to pursue a solution that entails defining many algorithm identifiers/enumerations in YANG.

I am glad of this.

An important thing to realize is that many cryptographic datatypes were designed for special purposes, and breaking everything down into its component parts defeats some of the security (separating the parameters from an RSA-PSS key, for example), or deployment issues (such as separating the signature from the certificate request or splitting up a CA cert chain into the individual certs).

Do not try for an omnibus of cryptographic types – any given application will almost definitely never have to use all the types in a module. Start with something small, such as what is needed to configure an HTTPS server – a cert chain, an end-entity cert, and a private key.  All of these can be handled by OpenSSL command-line.  Future modules could add SSH provisioning, VPN key management, Kerberos login actions, and suchlike.

Starting with the HTTPS server, all of those objects are, as you point out, structures defined in ASN1 and encoded in DER. For configuration, they are generally maintained as base-64 encoded files, with a known header and trailer line. This is popularized by OpenSSL as the PEM format, which harkens back to RFC 1421. RFC 7468 is an excellent starting point for actual use of that.

Hope this helps.  I would be glad to contribute to a draft developed along these lines.