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

[Arnaud Taddei <[e-mail]>]

+1 on 

> "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."

Arnaud Taddei
Global Security Strategist | Enterprise Security Group

mobile: [phone] 
Geneva, Switzerland
[e-mail] <mailto:[e-mail]> | broadcom.com

> On 3 Nov 2024, at 21:36, Eric Rescorla <[e-mail]> wrote:
> 
> 
> 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 <https://www.google.com/url?q=http://did.example-issuer.ca&source=gmail-imap&ust=1731274658000000&usg=AOvVaw1ZqenU3nqF74NQcYpUpOl_> IN URI 1 0 “did:web:example-issuer.ca <https://www.google.com/url?q=http://example-issuer.ca&source=gmail-imap&ust=1731274658000000&usg=AOvVaw2YS4iC3JTD6qTKFtyPdtse>”_*
> 
>    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/ <https://www.google.com/url?q=https://datatracker.ietf.org/doc/draft-carter-high-assurance-dids-with-dns/&source=gmail-imap&ust=1731274658000000&usg=AOvVaw1ogj06MGAolSgLugBTjbPq>
>>>  
>>> 
>>> 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/ <https://www.google.com/url?q=https://dhs-svip.github.io/requirements-for-decentralized-identity/TrustArchitecture/&source=gmail-imap&ust=1731274658000000&usg=AOvVaw3CKLhB9FM1v13XEhrWMfv_>
>>> ·         DID Specification Registries (w3c.github.io) <https://www.google.com/url?q=https://w3c.github.io/did-spec-registries/%23dnsvalidationdomain&source=gmail-imap&ust=1731274658000000&usg=AOvVaw34IbVkaMbfNTct5EGApM90>
>>> ·         Trust DID Web - The did:tdw DID Method (bcgov.github.io) <https://www.google.com/url?q=https://bcgov.github.io/trustdidweb/&source=gmail-imap&ust=1731274658000000&usg=AOvVaw2YLyJc19O8s3fS1dpEj07l>
>>>  
>>> 
>>> Example DNS implementation:
>>> 
>>>  
>>> 
>>> $ dig _did.trustroot.ca <https://www.google.com/url?q=http://did.trustroot.ca&source=gmail-imap&ust=1731274658000000&usg=AOvVaw1x9FVNlH8n_J85rAgA8ztb> uri +dnssec +multi
>>> 
>>>  
>>> 
>>> _did.trustroot.ca <https://www.google.com/url?q=http://did.trustroot.ca&source=gmail-imap&ust=1731274658000000&usg=AOvVaw1x9FVNlH8n_J85rAgA8ztb>.      3518 IN URI 0 0 "did:web:trustroot.ca <https://www.google.com/url?q=http://trustroot.ca&source=gmail-imap&ust=1731274658000000&usg=AOvVaw3j4bQYtHTFfyqTKusv6eNT>"
>>> 
>>> _did.trustroot.ca <https://www.google.com/url?q=http://did.trustroot.ca&source=gmail-imap&ust=1731274658000000&usg=AOvVaw1x9FVNlH8n_J85rAgA8ztb>.      3518 IN RRSIG URI 13 3 3600 (
>>> 
>>>                                 20240905000000 20240815000000 17999 trustroot.ca <https://www.google.com/url?q=http://trustroot.ca&source=gmail-imap&ust=1731274658000000&usg=AOvVaw3j4bQYtHTFfyqTKusv6eNT>.
>>> 
>>>                                 4CJsquY7BEcA2YX1iWHIKzXx4lEvWa7k8JWNbp4zu3dp
>>> 
>>>                                 KQXdwZ73geTKgzfNz9g5+HyckxTyNyz8LU8lA+G4lg== )
>>> 
>>>  
>>> 
>>> $ dig _did.trustroot.ca <https://www.google.com/url?q=http://did.trustroot.ca&source=gmail-imap&ust=1731274658000000&usg=AOvVaw1x9FVNlH8n_J85rAgA8ztb> tlsa +dnssec +multi
>>> 
>>>  
>>> 
>>> _did.trustroot.ca <https://www.google.com/url?q=http://did.trustroot.ca&source=gmail-imap&ust=1731274658000000&usg=AOvVaw1x9FVNlH8n_J85rAgA8ztb>.      3527 IN TLSA 3 1 1 (
>>> 
>>>                                 CEEAD59AAE176DDD8889DF0B02083CB393D07655CBA9
>>> 
>>>                                 D668EA334ABDBDB72A39 )
>>> 
>>> _did.trustroot.ca <https://www.google.com/url?q=http://did.trustroot.ca&source=gmail-imap&ust=1731274658000000&usg=AOvVaw1x9FVNlH8n_J85rAgA8ztb>.      3527 IN TLSA 3 1 0 (
>>> 
>>>                                 302A300506032B6570032100C300A443F0427440AC90
>>> 
>>>                                 BDA85B4F97896879564A7AB649B976FA7D15FEAFC225 )
>>> 
>>> _did.trustroot.ca <https://www.google.com/url?q=http://did.trustroot.ca&source=gmail-imap&ust=1731274658000000&usg=AOvVaw1x9FVNlH8n_J85rAgA8ztb>.      3527 IN RRSIG TLSA 13 3 3600 (
>>> 
>>>                                 20240905000000 20240815000000 17999 trustroot.ca <https://www.google.com/url?q=http://trustroot.ca&source=gmail-imap&ust=1731274658000000&usg=AOvVaw3j4bQYtHTFfyqTKusv6eNT>.
>>> 
>>>                                 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]>
> _______________________________________________
> Secdispatch mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]


-- 
This electronic communication and the information and any files transmitted 
with it, or attached to it, are confidential and are intended solely for 
the use of the individual or entity to whom it is addressed and may contain 
information that is confidential, legally privileged, protected by privacy 
laws, or otherwise restricted from disclosure to anyone else. If you are 
not the intended recipient or the person responsible for delivering the 
e-mail to the intended recipient, you are hereby notified that any use, 
copying, distributing, dissemination, forwarding, printing, or copying of 
this e-mail is strictly prohibited. If you received this e-mail in error, 
please return the e-mail to the sender, delete it from your computer, and 
destroy any printed copy of it.