Liaison statement
Reply to "LSout to IETF RATS & LAMPS on SEC020 Identity Trust Model"

The IETF thanks the ETSI ISG NFV-SEC for your liaison statement titled, "LSout
to IETF RATS & LAMPS on SEC020 Identity Trust Model"
(https://datatracker.ietf.org/liaison/1945/). We appreciate the ETSI ISG
NFV-SEC work on this important topic and your effort to keep the IETF apprised
of your progress, including sharing the NFV-SEC 020 document, and details of
the ongoing work.

The IETF LAMPS and RATS working groups have been working to define
specifications that support the stated identity management goals. This response
provides feedback on the proposed use of the referenced RFCs and
Internet-Drafts and highlights potential use of other RFCs and Internet-Drafts
and some potential gaps. The response is focused on proposed specifications
associated with the LAMPS and RATS working groups and does not comment on
broader aspects of NFV-SEC 020 nor usage of specifications produced in other
forum, like OpenID, Verifiable Credentials, etc. Accordingly, this response
focuses on sections 6.5 and 8.2.3 of NFV-SEC 020 V0.0.13 (2024-10).

Section 6.5 provides a very high-level view of the attestation process. It may
benefit from additionally providing a less abstract summary that highlights the
preparation of an EAT for presentation to a verifier, who in turn prepares a
different EAT (or similar) for inclusion in an X.509 certificate. At present,
EAT is only explicitly referenced as the format of the output produced by a
verifier. There is no explicit mention of EATS prepared by attester(s), though
this is implied. Clearly identifying each EAT that plays a role in the process
would be helpful.

Generally, the usage of the X.509 certificate as described is reasonable and
consistent with stated plans to use the certificates for mutually authenticated
TLS. The profiled use of the subject field and the basic constraints, subject
alternative name, and extended key usage extensions are all consistent with
RFC5280 and typical usage. However, the allowance for keyAgreement and
keyEncipherment in the keyUsage extension is inconsistent with current
recommendations targeting use of TLS 1.3 (see the CAB Forum baseline
requirements). A description regarding how subjectAltName values are verified
may be appropriate. This may be accomplished by referencing applicable
certificate policies, if available.

The proposed usage of the subjectDirectoryAttributes extension is more
questionable. Neither NFV-SEC020 nor any existing RFC or current LAMPS or RATS
Internet-Draft defines an attribute suitable for including an EAT in a
certificate. As currently written, the certificate profile in section 8.2.3
cannot be implemented. An attribute that may be used to convey an EAT in a
certificate request is defined in draft-ietf-lamps-csr-attestation-14. However,
its purpose is to convey evidence to be consumed by a verifier in support of
certificate issuance. The mechanisms in ietf-lamps-csr-attestation are likely
to be of use in the NFV-SEC020 context to that purpose, but the attribute is
probably not appropriate to reuse to convey attestation results.

The proposed usage of EAT is underspecified. Section 8.2.3.2.5.1 defines the
use of an EAT to convey an attestation result. This EAT is generated and signed
by a verifier and, per the profile in table 8.2.3.2.5.1-1, contains four
claims. However, it is unclear whether these claims were originated by the
verifier, by the attester, or some combination. Additionally, the measures
claim appears to be being used to convey an “attestation result”, but this is
not the purpose of the claim. At present, there is no claim defined in an IETF
RFC or LAMPS or RATS Internet-Draft to convey an “attestation result”.

There are several Internet-Drafts currently in development that may be useful
in the NFV-SEC020 context as well as potential for new Internet-Drafts/RFCs to
fill some gaps.

EATs are signed. Including a signed token that contains a verifier’s appraisal
in an X.509 certificate may be overkill. Relying parties of the X.509
certificate may have no relationship to the verifier and have no means of
verifying the signature. The draft-ietf-rats-uccs specification defines an
unsigned collection of claims, that would be covered by the certificate
signature and require no future verification actions on the party of relying
parties of the certificate.

Section 6 of EAT defines a format for defining profiles of EAT usage. The
NFV-SEC020 context may benefit from defining or referencing profiles that
govern attester-generated EAT contents and verifier-generated EAT contents.
Several profiles are currently under development that may serve as examples,
including draft-tschofenig-rats-psa-token-24 and
draft-kdyxy-rats-tdx-eat-profile-02.

Figure 6.5.1-2 references several policies that inform the behavior of
verifiers and relying parties, but the document never addresses how these
policies are defined or used. The draft-ietf-rats-corim-06 specification
defines a format for representing information that a verifier may require to
appraise evidence. Several profiles of CoRIM usage are currently in
development, including draft-fdb-rats-psa-endorsements-05 and
draft-cds-rats-intel-corim-profile-03.

There is on-going work related to representing attestation results. The
draft-ietf-rats-ar4si specification provides an abstract definition of
information that may appear in attestation results. The draft-fv-rats-ear-04
specification defines concrete representation of attestation results and
proposes several claims that may be useful in the NFV-SEC020 context.

It may be worth considering whether encoding attestation results in each
certificate is the best way to achieve the desired goal. One alternative would
be to define a certificate policy that clearly describes the actions a CA must
take with regard to processing evidence from a prospective subject then
including an object identifier that identifies that certificate policy in the
certificate policies extension of issued certificates. Relying parties who
require attestation support could then provide the object identifier as input
to an RFC5280 compliant validator. This approach would not require any new
ASN.1 elements to be defined, would not require any new attributes or
extensions to be included in each certificate, and would not require any
changes to RFC5280-compliant certification path validators. Most CAs already
abide by a certificate policy, as described in RFC3647, so the only change
would be the inclusion of additional requirements in the policy.

In addition to LAMPS and RATS, the IETF has several working groups that are
relevant to the work discussed and should be considered in context of device
and function identifiers. ETSI mentions reference to SPIFFE and SPIRE, which
are being considered in the Workload Identity in Multi System Environments
(WIMSE) and Secure Patterns for Internet CrEdentials (SPICE) working groups, as
well as related base work in OAuth that is part of the referenced OpenIdentity
framework. The SPIFFE/SPIRE documentation itself includes references to IETF
work in the OAuth working group such as variations on bearer tokens and the
IETF JOSE working group including JSON Web Tokens with specified format
requirements.

These concepts as a whole are being discussed across several IETF working
groups as mentioned, with WIMSE defining an architecture and protocol for
workload identity. The work in SPICE and WIMSE is an effort to look across the
various communities and align to agreed standards. Your participation and
reference of the resulting work is welcome.