Automatic certificate management environment for virtual network function certificate provisioning

Abstract

There is provided a method for certificate provisioning. The method being performed by a client. The method comprises obtaining a key. The method further comprises obtaining, using the key, a certificate from a certification server.

Description

AUTOMATIC CERTIFICATE MANAGEMENT ENVIRONMENT FOR VIRTUALNETWORK FUNCTION CERTIFICATE PROVISIONINGTechnical Field

[0001] The present disclosure relates to methods and apparatuses for supporting authorization procedures, in particular methods and apparatuses for supporting the issuance of certificates based on Automatic Certificate Management Environment (ACME).BackgroundHigh level position of Automatic Certificate Management Environment (ACME) versus Certificate Management Protocol (CMP)

[0002] Issuing certificates based on a trust relation: Currently, 3rdGeneration Partnership Project (3GPP) certificates are issued by a Certificate Authority (CA) via the Certificate Management Protocol (CMP). With CMP the CA receives a certificate request and issues the certificate if that request 1) comes from the legitimate Mobile Network Operator (MNO) and 2) if the request itself matches the profile (e.g authorized values) of the MNO. The trust model assumes a trust relation between the MNO and the CA. The MNO configures the CA with authentication credential for each CMP clients. Authentication credentials consists in an One Time Password (OTP) or a serial number certified by a vendor CA. In addition, the MNO configures the CA for each CMP client with the identifiers and attributes that are expected to be found in issued certificate (by way of example: subject ID, instance ID, NF Type). Subsequently, the CMP request is authenticated, and the CA issues a certificate as it has been configured for. The CA assumes the information in the issued certificate is valid. It trusts the MNO has provided valid information. The establishment of the trust cannot be fully automated.

[0003] Issuing certificates over checking the requester controls the resource: To enable automation, Automated Certificate Management Environment (ACME) (see RFC8555, Automatic Certificate Management Environment (ACME) by the Internet Engineering Task Force (IETF), available at https: / / datatracker.ietf.org / doc / html / rfc8555 as of 18 February 2024) does not rely on the applicant identity, but instead ensures the certificate can be issued with some relatively high confidence. When the certificate binds a fully qualified domain name (FQDN) to a key, the certificate can be issued when there is sufficient confidence that the owner of the key owns the FQDN. When the resource is a strongly typed networking resource that can be administered, such as an internet protocol (IP) address or a FQDN or a web server, the CA can expect the owner to prove its ability to manage the resource in a specific way. The CA acts to validate that ability to manage the resource appropriately and from such ability will infer the ownership of the resource. Validation challenges can beautomated both by the MNO and the CA as these mostly involve manageable networking resources. ACME is also very flexible in the sense that any challenge that provides sufficient confidence can be used. This makes it possible to establish specific challenges that are very convenient to the MNO.

[0004] In some cases, the resource to be associated with the key cannot be challenged by the CA; for example, when the CA does not have access to the MNO. In that case, the CA can delegate the validation to a Token Authority which will validate the legitimacy of the resource. The procedure requires a one-time-configuration to establish the trust between the Token Authority and the CA, but once set and assuming the validation of the parameters can be automatically checked, the procedure can be considered automated.

[0005] Automation and limit of the trustworthiness of the challenges: The main advantage of ACME for the Web Public Key Infrastructure (PKI) is that it does not rely on the establishment of a trust relation between all certificate requesters and the CA. This is particularly useful when multiple applicants are requesting the issuance of a single or a very limited amount of certificates. On the other hand, registration may not be an issue when one applicant requests the issuance of a few thousands certificates.

[0006] The ability for a CA to challenge the resources mentioned in the certificate requires the resources to be manageable (in some ways) and be accessible by the CA. This is (mostly) the case for FQDN, URL except that this information (unlike a web site) is not expected to be public information and as such some specific deployment will probably need to be deployed between the MNO and the CA. In addition, the trust associated with the challenges will also need to be re-evaluated in the light of the issuance of certificates for critical infrastructure. For example, Domain Name System (DNS) or Hypertext Transfer Protocol (HTTP) based challenges are unlikely to meet the necessary trust for an infrastructure while they could be considered as sufficiently trustworthy for a web site. For resources like UTF8 strings mentioned in the certificate Subject as well as for Uniform Resource Names (URN), it is not possible for the CA to validate the challenge. The use of a Token Authority is mostly useful for real time validation of identifiers. For MNO, the parameters are likely to be set once-for- all in which case the complexity associated with providing an always-on online service should be balanced with a configuration file shared to the CA by the MNO.ACME objects

[0007] The ACME resources and relations are described in RFC8555, as cited herein. A diagram of ACME resources and relationships is provided in Figure 1, which is taken from RFC8555.

[0008] There currently exist certain challenge(s). As a consequence of the above, automation provided by ACME may not be superior in all ways to that using CMP in the case of MNO as 1) registration to the CA and CA provisioning is close to the one-for-all model, and 2) 3GPP certificates contain identifiers that cannot be challenged easily by the CA. If deployed for MNO ACME will likely require the MNO to register to the CA and provision the CA with some specific configurations. However, ACME enables the issuance of certificates whose coherence is at least partly or fully checked. Also, ACME is becoming more and more popular and it seems legitimate that CA or MNOs are considering ritualizing their CA infrastructure and use ACME to issue certificates for their 6G infrastructure.

[0009] Traditionally certificates are issued using CMP which really matches the use case where certificates are issued based on configuring the CA with the parameters to be issued in the X509 certificate. ACME really fits the model where no trust relation exists between the CA and the MNO and where the MNO can prove some control over the identifiers / attributes to be indicated in the certificate. The challenges to overcome include: 1. Issuing certificate with identifiers / attributes for which there is no way to prove any control over. 2. Handle policies that are based on a per ACME Client basis, which require the ACME Client to be authenticated. 3. Optimize ACME that is by default a 7 exchanges protocol toward CMP that is a 1 exchange protocol.

[0010] A key concept in ACME which is also a cause of many problems is that the client has to prove to the CA that it has control over the identifiers / attributes it asks the CA to add into the certificate. This works fine in WEB settings where servers ask the CA to add a list of DNS-ID entries in the certificate subject alternative (SAN) field. The owner of server (where the ACME Client resides) can cooperate with a DNS which will result in that the CA can check by challenging the client that the ACME Client indeed is in control of the DNS-IDs it asks to be included in the SAN of the server certificate. But this approach does not work when the server certificate profile like for the Service-Based Architecture (SBA) also includes attributes that do not lend themselves to be challenged by the CA as to show control over. In the remainder we refer to this as having means to show to the CA that the client is authorized to claim the use of the attribute value. To exemplify some attributes that the ACME Server has challenges verifying, include an unresolvable FQDN DNS or IP address of the SBA entity (the SBA interface is not typically reachable from the management network, and the SBA interface is not a Public world wide web interface, to which it is easy to add e.g. tokens, but it is an specified API) Moreover, SBA client does not have an interface listening. Some attributes are also such, that are not possible to verify e.g. from ownership of a DNS or IP, such as nffype or InstancelD.Summary

[0011] It is an object of the present disclosure to support the use of ACME for certificate issuance.

[0012] Certain aspects of the disclosure and their embodiments may provide solutions to the above or other challenges.

[0013] According to a first aspect of the present disclosure there is provided a method performed by a client for certificate provisioning, the method comprising: obtaining a key; and obtaining, using the key, a certificate from a certification server.

[0014] According to a second aspect of the present disclosure there is provided a method performed by a token authority for certificate provisioning, the method comprising: receiving a request from a client for authorization for at least one attribute and / or identifier; and providing a token to the client, wherein the token is for use in obtaining a certificate.

[0015] According to a third aspect of the present disclosure there is provided a method performed by a certification server for certificate provisioning, the method comprising: receiving a certificate signing request, CSR, from a client; and providing a certificate to the client in response to receiving the CSR.

[0016] Further aspects of the present disclosure provide user equipments, network nodes and core network nodes for executing the methods disclosed herein.

[0017] Embodiments provide different architectures on how ACME can be used to issue certificates for SBA. The main challenge consists in adding identifiers / attributes for which there is no other means than implied trust to make them as authorized. A first set of architectures leverages the Token Authority that has been put in place to meet similar goals and adapt them to our use case: SBA. The resulting architectures remain relatively complex. However, its main advantage is that it preserves the ACME Server from several modifications. Such solutions are expected to meet the goals of the Cloud Providers, but not necessarily the goals of the MNO for which certificate issuance looks more complex both in term of management as well as in term of the number of exchanges that are required.

[0018] Another set of proposed architectures considers the ability to pre-authorize identifiers / attributes, which leads to a significantly simpler architecture, but the ACME Server may undergo some modifications. The general approach is to update the state machine for the enrolment to remain as close as possible to the standard ACME Server and even ensure compatibility with legacy ACME Clients. On the other hand, the number of exchanges remains high with unnecessary states. An optimized version proposes to remove the unnecessary states, and reduce the overall issuance to 2 exchanges only.

[0019] ACME has been designed to automate the issuance of certificates. The primary assumption for ACME to make automation possible is that a challenge can be performed - such as checking control of a FQDN. In the scope of 3GPP certificates this is not typically practical. For example, there is typically no way for a CA to check that the entity requesting the certificate will be an Application Management Function (AMF) or a Session Management Function (SMF), or that one specific Universally Unique ID (UUID) is legitimate to request the certificate. As result, the issuance of 3GPP certificates mostly relies on authenticating the entity requesting the certificate and determining from a configuration whether that specific client is legitimate for such a request or not. ACME is not necessarily suitable for such usage, but ACME is widely deployed in the IT world, so there is an advantage for being able to issue these certificates using ACME. Adapting ACME to meet the 3GPP use case may require:1. The definition of a new token that will contain all attributes of the X509 certificate and expected to be validated by the Token Authority (for the Token Authority Architecture).2. The definition of new identifiers, new challenge (associated to the attributes of the X509 certificate) when the Pre- Authorization Architecture is used.3. The ability for the ACME Server to authenticate an ACME Client and associate a specific configuration. That configuration may remain quite high level in the case of the ACME Token Authority Architecture, but in the case of the ACME Pre-Authorization Architecture, such profiling is very specific to each identifier type and value. This is new as ACME is expected to rely on challenges being performed to grant authorization.4. The ability to reduce the number of exchanges between the ACME Client and the ACME Server.5. ACME authentication is handled specifically to ensure the authentication credentials are only used once.Regarding the impact using ACME versus CMP, the changes on the CMP client may include:1. With the ACME Token Authority Architecture, the ACME Client deals with two distinct entities for the issuance. The two entities are the ACME Server and the Token Authority. They have different URLs but the Token Authority may belong to the CA, the MNO as an independent entity or as part of the Certificate Management Function CMF.2. Unless optimized, ACME involves multiple operations (exchanges) like the creation of an ACME account, the request for an authorization. Certain embodiments may provide one or more of the following technical advantage(s). Embodiments may facilitate the issuance of certificates based on ACME in SBA, thereby improving the adaptability and flexibility of 3 GPP systems.Brief Description of the Drawings

[0020] For a better understanding of the embodiments of the present disclosure, and to show how it may be put into effect, reference will now be made, by way of example only, to the accompanying drawings, in which:

[0021] Figure 1 shows ACME Resources and Relationships;

[0022] Figure 2 shows a method performed by a wireless device acting as a client according to embodiments of the disclosure;

[0023] Figure 3 shows a method performed by a network node acting as a token authority according to embodiments of the disclosure;

[0024] Figure 4 shows a method performed by a second core network entity acting as a certification server according to embodiments of the disclosure;

[0025] Figure 5 shows a CMP Architecture for SBA;

[0026] Figure 6 shows Principles for the ACME Token Authority Architecture for SBA according to embodiments of the disclosure;

[0027] Figure 7 shows Principles for the ACME Pre-Authorization Architecture for SBA according to embodiments of the disclosure;

[0028] Figure 8 shows a Simple Token Authority Architecture for SBA according to embodiments of the disclosure;

[0029] Figure 9 shows a Multi MNO Token Authority architecture for SBA according to embodiments of the disclosure;

[0030] Figure 10 shows a Pre Authorized Architecture for SBA according to embodiments of the disclosure;

[0031] Figure 11 shows a Pre Authorized and Optimized architecture according to embodiments of the disclosure;

[0032] Figure 12 shows an example of a communication system in accordance with some embodiments;

[0033] Figure 13 shows a UE in accordance with some embodiments;

[0034] Figure 14 shows a network node in accordance with some embodiments;

[0035] Figure 15 is a block diagram of a host in accordance with various aspects described herein;

[0036] Figure 16 is a block diagram illustrating a virtualization environment in which functions implemented by some embodiments may be virtualized;

[0037] Figure 17 shows a communication diagram of a host communicating via a network node with a UE over a partially wireless connection in accordance with some embodiments; and

[0038] Figure 18 shows a network node in accordance with further embodiments.DETAILED DESCRIPTION

[0039] Some of the embodiments contemplated herein will now be described more fully with reference to the accompanying drawings. Embodiments are provided by way of example to convey the scope of the subject matter to those skilled in the art. Additional information is provided by the appendices.

[0040] Figure 2 depicts a method performed by a client for certificate provisioning in accordance with particular embodiments. The method 2 may be performed by a UE or wireless device (e.g. the UE 1212 or UE 1300 as described later with reference to Figures 12 and 13 respectively) acting as a client. The method begins at step 202 with obtaining a key. The method continues at step 204 with obtaining, using the key, a certificate from a certification server.

[0041] Figure 3 depicts a method performed by a token authority for certificate provisioning in accordance with particular embodiments. The method 3 may be performed by a network node (e.g. the network node 1210 or network node 1400 as described later with reference to Figures 12 and 14 respectively) acting as a token authority. The method begins at step 302 with receiving a request from a client for authorization for at least one attribute and / or identifier. The method continues at step 304 with providing a token to the client, wherein the token is for use in obtaining a certificate.

[0042] Figure 4 depicts a method performed by a certification server for certificate provisioning in accordance with particular embodiments. The method 4 may be performed by a network node (e.g. the core network node 1208 or network node 1800 as described later with reference to Figures 12 and 18 respectively) acting as a certification server. The method begins at step 402 with receiving a certificate signing request (CSR) from a client. The method continues at step 404 with providing a certificate to the client in response to receiving the CSR.

[0043] Currently, SBA uses CMP in the architecture described herein and shown in Figure 5; this figure shows a conventional method for certificate provisioning.

[0044] The Certificate Management Function (CMF) (also called Broker) configures CA to register the CMP Client with its authentication credential (CMP Client ID), which may be a Pre-Shared Key (PSK) or public key as well as identifiers and attributes that are expected to be published in the issued certificate. Such configuration is performed using a specific APIagreed between the MNO and the CA (see 1. in Figure 5). Then the CMF configures the CMP Client with the appropriated credentials (an OTP in our case) and identifiers / attributes. The URL to reach the CA is also provided. The MNO may configure the CMF, which may then in turn configure the CA and the CMP Client; as a consequence the CA may validate the CMP requests and ensure these requests match expectations. The provision ping can be done using NETCONF over SSH. The configuration is assumed to be trusted, that is the CMP has generated a public private key pair and the CMF is able to associate via an LDAP directory the CMP client to that specific public key (see 2. in Figure 5). Typically, these communications may be used in embodiments.

[0045] Once the CA and the CMP Client are configured, the CMP uses Transport Layer Security (TLS) to authenticate the CA. The CA does not use TLS to authenticate the CMP Client and TLS is used as it is used in the context of WEB. That said, the CMP messages that contain a certificate request are authenticated with the OTP. The design of CMP consists in sending a certificate request and receive the certificate as a response, that is a single exchange (See 3. in Figure 5).

[0046] CMP is more suitable for the use case where certificates are issued based on configuring the CA with the parameters to be issued in the X509 certificate. ACME is more suitable where no trust relation exists between the CA and the MNO and where the MNO can prove some control over the identifiers / attributes to be indicated in the certificate. The above pieces of information may be necessary requirements for provisioning so the CA can ensure that these identifiers / attributes are legitimate. This leads to two possibilities.1. identifiers / attributes are configured outside the ACME Server. This is expected to limit the impact on the ACME Server. Embodiments using this policy are described in the Token Authority Architectures represented in Figure 6. The “Simple Token Authority Architecture for SBA” achieves that goal under certain conditions while the “Multi-MNO Token Authority Architecture” mostly achieves this goal. The main difference between the two architecture is that the Multi MNO Architecture requires to bind the ACME Client to a given MNO. The implementation leverages the externalaccount binding mechanisms specified by ACME [RFC8555]). Impact may be limited as the policies / configurations associated to MNO are quite high level - typically each configuration requires the specification of a specific Token Authority.

[0047] 2. identifiers are configured on an ACME Server. This alternative is described in the Pre Authorized architectures represented in Figure 7. The “Pre Authorized Architecture for SBA” describes how granting authorization by configuration can be implemented in ACME while maintaining the logic entirely. However, the real challenge here is to implement different policies (that is the specification of the exact identifiers / attributes) for each ACMEClients. Though we reuse the extemalaccount binding mechanisms specified in ACME, being able to generate some authorizations for each specific ACME Client might end up in being quite intrusive. Preauthorization aims to keep as much as possible ACME as being deployed today for the web pki, however some specific checks are required for SB A. The ACME model as typically applied requires that first specific identifiers are requested to be issued and then ownership is validated. In the preauthorization model, it is possible to authenticate the client and authorize the issuance of these identifiers based on the configuration. In the ACME model, once ownership of the identifiers has been proven, no certificate is issued. The certificate is only issued by the CA after it receives a CSR. The CA will not issue any received CSR without configured checks, which prevents requests for exotic attributes in a final certificate.

[0048] The “Pre Authorized with CSR Check Architecture for SB A” pushes a bit further the model by granting ACME authorization to any requested identifiers / attributes (not only an authorized ACME client) during the ACME order and authorization phases and only applying the specific checks on the CSR - that is at a latter stage than in existing systems. Such implementation is expected to be easier to implement and leave most of the ACME logic untouched. The “Pre Authorized and Optimized Architecture” considers that the ACME Server will need to be significantly impacted and considers how ACME exchanges may be optimized to reduce the number of exchange. The intent is that if the ACME Server is to be modified, the ACME implementation may be reduced to the minimum subset of function that is required. Figure 6 illustrates the Principles for the ACME Token Authority Architecture for SB A. Note that the Token Authority can be seen as part of the CMF or as a component handled by the CA. Figure 7 illustrates the Principles for the ACME Pre-Authorization Architecture for SB A.

[0049] As discussed above, ACME has been designed to automate the issuance of certificates. The primary assumption for ACME to make automation possible is that a challenge can be performed - such as checking control of a FQDN. In the scope of 3GPP certificates this is typically not possible. For example, there may be no way for a CA to check that the entity requesting the certificate will be a AMF or a SMF, or that one specific UUID is legitimate to request the certificate. As result, the issuance of 3GPP certificates mostly relies on authenticating the entity requesting the certificate and determine from a configuration whether that specific client is legitimate for such a request or not. ACME is not appropriated for such usage, but ACME is widely deployed in the IT world, so there is an advantage for being able to issue these certificates using ACME. Adapting ACME to meet the 3GPP may therefore require one or more of1.The definition of a new token that will contain all attributes of the X509 certificate and expected to be validated by the Token Authority (for the Token Authority Architecture).2. The definition of new identifiers, new challenge (associated to the attributes of the X509 certificate) when the Pre- Authorization Architecture is used.3. The ability for the ACME Server to authenticate an ACME Client and associate a specific configuration. That configuration may remain quite high level in the case of the ACME Token Authority Architecture, but in the case of the ACME Pre-Authorization Architecture, such profiling is very specific to each identifiers type and values. This is new as ACME is expected to rely on challenges being performed to grant authorization.4. The ability to reduce the number of exchanges between the ACME Client and the ACME Server.5. ACME authentication is handled specifically to ensure the authentication credentials are only used once.

[0050] The impact using ACME versus CMP may comprise, relative to the CMP client:1. With the ACME Token Authority Architecture, the ACME Client deals with two distinct entities for the issuance. The two entities are the ACME Server and the Token Authority. The have different URLs but the Token Authority may belong to the CA, the MNO as an independent entity or as part of the CMF.2. In some embodiments, ACME involves multiple operations (exchanges) like the creation of an ACME account, the request for an authorization, and so on.Simple Token Authority architecture for SBA

[0051] For SBA, a key issue is the CA issuing certificates with some specific attributes / identifiers for which the CA has no means to check with the ACME Client these attributes / identifiers, wherein the value(s) of the attributes / identifiers depends on the ACME Client. Typically, only the MNO can validate that these attributes / identifiers for a given ACME Client are valid.

[0052] For information that the ACME Server cannot directly validate, ACME has designed the Token Authority mechanism. By way of example, if a ACME client requests that the certificate contains a network function ID or a specific NF type or a specific Subject, there is no way the CA can directly validate the claim is legitimate. For IP addresses, or FQDN, this is different as the CA can request some changes - like crafting a specific RRSet associated to that FQDN or setting a specific path / web page for an IP address or FQDN. If an ACME client is able to create these RRset / web pages, the CA can test their existence and assume authority to administrate these FQDN, or the host behind the IP.

[0053] In addition, since the identifiers / attributes depends on the ACME Client, the Token Authority needs to authenticate the ACME Client. The implication of a Token Authorityrequires the definition of a new identifier type that we designate as ’cert’ and which contains all attributes associated to the certificate to be issued. In addition to verifying the identifiers / attributes, this identifier plays a similar role as the identifier of type ’TNAuthList’ in [RFC9448] (see RFC 9448 TNAuthList Profile of Automated Certificate Management Environment (ACME) Authority Token by the Internet Engineering Task Force (IETF), available at https: / / datatracker.ietf.org / doc / html / rfc9448 as of 18 February 2024). The identifier needed by 3 GPP contains multiple identifiers that cannot be checked by the CA / ACME server; the new certificate is therefore similar in some respects to TNAuthList, for example TNAuthList includes identifiers for which the CA cannot validate the ownership. The value associated to that identifier of type ’cert’ is a JSON dictionary that stores the ’key’ / ’value’ pairs of the expected identifiers attributed that are expected to appear in the X509 certificate.

