Eliding some bits:
On Wed, Sep 9, 2026 at 7:35 PM Bill Woodcock
<[email protected]> wrote:
> > (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.
Most DNSSEC-signed domains are not signed by the registrant. (They
are signed by a contracted nameserver operator.)
In the case of DIEM, I wouldn't be surprised to see an even further
remove, where the DIEM records are published in a zone registered to a
DIEM specialist (operating under contract).
> > * 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.
Stickers sometimes get torn off, or put on the wrong boxes. A
cross-check record that says "this domain is about the item with UPC
12345" seems valuable. (Perhaps that can be encoded in a UNECE or ISO
record...)
> ... 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.
I'm fine with that, but then it needs to be specified. If this kind
of behavior is allowed, then it's actually unsafe to place a UNECE
record on the same name as arbitrary other RR types. Otherwise
someone could infer that your TLSA record's certificate is worth €5000
for customs purposes.
> > 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.
Perhaps, but it is usually remedied by the next layer. On the web,
you may wonder if "nissan.com" is Nissan Motors (it is not), and the
DNS will not answer this question, but the HTML <title> tag will.
In this case, there is no additional layer, so an indicator in this
layer would be appropriate.
> 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.
I'm just thinking about detecting accidental mixups and glitches.
> 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.
It would be interesting to see that sheet of paper. I suspect that in
addition to standard codepoints, it probably has some human-readable
metadata, at least including the issuer's name and a date.
> > - It seems like it would be wisest not to use a DIEM domain for
> > anything else.
>
> In the general case, you're absolutely right.
I would like to see that mentioned, at least as operational guidance,
in the draft.
> > 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.
>From your previous example, it sounds like some validators may
actually rely on this, so I'm not convinced it is safe to be lax.
> > - 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?
"Descriptor" is the name of the fourth field in each RR type in this
draft. The draft says it is UTF-8 (although it doesn't specify who
should enforce that).
> > - 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.
This presumes that your scanner can regard any QR code that
syntactically resembles a domain name as the DIEM domain. That's fine
for single-purpose tooling in a focused deployment, but it wouldn't
work for using a general-purpose smartphone QR code scanner.
Having a URI scheme would allow more multipurpose tooling, and would
help to clarify errors ("the DIEM domain is broken" vs. "this isn't a
DIEM tag").
--Ben
_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]
