Hi dnsop,
This is a cross-post pointer from my dmsc thread earlier today on
draft-somoza-atn-agent-trust-negotiation-00. The draft sits primarily in dmsc
but registers SVCB ParamKeys, so I wanted to give dnsop visibility on the
DNS-layer content specifically.
The dnsop-relevant part is small. The draft requests two SVCB ParamKey
registrations:
atn URI Absolute HTTPS URI pointing to an ATN Index Document
atn-digest hex-string SHA-256 digest of the Index Document for integrity
binding
It also proposes the same two names as TXT key=value tags for compatibility
with existing TXT-based agent discovery records (notably AID).
The integrity model: the digest is bound to the content at the URL, not the DNS
lookup itself. This is the same model as Subresource Integrity in web
platforms. DNSSEC remains useful for authenticating the binding; the digest
covers the artifact after fetch. The draft requires JWS signature on the Index
Document when DNSSEC is not validated, and makes it RECOMMENDED but not
REQUIRED when DNSSEC is in use.
Questions where I would value dnsop input:
1. The name pattern. "atn" and "atn-digest" mirrors patterns in existing
TXT-based discovery drafts. Is there a dnsop preference for the integrity field
name (e.g., "atn-i", "atn-sha256", etc.) before this goes anywhere near IANA?
2. Allocation path. The draft is Experimental. Is the right path: (a)
provisional allocation from the private-use range during the Experimental
period, (b) early allocation with WG sponsorship, or (c) wait until
standards-track maturity?
3. SVCB vs TXT. The draft offers both forms for compatibility with the
discovery proposals already in flight (AID uses TXT; DNS-AID uses SVCB). Should
ATN deprecate the TXT form and require SVCB given dnsop's general direction?
4. DNSSEC interaction. The current language ("RECOMMENDED but not REQUIRED when
DNSSEC is in use") may be too permissive. Should JWS-on-Index be MUST
regardless?
The draft itself is at:
https://datatracker.ietf.org/doc/draft-somoza-atn-agent-trust-negotiation/
The DNS Binding section is Section 4 and is short.
Thanks,
Enrique
_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]
