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


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