[0054] An embodiment related to certificate provisioning and considering the Token Authority is represented in Figure 8. In this figure, the ACME Server is not for general purpose, but instead is instantiated to collaborate with the Token Authority. A cloud provider could typically instantiate the ACME Server for a given MNO and when the MNO requests an identifier of type ’cert’ in its ’order’ request (see 2. in the Figure 8), the ACME Server involves the Token Authority mentioned in Figure 8. The MNO may provide configuration information to the ACME Server CA, for example, as a database file linking a PSK with identifiers / attributes associated with a specific client. The ACME Server may be able to assign different Token Authority to different request of identifiers. However, the ACME Server in this case is not able to authenticate the ACME Client. Figure 8 illustrates the Simple Token Authority Architecture for SB A. Figure 8 shows the Token Authority as a component of the CA, but the Token Authority can also be seen as belonging to the CMF, that is the MNO (see Figure 2, for an example of such implementation.)

[0055] As previously mentioned, the ACME Server is likely instantiated for a given MNO, but on the other the ACME Server remains generic as it does not have to authenticate the ACME Client and manage any authorizations. In that sense the ACME Server remains quite generic. It is likely that such scheme will be favored by a Cloud Provider as the ACME Server is mostly associated with a specific configuration and remains working with anonymous ACME Client. The ACME Server handles ACME accounts, but in the ACME Server perspective, the ACME Client is nothing more than the owner of the ACME account, that is the owner of a private key.

[0056] The Token Authority remains responsible to authenticate the ACME Client so that it can validate 1) the set of attributes / identifiers requested for the certificate are legitimate and2) the ACME Client is legitimate to request such a certificate. The Token Authority needs to be provisioned by the MNO with ACME Client identifiers and associated credentials as well as the legitimate identifiers / attributes. The Token Authority needs to have a trusted relationship with the ACME Server, but the Token Authority can be operated by the CA which already operates the ACME Server or the MNO. As the complexity of handing ACME Client accounts is handled by the Token Authority, it might be convenient for the CA to delegates such a complexity to the MNO. Note that running the Token Authority by the MNO requires another service to be up and running as opposed to provisioning the CA once, however gives complete control of the issuance of certificates. Typically, this may provide some visibility on which certificate is being issued in real time.

[0057] Whoever operates the Token Authority, the MNO is configuring the Token Authority with the ACME Client PSKs and identifiers / attributes that are expected to be issued in the certificate. In this section the ACME Client PSK is a PSK that is used to identify and authenticate the ACME Client. This PSK is configured by the MNO in the ACME Client and in the Token Authentication. Nothing prevents the use of a public key whose corresponding private key is hosted by the ACME Client. However, currently PSK are used for the authentication. As result, using a PSK seems in continuation with the comment practices for SB A.

[0058] Once the ACME Client is configured with the PSK, it creates an ACME account (see 1. ’account’ in Figure 8). Then it orders the identifiers / attributes to be authorized (see 2. ’order’ in Figure 8). When the order request is received, the ACME Server creates an ’order’ object with its status set to ’pending’. The ACME Server responds to the ACME Client and indicates an URL that indicates how the ACME Client can create an ’authorization’ object. The ’order’ exchange is discussed in detail herein. The ACME Client proceeds to an authorization exchange (See 3. ’authorization’ in Figure 8). The ACME Server responds the ’authorization’ exchange by indicates the challenges to be completed. In our case the challenge consists in requesting an authorization TOKEN to the Token Authority. The ’authorization’ exchange is discussed in detail herein. The ACME Client request an authorization TOKEN to the Token Authority (see 4. get TOKEN in Figure 8). The ACME Client then provides the TOKEN to the ACME Server. The challenge completion phase is discussed in detail herein. Upon receiving and validating the TOKEN that has been provided to the owner of the ACME account by the Token Authority, the ACME Server indicates a CSR can be provided by the ACME Client by setting the ’order’ status to ’ready’ . The ACME Client provides a CSR (see 6. ’CSR’) and then retrieve the issued certificate (see 7. ’certificate’). The relevant exchanges are also discussed in detail herein. Note that the exchanges for single vs multi MNO embodiments are similar.

[0059] Embodiments providing Simple Token Authority Architectures for SB A differ from RFC9447 and RFC9448 (both cited herein, for RFC 9447 see Automated Certificate Management Environment (ACME) Challenges Using an Authority Token by the Internet Engineering Task Force (IETF), available at https: / / datatracker.ietf.org / doc / html / rfc9447 as of 18 February 2024) in that embodiments:1. Defines a new label for the identifier type. In some embodiments, that label is ’cert’.2. Defines a new identifier value. In some embodiments, the is a dictionary listing the identifiers / attributes associated to the ’cert’.3. Associates the Token Authority with an ACME Client based token validation policy. More explicitly, RFC9448 typically validates some fields in the certificate, but these fields were not dependant of the ACME Client identity.4. Define a mechanism to bind the TOKEN to the ACME account by having the ACME Client providing a proof of ownership of the ACME account key to the Token Authority.5. ACME Client authentication credentials are not expected to be used once (contrary to embodiments).Multi MNO Token Authority architecture for SBA

[0060] The embodiments providing Simple Token Authority Architectures include scenarios where the ACME Server does not have to authenticate the ACME Client and directly redirects the ACME Client to the Token Authority without checking if the ACME Client is actually legitimate for the Token Authority. This represents at the very least a security threat as any ACME Client can be delegated to the Token Authority. As a result, it is recommended that the ACME Server at least ensures the ACME Client is legitimate before delegating it to a Token Authority. In addition, the Simple Token Authority architecture also assumed there is only one Token Authority involved. While a single MNO may have multiple Token Authorities, it might also be the case that one ACME server issues certificates for multiple MNOs which are associated distinct Token Authorities. As a consequence, the ACME Server must be able to associate each ACME Client (or ACME account) to a specific MNO. Embodiments for multi MNO token authority architectures are therefore provided. Figure 9 illustrates a Multi MNO Token Authority architecture for SBA.

[0061] In embodiments for multi MNO token authority architectures, the ACME Server is configured to identify to which MNO the ACME Client is related to. To bind an ’anonymous’ ACME account to another account, ACME [RFC8555] defines the external account binding. The principle is that the CA provides an MAC key that represents the external non ACME account, and the ACME Client then proves at the creation of the ACME account both possession of the private key associated to the ACME account and the MAC key associatedto the non ACME account. Note that an ACME account is created. In our case, the external account is designated as CA account in Figure 9. In this example, the CA account is associated to MNO and each MNO is configured with the Token Authority information as well as a list of PSKs that represents the ACME Clients.

[0062] Some embodiments for multi MNO token authority architectures consider that BOTH the ACME Server and the Token Authority have specific configurations with MNO specific parameters. When the ACME Server and the Token Authority belong to different administrative domains, for example the ACME Server is operated by the Cloud provider but the Token Authority is operated by the MNO, two distinct configurations steps needs to be synchronized by the MNO. When the ACME Server and the Token Authority are operated by a single entity, like the Cloud Provider, then the Cloud Provider handles the two distinct configurations and provide the ability of the MNO to provide a single configuration. Note that even if the MNO does not have to proceed specifically to the configuration of the Token Authority, the ACME Client must be compliant with the Token Authority as there is a specific ’get TOKEN’ exchange. In other word, the simplification of the configuration does not make the Token Authority transparent to the ACME Client. As a result, the Directory object could be represented as specified below with: termsOfService: specifying the current term of services. While this is expected to be global to the ACME server, it seems reasonable to think a dedicated ACME server could be used for certificate being issued for 3GPP. In this case, the termOfService could be used to indicate the server is dedicated to issuing certificate following the 3GPP profile defined in this document. Note that such field remains in any case optional, as ACME Client will likely not check the termOfservices, and use the registered MNO account. As a result, the ToS is essentially for debug purpose and to prevent a regular ACME user to use that dedicated ACME server. external AccountRequired: indicates that creation of newAccount request include an extemalAccountBinding field. caaldentities is only useful if the CAA RRset. This field will be used to identify the CA.

[0063] The MNO starts by configuring the CA account with the PSK, the Token Authority and the ACME with the PSK and expected identifiers / attributes. The ACME Client creates an ACME account on the server with an ’account’ exchange. The ACME Client is aware of the necessity to provide a proof of the ownership of the PSK via the ’directory’ with an ’external AccountRequired’ set to True, as illustrated by the pseudocode below"newNonce" : "https : / / example . com / acme / new-nonce" , "newAccount : "https : / / example . com / acme / new-account" , "newOrder " : "https : / / example . com / acme / new-order " ,"newAuthz " : "https : / / example . com / acme / new- auth z " , " revokeCert" : "https : / / example . com / acme / revoke- cert" , " keychange" : "https : / / example . com / acme / key- change" , "meta" : { "termsOf Service" : "https : / / example . com / acme / terms / 3gpp-profile" , "caaldentities " : [ "ca . example . com" ] , "externalAccountRequired" : true , } }

[0064] In this case, the ACME Client provides a proof of ownership of the PSK. That PSK is used by the ACME Server to bind the CA account and determine which MNO the ACME Client belongs to. (see 1. ’account’ in Figure 9, discussed in more detail herein).

[0065] The remaining exchange follows the same format as single MNO embodiments, that is, the steps for single MNO embodiments as shown in Figure 8 and as discussed above. The main difference is that the PSK can be used as an common authentication credential shared between the ACME Server and the Token Authority. This means that by asserting the TOKEN is associated to the PSK, the ACME Server can determine whether the ACME Client is in scope of the TOKEN or not. The TOKEN binding is detailed below. As discussed above, Figure 9 illustrates a Multi MNO Token Authority architecture for SB A. As mentioned earlier, Figure 9 depicts the Token Authority that is hosted and managed by the CA but it can also be hosted and managed by the MNO.

[0066] Multi MNO embodiments may differ from simple token authority embodiments in one or more of the following ways:1. The Broker needs to configure CA and the Token Authority2. The ACME Server needs to perform externalaccount binding. Each of the external account binding impact the policy of the ACME Server.3. TOKEN Binding can be performed only using the PSK.ACME account TOKEN Binding

[0067] The Token Authority authenticates the ACME Client with the provisioned PSK and then validates the requested identifiers / attributes. The ACME Server knows the ACME Client as the owner of the private key associated to the ACME account. The TOKEN issued by the Token Authority (and transmitted to the ACME Server) must provide some evidences to the ACME Server so it can check that the TOKEN effectively designates the owner of the ACME account. There basically two ways to perform this. One way to do so is that the ACME Client provides a proof of possession of its ACME account key while performing the get TOKEN exchange. Then the Token Authority TOKEN indicates in a ’fingerprint’ field the key forwhich it has been provided a proof of possession which has been validated by the Token Authority. In addition to the TOKEN validation described in [RFC9447, RFC9448], the ACME Server MUST validate the key indicated in ’fingerprint’ matches the ACME account key. Alternatively, the Token Authority indicates in the TOKEN that the key used for the authentication was the PSK identifier in a ’psk id’ field, and that the ACME Client provides an proof of possession of that PSK. This proof of possession of the PSK can be provided at any point, that is during the exchanges (1. ’account’, 2. ’order’, or 4. ’challenge’) as shown in Figures 8 and 9.

[0068] In the case of embodiments using the Simple Token Authority architecture for SBA described herein, the goal was mostly to leave the ACME Server and ACME exchanges unchanged. On the other hand, there is no specifications for a generic get TOKEN exchange. This exchange is defined for every token type and authentication of the ACME is also left specific to the implementation. In that case, it more coherent to specific the 3. get TOKEN operation to contain a proof of ownership of the ACME account key and have the Token Authority verifying the proof of possession.

[0069] In the case of embodiments using the Multi MNO Token Authority architecture for SBA defined herein, the extemalbinding to a CA account provides the proof of possession of the PSK in the ’account’ exchange. As a result, the TOKEN only needs to indicate the ’psk id’ to indicate the PSK used by the Token Authority to authenticate the ACME Client. Both the ACME Server and the Token Authority have validated the possession of the PSK.Handling of the PSK

[0070] Embodiments utilise a key, which may be a public key or a PSK. PSK has been used as a convenient way to authenticate the CMP client by the CMP server. The way SBA uses the PSK is more or less as an OTP, which means the PSK should only be used once and then removed or regenerated. Because it is only used once, there is some assurance that the ACME Client being issued the certificate has properly been authenticated. In other words, if the PSK had been used by anyone else before the legitimate ACME Client, the legitimate ACME Client will not be issued the expected certificate and this would generate an error and at least get motived by the administrator. Since it is used only once, someone stealing the PSK will not be able to re-use it.Pre Authorized Architecture for SBA

[0071] ACME has been designed with automation in mind and this hardly fits the cases where identifiers or attributes cannot be automatically verified. The use of a Token Authority enables to delegate the verification to a external entity. There is especially a need to definethe interactions between the ACME Server and the Token Authority when these are from two distinct administrative domains. However, from a MNO perspective, the intention is to provide the necessary configuration so the CA is able to validate by itself the certificate request is legitimate. This could be instantiated by having the ACME Server and the Token Authority in a given administrative domain - that is managed by the CA. Accordingly, some embodiments utilize pre authorised architectures to simplify the architecture and enable the ACME Server to be provisioned ’a la CMP’ and issue the certificate without involving an exchange with the Token Authority. Note that the Token Authority even if it managed by the CA is not transparent to the ACME Client and the ACME Client MUST support that kind of challenge which requires a specific support for the get TOKEN exchange.

[0072] The Pre Authorized Architecture considers that the MNO configures the CA account with all identifiers and attributes requested by any specific ACME Clients, identified by a PSK. The MNO also configures the ACME Client with the PSK. The ACME Server indicated the ACME Client needs to bind its ACME account to an external account by setting the ’ external AccountRequired’ to True. The ACME Client proves ownership of the PSK to be authenticate while creating the ACME account in the 1. ’account’ exchange - see Figure 10. Figure 10 shows a Pre Authorized Architecture for SB A. Then, the ACME Client requests the authorization for each identifier or attribute with an ’order’ exchange - see step 2 in Figure 10. This requires the definition of an identifier type for each attribute / identifier. As the ACME Server is able to associate the ACME account to the specific type of identifiers and their associated value, the ACME Server is able to automatically grant the authorization without requiring the ACME Client to perform some challenges (see optional step 3a and 3b in Figure 10). Preauthorizing the identifiers upon receiving the ’order’ requests, basically consists in creating for each identifier a authorization object with the status ’valid’. When these authorization objects have all their status set to ’valid’, the order status is set to ’ready’ . Which indicates the ACME Client can proceed to the CSR exchange (see step 4 in Figure 10). A description of the preauthorized objects is located herein. One needs to remember that the reason we introduced such configuration is that there is no real ways for the ACME Client to prove the control over some attributes. Note also that a combination of pre-authorization and challenges can also be combined as these identifiers / attributes are considered separately. We simply do not consider this case in this section. Instead all arguments are provided via configuration and preauthorized by the ACME Server. The ’authorization’ exchange is indicated as optional to potentially enable the ACME Client to check the authorization status. It is likely that many ACME Client will consult the authorization object and then look for a challenge prior to check the status of the order object. Typically, the status order will be assumed to be ’pending’ in the beginning. Note that those ACME Client will also need to beable to support an empty list of challenge. One possibility to prevent to these ACME Client to fail is to create a new challenge ’no challenge-Ol’. Note that the ’order’ response contains the link for the ’CSR’ exchange (see ’finalized’) which makes it possible without changing the ’order’ response to skip the ’authorization’ and ’challenge’ exchanges. Remaining ’CSR’ and ’certificate’ exchange remains unchanged and may be performed as described in [RFC8555],

[0073] The differences between the Pre Authorized Architecture and typical ACME may include one or more of the following:1. The CA authorizes identifiers and attributes based on an out-of-band provisioning by the MNO to a external account. This requires interactions between the ACME policies / configuration and the external CA account.2. The CA account PSK and ACME account are deleted once the certificate is issued as to implement a one time password.3. Every item mentioned in the certificate may be registered to the IANA as a new identifier type.4. The order object MAY simply have a ’finalize’ link, that is an empty ’authorization’ link, or no ’authorization’ link. It MAY also have one for compatibility reasons with legacy ACME Client5. Traditional ACME is essentially focused on authorizing identifiers - such as IP address, FQDNS. In our case, authorization concerns identifiers and attributes. These attributes are pre-authorized and their status is set to ’valid’ by the ACME Server. This may be considered as an internal state of the ACME Server. Optionally the authorization object may be accessed and consulted by the ACME Client. However, there may be no need to do so.6. The ACME Client does not have to go through challenges and MUST be able to interpret a order response with a status directly set to ’ready’.7. The ACME may be required to be able to interpret an empty list of challenges. Eventually, for legacy ACME Client to remain compatible, a specific challenge ’no challenge’ might be created.Pre Authorized with CSR Check Architecture for SBA

[0074] Embodiments may be similar to those using pre authorised architectures. In embodiments using the Pre Authorized with CSR Check Architecture for SBA, each ACME Client is associated to some pre-authorized identifiers expected to be specific to the ACME Client. The order, authorization and challenges were originally designed in ACME to enable the ACME Client to prove the control over expected identifiers; this does not exists in ourmodel where provisioning is considered as the main source to indicate whether or not these identifier are expected. In addition, the ACME Server is also expected to check the CSR.

[0075] In order to avoid the double verification, some embodiments implementing the ACME Server may authorize blinding all requested identifiers and only performs the checks toward the CA account during the ’CSR’ exchange. In such implementations one can expect the following additional changes on the server side:1. ’order’ object is automatically generated without any look up to the CA account database, and set to ’valid’ . In clear the ACME Server does not proceed to any verification.2. ’authorization’ and ’challenges’ objects are also blindly generated with a status set to ’valid’. Note that access to these objects remain optional.3. Upon receiving a CSR, the ACME Server checks its validity by checking the CA account data base. The PSK is used to bind the appropriated account.

[0076] Pre-authorization may not be universally supported (for example, may not be supported by Boulder), so rather than implementing a pre-authorization for every individual identifier, the authorization phase in ACME may completely be skipped and instead implemented it at the CSR level.Pre Authorized and Optimized Architecture

[0077] Many of the embodiments discussed herein are intended to maintain certification servers as close as possible to the ACME servers, essentially to limit the impact on the current ACME Server / and ACME Client implementations. However, there remain some impacts. Typically, in ACME systems, external account binding is used to bind an external account to the ACME account. In embodiments, the binding is used to provide some specific configurations to the ACME Server. While embodiments use a mechanism described in the ACME specification, the specification remains quite vague about the capabilities provided by an external account, and such interaction may significantly impact the code of the ACME Server.

[0078] If limiting to the mechanisms put in place by ACME is not required, embodiments that differ from typical ACME systems and specifications may be provided; ACME specifications remain vague on how an implementation may coexist with another system.

[0079] In some embodiments, the use of an ACME account and a CA account that needs to be coordinated may be altered; an example is shown in Figure 11. Figure 11 shows a Pre Authorized and Optimized architecture. One possible way would be to use PSK to authenticate the ACME account. The creation of the account object could be performed as soon as the CA account is configured, together with the ’order’ object, as well as the pre-authorized’authorization’ object and potential ’challenge’ objects. The ’finalize’ URL could be built based on the PSK, so it can be derived by the ACME Client without knowing the ’finalized’ URL from a previous request. In any case, the CSR exchange imitated by the ACME Client is protected by a signature, with can be done with a HMAC. The ACME Client could then proceed to the ’certificate’ exchange. The use of a PSK is quite convenient as the certificate is expected to be issued once. In other words, the ’finalize’ URL is only expected to be accessed once and so once the CSR exchange has been performed no additional CSR are accepted. A common way to do this is to remove the finalize URL.

[0080] Embodiments may also or alternatively configure the CA account with a public key provided by the MNO which will be used as the ACME account. The ACME account is thus generated with the other objects - as previously. The ’finalize’ URL cannot be generated with the ACME account key - as we could do with the PSK. In that case the standard signature is used instead.

[0081] Differences relative to typical ACME systems may include one or more of the following:1. ’account’, ’order’, ’authorization’, ’order’ objects are all generated form the CA account configuration.2. ’finalize’ may be accessed without Nonce as to avoid additional round trip.3. The ACME account could be a PSK and use symmetric cryptography.4. Once properly accessed the ’finalize’ URL is removed.5. ACME Client need to be configured to start with the ’CSR’ or ’finalize’ exchange. The main motivation is to prevent maintaining unnecessary URLs, or objects.6. authorization is implemented by checking the CSR.TABLE 1: Status on current ACME implementationsImplementation CMP ACME TA EAB Pre-auth.OpenCA - . . . .Dogtagpki - yes - yesOpenxpki - . . . .Ejbca yes yes - yes yesBoulder - yes - - step-ca - yes - -

[0082] Table 1 shows PKI implementation positioning versus ACME and CMP. TA stands for Token Authority, EAB stands for External Account Binding.

[0083] Ejbca supports ACME External Account Binding (EAB), however, I do not see interactions between the non ACME account and the ACME configuration. It seems to me that this is only used to grant access and that is is not feasible to implement policies that depends on the non ACME account.

[0084] Ejbca implements also the Pre-authorization. A pre-authorization enables an ACME Client to get an authorization prior requesting an ’order’. That this mechanism is in place could help implementing the Pre-Authorize model as it means authorization can be granted outside the issuance of a certificate. Note that pre-authorization requests are sent per identifier. Note also that my understanding of pre-authorization is represent the ability to request authorization outside an order of certificate. It does not mean that there is no challenge. However, it could be helpful in our case as it potentially makes possible to create the authorization object according to a non ACME account. This is one of the motivation for creating this resource as per section 7.1 of [RFC8555],

[0085] Ejbca seems also to support an external account binding with asymmetric keys in addition to the PSK that is described in [RFC8555],

