Re: [Danish] Proposed DANISH charter

[Ash Wilson <[e-mail]>]

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.

On Wed, May 12, 2021 at 2:35 PM Ash Wilson <[e-mail]> 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:* [e-mail]
>
> 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:* [e-mail]

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.