Hello. 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 with the intent of improving security requirements and considerations in IETF drafts. Comments not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. I think the first sentence in the Security Considerations section is unnecessary. This document does not inherit the security considerations of 5280 as its scope is nowhere near as broad as that RFC. The rest just about covers it. The document does not introduce new security vulnerabilities as it reduces (once implemented and deployed) the possibility of misusing keys to sign JWT claims, encrypt JSON objects between SEPPs, and to sign OAuth 2.0 access tokens, when that was not their intended purpose. What I find confusing is the the last paragraph of the Introduction: Vendor-defined KeyPurposeIds that are used in a PKI governed by the vendor or a group of vendors pose no interoperability concern. Appropriating, or misappropriating as the case may be, KeyPurposeIds for use outside of their originally intended vendor or group of vendors controlled environment can introduce problems, the impact of which is difficult to determine. Therefore, it is not favorable to use vendor-defined KeyPurposeIds. So, vendor-defined KeyPurposeIds do not cause interoperability issues. Misappropriating them can cause (interoperability?) problems. Therefore, they should not be used? So do they or don't they cause interoperability issues? I suppose this paragraph is there for justifying the need to have these KeyPurposeIds come from LAMPS and the IETF rather than some vendor group, but I'm not seeing how a 3GPP-controlled assignment would be any more prone to misappropriation than an IETF one. Regardless, LAMPS has already taken up this work, so perhaps this paragraph is not needed anymore? Yoav