[0086] Ejbca seems to authenticates its client via the TLS certificate, that is with mutual authentication. The service uses different URL when client authentication is enabled. https: / / doc.primekey.com / ejbca / ejbca-operations / ejbca-ca-concept-guide / protocols / acme

[0087] Dogtagpki does not seems to support Token Authority, nor pre-authentication (new- authz) and client authentication seems to be done via TLS.

[0088] step-ca lists their view on when ACME should be used or not. On the one hand the mention the example when cert-manager is used with ACME enabled. But concord with our view that ACME is not recommended in our case.

[0089] https: / / smallstep.com / docs / certificate-manager / acme / when-to-use-acme / #when-not- to-use-acme

[0090] step-ca does not supports the Token Authority challenge and seems to confirm that external account binding is mostly intended to authorize clients or implement rate limiting as to bind a configuration to a specific ACME Client.

[0091] https: / / smallstep.com / blog / acme-eab-overview /

[0092] Boulder does not seem to implement pre-authorization. https: / / github.com / letsencrypt / boulder / blob / ce5632b480f0b5c6cl25256ef9f8b0c4284548d3 / docs / DESIGN.md?plain=l#L102 https: / / github.com / letsencrypt / boulder / issues / 7050

[0093] Embodiments provide ACME based architecture to handle certificate being issued for 3GPP. The Token based architecture and the Pre-authenticated based architectures are two different approaches, which may be used in combination but would typically be used in isolation. Below is a comparison between the approaches.

[0094] In term of standardization, both architectures require similar effort - typically the definition of a token versus the definition of a ’no challenge’ challenge or identifiers.

[0095] Theoretically, the Token Authority Architecture provides the advantage that is defines a method to delegate the authorization decision to a third party. As a result, this solution is likely to limit the impact on the ACME Server. However, it requires 1) the Token Authority challenge to be implemented in the ACME server and 2) Token Authority to be implemented. So far we have seen no open source or commercial implementation or the Token Authority, while we should potentially assume it is implemented. The great advantage of that solution is that a general purpose ACME Server with external binding and token authority challenge could issue 3GPP certificates. If desired to split the responsibilities between the CA and the MNO this architecture also enables to do so. This is however done at the expense of having the MNO running an additional service.

[0096] On the other hand, Pre-authorization can be optimized and rely on tweaking existing code without very much changes. The changes do not appear considerable as they follow the ACME logic. It also provides the ability be much more optimal. This model is also closer to the CMP model.

[0097] Client authentication uses TLS, that is, is left to TLS.

[0098] As mentioned by step-ca ACME is a good choice in a container environment mostly because cert-manager only supports ACME and so it makes it able to use cert-manager. On the other hand, still according to step-ca, our use case does not match the ACME use case. Using ACME will force CA to support the necessary ACME extensions we are defining. It would be good to consider which CAs will be willing to do so. Especially considering that very few implementations are supporting CMP, nor the Token Authority Challenge. This tend to show that ACME is not closely following the standards when it goes outside the web PKI use case and will not implement extensions required by 3GPP. Instead, we will be using certificate where only the FQDN is challenged and verified.

[0099] From the perspective of implementers using cert-manager is appealing. Benefits include the integration with container - based controls. In that case, it would be good to consider integrating CMP to the cert-manger so certificate management can be abstracted by the CertificateRequest. It is necessary to consider the benefits of using cert-manager versus a given CMP client.

[0100] Another avenue is to align 3GPP certificates to TLS certificates, that is with only a FQDN. This will enable to use an unmodified cert-manger and a unmodified ACME server - with ACME security that is an non protected challenge.

[0101] Appendices A to D below provide additional background information and information on embodiments.

[0102] Figure 12 shows an example of a communication system 1200 in accordance with some embodiments.

[0103] In the example, the communication system 1200 includes a telecommunication network 1202 that includes an access network 1204, such as a radio access network (RAN), and a core network 1206, which includes one or more core network nodes 1208. The access network 1204 includes one or more access network nodes, such as network nodes 1210a and 1210b (one or more of which may be generally referred to as network nodes 1210), or any other similar 3rdGeneration Partnership Project (3GPP) access nodes or non-3GPP access points. Moreover, as will be appreciated by those of skill in the art, a network node is not necessarily limited to an implementation in which a radio portion and a baseband portion aresupplied and integrated by a single vendor. Thus, it will be understood that network nodes include disaggregated implementations or portions thereof. For example, in some embodiments, the telecommunication network 1202 includes one or more Open-RAN (ORAN) network nodes. An ORAN network node is a node in the telecommunication network 1202 that supports an ORAN specification (e.g., a specification published by the O- RAN Alliance, or any similar organization) and may operate alone or together with other nodes to implement one or more functionalities of any node in the telecommunication network 1202, including one or more network nodes 1210 and / or core network nodes 1208.

[0104] Examples of an ORAN network node include an open radio unit (O-RU), an open distributed unit (O-DU), an open central unit (O-CU), including an O-CU control plane (O- CU-CP) or an O-CU user plane (O-CU-UP), a RAN intelligent controller (near-real time or non-real time) hosting software or software plug-ins, such as a near-real time control application (e.g., xApp) or a non-real time control application (e.g., rApp), or any combination thereof (the adjective “open” designating support of an ORAN specification). The network node may support a specification by, for example, supporting an interface defined by the ORAN specification, such as an Al, Fl, Wl, El, E2, X2, Xn interface, an open fronthaul user plane interface, or an open fronthaul management plane interface. Moreover, an ORAN access node may be a logical node in a physical node. Furthermore, an ORAN network node may be implemented in a virtualization environment (described further below) in which one or more network functions are virtualized. For example, the virtualization environment may include an O-Cloud computing platform orchestrated by a Service Management and Orchestration Framework via an O-2 interface defined by the 0-RAN Alliance or comparable technologies. The network nodes 1210 facilitate direct or indirect connection of user equipment (UE), such as by connecting UEs 1212a, 1212b, 1212c, and 1212d (one or more of which may be generally referred to as UEs 1212) to the core network 1206 over one or more wireless connections.

[0105] Example wireless communications over a wireless connection include transmitting and / or receiving wireless signals using electromagnetic waves, radio waves, infrared waves, and / or other types of signals suitable for conveying information without the use of wires, cables, or other material conductors. Moreover, in different embodiments, the communication system 1200 may include any number of wired or wireless networks, network nodes, UEs, and / or any other components or systems that may facilitate or participate in the communication of data and / or signals whether via wired or wireless connections. The communication system 1200 may include and / or interface with any type of communication, telecommunication, data, cellular, radio network, and / or other similar type of system.

[0106] The UEs 1212 may be any of a wide variety of communication devices, including wireless devices arranged, configured, and / or operable to communicate wirelessly with the network nodes 1210 and other communication devices. Similarly, the network nodes 1210 are arranged, capable, configured, and / or operable to communicate directly or indirectly with the UEs 1212 and / or with other network nodes or equipment in the telecommunication network 1202 to enable and / or provide network access, such as wireless network access, and / or to perform other functions, such as administration in the telecommunication network 1202.

[0107] In the depicted example, the core network 1206 connects the network nodes 1210 to one or more hosts, such as host 1216. These connections may be direct or indirect via one or more intermediary networks or devices. In other examples, network nodes may be directly coupled to hosts. The core network 1206 includes one more core network nodes (e.g., core network node 1208) that are structured with hardware and software components. Features of these components may be substantially similar to those described with respect to the UEs, network nodes, and / or hosts, such that the descriptions thereof are generally applicable to the corresponding components of the core network node 1208. Example core network nodes include functions of one or more of a Mobile Switching Center (MSC), Mobility Management Entity (MME), Home Subscriber Server (HSS), Access and Mobility Management Function (AMF), Session Management Function (SMF), Authentication Server Function (AUSF), Subscription Identifier De-concealing function (SIDF), Unified Data Management (UDM), Security Edge Protection Proxy (SEPP), Network Exposure Function (NEF), Policy Control Function (PCF) and / or a User Plane Function (UPF).

[0108] The host 1216 may be under the ownership or control of a service provider other than an operator or provider of the access network 1204 and / or the telecommunication network 1202, and may be operated by the service provider or on behalf of the service provider. The host 1216 may host a variety of applications to provide one or more services. Examples of such applications include the provision of live and / or pre-recorded audio / video content, data collection services, for example, retrieving and compiling data on various ambient conditions detected by a plurality of UEs, analytics functionality, social media, functions for controlling or otherwise interacting with remote devices, functions for an alarm and surveillance center, or any other such function performed by a server.

[0109] As a whole, the communication system 1200 of Figure 12 enables connectivity between the UEs, network nodes, and hosts. In that sense, the communication system may be configured to operate according to predefined rules or procedures, such as specific standards that include, but are not limited to: Global System for Mobile Communications (GSM); Universal Mobile Telecommunications System (UMTS); Long Term Evolution (LTE), and / or other suitable 2G, 3G, 4G, 5G standards, or any applicable future generation standard (e.g.,6G); wireless local area network (WLAN) standards, such as the Institute of Electrical and Electronics Engineers (IEEE) 802.11 standards (WiFi); and / or any other appropriate wireless communication standard, such as the Worldwide Interoperability for Microwave Access (WiMax), Bluetooth, Z-Wave, Near Field Communication (NFC) ZigBee, LiFi, and / or any low-power wide-area network (LPWAN) standards such as LoRa and Sigfox.

[0110] In some examples, the telecommunication network 1202 is a cellular network that implements 3GPP standardized features. Accordingly, the telecommunications network 1202 may support network slicing to provide different logical networks to different devices that are connected to the telecommunication network 1202. For example, the telecommunications network 1202 may provide Ultra Reliable Low Latency Communication (URLLC) services to some UEs, while providing Enhanced Mobile Broadband (eMBB) services to other UEs, and / or Massive Machine Type Communication (mMTC) / Massive loT services to yet further UEs.[OHl] In some examples, the UEs 1212 are configured to transmit and / or receive information without direct human interaction. For instance, a UE may be designed to transmit information to the access network 1204 on a predetermined schedule, when triggered by an internal or external event, or in response to requests from the access network 1204. Additionally, a UE may be configured for operating in single- or multi -RAT or multi -standard mode. For example, a UE may operate with any one or combination of Wi-Fi, NR (New Radio) and LTE, i.e. being configured for multi-radio dual connectivity (MR-DC), such as E- UTRAN (Evolved-UMTS Terrestrial Radio Access Network) New Radio - Dual Connectivity (EN-DC).

[0112] In the example illustrated in Figure 12, the hub 1214 communicates with the access network 1204 to facilitate indirect communication between one or more UEs (e.g., UE 1212c and / or 1212d) and network nodes (e.g., network node 1210b). In some examples, the hub 1214 may be a controller, router, a content source and analytics node, or any of the other communication devices described herein regarding UEs. For example, the hub 1214 may be a broadband router enabling access to the core network 1206 for the UEs. As another example, the hub 1214 may be a controller that sends commands or instructions to one or more actuators in the UEs. Commands or instructions may be received from the UEs, network nodes 1210, or by executable code, script, process, or other instructions in the hub 1214. As another example, the hub 1214 may be a data collector that acts as temporary storage for UE data and, in some embodiments, may perform analysis or other processing of the data. As another example, the hub 1214 may be a content source. For example, for a UE that is a VR headset, display, loudspeaker or other media delivery device, the hub 1214 may retrieve VR assets, video, audio, or other media or data related to sensory information via a network node, whichthe hub 1214 then provides to the UE either directly, after performing local processing, and / or after adding additional local content. In still another example, the hub 1214 acts as a proxy server or orchestrator for the UEs, in particular if one or more of the UEs are low energy loT devices.

[0113] The hub 1214 may have a constant / persistent or intermittent connection to the network node 1210b. The hub 1214 may also allow for a different communication scheme and / or schedule between the hub 1214 and UEs (e.g., UE 1212c and / or 1212d), and between the hub 1214 and the core network 1206. In other examples, the hub 1214 is connected to the core network 1206 and / or one or more UEs via a wired connection. Moreover, the hub 1214 may be configured to connect to an M2M service provider over the access network 1204 and / or to another UE over a direct connection. In some scenarios, UEs may establish a wireless connection with the network nodes 1210 while still connected via the hub 1214 via a wired or wireless connection. In some embodiments, the hub 1214 may be a dedicated hub - that is, a hub whose primary function is to route communications to / from the UEs from / to the network node 1210b. In other embodiments, the hub 1214 may be a non-dedicated hub - that is, a device which is capable of operating to route communications between the UEs and network node 1210b, but which is additionally capable of operating as a communication start and / or end point for certain data channels.

[0114] Figure 13 shows a UE 1300 in accordance with some embodiments. As used herein, a UE refers to a device capable, configured, arranged and / or operable to communicate wirelessly with network nodes and / or other UEs. Examples of a UE include, but are not limited to, a smart phone, mobile phone, cell phone, voice over IP (VoIP) phone, wireless local loop phone, desktop computer, personal digital assistant (PDA), wireless camera, gaming console or device, music storage device, playback appliance, wearable terminal device, wireless endpoint, mobile station, tablet, laptop, laptop-embedded equipment (LEE), laptop-mounted equipment (LME), smart device, wireless customer-premise equipment (CPE), vehicle, vehicle-mounted or vehicle embedded / integrated wireless device, etc. Other examples include any UE identified by the 3rd Generation Partnership Project (3GPP), including a narrow band internet of things (NB-IoT) UE, a machine type communication (MTC) UE, and / or an enhanced MTC (eMTC) UE.

[0115] A UE may support device-to-device (D2D) communication, for example by implementing a 3 GPP standard for sidelink communication, Dedicated Short-Range Communication (DSRC), vehicle-to-vehicle (V2V), vehicle-to-infrastructure (V2I), or vehicle-to-everything (V2X). In other examples, a UE may not necessarily have a user in the sense of a human user who owns and / or operates the relevant device. Instead, a UE may represent a device that is intended for sale to, or operation by, a human user but which maynot, or which may not initially, be associated with a specific human user (e.g., a smart sprinkler controller). Alternatively, a UE may represent a device that is not intended for sale to, or operation by, an end user but which may be associated with or operated for the benefit of a user (e.g., a smart power meter).

[0116] The UE 1300 includes processing circuitry 1302 that is operatively coupled via a bus 1304 to an input / output interface 1306, a power source 1308, a memory 1310, a communication interface 1312, and / or any other component, or any combination thereof. Certain UEs may utilize all or a subset of the components shown in Figure 13. The level of integration between the components may vary from one UE to another UE. Further, certain UEs may contain multiple instances of a component, such as multiple processors, memories, transceivers, transmitters, receivers, etc.

[0117] The processing circuitry 1302 is configured to process instructions and data and may be configured to implement any sequential state machine operative to execute instructions stored as machine-readable computer programs in the memory 1310. The processing circuitry 1302 may be implemented as one or more hardware-implemented state machines (e.g., in discrete logic, field-programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), etc.); programmable logic together with appropriate firmware; one or more stored computer programs, general-purpose processors, such as a microprocessor or digital signal processor (DSP), together with appropriate software; or any combination of the above. For example, the processing circuitry 1302 may include multiple central processing units (CPUs). The processing circuitry 1302 may be operable to provide, either alone or in conjunction with other UE 1300 components, such as the memory 1310, UE 1300 functionality. For example, the processing circuitry 1302 may be configured to cause the UE 1302 to perform the methods as described with reference to Figure 2.

[0118] In the example, the input / output interface 1306 may be configured to provide an interface or interfaces to an input device, output device, or one or more input and / or output devices. Examples of an output device include a speaker, a sound card, a video card, a display, a monitor, a printer, an actuator, an emitter, a smartcard, another output device, or any combination thereof. An input device may allow a user to capture information into the UE 1300. Examples of an input device include a touch-sensitive or presence-sensitive display, a camera (e.g., a digital camera, a digital video camera, a web camera, etc.), a microphone, a sensor, a mouse, a trackball, a directional pad, a trackpad, a scroll wheel, a smartcard, and the like. The presence-sensitive display may include a capacitive or resistive touch sensor to sense input from a user. A sensor may be, for instance, an accelerometer, a gyroscope, a tilt sensor, a force sensor, a magnetometer, an optical sensor, a proximity sensor, a biometric sensor, etc., or any combination thereof. An output device may use the same type of interface port as aninput device. For example, a Universal Serial Bus (USB) port may be used to provide an input device and an output device.

[0119] In some embodiments, the power source 1308 is structured as a battery or battery pack. Other types of power sources, such as an external power source (e.g., an electricity outlet), photovoltaic device, or power cell, may be used. The power source 1308 may further include power circuitry for delivering power from the power source 1308 itself, and / or an external power source, to the various parts of the UE 1300 via input circuitry or an interface such as an electrical power cable. Delivering power may be, for example, for charging of the power source 1308. Power circuitry may perform any formatting, converting, or other modification to the power from the power source 1308 to make the power suitable for the respective components of the UE 1300 to which power is supplied.

[0120] The memory 1310 may be or be configured to include memory such as random access memory (RAM), read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), magnetic disks, optical disks, hard disks, removable cartridges, flash drives, and so forth. In one example, the memory 1310 includes one or more application programs 1314, such as an operating system, web browser application, a widget, gadget engine, or other application, and corresponding data 1316. The memory 1310 may store, for use by the UE 1300, any of a variety of various operating systems or combinations of operating systems.

[0121] The memory 1310 may be configured to include a number of physical drive units, such as redundant array of independent disks (RAID), flash memory, USB flash drive, external hard disk drive, thumb drive, pen drive, key drive, high-density digital versatile disc (HD-DVD) optical disc drive, internal hard disk drive, Blu-Ray optical disc drive, holographic digital data storage (HDDS) optical disc drive, external mini-dual in-line memory module (DIMM), synchronous dynamic random access memory (SDRAM), external micro-DIMM SDRAM, smartcard memory such as tamper resistant module in the form of a universal integrated circuit card (UICC) including one or more subscriber identity modules (SIMs), such as a USIM and / or ISIM, other memory, or any combination thereof. The UICC may for example be an embedded UICC (eUICC), integrated UICC (iUICC) or a removable UICC commonly known as ‘SIM card.’ The memory 1310 may allow the UE 1300 to access instructions, application programs and the like, stored on transitory or non-transitory memory media, to off-load data, or to upload data. An article of manufacture, such as one utilizing a communication system may be tangibly embodied as or in the memory 1310, which may be or comprise a device-readable storage medium.

[0122] The processing circuitry 1302 may be configured to communicate with an access network or other network using the communication interface 1312. The communication interface 1312 may comprise one or more communication subsystems and may include or be communicatively coupled to an antenna 1322. The communication interface 1312 may include one or more transceivers used to communicate, such as by communicating with one or more remote transceivers of another device capable of wireless communication (e.g., another UE or a network node in an access network). Each transceiver may include a transmitter 1318 and / or a receiver 1320 appropriate to provide network communications (e.g., optical, electrical, frequency allocations, and so forth). Moreover, the transmitter 1318 and receiver 1320 may be coupled to one or more antennas (e.g., antenna 1322) and may share circuit components, software or firmware, or alternatively be implemented separately.

[0123] In some embodiments, communication functions of the communication interface 1312 may include cellular communication, Wi-Fi communication, LPWAN communication, data communication, voice communication, multimedia communication, short-range communications such as Bluetooth, near-field communication, location-based communication such as the use of the global positioning system (GPS) to determine a location, another like communication function, or any combination thereof. Communications may be implemented in according to one or more communication protocols and / or standards, such as IEEE 802.11, Code Division Multiplexing Access (CDMA), Wideband Code Division Multiple Access (WCDMA), GSM, LTE, New Radio (NR), UMTS, WiMax, Ethernet, transmission control protocol / internet protocol (TCP / IP), synchronous optical networking (SONET), Asynchronous Transfer Mode (ATM), QUIC, Hypertext Transfer Protocol (HTTP), and so forth.

[0124] Regardless of the type of sensor, a UE may provide an output of data captured by its sensors, through its communication interface 1312, via a wireless connection to a network node. Data captured by sensors of a UE can be communicated through a wireless connection to a network node via another UE. The output may be periodic (e.g., once every 15 minutes if it reports the sensed temperature), random (e.g., to even out the load from reporting from several sensors), in response to a triggering event (e.g., when moisture is detected an alert is sent), in response to a request (e.g., a user initiated request), or a continuous stream (e.g., a live video feed of a patient).

[0125] As another example, a UE comprises an actuator, a motor, or a switch, related to a communication interface configured to receive wireless input from a network node via a wireless connection. In response to the received wireless input the states of the actuator, the motor, or the switch may change. For example, the UE may comprise a motor that adjusts thecontrol surfaces or rotors of a drone in flight according to the received input or controls a robotic arm performing a medical procedure according to the received input.

[0126] A UE, when in the form of an Internet of Things (loT) device, may be a device for use in one or more application domains, these domains comprising, but not limited to, city wearable technology, extended industrial application and healthcare. Non-limiting examples of such an loT device are devices which are or which are embedded in: a connected refrigerator or freezer, a TV, a connected lighting device, an electricity meter, a robot vacuum cleaner, a voice controlled smart speaker, a home security camera, a motion detector, a thermostat, a smoke detector, a door / window sensor, a flood / moisture sensor, an electrical door lock, a connected doorbell, an air conditioning system like a heat pump, an autonomous vehicle, a surveillance system, a weather monitoring device, a vehicle parking monitoring device, an electric vehicle charging station, a smart watch, a fitness tracker, a head-mounted display for Augmented Reality (AR) or Virtual Reality (VR), a wearable for tactile augmentation or sensory enhancement, a water sprinkler, an animal- or item-tracking device, a sensor for monitoring a plant or animal, an industrial robot, an Unmanned Aerial Vehicle (UAV), and any kind of medical device, like a heart rate monitor or a remote controlled surgical robot. A UE in the form of an loT device comprises circuitry and / or software in dependence on the intended application of the loT device in addition to other components as described in relation to the UE 1300 shown in Figure 13.

