Certificates bind keys to number resources
Resource certificates bind public keys to IP address ranges or AS-number resources, with subordinate allocations reflected in certification paths. The structure follows number-resource allocation so relying parties can check the basis for an authorization.
These certificates convey resource authorization rather than authenticating a descriptive personal or company name, and do not replace HTTPS certificates. Validating a key’s resource scope does not establish the truth of everything an organization publishes.
References: [1]
Resource holdings differ from route-origin permission
Holding a resource certificate does not by itself specify which AS may originate a prefix. Signed objects such as ROAs express that permission, and their validation checks the signer’s resource authority as well as the signature.
Repositories publish certificates, revocation information and signed objects. Relying software obtains and validates them as routing-policy inputs; this does not transform BGP into certificate carriage or require a new signature check on every user packet.
Trust anchors, updates and use boundaries
Relying parties build paths to configured trust anchors and check validity and relevant revocation state. Allocations, rollover and revocation change over time, so cached authorization cannot be treated as permanently current. Signed repository objects and manifests support integrity.
Origin validation checks authorization for a route’s originating AS, not every AS_PATH hop, and does not itself choose acceptance policy. Validation, updates, policy and forwarding remain distinct mechanisms.