[Diem] Re: architectural considerations document

[Bill Woodcock <[e-mail]>]

Ok, that’s fine.  As long as it’s a question of DNSSEC or no authentication, rather than DNSSEC, no with, or some ambiguous number of other mechanisms implementers might need to bolt onto the side.  No need to reinvent the wheel. 

    

                -Bill

On Apr 28, 2026, at 15:37, Rohan Mahy <[e-mail]> wrote:



Bill, Alex,

We have use cases where authentication is not required. Hopefully it is sufficient to say that when emblems are looked up in the DNS and authentication is required, that DNSsec is the default/assumed authentication mechanism; DNSsec could also be used for other discovery mechanisms either in whole or in part.

Thanks,

-rohan

On Tue, 28 Apr 2026, 08:38 Bill Woodcock, <[e-mail]> wrote:

We do require DNSSEC, because it provides the digital signature which allows the validator to assure themselves of the validity of the record bundle. 

    

                -Bill

On Apr 28, 2026, at 12:31, Alex Rosenberg <[e-mail]> wrote:



(inline)

On Mar 22, 2026, at 1:16 AM, Felix Linker <[e-mail]> wrote:

Hi Alex,

Thanks for that doc. I think what you describe quite closely matches how our current prototypes work already (for reference https://github.com/adem-wg/adem-proto" target="_blank" rel="noreferrer nofollow">https://github.com/adem-wg/adem-proto).

We don't require DNSSEC, as it doesn't provide any additional security and because authorization (and thus extra validation steps) are necessary anyway.

How do we know that a DNS-provided emblem is not spoofed otherwise? I have been assuming DNSSEC is required.

I have some questions on your draft:

• In your Sec. 5, you mention a hierarchical structure, and you say that this "hierarchy is effectively a Merkle tree of chains of trust." Is it or is it just "effectively" - and what does the word "effectively" do here?

The Merkle tree is an emergent property of the result, not intended. None of the uses for that property that I’ve come up with seem worth pursing since we’re not making git or a ledger of NFTs.

• You also mention that "[s]igned fields are included in a cryptographic hash of the record." So will that hash be signed? I don't think you mention that. And what's the benefit of signing the hash vs just signing the record?

I would think the hash is only used when part of the hierarchy refers to another emblem for inclusion.

Alex

Cheers,

Felix

Am Mo., 16. März 2026 um 10:04 Uhr schrieb Alex Rosenberg <[e-mail]>:

I pushed this document up to datatracker the other day in hopes to facilitate conversation. I foolishly assumed that the email list would be notified of new documents being published. My apologies for not sending this notification prior to today’s meeting.

It primarily describes the mental model I’ve been forming of what DIEM might look like for the use cases we’ve already discussed.

https://datatracker.ietf.org/doc/draft-rosenberg-diem-architecture/" dir="ltr" role="button" width="300" target="_blank">

https://datatracker.ietf.org/doc/draft-rosenberg-diem-architecture/" target="_blank">Digital Emblems - Architectural Considerations https://datatracker.ietf.org/doc/draft-rosenberg-diem-architecture/" target="_blank">datatracker.ietf.org https://datatracker.ietf.org/doc/draft-rosenberg-diem-architecture/" target="_blank"><ietf-logo-nor-180.png>

Alex

_______________________________________________
Diem mailing list -- [e-mail]
To unsubscribe send an email to [e-mail]

_______________________________________________
Diem mailing list -- [e-mail]
To unsubscribe send an email to [e-mail]

_______________________________________________
Diem mailing list -- [e-mail]
To unsubscribe send an email to [e-mail]

_______________________________________________
Diem mailing list -- [e-mail]
To unsubscribe send an email to [e-mail]

_______________________________________________
Diem mailing list -- [e-mail]
To unsubscribe send an email to [e-mail]