[0127] As yet another specific example, in an loT scenario, a UE may represent a machine or other device that performs monitoring and / or measurements, and transmits the results of such monitoring and / or measurements to another UE and / or a network node. The UE may in this case be an M2M device, which may in a 3GPP context be referred to as an MTC device. As one particular example, the UE may implement the 3GPP NB-IoT standard. In other scenarios, a UE may represent a vehicle, such as a car, a bus, a truck, a ship and an airplane, or other equipment that is capable of monitoring and / or reporting on its operational status or other functions associated with its operation.

[0128] In practice, any number of UEs may be used together with respect to a single use case. For example, a first UE might be or be integrated in a drone and provide the drone’s speed information (obtained through a speed sensor) to a second UE that is a remote controller operating the drone. When the user makes changes from the remote controller, the first UE may adjust the throttle on the drone (e.g. by controlling an actuator) to increase or decrease the drone’s speed. The first and / or the second UE can also include more than one of the functionalities described above. For example, a UE might comprise the sensor and the actuator, and handle communication of data for both the speed sensor and the actuators.

[0129] Figure 14 shows a network node 1400 in accordance with some embodiments. As used herein, network node refers to equipment capable, configured, arranged and / or operable to communicate directly or indirectly with a UE and / or with other network nodes or equipment, in a telecommunication network. Examples of network nodes include, but are not limited to, access points (APs) (e.g., radio access points), base stations (BSs) (e.g., radio base stations, Node Bs, evolved Node Bs (eNBs) and NR NodeBs (gNBs)), 0-RAN nodes or components of an 0-RAN node (e.g., O-RU, O-DU, O-CU).

[0130] Base stations may be categorized based on the amount of coverage they provide (or, stated differently, their transmit power level) and so, depending on the provided amount of coverage, may be referred to as femto base stations, pico base stations, micro base stations, or macro base stations. A base station may be a relay node or a relay donor node controlling a relay. A network node may also include one or more (or all) parts of a distributed radio base station such as centralized digital units, distributed units (e.g., in an O-RAN access node) and / or remote radio units (RRUs), sometimes referred to as Remote Radio Heads (RRHs). Such remote radio units may or may not be integrated with an antenna as an antenna integrated radio. Parts of a distributed radio base station may also be referred to as nodes in a distributed antenna system (DAS).

[0131] Other examples of network nodes include multiple transmission point (multi-TRP) 5G access nodes, multi -standard radio (MSR) equipment such as MSR BSs, network controllers such as radio network controllers (RNCs) or base station controllers (BSCs), base transceiver stations (BTSs), transmission points, transmission nodes, multi-cell / multicast coordination entities (MCEs), Operation and Maintenance (O&M) nodes, Operations Support System (OSS) nodes, Self-Organizing Network (SON) nodes, positioning nodes (e.g., Evolved Serving Mobile Location Centers (E-SMLCs)), and / or Minimization of Drive Tests (MDTs).

[0132] The network node 1400 includes processing circuitry 1402, a memory 1404, a communication interface 1406, and a power source 1408, and / or any other component, or any combination thereof. The network node 1400 may be composed of multiple physically separate components (e.g., a NodeB component and a RNC component, or a BTS component and a BSC component, etc.), which may each have their own respective components. In certain scenarios in which the network node 1400 comprises multiple separate components (e.g., BTS and BSC components), one or more of the separate components may be shared among several network nodes. For example, a single RNC may control multiple NodeBs. In such a scenario, each unique NodeB and RNC pair, may in some instances be considered a single separate network node. In some embodiments, the network node 1400 may be configured to support multiple radio access technologies (RATs). In such embodiments, somecomponents may be duplicated (e.g., separate memory 1404 for different RATs) and some components may be reused (e.g., a same antenna 1410 may be shared by different RATs). The network node 1400 may also include multiple sets of the various illustrated components for different wireless technologies integrated into network node 1400, for example GSM, WCDMA, LTE, NR, WiFi, Zigbee, Z-wave, LoRaWAN, Radio Frequency Identification (RFID) or Bluetooth wireless technologies. These wireless technologies may be integrated into the same or different chip or set of chips and other components within network node 1400.

[0133] The processing circuitry 1402 may comprise a combination of one or more of a microprocessor, controller, microcontroller, central processing unit, digital signal processor, application-specific integrated circuit, field programmable gate array, or any other suitable computing device, resource, or combination of hardware, software and / or encoded logic operable to provide, either alone or in conjunction with other network node 1400 components, such as the memory 1404, network node 1400 functionality. For example, the processing circuitry 1402 may be configured to cause the network node to perform the methods as described with reference to Figure 3.

[0134] In some embodiments, the processing circuitry 1402 includes a system on a chip (SOC). In some embodiments, the processing circuitry 1402 includes one or more of radio frequency (RF) transceiver circuitry 1412 and baseband processing circuitry 1414. In some embodiments, the radio frequency (RF) transceiver circuitry 1412 and the baseband processing circuitry 1414 may be on separate chips (or sets of chips), boards, or units, such as radio units and digital units. In alternative embodiments, part or all of RF transceiver circuitry 1412 and baseband processing circuitry 1414 may be on the same chip or set of chips, boards, or units.

[0135] The memory 1404 may comprise any form of volatile or non-volatile computer- readable memory including, without limitation, persistent storage, solid-state memory, remotely mounted memory, magnetic media, optical media, random access memory (RAM), read-only memory (ROM), mass storage media (for example, a hard disk), removable storage media (for example, a flash drive, a Compact Disk (CD) or a Digital Video Disk (DVD)), and / or any other volatile or non-volatile, non-transitory device-readable and / or computerexecutable memory devices that store information, data, and / or instructions that may be used by the processing circuitry 1402. The memory 1404 may store any suitable instructions, data, or information, including a computer program, software, an application including one or more of logic, rules, code, tables, and / or other instructions capable of being executed by the processing circuitry 1402 and utilized by the network node 1400. The memory 1404 may be used to store any calculations made by the processing circuitry 1402 and / or any data receivedvia the communication interface 1406. In some embodiments, the processing circuitry 1402 and memory 1404 is integrated.

[0136] The communication interface 1406 is used in wired or wireless communication of signaling and / or data between a network node, access network, and / or UE. As illustrated, the communication interface 1406 comprises port(s) / terminal(s) 1416 to send and receive data, for example to and from a network over a wired connection. The communication interface 1406 also includes radio front-end circuitry 1418 that may be coupled to, or in certain embodiments a part of, the antenna 1410. Radio front-end circuitry 1418 comprises filters 1420 and amplifiers 1422. The radio front-end circuitry 1418 may be connected to an antenna 1410 and processing circuitry 1402. The radio front-end circuitry may be configured to condition signals communicated between antenna 1410 and processing circuitry 1402. The radio front-end circuitry 1418 may receive digital data that is to be sent out to other network nodes or UEs via a wireless connection. The radio front-end circuitry 1418 may convert the digital data into a radio signal having the appropriate channel and bandwidth parameters using a combination of filters 1420 and / or amplifiers 1422. The radio signal may then be transmitted via the antenna 1410. Similarly, when receiving data, the antenna 1410 may collect radio signals which are then converted into digital data by the radio front-end circuitry 1418. The digital data may be passed to the processing circuitry 1402. In other embodiments, the communication interface may comprise different components and / or different combinations of components.

[0137] In certain alternative embodiments, the network node 1400 does not include separate radio front-end circuitry 1418, instead, the processing circuitry 1402 includes radio front-end circuitry and is connected to the antenna 1410. Similarly, in some embodiments, all or some of the RF transceiver circuitry 1412 is part of the communication interface 1406. In still other embodiments, the communication interface 1406 includes one or more ports or terminals 1416, the radio front-end circuitry 1418, and the RF transceiver circuitry 1412, as part of a radio unit (not shown), and the communication interface 1406 communicates with the baseband processing circuitry 1414, which is part of a digital unit (not shown).

[0138] The antenna 1410 may include one or more antennas, or antenna arrays, configured to send and / or receive wireless signals. The antenna 1410 may be coupled to the radio frontend circuitry 1418 and may be any type of antenna capable of transmitting and receiving data and / or signals wirelessly. In certain embodiments, the antenna 1410 is separate from the network node 1400 and connectable to the network node 1400 through an interface or port.

[0139] The antenna 1410, communication interface 1406, and / or the processing circuitry 1402 may be configured to perform any receiving operations and / or certain obtaining operations described herein as being performed by the network node. Any information, dataand / or signals may be received from a UE, another network node and / or any other network equipment. Similarly, the antenna 1410, the communication interface 1406, and / or the processing circuitry 1402 may be configured to perform any transmitting operations described herein as being performed by the network node. Any information, data and / or signals may be transmitted to a UE, another network node and / or any other network equipment.

[0140] The power source 1408 provides power to the various components of network node 1400 in a form suitable for the respective components (e.g., at a voltage and current level needed for each respective component). The power source 1408 may further comprise, or be coupled to, power management circuitry to supply the components of the network node 1400 with power for performing the functionality described herein. For example, the network node 1400 may be connectable to an external power source (e.g., the power grid, an electricity outlet) via an input circuitry or interface such as an electrical cable, whereby the external power source supplies power to power circuitry of the power source 1408. As a further example, the power source 1408 may comprise a source of power in the form of a battery or battery pack which is connected to, or integrated in, power circuitry. The battery may provide backup power should the external power source fail.

[0141] Embodiments of the network node 1400 may include additional components beyond those shown in Figure 14 for providing certain aspects of the network node’s functionality, including any of the functionality described herein and / or any functionality necessary to support the subject matter described herein. For example, the network node 1400 may include user interface equipment to allow input of information into the network node 1400 and to allow output of information from the network node 1400. This may allow a user to perform diagnostic, maintenance, repair, and other administrative functions for the network node 1400.

[0142] Figure 18 shows a network node 1800 in accordance with some embodiments. As used herein, network node refers to equipment capable, configured, arranged and / or operable to communicate directly or indirectly with a UE and / or with other network nodes or equipment, in a telecommunication network. The network node 1800 may be operable as a core network node, a core network function or, more generally, a core network entity, such as the core network node 1208 described above with respect to Figure 12). Examples of network nodes in this context include core network entities such as one or more of a Mobile Switching Center (MSC), Mobility Management Entity (MME), Home Subscriber Server (HSS), Access and Mobility Management Function (AMF), Session Management Function (SMF), Authentication Server Function (AUSF), Subscription Identifier De-concealing function (SIDF), Unified Data Management (UDM), Security Edge Protection Proxy (SEPP), Network Exposure Function (NEF), Policy Control Function (PCF) and / or a User Plane Function (UPF).

[0143] The network node 1800 includes processing circuitry 1802, a memory 1804, a communication interface 1806, and a power source 1808, and / or any other component, or any combination thereof. The network node 1800 may be composed of multiple physically separate components, which may each have their own respective components. In certain scenarios in which the network node 1800 comprises multiple separate components, one or more of the separate components may be shared among several network nodes.

[0144] The processing circuitry 1802 may comprise a combination of one or more of a microprocessor, controller, microcontroller, central processing unit, digital signal processor, application-specific integrated circuit, field programmable gate array, or any other suitable computing device, resource, or combination of hardware, software and / or encoded logic operable to provide, either alone or in conjunction with other network node 1800 components, such as the memory 1804, network node 1800 functionality. For example, the processing circuitry 1802 may be configured to cause the network node to perform the methods as described with reference to Figure 4.

[0145] The memory 1804 may comprise any form of volatile or non-volatile computer- readable memory including, without limitation, persistent storage, solid-state memory, remotely mounted memory, magnetic media, optical media, random access memory (RAM), read-only memory (ROM), mass storage media (for example, a hard disk), removable storage media (for example, a flash drive, a Compact Disk (CD) or a Digital Video Disk (DVD)), and / or any other volatile or non-volatile, non-transitory device-readable and / or computerexecutable memory devices that store information, data, and / or instructions that may be used by the processing circuitry 1802. The memory 1804 may store any suitable instructions, data, or information, including a computer program, software, an application including one or more of logic, rules, code, tables, and / or other instructions capable of being executed by the processing circuitry 1802 and utilized by the network node 1800. The memory 1804 may be used to store any calculations made by the processing circuitry 1802 and / or any data received via the communication interface 1806. In some embodiments, the processing circuitry 1802 and memory 1804 is integrated.

[0146] The communication interface 1806 is used in wired or wireless communication of signaling and / or data between a network node, access network, and / or UE.

[0147] The power source 1808 provides power to the various components of network node 1800 in a form suitable for the respective components (e.g., at a voltage and current level needed for each respective component). The power source 1808 may further comprise, or be coupled to, power management circuitry to supply the components of the network node 1800 with power for performing the functionality described herein. For example, the network node 1800 may be connectable to an external power source (e.g., the power grid, an electricityoutlet) via an input circuitry or interface such as an electrical cable, whereby the external power source supplies power to power circuitry of the power source 1808. As a further example, the power source 1808 may comprise a source of power in the form of a battery or battery pack which is connected to, or integrated in, power circuitry. The battery may provide backup power should the external power source fail.

[0148] Embodiments of the network node 1800 may include additional components beyond those shown in Figure 18 for providing certain aspects of the network node’s functionality, including any of the functionality described herein and / or any functionality necessary to support the subject matter described herein. For example, the network node 1800 may include user interface equipment to allow input of information into the network node 1800 and to allow output of information from the network node 1800. This may allow a user to perform diagnostic, maintenance, repair, and other administrative functions for the network node 1800.

[0149] Figure 15 is a block diagram of a host 1500, which may be an embodiment of the host 1216 of Figure 12, in accordance with various aspects described herein. As used herein, the host 1500 may be or comprise various combinations hardware and / or software, including a standalone server, a blade server, a cloud-implemented server, a distributed server, a virtual machine, container, or processing resources in a server farm. The host 1500 may provide one or more services to one or more UEs.

[0150] The host 1500 includes processing circuitry 1502 that is operatively coupled via a bus 1504 to an input / output interface 1506, a network interface 1508, a power source 1510, and a memory 1512. Other components may be included in other embodiments. Features of these components may be substantially similar to those described with respect to the devices of previous figures, such as Figures 13 and 14, such that the descriptions thereof are generally applicable to the corresponding components of host 1500.

[0151] The memory 1512 may include one or more computer programs including one or more host application programs 1514 and data 1516, which may include user data, e.g., data generated by a UE for the host 1500 or data generated by the host 1500 for a UE. Embodiments of the host 1500 may utilize only a subset or all of the components shown. The host application programs 1514 may be implemented in a container-based architecture and may provide support for video codecs (e.g., Versatile Video Coding (VVC), High Efficiency Video Coding (HEVC), Advanced Video Coding (AVC), MPEG, VP9) and audio codecs (e.g., FLAC, Advanced Audio Coding (AAC), MPEG, G.711), including transcoding for multiple different classes, types, or implementations of UEs (e.g., handsets, desktop computers, wearable display systems, heads-up display systems). The host application programs 1514 may also provide for user authentication and licensing checks and may periodically report health, routes, and content availability to a central node, such as a device in or on the edge of a corenetwork. Accordingly, the host 1500 may select and / or indicate a different host for over-the- top services for a UE. The host application programs 1514 may support various protocols, such as the HTTP Live Streaming (HLS) protocol, Real-Time Messaging Protocol (RTMP), Real-Time Streaming Protocol (RTSP), Dynamic Adaptive Streaming over HTTP (MPEG- DASH), etc.

[0152] Figure 16 is a block diagram illustrating a virtualization environment 1600 in which functions implemented by some embodiments may be virtualized. In the present context, virtualizing means creating virtual versions of apparatuses or devices which may include virtualizing hardware platforms, storage devices and networking resources. As used herein, virtualization can be applied to any device described herein, or components thereof, and relates to an implementation in which at least a portion of the functionality is implemented as one or more virtual components. Some or all of the functions described herein may be implemented as virtual components executed by one or more virtual machines (VMs) implemented in one or more virtual environments 1600 hosted by one or more of hardware nodes, such as a hardware computing device that operates as a network node, UE, core network node, or host. Further, in embodiments in which the virtual node does not require radio connectivity (e.g., a core network node or host), then the node may be entirely virtualized. In some embodiments, the virtualization environment 1600 includes components defined by the O-RAN Alliance, such as an O-Cloud environment orchestrated by a Service Management and Orchestration Framework via an O-2 interface.

[0153] Applications 1602 (which may alternatively be called software instances, virtual appliances, network functions, virtual nodes, virtual network functions, etc.) are run in the virtualization environment Q400 to implement some of the features, functions, and / or benefits of some of the embodiments disclosed herein.

[0154] Hardware 1604 includes processing circuitry, memory that stores software and / or instructions executable by hardware processing circuitry, and / or other hardware devices as described herein, such as a network interface, input / output interface, and so forth. Software may be executed by the processing circuitry to instantiate one or more virtualization layers 1606 (also referred to as hypervisors or virtual machine monitors (VMMs)), provide VMs 1608a and 1608b (one or more of which may be generally referred to as VMs 1608), and / or perform any of the functions, features and / or benefits described in relation with some embodiments described herein. The virtualization layer 1606 may present a virtual operating platform that appears like networking hardware to the VMs 1608.

[0155] The VMs 1608 comprise virtual processing, virtual memory, virtual networking or interface and virtual storage, and may be run by a corresponding virtualization layer 1606. Different embodiments of the instance of a virtual appliance 1602 may be implemented onone or more of VMs 1608, and the implementations may be made in different ways. Virtualization of the hardware is in some contexts referred to as network function virtualization (NFV). NFV may be used to consolidate many network equipment types onto industry standard high volume server hardware, physical switches, and physical storage, which can be located in data centers, and customer premise equipment.

[0156] In the context of NFV, a VM 1608 may be a software implementation of a physical machine that runs programs as if they were executing on a physical, non-virtualized machine. Each of the VMs 1608, and that part of hardware 1604 that executes that VM, be it hardware dedicated to that VM and / or hardware shared by that VM with others of the VMs, forms separate virtual network elements. Still in the context of NFV, a virtual network function is responsible for handling specific network functions that run in one or more VMs 1608 on top of the hardware 1604 and corresponds to the application 1602.

[0157] Hardware 1604 may be implemented in a standalone network node with generic or specific components. Hardware 1604 may implement some functions via virtualization. Alternatively, hardware 1604 may be part of a larger cluster of hardware (e.g. such as in a data center or CPE) where many hardware nodes work together and are managed via management and orchestration 1610, which, among others, oversees lifecycle management of applications 1602. In some embodiments, hardware 1604 is coupled to one or more radio units that each include one or more transmitters and one or more receivers that may be coupled to one or more antennas. Radio units may communicate directly with other hardware nodes via one or more appropriate network interfaces and may be used in combination with the virtual components to provide a virtual node with radio capabilities, such as a radio access node or a base station. In some embodiments, some signaling can be provided with the use of a control system 1612 which may alternatively be used for communication between hardware nodes and radio units.

[0158] Figure 17 shows a communication diagram of a host 1702 communicating via a network node 1704 with a UE 1706 over a partially wireless connection in accordance with some embodiments. Example implementations, in accordance with various embodiments, of the UE (such as a UE 1212a of Figure 12 and / or UE 1300 of Figure 13), network node (such as network node 1210a of Figure 12 and / or network node 1400 of Figure 14), and host (such as host 1216 of Figure 12 and / or host 1500 of Figure 15) discussed in the preceding paragraphs will now be described with reference to Figure 17.

[0159] Like host 1500, embodiments of host 1702 include hardware, such as a communication interface, processing circuitry, and memory. The host 1702 also includes software, which is stored in or accessible by the host 1702 and executable by the processing circuitry. The software includes a host application that may be operable to provide a serviceto a remote user, such as the UE 1706 connecting via an over-the-top (OTT) connection 1750 extending between the UE 1706 and host 1702. In providing the service to the remote user, a host application may provide user data which is transmitted using the OTT connection 1750.

[0160] The network node 1704 includes hardware enabling it to communicate with the host 1702 and UE 1706. The connection 1760 may be direct or pass through a core network (like core network 1206 of Figure 12) and / or one or more other intermediate networks, such as one or more public, private, or hosted networks. For example, an intermediate network may be a backbone network or the Internet.

[0161] The UE 1706 includes hardware and software, which is stored in or accessible by UE 1706 and executable by the UE’s processing circuitry. The software includes a client application, such as a web browser or operator-specific “app” that may be operable to provide a service to a human or non-human user via UE 1706 with the support of the host 1702. In the host 1702, an executing host application may communicate with the executing client application via the OTT connection 1750 terminating at the UE 1706 and host 1702. In providing the service to the user, the UE's client application may receive request data from the host's host application and provide user data in response to the request data. The OTT connection 1750 may transfer both the request data and the user data. The UE's client application may interact with the user to generate the user data that it provides to the host application through the OTT connection 1750.

[0162] The OTT connection 1750 may extend via a connection 1760 between the host 1702 and the network node 1704 and via a wireless connection 1770 between the network node 1704 and the UE 1706 to provide the connection between the host 1702 and the UE 1706. The connection 1760 and wireless connection 1770, over which the OTT connection 1750 may be provided, have been drawn abstractly to illustrate the communication between the host 1702 and the UE 1706 via the network node 1704, without explicit reference to any intermediary devices and the precise routing of messages via these devices.

[0163] As an example of transmitting data via the OTT connection 1750, in step 1708, the host 1702 provides user data, which may be performed by executing a host application. In some embodiments, the user data is associated with a particular human user interacting with the UE 1706. In other embodiments, the user data is associated with a UE 1706 that shares data with the host 1702 without explicit human interaction. In step 1710, the host 1702 initiates a transmission carrying the user data towards the UE 1706. The host 1702 may initiate the transmission responsive to a request transmitted by the UE 1706. The request may be caused by human interaction with the UE 1706 or by operation of the client application executing on the UE 1706. The transmission may pass via the network node 1704, in accordance with the teachings of the embodiments described throughout this disclosure. Accordingly, in step 1712,the network node 1704 transmits to the UE 1706 the user data that was carried in the transmission that the host 1702 initiated, in accordance with the teachings of the embodiments described throughout this disclosure. In step 1714, the UE 1706 receives the user data carried in the transmission, which may be performed by a client application executed on the UE 1706 associated with the host application executed by the host 1702.

