[Trust Model] Definition of Trust Anchor

[peppelinux]

In docs/annexes/annex-1/annex-1-definitions.md we read that the Trust Anchor is defined as below

The public key of an entity that is trusted by a Wallet Instance and used for validating certificates in certification paths.

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

[henkbirkholz]

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:

1. A public key as a point of trust
2. A CA as a point of trust
3. A public-key certificate as a point of trust
4. Combinations and variations of the first three definitions are also used in the PKI literature

[peppelinux]

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.

[digeorgi]

Thank you very much for your comment. We agree it is important to use terms in their generally accepted meaning, However, 'trust anchor' is actually used in different meanings in the standards you refer to. For example: RFC 5280 uses this word mainly to refer to a public key of a certificate authority, in the same way as the ARF does. Sometimes it uses the word also to refer to the authority itself. In fact, the same is true for RFC 5914, despite the definition you quote. That RFC is titled 'Trust Anchor format' - but of course it does not describe the format of the authority, but the format of the public key of that authority. Reading through the RFC, it is clear that the word is used in both meanings. ISO 27001 (2022) does not use the word 'trust anchor' at all.

In conclusion, we believe we use this term in its generally accepted meaning and there is no reason to change to a different word. That being said, the definition is Annex 1 is in fact incorrect and incomplete, since a trust anchor is not trusted by a Wallet Instance exclusively and since it not only contains a public key, but also some data identifying the authority owning that key. This will be addressed in an upcoming ARF version update.

[henkbirkholz]

A public key is one of many potential manifestations how to refer to a trust anchor, as RFC 4949 literally states. Please be not deterred by the age of RFC4949. If you use a portion of it (in this case A public key as a point of trust, it really never hurts to pull in the RFC4949 reference. If you use it differently, it also does never hurt to specify local use and how it is different (but probably similar) to RFC4949.