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. Best, Antoine From: SCITT <scitt-boun...@ietf.org> On Behalf Of Orie Steele Sent: Thursday, June 8, 2023 4:22 PM To: da...@ietf.org Cc: jacques.lat...@cira.ca; uta@ietf.org; scitt <sc...@ietf.org> 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%2Fmailarchi ve.ietf.org%2Farch%2Fmsg%2Fdance%2Fg0eSMxmZzb1ucsFtgkVkICV5Hh8%2F&data=05%7C 01%7Cantdl%40microsoft.com%7Cd090b78c3a4a4499a63808db68342650%7C72f988bf86f1 41af91ab2d7cd011db47%7C1%7C0%7C638218345468867932%7CUnknown%7CTWFpbGZsb3d8ey JWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7 C%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%7C72f988bf86f141 af91ab2d7cd011db47%7C1%7C0%7C638218345468867932%7CUnknown%7CTWFpbGZsb3d8eyJW IjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%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%2Fdatatrack er.ietf.org%2Fdoc%2Fdraft-mayrhofer-did-dns%2F&data=05%7C01%7Cantdl%40micros oft.com%7Cd090b78c3a4a4499a63808db68342650%7C72f988bf86f141af91ab2d7cd011db4 7%7C1%7C0%7C638218345469024142%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiL CJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=MRXm6gqr I0fdPLD1%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%7Ca ntdl%40microsoft.com%7Cd090b78c3a4a4499a63808db68342650%7C72f988bf86f141af91 ab2d7cd011db47%7C1%7C0%7C638218345469024142%7CUnknown%7CTWFpbGZsb3d8eyJWIjoi MC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&s data=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-is suer.ca%2F&data=05%7C01%7Cantdl%40microsoft.com%7Cd090b78c3a4a4499a63808db68 342650%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638218345469024142%7CUnk nown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXV CI6Mn0%3D%7C3000%7C%7C%7C&sdata=EVkmskvf9Ty%2BmEwOWE4qGDHt68Tna73hcgcyWb6IBm c%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%2Fdatatrack er.ietf.org%2Fdoc%2Fdraft-ietf-uta-rfc6125bis%2F&data=05%7C01%7Cantdl%40micr osoft.com%7Cd090b78c3a4a4499a63808db68342650%7C72f988bf86f141af91ab2d7cd011d b47%7C1%7C0%7C638218345469024142%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDA iLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=u5J9mj jrEL0huA4aeLkzB7GbP5HnS03rkhV8rNklgjo%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.or g%2FTR%2Fdid-core%2F&data=05%7C01%7Cantdl%40microsoft.com%7Cd090b78c3a4a4499 a63808db68342650%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63821834546902 4142%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1 haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=9xUk2xQG0iGQwOblIG94gcUmSew4oevUJe ErF0OewgM%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.wy den.senate.gov%2F&data=05%7C01%7Cantdl%40microsoft.com%7Cd090b78c3a4a4499a63 808db68342650%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63821834546902414 2%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haW wiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=bHHFaB5%2FAy%2Fuj6D%2BLd2maHxGPiR1PLu rhuTmlYwlnAY%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.co m%2Fw3c%2Fdid-spec-registries%2Fpull%2F515&data=05%7C01%7Cantdl%40microsoft. com%7Cd090b78c3a4a4499a63808db68342650%7C72f988bf86f141af91ab2d7cd011db47%7C 1%7C0%7C638218345469024142%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQI joiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=SSNIjq3qC9ia W%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 <http://www.transmute.industries> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftransmute .industries%2F&data=05%7C01%7Cantdl%40microsoft.com%7Cd090b78c3a4a4499a63808 db68342650%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638218345469024142%7 CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiL CJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=1RRTFtUI15nKsuaQc8%2BIlPKs18PySUMcr0QyZv iLE9Y%3D&reserved=0>
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta
