eu-digital-identity-wallet / eudi-doc-architecture-and-reference-framework

The European Digital Identity Wallet
https://eu-digital-identity-wallet.github.io/eudi-doc-architecture-and-reference-framework/
Other
369 stars 55 forks source link

[Trust Model] Definition of Trust Anchor #198

Open peppelinux opened 1 week ago

peppelinux commented 1 week ago

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 commented 3 days 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:

  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 commented 2 days ago

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.