[0164] In some examples, the UE 1706 executes a client application which provides user data to the host 1702. The user data may be provided in reaction or response to the data received from the host 1702. Accordingly, in step 1716, the UE 1706 may provide user data, which may be performed by executing the client application. In providing the user data, the client application may further consider user input received from the user via an input / output interface of the UE 1706. Regardless of the specific manner in which the user data was provided, the UE 1706 initiates, in step 1718, transmission of the user data towards the host 1702 via the network node 1704. In step 1720, in accordance with the teachings of the embodiments described throughout this disclosure, the network node 1704 receives user data from the UE 1706 and initiates transmission of the received user data towards the host 1702. In step 1722, the host 1702 receives the user data carried in the transmission initiated by the UE 1706.

[0165] One or more of the various embodiments improve the performance of OTT services provided to the UE 1706 using the OTT connection 1750, in which the wireless connection 1770 forms the last segment. More precisely, the teachings of these embodiments may improve the integration of ACME into SBA systems and thereby provide benefits such as improved system versatility.

[0166] In an example scenario, factory status information may be collected and analyzed by the host 1702. As another example, the host 1702 may process audio and video data which may have been retrieved from a UE for use in creating maps. As another example, the host 1702 may collect and analyze real-time data to assist in controlling vehicle congestion (e.g., controlling traffic lights). As another example, the host 1702 may store surveillance video uploaded by a UE. As another example, the host 1702 may store or control access to media content such as video, audio, VR or AR which it can broadcast, multicast or unicast to UEs. As other examples, the host 1702 may be used for energy pricing, remote control of non-time critical electrical load to balance power generation needs, location services, presentation services (such as compiling diagrams etc. from data collected from remote devices), or any other function of collecting, retrieving, storing, analyzing and / or transmitting data.

[0167] In some examples, a measurement procedure may be provided for the purpose of monitoring data rate, latency and other factors on which the one or more embodiments improve. There may further be an optional network functionality for reconfiguring the OTTconnection 1750 between the host 1702 and UE 1706, in response to variations in the measurement results. The measurement procedure and / or the network functionality for reconfiguring the OTT connection may be implemented in software and hardware of the host 1702 and / or UE 1706. In some embodiments, sensors (not shown) may be deployed in or in association with other devices through which the OTT connection 1750 passes; the sensors may participate in the measurement procedure by supplying values of the monitored quantities exemplified above, or supplying values of other physical quantities from which software may compute or estimate the monitored quantities. The reconfiguring of the OTT connection 1750 may include message format, retransmission settings, preferred routing etc.; the reconfiguring need not directly alter the operation of the network node 1704. Such procedures and functionalities may be known and practiced in the art. In certain embodiments, measurements may involve proprietary UE signaling that facilitates measurements of throughput, propagation times, latency and the like, by the host 1702. The measurements may be implemented in that software causes messages to be transmitted, in particular empty or ‘dummy’ messages, using the OTT connection 1750 while monitoring propagation times, errors, etc.

[0168] Although the computing devices described herein (e.g., UEs, network nodes, hosts) may include the illustrated combination of hardware components, other embodiments may comprise computing devices with different combinations of components. It is to be understood that these computing devices may comprise any suitable combination of hardware and / or software needed to perform the tasks, features, functions and methods disclosed herein. Determining, calculating, obtaining or similar operations described herein may be performed by processing circuitry, which may process information by, for example, converting the obtained information into other information, comparing the obtained information or converted information to information stored in the network node, and / or performing one or more operations based on the obtained information or converted information, and as a result of said processing making a determination. Moreover, while components are depicted as single boxes located within a larger box, or nested within multiple boxes, in practice, computing devices may comprise multiple different physical components that make up a single illustrated component, and functionality may be partitioned between separate components. For example, a communication interface may be configured to include any of the components described herein, and / or the functionality of the components may be partitioned between the processing circuitry and the communication interface. In another example, non-computationally intensive functions of any of such components may be implemented in software or firmware and computationally intensive functions may be implemented in hardware.

[0169] In certain embodiments, some or all of the functionality described herein may be provided by processing circuitry executing instructions stored on in memory, which in certain embodiments may be a computer program product in the form of a non-transitory computer- readable storage medium. In alternative embodiments, some or all of the functionality may be provided by the processing circuitry without executing instructions stored on a separate or discrete device-readable storage medium, such as in a hard-wired manner. In any of those particular embodiments, whether executing instructions stored on a non-transitory computer- readable storage medium or not, the processing circuitry can be configured to perform the described functionality. The benefits provided by such functionality are not limited to the processing circuitry alone or to other components of the computing device, but are enjoyed by the computing device as a whole, and / or by end users and a wireless network generally.

