Last Call Review of draft-ietf-netconf-keystore-30
review-ietf-netconf-keystore-30-secdir-lc-nystrom-2024-02-04-00
Request | Review of | draft-ietf-netconf-keystore |
---|---|---|
Requested revision | No specific revision (document currently at 35) | |
Type | Last Call Review | |
Team | Security Area Directorate (secdir) | |
Deadline | 2024-01-24 | |
Requested | 2024-01-10 | |
Authors | Kent Watsen | |
I-D last updated | 2024-02-04 | |
Completed reviews |
Genart Last Call review of -29
by Reese Enghardt
(diff)
Secdir Last Call review of -30 by Magnus Nyström (diff) Yangdoctors Last Call review of -02 by Jürgen Schönwälder (diff) Secdir Early review of -18 by Magnus Nyström (diff) Secdir Last Call review of -19 by Sandra L. Murphy (diff) Yangdoctors Last Call review of -20 by Jürgen Schönwälder (diff) |
|
Assignment | Reviewer | Magnus Nyström |
State | Completed | |
Request | Last Call review on draft-ietf-netconf-keystore by Security Area Directorate Assigned | |
Posted at | https://mailarchive.ietf.org/arch/msg/secdir/V5nBbEnCDQPJELkCdo7DNrvXK0k | |
Reviewed revision | 30 (document currently at 35) | |
Result | Has nits | |
Completed | 2024-02-04 |
review-ietf-netconf-keystore-30-secdir-lc-nystrom-2024-02-04-00
I have reviewed this document as part of the IETF SecDir's effort to review all I-Ds before publication. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other comments. This is my second review of this document; the first was done on version -18 (or -19). The document is much improved in clarity, and I particularly liked the inclusion of a Master Key option to handle KEKs. My remaining comments are: - The "certificate" node in the YANG module seems under-specified. It isn't clear to me what "name" refers to, and normally you're able to look up a certifiate by using the combination of Issuer (distinguished) name and serial number, for example. Some more info here seems warranted? - Section 4.1 talks about "possessing" a key - it is not clear what "possess" means. In practice, access to the key such that it can be used for its intended purpose (even without being able to know the actual key value) should be sufficient.