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

[Jesse Carter <[e-mail]>]

Hey Eric, I appreciate your feedback. Hopefully I can provide some clarification on the points below.

We always sign the did documents, regardless of the did method. So did:web receives the same dataIntegrityProof treatment that any other did method does.

The URI record is used to indicate which dids are associated with that domain, by the domain. This prevents somebody from creating a DID and pointing it to a domain, and then requiring a resolver or someone interacting with the did to guess whether this association is being repudiated or not.

The contrast in the last statement is in comparison to DIDs without the added assurance of our DNS verification process. If a DID is claiming to be related to a given domain, but there is no way for the domain to repudiate or validate that association, that association cannot be taken seriously. This provides a way to affirm that association, while also duplicating the important information (PKI and ID) within the DID document across 2 completely separate sets of infrastructure, providing increased assurance that the information you are interacting with from that DID is what is intended, and indicating tampering or a potential issue when it doesn’t line up.



CLASSIFICATION:CONFIDENTIAL
From: Eric Rescorla <[e-mail]>
Sent: Sunday, November 3, 2024 4:37 PM
To: Rifaat Shekh-Yusef <[e-mail]>
Cc: Jacques Latour <Jacques.Latour=[e-mail]>; [e-mail]; Jesse Carter <[e-mail]>; Mathieu Glaude <[e-mail]>; Tim Bouma <[e-mail]>; Jim Fenton <[e-mail]>; Pengshuping (Peng Shuping) <[e-mail]>
Subject: [EXT] Re: [Secdispatch] Re: Request for Review and Adoption of Internet Draft: High Assurance DIDs with DNS

You don't often get email from [e-mail]<mailto:[e-mail]>. Learn why this is important<https://aka.ms/LearnAboutSenderIdentification>

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<http://did.example-issuer.ca> IN URI 1 0 “did:web:example-issuer.ca<http://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]<mailto:[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]<mailto:[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]<mailto:[e-mail]>>
Sent: August 28, 2024 4:30 PM
To: [e-mail]<mailto:[e-mail]>
Cc: Jacques Latour <[e-mail]<mailto:[e-mail]>>; Jesse Carter <[e-mail]<mailto:[e-mail]>>; Mathieu Glaude <[e-mail]<mailto:[e-mail]>>; Tim Bouma <[e-mail]<mailto:[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<http://did.trustroot.ca> uri +dnssec +multi

_did.trustroot.ca<http://did.trustroot.ca>.      3518 IN URI 0 0 "did:web:trustroot.ca<http://trustroot.ca>"
_did.trustroot.ca<http://did.trustroot.ca>.      3518 IN RRSIG URI 13 3 3600 (
                                20240905000000 20240815000000 17999 trustroot.ca<http://trustroot.ca>.
                                4CJsquY7BEcA2YX1iWHIKzXx4lEvWa7k8JWNbp4zu3dp
                                KQXdwZ73geTKgzfNz9g5+HyckxTyNyz8LU8lA+G4lg== )

$ dig _did.trustroot.ca<http://did.trustroot.ca> tlsa +dnssec +multi

_did.trustroot.ca<http://did.trustroot.ca>.      3527 IN TLSA 3 1 1 (
                                CEEAD59AAE176DDD8889DF0B02083CB393D07655CBA9
                                D668EA334ABDBDB72A39 )
_did.trustroot.ca<http://did.trustroot.ca>.      3527 IN TLSA 3 1 0 (
                                302A300506032B6570032100C300A443F0427440AC90
                                BDA85B4F97896879564A7AB649B976FA7D15FEAFC225 )
_did.trustroot.ca<http://did.trustroot.ca>.      3527 IN RRSIG TLSA 13 3 3600 (
                                20240905000000 20240815000000 17999 trustroot.ca<http://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]<mailto:[e-mail]>
To unsubscribe send an email to [e-mail]<mailto:[e-mail]>
_______________________________________________
Secdispatch mailing list -- [e-mail]<mailto:[e-mail]>
To unsubscribe send an email to [e-mail]<mailto:[e-mail]>