Reviewer: Yoav Nir Review result: Has Issues I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. 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 last call comments. The document defines a YANG model for managing a trust anchor store. It allows two kinds of trust anchors: certificates and raw public keys. However, certificates are not just containers for public keys. Certificates include attributes about key usage, path constraints and name constraints, all of which constrain the ability to use the public key, and are relevant for trust anchors. As far as I can tell the document does not include any attributes to equivalently constrain the use of the raw public keys. If the intention is that raw public keys will not be constrained, the document should state this explicitly. Perhaps this is clear to the people who worked on the document, but it's not clear to me. Are the trust anchors managed with this module supposed to be used to establish trust for the NETCONF or RESTCONF connections? Section 1.1 seems to suggest that it does, but then how is the bootstrap problem solved? How do we establish the NETCONF connection the first time, and if we are able to do that, why do we need more certificates? If the answer is no, and the certificates are to be used by other protocols, then perhaps some re-wording in section 1.1 would help to show this. Currently, it says: "This document presents ... YANG modules that are part of a collection of RFCs ... define configuration modules for clients and servers of both the NETCONF and RESTCONF protocols." The security considerations section is OK, especially sub-section 4.2. Sub-section 4.1 has the following: The YANG module defined in this document defines a mechanism called a "truststore" that, by its name, suggests that it will protect its contents from unauthorized modification. Perhaps this is my different perspective, but the name doesn't lead me to expect that it protects its contents. I think that the document should either just suggest that some mechanism to prevent unauthorized modification should be used, or to present such a mechanism in detail. The current text suggests is partially specific by mentioning digital signatures and non-volatile storage, but not explaining where the trust for the digital signature comes from and what policies govern its us: In order to satisfy the expectations of a "truststore", it is RECOMMENDED that implementations ensure that the truststore contents are signed when persisted to non-volatile memory, to prevent unauthorized modifications from being made undetected. It is too vague to be a specification, but still unnecessarily constrains the solution space. I think the correct thing to do is to be explicitly vague and to just suggest some mechanism for protecting the content. -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
