]> AppViewX Inc

222 Broadway New York NY 10038 US Phone 2016063304 muralida@gmail.com URI www.appviewx.com.

Bank of New York Mellon

240 Greenwitch Street New York NY 10038 US anand2031@icloud.com URI

General Internet Engineering Task Force DNSSEC,CA,Trust Anchor,DNS Certificate Trust Stores are the foundation of trust, with Quantum threat looming updating trust anchors is a challenge for IOT and distributed devices. Using DNS as a foundation for trust since every communication uses DNS and DNSSEC to securely verify the domain resolution we use DNS to securely publish the Trust Store Content or update the trust anchors to be used to validate the TLS connection.

Introduction The Domain Name System (DNS) is essential for the proper functioning of the internet, serving as the foundational pillar of trust for every digital transaction. Each web page visited, email sent, and digital communication relies on DNS to translate human-friendly names into destination addresses. Certificates are another form of trust used to validate and verify endpoints like websites and servers, leveraging Public Key Cryptography or Public Key Infrastructure (PKI). Public keys or Certificate Authorities (CAs) are embedded in device trust stores or browsers to verify endpoint certificates deployed on servers or websites. In a zero trust environment or with a short lived certificate authority there is a need to dynamically provide or update trust stores or even present certificate used to validate the domains. For this DNS can be used as a foundation of trust by leveraging Domain Name System (DNS) CERT records which are DNSSEC signed to be used to validate the domain. Section 3 specifies a CERT resource record (RR) for the storage of certificates in the Domain Name System (DNS) as detailed in RFC 4398. Section 4 explains how Server Trust can be valdiated using Certificate from DNS.

Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

2. Problem Statement Trust anchors are used to support many application scenarios. Most Internet browsers and email clients use trust anchors when authenticating Transport Layer Security (TLS) sessions by validating a certification path to a server's certificate. Trust anchors that support these applications are typically installed as part of the operating system (OS) or application,installed using an enterprise configuration management system, or installed directly by an OS or application user. Trust anchors are typically stored in application-specific or OS-specific trust anchor stores.Often, a single machine may have a number of different trust anchor stores that may not be synchronized.Reviewing the contents of a particular trust anchor store typically involves use of a proprietary tool that interacts with a particular type of trust store. The presence of a trust anchor in a particular store often conveys implicit authorization to validate signatures for any contexts from which the store is accessed. If the store containing this TA is used by multiple applications that serve different purposes, the same key may be used (inappropriately) to validate other types of objects such as certificates or Online Certificate Status Protocol (OCSP) responses. Trust anchors are often represented as self-signed certificates,which provide no useful means of establishing the validity of the information contained in the certificate.Confidence in the integrity of a trust anchor is typically established through out-of-band means, often by checking the "fingerprint" (one-way hash) of the self-signed certificate with an authoritative source. Routine trust anchor rekey operations typically require similar out-of-band checks, though in-band rekey of a trust anchor is supported by the Certificate Management Protocol (CMP) RFC4210. Ideally, only the initial set of trust anchors are installed in a particular trust anchor store should require out-of-band verification, particularly when the costs of performing out-of-band checks commensurate with the security requirements of applications using the trust anchor store are high. Despite the prevalent use of trust anchors, there is neither a standard means for discovering the set of trust anchors installed in a particular trust anchor store nor a standard means of managing those trust anchors. The remainder of this document describes requirements for a solution to this problem using DNS and DNSSEC along with some security considerations.This specification is improve security and zero trust by improving access to public keys for end-to-end Transport Layer Security(TLS) communication. This document defines a unique way of using exsiting IETF standard to pass the public key using DNS CERT records that can be used to validate TLS connections. 2.1 Functional Requirement A general-purpose solution for the management of trust anchors MUST be common transport in order to apply to a range of device communications environments. It MUST work in session-oriented environments in a pull distribution model.It should provide integrity and data origin authentication for TA transactions MUST be provided at the application layer.Confidentiality MAY not be needed for such transactions since it is a public key information. 2.2 Solution Approach Using DNS as the foundation of trust Using DNS as the foundation of trust, explicit trust or Zero Trust is possible where the DNS domain owner publishes the Public Certificate used to sign their website or server certificate. With DNSSEC and using DNS CERT records, the owner can authoritatively validate and publish a CA issued public certificate with integrity and verifiable legitimacy.This enables verification of the DNS domain to the actual server. In turn, application level verification of the certificate is directly from the DNS name owners and ensures that the DNS names have the correct CAs verifying the certificates. Trust Anchor Management TLS clients can look up DNS for the domain CERT DNS record (RFC 4398) to retrieve the Trust Anchor that can be updated with a short Time-to-Live (TTL) value enabling short lived certificate authority support. The complete list of trusted certificates can be published with multiple CERT records based on application or enterprise top level domain. Publishing Certificate Authority Public Keys enables explicit trust with agility to switch and reduce Certificate Authority and Certificate validity aimed at reducing future Quantum computing threats and enabling Zero Trust.