[0170] The following appendices provide additional information on the disclosure:APPENDICESAppendix A High level description of ACMEThis section is essentially illustrative and mostly summarizes the ACME exchanges. It assumes the reader is familiar with relevant publication.A.l DNS challengeThis section intends to briefly illustrate of ACME as described in [RFC8555] proceeds at a very high level.ACME has been designed for web server and enables to automate the verification by the CA of the ownership and control of the domain name and the key that are certified by the CA. More typically, a ACME Client creates an account based on a given key k publ and k_priv is used to sign these exchanges as to prove the ownership of the key. The ACME Client is not necessarily authenticated via any other means. Once the ACME Client has an account he creates an order to the ACME Server for the creation of a certificate associated to a specific FQDN. The ACME Server provides authorizations which contains challenges, that is operations that will provide sufficient confidence to the ACME Server, the ACME Client has control over the DNS FQDN or the web server. These challenges mostly consist in creating an HTTP web page or a DNS RRset, and the ACME Client notifies the ACME Server it can verify the challenges are completed. The ACME Server checks the challenges can be completed. When the verification has been completed, the ACME Client sends a CSR request.The ACME protocol is summed up below:ACME Client ACMEServer DNS / HTTP server< - Account Creation - >## The creation of an account consists in the registration of k_pub . ## In our case , the k_pub is associated to email addresses in case ## the ACME server needs to reach the account owner .## The resulting account is: https: / / example.com / acme / acct / evOfKhNU60wgPOST / acme / new-account HTTP / 1.1Host: example.comContent-Type : application / j ose+j son { "protected": base64url ( {"alg": "ES256", ## k_publ" jwk" : { ... }, "nonce" : "6S8IqOGY7eL21sGoTZYifg", "url" : "https : / / example . com / acme / new-account" }) , "payload": base64url ({"termsOf ServiceAgreed" : true, "contact" : ["mailto : cert-admin@example . org" ,"mailto : admin@example . org"]}) ,"signature": "RZPOnYoPslPhj szF . . . -nh6XlqtOFPB519I " ## JWT signature that proves the ownership of k_priv }HTTP / 1.1 201 Created ## status of the account creation requestContent-Type : application / j sonReplay-Nonce : D8s4D2mLs8Vn-goWuPQeKA ## nonce to be used nextLink :<https : / / example . com / acme / directory>; rel="index" ## directory Location : https: / / example.com / acme / acct / evOfKhNU60wg ## account{"status": "valid", "contact" : ["mailto : cert- admin@example . org" , "mailto : admin@example . org"] ,"orders " :"https: / / example.com / acme / acct / evOfKhNU60wg / orders" ## list of orders associated} ## to the account< - Order for certificate issuance## an order represents a request for the issuance of a certificate.## in this case, the certificate is associated to the DNS FQDNs## www.example.org and example.org.## an order object is created https : / / example . com / acme / order / TO!ocE8rfgo## - "authorizations" contains the challenges that are provided by the ACME server## to the ACME Client to prove the ownership of the FQDNs## - "finalized" is the url the CSR will have to be posted to.POST / acme / new-order HTTP / 1.1Host: example.comContent-Type : application / j ose+j son { "protected": base64url ( { "alg" : "ES256" , "kid": "https: / / example.com / acme / acct / evOfKhNU60wg", ## k_pub of the account "nonce" : "D8s4D2mLs8Vn-goWuPQeKA" , "url" : "https : / / example . com / acme / new-order " }) , "payload": base64url ({ "identifiers": [ { "type": "dns", "value": "www.example.org" }, { "type": "dns", "value": "example.org" } ] , "notBefore": "2016-01-01T00 : 04 : 00+04 : 00", ## characteristics for the certificate that "notAfter": "2016-01-08T00 : 04 : 00+04 : 00" ## are not carried in a CSR }) , "signature": "H6ZXtGj TZyUnPeKn . . . wEA4TklBdh3e454g" }HTTP / 1.1 201 CreatedReplay-Nonce :MYAuv0paoIiywTezizk5vwLink : <https : / / example . com / acme / directory>; rel="index" Location : https: / / example.com / acme / order / T01ocE8rf o ## order { "status" : "pending" , "expires": "2016- 01-05T14 : 09 : 07.99Z", "notBefore": "2016- 01-01T00 : 00 : 00Z", "notAfter": "2016- 01-08T00 : 00 : 00Z", "identifiers": [ { "type" : "dns", "value": "www.example.org" }, { "type" : "dns", "value": "example.org" } ] , "authorizations": [ "https : / / example . com / acme / authz / PAniVns Zeis " , "https : / / example . com / acme / authz / r4HqLzrSrpI " ] , "finalize" : "https : / / example . com / acme / order / T01ocE8rfgo / finalize" } < - Requesting Authorizations - >## The authorizations contains the challenges ## in our case https: / / example.com / acme / authz / PAniVnsZcis contains two challenges ## and the ACME Client may select one or the other.## In our case, the ACME Client picked the dns-01 challenge which requires## the addition of a RRSet into the DNS.POST / acme / authz / PAniVnsZcis HTTP / 1.1Host: example.comContent-Type : application / j ose+j son{"protected": base64url ( {"alg" : "ES256" ,"kid" : "https : / / example . com / acme / acct / evOfKhNU60wg" ,"nonce" : "MYAuvOpaoIiywTezizk5vw" ,"url" : "https : / / example . com / acme / authz / PAniVnsZcis"}) ,"payload" : " " ,"signature": "nuSDISbWG8mMgE7H . . . QyVUL68yzf3Zawps"}HTTP / 1.1 200 OK Content-Type : application / j sonLink :<https : / / example . com / acme / directory>; rel="index"{"status" :"pending", ## authorization status"expires": "2016- 01-02T14 : 09 : 30Z","identifier" : { "type" : "dns", "value" :"www. example . org"},"challenges " : [ {"type" :"http-01","url " :"https : / / example . com / acme / chai l / prV_B7yEyA4 " , "token" :"DGyRe jmCef e7v4Nf DGDKf A"}, {"type" : "dns- 01","url " :"https : / / example . com / acme / chall / Rg5dV14GhlQ" ,"token" :"DGyRe jmCefe7v4Nf DGDKf A"}]}< - Achieving the Challenge - >## RFC8555 defines two types of challenges dns-01 and http-01.## Once verified, the challenge status is set to "valid".## For a dns-01 challenge_acme-challenge.www.example.org. 300 IN TXT "token | | ' | | base64url (SHA256 (k_pub) ) "## For a http-01 challenge / . well-known / acme-challenge / token | | | | base64url (SHA256 (k_pub) ) token | | ' | | base64url (SHA256 (k_pub) )< - Notifying Challenge has been achieved - >## To indicate the change has been performed by the ACME Client, the ACME Client## sends a void { } messages.## The ACME server is then able to validate and move the authorization from## pending to valid.POST / acme / chall / Rg5dV14GhlQ HTTP / 1.1Host: example.comContent-Type : application / j ose+j son{"protected": base64url ( {"alg" : "ES256" ,"kid" : "https : / / example . com / acme / acct / evOfKhNU60wg" ,"nonce" : "Q_s3MWoqT05TrdkM2MTDcw" ,"url" : "https : / / example . com / acme / chall / Rg5dV14GhlQ" }) , "payload" : base64url ( { } ) ,"signature": " 9cbg5 JOlGf 5YL j j z . . . SpkUfcdPai9uVYYQ"}HTTP / 1.1 200 OK Content-Type : application / j sonLink : <https : / / example . com / acme / directory>; rel="index"< - ACME server validates the challenges - >## RFC8555 defines two types of challenges dns-01 and http-01.## Once verified, the challenge status is set to "valid".## For a dns-01 challengeDNS acmechallenge . www. example . org - ><-- _acme- challenge.www.example.org. 300 IN TXT "token | | | | base64url (SHA256 (k_pub) ) "## For a http-01 challengeGET / .well- known / acme-challenge / token | | | | base64url (SHA256 (k_pub) )Host : example . orgHTTP / 1.1 200 OK Content-Type : application / octet- st ream token | | I I base64url (SHA256 (k_pub) )WP < - Checking ACME server has validated the Challenge(Optional) - >POST / acme / authz / PAniVnsZcis HTTP / 1.1Host: example.comContent-Type : application / j ose+j son{"protected": base64url ( {"alg" : "ES256" ,"kid" : "https : / / example . com / acme / acct / evOfKhNU60wg" ,"nonce" : "uQpS j !Rb4vQVC j VYAyyUWg" ,"url" : "https : / / example . com / acme / authz / PAniVnsZcis"}) ,"payload" : " " ,"signature": "nuSDISbWG8mMgE7H . . . QyVUL68yzf3Zawps"}HTTP / 1.1 200 OK Content-Type : application / j sonLink :<https : / / example . com / acme / directory>; rel="index"{"status" :"valid" ,"expires": "2018- 09-09T14 : 09 : 01.13Z","identifier" : { "type" : "dns", "value" :"www. example . org"},"challenges " : [{"type" : "dns- 01","url " :"https : / / example . com / acme / chai l / prV_B7yEyA4 " ,"status" :"valid" ,"validated" :"2014- 12- 01T12 : 05 : 13.72Z", "token" :" Ilir f xKKXAsHtmzK29P j 8A"}]}< - CSR request - >## Once the authorization has a valid status, the ACME Client requests## a certificate with a CSR.## The ACME Client MAY perform POST-as-GET to check the status of## https: / / example.com / acme / chall / prV_B7yEyA4 .## These exchanges are not represented here.## Upon receiving it, the ACME server generate the certificatePOST / acme / order / T01ocE8rfgo / finalize HTTP / 1.1Host: example.comContent-Type : application / j ose+j son{"protected": base64url ( {"alg" : "ES256" ,"kid" : "https : / / example . com / acme / acct / evOfKhNU60wg" ,"nonce" : "MSF2 j 2nawWHPxxkE3Z JtKQ" ,"url" : "https : / / example . com / acme / order / T01ocE8rf go / finalize" }) , "payload": base64url ({"csr": "MI IBPTCBxAIBADBFMQ . . . FS6aKdZeGsysoCo4H9P" ,}) ,"signature": "uOrUf IIk5RyQ . . . nw62Aylcl6AB"}HTTP / 1.1 200 OKReplay-Nonce :CGf 81 JWBsq8QyIgPCi 9Q9XLink :<https : / / example . com / acme / directory>; rel="index"Location : https : / / example . com / acme / order / T01ocE8rfgo{"status" :"valid" ,"expires " :"2016- 01-20T14 :09:07.99Z","notBefore" :"2016- 01- 0 ITO 0 : 00 : 00Z","notAf ter " :"2016- 01- 08T00 : 00 : 00Z","identifiers": [ { "type": "dns", "value": "www.example.org" },{ "type": "dns", "value": "example.org" }] ,"authorizations": ["https : / / example . com / acme / authz / PAniVns Zeis " ,"https : / / example . com / acme / authz / r4HqLzrSrpI "] ,"finalize" :"https : / / example . com / acme / order / T01ocE8rf go / finalize" ,"certificate" :"https : / / example . com / acme / cert / mAt3xBGaobw"}< - Downloading Certificates - >## When the order is set to valid, the certificates have been processed ## and the ACME Client downloads these certificates.POST / acme / cert / mAt3xBGaobw HTTP / 1 . 1Host : example . comContent-Type : application / j ose+j sonAccept : application / pem-certi ficate-chain{"protected" : base64url ( {"alg" : "ES256" ," kid" : "https : / / example . com / acme / acct / evOfKhNU60wg" ,"nonce" : "uQpS j !Rb4vQVC j VYAyyUWg" ,"url" : "https : / / example . com / acme / cert / mAt3xBGaobw"} ) ,"payload" : " " ," signature" : "nuSDISbWG8mMgE7H . . . QyVUL68yz f3Zawps"}HTTP / 1 . 1 200 OK Content-Type : application / pem-certi f icate-chainLink :<https : / / example . com / acme / directory>; rel="index"- BEGIN CERTI FICATE -[ End-entity certi ficate contents ]- ENDCERTI FICATE -- BEGINCERTI FICATE -[ I ssuer certi ficate contents ]- ENDCERTI FICATE -- BEGINCERTI FICATE -[ Other certi ficate contents ]- END CERTI FICATE -ACME protocol is relatively insecure unless sufficient precautions are taken to make the validation performed by ACME server reliable. More specifically, an attacker that is able to spoof traffic to the ACME Server is able to issue a certificate without having control of the resource - FQDN or HTTP. The reason is that DNS or HTTP traffic that validates the creation of a RRSet (resp. a web page) are not protected and could be performed by an attacker. When a DNS challenge is used, DNSSEC ensures the legitimate RRset has been created, but there are no evidence for the ACME Client that DNSSEC is being used. There is no way the HTTP can be sufficiently protected. Similarly TLS-ALPN challenges does not provides evidence the IP traffic is not being redirected.Note that [DBLP:conf / fc / BhargavanDK17] is a formal verification of the ACME but does not consider the latest version of ACME (ACMEv2) as standardized in [RFC8555], However, it is likely the result from [DBLP:conf / fc / BhargavanDK17] influenced [RFC8555], [DBLP:conf / fc / BhargavanDK17] provides a formal verification and the conclusion is NOT the protocol is secured, but seems - at least to my interpretation - that it provides more confidence in the verification to issue certificate than what used to be done without ACME. I am not reading the [RFC8555] be that clear.[DBLP:conf / fc / BhargavanDK17] mentions that the DNS challenge is not provided by Let’sEncrypt, but this does not seems correct at the time of writing and mentioned on Let’s Encrypt web site [letsencrypt-challenge-types]. In the context of web servers, the use of the DNS challenge requires some specific interfaces with the DNS provisioning which may come with two drawbacks. Firstly delays might be consequent between the configuration for an update and the update being effective. Secondly, it requires in a web server context to have all DNS credentials co-located in the web server, which is not recommended. Both issues are resolved by outsourcing the DNS infrastructure as defined in [draft-ietf-homenet- front-end-naming-delegation],A.2 Authority Token ChallengeThis section summarizes the exchanges associated to the Authorization Token challenge. The Token Authority architecture is defined in [RFC9447] and the specific used token is defined in [RFC9448], The use of that specific token is not applicable in our case, and we would need to design a specific token for our own purpose.< - Account Creation - >< - Order for certificate issuance## This works similarly to the dns-01 challenge, the main## difference is that the type of identifier is not a dns name ## but an opaque value thta designates telephone numbers.POST / acme / new-order HTTP / 1.1Host: example.comContent-Type : application / j ose+j son{"protected": base64url ( {"alg" : "ES256" ,"kid" : "https : / / example . com / acme / acct / evOfKhNU60wg" ,"nonce" : "5XJlL31EkMG7tR6pA00clA" ,"url" : "https : / / example . com / acme / new-order "}) ,"payload": base64url ({"identifiers " : [ { "type" : "TNAuthList " , "value" : "F83n . . . n27DN3 " } ] , "notBefore" : "2021-01-01T00:00:00Z", "not fter" : "2021-01-08T00:00:00Z"}) , "signature": "H6ZXtGjTZyUnPeKn . . . wEA4TklBdh3e454g" }HTTP / 1.1 201CreatedContent-Type : application / j sonReplay-Nonce :MYAuv0paoIiywTezizk5vwLocation : https : / / example . com / acme / order / 1234{"status" :"pending" ,"expires": "2022-01-08T00 : 00 : 00Z","notBefore" :"2022- 01-01T00 : 00 : 00Z","notAfter" :"2022- 01- 08T00 : 00 : 00Z","identifiers" : [ { "type" : "TNAuthList","value" : "F83n2a . . . avn27DN3" } ] ,"authorizations" :["https : / / example . com / acme / authz / 1234""finalize" :"https : / / example . com / acme / order / 1234 / finalize"< - Requesting Authorizations - >## The authorization request happens as described in the dns-01 section .## The only difference is that in this case, the ACME server proposes## the tkauth-01 challenge.## The authorizations contains the challenges## in our case https: / / example.com / acme / authz / PAniVnsZcis contains two challenges## and the ACME Client may select one or the other.POST / acme / authz / PAniVnsZcis HTTP / 1.1Host: example.comContent-Type : application / j ose+j son{"protected": base64url ( {"alg" : "ES256" ,"kid" : "https : / / example . com / acme / acct / evOfKhNU60wg" ,"nonce" : "MYAuvOpaoIiywTezizk5vw" ,"url" : "https : / / example . com / acme / authz / PAniVnsZcis"}) ,"payload" : " " ,"signature": "nuSDISbWG8mMgE7H . . . QyVUL68yzf3Zawps"}HTTP / 1.1 200 OKContent-Type : application / j sonLink :<https : / / example . com / acme / some-directory>; rel="index"{"status" :"pending" ,"expires": "2022- 01-08T00 : 00 : 00Z","identifier" : {"type" : "TNAuthList" ,"value" : "F83n2a . . . avn27DN3"},"challenges " : [{"type" : "tkauth-01","tkauth- type" : "ate" ,"token- authority" : "https : / / authority . example . org" ,"url " :"https : / / example . com / acme / chai l / prV_B7yEyA4 " ,"token" :" Ilir f xKKXAsHtmzK29P j 8A"< - Achieving the Challenge - >ACME Client Token AuthorityPOST / at / account / : id / token HTTP / 1.1Host: authority.example.orgContent-Type: application / j son"tktype" : "TNAuthList" ,"tkvalue" : "F83n2a . . . avn27DN3 " ,"ca" : false,"fingerprint" : "SHA256 56 : 3E : CF : AE : 83 : CA: 4D : 15 : BO : 29 : FF : IB : 71 : D3: BA: B9 : 19 : 81 : F8 : 50 : 9B : DF : 4A: D4 : 39 : 72 : E2 : Bl : FO : B9 : 38 : E3 "HTTP / 1.1 200 OK Content-Type : application / j son{ "token" :"DGyRe jmCef e7v4N . . . vb29Hh j j LPSggwiE " }### The token is typically:{"protected": base64url ( {"typ" : " JWT" ,"alg" : "ES256" ,"x5u" : "https : / / authority. example . org / cert"}) ,"payload": base64url ({"iss ": "https : / / authority . example . org" ,"exp" : 1640995200," jti" : "id6098364921 " ,"ate" : { "tktype" : "TNAuthList" ,"tkvalue" : "F83n2a. . . avn27DN3","ca" : false,"fingerprint" : "SHA256 56 : 3E : CF : AE : 83 : CA: 4D : 15 : BO : 29 : FF : IB : 71 : D3 : BA: B9 : 19 : 81 : F8 : 50 : 9B : DF : 4A: D4 : 39 : 72 : E2 : Bl : FO : B9 : 38 : E3 " } }) , "signature": " 9cbg5 JOlGf 5YL j j z . . . SpkUfcdPai9uVYYQ"< - Notifying Challenge has been achieved - >## The main difference with the dns-01 challenge is that here,## the token received by the Token Authority is included into the notification## the challenge has been performed.## This is different from the dns-01 challenge were the notification is void## a sthe ACME server doe snot need additional information to validate the challenge .POST / acme / chall / prV_B7yEyA4 HTTP / 1 . 1 Host : boulder . example . com Content-Type : application / j ose+j son { "protected" : base64url ( { "alg" : "ES256" , " kid" : "https : / / example . com / acme / acct / evOfKhNU60wg" , "nonce" : "Q_s3MWoqT05TrdkM2MTDcw" , "url " : "https : / / boulder . example . com / acme / authz / asdf / 0 " } ) , "payload" : base64url ( { "tkauth" : "DGyRe jmCefe7v4N . . . vb29Hh j j LPSggwiE " } ) , " signature" : " 9cbg5 JOlGf 5YL j j z . . . SpkUfcdPai 9uVYYQ" }WP < - Checking ACME server has validated the Challenge( Optional ) - >< - CSR request - >< - Downloading Certi ficates - >A.3 External Account Binding[RFC8555] section 7.3.4 mentions the possibility of the server to bind the account created by the ACME server to another account. The usage I see for it is to enable a system to bind the ACME account (that is not related to an identity of the user) to another account already defined elsewhere - in most cases, this account can be assumed related to the identity of the ACME Client.When an ACME Client creates a new account it creates an asymmetric key pair, which is known as the key account. That key will be used by the ACME Client to authenticate all its messages using JWS. The JWS contains a signature as well as in indication of which key is being used to check the JWS signature. When the account key is not known by the ACME server, the public part of the key is provided using a JWK - For new Account requests, and for revokeCert requests. For other request that account key is referred by a kid.(see [RFC8555] section 6.2).The ACME server identifies the user account with an account URL but must be able to retrieve the account URL from the account key (see [RFC8555] section 7.3.1).The binding between the ACME account on the ACME server and the non- ACME account is performed via a MAC key. The MAC key represents the non ACME account, the ACME Client proves ownership of the MAC key with the external account binding by signing the account key with the MAC key. It also proves the ownership of the account key by signing with the account key the account key and the external account binding object.The externalAccountBinding"externalAccountBinding" : {"protected" : base64url ( {"alg" : "HS256" ," kid" : / * key identi fier from GA * / ,"url" : "https : / / example . com / acme / new-account"} ) ,"payload" : base64url ( / * same as in " j wk" above * / ) , " signature" : / * MAC using MAC key from CA * / }The new-account requestPOST / acme / new-account HTTP / 1.1Host: example.comContent-Type : application / j ose+j son{"protected": base64url ( {"alg" : "ES256" ,"jwk": / * account key * / ,"nonce" : "K60BWPrMQG9SDxBDS_xtSw" ,"url" : "https : / / example . com / acme / new-account"}) ,"payload": base64url ( {"contact" : ["mailto : cert-admin@example . org" ,"mailto : admin@example . org"] ,"termsOf ServiceAgreed" : true,"externalAccountBinding": {"protected": base64url ( {"alg" : "HS256" ,"kid": / * key identifier from CA * / ,"url" : "https : / / example . com / acme / new-account" }) , "payload": base64url( / * same as in "jwk" above * / ) , "signature": / * MAC using MAC key from CA * / }}) ,"signature": "5TWiqIYQfIDfALQv. . . x9C2mg8 JGPxl5bI 4 " }The ACME server knows the MAC key and kid as it checks the external account binding.ACME Client ACME server |- account key - account key (public) |( private / public ) - account URL |- MAC key, kid - MAC key, kid < - F2. H — > MAC key <-> policies DB new-account request externalAccountBindingA.3.1 Application to non ACME accountIn this section, the ACME accounts needs to be bound to a specific account to provide some sort of access control. ACME has only been designed for Web PKI certificates, which means that binding to a given non-ACME account can be seen as an authorization access to generate the certificate as the ACME server would otherwise do it. The 3GPP use case differs a bit from that situation as in addition to the ’’simple authorization”, an account is associated to a specific policy that will impact how the ACME server will issue certificates. Typically, when an account represents an MNO, the account will be associated to a policythat indicates how to issue the certificates. This could includes some specific values associated to the attributes and SAN of the certificate. These are expected to be provisioned to the CA via an out of band mechanism.Suppose we do have a non-ACME account of a MNO that is represented by a Ed25519 public key. Many NFs issue certificate bound to that account. Here are the foreseen steps:• 1.The CA issue a MAC key to the ACME Clients and the ACME server. A reasonable scenario may consist in out-of band provisioning. The ACME Client could be provisioned with the OTP. Provisioning of the ACME server is performed similarly, but we can assume that the ACME server and the non-ACME accounts• 2.The ACME Client generates the JWS to binds the account key and the MAC key.• 3.The ACME server binds the request to the no- ACME account and can apply a specific policy.How such binding can be used ? for 3GPP. Binding to an external account is useful to implement some access control or binding the account top a given policy, configuration. However, this requires the ACME server to implement such policy.The external account binding introduces an additional indirection, this means that the CA MUST implement some proxies that are able to implement the no- ACME account to ( MAC key, key id) and the (MAC key, key id) to non ACME account.The use of a MAC key provides the ability of the ACME Client, the ACME server and the non-ACME account to impersonate the MNO (or the NF if we consider that the MNO considers more than a single account). This provides more privileges than necessary as the ACME Client only needs to generate a signature, the ACME server and the non-ACME database only needs to verify the signature. The usage of a asymmetric key pair would enable the limitation of the roles by only distributing the public key to the ACME Server and the non ACME account and limiting the distribution of the private key to the ACME Client.A.4 Using the DNS CAA RRset[RFC8657] leverages the Certification Authority Authorization (CAA) DNS [RFC8659] to provides some CA-specific policies. This field is used in ACME to specify a specific CA and bind that specific CA a specific account or a specific validation method.In the following example the owner of the domain name example.com indicates that the CA example.net is expected to use the account to issue with one method and another account to issue with another method.The following shows a zone file fragment in which one account can be used to issue with the "dns- 01" method and one account can be used to issue with the "http- 01" method .example . com. IN CAA 0 issue "example . net ; \ accounturi=https : / / example . net / account / 1234 ; \ validationmethods=dns- 01 " example . com. IN CAA 0 issue "example . net ; \ accounturi=https : / / example . net / account / 2345 ; \ validationmethods=http- 01 "The following shows a zone file fragment in which only ACME method "dns- 01" or a CA-speci fic method "ca- foo" can be used . example . com. IN CAA 0 issue "example . net ; \ validationmethods=dns- 01 , ca- foo"It is worth noting that the parameters defined and considered as CA specific, thus do not require IANA registration.As per [ RFC8659 ] , the parameter namespace for the CAA "issue" and "issuewild" Properties has CA- defined semantics , and the identi fiers within that namespace may be freely and arbitrarily assigned by a CA. This document merely speci fies recommended semantics for parameters of the names "accounturi" and "validationmethods" , which CAs may choose to adopt .How such binding can be used ? for 3GPP The main advantage of specifying some CA- specific policies in the DNS is to make the implementation of these policies standard and prevent or at least limit each deployment to have its own specificities.On of its drawback though is that it may also require to makes ’’almost public” the policies and to repeat the policies for each domain name.For that matter, I suspect that binding a policy to an account is more appropriated. In a typical scenario, we could specify the ’’account” which contains the account, or as specified in ACME the ’’accounturi” we could also specify a profile that is set to ”3gpp” for example.Appendix B Exchanges for the Multi MNO with Token AuthorityThis section provides an illustrative example on how ACME can be implemented to issue 3GPP certificates for SBA via a Token Authority [RFC9447, RFC9448]B.l Creation of the CA accountThe creation of the CA account and managing the binding between ACME account and the CA account is optional when the Token Authority is involved. In fact, the advantage of using a Token Authority is precisely to avoid the creation of CA accounts.In the lustrated use case, we however take advantage of the external account binding for at least two reasons. The first one is to be able to associate parameters at the MNO level. In this case, it mostly consists in being able to define a Token Authority that is trusted by the CA and that will be accepted by the ACME Client. The necessity to identify the Token Authority and associate it to the ACME Client is only valid when a given CA is handling multiple MNO or multiple Token Authorities. This is likely not needed if the CA is dedicated to an MNO for example. The second reason for us to consider an external account binding is to control the certificate issuance with a OTP-like mechanism that is currently inused today. The OTP ensures that certificate issuance is performed when the administrator is expecting that to happen. This is a bootstrapping aspect that might contradict the initial objective of being automated, but such a control is a common practice, and we ensure the creation of ACME account is associated to an authorization implemented with the use of a PSK.In our case, the CA account can be represented as follows:{ "MNO" : "The best MNO" ,"Authority Token" :{ "URL" :"Token Signing Key" : b ' QWrfguhJI j ; . . . ' , } ,"Authori zed PSK" : [ { ' psk_l ' : <psk_value> ,Wf ' psk_n' : <psk_value> } ]Of course there is also the possibility to create an account associated to each ACME account, in which case, of parameters associated to that account could be provisioned. In such case, we would find out in a 1 CA account: 1 ACME account binding as detailed in Section C. We believe the main advantage of using a Token Authority is to be able to delegate the validation of the token and preserve the CA operations unchanged, so this is not a configuration we will consider in this illustrative example.On the other hand, the Token Authority is expected to be configured with the necessary attributes. More specifically, we expect the MNO to associate each X509 configuration to a given PSK. The CA is not aware of such binding. The MNO decides which PSK is associated to which configuration. This binding is entirely in the end of the MNO as it is expected to provision sits ACME Client. The CA will rely on the Token Authority to validate the identifiers and attributes as well their association to the PSK. It is then the responsibility of the CA to ensure that the ACME account is clearly associated to that PSK before issuing the certificate. In other words, the following trust model is considered:1. 1.The MNO creates a CA account to the CA. That account will be used for all VNF.2. 2.The MNO requests the CA creates PSK that will be used for each VNF.3. 3.The MNO provision the Token Authority with the PSK and the associated X509 attributes / identifiers4. 4.The MNO for each PSK provision the appropriated ACME Client5. 5.The ACME Client creates a ACME account using the PSK for external account binding. The CA determine the ACME Client from the CA account that the ACME Client is associated toa specific Token Authority. The ACME account (private key) is bound to that PSK.6. 6.The ACME validates the challenge with the Token Authority. The Token Authority returns a token that assesses that a specific PSK is bound to some X509 identifiers and attributes. At that point we can even assume that Token Authority has not authenticate the ACME Client and has not checked the ACME Client effectively owns the private key associated to eth ACME account nor the PSK.7. 7.The ACME server reads the token, ensures the account is associated to the PSK and the ACME account key.8. 8.The ACME server issues the certificate.B.2 Creation of the ACME accountThe creation of the ACME account is unmodified and reuses the standard exchanges as defined in [RFC8555], In this example we are using an external account binding so the CA can bound the request to an external CA account. In this case the main use reason fro providing an account binding is to ensure the ACME Client is authorized to create the account and potentially to infer which Token Authority the Token Authority Token will be requested to. In such case the external account binding may simply bound to a CA account that contains only contain information global to the MNO as opposed to very specific information associated to the certificate issuance that is expected to be validated by the Token Authority.MNO / ACME Client CAPOST / acme / new-account HTTP / 1.1Host: ca.example.comContent-Type : application / j ose+j son{"protected": base64url ( {"alg" : "ES256" ,"jwk": / * account key * / ,"nonce" : "K60BWPrMQG9SDxBDS_xtSw" ,"url" : "https : / / ca . example . com / acme / new-account"}) ,"payload": base64url ( {"termsOf ServiceAgreed" : true,"externalAccountBinding" : {"protected": base64url ( {"alg" : "HS256" ,"kid": / * key identifier from CA * / ,"url" : "https : / / example . com / acme / new-account"}) ,"payload": base64url ( / * same as in "jwk" above * / ) , "signature": / * MAC using MAC key from CA * / }}) ,"signature": "5TWiqIYQfIDfALQv. . . x9C2mg8 JGPxl5bI 4 "}HTTP / 1 . 1 201 Created Content-Type : application / j son Replay-Nonce : D8 s4D2mLs 8Vn-goWuPQeKA Link : <https : / / example . com / acme / directory>; rel=" index" Location : https : / / example . com / acme / acct / evOfKhNU60wg { " status" : "valid" , "orders " :"https : / / example . com / acme / acct / evOfKhNU60wg / orders " }B.3 Pre-authorizationsWhen the Token Authority is used, there is no need to configure some pre-authorizations as attributes or identifiers the ACME Client cannot prove control over are in fact validated by the Token Authority. As a result, we do not expect to specify anything for the preauthorizations.Note that pre-authorization may be used as in the standard ACME [RFC8555] and we do not prevent them to be used.B.4 Applying for Certificate IssuanceThe application for certificate issuance and issuance of the certificate follows the standard ACME [RFC8555] and the Token Authority extension [RFC9447, RFC9448], More specifically, the following steps are expected to be the following ones:1. 1.The ACME Client sends a new-order request is sent by the ACME Client in which all necessary identifiers are indicated.2. 2.The CA creates the order and returns the URL associated to that order. This URL contains some authorization URLs as well as the finalize URL. When all authorizations are granted the order status becomes set to ’valid’, the finalize URL is then used to issue the CSR.3. 3.The ACME Client consults each of the authorizations URLs. Each URL contains a list of challenges represented by an URL. In our case the challenge is of type TokenAuthority ”tkauth-01” as defined in [RFC9448],4. 4.The ACME Client select one of the proposed challenge (one per authorization) and indicate the challenge has been performed to the challenge URL.The CA validates the challenge and indicates the authorization as ’valid’ .6. 6.The CA indicates the order as ’ready’ when all authorizations are completed.7. 7.The ACME Client connects to the authorizations or order to check all authorizations have their status set to ’valid’ and the order has its status set to ’ready’.8. 8.The ACME Client can proceed to sending a certificate request CSR.In our case, a new subtype needs to define the type of the Token to be used. This is to define that the token and the validation is expected for the issuance of a certificate. As the identifiers and attributes are not 3 GPP specific, but quite generic to the certificate, we define in this example the identifier as ’cert’. The value associated to that identifier could be a binary format (for example using ASN1), but in this example we choose to select and define the attributes and identifiers involved so that the value of identifier ’cert’ can be expressed as a JSON object.It is worth noting that the type ”dns” is an attribute of ’cert’ and as such is different than the identifier of type ”dns” defined by [RFC8555],MNO / ACME Client CAPOST / acme / new-order HTTP / 1.1Host: example.comContent-Type : application / j ose+j son{ "protected": base64url ( { "alg" : "ES256" , "kid" : "https : / / example . com / acme / acct / evOfKhNU60wg" , "nonce" : "5XJlL31EkMG7tR6pA00clA" , "uri" : "https : / / example . com / acme / new-order " }) , "payload": base64url ( { "identifiers" : [ { "type" : "cert", "value" : {{ "type": "dns", "value": "www.example.or " }, { "type": "dns", "value": "example.org" }{ "type": "dns", "value": "5gc.mnc081.mcc240.gppnetwork.org" }, { "type": "sub j ect_country" , "value": "US"}, { "type": "sub j ect_organization" , "value": "5gc.mnc400.mcc311.3gppnetwork.org" },{ "type" : "uri", "value": "urn : uuid : f 8 ld4f ae-7dec-lld0-a765-00a0c91e6bf 6" },{ "type" : "uri",T "value": "https : / / smf-amf- notification.clusterl.net2. amf .5gc . mnc400. mcc311.3 ppnetwork . or : 7070 " } }] , "notBefore" : "2021-01-01T00:00:00Z", "notAfter" : "2021-01-08T00:00:00Z" }) , "signature": "H6ZXtGj TZyUnPeKn . . . wEA4TklBdh3e454g"}HTTP / 1.1 201 Created Content-Type: application / j son Replay-Nonce : MYAuvOpaoIiywTezizk5vw Location : https : / / example . com / acme / order / 1234 { "status": "pending", "expires" : "2022-01-08T00:00:00Z", "notBefore" : "2022-01-01T00:00:00Z", "notAfter" : "2022-01-08T00:00:00Z", "identifiers" : [ { "type" : "cert", "value" : {{ "type": "dns", "value": "www.example.org" }, { "type": "dns", "value": "example.org" } { "type": "dns", "value": "5gc.mnc081.mcc240.gppnetwork.org" }, { "type": "sub j ect_country" , "value": "US"}, { "type": "sub j ect_organization" , "value": "5gc.mnc400.mcc311.3gppnetwork.org" }, { "type" : "uri", "value": "urn : uuid : f 8 ld4f ae-7dec-lld0-a765-00a0c91e6bf 6" }, { "type" : "uri", "value": "https : / / smf-amf- notification.clusterl. net 2. amf .5gc . mnc400. mcc311.3gppnetwork . org : 7070 " } }] , "authorizations": ["https : / / example . com / acme / authz / 1234" ] , "finalize" : "https : / / example . com / acme / order / 1234 / finalize" }B.5 Identifier AuthorizationMNO / ACME Client CAPOST / acme / authz / 1234 HTTP / 1.1Host: example.comContent-Type : application / j ose+j son{"protected": base64url ( {"alg" : "ES256" ,"kid": " https: / / example.com / acme / acct / evOfKhNU60wg", "nonce" : "uQpS j !Rb4vQVC j VYAyyUWg" ,"uri" : "https : / / example . com / acme / authz / 1234" }) , "payload" : " " , "signature": "nuSDISbWG8mMgE7H . . . QyVUL68yzf3Zawps" }HTTP / 1.1 200 OKContent-Type: application / j sonLink : <https : / / example . com / acme / some-directory>; rel=" index"{"status": "pending","expires" : "2022-01-08T00:00:00Z","identifier" : { "type" : "cert" ,"value" : {{ "type": "dns", "value": "www.exam le.org" },{ "type": "dns", "value": "example.org" }{ "type": "dns", "value": "5gc.mnc081.mcc240.gppnetwork.org" },{ "type": "sub j ect_country" , "value": "US"},{ "type": "sub j ect_organization" ,"value": "5gc.mnc400.mcc311.3gppnetwork.org" },{ "type" : "uri","value": "urn : uuid : f 8 ld4f ae-7dec-lld0-a765-00a0c91e6bf 6" },{ "type" : "uri","value": "https : / / smf-amf- notification.clusterl.net2. amf .5gc . mnc400. mcc311.3gppnetwork . org : 7070 " } } },"challenges " : [{"type": "tkauth-01","tkauth-type" : "ate","token-authority" : "https : / / authority . example . org" , "uri " : "https : / / example . com / acme / chai l / prV_B7yEyA4 " , "token" : "IlirfxKKXAsHtmzK29Pj 8A"}]}B.6 Challenge CompletionThe challenge indicated by the CA contains the URL to reach the Authority Token. The token is an object that indicates the Token Authority authorizes the CA to issue a certificate to the ACME Client with the requested identifiers.The token structure is similar to the one detailed in [RFC9448], The payload is signed by the Token Authority and contains:• iss: the Token Authority• exp: expiration date of the Token• jti: an identifier of the transaction• ate: which contains ’tktype’ the type of the token, ’tkvalue’ the various values, ’a’ an indication whether the ACME Client is s CA, and ’fingerprint’ that is the hash of the ACME account key.In our case, none of the information validated by the Token Authority is private and need to be protected against anyone. This means that In our case, there is a need to bind the Token to the PSK in order to identify the transaction. This is especially the case as the Token Authority is expected to be configured with the PSK and not the ACME key account. As result we add the psk id attribute to the TOKEN defined in [RFC9448], Note thatfingerprint is not validated by the Token Authority in [RFC9448], As far as I understand the information provided by [RFC9448] simply needed to be valid and not necessarily bound to a ACME Client. Our case is different, we want to associate the TOKEN to and ACME account, AND to a CA account AND to a specific transaction. The PSK alone would be sufficient if the ACME server keeps the PSK in its context. So in this example we prefer to consider:The PSK is used to authenticate the ACME Client and the Token Authority. Such authentication is optional and the ACME Client MUST use the credential that will be used by the Token Authority to provide the authorization.The Token Authority asses the ownership of the private key associated to the ACME account as well as the PSK.TOKEN =\{"protected": base64url ( {"typ" : " JWT" ,"alg" : "ES256" ,"x5u" : "https : / / authority. example . org / cert"}) ,"payload": base64url ( {"iss ": "https : / / authority . example . org" ,"exp" : 1640995200," jti" : "id6098364921 " ,"ate" : {"tktype" : "cert" ,"tkvalue" : {{ "type": "dns", "value": "www.example.org" },{ "type": "dns", "value": "example.org" }{ "type": "dns", "value": "5gc.mnc081.mcc240.gppnetwork.org" },{ "type": "sub j ect_country" , "value": "US"},{ "type": "sub j ect_organization" ,"value": "5gc.mnc400.mcc311.3gppnetwork.org" },{ "type" : "uri","value": "urn : uuid : f 8 ld4f ae-7dec-lld0-a765-00a0c91e6bf 6" },{ "type" : "uri","value": "https : / / smf-amf- notification.clusterl.net2. amf .5gc . mnc400. mcc311.3 ppnetwork . or : 7070 " } },"ca" : false,"fingerprint" : "SHA256 56 : 3E : CF : AE : 83 : CA: 4D : 15 : BO : 29 : FF : IB : 71 :D3 : BA: B9 : 19 : 81 : F8 : 50 : 9B : DF : 4A: D4 : 39 : 72 : E2 : Bl : FO : B9 : 38 : E3 " , "psk_id: "SHA256 48 : 3E : BF : DE : 45 : DA: 4F : 89 : AO : 19 : 5F : 2A: 23 :A3 : EF : B9 : 19 : 81 : F8 : 50 : 9B : DF : 4A: D4 : 39 : 56 : E2 : Al : DO : B9 : 38 : 32 " } }) ,"signature": " 9cbg5 JOlGf 5YL j j z . . . SpkUfcdPai9uVYYQ"}Taking the same logic as defined in [RFC9448], the ACME Client sends to the Token Authority. In the example, the policy to be applied by the Token Authority is indicated by the URL 7at / account / :id / token’ which is known by the ACME Client. The ACME Client is also authenticated by the Token Authority.The expected TOKEN is retrieved from the Token Authority as follows:MNO / ACME Client Token AuthorityHost: authority.example.orgContent-Type: application / j son{"tktype" : "cert" ,"tkvalue" : " {{ "type": "dns", "value": "www.example.org" },{ "type": "dns", "value": "example.org" }{ "type": "dns", "value": "5gc.mnc081.mcc240.gppnetwork.org" },{ "type": "sub j ect_country" , "value": "US"},{ "type": "sub j ect_organization" ,"value": "5gc.mnc400.mcc311.3gppnetwork.org" },{ "type" : "uri","value": "urn : uuid : f 8 ld4f ae-7dec-lld0-a765-00a0c91e6bf 6" },{ "type" : "uri","value": "https : / / smf-amf- notification.clusterl. net 2. amf .5gc . mnc400. mcc311.3gppnetwork . org : 7070 " }}","ca" : false,"fingerprint" : "SHA256 56 : 3E : CF : E : 83 : CA: 4D : 15 : BO : 29 : FF : IB : 71 : D3: BA: B9 : 19 : 81 : F8 : 50 : 9B : DF : 4A: D4 : 39 : 72 : E2 : Bl : FO : B9 : 38 : E3 ""psk_id: "SHA256 48 : 3E : BF : DE : 45 : DA: 4F : 89 : AO : 19 : 5F : 2A: 23 :A3 : EF : B9 : 19 : 81 : F8 : 50 : 9B : DF : 4A: D4 : 39 : 56 : E2 : Al : DO : B9 : 38 : 32 " }}HTTP / 1.1 200 OKContent-Type: application / j son {"token": TOKEN }Once the token is received, the ACME Client post it to the challenge URL to indicate the challenge is completed. The CA checks the signature, validates the identifiers and its association to the ACME account.As mentioned in Section B l, authneti cation of the ACME Client is not necessarily being performed by the Token Authority. Instead the Token Authority indicates in its token, the ’psk id’ that is the identity of the ACME Client for which the identifiers and attributes can be issued. The ’fingerprint’ is in my opinion not necessary and only here as an indication or hint of which identity is being used by the ACME Client. The ACME server will have to check these two identifiers corresponds to the ACME Client.That said, we do recommend that the ACME Client uses the PSK to authenticates itslef to the Token Authority. This can be achived via TLS in a PSK mode or using a JWS. The main purpose is to restricte the access to the information to legitimate ACME Clients. The addition of a proof of ownership of the ACME account key would enable the Token Authority to assert to the ACME server. The ACME Client effectively posses these two identifiers. As such the latest proof of possesion of the ACME account key is left OPTIONAL.The ACME Client provides the TOKEN to the CA as follows:MNO / ACME Client CAHost: boulder.example.comContent-Type : application / j ose+j son"protected": base64url ( {"alg" : "ES256" ,"kid" : "https : / / example . com / acme / acct / evOfKhNU60wg" ,"nonce" : "Q_s3MWoqT05TrdkM2MTDcw" ,"url " : "https : / / boulder . example . com / acme / authz / asdf / 0 " }) ,"payload": base64url ( {"tkauth": "DGyRe jmCef e7v4N . . . vb29Hh j j LPSggwiE " }) ,"signature": " 9cbg5 JOlGf 5YL j j z . . . SpkUfcdPai9uVYYQ"B.7 Certificate IssuanceOnce the challenge is verified by the CA and the order is set as ’ready’, the ACME Client post CSR as follows.From now, the processing does not differ from the standard ACME processing:1. 1.The ACME Client submit a CSR to the finalize URL.2. 2.The CA responds by adding a certificate URL.3. 3.The ACME Client checks until the order status is set to ’valid’ and download the certificate at the certificate URL.The only difference is that the CA accoutn PSK and the ACME account are removed once the ACME accoutn is removed as to implement the One Time Password policy.MNO / ACME Client CAPOST / acme / order / T01ocE8rfgo / finalize HTTP / 1.1Host: example.comContent-Type : application / j ose+j son{"protected": base64url ( {"alg" : "ES256" ,"kid" : "https : / / example . com / acme / acct / evOfKhNU60wg" ,"nonce" : "MSF2 j 2nawWHPxxkE3Z JtKQ" ,"url" : "https : / / example . com / acme / order / T01ocE8rf o / finalize" }) , "payload": base64url ({"csr": "MI IBPTCBxAIBADBFMQ . . . FS6aKdZeGsysoCo4H9P" , }) , "signature": "uOrUf IIk5RyQ . . . nw62Aylcl6AB" }HTTP / 1.1 200 OKContent-Type: application / j sonReplay-Nonce : CGf 81JWBsq8QyIgPCi9Q9X Link : <https : / / example . com / acme / directory>; rel=" index" Location : https : / / example . com / acme / order / T01ocE8rfgo { "status": "valid", "expires" : "2016-01-20T14:09:07.99Z", "notBefore" : "2016-01-01T00:00:00Z", "notAfter" : "2016-01-08T00:00:00Z", "identifiers": [ "type" : "cert" , "value" : TOKEN ] , "authorizations": ["https: / / sti-ca.com / acme / authz / 1234"] ,"finalize" : "https : / / example . com / acme / order / T01ocE8rf go / finalize" , "certificate" : "https : / / example . com / acme / cert / mAt3xBGaobw" , "x5u" : "https : / / example . com / cert- repo / gi JI53km23. pern" }Host: example.comContent-Type : application / j ose+j sonAccept : application / pem-certificate-chain {"protected": base64url ( {"alg" : "ES256" ,"kid" : "https : / / example . com / acme / acct / evOfKhNU60wg" ,"nonce" : "uQpS j !Rb4vQVC j VYAyyUWg" ,"url" : "https : / / example . com / acme / cert / mAt3xBGaobw" }) , "payload" : " " ,"signature": "nuSDISbWG8mMgE7H . . . QyVUL68yzf3Zawps"}HTTP / 1.1 200 OKContent-Type : application / pem-certificate-chainLink : <https : / / example . com / acme / directory>; rel=" index"- BEGIN CERTIFICATE -[End-entity certificate contents]- END CERTIFICATE -- BEGIN CERTIFICATE -[Issuer certificate contents]- END CERTIFICATE -- BEGIN CERTIFICATE -[Other certificate contents]- END CERTIFICATE -Appendix C Exchange for the Pre AuthorizedArchitecture for SBAThis section provides an illustrative example on how ACME can be implemented to issue 3GPP certificates for SB A. This section does not consider the Token Authentication for the reasons exposed in Section 1 and Section LABEL:sec:acme-mno. In short the Token Authentication is perceived as the MNO validating the certificates requests on behalf of the CA. Such option may of course favored by CA, as their responsibility and operations get simplified but at the expense of the MNO. On the other end, such model has been deployed by ATT to validate the phone numbers.C.l Creation of the CA accountThe first phase consists in the MNO provisioning / configuring the CA with the information associated to the ACME Clients. At the very least this includes parameter the ACME Client will request to be mentioned in its certificate and whose ownership (or control) by the ACME Client cannot be verified by the CA. This can also be extended by parameters that can be checked by the CA, that is parameters for which a challenge exists.As mentioned in Section LABEL: sec mewauthz, the information provided by the MNO to the CA looks as follows:{ "Organi zation" : ' 5gc . mnc400 . mcc311 . 3gppnetwork . org' ,"Country" : ' US ' ," FQDN" : [ ' amfl . clusterl . net2 . amf . 5gc . mnc400 . mcc311 . 3gppnetwork . org' ] , "URI" : [ ' urn : uuid : f 8 ld4 f ae- 7dec- l ld0-a765- 00a0c91e6bf 6 ' ] , "CN" : "amfl . clusterl . net2 . amf""NF_TYPE" : "AMF" }The example above is taken from [RFC9310], While Organization in this example has the format of an FQDN, this is not mandatory. The 3GPP specification mentions a CN, that does not appear in the example. We arbitrary set it to ’amfl.clusterl.net2.amf which does not corresponds to a FQDN while in most case - and at least for ACME cases, this is a FQDN that is part of the SAN. As it is not an FQDN, the ownership of the CN cannot be verified by the CA. Similar URIs of type URN cannot either be checked by the CA. URIs using an ’https’ or ’http’ scheme could be verified - at least in theory. However, this would require to have an unsecured http interface being reachable by the CA.Overall that we provision one parameter or a serie of parameters is equivalent, and there is no strong advantage in providing only a subset of the parameters. As a result, we assume for simplicity in this example that d / . / . parameters are provisioned by the MNO to the CA. The resulting account is designated as CA account.In return, the CA provides the MNO a OTP or PSK that the ACME Client will later use to bind the ACME account to the CA account.The creation of the CA account is not an ACME exchange and is performed via a proprietary API supported by the CA and the MNO.MNO CACreate CA account :{ "Organi zation" : ' 5gc . mnc . . . ' , "Country" : ' US ' , " FQDN" : [ ' amfl . clust . . . ' ] , "URI" : [ ' urn : uuid : f 8 . . . ' ] , "CN" : ' amf 1 . clusterl . . . ' "NF_TYPE" : "AMF" }Creation of the CA accountCreation of the CA account bindingPSKCA account binding PSKAs mentioned in Section LABEL: sec: non-acme-account the Directory object looks as follows with the mention of the ’’extemalAccountRequired” to indicate ACME account is bound to a external CA account.As we place ourselves in the case where authorizations are all preprovisioned by the CA, the newAuthz resource is not used. In addition, revokeCert, keyChange are probably introducing features that are not expected to be used and as such are not expected to be provided. These resources have been commented.{"newNonce" : "https : / / example . com / acme / new-nonce" ,"newAccount" : "https : / / example . com / acme / new-account" ,"newOrder" : "https : / / example . com / acme / new-order " ,## "newAuthz": "https: / / example.com / acme / new-authz",## "revokeCert": "https: / / example.com / acme / revoke-cert",## "keyChange": "https: / / example.com / acme / key-change","meta" : {"termsOf Service" : "https : / / example . com / acme / terms / 3gpp-profile" , "caaldentities " : [ "ca . example . com" ] ,"extemalAccountRequired" : true,}}C.2 Creation of the ACME accountThe MNO configures the ACME Client with the CA account Binding PSK, the CA URL as well as the necessary information so the CSR can be appropriately formatted when a request to issue the certificate is generated.As described in Section LABEL: sec mewaccount the creation of the ACME account is performed by POSTing a request to the / acme / new-account resource and providing the external account binding with a proof of possession of the external account binding.The exchange is as follows:MNO / ACME Client CAPOST / acme / new-account HTTP / 1.1Host: ca.example.comContent-Type : application / j ose+j son{"protected": base64url ( {"alg" : "ES256" ,"jwk": / * account key * / ,"nonce" : "K60BWPrMQG9SDxBDS_xtSw" ,"url" : "https : / / ca . example . com / acme / new-account" }) , "payload": base64url ({"termsOf ServiceAgreed" : true,"externalAccountBinding" : {"protected" : base64url ( {"alg" : "HS256" ," kid" : / * key identi fier from CA * / ,"url" : "https : / / example . com / acme / new-account"} ) ,"payload" : base64url ( / * same as in " j wk" above * / ) , " signature" : / * MAC using MAC key from CA * / }} ) ," signature" : " 5TWiqIYQfIDfALQv . . . x9C2mg8 JGPxl5bI 4 "}HTTP / 1 . 1 201 CreatedContent-Type : application / j son Replay-Nonce : D8 s4D2mLs 8Vn-goWuPQeKA Link : <https : / / example . com / acme / directory>; rel=" index" Location : https : / / example . com / acme / acct / evOfKhNU60wg{" status" : "valid" ,"orders " :"https : / / example . com / acme / acct / evOfKhNU60wg / orders "}C.3 Pre-authorizationsUpon Creating the ACME account the CA provisions the newAuthz resource to grant authorization to all identifiers and resources that will be requested by the ACME Client in the CSR or the Order.The ’kid’ of the new-account request from the ACME Client, identifies the CA account PSK and the ACME Client has proven its possession of that PSK. As a result, the CA has access to the authorized identities and attributes. In this case, authorization has been provided by the MNO as opposed to the CA in the general ACME case. The CA is then able to complete the pre-authorized in the authz resources. As we mentioned earlier, in this example, we do not consider that some challenges will be completed by the ACME Client. However as explained in Section LABEL: sec: authz a combination of challenged identities or attributes may be consider, in which case the newAuthz will need to be accessed by the ACME Client.The following authorization are thus configured. Note that this requires. The creation of new identifiers type such as ”subject_country”, ”subject_organization”, ’’nftype” as well as ”uri”. The traditional ACME mostly cares of FQDN or one specific resource that is an identifier.. In our case, we extend this to attributes. It is so important to ensure that a specific attribute will be used in a specific place. Typically ACME defined identifiers such as IP addresses and FQDNs, These identifiers could be in the CN or the SAN. There is a limited number of possibilities as indicating it in the SAN is mandatory. The CN does not play a major role, and a balance between the CSR indicated by the ACME Client and the CA determines how the CN is populated. In our case, the nftype MUST be in a NF TYPE [RFC9310] attribute. Similarly attributes of the distinguished name MUST be at a specific location.Note also that each authorization is seen as an URL, in other words, these authorizations are not contained in the same page. https : / / example . com / acme / authz / PAniVnsZcis{" status" : "valid" ,"expires" : "2024- 03- 01T14 : 09 : 07 . 99Z" ,"identifier" : {"type" : "dns","value" : "5gc . mnc081. mcc240. gppnetwork . org" }, "challenges " : [ ] ,} https : / / example . com / acme / authz / aAIOHJfD{"status": "valid","expires" : "2024-03-01T14:09:07.99Z","identifier" : {"type": "sub j ect_country" ,"value" : "US"},"challenges " : [ ] , } https : / / example . com / acme / authz / opifmKM{"status": "valid","expires" : "2024-03-01T14:09:07.99Z","identifier" : {"type" : "sub j ect_organization" ,"value" : "5gc . mnc400. mcc311.3 gppnetwork .org" },"challenges " : [ ] , } https : / / example . com / acme / authz / MI JPi j sd{"status": "valid","expires" : "2024-03-01T14:09:07.99Z","identifier" : {"type" : "uri","value" : "urn : uuid :f81d4fae-7dec-lld0-a765-00a0c91e6bf6" }, "challenges " : [ ] ,} https : / / example . com / acme / authz / Ta j hiSpn{"status": "valid","expires" : "2024-03-01T14:09:07.99Z","identifier" : {"type" : "uri","value": "https : / / smf- l.clusterl.net2. amf .5gc . mnc400. mcc311.3 gppnetwork . org : 7070 " }, "challenges " : [ ] ,}https : / / example . com / acme / authz / oi j tmvbr{ " status" : "valid" , "expires" : "2024- 03- 01T14 : 09 : 07 . 99Z" , "identi fier" : { "type" : "uri" , "value" : "https : / / smf-amf- noti fication . clusterl . net2 . amf . 5gc . mnc400 . mcc311 . 3gppnetwork . org : 7070 " } , "challenges " : [ ] ,}Another variant would be that the ACME Client requests an pre-authorization.On boulder, - as far as I understand - the names from the CSR are checked against valid authorizations https: / / github.eom / letsencrypt / boulder / blob / main / ra / ra.go#L745.Note that pre authorization is currenlty not implemented on Boulder as per https: / / github.com / letsencrypt / boulder / blob / ce5632b480f0b5c6cl25256ef9f8b0c4284548d3 / docs / DESIGN.md?plain=l#L102 and http s : / / ithub . com / 1 etsencry pt / b oul der / i ssues / 7050C.4 Applying for Certificate IssuanceTraditional ACME for certificate Issuance includes challenges and is performed as follows:1. 1.The ACME Client sends a new-order request is sent by the ACME Client in which all necessary identifiers are indicated.2. 2.The CA creates the order and returns the URL associated to that order. This URL contains some authorization URLs as well as the finalize URL. When all authorizations are granted the order status becomes set to ’valid’, the finalize URL is then used to issue the CSR.3. 3.The ACME Client consults each of the authorizations URLs. Each URL contains a list of challenges represented by an URL.4. 4.The ACME Client select one of the proposed challenge (one per authorization) and indicate the challenge has been performed to the challenge URL.5. 5.The CA validates the challenge and indicates the authorization as ’valid’ .The CA indicates the order as ’ready’ when all authorizations are completed.7. 7.The ACME Client connects to the authorizations or order to check all authorizations have their status set to ’valid’ and the order has its status set to ’ready’.8. 8.The ACME Client can proceed to sending a certificate request CSR.In our case, with all pre-authorizations being set, the application for Certificate issuance is performed as follows:1. 1.The ACME Client sends a new-order request is sent by the ACME Client in which all necessary identifiers are indicated. This phase requires the definition of identifiers and attributes that can be indicated by the ACME Client.2. 2.The CA creates the order and returns the URL associated to that order. This URL contains some authorization URLs as well as the finalize URL. When all authorizations are granted the order status becomes set to ’valid’, the finalize URL is then used to issue the CSR. When present, these authorization URLs are indicated are ’valid’ and the order status is set to ’ready’, authz URL are optional as the ACME Client do not use them. Here the main difference is that we do not go through the authorization phase, and ACME Client needs to be prepared to do so and check the status of the order resource. By default, the ACME Client is expected that status and start validating the authorization. With our way of doing, the ACME Client needs to start by checking the status of the order. If that status is set to pending starts validating the authorizations. If that status is set to ’ready’ the ACME Client submits the CSR. The ACME Client also needs to handle empty or non existing authorization URLs.3. 3.The ACME Client can proceed to sending a certificate request CSR.MNO / ACME Client CAPOST / acme / new-order HTTP / 1 . 1Host : example . comContent-Type : application / j ose+j son{"protected" : base64url ( {"alg" : "ES256" ," kid" : "https : / / example . com / acme / acct / evOfKhNU60wg" ,"nonce" : " 5XJlL31EkMG7tR6pA00clA" ,"url" : "https : / / example . com / acme / new-order "} ) ,"payload" : base64url ( {"identi fiers" : [{ "type" : "dns" , "value" : "www . example . org" } ,{ "type": "dns", "value": "example.org" } { "type": "dns", "value": "5gc.mnc081.mcc240.gppnetwork.org" }, { "type": "sub j ect_country" , "value": "US"}, { "type": "sub j ect_organization" , "value": "5gc.mnc400.mcc311.3gppnetwork.org" }, { "type" : "uri", "value": "urn : uuid : f 8 ld4f ae-7dec-lld0-a765-00a0c91e6bf 6" }, { "type" : "uri", "value": "https : / / smf-amf- notification.clusterl.net2. amf .5gc . mnc400. mcc311.3gppnetwork . org : 7070 " } ] , "notBefore" : "2016-01-01T00:04:00+04:00", "notAfter" : "2016-01-08T00 : 04 : 00+04 : 00" }) , "signature": "H6ZXtGjTZyUnPeKn . . . wEA4TklBdh3e454g"}HTTP / 1.1 201 Created Replay-Nonce : MYAuv0paoIiywTezizk5vw Link : <https : / / example . com / acme / directory>; rel=" index" Location : https : / / example . com / acme / order / T01ocE8rfgo { "status": "valid", ### instead of "pending", "expires" : "2016-01-05T14:09:07.99Z", "notBefore" : "2016-01-01T00:00:00Z", "notAfter" : "2016-01-08T00:00:00Z", "identifiers": [ { "type": "dns", "value": "www.example.org" }, { "type": "dns", "value": "example.org" } { "type": "dns", "value": "5gc.mnc081.mcc240.gppnetwork.org" }, { "type": "sub j ect_country" , "value": "US"}, { "type": "sub j ect_organization" , "value": "5gc.mnc400.mcc311.3gppnetwork.org" }, { "type" : "uri", "value": "urn : uuid : f 8 ld4f ae-7dec-lld0-a765-00a0c91e6bf 6" }, { "type" : "uri", "value": "https : / / smf-amf- notification.clusterl.net2. amf .5gc . mnc400. mcc311.3gppnetwork . org : 7070 " } ] , "notBefore" : "2016-01-01T00:04:00+04:00", ] , "authorizations": [ ## "https : / / example . com / acme / authz / PAniVns Zeis " , ## "https : / / example . com / acme / authz / r4HqLzrSrpI " ] , "finalize" : "https : / / example . com / acme / order / T01ocE8rf go / finalize" }C.5 Identifier AuthorizationThis phase does not exist in this example.C.6 Challenge CompletionThis phase does not exist in this example.C.7 Certificate IssuanceFrom now, the processing does not differ from the standard ACME processing:1. 1.The ACME Client submit a CSR to the finalize URL.2. 2.The CA responds by adding a certificate URL.3. 3.The ACME Client checks until the order status is set to ’valid’ and download the certificate at the certificate URL.The only difference is that the CA accoutn PSK and the ACME account are removed once the ACME accoutn is removed as to implement the One Time Password policy.MNO / ACME Client CAPOST / acme / order / T01ocE8rfgo / finalize HTTP / 1.1Host: example.comContent-Type : application / j ose+j son{"protected": base64url ( {"alg" : "ES256" ,"kid" : "https : / / example . com / acme / acct / evOfKhNU60wg" ,"nonce" : "MSF2 j 2nawWHPxxkE3Z JtKQ" ,"url" : "https : / / example . com / acme / order / T01ocE8rf go / finalize" }) , "payload": base64url ({"csr": "MI IBPTCBxAIBADBFMQ . . . FS6aKdZeGsysoCo4H9P" , }) , "signature": "uOrUf IIk5RyQ . . . nw62Aylcl6AB" }HTTP / 1.1 200 OKReplay-Nonce : CGf 81JWBsq8QyIgPCi9Q9XLink : <https : / / example . com / acme / directory>; rel=" index"Location : https : / / example . com / acme / order / T01ocE8rfgo{"status": "valid","expires" : "2016-01-20T14:09:07.99Z","notBefore" : "2016-01-01T00:00:00Z","notAfter" : "2016-01-08T00:00:00Z","identifiers": [{ "type": "dns", "value": "www.example.org" },{ "type": "dns", "value": "example.org" }] ,"authorizations": ["https : / / example . com / acme / authz / PAniVns Zeis " ,"https : / / example . com / acme / authz / r4HqLzrSrpI " ] ,"finalize" : "https : / / example . com / acme / order / T01ocE8rf go / finalize" ,"certificate" : "https : / / example . com / acme / cert / mAt3xBGaobw"}Host: example.comContent-Type : application / j ose+j sonAccept : application / pem-certificate-chain {"protected": base64url ( {"alg" : "ES256" ,"kid" : "https : / / example . com / acme / acct / evOfKhNU60wg" ,"nonce" : "uQpS j !Rb4vQVC j VYAyyUWg" ,"url" : "https : / / example . com / acme / cert / mAt3xBGaobw" }) , "payload" : " " ,"signature": "nuSDISbWG8mMgE7H . . . QyVUL68yzf3Zawps"}HTTP / 1.1 200 OKContent-Type : application / pem-certificate-chainLink : <https : / / example . com / acme / directory>; rel=" index"- BEGIN CERTIFICATE -[End-entity certificate contents]- END CERTIFICATE -- BEGIN CERTIFICATE -[Issuer certificate contents]- END CERTIFICATE -- BEGIN CERTIFICATE -[Other certificate contents]- END CERTIFICATE -Appendix D Exchange for the Pre Authorized with CSR Check Architecture for SBAA second variant may be considered where the authorization mechanism provided by ACME is bypassed. Instead, the verification of the parameters are validated upon receiving the CSR. This presents the advantage that there is not a need to define new identifier or attribute type. On the other hand, this requires the ACME server to keep track of the binding with the CA account until the certificate is issued.This differs from the variant 1 described in Section LABEL: secwarl in thatThe pre-authorization described in Section phase is skipped.The Applying Certificate Issuance described in Section does not carry all identifiers in question. The ACME server MUST be able to handle a order request with no identifiers.The difference toward the traditional ACME are:The CA authorizes identifiers and attributes based on an out-of-band provisioning by the MNO to a external account.Traditional ACME is essentially focused on authorizing identifiers - such as IP address, FQDNS. In our case, authorization concerns identifiers and attributes.The ACME Client does not have to go through challenges and MUST be able to interpret a order response with a status directly set to ’ready’.The ACME MUST be able to interpret an empty list of challenges.The CA MUST be able to interpret an empty list of identifiers in an order request.The CA MUST be able to apply policies based on account to accept or reject the CSR and as such keep track of the binding between the CA account (with the specific information to implement the policy) and the ACME account.The following numbered statements provide additional information on the disclosure:1. A method performed by a client for certificate provisioning, the method comprising:- obtaining a key; and- obtaining, using the key, a certificate from a certification server.2. The method of statement 1, further comprising:- requesting, using the key, authorization for at least one attribute and / or identifier;- obtaining a token from a token authority;- providing the token to the certification server; and- wherein the certificate is obtained using a response from the certification server.3. The method of statement 2, wherein the key is used to bind a local account of the client to a certification account of the certification server.4. The method of any of statements 2 and 3, wherein the request for authorization is transmitted to the certification server.5. The method of statement 4 further comprising receiving a response to the request for authorization from certification server, wherein the response allows the client to perform authorization process and obtain the token.6. The method of any preceding statement, wherein to obtain the certificate the client: provides a certificate signing request, CSR, to the certification server; and receives the certificate in response to providing the CSR.7. The method of any preceding statement, wherein: the client is an automated certificate management entity, ACME, client; and the certification server is an ACME server.8. The method of statement 7, wherein the ACME server is managed by a certification authority, CA, and the ACME client is managed by a mobile network operator, MNO.9. The method of statement 8, wherein the token authority is managed by the CA, optionally wherein the token authority forms part of the ACME server.10. The method of statement 8, wherein the token authority is managed by the MNO, optionally wherein the token authority forms part of a certificate management function, CMF, of the MNO.11. The method of any of statements 8 to 10 wherein the certification server provides certification for several MNOs and wherein the method further comprises, prior to obtaining the token, providing to the certification server a medium access control, MAC,key that identifies the specific MNO to which the client belongs.12. The method of statement 1, wherein the client is configured with the key by a MNO, and wherein the client is further configured to: request, using the key, authorization for at least one attribute and / or identifier from the certification server; and receive in response authorization from the certification server.13. The method of any of statements 1 and 12, wherein the method comprises: sending, by the client, a certificate signing request, CSR, to the certification server; and receiving, from the certification server, the certificate in response to sending the CSR.14. The method of any preceding statement, wherein the key is a pre-shared key, PSK, or wherein the key is a public key.15. The method of any preceding statement, wherein the attributes and / or identifiers comprise one or more of: a country identifier, an organization identifier, an organization unit identifier, a common name, one or more subject alternative name identifiers, and a uniform resource locator, URL.16. The method of any of the previous statements, further comprising: providing, by the client, user data; and forwarding the user data to a host via transmission to a network node.17. A method performed by a token authority for certificate provisioning, the method comprising:- receiving a request from a client for authorization for at least one attribute and / or identifier; and- providing a token to the client, wherein the token is for use in obtaining a certificate.18. The method of statement 17 wherein the method further comprises, prior to receiving the request from the client, obtaining a key and attributes and / or identifiers associated with the client.19. The method of statement 18, wherein the key is used to identify and authenticate the client.20. The method of any of statements 17 to 19, wherein the client is an automated certificate management entity, ACME, client that is managed by a mobile network operator, MNO.21. The method of statement 20, wherein the token authority is managed by the MNO, optionally wherein the token authority forms part of a certificate management function, CMF, of the MNO.22. The method of statement 20, wherein the token authority is managed by a certification authority, CA, optionally wherein the token authority forms part of an ACME server.23. The method of any of statements 17 to 22, wherein the key is a pre-shared key, PSK, or wherein the key is a public key.24. The method of any of statements 17 to 23, wherein the attributes and / or identifiers comprise one or more of: a country identifier, an organization identifier, an organization unit identifier, a common name, one or more subject alternative name identifiers, and a uniform resource locator, URL.25. The method of any of statements 17 to 24, further comprising: obtaining user data from a client; and forwarding the user data to a host or a user equipment.26. A method performed by a certification server for certificate provisioning, the method comprising:- receiving a certificate signing request, CSR, from a client; and- providing a certificate to the client in response to receiving the CSR.27. The method of statement 26, wherein the method further comprises: receiving a request from the client for authorization for at least one attribute and / or identifier, wherein the request includes a key; and instructing the client to perform an authorization process to obtain a token.28. The method of statement 27, further comprising receiving the token from the client, and issuing the CSR in response to receiving the token.29. The method of any of statements 26 to 29 wherein the certification server provides certification for several mobile network operators, MNOs, and wherein the method further comprises: receiving from a specific MNO, a medium access control, MAC, key that identifies the specific MNO; and using the MAC key to verify the client.30. The method of statement 26 further comprising, by the certification server, authorizing binding at least one attribute and / or identifier.31. The method of any of statements 26 to 30 wherein: the client is an automated certificate management entity, ACME, client; and the certification server is an ACME server.32. The method of statement 31, wherein the ACME server is managed by a certification authority, CA, and the ACME client is managed by a mobile network operator, MNO.33. The method of statement 32, wherein the ACME server further comprises a tokenauthority.34. The method of statement 27, wherein the key is a pre-shared key, PSK, or wherein the key is a public key.35. A user equipment acting as a client for certificate provisioning, comprising: processing circuitry configured to cause the user equipment to perform any of the steps of any statements 1 to 16; and power supply circuitry configured to supply power to the processing circuitry.36. A network node acting as a token authority for certificate provisioning, the network node comprising: processing circuitry configured to cause the network node to perform any of the steps of any of statements 17 to 25; and power supply circuitry configured to supply power to the processing circuitry.37. A core network node acting as a certification server for certificate provisioning, the core network node comprising: processing circuitry configured to cause the network node to perform any of the steps of any of statements 26 to 34; and power supply circuitry configured to supply power to the processing circuitry.38. A user equipment (UE) acting as a client for certificate provisioning, the UE comprising: an antenna configured to send and receive wireless signals; radio front-end circuitry connected to the antenna and to processing circuitry, and configured to condition signals communicated between the antenna and the processing circuitry; the processing circuitry being configured to perform any of the steps of any of statements 1 to 16; an input interface connected to the processing circuitry and configured to allow input of information into the UE to be processed by the processing circuitry; an output interface connected to the processing circuitry and configured to output information from the UE that has been processed by the processing circuitry; and a battery connected to the processing circuitry and configured to supply power to the UE.39. A host configured to operate in a communication system to provide an over-the-top (OTT) service, the host comprising: processing circuitry configured to provide user data; anda network interface configured to initiate transmission of the user data to a network node acting as a token authority in a cellular network for transmission to a user equipment (UE), the network node having a communication interface and processing circuitry, the processing circuitry of the network node configured to perform any of the operations of any of statements 17 to 25 to transmit the user data from the host to the UE.40. The host of statement 39, wherein: the processing circuitry of the host is configured to execute a host application that provides the user data; and the UE comprises processing circuitry configured to execute a client application associated with the host application to receive the transmission of user data from the host.41. A method implemented in a host configured to operate in a communication system that further includes a network node acting as a token authority and a user equipment (UE) acting as a client, the method comprising: providing user data for the UE; and initiating a transmission carrying the user data to the UE via a cellular network comprising the network node, wherein the network node performs any of the operations of any of statements 17 to 25 to transmit the user data from the host to the UE.42. The method of statement 41, further comprising, at the network node, transmitting the user data provided by the host for the UE.43. The method of any of statements 41 and 42, wherein the user data is provided at the host by executing a host application that interacts with a client application executing on the UE, the client application being associated with the host application.44. A communication system configured to provide an over-the-top (OTT) service, the communication system comprising: a host comprising: processing circuitry configured to provide user data for a user equipment (UE) acting as a client, the user data being associated with the over-the-top service; and a network interface configured to initiate transmission of the user data toward a cellular network node acting as a token authority for transmission to the UE, the network node having a communication interface and processing circuitry, the processing circuitry of the network node configured to perform any of the operations of any of statements 17 to 25 to transmit the user data from the host to the UE.45. The communication system of the previous statement, further comprising: the network node; and / orthe UE.46. A host configured to operate in a communication system to provide an over-the-top (OTT) service, the host comprising: processing circuitry configured to initiate receipt of user data; and a network interface configured to receive the user data from a network node acting as a token authority in a cellular network, the network node having a communication interface and processing circuitry, the processing circuitry of the network node configured to perform any of the operations of any of statements 17 to 25 to receive the user data from a user equipment (UE) for the host.47. The host of any of statements 45 and 46, wherein: the processing circuitry of the host is configured to execute a host application that receives the user data; and the host application is configured to interact with a client application executing on the UE, the client application being associated with the host application.48. The host of any of statements 45 to 47, wherein the initiating receipt of the user data comprises requesting the user data.49. A method implemented by a host configured to operate in a communication system that further includes a network node acting as a token authority and a user equipment (UE) acting as a client, the method comprising: at the host, initiating receipt of user data from the UE, the user data originating from a transmission which the network node has received from the UE, wherein the network node performs any of the steps of any of statements 17 to 25 to receive the user data from the UE for the host.50. The method of statement 49, further comprising at the network node, transmitting the received user data to the host.51. A host configured to operate in a communication system to provide an over-the-top (OTT) service, the host comprising: processing circuitry configured to provide user data; and a network interface configured to initiate transmission of the user data to a cellular network for transmission to a user equipment (UE) acting as a client, wherein the UE comprises a communication interface and processing circuitry, the communication interface and processing circuitry of the UE being configured to perform any of the operations of any of statements 1 to 16 to receive the user data from the host.52. The host of statement 51 , wherein the cellular network further includes a network nodeconfigured to communicate with the UE to transmit the user data to the UE from the host.53. The host of any of statements 51 and 52, wherein: the processing circuitry of the host is configured to execute a host application, thereby providing the user data; and the host application is configured to interact with a client application executing on the UE, the client application being associated with the host application.54. A method implemented by a host operating in a communication system that further includes a network node acting as a token authority and a user equipment (UE) acting as a client, the method comprising: providing user data for the UE; and initiating a transmission carrying the user data to the UE via a cellular network comprising the network node, wherein the UE performs any of the operations of any of statements 1 to 16 to receive the user data from the host.55. The method of statement 54, further comprising: at the host, executing a host application associated with a client application executing on the UE to receive the user data from the host application.56. The method of statement 55, further comprising: at the host, transmitting input data to the client application executing on the UE, the input data being provided by executing the host application, wherein the user data is provided by the client application in response to the input data from the host application.57. A host configured to operate in a communication system to provide an over-the-top (OTT) service, the host comprising: processing circuitry configured to provide user data; and a network interface configured to initiate transmission of the user data to a cellular network for transmission to a user equipment (UE) acting as a client, wherein the UE comprises a communication interface and processing circuitry, the communication interface and processing circuitry of the UE being configured to perform any of the steps of any of statements 1 to 16 to transmit the user data to the host.58. The host of statement 57, wherein the cellular network further includes a network node configured to communicate with the UE to transmit the user data from the UE to the host.59. The host of any of statements 57 and 58, wherein: the processing circuitry of the host is configured to execute a host application, thereby providing the user data; andthe host application is configured to interact with a client application executing on the UE, the client application being associated with the host application.60. A method implemented by a host configured to operate in a communication system that further includes a network node acting as a token authority and a user equipment (UE) acting as a client, the method comprising: at the host, receiving user data transmitted to the host via the network node by the UE, wherein the UE performs any of the steps of any of statements 1 to 16 to transmit the user data to the host.61. The method of statement 60, further comprising: at the host, executing a host application associated with a client application executing on the UE to receive the user data from the UE.62. The method of any of statements 60 and 61, further comprising: at the host, transmitting input data to the client application executing on the UE, the input data being provided by executing the host application, wherein the user data is provided by the client application in response to the input data from the host application.

