Repository navigation
spec: define 'align' for publisher authority binding (§4.5.1) - #98
sachinsharma3191 wants to merge 1 commit into
Conversation
| #### 4.5.1 Publisher Authority Binding | ||
|
|
||
| The cryptographic trust domain asserted in `trustManifest.identity` MUST align with the `<publisher>` domain embedded in the entry's discovery identifier (Appendix C). This is ARD's defense against namespace squatting: an entry claiming `urn:air:google.com:...` is rejected by a verifying registry unless it can produce a verifiable attestation issued by `google.com`. The discovery identifier and the security principal are otherwise decoupled — the former is a stable searchable handle, the latter a dynamic cryptographic credential. | ||
| The cryptographic trust domain asserted in `trustManifest.identity` MUST align with the `<publisher>` domain embedded in the entry's discovery identifier (Appendix C). The trust domain aligns with the publisher when it equals the publisher domain, or is a subdomain of it, after case folding, and the publisher domain is not a public suffix. Domains are compared as A-labels, so an internationalised domain name is converted before the comparison. For example, with the identifier `urn:air:acme.com:server:weather`, the identity `spiffe://prod.acme.com/ns/prod/sa/weather` aligns, while `spiffe://acme.com.evil.example/...` does not; an entry claiming `urn:air:co.uk:...` cannot align with any identity, because `co.uk` is a public suffix. This is ARD's defense against namespace squatting: an entry claiming `urn:air:google.com:...` is rejected by a verifying registry unless it can produce a verifiable attestation issued by `google.com`. The discovery identifier and the security principal are otherwise decoupled — the former is a stable searchable handle, the latter a dynamic cryptographic credential. |
There was a problem hiding this comment.
Thanks for putting this together, @sachinsharma3191
One concern with allowing any subdomain to match by default: in many deployments, subdomains (dev.acme.com, staging.acme.com, vendor-hosted subdomains, or multi-tenant hosts) are operated at a lower trust level than the apex domain. If spiffe://dev.acme.com/... or did:web:dev.acme.com automatically aligns with urn:air:acme.com:..., a lower-trust subdomain can mint entries under the root acme.com namespace without acme.com's authorization.
It would be safer (and simpler) to require an exact domain match between the trust domain and (both as lowercase ASCII A-labels, since §4.2 already requires to be lowercase. If prod.acme.com is its own trust domain, it can either publish as urn:air:prod.acme.com:... or be explicitly delegated by acme.com at the key/DID/bundle layer. That also avoids needing verifiers to bundle and maintain a Public Suffix List just to guard subdomain matching.
Fixes #94.
§4.5.1 requires the trust domain in
trustManifest.identityto "align" with the URN publisher domain but never defines the term, so registries can pick different readings (equality vs. subdomain).This uses the wording proposed in the issue: the trust domain aligns when it equals the publisher domain or is a subdomain of it (after case folding), and the publisher domain is not a public suffix; comparison is on A-labels. Adds a worked example (a SPIFFE ID under
prod.acme.comaligns withacme.com;acme.com.evil.exampleand aco.ukpublisher do not) and updates the D.2 constraint to point at the definition.Docs-only; no schema change.