rfc9509xml2.original.xml   rfc9509.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?> <!DOCTYPE rfc [
<?rfc tocompact="yes"?> <!ENTITY nbsp "&#160;">
<?rfc tocdepth="3"?> <!ENTITY zwsp "&#8203;">
<?rfc tocindent="yes"?> <!ENTITY nbhy "&#8209;">
<?rfc symrefs="yes"?> <!ENTITY wj "&#8288;">
<?rfc sortrefs="yes"?> ]>
<?rfc comments="yes"?>
<?rfc inline="yes"?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IETF" category="
<?rfc compact="yes"?> std" consensus="true" docName="draft-ietf-lamps-nf-eku-05" number="9509" ipr="tr
<?rfc subcompact="no"?> ust200902" obsoletes="" updates="" xml:lang="en" tocInclude="true" tocDepth="3"
<rfc category="std" docName="draft-ietf-lamps-nf-eku-05" ipr="trust200902"> symRefs="true" sortRefs="true" version="3">
<front> <front>
<title abbrev="EKUs for NFs">X.509 Certificate Extended Key Usage (EKU) <title abbrev="EKUs for 5G Network Functions">X.509 Certificate Extended Key Usage (EKU)
for 5G Network Functions</title> for 5G Network Functions</title>
<seriesInfo name="RFC" value="9509"/>
<author fullname="Tirumaleswar Reddy" initials="T." surname="Reddy"> <author fullname="Tirumaleswar Reddy.K" initials="T." surname="Reddy.K">
<organization>Nokia</organization> <organization>Nokia</organization>
<address> <address>
<postal> <postal>
<street></street> <street/>
<country>India</country> <country>India</country>
</postal> </postal>
<email>kondtir@gmail.com</email> <email>kondtir@gmail.com</email>
</address> </address>
</author> </author>
<author fullname="Jani Ekman" initials="J." surname="Ekman"> <author fullname="Jani Ekman" initials="J." surname="Ekman">
<organization>Nokia</organization> <organization>Nokia</organization>
<address> <address>
<postal> <postal>
<street></street> <street/>
<country>Finland</country> <country>Finland</country>
</postal> </postal>
<email>jani.ekman@nokia.com</email> <email>jani.ekman@nokia.com</email>
</address> </address>
</author> </author>
<author fullname="Daniel Migault" initials="D." surname="Migault"> <author fullname="Daniel Migault" initials="D." surname="Migault">
<organization>Ericsson</organization> <organization>Ericsson</organization>
<address> <address>
<postal> <postal>
<street></street> <street/>
<country>Canada</country> <country>Canada</country>
</postal> </postal>
<email>daniel.migault@ericsson.com</email> <email>daniel.migault@ericsson.com</email>
</address> </address>
</author> </author>
<date year="2024" month="March"/>
<date /> <area>sec</area>
<workgroup>lamps</workgroup>
<workgroup>LAMPS WG</workgroup> <keyword>3GPP</keyword>
<abstract> <abstract>
<t>RFC 5280 specifies several extended key purpose identifiers <t>RFC 5280 specifies several extended key purpose identifiers
(KeyPurposeIds) for X.509 certificates. This document defines encrypting (KeyPurposeIds) for X.509 certificates. This document defines encrypting
JSON objects in HTTP messages, JSON Web Token (JWT) and signing the JSON objects in HTTP messages, using JSON Web Tokens (JWTs), and signing
OAuth 2.0 access tokens KeyPurposeIds for inclusion in the Extended Key the OAuth 2.0 access tokens KeyPurposeIds for inclusion in the Extended
Usage (EKU) extension of X.509 v3 public key certificates used by Key Usage (EKU) extension of X.509 v3 public key certificates used by
Network Functions (NFs) for the 5G System.</t> Network Functions (NFs) for the 5G System.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section anchor="intro" title="Introduction"> <section anchor="intro" numbered="true" toc="default">
<t>The Operators of 5G ("fifth generation") systems as defined by 3GPP <name>Introduction</name>
<t>The operators of 5G ("fifth generation") systems as defined by 3GPP
make use of an internal PKI to generate X.509 PKI certificates for the make use of an internal PKI to generate X.509 PKI certificates for the
Network Functions (NFs) (Section 6 of <xref target="TS23.501"></xref>) Network Functions (NFs) (Section 6 of <xref target="TS23.501"
in a 5G system. The certificates are used for the following format="default"/>) in a 5G System. The certificates are used for the
purposes:</t> following purposes:</t>
<ul spacing="normal">
<t><list style="symbols"> <li>Client and Server certificates for NFs in 5G Core (5GC) Service Base
<t>Client and Server certificates for NFs in 5GC Service Based d
Architecture (see Section 6.1.3c of <xref Architecture (SBA) (see Section 6.1.3c of <xref target="TS33.310"
target="TS33.310"></xref>)</t> format="default"/> and Section 6.7.2 of <xref target="TS29.500"
format="default"/>)</li>
<t>Client Credentials Assertion (CCA) uses JSON Web Tokens (JWT) <li>Client Credentials Assertion (CCA) uses JSON Web Tokens (JWTs)
<xref target="RFC7519"></xref> and is secured with digital <xref target="RFC7519" format="default"/> and is secured with digital
signatures based on JSON Web Signature (JWS) <xref signatures based on the JSON Web Signature (JWS) <xref
target="RFC7515"></xref> (see Section 13.3.8.2 of <xref target="RFC7515" format="default"/> (see Section 13.3.8.2 of <xref
target="TS33.501"></xref>).</t> target="TS33.501" format="default"/>, and Section 6.7.5 of <xref
target="TS29.500" format="default"/>).</li>
<t>Certificates for encrypting JSON objects in HTTP messages between <li>Certificates for encrypting JSON objects in HTTP messages between
Security Edge Protection Proxies (SEPPs) using JSON Web Encryption Security Edge Protection Proxies (SEPPs) using JSON Web Encryption
(JWE) <xref target="RFC7516"></xref> (Section 13.2.4.4 of <xref (JWE) <xref target="RFC7516" format="default"/> (see Section 13.2.4.4
target="TS33.501"></xref>) and Section 6.3.2 of <xref of <xref target="TS33.501" format="default"/>, Section 6.3.2 of <xref
target="TS33.210"></xref>).</t> target="TS33.210" format="default"/>, Section 6.7.4 of <xref
target="TS29.500" format="default"/>, and Section 5.3.2.1 of <xref
<t>Certificates for signing the OAuth 2.0 access tokens for service target="TS29.573" format="default"/>).</li>
authorization to grant temporary access to resources provided by NF <li>Certificates for signing the OAuth 2.0 access tokens for service
producers using JWS (see Section 13.4.1 of <xref authorization to grant temporary access to resources provided by NF
target="TS33.501"></xref>).</t> producers using JWS (see Section 13.4.1 of <xref target="TS33.501"
</list></t> format="default"/> and Section 6.7.3 of <xref target="TS29.500"
format="default"/>).</li>
<t><xref target="RFC5280"></xref> specifies several key usage </ul>
<t><xref target="RFC5280" format="default"/> specifies several key usage
extensions, defined via KeyPurposeIds, for X.509 certificates. Key usage extensions, defined via KeyPurposeIds, for X.509 certificates. Key usage
extensions added to a certificate are meant to express intent as to the extensions added to a certificate are meant to express intent as to the
purpose of the named usage, for humans and for complying libraries. In purpose of the named usage, for humans and for complying libraries. In
addition, the IANA registry "SMI Security for PKIX Extended Key Purpose" addition, the IANA registry "SMI Security for PKIX Extended Key Purpose"
<xref target="RFC7299"></xref> contains additional KeyPurposeIds.The use <xref target="RFC7299" format="default"/> contains additional
of the anyExtendedKeyUsage KeyPurposeId, as defined in Section 4.2.1.12 KeyPurposeIds. The use of the anyExtendedKeyUsage KeyPurposeId, as
of <xref target="RFC5280"></xref>, is generally considered a poor defined in <xref target="RFC5280" sectionFormat="of"
practice. This is especially true for publicly trusted certificates, section="4.2.1.12"/>, is generally considered a poor practice. This is
whether they are multi-purpose or single-purpose, within the context of especially true for publicly trusted certificates, whether they are
5G systems and the 5G Core Service Based Architecture.</t> multi-purpose or single-purpose, within the context of 5G Systems and
the 5GC Service Based Architecture.</t>
<t>If the purpose of the issued certificates is not restricted, i.e., <t>If the purpose of the issued certificates is not restricted, i.e.,
the type of operations for which a public key contained in the the type of operations for which a public key contained in the
certificate can be used are not specified, those certificates could be certificate can be used are not specified, those certificates could be
used for another purpose than intended, increasing the risk of used for another purpose than intended, increasing the risk of
cross-protocol attacks. Failure to ensure proper segregation of duties cross-protocol attacks. Failure to ensure proper segregation of duties
means that a NF which generates the public/private keys and applies for means that a NF that generates the public/private keys and applies for a
a certificate to the operator CA, could obtain a certificate which can certificate to the operator certification authority could obtain a
be misused for tasks that this NF is not entitled to perform. For certificate that can be misused for tasks that this NF is not entitled
example, a NF service consumer could potentially impersonate NF service to perform. For example, a NF service consumer could potentially
producers using its certificate. Additionally, in cases where the impersonate NF service producers using its certificate. Additionally, in
certificate's purpose is intended for use by the NF service consumer as cases where the certificate's purpose is intended for use by the NF
a client certificate, it's essential to ensure that the NF with this service consumer as a client certificate, it's essential to ensure that
client certificate and the corresponding private key is not allowed to the NF with this client certificate and the corresponding private key
sign the Client Credentials Assertion (CCA). When a NF service producer are not allowed to sign the Client Credentials Assertion (CCA). When a
receives the signed CCA from the NF service consumer, the NF should only NF service producer receives the signed CCA from the NF service
accept the token if the CCA is signed with a certificate that has been consumer, the NF should only accept the token if the CCA is signed with
explicitly issued for this purpose.</t> a certificate that has been explicitly issued for this purpose.</t>
<t>The KeyPurposeId id-kp-serverAuth (<xref target="RFC5280"
<t>The KeyPurposeId id-kp-serverAuth (Section 4.2.1.12 of <xref sectionFormat="of" section="4.2.1.12"/>) can be used to identify that
target="RFC5280"></xref>) can be used to identify that the certificate the certificate is for a server (e.g., NF service producer), and the
is for a server (e.g., NF service producer), and the KeyPurposeId KeyPurposeId id-kp-clientAuth (<xref target="RFC5280"
id-kp-clientAuth (Section 4.2.1.12 of <xref target="RFC5280"></xref>) sectionFormat="of" section="4.2.1.12"/>) can be used to identify that
can be used to identify that the certificate is for a client (e.g., NF the certificate is for a client (e.g., NF service consumer). However,
service consumer). However, there are currently no KeyPurposeIds for the there are currently no KeyPurposeIds for the other usages of
other usages of certificates in 5G System. This document addresses the certificates in a 5G System. This document addresses the above problem by
above problem by defining the Extended Key Usage (EKU) extension of defining the EKU extension of X.509 public key certificates for signing
X.509 public key certificates for signing the JWT Claims set using JWS, the JWT Claims Set using JWS, encrypting JSON objects in HTTP messages
encrypting JSON objects in HTTP messages using JWE, and signing the using JWE, and signing the OAuth 2.0 access tokens using JWS.</t>
OAuth 2.0 access tokens using JWS.</t>
<t>Vendor-defined KeyPurposeIds used within a PKI governed by the vendor <t>Vendor-defined KeyPurposeIds used within a PKI governed by the vendor
or a group of vendors typically do not pose interoperability concerns, or a group of vendors typically do not pose interoperability concerns,
as non-critical extensions can be safely ignored if unrecognized. as non-critical extensions can be safely ignored if unrecognized.
However, using or misusing KeyPurposeIds outside of their intended However, using or misusing KeyPurposeIds outside of their intended
vendor-controlled environment can lead to interoperability issues. vendor-controlled environment can lead to interoperability issues.
Therefore, it is advisable not to rely on vendor-defined KeyPurposeIds. Therefore, it is advisable not to rely on vendor-defined KeyPurposeIds.
Instead, the specification defines standard KeyPurposeIds to ensure Instead, the specification defines standard KeyPurposeIds to ensure
interoperability across various implementations.</t> interoperability across various implementations.</t>
<t>Although the specification focuses on a 5G use case, the standard <t>Although the specification focuses on a 5G use case, the standard
KeyPurposeIds defined in this document can be used in other KeyPurposeIds defined in this document can be used in other
deployments.</t> deployments.</t>
</section> </section>
<section anchor="notation" numbered="true" toc="default">
<section anchor="notation" title="Terminology"> <name>Terminology</name>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", <t> The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
"OPTIONAL" in this document are to be interpreted as described in BCP 14 NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
<xref target="RFC2119"></xref><xref target="RFC8174"></xref> when, and "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
only when, they appear in all capitals, as shown here.</t> "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document
are to be interpreted as described in BCP&nbsp;14 <xref
target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they
appear in all capitals, as shown here.
</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Extended Key Purpose for Network Functions"> <name>Extended Key Purpose for Network Functions</name>
<t>This specification defines the KeyPurposeIds id-kp-jwt, <t>This specification defines the KeyPurposeIds id-kp-jwt,
id-kp-httpContentEncrypt, id-kp-oauthAccessTokenSigning and uses these id-kp-httpContentEncrypt, and id-kp-oauthAccessTokenSigning
for respectively signing the JWT Claims set of CCA using JWS, encrypting and uses these, respectively, for: signing the JWT Claims Set
JSON objects in HTTP messages between Security Edge Protection Proxies of CCA using JWS, encrypting JSON objects in HTTP messages between
(SEPPs) using JWE and signing the OAuth 2.0 access tokens for service Security Edge Protection Proxies (SEPPs) using JWE, and signing the
authorization to grant temporary access to resources provided by NF OAuth 2.0 access tokens for service authorization to grant temporary
producers using JWS. As described in <xref target="RFC5280"></xref>, access to resources provided by NF producers using JWS. As described in
"[i]f the [Extended Key Usage] extension is present, then the <xref target="RFC5280" format="default"/>, "[i]f the [Extended Key
certificate MUST only be used for one of the purposes indicated." <xref Usage] extension is present, then the certificate <bcp14>MUST</bcp14>
target="RFC5280"></xref> also notes that "[i]f multiple [key] purposes only be used for one of the purposes indicated." <xref target="RFC5280"
are indicated the application need not recognize all purposes indicated, format="default"/> also notes that "[i]f multiple [key] purposes are
as long as the intended purpose is present."</t> indicated the application need not recognize all purposes indicated, as
long as the intended purpose is present."</t>
<t>Network functions that verify the signature of a CCA represented as a <t>Network Functions that verify the signature of a CCA represented as a
JWT, decrypt JSON objects in HTTP messages between Security Edge JWT, decrypt JSON objects in HTTP messages between Security Edge
Protection Proxies (SEPPs) using JWE, or verify the signature of an Protection Proxies (SEPPs) using JWE, or verify the signature of an
OAuth 2.0 access tokens for service authorization to grant temporary OAuth 2.0 access tokens for service authorization to grant temporary
access to resources provided by NF producers using JWS SHOULD require access to resources provided by NF producers using JWS
the specification of corresponding KeyPurposeIds by the Extended Key <bcp14>SHOULD</bcp14> require that corresponding
Usage (EKU) extension. If the certificate requester knows the KeyPurposeIds be specified by the EKU extension. If the certificate reques
certificate users are mandated to use these KeyPurposeIds, it MUST ter knows
enforce their inclusion. Additionally, such certificate requester MUST the certificate users are mandated to use these KeyPurposeIds, it
ensure that the KeyUsage extension be set to digitalSignature or <bcp14>MUST</bcp14> enforce their inclusion. Additionally, such
nonRepudiation (also designated as contentCommitment) for signature a certificate requester <bcp14>MUST</bcp14> ensure that the KeyUsage
calculation and/or to keyEncipherment for secret key encryption.</t> extension be set to digitalSignature or nonRepudiation (also designated
as contentCommitment) for signature calculation and/or to
keyEncipherment for secret key encryption.</t>
</section> </section>
<section numbered="true" toc="default" anchor="purpose-in-certificates">
<name>Including the Extended Key Purpose in Certificates</name>
<t><xref target="RFC5280" format="default"/> specifies the EKU X.509
certificate extension for use on end entity certificates. The extension
indicates one or more purposes for which the certified public key is
valid. The EKU extension can be used in conjunction with the key usage
extension, which indicates the set of basic cryptographic operations for
which the certified key may be used. The EKU extension syntax is
repeated here for convenience:</t>
<section title="Including the Extended Key Purpose in Certificates"> <sourcecode type="asn.1"><![CDATA[
<t><xref target="RFC5280"></xref> specifies the Extended Key Usage (EKU) ExtKeyUsageSyntax ::= SEQUENCE SIZE (1..MAX) OF KeyPurposeId
X.509 certificate extension for use on end entity certificates. The
extension indicates one or more purposes for which the certified public
key is valid. The EKU extension can be used in conjunction with the key
usage extension, which indicates the set of basic cryptographic
operations for which the certified key may be used. The EKU extension
syntax is repeated here for convenience:</t>
<figure>
<artwork><![CDATA[ExtKeyUsageSyntax ::= SEQUENCE SIZE (1..MAX) OF KeyPur
poseId
KeyPurposeId ::= OBJECT IDENTIFIER KeyPurposeId ::= OBJECT IDENTIFIER
]]></artwork> ]]></sourcecode>
</figure>
<t></t>
<t>As described in <xref target="RFC5280"></xref>, the EKU extension <t>As described in <xref target="RFC5280" format="default"/>, the EKU
may, at the option of the certificate issuer, be either critical or extension may, at the option of the certificate issuer, be either
non-critical. The inclusion of KeyPurposeId id-kp-jwt, critical or non-critical. The inclusion of KeyPurposeIds id-kp-jwt,
id-kp-httpContentEncrypt, and id-kp-oauthAccessTokenSigning in a id-kp-httpContentEncrypt, and id-kp-oauthAccessTokenSigning in a
certificate indicates that the public key encoded in the certificate has certificate indicates that the public key encoded in the certificate has
been certified for use in the following: <list style="numbers"> been certified for use in the following: </t>
<t>Validating the JWS Signature in JWT. The distinction between JWS
and JWE is determined by the KU that is set to digitalSignature or
nonRepudiation for JWS and keyEncipherment for JWE.</t>
<t>Encrypting JSON objects in HTTP messages (for example, encrypting
the CEK with the recipient's public key using the RSAES-OAEP
algorithm to produce the JWE Encrypted Key). KU is set to
keyEncipherment.</t>
<t>Signing OAuth 2.0 access tokens. In this case, KU is set to
digitalSignature or nonRepudiation.</t>
</list></t>
<t><figure> <ol spacing="normal" type="1">
<artwork><![CDATA[ id-kp OBJECT IDENTIFIER ::= { <li>Validating the JWS Signature in JWT. The distinction between JWS
and JWE is determined by the Key Usage (KU) that is set to
digitalSignature or nonRepudiation for JWS and keyEncipherment for
JWE.</li>
<li>Encrypting JSON objects in HTTP messages (for example, encrypting
the content-encryption key (CEK) with the recipient's public key using
the RSAES-OAEP algorithm to produce the JWE Encrypted Key). KU is set
to keyEncipherment.</li>
<li>Signing OAuth 2.0 access tokens. In this case, KU is set to
digitalSignature or nonRepudiation.</li>
</ol>
<sourcecode type="asn.1"><![CDATA[
id-kp OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) dod(6) internet(1) iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) kp(3) } security(5) mechanisms(5) pkix(7) kp(3) }
id-kp-jwt OBJECT IDENTIFIER ::= { id-kp TBD1 } id-kp-jwt OBJECT IDENTIFIER ::= { id-kp 37 }
id-kp-httpContentEncrypt OBJECT IDENTIFIER ::= { id-kp TBD2 } id-kp-httpContentEncrypt OBJECT IDENTIFIER ::= { id-kp 38 }
id-kp-oauthAccessTokenSigning OBJECT IDENTIFIER ::= { id-kp TBD3 } id-kp-oauthAccessTokenSigning OBJECT IDENTIFIER ::= { id-kp 39 }
]]></artwork> ]]></sourcecode>
</figure></t>
</section> </section>
<section anchor="solution" numbered="true" toc="default">
<section anchor="solution" <name>Implications for a Certification Authority</name>
title="Implications for a Certification Authority">
<t>The procedures and practices employed by a certification authority <t>The procedures and practices employed by a certification authority
MUST ensure that the correct values for the EKU extension as well as the <bcp14>MUST</bcp14> ensure that the correct values for the EKU extension a s well as the
KU extension are inserted in each certificate that is issued. The KU extension are inserted in each certificate that is issued. The
inclusion of the id-kp-jwt, id-kp-httpContentEncrypt and inclusion of the id-kp-jwt, id-kp-httpContentEncrypt, and
id-kp-oauthAccessTokenSigning KeyPurposeIds does not preclude the id-kp-oauthAccessTokenSigning KeyPurposeIds does not preclude the
inclusion of other KeyPurposeIds.</t> inclusion of other KeyPurposeIds.</t>
</section> </section>
<section anchor="Security" numbered="true" toc="default">
<section anchor="Security" title="Security Considerations"> <name>Security Considerations</name>
<t>The Security Considerations of <xref target="RFC5280"></xref> are <t>The Security Considerations of <xref target="RFC5280"
applicable to this document. This extended key purpose does not format="default"/> are applicable to this document. This extended key
introduce new security risks but instead reduces existing security risks purpose does not introduce new security risks but instead reduces
by providing means to identify if the certificate is generated to sign existing security risks by providing the means to identify if the
the JWT Claims Set, signing the OAuth 2.0 access tokens using JWS or to certificate is generated to sign the JWT Claims Set, signing the OAuth
encrypt the CEK in JWE for encrypting JSON objects in HTTP messages.</t> 2.0 access tokens using JWS, or encrypting the CEK in JWE for encrypting
JSON objects in HTTP messages.</t>
<t>To reduce the risk of specific cross-protocol attacks, the relying <t>To reduce the risk of specific cross-protocol attacks, the relying
party or the relying party software may additionally prohibit use of party or the relying party software may additionally prohibit use of
specific combinations of KeyPurposeIds. The procedure for allowing or specific combinations of KeyPurposeIds. The procedure for allowing or
disallowing combinations of KeyPurposeIds using Excluded KeyPurposeId disallowing combinations of KeyPurposeIds using Excluded KeyPurposeId
and Permitted KeyPurposeId, as carried out by a relying party, is and Permitted KeyPurposeId, as carried out by a relying party, is
defined in Section 4 of <xref target="RFC9336"></xref>. Examples of defined in <xref target="RFC9336" sectionFormat="of"
Excluded KeyPurposeId include the presence of the anyExtendedKeyUsage section="4"/>. Examples of Excluded KeyPurposeIds include the presence of
KeyPurposeId or the complete absence of the EKU extension in a the anyExtendedKeyUsage KeyPurposeId or the complete absence of the EKU
certificate. Examples of Permitted KeyPurposeId include the presence of extension in a certificate. Examples of Permitted KeyPurposeIds include
id-kp-jwt, id-kp-httpContentEncrypt or id-kp-oauthAccessTokenSigning the presence of id-kp-jwt, id-kp-httpContentEncrypt, or
KeyPurposeId.</t> id-kp-oauthAccessTokenSigning KeyPurposeIds.</t>
</section> </section>
<section anchor="Privacy" numbered="true" toc="default">
<section anchor="Privacy" title="Privacy Considerations"> <name>Privacy Considerations</name>
<t>In some security protocols, such as TLS 1.2 <xref <t>In some security protocols, such as TLS 1.2 <xref target="RFC5246"
target="RFC5246"></xref>, certificates are exchanged in the clear. In format="default"/>, certificates are exchanged in the clear. In other
other security protocols, such as TLS 1.3 <xref security protocols, such as TLS 1.3 <xref target="RFC8446"
target="RFC8446"></xref>, the certificates are encrypted. The inclusion format="default"/>, the certificates are encrypted. The inclusion of the
of the EKU extension can help an observer determine the purpose of the EKU extension can help an observer determine the purpose of the
certificate. In addition, If the certificate is issued by a public certificate. In addition, if the certificate is issued by a public
certification authority, the inclusion of EKU extension can help an certification authority, the inclusion of an EKU extension can help an
attacker to monitor the Certificate Transparency logs <xref attacker to monitor the Certificate Transparency logs <xref
target="RFC9162"></xref> to identify the purpose of the certificate.</t> target="RFC9162" format="default"/> to identify the purpose of the
certificate.</t>
</section> </section>
<section anchor="IANA" numbered="true" toc="default">
<section anchor="IANA" title="IANA Considerations"> <name>IANA Considerations</name>
<t>IANA is requested to register the following OIDs in the "SMI Security <t>IANA has registered the following OIDs in the "SMI Security
for PKIX Extended Key Purpose" registry (1.3.6.1.5.5.7.3). These OIDs for PKIX Extended Key Purpose" registry (1.3.6.1.5.5.7.3). These OIDs
are defined in Section 4.</t> are defined in <xref target="purpose-in-certificates"/>.</t>
<figure anchor="fig-a">
<name>Table 1</name>
<artwork><![CDATA[
+=========+===============================+============+
| Decimal | Description | References |
+=========+===============================+============+
| TBD1 | id-kp-jwt | This-RFC |
+---------+-------------------------------+------------+
| TBD2 | id-kp-httpContentEncrypt | This-RFC |
+---------+-------------------------------+------------+
| TBD3 | id-kp-oauthAccessTokenSigning | This-RFC |
+---------+-------------------------------+------------+
]]></artwork>
</figure>
<t></t>
<t>IANA is also requested to register the following ASN.1<xref
target="X.680"></xref> module OID in the "SMI Security for PKIX Module
Identifier" registry (1.3.6.1.5.5.7.0). This OID is defined in <xref
target="Appendix"></xref>.</t>
<t><figure anchor="fig-b">
<name>Table 2</name>
<artwork><![CDATA[
+=========+==========================+============+
| Decimal | Description | References |
+=========+==========================+============+
| TBD4 | id-mod-nf-eku | This-RFC |
+---------+--------------------------+------------+
]]></artwork>
</figure></t>
</section>
<section anchor="contrib" title="Contributors"> <table anchor="iana-table-1" align="left">
<t>The following individuals have contributed to this document:</t> <thead>
<tr>
<th>Decimal</th>
<th>Description</th>
<th>References</th>
</tr>
</thead>
<tbody>
<tr>
<td>37</td>
<td>id-kp-jwt</td>
<td>RFC 9509</td>
</tr>
<tr>
<td>38</td>
<td>id-kp-httpContentEncrypt</td>
<td>RFC 9509</td>
</tr>
<tr>
<td>39</td>
<td>id-kp-oauthAccessTokenSigning</td>
<td>RFC 9509</td>
</tr>
</tbody>
</table>
<t><figure> <t>IANA has registered the following ASN.1<xref
<artwork><![CDATA[ German Peinado target="X.680" format="default"/> module OID in the "SMI Security for PKIX
Nokia Module Identifier" registry (1.3.6.1.5.5.7.0). This OID is defined
in <xref target="Appendix" format="default"/>.</t>
Email: german.peinado@nokia.com]]></artwork> <table anchor="iana-table-2" align="left">
</figure></t> <thead>
<tr>
<th>Decimal</th>
<th>Description</th>
<th>References</th>
</tr>
</thead>
<tbody>
<tr>
<td>108</td>
<td>id-mod-nf-eku</td>
<td>RFC 9509</td>
</tr>
</tbody>
</table>
</section> </section>
<section anchor="acknowledgments" title="Acknowledgments">
<t>We would like to thank Corey Bonnell, Ilari Liusvaara, Carl Wallace
and Russ Housley for their useful feedback. Thanks to Yoav Nir for the
secdir review, Elwyn Davies for the genart review and Benson Muite for
the intdir review.</t>
<t>Thanks to Paul Wouters, Lars Eggert, and &Eacute;ric Vyncke for the
IESG review.</t>
</section>
</middle> </middle>
<back> <back>
<references title="Normative References"> <references>
<?rfc include="reference.RFC.2119"?> <name>References</name>
<references>
<?rfc include="reference.RFC.8174"?> <name>Normative References</name>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
<?rfc include="reference.RFC.5280"?> 119.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<?rfc include="reference.RFC.7515"?> 174.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
<?rfc include="reference.RFC.7519"?> 280.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
<?rfc include="reference.RFC.7516"?> 515.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
<!-- <?rfc include="reference.RFC.7159"?> --> 519.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
<!-- <?rfc include="reference.RFC.9052"?> --> 516.xml"/>
<!-- <?rfc include="reference.RFC.8949"?> -->
<reference anchor="X.680" target="https://www.itu.int/rec/T-REC-X.680"> <reference anchor="X.680" target="https://www.itu.int/rec/T-REC-X.680">
<front> <front>
<title>ITU-T, "Information technology - Abstract Syntax Notation One <title>Information technology - Abstract Syntax Notation One
(ASN.1): Specification of basic notation", ITU-T Recommendation (ASN.1): Specification of basic notation</title>
X.680, February 2021.</title> <author>
<organization>ITU-T</organization>
<author> </author>
<organization></organization> <date month="February" year="2021"/>
</author> </front>
<seriesInfo name="ITU-T Recommendation" value="X.680"/>
<date day="" month="" year="" /> </reference>
</front>
</reference>
<reference anchor="X.690" target="https://www.itu.int/rec/T-REC-X.690">
<front>
<title>ITU-T, "Information technology - ASN.1 encoding rules:
Specification of Basic Encoding Rules (BER), Canonical Encoding
Rules (CER) and Distinguished Encoding Rules (DER)", ITU-T
Recommendation X.690, February 2021,</title>
<author>
<organization></organization>
</author>
<date day="" month="" year="" />
</front>
</reference>
</references>
<references title="Informative References">
<?rfc include='reference.RFC.5246'?>
<?rfc include='reference.RFC.8446'
?>
<?rfc include="reference.RFC.7299"?>
<?rfc include="reference.RFC.9336"?>
<?rfc include="reference.RFC.9162"?>
<!-- <?rfc include="reference.RFC.7518"?> -->
<reference anchor="TS33.501"
target="https://www.3gpp.org/ftp/Specs/archive/33_series/33.501
/33501-h70.zip">
<front>
<title>3rd Generation Partnership Project; Technical Specification
Group Services and System Aspects; Security architecture and
procedures for 5G system (Release 17), , 3GPP TS:33.501 V17.7.0,
Sept 2022,</title>
<author>
<organization></organization>
</author>
<date day="" month="" year="" /> <reference anchor="X.690" target="https://www.itu.int/rec/T-REC-X.690">
</front> <front>
</reference> <title>Information technology - ASN.1 encoding rules:
Specification of Basic Encoding Rules (BER), Canonical Encoding
Rules (CER) and Distinguished Encoding Rules (DER)</title>
<author>
<organization>ITU-T</organization>
</author>
<date month="February" year="2021"/>
</front>
<seriesInfo name="ITU-T Recommendation" value="X.690"/>
</reference>
<reference anchor="TS33.310" </references>
target="https://www.3gpp.org/ftp/Specs/archive/33_series/33.310
/33310-h40.zip">
<front>
<title>3rd Generation Partnership Project; Technical Specification
Group Services and System Aspects; Network Domain Security (NDS);
Authentication Framework (AF) (Release 17), 3GPP 33.310 V17.4.0,
Sept 2022,</title>
<author> <references>
<organization></organization> <name>Informative References</name>
</author> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
246.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
446.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
299.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
336.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
162.xml"/>
<date day="" month="" year="" /> <reference anchor="TS29.573" target="https://www.3gpp.org/ftp/Specs/archiv
</front> e/29_series/29.573/29573-i50.zip">
<front>
<title>5G System; Public Land Mobile Network (PLMN) Interconnection; St
age 3</title>
<author>
<organization>3GPP</organization>
</author>
<date month="December" year="2023"/>
</front>
<seriesInfo name="Release" value="18.5.0"/>
<seriesInfo name="3GPP TS" value="29.573"/>
</reference> </reference>
<reference anchor="TS33.210" <reference anchor="TS33.501" target="https://www.3gpp.org/ftp/Specs/archiv
target="https://www.3gpp.org/ftp/Specs/archive/33_series/33.210 e/33_series/33.501/33501-i40.zip">
/33210-h10.zip"> <front>
<front> <title>Security architecture and procedures for 5G system</title>
<title>3rd Generation Partnership Project; Technical Specification <author>
Group Services and System Aspects;Network Domain Security (NDS); IP <organization>3GPP</organization>
network layer security (Release 17), 3GPP TS 33.210 V17.1.0 Sept </author>
2022,</title> <date month="December" year="2023"/>
</front>
<seriesInfo name="Release" value="18.4.0"/>
<seriesInfo name="3GPP TS" value="33.501"/>
</reference>
<author> <reference anchor="TS33.310" target="https://www.3gpp.org/ftp/Specs/arch
<organization></organization> ive/33_series/33.310/33310-i20.zip">
</author> <front>
<title>Network Domain Security (NDS); Authentication Framework
(AF)</title>
<author>
<organization>3GPP</organization>
</author>
<date month="December" year="2023"/>
</front>
<seriesInfo name="Release" value="18.2.0"/>
<seriesInfo name="3GPP TS" value="33.310"/>
</reference>
<date day="" month="" year="" /> <reference anchor="TS33.210" target="https://www.3gpp.org/ftp/Specs/arch
</front> ive/33_series/33.210/33210-h10.zip">
</reference> <front>
<title>Network Domain Security (NDS); IP network layer
security</title>
<author>
<organization>3GPP</organization>
</author>
<date month="September" year="2022"/>
</front>
<seriesInfo name="Release" value="17.1.0"/>
<seriesInfo name="3GPP TS" value="33.210"/>
</reference>
<reference anchor="TS23.501" <reference anchor="TS23.501" target="https://www.3gpp.org/ftp/Specs/arch
target="https://www.3gpp.org/ftp/Specs/archive/23_series/23.501 ive/23_series/23.501/23501-i40.zip">
/23501-i00.zip"> <front>
<front> <title>System architecture for the 5G System (5GS)</title>
<title>3rd Generation Partnership Project; Technical Specification <author>
Group Services and System Aspects; System architecture for the 5G <organization>3GPP</organization>
System (5GS); Stage 2 (Release 18), 3GPP TS 23.501 V18.0.0 Dec </author>
2022,</title> <date month="December" year="2023"/>
</front>
<seriesInfo name="Release" value="18.4.0"/>
<seriesInfo name="3GPP TS" value="23.501"/>
</reference>
<author> <reference anchor="TS29.500" target="https://www.3gpp.org/ftp/Specs/archi
<organization></organization> ve/29_series/29.500/29500-i40.zip">
</author> <front>
<title>5G System; Technical Realization of Service Based Architecture
; Stage 3</title>
<author>
<organization>3GPP</organization>
</author>
<date month="December" year="2023"/>
</front>
<seriesInfo name="Release" value="18.4.0"/>
<seriesInfo name="3GPP TS" value="29.500"/>
</reference>
<date day="" month="" year="" /> </references>
</front>
</reference>
</references> </references>
<section anchor="Appendix" title="ASN.1 Module"> <section anchor="Appendix" numbered="true" toc="default">
<t>The following module adheres to ASN.1 specifications <xref <name>ASN.1 Module</name>
target="X.680"></xref> and <xref target="X.690"></xref>.</t> <t>The following module adheres to ASN.1 specifications <xref target="X.68
0" format="default"/> and <xref target="X.690" format="default"/>.</t>
<figure> <sourcecode name="" type="asn.1" markers="true"><![CDATA[
<artwork><![CDATA[<CODE BEGINS>
NF-EKU NF-EKU
{ iso(1) identified-organization(3) dod(6) internet(1) { iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0) security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-nf-eku (TBD4) } id-mod-nf-eku (108) }
DEFINITIONS IMPLICIT TAGS ::= DEFINITIONS IMPLICIT TAGS ::=
BEGIN BEGIN
-- OID Arc -- OID Arc
id-kp OBJECT IDENTIFIER ::= id-kp OBJECT IDENTIFIER ::=
{ iso(1) identified-organization(3) dod(6) internet(1) { iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) kp(3) } security(5) mechanisms(5) pkix(7) kp(3) }
-- Extended Key Usage Values -- Extended Key Usage Values
id-kp-jwt OBJECT IDENTIFIER ::= { id-kp TBD1 } id-kp-jwt OBJECT IDENTIFIER ::= { id-kp 37 }
id-kp-httpContentEncrypt OBJECT IDENTIFIER ::= { id-kp TBD2 } id-kp-httpContentEncrypt OBJECT IDENTIFIER ::= { id-kp 38 }
id-kp-oauthAccessTokenSigning OBJECT IDENTIFIER ::= { id-kp TBD3 } id-kp-oauthAccessTokenSigning OBJECT IDENTIFIER ::= { id-kp 39 }
END END
]]></sourcecode>
<CODE ENDS>]]></artwork> </section>
</figure>
<section anchor="acknowledgments" numbered="false" toc="default">
<name>Acknowledgments</name>
<t>We would like to thank <contact fullname="Corey Bonnell"/>, <contact
fullname="Ilari Liusvaara"/>, <contact fullname="Carl Wallace"/>, and
<contact fullname="Russ Housley"/> for their useful feedback. Thanks to
<contact fullname="Yoav Nir"/> for the secdir review, <contact
fullname="Elwyn Davies"/> for the genart review, and <contact
fullname="Benson Muite"/> for the intdir review.</t>
<t>Thanks to <contact fullname="Paul Wouters"/>, <contact fullname="Lars
Eggert"/>, and <contact fullname="Éric Vyncke"/> for the IESG
review.</t>
</section> </section>
<section anchor="contrib" numbered="false" toc="default">
<name>Contributor</name>
<t>The following individual has contributed to this document:</t>
<contact fullname="German Peinado">
<organization>Nokia</organization>
<address>
<email>german.peinado@nokia.com</email>
</address>
</contact>
</section>
</back> </back>
</rfc> </rfc>
 End of changes. 67 change blocks. 
387 lines changed or deleted 402 lines changed or added

This html diff was produced by rfcdiff 1.48.