Subject: [Danish] Proposed DANISH charter

From: Ash Wilson <[email-masked]>
Date: Wed, 12 May 2021 14:35:37 -0700

Hello everyone,

Together with the BoF chairs, a few of us have been discussing what a
charter for this working group might look like. We are pleased to present
the following for your consideration:

-----
Objective
DANE’s original purpose only covered the coupling of PKI and DNS for server
identity. The DANISH working group seeks to extend the DANE standard to
encompass client identity and message sender identity use cases. DANISH
also seeks to define a transitional mode for DANE, which will allow the
safe adoption of DANE for domain owners who have not yet implemented
DNSSEC..

Problem statement
Using DANE for representing client identities safely allows authentication
across CAs and prevents impersonation, because DNSSEC is used instead of a
CA certificate and its associated trust hierarchy to bind an identity’s
name to a public key. Everyone agrees on the DNS namespace and the DNS root
zone’s DNSSEC trust anchor, eliminating the barrier to adoption for
multiple private PKIs participating in application deployment.

The greatest barrier to DANE adoption has been the DNSSEC requirement.
DANISH will seek to provide a method of certificate and trust chain
discovery for private PKIs, to enable the messaging security use case. This
alternative mode will allow the use of  Web PKI to securely discover
certificates, in the absence of DNSSEC. This allows for a gradual DANE
adoption where DNSSEC is not in the initial set of requirements. If the
application owner wishes to use DANE for mutual TLS authentication, the
application owner must then configure DNSSEC for the zone.

Scope of work
The DANISH group will produce an architecture document describing the
primary application components, and their interaction patterns. DANISH will
establish usage conventions for DANE DNS records to represent client
identity for TLS connections and how to perform public key discovery for
object security use cases. DANISH will also define any required TLS
protocol updates to support client authentication using DANE. DANISH will
define a method whereby Web PKI may be used in lieu of DNSSEC, using DANE
DNS record types under specific use cases, as a transitional mode from Web
PKI to the DNSSEC-based trust model.

While modifications to the following standards are not within the scope of
the DANISH charter, the DANISH working group will take care to ensure a
potential path for interoperability with the following standards, enabling
potential future work: JOSE, COSE, Oauth2, MLS, EAP-TLS, SMIMEA (RFC 8162),
SIP (RFC 5922), Proxy headers (RFC 7239), IANA email authentication
headers, and TCP proxy TLVs standardized by haproxy.

-- 

*Ash Wilson* | Technical Director
*e:* [email-masked]

This email and all data transmitted with it contains confidential and/or
proprietary information intended solely for the use of individual(s)
authorized to receive it. If you are not an intended and authorized
recipient you are hereby notified of any use, disclosure, copying or
distribution of the information included in this transmission is prohibited
and may be unlawful. Please immediately notify the sender by replying to
this email and then delete it from your system.

---

From: Paul Wouters <[email-masked]>
Date: Wed, 12 May 2021 21:47:58 -0400 (EDT)

On Wed, 12 May 2021, Ash Wilson wrote:

> DANE’s original purpose only covered the coupling of PKI and DNS for server identity.

Please change to "only covered authentication for the TLS server identity".

The term PKI is loaded, as DANE is a PKI that works as alternative to WebPKI,
but the DANE standard was forced to add support for WebPKI validation.

> which will allow the safe adoption of DANE for domain owners who have not yet implemented DNSSEC..

This is confusing. DANE stands for "DNS-Based Authentication of Named Entities". There is only
one DNS-Based Authentication and that is DNSSEC. I think it would be
more fair to say you are looking at two different methods, one using
authenticated DNS and one using a non-DNS authentication method. That
second matter is not DANE (and not DANEish either, it has nothing to do
with DANE)

