Liaison statement
Reply to "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.