Open peppelinux opened 1 week ago
I'd like to add the generic definition of a Trust Anchor from RFC4949 (Internet Security Glossary, Version 2):
$ trust anchor (I) /PKI/ An established point of trust (usually based on the authority of some person, office, or organization) from which a certificate user begins the validation of a certification path.
RFC4949 also illustrates four examples that are common in literature:
- A public key as a point of trust
- A CA as a point of trust
- A public-key certificate as a point of trust
- Combinations and variations of the first three definitions are also used in the PKI literature
The entity offers superior scalability compared to the "artifact" (the certificate), as the artifact alone faces limitations in terms of rotation, revocation, and accountability.
RFC 4949 is informative but appears isolated when compared to other referenced specifications.
For optimal configuration, it would be preferable to establish the trust anchor as an entity, if there is consensus on this approach.
In docs/annexes/annex-1/annex-1-definitions.md we read that the Trust Anchor is defined as below
I find this really concerning since the Trust Anchor is a role within the ecosystem and not an artifact, such as a certificate represented by a public key along with other data, or a public key alone.
The evidence that brings my attention to this issues can be found in the literature, such as in RFC 5914 where we read that "A trust anchor is an authoritative entity represented by a public key and associated data"
It is therefore clear that the Trust Anchor is an authoritative entity, which is/can be represented by a certificate or any other public key accompanied by metadata
other references taken from the literature are:
ISO/IEC 27001 IETF RFC 5280 NIST Special Publication 800-32