> Problem statement
> Using DANE for representing client identities safely allows authentication across CAs and prevents impersonation, because DNSSEC is
> used instead of a CA certificate and its associated trust hierarchy to bind an identity’s name to a public key. Everyone agrees on
> the DNS namespace and the DNS root zone’s DNSSEC trust anchor, eliminating the barrier to adoption for multiple private PKIs
> participating in application deployment.
> 
> The greatest barrier to DANE adoption has been the DNSSEC requirement. DANISH will seek to provide a method of certificate and
> trust chain discovery for private PKIs, to enable the messaging security use case.

The amount of draft/RFC pages written to avoid using DNSSEC is ever
increasing. At some point it reaches more pages than the DNSSEC
standard. With DoH and DoT, the issue of reaching a reliable DNSSEC
capable server has been largely solved.

> This alternative mode will allow the use of  Web
> PKI to securely discover certificates, in the absence of DNSSEC. This allows for a gradual DANE adoption where DNSSEC is not in the
> initial set of requirements. If the application owner wishes to use DANE for mutual TLS authentication, the application owner must
> then configure DNSSEC for the zone.

This is also really confusing. What CA would the TLS client use for its
mutual TLS authentication? Either it is a private one (eg non-webpki)
that _requires_ anchoring in DNSSEC, or it is some semi-private but
webpki verified CA, which honestly is just WebPKI as-is.

> Scope of work
> The DANISH group will produce an architecture document describing the primary application components, and their interaction
> patterns. DANISH will establish usage conventions for DANE DNS records to represent client identity for TLS connections and how to
> perform public key discovery for object security use cases. DANISH will also define any required TLS protocol updates to support
> client authentication using DANE. DANISH will define a method whereby Web PKI may be used in lieu of DNSSEC, using DANE DNS record
> types under specific use cases, as a transitional mode from Web PKI to the DNSSEC-based trust model.

So you are bootstrapping webpki via unsigned DANE DNS records? That
seems dangerous. DANE was never meant to be used without DNSSEC.

Originally, I thought DANISCH was about providing identities to TLS
clients to compliment authentiation of TLS servers. But now I read
the charter as a work around for somehow adding external trust parties
to the DNS to replace or augment DNSSEC. That has me worried.

I think what really needs clarification is if you are working on mutual
authenticated TLS only, or working on some other things. If working on
mutual TLS only, I do not see the case for a DNSSEC-non-DNSSEC protocol.

Paul

---

From: Jacques Latour <[email-masked]>
Date: Thu, 13 May 2021 13:42:21 +0000

I agree w/Paul, mutual TLS connection & DNSSEC enabled entities, and perhaps add a scope in the charter to address potential scaling of identities in the DNS, we should consider the impacts of having billions of IoT devices that have their identities in the DNS.

CLASSIFICATION:CONFIDENTIAL

-----Original Message-----
From: Danish <[email-masked]> On Behalf Of Paul Nohats
Sent: May 12, 2021 9:48 PM
To: Ash Wilson <ash.wilson=[email-masked]>
Cc: [email-masked]
Subject: [EXT] Re: [Danish] Proposed DANISH charter

On Wed, 12 May 2021, Ash Wilson wrote:

> DANE¢s original purpose only covered the coupling of PKI and DNS for server identity.

The term PKI is loaded, as DANE is a PKI that works as alternative to WebPKI, but the DANE standard was forced to add support for WebPKI validation.

> which will allow the safe adoption of DANE for domain owners who have not yet implemented DNSSEC..

This is confusing. DANE stands for "DNS-Based Authentication of Named Entities". There is only one DNS-Based Authentication and that is DNSSEC. I think it would be more fair to say you are looking at two different methods, one using authenticated DNS and one using a non-DNS authentication method. That second matter is not DANE (and not DANEish either, it has nothing to do with DANE)

> Problem statement
> Using DANE for representing client identities safely allows 
> authentication across CAs and prevents impersonation, because DNSSEC 
> is used instead of a CA certificate and its associated trust hierarchy 
> to bind an identity¢s name to a public key. Everyone agrees on the DNS namespace and the DNS root zone¢s DNSSEC trust anchor, eliminating the barrier to adoption for multiple private PKIs participating in application deployment.
> 
> DANISH will seek to provide a method of certificate and trust chain discovery for private PKIs, to enable the messaging security use case.