Claims

Claims1. A method performed by a client (1300) for certificate provisioning, the method comprising:- obtaining (102) a key; and- obtaining (104), using the key, a certificate from a certification server (1800).

2. The method of claim 1, further comprising:- requesting, using the key, authorization for at least one attribute and / or identifier;- obtaining a token from a token authority (1400);- providing the token to the certification server (1800); and- wherein the certificate is obtained using a response from the certification server (1800).

3. The method of claim 2, wherein the key is used to bind a local account of the client (1300) to a certification account of the certification server (1800).

4. The method of any of claims 2 and 3, wherein the request for authorization is transmitted to the certification server (1800).

5. The method of claim 4 further comprising receiving a response to the request for authorization from the certification server (1800), wherein the response allows the client (1300) to perform authorization process and obtain the token.

6. The method of any preceding claim, wherein to obtain the certificate the client (1300): provides a certificate signing request, CSR, to the certification server (1800); and receives the certificate in response to providing the CSR.

7. The method of any preceding claim, wherein: the client (1300) is an automated certificate management entity, ACME, client; and the certification server (1800) is an ACME server.

8. The method of claim 7, wherein the ACME server is managed by a certification authority, CA, and the ACME client is managed by a mobile network operator, MNO.

9. The method of claim 8, wherein the token authority (1400) is managed by the CA, optionally wherein the token authority forms part of the ACME server.

