Last Call Review of draft-ietf-lamps-nf-eku-01
review-ietf-lamps-nf-eku-01-secdir-lc-nir-2023-09-01-00

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