YANGster Liaison Notes
Responses to https://datatracker.ietf.org/liaison/1761.
===== START =====
The IEEE 802.1 Security Task Group reviewed the Internet-Draft A YANG Data
Model for a Keystore
(https://datatracker.ietf.org/doc/draft-ietf-netconf-keystore/ ).
This liaison was posted on 2021-10-15. An update to the draft (-23) was posted ~six weeks later:
-23: https://datatracker.ietf.org/doc/html/draft-ietf-netconf-keystore-23
Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-keystore-23.txt
The update was trivial. From the Change Log:
A.23. 22 to 23
* Updated 802.1AR ref to latest version
* Replaced “base64encodedvalue==” with “BASE64VALUE=” in examples.
* Minor editorial nits
Now, on to the points made in the liaison!
In this draft, a number of items are identified as truly optional MAY; it would
appear that some of these items would override restrictions in other security
standards.
For example, in Section 3, Support for Built-in Keys, there is
discussion about copying the built-in keys; however this is restricted by IEEE
Std 802.1AR. The draft should be clear that where provisions of referenced
security standards appear to conflict or restrict the operations described in
the draft, those other security standards take precedence.
First, to the last point, isn’t that always the case?
As for the main point, this is effectively a non-issue since the text in Section 3 is referring to copying a *handle* to raw private-key data (not the raw key data itself). This text must be confusing since the word “key” has three potential meanings: the raw key, the “[a]symmetric-key” YANG-defined node, and the “key” to the YANG “list” statement.
I write “effectively” above because the handles can point to three kinds of keys: hidden, encrypted, and cleartext. For “hidden” keys (e.g., TPM-protected keys), the concern is definitely a non-issue. For “encrypted”, the concern should be a non-issue, as it mimics the real-world (e.g., TPM-encrypted keys). For “cleartext”, the concern may be valid but note that, in this case, the key-data has the “default-deny-all” NACM extension applied and, more importantly, it would be rather silly for a server to define a forever-key in the clear, though this draft doesn’t restrict that possibility. FWIW, this section is merely pointing out necessary handling in order to maintain DB referential integrity.
Please also note that the “with-system” draft introduces more formal support for system-defined (a.k.a., built-in) nodes and that, after vigorous on-list debate, it also requires that such nodes are copied into <running>.
The certificate encoding specified does not appear to use any standard encoding
(e.g., DER/BER).
Assuming /keystore/asymmetric-keys/certificates/certificate/cert-data, it is of type “ct:end-entity-cert-cms”, which is formally defined in Section 2.3 (YANG Module) in the “crypto-types” draft, which states that it is the DER encoding.
It also might be useful to reference a standard key wrap or
specifier for a standard key wrap algorithm for transporting both symmetric and
asymmetric keys.
Asymmetric keys are defined by the grouping “asymmetric-key-pair-grouping” described in Section 2.1.4.5. of the “crypto-types” draft. Note that “private-key-format” is a base identity for which a number of obvious formats are defined and more may be added (via extensions) to support other formats as needed. Similar definitions exist for symmetric keys.
There is an updated standard IEEE Std 802.1AR, Secure Device Identity, which is
IEEE Std 802.1AR- 2018. And there are extraneous letters (i.e., Group, W. -. H.
L. L. P. W.) in the reference for [Std- 802.1AR-2009] which should be removed.
The reference version was changed to “2018” in the -23 update.