[netconf] algorithms in crypto-types

[Kent Watsen <[e-mail]>]

This message proposes an approach for how to support algorithms that is quite different than in the current draft.

But, first, let me preface this by saying I continue to believe the current approach is ideal (as in idealistic), but fear that it may be trying to solve a problem that should be solved by the crypto community, not us (and hence not very practical).    To be ensure this is the case, the Chairs need to reach out to the Security Directorate for guidance.  With luck, a representative will be up to speed and able to attend our session Monday morning.  Stay tuned.

That being the case, I'd like to suggest an alternative approach, which is for ietf-crypto-types to define even more ASN.1 types, specifically, ASN.1 types for public and private keys.   But, first, let me explain how I came to think of this idea.  As mentioned before, I'm implementing ietf-restconf-server and when I got to the point of needing to populate values for the public and private key nodes, I took a shortcut of just storing the DER-encoded ASN.1 values provided by a utility such as OpenSSL.  Of course, ietf-restconf-server is primarily about HTTP over TLS, and hence it's common a create keys in the process of generating the PKI hierarchies needed to support TLS trust-anchor and end-entity certificates.   I was just being lazy at the time but, after awhile stewing on it, I'm wondering if this might not be an idea worth standardizing.

To be clear, the idea is to define the public/private key nodes as being ASN.1 types and, in doing so, inherit the algorithm identities used by ASN.1, thus negating the need to define any YANG-level identities.

Framing this idea a little more, if we were to do this:

1) ietf-crypto-types might be better titled ietf-asn1-types.  Already the module defines many ASN.1 types (listed below) and, after adding a few more ASN.1 types for the public and private key structures, and removing the identities/enumerations for the algorithms, all the typedefs would there be ASN.1 based.   [Here are the current ASN.1 types defined in the current module: x509, crl, cms, data-content-cms, signed-data-cms, enveloped-data-cms, digested-data-cms, encrypted-data-cms, authenticated-data-cms, trust-anchor-cert-x509, end-entity-cert-x509, trust-anchor-cert-cms, and end-entity-cert-cms.]

2) the solution in the suite of client-server drafts would be very much ASN.1 oriented.  This would be (for the most part) splendid for TLS-based protocols, but not very helpful for other protocols, notably SSH (unless using the X.509 extensions per RFC 6187).   It sounds limiting but, let's be honest, TLS is the basis for most protocols and hence this would be a 90% solution.  Further, when thinking about ietf-truststore, it's fairly uncommon to use trust-anchors with SSH.  And, for ietf-keystore, I'm unsure at this point to what extent keystores are used to protect SSH private keys - I've never seen a TPM/HSM used to protect an SSH key, unless the key were encrypted (as in the latest keystore draft), or was an X.509 end-entity certificate (per RFC 6187, albeit I don't know any vendor that supports RFC 6187 today).

3) this approach would do little to help the other WGs (e.g., SACM) with their YANG modeling endeavors.  Note that the reason my co-authors from Huawei were attracted to helping us with this effort was because they want to embrace-and-extend it for other work.  I'm not up-to-speed on that, and thus look to them to share more about the landscape in which this module fits.


Kent // contributor