Re: [Dance] [EXTERNAL] Re: [SCITT] Leveraging DNS in Digital Trust: Credential Exchanges and Trust Registries

[Orie Steele <[e-mail]>]

Inline:

On Fri, Jun 9, 2023 at 10:10 AM Antoine Delignat-Lavaud <[e-mail]>
wrote:

> I’m all for a DNS-based DID method, as unlike did:web it would be possible
> to audit a did:dns resolution by keeping the DNSSEC signatures and key
> chain. It is probably a good idea to only enable did:dns on DNSSEC zones,
> otherwise inconsistencies can be blamed on network attackers, DNS caches,
> etc.
>
>
>
> I don’t like using a very short prefix to find DID keys in TXT records.
> There are already too many ways to abuse cross-protocol ability to set TXT
> records (e.g. DKIM, ACME, SPF, etc)
>
>
>
> Given that there are several existing DNS record types for keys (DNSKEY,
> KEY, IPSECKEY, OPENPGPKEY, TLSA, TKEY), I would also prefer to re-use an
> existing standard rather than introduce yet another DNS record type. DNSKEY
> and TLSA are both decent option, through the later is designed for ASN.1
> encoded keys and is a bit annoying to convert with JWKS/CKS.
>

Yes, when I learned of what at protocol was doing, my first thought was
they could have just put their
https://www.w3.org/TR/did-core/#verification-relationships

Directly into the records, so resolution would be a pure function of
"dig"...

For example:

did:dig-example-method:vendor.example -> controller / subject ...
https://www.w3.org/TR/did-core/#did-controller /
https://www.w3.org/TR/did-core/#did-subject
did:dig-example-method:vendor.example#authentication-key (signing) ...
https://www.w3.org/TR/did-core/#authentication
did:dig-example-method:vendor.example#assertion-key  (signing)  ...
https://www.w3.org/TR/did-core/#assertion
did:dig-example-method:vendor.example#key-agreement (encryption)  ...
https://www.w3.org/TR/did-core/#key-agreement

Of course, this would be a "new" did method, but perhaps one more useful
than "did:plc".

There would also be limits on the size of keys stored in this manner (and
privacy issues for key metadata),
which is why it would be nice if COSE Key supports x5c / x5u... it does not:

https://www.iana.org/assignments/cose/cose.xhtml#key-common-parameters

Still, you could include JWKS that do, here is an example:
https://contoso.auth0.com/.well-known/jwks.json

Obviously putting the JWK directly into the record might cause us to wish
for smaller key representations... there are always "multi formats"...

- https://w3c.github.io/vc-data-integrity/#verification-material
- https://www.w3.org/TR/did-core/#verification-material

Personally, I would prefer COSE Key supported what JWK supports... and not
to take multi formats as a dependency.

OS


