Liaison statement
Liaison on a YANG Data Model for a Keystore
Additional information about IETF liaison relationships is available on the
IETF webpage
and the
Internet Architecture Board liaison webpage.
State | Posted |
---|---|
Submitted Date | 2021-10-15 |
From Group | IEEE-802-1 |
From Contact | Glenn Parsons |
To Group | IETF |
To Contacts | The IETF Chair <chair@ietf.org> |
Cc | The IETF Chair <chair@ietf.org> The IESG <iesg@ietf.org> Paul Nikolich <p.nikolich@ieee.org> Karen Randall <karen@randall-consulting.com> Jodi Haasz <j.haasz@ieee.org> Russ Housley <housley@vigilsec.com> Dorothy Stanley <dorothy.stanley@hpe.com> |
Response Contact | Jessy Rouyer <jessy.rouyer@nokia.com> Glenn Parsons <glenn.parsons@ericsson.com> Mick Seaman <mickseaman@gmail.com> |
Purpose | For action |
Deadline | 2021-12-10 Action Needed |
Attachments | liaison-ietf-YANGkeystore-0921-v02 |
Body |
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/ ). 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. The certificate encoding specified does not appear to use any standard encoding (e.g., DER/BER). 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. 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. Thank you for your consideration of these matters, and we welcome continued collaboration going forward. |