10. The method of claim 8, wherein the token authority (1400) is managed by the MNO, optionally wherein the token authority forms part of a certificate management function, CMF, of the MNO.

11. The method of any of claims 8 to 10 wherein the certification server (1800) provides certification for several MNOs and wherein the method further comprises, priorto obtaining the token, providing to the certification server (1800) a medium access control, MAC, key that identifies the specific MNO to which the client (1300) belongs.

12. The method of claim 1, wherein the client (1300) is configured with the key by a MNO, and wherein the method further comprises: requesting, using the key, authorization for at least one attribute and / or identifier from the certification server (1800); and receiving in response authorization from the certification server (1800).

13. The method of any of claims 1 and 12, wherein the method comprises: sending, by the client (1300), a certificate signing request, CSR, to the certification server (1800); and further comprises receiving, from the certification server (1800), the certificate in response to sending the CSR.

14. The method of any preceding claim, wherein the key is a pre-shared key, PSK, or wherein the key is a public key.

15. The method of any preceding claim, wherein the attributes and / or identifiers comprise one or more of: a country identifier, an organization identifier, an organization unit identifier, a common name, one or more subject alternative name identifiers, and a uniform resource locator, URL.

16. A method performed by a token authority (1400) for certificate provisioning, the method comprising:- receiving (202) a request from a client (1300) for authorization for at least one attribute and / or identifier; and- providing a token to the client (1300), wherein the token is for use in obtaining a certificate.

17. The method of claim 16 wherein the method further comprises, prior to receiving the request from the client (1300), obtaining a key and attributes and / or identifiers associated with the client (1300).

18. The method of claim 17, wherein the key is used to identify and authenticate the client (1300).

19. The method of any of claims 16 to 18, wherein the client (1300) is an automated certificate management entity, ACME, client that is managed by a mobile network operator, MNO.

20. The method of claim 19, wherein the token authority (1400) is managed by the MNO, optionally wherein the token authority forms part of a certificate management function, CMF, of the MNO.

21. The method of claim 19, wherein the token authority (1400) is managed by a certification authority, CA, optionally wherein the token authority forms part of an ACME server.

22. The method of any of claims 16 to 21, wherein the key is a pre-shared key, PSK, or wherein the key is a public key.

23. The method of any of claims 16 to 22, wherein the attributes and / or identifiers comprise one or more of: a country identifier, an organization identifier, an organization unit identifier, a common name, one or more subject alternative name identifiers, and a uniform resource locator, URL.

24. A method performed by a certification server (1800) for certificate provisioning, the method comprising:- receiving (302) a certificate signing request, CSR, from a client (1300); and- providing (304) a certificate to the client (1300) in response to receiving the CSR.

25. The method of claim 24, wherein the method further comprises: receiving a request from the client (1300) for authorization for at least one attribute and / or identifier, wherein the request includes a key; and instructing the client (1300) to perform an authorization process to obtain a token.

26. The method of claim 25, further comprising receiving the token from the client (1300), and issuing the CSR in response to receiving the token.

27. The method of any of claims 24 to 26 wherein the certification server (1800) provides certification for several mobile network operators, MNOs, and wherein the method further comprises: receiving from a specific MNO, a medium access control, MAC, key that identifies the specific MNO; and using the MAC key to verify the client (1300).

28. The method of claim 24 further comprising, by the certification server (1800), authorizing binding at least one attribute and / or identifier.

29. The method of any of claims 24 to 28 wherein: the client (1300) is an automated certificate management entity, ACME, client; and the certification server (1800) is an ACME server.

30. The method of claim 29, wherein the ACME server is managed by a certification authority, CA, and the ACME client is managed by a mobile network operator, MNO.

31. The method of claim 30, wherein the ACME server further comprises a token authority.

32. The method of claim 25, wherein the key is a pre-shared key, PSK, or wherein the key is a public key.

33. A user equipment (1300) acting as a client for certificate provisioning, comprising: processing circuitry (1302) configured to cause the user equipment (1300) to: obtain a key; and obtain, using the key, a certificate from a certification server (1800); andpower supply circuitry (1308) configured to supply power to the processing circuitry (1302).

34. A network node (1400) acting as a token authority for certificate provisioning, the network node (1400) comprising: processing circuitry (1402) configured to cause the network node (1400) to: receive a request from a client (1300) for authorization for at least one attribute and / or identifier; and provide a token to the client (1300), wherein the token is for use in obtaining a certificate; and power supply circuitry (1408) configured to supply power to the processing circuitry (1402).

35. A core network node (1800) acting as a certification server for certificate provisioning, the core network node (1800) comprising: processing circuitry (1802) configured to cause the core network node (1800) to receive a certificate signing request, CSR, from a client (1300); and provide a certificate to the client (1300) in response to receiving the CSR; and power supply circuitry (1808) configured to supply power to the processing circuitry (1802).

36. A communication system comprising at least one of: the user equipment (1300) of claim 33; the network node (1400) of claim 34; and the core network node (1800) of claim 35.

Images