>
>
> Best,
>
> Antoine
>
>
>
>
>
> *From:* SCITT <[e-mail]> *On Behalf Of *Orie Steele
> *Sent:* Thursday, June 8, 2023 4:22 PM
> *To:* [e-mail]
> *Cc:* [e-mail]; [e-mail]; scitt <[e-mail]>
> *Subject:* [EXTERNAL] Re: [SCITT] Leveraging DNS in Digital Trust:
> Credential Exchanges and Trust Registries
>
>
>
> Original thread:
> https://mailarchive.ietf.org/arch/msg/dance/g0eSMxmZzb1ucsFtgkVkICV5Hh8/
>
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fdance%2Fg0eSMxmZzb1ucsFtgkVkICV5Hh8%2F&data=05%7C01%7Cantdl%40microsoft.com%7Cd090b78c3a4a4499a63808db68342650%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638218345468867932%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=V44MiJjKSt85QVoePlQJhn4d1Gj60HVB7mBUybxwsbE%3D&reserved=0>
> I read
> https://www.ietf.org/archive/id/draft-latour-dns-and-digital-trust-00.html
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-latour-dns-and-digital-trust-00.html&data=05%7C01%7Cantdl%40microsoft.com%7Cd090b78c3a4a4499a63808db68342650%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638218345468867932%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=XS4CcwWP9SBooeMsYwPL7pKlzZSAc0i0Jw5mhw8ULMk%3D&reserved=0>
>
>
> Previously I had read:
> - https://datatracker.ietf.org/doc/draft-mayrhofer-did-dns/
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-mayrhofer-did-dns%2F&data=05%7C01%7Cantdl%40microsoft.com%7Cd090b78c3a4a4499a63808db68342650%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638218345469024142%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=MRXm6gqrI0fdPLD1%2FXkRG1rsvlcXgbqwY0PgGziwyns%3D&reserved=0>
> - https://identity.foundation/.well-known/resources/did-configuration/
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fidentity.foundation%2F.well-known%2Fresources%2Fdid-configuration%2F&data=05%7C01%7Cantdl%40microsoft.com%7Cd090b78c3a4a4499a63808db68342650%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638218345469024142%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=el6evHnTtjnFasREelT1Ai3b%2F9Hr4YyQext2vcdfzv0%3D&reserved=0> (I'm
> co-author)
>
> I don't understand the role that "example-issuer.ca
> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fexample-issuer.ca%2F&data=05%7C01%7Cantdl%40microsoft.com%7Cd090b78c3a4a4499a63808db68342650%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638218345469024142%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=EVkmskvf9Ty%2BmEwOWE4qGDHt68Tna73hcgcyWb6IBmc%3D&reserved=0>"
> is playing in these records.
>
> Why is there a need to structure the record "key" to include CA
> information?
>
> Is https://datatracker.ietf.org/doc/draft-ietf-uta-rfc6125bis/
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-uta-rfc6125bis%2F&data=05%7C01%7Cantdl%40microsoft.com%7Cd090b78c3a4a4499a63808db68342650%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638218345469024142%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=u5J9mjjrEL0huA4aeLkzB7GbP5HnS03rkhV8rNklgjo%3D&reserved=0> relevant
> to this conversation?
>
> I wanted to share some related work, from BlueSky:
>
> They support linking https://www.w3.org/TR/did-core/
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2FTR%2Fdid-core%2F&data=05%7C01%7Cantdl%40microsoft.com%7Cd090b78c3a4a4499a63808db68342650%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638218345469024142%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=9xUk2xQG0iGQwOblIG94gcUmSew4oevUJeErF0OewgM%3D&reserved=0>
> to specific domains, this allows for the natural control of a domain to be
> used to establish the natural authority of an identifier,
>
> For example:
>
> dig -t txt _atproto.wyden.senate.gov
> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fatproto.wyden.senate.gov%2F&data=05%7C01%7Cantdl%40microsoft.com%7Cd090b78c3a4a4499a63808db68342650%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638218345469024142%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=bHHFaB5%2FAy%2Fuj6D%2BLd2maHxGPiR1PLurhuTmlYwlnAY%3D&reserved=0>
> | grep 'did=' | grep -o '"did=.*"' | jq -r 'split("=")[1]'
>
> https://github.com/w3c/did-spec-registries/pull/515
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fw3c%2Fdid-spec-registries%2Fpull%2F515&data=05%7C01%7Cantdl%40microsoft.com%7Cd090b78c3a4a4499a63808db68342650%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638218345469024142%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=SSNIjq3qC9iaW%2B2tpAq1PHScv6mYcxBhuHtB8KLPdgk%3D&reserved=0>
>
> I would like to see a standard way to link decentralized identifiers to
> domains documented somewhere at IETF.
>
> Including UTA & SCITT in case there are folks with relevant comments.
>
> Regards,
>
> OS
>
> --
>
>
>
>
> *ORIE STEELE*Chief Technology Officer
> www.transmute.industries
>
>
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftransmute.industries%2F&data=05%7C01%7Cantdl%40microsoft.com%7Cd090b78c3a4a4499a63808db68342650%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638218345469024142%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=1RRTFtUI15nKsuaQc8%2BIlPKs18PySUMcr0QyZviLE9Y%3D&reserved=0>
>


-- 


ORIE STEELE
Chief Technology Officer
www.transmute.industries

<https://transmute.industries>