The amount of draft/RFC pages written to avoid using DNSSEC is ever increasing. At some point it reaches more pages than the DNSSEC standard. With DoH and DoT, the issue of reaching a reliable DNSSEC capable server has been largely solved.

> This alternative mode will allow the use of  Web PKI to securely 
> discover certificates, in the absence of DNSSEC. This allows for a 
> gradual DANE adoption where DNSSEC is not in the initial set of 
> requirements. If the application owner wishes to use DANE for mutual TLS authentication, the application owner must then configure DNSSEC for the zone.

This is also really confusing. What CA would the TLS client use for its mutual TLS authentication? Either it is a private one (eg non-webpki) that _requires_ anchoring in DNSSEC, or it is some semi-private but webpki verified CA, which honestly is just WebPKI as-is.

> primary application components, and their interaction patterns. DANISH 
> will establish usage conventions for DANE DNS records to represent 
> client identity for TLS connections and how to perform public key 
> discovery for object security use cases. DANISH will also define any required TLS protocol updates to support client authentication using DANE. DANISH will define a method whereby Web PKI may be used in lieu of DNSSEC, using DANE DNS record types under specific use cases, as a transitional mode from Web PKI to the DNSSEC-based trust model.

So you are bootstrapping webpki via unsigned DANE DNS records? That seems dangerous. DANE was never meant to be used without DNSSEC.

Originally, I thought DANISCH was about providing identities to TLS clients to compliment authentiation of TLS servers. But now I read the charter as a work around for somehow adding external trust parties to the DNS to replace or augment DNSSEC. That has me worried.

I think what really needs clarification is if you are working on mutual authenticated TLS only, or working on some other things. If working on mutual TLS only, I do not see the case for a DNSSEC-non-DNSSEC protocol.

Paul

--
Danish mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/danish

---

From: Ash Wilson <[email-masked]>
Date: Tue, 18 May 2021 13:21:30 -0700

Hey Paul,
Thanks for your feedback, responses in-line below...

> but the DANE standard was forced to add support for WebPKI validation.
Ok, no problem. I'll make that change.