3. DNS CERT Records RFC 4398 details CERT resource records structure. With the specification defined the Servers public key or possibly root certificate to validate the chain can be publised on the same domains name with CERT records. For example example.com. can have an A record and a CERT record and the CERT record can have the certificate used to validate the domain. DNS Security Extensions (commonly called "DNSSEC") that are specified in RFCs 9364 is a pre-requsite must have for this since the certificate is used to validate the domains. DNSSEC uses digital signatures based on public key cryptography to sign responses by the domain owner. It serves two primary functions: Data Origin Authentication: This allows resolvers/clients to cryptographically verify that the responses actually originate from the owner of the DNS name. Data Integrity Protection: This enables resolvers/clients to verify that the data has not been altered during transit. Example: example.com. 296 IN CERT 0 0 0 ( MIIB8zCCAZmgAwIBAgITQMvCiTnXkcxee5eiUrzKJIna8TAKBggqhkjOPQQD+MREwDwYDVQQKEwhBcHB2aWV3eDELMAkGA1UECxMCSVQxHDAaBgNVBAMTE0lULUFWWC1Sb290LUdDQVMtRUMwHhcNMjMwNTExMDc1MDIyWhcNMzMwNTA4MDc1MDI+MREwDwYDVQQKEwhBcHB2aWV3eDELMAkGA1UECxMCSVQxHDAaBgNVBAMTE0lULUFWWC1Sb290LUdDQVMtRUMwWTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAATkccapehNjCA3Hgjj+XLxFQayMtDUUHi3+fO5OgGa36llwn6QPWKhXxNNK+x+Y3QrDWPq0IK8j0jopoBo3YwdDAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0TAQ/BAUwAw/zAdBgNVHQ4EFgQUNPcUdSNHNjLULpkUMEJ4sUjbtIwHwYDVR0jBBgwFoAUNPcUdSNHNjLULpkUME4J4sUjbtIwEQYDVR0gBAowCDAGBgRVHSAAMAoGCCqGSM49BAMCA0gAMEUCIQCZ6ZgBMr+ir2Fzu192+RFMuLqV973KaiDvSOVuf2gIgXkcYJB79bIqBvzJFssuAanEBLhGF+O9grlxPNNeLdU= ) example.com. 296 IN RRSIG CERT 13 3 300 ( 20240522233005 20240520213005 34505 example.com. ZttZh6XV3HbFYWyztXOQrznMlphJzlmuFmObE1JqXCmh14MC69bxxsjsE5fX6kGkmTn4gaNR01kLg+z1Jl7A== ) the same can be used to validate the connection.

4. TLS Server Validation with DNS CERT Certificates Digital signatures are used in many applications. For digital signatures to provide integrity and authentication, the public key used to verify the digital signature must be "trusted", i.e.,accepted by a relying party (RP) as appropriate for use in the given context. A public key used to verify a signature must be configured as a trust anchor (TA) or contained in a certificate that can be transitively verified by a certification path terminating at a trust anchor. A trust anchor is a public key and associated data used by a relying party to validate a signature on a signed object where the object is either: o a public key certificate that begins a certification path terminated by a signature certificate or encryption certificate o an object, other than a public key certificate or certificate revocation list (CRL), that cannot be validated via use of a certification path Trust anchors have only local significance, i.e., each RP is configured with a set of trust anchors, either by the RP or by an entity that manages TAs in the context in which the RP operates. The associated data defines the scope of a trust anchor by imposing constraints on the signatures that the trust anchor may be used to verify. For example, if a trust anchor is used to verify signatures on X.509 certificates, these constraints may include a combination of name spaces, certificate policies, or application/usage types. All applications that rely upon digital signatures rely upon some means of managing one or more sets of trust anchors. Each set of trust anchors is referred to in this document as a trust anchor store. Trust Anchor: A trust anchor represents an authoritative entity via a public key and associated data. The public key is used to verify digital signatures, and the associated data is used to constrain the types of information for which the trust anchor is authoritative. A relying party uses trust anchors to determine if a digitally signed object is valid by verifying a digital signature using the trust anchor's public key, and by enforcing the constraints expressed in the associated data for the trust anchor. In this new approach during the TLS communication while the client can looks up DNS name of the target server for IP address it can also lookup for a CERT record which is DNSSEC validated and use the CERT record to validate the integrity and authenticate the server if its appropriate. This use case is primarily useful in case of internet facing Internet of Things Deployments like Smart Meters, Connected Cars where Crypto Agility is a requirement due to the threat of Quantum Computers. These can be implemented by updating the TLS clients and DNS clients with updated steps to look up for the right certificates.

IANA Considerations This memo includes no request to IANA.

Security Considerations This document should not affect the security of the Internet. It can be extended to all TLS connections if the browsers accept the updated trust anchors. DNSSEC keys have to be updated with quantum safe algorithms for this to be considered quantum safe communication

References Normative References

Acknowledgements This template uses extracts from templates written by Pekka Savola, Elwyn Davies and Henrik Levkowetz. It uses contents from RFC 6024 Trust Anchor Management, RFC 4398 Storing Certificates in DNS

Contributors Thanks to all of the contributors. Thanks to Claudine Ramocan for the solution discussions Thanks to Ganesh Gopalan and Asif Karel for validating the solution Thanks to Marin Cosmin Stefan for reviewing the solution