[Secdispatch] Re: Request for Review and Adoption of Internet Draft: High Assurance DIDs with DNS

[Eric Rescorla <[e-mail]>]

DISPATCH COMMENTS
I do not think that the IETF is the proper location for this
document. DIDs are not an IETF product and there's very little
IETF-specific in this WG. The appropriate place for this work is in
the W3C DID WG. I might feel differently if the W3C were to sendd us a
liaison statement asking us to pick up this work.


TECHNICAL COMMENTS

* did:web
I understand the design you have for did:X where X != Web, where
there is a signature from some key that is in the DNS. But
with did:web, it seems like instead the key is being used to
validate the TLS connection to the Web server? This seems
quite a bit weaker. Why not sign all th time?

* DNSSEC
I think this really needs to require DNSSEC all the time. I
have concerns about the deployability of DNSSEC, but I don't
see how this mechanism adds real safety without that.

S 3.3.
   The association to a domain stemming only from the did is
   unidirectional.  By leveraging URI records as outlined in
   [DID-in-the-DNS], we can create a bidirectional relationship,
   allowing a domain to publish their associated DID in the DNS.

   *_Ex: _did.example-issuer.ca IN URI 1 0 “did:web:example-issuer.ca”_*

   This relationship enhances security, as an entity would require
   control over both the DID and the domain’s DNS server to create this
   bidirectional association, reducing the likelihood of malicious
   impersonation.

I don't follow how this works. Once you are signing using a key
in the DNS, how does this new record help?


S 3.4.3.

   Hosting the public keys in TLSA records provides a stronger mechanism
   for the verifier to verify a did and its associated entity with, as
   they are able to perform a cryptographic challenge against the DID
   using the corresponding TLSA records, or against the domain using the
   corresponding [verificationMethod] in the DID document.  The
   accessibility of the public keys is also beneficial, as the verifier
   does not need to resolve the DID document to accesss its associated
   key material, enhancing interoperability.

I'm not sure what you are contrasting hosting the keys in DNS to. Can you
expand.





On Mon, Sep 9, 2024 at 10:44 AM Rifaat Shekh-Yusef <[e-mail]>
wrote:

> Thanks Jacques!
> We will add it to the list of topics to discuss.
> Will you be attending in person or remote?
>
> Regards,
>  Rifaat
>
>
> On Thu, Aug 29, 2024 at 8:57 AM Jacques Latour <Jacques.Latour=
> [e-mail]> wrote:
>
>> Hi,
>>
>>
>>
>> ACME recommended this should be sent here for considerations.
>>
>>
>>
>> Looking forward to see what you think and where home is 😉.
>>
>>
>>
>> Jacques
>>
>>
>>
>>
>>
>> *From:* Jacques Latour <[e-mail]>
>> *Sent:* August 28, 2024 4:30 PM
>> *To:* [e-mail]
>> *Cc:* Jacques Latour <[e-mail]>; Jesse Carter <
>> [e-mail]>; Mathieu Glaude <[e-mail]>; Tim
>> Bouma <[e-mail]>
>> *Subject:* Request for Review and Adoption of Internet Draft: High
>> Assurance DIDs with DNS
>>
>>
>>
>> Hi all!
>>
>>
>>
>> First time asking for an internet draft adoption.
>>
>>
>>
>> ·
>> https://datatracker.ietf.org/doc/draft-carter-high-assurance-dids-with-dns/
>>
>>
>>
>> As one of the authors of the internet draft titled "High Assurance DIDs
>> with DNS" (draft-carter-high-assurance-dids-with-dns), I am writing to
>> request the ACME Working Group to review and consider adopting this draft
>> as part of your working group.
>>
>>
>> The draft proposes a method for integrating high assurance Decentralized
>> Identifiers (DIDs) with the Domain Name System (DNS), aiming to enhance the
>> security and reliability of DIDs by leveraging the established trust
>> infrastructure of DNS. We believe that this integration aligns well with
>> the goals and expertise of the ACME Working Group, particularly in the
>> areas of secure and automated certificate management.
>>
>> We would greatly appreciate the opportunity to present this draft to the
>> working group and discuss its potential benefits and implementation
>> details. Your feedback and guidance would be invaluable in refining the
>> draft and ensuring its alignment with the broader objectives of the IETF.
>>
>> Please let us know if there are any specific procedures or additional
>> information required for this request. We are eager to collaborate with the
>> ACME Working Group and contribute to the advancement of secure and reliable
>> internet standards.
>>
>> In terms of support and reference for this draft, we have the following
>> references that may help justify our ask.
>>
>>
>>
>> ·
>> https://dhs-svip.github.io/requirements-for-decentralized-identity/TrustArchitecture/
>>
>> ·         DID Specification Registries (w3c.github.io)
>> <https://w3c.github.io/did-spec-registries/#dnsvalidationdomain>
>>
>> ·         Trust DID Web - The did:tdw DID Method (bcgov.github.io)
>> <https://bcgov.github.io/trustdidweb/>
>>
>>
>>
>> Example DNS implementation:
>>
>>
>>
>> $ dig _did.trustroot.ca uri +dnssec +multi
>>
>>
>>
>> _did.trustroot.ca.      3518 IN URI 0 0 "did:web:trustroot.ca"
>>
>> _did.trustroot.ca.      3518 IN RRSIG URI 13 3 3600 (
>>
>>                                 20240905000000 20240815000000 17999
>> trustroot.ca.
>>
>>
>> 4CJsquY7BEcA2YX1iWHIKzXx4lEvWa7k8JWNbp4zu3dp
>>
>>
>> KQXdwZ73geTKgzfNz9g5+HyckxTyNyz8LU8lA+G4lg== )
>>
>>
>>
>> $ dig _did.trustroot.ca tlsa +dnssec +multi
>>
>>
>>
>> _did.trustroot.ca.      3527 IN TLSA 3 1 1 (
>>
>>
>> CEEAD59AAE176DDD8889DF0B02083CB393D07655CBA9
>>
>>                                 D668EA334ABDBDB72A39 )
>>
>> _did.trustroot.ca.      3527 IN TLSA 3 1 0 (
>>
>>
>> 302A300506032B6570032100C300A443F0427440AC90
>>
>>
>> BDA85B4F97896879564A7AB649B976FA7D15FEAFC225 )
>>
>> _did.trustroot.ca.      3527 IN RRSIG TLSA 13 3 3600 (
>>
>>                                 20240905000000 20240815000000 17999
>> trustroot.ca.
>>
>>
>> z/E+jECtQzNi0zcBcrVa8P8UKiHx5SHcSEmN2vR6Oe4t
>>
>>
>> nfvjso/8/ZXo/IlWtoqgIYrCeJJ9NLFTu/q0cGwUIg== )
>>
>>
>>
>> Thank you for your time and consideration.
>>
>> Best regards,
>>
>> Jacques, Jesse, Mathieu and Tim.
>>
>>
>>
>>
>>
>>
>>
>> CLASSIFICATION:CONFIDENTIAL
>> _______________________________________________
>> Secdispatch mailing list -- [e-mail]
>> To unsubscribe send an email to [e-mail]
>>
> _______________________________________________
> Secdispatch mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>