> second matter is not DANE (and not DANEish either, it has nothing to do
For the limited set of use cases we're recommending for the transitional
mode, DNS still remains the authentication system's namespace and discovery
mechanism. The PKI used for authenticating discovered CA certificates is
Web PKI instead of DNSSEC.

> authentication across CAs and prevents impersonation, because DNSSEC is
> > used instead of a CA certificate and its associated trust hierarchy to
> bind an identity’s name to a public key. Everyone agrees on
> > the DNS namespace and the DNS root zone’s DNSSEC trust anchor,
> eliminating the barrier to adoption for multiple private PKIs
> DANISH will seek to provide a method of certificate and
I understand the frustration with the lack of DNSSEC adoption, and I agree
with you that it is easier and safer to adopt than in the past.
Unfortunately, adoption remains abysmal. We expect that by adding this
transitional mode in the adoption path for DANE, it will incentivize the
eventual adoption of DNSSEC.

> > PKI to securely discover certificates, in the absence of DNSSEC. This
> allows for a gradual DANE adoption where DNSSEC is not in the
> > initial set of requirements. If the application owner wishes to use DANE
> for mutual TLS authentication, the application owner must
The use cases we're looking at for the transitional mode center around
discovering private PKI entity and CA certificates. The pattern we are
exploring has the entity certificate in the TLSA record and the CA
certificate discoverable via HTTPS.

> primary application components, and their interaction
> > patterns. DANISH will establish usage conventions for DANE DNS records
> to represent client identity for TLS connections and how to
> > perform public key discovery for object security use cases. DANISH will
> also define any required TLS protocol updates to support
> > client authentication using DANE. DANISH will define a method whereby
> Web PKI may be used in lieu of DNSSEC, using DANE DNS record
The transitional mode use cases for entity and CA certificate discovery
don't involve changes to the TLS library. An example use case for this mode
is the discovery of entity certificates for authenticating signed telemetry
in decoupled applications.
DANE client identity support within the TLS handshake requires DNSSEC, and
we're looking to establish that pattern via the client ID and client
certificate drafts. So if an organization wants to transition from
certificate discovery use cases to having DANE client identity support in
the TLS protocol, they'll have to take the final step and implement DNSSEC.

--

---

From: Ash Wilson <[email-masked]>
Date: Tue, 18 May 2021 13:32:37 -0700

Hi Jacques,
I'll make the change for specifying TLS server authentication. I also agree
that we should investigate the impact of placing large volumes of client
identities in DNS.
I have done some initial feasibility testing using RIPE ATLAS. However,
that research was geared toward understanding the deliverability of DNS
records containing full certificates across the world, and not necessarily
load testing for intermediate infrastructure.

On Thu, May 13, 2021 at 6:42 AM Jacques Latour <[email-masked]>
wrote:

> I agree w/Paul, mutual TLS connection & DNSSEC enabled entities, and
> perhaps add a scope in the charter to address potential scaling of
> identities in the DNS, we should consider the impacts of having billions of
> IoT devices that have their identities in the DNS.
>
>
> The term PKI is loaded, as DANE is a PKI that works as alternative to
> WebPKI, but the DANE standard was forced to add support for WebPKI
> validation.
>
> This is confusing. DANE stands for "DNS-Based Authentication of Named
> Entities". There is only one DNS-Based Authentication and that is DNSSEC. I
> think it would be more fair to say you are looking at two different
> methods, one using authenticated DNS and one using a non-DNS authentication
> method. That second matter is not DANE (and not DANEish either, it has
> nothing to do with DANE)
>
> > Problem statement
> > to bind an identity¢s name to a public key. Everyone agrees on the DNS
> namespace and the DNS root zone¢s DNSSEC trust anchor, eliminating the
> barrier to adoption for multiple private PKIs participating in application
> deployment.
> >
> discovery for private PKIs, to enable the messaging security use case.
>
> increasing. At some point it reaches more pages than the DNSSEC standard.
> With DoH and DoT, the issue of reaching a reliable DNSSEC capable server
> has been largely solved.
>
> > requirements. If the application owner wishes to use DANE for mutual TLS
> authentication, the application owner must then configure DNSSEC for the
> zone.
>
> mutual TLS authentication? Either it is a private one (eg non-webpki) that
> _requires_ anchoring in DNSSEC, or it is some semi-private but webpki
> verified CA, which honestly is just WebPKI as-is.
>
> > Scope of work
> > discovery for object security use cases. DANISH will also define any
> required TLS protocol updates to support client authentication using DANE.
> DANISH will define a method whereby Web PKI may be used in lieu of DNSSEC,
> using DANE DNS record types under specific use cases, as a transitional
> mode from Web PKI to the DNSSEC-based trust model.
>
> So you are bootstrapping webpki via unsigned DANE DNS records? That seems
> dangerous. DANE was never meant to be used without DNSSEC.
>
> clients to compliment authentiation of TLS servers. But now I read the
> charter as a work around for somehow adding external trust parties to the
> DNS to replace or augment DNSSEC. That has me worried.
>

--

---

From: Paul Wouters <[email-masked]>
Date: Tue, 18 May 2021 17:52:31 -0400 (EDT)

> Ok, no problem. I'll make that change. 

Thanks.

> For the limited set of use cases we're recommending for the transitional mode, DNS still remains the authentication
> system's namespace and discovery mechanism. The PKI used for authenticating discovered CA certificates is Web PKI
> instead of DNSSEC. 

If you are authenticating "discovered CA certificates" with webpki, you
must have a preloaded list of webpki acceptable CA certificates ? So if
you have that, can't a TLS client with EEcert signed by a "discovered CA
cert" already connect with the current protcols and technologies? What
use case is currently not covered that you want DANISH to cover?

> I understand the frustration with the lack of DNSSEC adoption, and I agree with you that it is easier and safer to adopt
> than in the past. Unfortunately, adoption remains abysmal. We expect that by adding this transitional mode in the
> adoption path for DANE, it will incentivize the eventual adoption of DNSSEC.

I'm not sure why DANISH wouldn't be treated equally to DANE and be
ignored. Any "transitional" mode that offers webpki will be the final
mode, with CT or something else bolted on top.

> The use cases we're looking at for the transitional mode center around discovering private PKI entity and CA
> certificates. The pattern we are exploring has the entity certificate in the TLSA record and the CA certificate
> discoverable via HTTPS.

Hmm. So you are thinking of somehow using TLSA records, without DNSSEC
protection, to publish CA certs, that will then need to somehow link
back to webpki. I don't think the HTTPS servers are going to do any
kind of DNS lookup (let alone DNSSEC lookups) and will just have the
CA's allowed hardcoded.

> The transitional mode use cases for entity and CA certificate discovery don't involve changes to the TLS library. An
> example use case for this mode is the discovery of entity certificates for authenticating signed telemetry in decoupled
> applications.
> DANE client identity support within the TLS handshake requires DNSSEC, and we're looking to establish that pattern via
> the client ID and client certificate drafts. So if an organization wants to transition from certificate discovery use
> cases to having DANE client identity support in the TLS protocol, they'll have to take the final step and implement
> DNSSEC.

Okay. Thanks for the clarification. I do wish you look with this moving
DNSSEC deployment forward, but I don't see this based on the charter
text or your explanations. But I also wouldn't stand in your way of
trying.

I do think it would be better for the IETF to take a stance on DNSSEC
and make it mandatory to implement, so we can phase out unsigned DNS.
If I see the amount of data currently in DNS (eg do a dig txt cnn.com)
and with things like the proposed SVCB records, and any linking of
pubkey materials in hiding/encrypting the SNI using DNS, it is proper
for the IETF to state that DNSSEC is just a mandatory part of DNS. But
that's not a problem for DANISH to solve.

Paul

---

From: Ash Wilson <[email-masked]>
Date: Tue, 18 May 2021 18:44:26 -0700

Hey Paul,

Thanks for your input here. I hope you'll keep the feedback coming as we
dig into the drafts as well.
Responses in-line below...

On Tue, May 18, 2021 at 2:52 PM Paul Wouters <[email-masked]> wrote:

> mode, DNS still remains the authentication
> > system's namespace and discovery mechanism. The PKI used for
> authenticating discovered CA certificates is Web PKI
> > instead of DNSSEC.
>

IoT devices shouldn't necessarily present browser-trusted certificates.
Also, getting certificates that validate to the WebPKI are typically more
expensive... Letsencrypt being an exception to that rule, but with some
challenges for bootstrapping IoT device identity.
We want organizations to be able to use private PKI and lessen the
associated interoperability challenges. If you look at the proposed naming
pattern (device123._device.organization.example), we have an underscore in
the identity type label that makes the devices' DNS name ineligible for
WebPKI, and that's intentional. The root of trust for transitional mode is
in the browser bundle, which authenticates the TLS connection used for
discovering private PKI CA certificates (this will probably end up being
something like
https://device.organization.example/.well-known/ca/${authorityKeyID}.pem).
The private CA certificates are then used to validate the entity
certificates discovered via TLSA records.

> > I understand the frustration with the lack of DNSSEC adoption, and I
> agree with you that it is easier and safer to adopt
> > than in the past. Unfortunately, adoption remains abysmal. We expect
> that by adding this transitional mode in the
You make a good point, and there's really not anything preventing anyone
from implementing this against our guidance right now.
I think that if we hold on to the DNSSEC requirement for any updates to how
the TLS handshake works, that will offer some measure of safety.

> >       > PKI to securely discover certificates, in the absence of DNSSEC.
> This allows for a gradual DANE adoption
> >       where DNSSEC is not in the
> >       > initial set of requirements. If the application owner wishes to
> use DANE for mutual TLS authentication,
> >       the application owner must
> discovering private PKI entity and CA
Nope, let me clarify: The private PKI CA certificates are discovered via
HTTPS, which is server-authenticated using Web PKI. Entity certificates are
discovered via TLSA records, and authenticated using the discovered private
PKI CA certificates.
Keep in mind that we aren't recommending the implementation of transitional
mode in the TLS handshake. Transitional mode is only for discovering entity
and CA certificates outside the context of a TLS handshake.

> don't involve changes to the TLS library. An
> > example use case for this mode is the discovery of entity certificates
> for authenticating signed telemetry in decoupled
> > applications.
> > DANE client identity support within the TLS handshake requires DNSSEC,
> and we're looking to establish that pattern via
> > the client ID and client certificate drafts. So if an organization wants
> to transition from certificate discovery use
> > cases to having DANE client identity support in the TLS protocol,
> they'll have to take the final step and implement
> > DNSSEC.
>
Yeah, we were trying to keep the charter as succinct as possible, and leave
the implementation details to the drafts themselves. How would you prefer
we update/clarify the charter?

--

---

From: Ash Wilson <[email-masked]>
Date: Thu, 20 May 2021 22:23:41 -0700

Hi everyone,
I've updated the text stating DANE's original purpose, according to
recommendations from Paul and Jacques.

Any other comments or suggestions for clarification? We've had some
dialogue and I want to make sure that anything that's not sufficiently
clear for a charter-level doc is appropriately addressed.

-----
Objective
DANE’s original purpose only covered authentication for the TLS server

Problem statement

Scope of work

On Wed, May 12, 2021 at 2:35 PM Ash Wilson <[email-masked]> wrote:

> DANE’s original purpose only covered the coupling of PKI and DNS for
> server identity. The DANISH working group seeks to extend the DANE standard
> to encompass client identity and message sender identity use cases. DANISH

--

---

From: "Olle E. Johansson" <[email-masked]>
Date: Fri, 21 May 2021 08:59:34 +0200

> On 21 May 2021, at 07:23, Ash Wilson <ash.wilson=[email-masked]> wrote:
> 
> Hi everyone,
> I've updated the text stating DANE's original purpose, according to recommendations from Paul and Jacques.
> 
> Any other comments or suggestions for clarification? We've had some dialogue and I want to make sure that anything that's not sufficiently clear for a charter-level doc is appropriately addressed.
> 
> -----
> Objective
> DANE’s original purpose only covered authentication for the TLS server identity. The DANISH working group seeks to extend the DANE standard to encompass client identity and message sender identity use cases. DANISH also seeks to define a transitional mode for DANE, which will allow the safe adoption of DANE for domain owners who have not yet implemented DNSSEC..
> 
> Problem statement
> Using DANE for representing client identities safely allows authentication across CAs and prevents impersonation, because DNSSEC is used instead of a CA certificate and its associated trust hierarchy to bind an identity’s name to a public key. Everyone agrees on the DNS namespace and the DNS root zone’s DNSSEC trust anchor, eliminating the barrier to adoption for multiple private PKIs participating in application deployment.
> 
> The greatest barrier to DANE adoption has been the DNSSEC requirement. DANISH will seek to provide a method of certificate and trust chain discovery for private PKIs, to enable the messaging security use case. This alternative mode will allow the use of  Web PKI to securely discover certificates, in the absence of DNSSEC. This allows for a gradual DANE adoption where DNSSEC is not in the initial set of requirements. If the application owner wishes to use DANE for mutual TLS authentication, the application owner must then configure DNSSEC for the zone.
> 
> Scope of work
> The DANISH group will produce an architecture document describing the primary application components, and their interaction patterns. DANISH will establish usage conventions for DANE DNS records to represent client identity for TLS connections and how to perform public key discovery for object security use cases. DANISH will also define any required TLS protocol updates to support client authentication using DANE. DANISH will define a method whereby Web PKI may be used in lieu of DNSSEC, using DANE DNS record types under specific use cases, as a transitional mode from Web PKI to the DNSSEC-based trust model.
> 
> While modifications to the following standards are not within the scope of the DANISH charter, the DANISH working group will take care to ensure a potential path for interoperability with the following standards, enabling potential future work: JOSE, COSE, Oauth2, MLS, EAP-TLS, SMIMEA (RFC 8162), SIP (RFC 5922), Proxy headers (RFC 7239), IANA email authentication headers, and TCP proxy TLVs standardized by haproxy.

Sounds good to me!
+1

/O
> 
> On Wed, May 12, 2021 at 2:35 PM Ash Wilson <[email-masked] <mailto:[email-masked]>> wrote:
> Hello everyone,
> 
> Together with the BoF chairs, a few of us have been discussing what a charter for this working group might look like. We are pleased to present the following for your consideration:
> 
> -----
> Objective
> DANE’s original purpose only covered the coupling of PKI and DNS for server identity. The DANISH working group seeks to extend the DANE standard to encompass client identity and message sender identity use cases. DANISH also seeks to define a transitional mode for DANE, which will allow the safe adoption of DANE for domain owners who have not yet implemented DNSSEC..
> 
> Problem statement
> Using DANE for representing client identities safely allows authentication across CAs and prevents impersonation, because DNSSEC is used instead of a CA certificate and its associated trust hierarchy to bind an identity’s name to a public key. Everyone agrees on the DNS namespace and the DNS root zone’s DNSSEC trust anchor, eliminating the barrier to adoption for multiple private PKIs participating in application deployment.
> 
> The greatest barrier to DANE adoption has been the DNSSEC requirement. DANISH will seek to provide a method of certificate and trust chain discovery for private PKIs, to enable the messaging security use case. This alternative mode will allow the use of  Web PKI to securely discover certificates, in the absence of DNSSEC. This allows for a gradual DANE adoption where DNSSEC is not in the initial set of requirements. If the application owner wishes to use DANE for mutual TLS authentication, the application owner must then configure DNSSEC for the zone.
> 
> Scope of work
> The DANISH group will produce an architecture document describing the primary application components, and their interaction patterns. DANISH will establish usage conventions for DANE DNS records to represent client identity for TLS connections and how to perform public key discovery for object security use cases. DANISH will also define any required TLS protocol updates to support client authentication using DANE. DANISH will define a method whereby Web PKI may be used in lieu of DNSSEC, using DANE DNS record types under specific use cases, as a transitional mode from Web PKI to the DNSSEC-based trust model.
> 
> While modifications to the following standards are not within the scope of the DANISH charter, the DANISH working group will take care to ensure a potential path for interoperability with the following standards, enabling potential future work: JOSE, COSE, Oauth2, MLS, EAP-TLS, SMIMEA (RFC 8162), SIP (RFC 5922), Proxy headers (RFC 7239), IANA email authentication headers, and TCP proxy TLVs standardized by haproxy. 
> 
> -- 
> Ash Wilson | Technical Director
> e: [email-masked] <mailto:[email-masked]> 
> 
> This email and all data transmitted with it contains confidential and/or proprietary information intended solely for the use of individual(s) authorized to receive it. If you are not an intended and authorized recipient you are hereby notified of any use, disclosure, copying or distribution of the information included in this transmission is prohibited and may be unlawful. Please immediately notify the sender by replying to this email and then delete it from your system.
> 
> 
> -- 
> Ash Wilson | Technical Director
> e: [email-masked] <mailto:[email-masked]> 
> 
> This email and all data transmitted with it contains confidential and/or proprietary information intended solely for the use of individual(s) authorized to receive it. If you are not an intended and authorized recipient you are hereby notified of any use, disclosure, copying or distribution of the information included in this transmission is prohibited and may be unlawful. Please immediately notify the sender by replying to this email and then delete it from your system.
> -- 
> Danish mailing list
> [email-masked]