On 9/9/26 15:07, Ben Schwartz wrote:
* The consumer of these records
...in DIEM terms, a "validator"...
is expected to learn out of band "$SPEAKER publishes their claims about $ASSET at $DOMAIN".
Yes. In many cases, the "out of band" would be printing on the asset, or a QRcode, or an NFC tag. But the validator (who in 99% of cases would be a customs agent) is expected to have realm expertise in whether such out-of-band assertions are plausible or not. i.e. they would likely be better than the average Internet user at spotting typosquatting, etc. And they'd be wielding a validating scanner which might well have up-to-date blocklists for homographs, etc.
There is no presumption of equality or equivalence between $SPEAKER, $ASSET, and $DOMAIN.
Well... No, but the issuer and the validator are actors, whereas the asset (although it might be a person) is passive relative to the transaction. The asset is not an actor, in that it does not query or respond or transport in-band data.
(However, $SPEAKER must trust the owner of $DOMAIN, which approaches an equivalence.)
Uh... If by "speaker" you mean the issuer, the issuer is, by definition, the owner of the domain, and in sole control of the domain's DNSSEC keys.
* There is no specified in-band identification of $SPEAKER or $ASSET.
I wouldn't go that far... In the vast majority of cases, the asset will be physically present in front of the validator, and the issuer will be identified to the validator out-of-band, via the DNS label of the emblem.
However, as I said, there is a very vocal minority who want to apply emblems to assets which are domains, networks, and data. i.e. in-band assets. The categories of assets thus far identified are: "persons, places, things, information services, and digital data in transit or at rest." Domain names and networks (ASNs) have generally been thought to be either "things" or "information services," though there's no actual reason to put assets in different categories, as they're all treated the same: things which can be identified (not necessarily uniquely) within a hierarchical namespace.
* There is no implicit connection to any other records on the domain name. If example.com has a UNECE record saying "protected wetland", and a LOC record conveying geographic coordinates, this does not mean that the speaker is claiming that a protected wetland exists at that location. (Perhaps it _could_ be used that way, but this would have to be communicated to the consumer out of band.)
Well, that's kinda in the eye of the beholder... If you're a real estate title company, and you do a lookup which you expect to reveal the presence or absence of a digital emblem associated with a named or located spot (that part is all GEOPRIV), you're looking for a bundle of RRs at a label, and your validating client will try to read and understand all of them as, collectively, a digital emblem. There may be records that your particular client doesn't know how to interpret, which is fine. And if a web server were the asset being labeled, there would be, for instance, A and AAAA records at the label as well. But if the asset is a diplomatic pouch, or a wetland, it probably won't have any non-emblem records at its label.
Thoughts on that basis: - The absence of explicit in-band identifiers for $SPEAKER or $ASSET seems like a weakness.
It is a weakness shared by every use of the DNS. It is a weakness inherent to how the world works. If someone misremembers the name of a thing, and they way they misremember it is anticipatable, an attacker may be able to register a domain anticipating their mistake. This is not a problem which is very subject to in-band solutions.
For example, if the vendor of some DIEM-labeled equipment sells that brand to a different company, I might care to know which one published the UNECE record that I am relying on.
Remember that "you" are a customs agent, who identifies this stuff professionally, and have realm expertise which you apply all day, every day. What the emblem is doing is digitalizing information which would otherwise be faxed or stuffed in an envelope and stapled to the outside of a crate. We're transporting preexisting information digitally between preexisting issuers and validators, and giving them DNSSEC signatures as a value-add. We're not changing their existing business practices or telling them how to do their jobs. Just as we don't dictate the business or trust relationship between people who send email or use web sites or make video calls.
- It seems like it would be wisest not to use a DIEM domain for anything else.
In the general case, you're absolutely right. It's anticipated that most DIEM domains would be of the form bill-woodcock.individual.diem.pch.net, for instance. However, as I said, there is also a very vocal minority who want to attach emblems to assets which are in-band, and that is not a decision which will be walked back at this point. So there will definitely be emblems attached to some domain names, email servers, ASNs, etc. Which will either have other records at the same label (which really is fine), or will have pointers from "www.foo.int" to "www.server.diem.foo.int" or something. Though the reason for making that separation would likely have less to do with label hygiene than with moving the DIEM stuff all off into its own hierarchy which could be managed with tighter security, on its own infrastructure.
That way, it can easily be aliased by CNAME in the future.
Yes. By building on top of the DNS, we inherit a rich set of tools and very active security development.
If that were a rule, it would also help to expand the semantics: any other records on that name are also $SPEAKER talking about $ASSET.
If that were a rule, we'd be telling people how to use the DNS in a way which we do not, currently, and I don't think we want to bake any specific religion into the protocol.
- The Descriptor is UTF-8 and intended for human consumption. Does it need to be internationalized? Do we need a language tag?
When you say "descriptor" do you mean the DNS label by which the emblem is identified? This is just DNS. IDNs exist. TXT records and many encodings within them exist. We aren't really inventing new stuff. Which is the point of building on top of the DNS, DNSSEC, and DANE: we can build DIEM with only the very smallest shim of additional stuff, which includes these two RRtypes, and no protocol changes.
- I can imagine stamping this domain on physical goods as a QR code, but that would need a URI scheme. "diem://" perhaps?
The beauty of building on top of the DNS is that adding a URI scheme is unnecessary, since there won't be a further redirection. Aim the scanner, do one lookup if you're doing online validation, zero if you're doing offline validation, read what it says on the screen, and you're done. You don't have to use a URI to determine what to do with the response, there is no subsequent step. It's not like going to a web server or an email server; get your DNS response and you're done.
-Bill
OpenPGP_signature.asc
Description: OpenPGP digital signature
_______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
