X.509 Certificate Extended Key Usage (EKU) for 5G Network Functions
draft-ietf-lamps-nf-eku-05

        In addition, the IANA repository "SMI Security for PKIX Extended Key Purpose"

You mean Registry, not repository?

        It's important to note that using the anyExtendedKeyUsage
        KeyPurposeId, as defined in Section 4.2.1.12 of [RFC5280], is
        generally considered a poor practice. This is especially true for
        publicly trusted certificates, whether they are multi-purpose
        or single-purpose, within the context of 5G systems and the 5G
        Core Service Based Architecture.

Why is it important to note? I would likely either remove the paragraph
or just reword it much simpler:

        KeyPurposeId properties are meant to limit the applicability of
        the certificate. The use of the anyExtendedKeyUsage KeyPurposeId
        would remove the use of this additional security property.

But if you are only trying to say "we obviously dont want to use
anyExtendedKeyUsage", then I think that is quite obvious and the entire
paragraph can be cut.  If this property is currently used because there
is no other KeyPurposeId that can be used and that's why it is currently
being used, perhaps that should be stated explicitly, eg "this document
defines new KeyPurposeId values that allow 5G systems to no longer need
to rely on the less secure anyExtendedKeyUsage KeyPurposeId".

       If the purpose of the issued certificates is not restricted, i.e.,
        the type of operations for which a public key contained in the
        certificate can be used are not specified, those certificates
        could be used for another purpose than intended, violating the
        CA policies, and increasing the risk of cross-protocol attacks.

I would remove "violating the CA policies" because if the CA signed without
specifying restrictions, you are not really violating their policies.

        Another example, if the purpose of the certificate is for the
        NF service consumer is to use it as a client certificate, the
        NF with this client certificate and corresponding private key
        must not be allowed to sign the CCA.

Doesn't the lack of X509v3 Basic Constraints CA:TRUE deal with this use
case already? So maybe this is not the best example, or if it is, perhaps
explain why the Basic Constraints CA: in itself isn't enough?

        Vendor-defined KeyPurposeIds used within a PKI governed
        by the vendor or a group of vendors typically do not pose
        interoperability concerns, as non-critical extensions can be
        safely ignored if unrecognized. However, using or misusing
        KeyPurposeIds outside of their intended vendor-controlled
        environment can lead to interoperability issues. Therefore, it is
        advisable not to rely on vendor-defined KeyPurposeIds. Instead,
        the specification defines standard KeyPurposeIds to ensure
        interoperability across various implementations.

I think this paragraph can be safely deleted. It is stating things that
are very obvious (there are multiple vendors in the telecom industry)
       This specification defines the KeyPurposeIds id-kp-jwt,
        id-kp-httpContentEncrypt, id-kp-oauthAccessTokenSigning for
        respectively [...]

I think you want to say:

        This specification defines the KeyPurposeIds id-kp-jwt,
        id-kp-httpContentEncrypt, id-kp-oauthAccessTokenSigning and
        uses these for respectively [...]

That makes it clear that these KeyPurposeIds are not just for 5G equipment.

        Applications verifying the signature of a Client Credentials
        Assertion (CCA) represented as JWT, decrypting JSON objects in
        HTTP messages between Security Edge Protection Proxies (SEPPs)
        using JWE or verifying the signature of an OAuth 2.0 access
        tokens for service authorization to grant temporary access
        to resources provided by NF producers using JWS MAY require
        corresponding KeyPurposeIds be specified by the EKU extension.

This is pretty unreadable. How about:

        Applications verifying the KeyPurposeIds id-kp-jwt, id-kp-httpContentEncrypt
        and id-kp-oauthAccessTokenSigning MAY require corresponding KeyPurposeIds
        be specified by the EKU extension.

The "MAY" here is also rather weak, and undoing the gains of using
these new KeyPurposeIds. Maybe "SHOULD" is better? Or perhaps some
additional text about greenfield deployments could say something like
"if the application knows clients are required to use these KeyPurposeIds,
it MUST require them being set".