[lamps] Re: New Liaison Statement, "LSout to IETF on “Certificate Management”"

["Brockhaus, Hendrik" <[e-mail]>]

I just wanted to let you know that RFC 9810 (https://datatracker.ietf.org/doc/rfc9810/) and RFC 9811 (https://datatracker.ietf.org/doc/rfc9811/) were published in July obsoleting RFC 4210, RFC 6712, and RFC 9480.

Hendrik

Von: Russ Housley <[e-mail]>
Gesendet: Montag, 16. Juni 2025 18:22
An: Support Nvf <[e-mail]>
Cc: Kathleen Moriarty <[e-mail]>; Ned Smith <[e-mail]>; Tim Hollebeek <[e-mail]>; Deb Cooley <[e-mail]>; Limited Additional Mechanisms for PKIX and SMIME Discussion List <[e-mail]>; Paul Wouters <[e-mail]>; Remote ATtestation ProcedureS Discussion List <[e-mail]>; [e-mail]; IETF Liaison Statements <[e-mail]>; [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]
Betreff: [lamps] Re: New Liaison Statement, "LSout to IETF on “Certificate Management”"


In January 2025, the documents https://datatracker.ietf.org/doc/draft-ietf-lamps-rfc6712bis/ and https://datatracker.ietf.org/doc/draft-ietf-lamps-rfc4210bis/ approved by the IESG. The two documents are expected to be published as RFCs in mid-2025. They will obsolete the current RFCs 4210, 6712 and 9480.


RE: Action 1.


In NFV-SOL023: https://docbox.etsi.org/ISG/NFV/Open/Drafts/SOL023/NFV-SOL023v0011.zip, it is crucial to understand that the delegation mode features distinct endpoints for TLS and CMP. The TLS endpoint is designated as the CMF acting as an RA forwarding a CMP request to the CA if the certificate request was approved. While the CMP endpoint on the CA requires the message-origin authentication of the request. This necessitates that the VNFM must be registered with both the CMF and the CA, making both authentications essential.


It is important to note that the end-to-end authentication capability of CMP is crucial for the message-origin authentication at the CA. It cannot be replaced solely by the TLS client authentication as it offers only authentication on the first hop at the CMF. The senderKID facilitates identification of the CMP protection credentials. Leaving the senderKID empty only makes sense when omitting CMP message protection. This would lead to an unprotected certificate request message, meaning no proof-of-identity of the VNFM requesting the certificate, being transmitted from the CMF to the CA.


Both TLS and CMP provide comprehensive authentication means. While TLS only provides authentication to the next TLS hop and CMP can provide end-to-end authentication to even further hops. For CMP, the two endpoints authenticating to each other are the VNFM requesting a certificate and the CA/RA. According to RFC 9483, CMP messages must be authenticated, meaning that the certificate request message will be generated by the VNFM requesting the certificate, and will be authenticated by the CA/RA. Authentication is non-negotiable and cannot be null or left empty; an unprotected CMP message will cause the message to be rejected by the CA/RA. This is because without message-origin authentication of the certificate request message the CA/RA has no reliable information to authorize the certificate request with. The senderKID is used to ease the identification of the CMP protection certificate and therefore is required to be set accordingly.



While TLS provides server authentication, in cases of mutually authentication, both the client and server are authenticated. A single endpoint can utilize the same identity for both TLS and CMP. This allows an entity requesting the certificate to send the certificate request message using the same identity on TLS as well as on CMP level. It is essential to recognize that both TLS and CMP offer authentication based on certificates and pre-shared keys.


RE: Action 2.


The process of registering or de-registering during the provisioning phase involves CMP clients being registered with the Certification Authority (CA) to obtain certificates linked to their accounts. However, CMP does not exactly encompass this concept as described in ETSI-GS-NFV-IFA 026, which seems to be related to account management. Typically, these actions are carried out through proprietary APIs offered by the CA, and there are currently no intentions to standardize these APIs at the IETF. Consequently, it is highly unlikely that this will fall within the scope of LAMPS.



When CMP mentions “registration” it is understood as the process where an entity applies for its first certificate at the PKI and this PKI issues it. Accordingly, the de-registration of an entity takes place through the revocation of all still valid certificates that this PKI has issued for this entity. Details on initial registration/certification using CMP can be found at https://datatracker.ietf.org/doc/html/draft-ietf-lamps-rfc4210bis-18#section-4.2 and https://datatracker.ietf.org/doc/html/rfc9483#section-4.1.1. De-registration might be implemented by revocation or expiration of the certificates. Details on revocation using CMP can be found in https://datatracker.ietf.org/doc/html/draft-ietf-lamps-rfc4210bis-18#section-5.3.9 and https://datatracker.ietf.org/doc/html/rfc9483#section-4.2.



Because CMP is a flexible protocol, it can easily be extended. If you wish to perform the registration/de-registration exchanges inband CMP you could either profile the ir/cr/kur/p10cr/rr messages or specify additional general messages (genm/genp), see examples for how to extend general messages in https://datatracker.ietf.org/doc/html/draft-ietf-lamps-rfc4210bis-18#section-5.3.19 and https://datatracker.ietf.org/doc/html/rfc9483#section-4.4. Such extensions would require specification in an RFC.


RE: Action 3.


ACME offers the Token Authority as outlined in RFC 9447 and RFC 9448. A Token Authority acts as an RA performing authorization of a certificate request in a domain separate from the CA.  However, the current architecture is tailored for specific tokens, which may not align with your particular needs.



As said, CMP is quite flexible. An authorization token could either be carried in the generalInfo field of the CMP request message header (see https://datatracker.ietf.org/doc/html/draft-ietf-lamps-rfc4210bis-18#section-5.1.1) or in the regInfo field of the certificate request (see https://datatracker.ietf.org/doc/html/rfc4211#section-3, this does not work with PKCS#10). The respective new syntax would need to be specified in an RFC.

When a CA does not use the Token Authority, note that it will also likely consider isolating internally the ACME server exposed to the Internet from its certificate issuing function.


RE: Action 4.


The IETF operates as an open standards organization, welcoming anyone to join and participate. Currently, the primary groups of concern are LAMPS https://datatracker.ietf.org/wg/lamps/about/ and ACME https://datatracker.ietf.org/wg/acme/about/. We strongly encourage you to participate actively in the LAMPS and ACME Working Groups. In case you plan to extend the CMP protocol based on the proposals above, there may be support regarding CMP ASN.1 syntax specification. Participation is the best way to represent the ETSI requirements in the IETF.


In NFV-SOL023, accessible at https://docbox.etsi.org/ISG/NFV/Open/Drafts/SOL023/NFV-SOL023v0011.zip, we recognize that the CMP message is part of a specific protocol outlined in this document. It is important to clarify that CMP is not just message syntax. Like many protocols, it includes elements of procedure as well.



We suggest that your protocol be divided into two components: one component is responsible for the registration/de-registration and the other component is responsible for the management of the certificates.  If you are using CMP, the latter must be articulated by using RFC9483.


On Apr 24, 2025, at 8:11 PM, Liaison Statement Management Tool <[e-mail]<mailto:[e-mail]>> wrote:

Title: LSout to IETF on “Certificate Management”
Submission Date: 2025-04-24
URL of the IETF Web page: https://datatracker.ietf.org/liaison/1992/
Please reply by 2025-06-16
From: Support Nvf <[e-mail]<mailto:[e-mail]>>
To: Ned Smith <[e-mail]<mailto:[e-mail]>>,Kathleen Moriarty <[e-mail]<mailto:[e-mail]>>,Russ Housley <[e-mail]<mailto:[e-mail]>>,Tim Hollebeek <[e-mail]<mailto:[e-mail]>>
Cc: Limited Additional Mechanisms for PKIX and SMIME Discussion List <[e-mail]<mailto:[e-mail]>>,Remote ATtestation ProcedureS Discussion List <[e-mail]<mailto:[e-mail]>>,Russ Housley <[e-mail]<mailto:[e-mail]>>,Deb Cooley <[e-mail]<mailto:[e-mail]>>,Paul Wouters <[e-mail]<mailto:[e-mail]>>,Kathleen Moriarty <[e-mail]<mailto:[e-mail]>>,Ned Smith <[e-mail]<mailto:[e-mail]>>,Tim Hollebeek <[e-mail]<mailto:[e-mail]>>
Response Contacts: Yoshihiro Nakjima (ISG Chair) <[e-mail]<mailto:[e-mail]>>
Deng Hui (ISG Vice-Chair) <[e-mail]<mailto:[e-mail]>>
Wang Xuliang (ISG Vice-Chair) <[e-mail]<mailto:[e-mail]>>
Ju Manchang (ISG Vice-Chair) <[e-mail]<mailto:[e-mail]>>
Hassett Brendan (ISG Technical Manager) <[e-mail]<mailto:[e-mail]>>
Leslie Willis (SEC WG Chair) <[e-mail]<mailto:[e-mail]>>
Preda Stere (SEC WG Vice-Chair) <[e-mail]<mailto:[e-mail]>>
Xia Haitao (IFA WG Chair) <[e-mail]<mailto:[e-mail]>>
Kostas Katsalis (IFA WG Vice-Chair) <[e-mail]<mailto:[e-mail]>>
Yuya Kuno (SOL WG Chair & feature prime) <[e-mail]<mailto:[e-mail]>>
Li Shitao (SOL WG Vice-Chair) <[e-mail]<mailto:[e-mail]>>
Technical Contacts:
Purpose: For action

Body: 1. Overall description:

ETSI ISG NFV has been working on “Certificate Management” and has published the set of specifications.

Main outcome of works is ETSI GS NFV-IFA 026, “Network Functions Virtualisation (NFV) Release 5; Management and Orchestration; Security Architecture enhancements for NFV Specification”, which introduces the main concept, architecture, use cases, and requirements, and ETSI GS NFV-IFA 033 “Reference points related to Security Manager and Certificate Management Function Interface and Information Model Specification”. Version 5.2.1 of ETSI NFV IFA026/IFA033 are available at the following location:

• https://www.etsi.org/deliver/etsi_gs/NFV-IFA/001_099/026/05.02.01_60/gs_NFV-IFA026v050201p.pdf
• https://www.etsi.org/deliver/etsi_gs/NFV-IFA/001_099/033/05.02.01_60/gs_NFV-IFA033v050201p.pdf

ISG NFV is working on ETSI GS NFV-SOL 023, “Specification of protocol and data model solutions for CMF - NFV-MANO reference point”, that introduces the protocol and data model solutions for CMF - NFV-MANO reference point by use of profiling approach against IETF RFC 4210/9480/9483 CMP. One of the options within IFA026/ IFA033/ SOL023 is the use of the VNFM (VNF Manager) as a delegate for certificate request/renewal/revocation (delegation mode). The proof of ownership may not be available and therefore other concepts of authentication are being investigated. The following questions have been raised.

• Where the transport for CMPv2 is using HTTP (RFC 6712) which itself is secured using TLS could client certificate-based authentication (mTLS) be used rather than authentication keys? If so, what exact values would be expected for the “senderKID” parameter? Or can the client skip or put null according to the chapter 3.1 of RFC 9483 for senderKID?
• As described in ETSI GS NFV-IFA026/IFA033, the concepts of “Registration” and “De-registration” are introduced. ETSI NFV would like to ask or confirm that CMPv2 has the appropriate concept aligning with end entity registration / de-registration or whether there are any evolution plans to support similar kinds of concepts?
• For the consideration of functions of ACME server (RFC 8555), ETSI NFV has been discussing if the ACME server can be realized as part of CA functionality or different functions. ETSI NFV would like to ask for thoughts on this matter and any background information.

2. Actions:

ETSI ISG NFV kindly asks your organization to:
1) provide technical feedback on what exact values would be expected for the “senderKID” paramenter when the transport for CMPv2 is using HTTP (RFC 6712).
2) provide technical feedback on whether CMPv2 has the appropriate concept aligning with end entity registration / de-registration or whether there are any evolution plans to support similar kinds of concepts.
3) provide technical feedback on whether the ACME server can be realized as part of CA functionality or different function.
4) consider the possibility of collaboration on the harmonized and consolidated certificate related standards among SDOs who are working e.g. virtualization-platform for telco industry. ETSI ISG NFV aims to avoid potential overlapping work and fragmentation of the standards in close area/aspect of the industry.

3. Date of next meetings of the originator:

16-20 June 2025       NFV#50 plenary                                                         Shanghai, China

In addition, NFV-IFA WG has weekly decision-making conference calls every Wednesday, NFV-SEC WG has bi-weekly decision-making conference calls every Thursday, and NFV-SOL WG has weekly decision-making conference calls every Thursday.
Attachments:

   NFV(25)000052r2_LSout_on_ENH01_01_Certificate_Management_to_IETF
   https://www.ietf.org/lib/dt/documents/LIAISON/liaison-2025-04-25-etsi-isg-nfv-lamps-rats-lsout-to-ietf-on-certificate-management-attachment-1.docx