From nobody Thu Apr 1 01:17:55 2021 Return-Path: X-Original-To: danish@ietfa.amsl.com Delivered-To: danish@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14DCC3A0E39 for ; Thu, 1 Apr 2021 01:17:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.118 X-Spam-Level: X-Spam-Status: No, score=-2.118 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=openfortress.nl Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M_l4w7GuVh2b for ; Thu, 1 Apr 2021 01:17:48 -0700 (PDT) Received: from lb2-smtp-cloud7.xs4all.net (lb2-smtp-cloud7.xs4all.net [194.109.24.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E521C3A0E43 for ; Thu, 1 Apr 2021 01:17:47 -0700 (PDT) Received: from popmini.vanrein.org ([83.161.146.46]) by smtp-cloud7.xs4all.net with ESMTP id RsWLlcoK6MxedRsWMlrbzZ; Thu, 01 Apr 2021 10:17:42 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=openfortress.nl; i=rick@openfortress.nl; q=dns/txt; s=fame; t=1617265055; h=message-id : date : from : mime-version : to : subject : content-type : content-transfer-encoding : date : from : subject; bh=Y8FlXYC20dKJNAiN3zj0Imlg7cbk5vjXi4YNfz2EbtM=; b=gvYbANhwHcJEPQao32e/RO7gOObo9jFDss0yr62WEuDDMFExeQdL9/10 BERB3xrRrDzFZdSd2F7ORBIbyy7ZfINCL47MCvXEcSTU0Sp96+Hkpp+tt5 urN7kOY9XAlBeqrqtoxztLchYrxM71u46agDm+XhcIHgCbd4EQaGqybY8= Received: by fame.vanrein.org (Postfix, from userid 1006) id 5DD9C4BFEE; Thu, 1 Apr 2021 08:17:35 +0000 (UTC) X-Original-To: danish@ietf.org Received: from airhead.local (phantom.vanrein.org [83.161.146.46]) by fame.vanrein.org (Postfix) with ESMTPA id 24B2A4BFEC; Thu, 1 Apr 2021 08:17:31 +0000 (UTC) Message-ID: <60658198.2070902@openfortress.nl> Date: Thu, 01 Apr 2021 10:17:28 +0200 From: Rick van Rein User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: danish@ietf.org X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Bogosity: Unsure, tests=bogofilter, spamicity=0.520000, version=1.2.4 X-CMAE-Envelope: MS4xfO6Ogz7f7cd6a/hYlH+jnYeWJfkD7oX2ECS4UXz6bYePHTgkjioUHuMQcetBXNoNIwlhGN+sU4HXJibz66+vUiYat6aWhBJYn/WS3Ri0rwZUcFCOfzqF Vg6R9/3gcAj0nYlu9W25GZhKBiXGpYVX/TH1AbvA9n38vkYR08ktwGwT0DzPPoMR4A3aaYNj+YH+/A== Archived-At: Subject: [Danish] Application-Independent Client Identity through DANE X-BeenThere: danish@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Apr 2021 08:17:54 -0000 Hallo Danish, I was happy to learn that Client DANE is being worked on again. An opportunity that I'd like to see addressed is a mechanism for clients to state that their identity sits under a given domain. The way to do that now involves LDAP, protected with TLS and DANE/DNSSEC. There are advantages including simplicity about doing this with Client DANE. Would you consider the attached portion of text? It would be a way of achieving Realm Crossover, our globally described intention in draft-vanrein-internetwide-realm-crossover The general approach is to use DNSSEC-based authority for domains, and treat the assignment of userids as the prerogative of the domain, to be validated over a secure backlink. The draft expired just yet, and I'd love to update it with a reference to the following in Client DANE :) Thanks for considering, Rick van Rein InternetWide.org / OpenFortress.nl 2.0. Format 0: Application-Independent Client Identity The purpose of this format is to allow clients to state [client-user-identity]@[client-domain-name] style identities which are not tied to any specific application. This uses certificates to implement Realm Crossver . In this format, domain users hold certificates signed under a CA certificate that is approved of in a TLSA record named _client-identity.[client-domain-name] The TLSA record SHOULD NOT set the TLSA RDATA field for Certificate Usage to match end entity certificates. The issuing CA or CAs approved by this statement MUST NOT issue any attributes that represents another domain name than [client-domain-name]. Note that a sequence of "domainComponent" or "dc" RDNs would combine to form a domain name. Note that a domain name may occur as part of a longer attribute. The issuing CA or CAs approved by this statement SHOULD NOT issue any attributes that represent a user identity that has not been established by a RA run under control of the domain [client-domain-name]. Note that a userid may occur as part of a longer attribute. To implement these rules, the issuing CA or CAs approved by this statement MUST NOT produce attributes of which it does not known whether it represents a domain name and/or user identity. On the grounds of this TLSA statement, the relying party SHOULD NOT trust any other information than domain names and user identities. This does not preclude that other paths may validate the information, possibly including application choices to treat attributes as informative suggestions without security implications. From nobody Thu Apr 1 23:34:09 2021 Return-Path: X-Original-To: danish@ietfa.amsl.com Delivered-To: danish@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6450C3A34DD for ; Thu, 1 Apr 2021 23:34:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.118 X-Spam-Level: X-Spam-Status: No, score=-2.118 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=openfortress.nl Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y97WX63vc0B9 for ; Thu, 1 Apr 2021 23:34:02 -0700 (PDT) Received: from lb2-smtp-cloud7.xs4all.net (lb2-smtp-cloud7.xs4all.net [194.109.24.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2285A3A34DC for ; Thu, 1 Apr 2021 23:33:59 -0700 (PDT) Received: from popmini.vanrein.org ([83.161.146.46]) by smtp-cloud7.xs4all.net with ESMTP id SDNTllTpsMxedSDNUlwC1X; Fri, 02 Apr 2021 08:33:56 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=openfortress.nl; i=rick@openfortress.nl; q=dns/txt; s=fame; t=1617345229; h=message-id : date : from : mime-version : to : subject : references : in-reply-to : content-type : content-transfer-encoding : date : from : subject; bh=GwS4rSFEEyQ5iGFRtrY6tgh7+NWqEkJe8cj3NYxRLSE=; b=lDUuq/Or6dxmMVob8IVPsp+rDpH5MY+HZbcBDakIyABeljEWPbskZLqe GN5tF/Z/81zb+CQJEh0+EUuErvXuGpxQ1FS0Em23uHmRYxMQJRVyntCt0Z l04b1B1yy56no4ZAU5JWnkjCFWe5KPIcmYvr/mq35c/UuPBsopQMm0Up0= Received: by fame.vanrein.org (Postfix, from userid 1006) id 4CBFB4C262; Fri, 2 Apr 2021 06:33:49 +0000 (UTC) X-Original-To: danish@ietf.org Received: from airhead.local (phantom.vanrein.org [83.161.146.46]) by fame.vanrein.org (Postfix) with ESMTPA id 1F01B4C25F; Fri, 2 Apr 2021 06:33:45 +0000 (UTC) Message-ID: <6066BAC6.2000801@openfortress.nl> Date: Fri, 02 Apr 2021 08:33:42 +0200 From: Rick van Rein User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: danish@ietf.org References: <60658198.2070902@openfortress.nl> In-Reply-To: <60658198.2070902@openfortress.nl> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Bogosity: Unsure, tests=bogofilter, spamicity=0.520000, version=1.2.4 X-CMAE-Envelope: MS4xfMY1e9xDpd1xAHvLPE+8gdnWqLfF7lklsiI1AiF1T0AItFfdsXp63/ou/xMmpxqMcY91Vm40QPefc6eOeD36GrS/2vZvNcCI7UrXEQ+/jFSlKWW0bwPE KYWFF0lbI85/P8SGrq+ssatqE9y1b19TjG9xMsZ6VyIt6+xEwQOUsQtBbuYpXGirAS5rZ+2Ja+lZGQ== Archived-At: Subject: Re: [Danish] Application-Independent Client Identity through DANE X-BeenThere: danish@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Apr 2021 06:34:07 -0000 Hello Danish, Shumon suggested that the text I wrote might be too specific for an application that I have in mind. This is an alternative text aiming to say just enough to support meaningful conclusions. I mention "uid" and "dc" attributes as a hint without force. This may be helpful to provide some guidance to allow various applications to come together. Cheers, -Rick 2.0. Format 0: Application-Independent Client Identity The purpose of this format is to certify client's [client-user-identity]@[client-domain-name] style identities without ties to any specific application or protocol. This is a mechanism to support Realm Crossver . In this format, domain users hold certificates signed under a CA certificate that is approved of in a TLSA record named _client-identity.[client-domain-name] TLSA records with such names SHOULD NOT set the RDATA field for Certificate Usage to match end entity certificates. The issuing CA or CAs approved by this statement MUST NOT publish certificate attributes whose meaning specify the [client-user-identity], the [client-domain-name] or any parts or combinations thereof, except when (1) the full [client-domain-name] is represented and (2) that domain has approved the [client-user-identity] and the public key to belong to the requesting client for at least the period of validity of the certificate to be issued. After extracting the [client-domain-name] from a client certificate and validating the certificate to comply to this TLSA record, a relying party can trust attributes that specify the [client-user-identity] such as "uid", and the [client-domain-name] such as in a "dc" sequence, to adhere to the authoritative hierarchy of Internet names. From nobody Fri Apr 2 05:45:04 2021 Return-Path: X-Original-To: danish@ietfa.amsl.com Delivered-To: danish@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E4253A13CF for ; Fri, 2 Apr 2021 05:45:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y9n5q821I5pA for ; Fri, 2 Apr 2021 05:44:56 -0700 (PDT) Received: from mail-ed1-x532.google.com (mail-ed1-x532.google.com [IPv6:2a00:1450:4864:20::532]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15A533A13E1 for ; Fri, 2 Apr 2021 05:44:55 -0700 (PDT) Received: by mail-ed1-x532.google.com with SMTP id h13so5337714eds.5 for ; Fri, 02 Apr 2021 05:44:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=CXGr0+/Blsg0p4sF9JUWddZ1D3AnsoQeU53uUjmuEoo=; b=azbC3FaOkkkdgxfM1T38JaoGRpAhXEEdN0OffJmZRXMnfLk9o2kMaidYlKK/a7Nhe/ fEsGmixiH9O5CdiLR0OJx7ZcgmFgO8H7YVQjHY+wgYyyajhnF2SItanPSoxqiVCTrncW r0o8WCSmRCUwmn+XUvGUkD3xWzzxCNJBEacKagIMYcWsBMCeTSOELb2J4FwWuKR06bZj TrFMH/d9YJghD2MGWJO9r3ASXSV9ywVWs4npiY3Edk7NepDCsaCVOB2h3YN+L9Jy/vdt q1RY1uHgtYWYFDMg9lfgCWcmywJ6UpwInPY79Ub4/U6gAM1++Z/QFSF12SUoAsUmK84l 8hJw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=CXGr0+/Blsg0p4sF9JUWddZ1D3AnsoQeU53uUjmuEoo=; b=qZXU0yXxH4njv9Zm/DI68+vc8eI/s8hZYcXQnTwIQUYIQaS7p/MLffRSNb7AXOlW2F WsHNe7K+/nXoWiXo8cvnEvp9UrPBQcci9I9hCWvdrVqcrWazL/lMThaPNjXcUBOwGH8q TEbkA7sDNOFenpvukV5uFIjgu8ZFXHHZAdCMbUKFgd91w/sGPeIr5TtOImFlW65aklF5 hYFz59aH9OoPmxW//ZDAoYg3BCjzz/YkpzkpsHnnIm1PCi3XaeXpkUvbIG7psSC/q2Ib 5biHzV/Pis0Bmo+UWuoSHAwvVPqvydNXlcA3NvSNVwCkPOkWV4/9rr88BSs65x9EoIgh ZQkA== X-Gm-Message-State: AOAM5304KFpVJfWeKQkpx0uRlGXWg2XoU+d5rY6jN3aITGWf+OdfPc5v QY4qmgmR56j9au9wKsHKK65sVt6wZXzExEFW0iJl38E3 X-Google-Smtp-Source: ABdhPJwEYCmrjJsPiO+GniVlgI8xIujglk67GWzdySh7epocjdQ22PlxaJwzHrI15FBhaWTghJTvIT7EDNXHE4UnGtE= X-Received: by 2002:a50:ed96:: with SMTP id h22mr15056836edr.39.1617367492990; Fri, 02 Apr 2021 05:44:52 -0700 (PDT) MIME-Version: 1.0 References: <60658198.2070902@openfortress.nl> <6066BAC6.2000801@openfortress.nl> In-Reply-To: <6066BAC6.2000801@openfortress.nl> From: Shumon Huque Date: Fri, 2 Apr 2021 08:44:41 -0400 Message-ID: To: Rick van Rein Cc: danish@ietf.org Content-Type: multipart/alternative; boundary="000000000000e4180e05befcb62e" Archived-At: Subject: Re: [Danish] Application-Independent Client Identity through DANE X-BeenThere: danish@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Apr 2021 12:45:02 -0000 --000000000000e4180e05befcb62e Content-Type: text/plain; charset="UTF-8" Thanks Rick, I'm reviewing, and hope others will too. I'll note that although this work is expected to be done in the context of an IOT focussed working group, the DANE client authentication draft is general purpose in nature, and we know that there are several folks from other application communities interested in this (SMTP, etc). So, I'm personally very open to expanding the utility of the draft to your Internet identity proposals, and adding another proposed format to support application independent identities sounds quite reasonable to me. Will circle back with more detailed comments soon. Shumon. On Fri, Apr 2, 2021 at 2:34 AM Rick van Rein wrote: > Hello Danish, > > Shumon suggested that the text I wrote might be too specific > for an application that I have in mind. This is an alternative > text aiming to say just enough to support meaningful conclusions. > > I mention "uid" and "dc" attributes as a hint without force. > This may be helpful to provide some guidance to allow various > applications to come together. > > > Cheers, > -Rick > > > 2.0. Format 0: Application-Independent Client Identity > > The purpose of this format is to certify client's > [client-user-identity]@[client-domain-name] style > identities without ties to any specific application or > protocol. This is a mechanism to support Realm Crossver > . > > In this format, domain users hold certificates signed > under a CA certificate that is approved of in a TLSA > record named > > _client-identity.[client-domain-name] > > TLSA records with such names SHOULD NOT set the RDATA field > for Certificate Usage to match end entity certificates. > > The issuing CA or CAs approved by this statement MUST NOT > publish certificate attributes whose meaning specify the > [client-user-identity], the [client-domain-name] or any > parts or combinations thereof, except when (1) the full > [client-domain-name] is represented and (2) that domain has > approved the [client-user-identity] and the public key to > belong to the requesting client for at least the period > of validity of the certificate to be issued. > > After extracting the [client-domain-name] from a client > certificate and validating the certificate to comply to > this TLSA record, a relying party can trust attributes > that specify the [client-user-identity] such as "uid", and > the [client-domain-name] such as in a "dc" sequence, to > adhere to the authoritative hierarchy of Internet names. > > -- > Danish mailing list > Danish@ietf.org > https://www.ietf.org/mailman/listinfo/danish > --000000000000e4180e05befcb62e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks Rick,

I'm reviewi= ng, and hope others will too.

I'll note that a= lthough this work is expected to be done in the context of an IOT focussed = working group, the DANE client authentication draft is general purpose in n= ature, and we know that there are several folks from other application comm= unities interested in this (SMTP, etc). So, I'm personally very open to= expanding the utility of the draft to your Internet identity proposals, an= d adding another proposed format to support application independent identit= ies sounds quite reasonable to me. Will circle back with more detailed comm= ents soon.

Shumon.

On Fri, Apr 2, 2021 at 2= :34 AM Rick van Rein <rick@openf= ortress.nl> wrote:
Hello Danish,

Shumon suggested that the text I wrote might be too specific
for an application that I have in mind.=C2=A0 This is an alternative
text aiming to say just enough to support meaningful conclusions.

I mention "uid" and "dc" attributes as a hint without f= orce.
This may be helpful to provide some guidance to allow various
applications to come together.


Cheers,
=C2=A0-Rick


2.0.=C2=A0 Format 0: Application-Independent Client Identity

=C2=A0 =C2=A0The purpose of this format is to certify client's
=C2=A0 =C2=A0[client-user-identity]@[client-domain-name] style
=C2=A0 =C2=A0identities without ties to any specific application or
=C2=A0 =C2=A0protocol.=C2=A0 This is a mechanism to support Realm Crossver<= br> =C2=A0 =C2=A0<xref target=3D"draft-vanrein-internetwide-realm-cross= over"/>.

=C2=A0 =C2=A0In this format, domain users hold certificates signed
=C2=A0 =C2=A0under a CA certificate that is approved of in a TLSA
=C2=A0 =C2=A0record named

=C2=A0 =C2=A0_client-identity.[client-domain-name]

=C2=A0 =C2=A0TLSA records with such names SHOULD NOT set the RDATA field =C2=A0 =C2=A0for Certificate Usage to match end entity certificates.

=C2=A0 =C2=A0The issuing CA or CAs approved by this statement MUST NOT
=C2=A0 =C2=A0publish certificate attributes whose meaning specify the
=C2=A0 =C2=A0[client-user-identity], the [client-domain-name] or any
=C2=A0 =C2=A0parts or combinations thereof, except when (1) the full
=C2=A0 =C2=A0[client-domain-name] is represented and (2) that domain has =C2=A0 =C2=A0approved the [client-user-identity] and the public key to
=C2=A0 =C2=A0belong to the requesting client for at least the period
=C2=A0 =C2=A0of validity of the certificate to be issued.

=C2=A0 =C2=A0After extracting the [client-domain-name] from a client
=C2=A0 =C2=A0certificate and validating the certificate to comply to
=C2=A0 =C2=A0this TLSA record, a relying party can trust attributes
=C2=A0 =C2=A0that specify the [client-user-identity] such as "uid"= ;, and
=C2=A0 =C2=A0the [client-domain-name] such as in a "dc" sequence,= to
=C2=A0 =C2=A0adhere to the authoritative hierarchy of Internet names.

--
Danish mailing list
Danish@ietf.org https://www.ietf.org/mailman/listinfo/danish
--000000000000e4180e05befcb62e-- From nobody Fri Apr 2 23:45:29 2021 Return-Path: X-Original-To: danish@ietfa.amsl.com Delivered-To: danish@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0FC13A0B1D for ; Fri, 2 Apr 2021 23:45:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.118 X-Spam-Level: X-Spam-Status: No, score=-2.118 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=openfortress.nl Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xqJ4BfBtFFBj for ; Fri, 2 Apr 2021 23:45:21 -0700 (PDT) Received: from lb3-smtp-cloud7.xs4all.net (lb3-smtp-cloud7.xs4all.net [194.109.24.31]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44B823A0B17 for ; Fri, 2 Apr 2021 23:45:19 -0700 (PDT) Received: from popmini.vanrein.org ([83.161.146.46]) by smtp-cloud7.xs4all.net with ESMTP id Sa1zltciwMxedSa20l0YDk; Sat, 03 Apr 2021 08:45:17 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=openfortress.nl; i=rick@openfortress.nl; q=dns/txt; s=fame; t=1617432309; h=message-id : date : from : mime-version : to : cc : subject : references : in-reply-to : content-type : content-transfer-encoding : date : from : subject; bh=+LAR6RxgCj9MjiNJ4FCFfXWDSKrn+GibQsUAtIOFtI0=; b=IABqSr6cnvD4IiL7HVLTHn8aMIF2T/XHJQ4BQ2OHuj3FXScmLy1aqITe gv7E99Dz6awdwQyAZUx+F6tO7MpXEofXfO545ZUxoDy6Ki2ZbSxF8di3bW 7g2v40fMAXQ6bfNSgBqpakJfbSB+j5+A8Ky/2vI3ru9z289qPu0LHXJqg= Received: by fame.vanrein.org (Postfix, from userid 1006) id 7A6D54C41B; Sat, 3 Apr 2021 06:45:09 +0000 (UTC) X-Original-To: danish@ietf.org Received: from airhead.local (phantom.vanrein.org [83.161.146.46]) by fame.vanrein.org (Postfix) with ESMTPA id CEE1E4C418; Sat, 3 Apr 2021 06:45:05 +0000 (UTC) Message-ID: <60680EF0.5080901@openfortress.nl> Date: Sat, 03 Apr 2021 08:45:04 +0200 From: Rick van Rein User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: Shumon Huque CC: danish@ietf.org References: <60658198.2070902@openfortress.nl> <6066BAC6.2000801@openfortress.nl> In-Reply-To: X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Bogosity: Unsure, tests=bogofilter, spamicity=0.520000, version=1.2.4 X-CMAE-Envelope: MS4xfJhOn/cE8L+8NSHHKzLivnXYCw2ilFAwPRBHEKtdyhZo8/WECIytsecWU3alt7r1XJYvhi6lpKcVG/6S8RGR6TDvoO5Zt7bd9sN1r6MbYxS6cQiC24IS /xZp8PIpSC9/+JySbnjy4EbXgf6iwEsWGk2ad6rKftp9ctwdayrk/OTztqwDenW/Z/YzP1rcYA4sKA== Archived-At: Subject: Re: [Danish] Application-Independent Client Identity through DANE X-BeenThere: danish@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Apr 2021 06:45:28 -0000 Hi Shumon, Looking forward to your comments. > [...] we know that there are several folks from > other application communities interested in this (SMTP, etc). There are several concrete ways in which Realm Crossover could lighten the burden of SMTP spam. - Clients could submit directly to the destintation SMTP server - Clients could run a personal destination SMTP server (P2P style) - Submission services could work with less configuration -Rick From nobody Fri Apr 2 23:46:24 2021 Return-Path: X-Original-To: danish@ietfa.amsl.com Delivered-To: danish@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7ABB3A0B21 for ; Fri, 2 Apr 2021 23:46:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.819 X-Spam-Level: X-Spam-Status: No, score=-2.819 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=openfortress.nl Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qy_7W-3dGWQk for ; Fri, 2 Apr 2021 23:46:17 -0700 (PDT) Received: from lb2-smtp-cloud7.xs4all.net (lb2-smtp-cloud7.xs4all.net [194.109.24.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A40003A0B20 for ; Fri, 2 Apr 2021 23:46:17 -0700 (PDT) Received: from popmini.vanrein.org ([83.161.146.46]) by smtp-cloud7.xs4all.net with ESMTP id Sa2wltd10MxedSa2xl0YMo; Sat, 03 Apr 2021 08:46:15 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=openfortress.nl; i=rick@openfortress.nl; q=dns/txt; s=fame; t=1617432365; h=message-id : date : from : mime-version : to : subject : references : in-reply-to : content-type : content-transfer-encoding : date : from : subject; bh=Ka1UCSNxXt0L/BbSEMTCG9ZvNokm9WMN2QlsPcsM0a4=; b=OvhmWHMFTX+VhHLojstxw2/uSnlhJoxn70evnAP8r+aRIfEM7NddRHf8 fODby7cYbYdXbQ+jIkoe2ZMI2J4z3qsYAJIcCG8kxDifOqR6DpvDwAjBg/ NSf8+VUR225XcGK6IiNywy8z+B/CD3n6q1g9RZ7ncxhItvvri22t9DgXw= Received: by fame.vanrein.org (Postfix, from userid 1006) id CBDA24C420; Sat, 3 Apr 2021 06:46:05 +0000 (UTC) X-Original-To: danish@ietf.org Received: from airhead.local (phantom.vanrein.org [83.161.146.46]) by fame.vanrein.org (Postfix) with ESMTPA id 499564C41A; Sat, 3 Apr 2021 06:46:05 +0000 (UTC) Message-ID: <60680F2C.3020308@openfortress.nl> Date: Sat, 03 Apr 2021 08:46:04 +0200 From: Rick van Rein User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: danish@ietf.org References: <60658198.2070902@openfortress.nl> <6066BAC6.2000801@openfortress.nl> <60680D1F.8060004@openfortress.nl> In-Reply-To: <60680D1F.8060004@openfortress.nl> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Bogosity: Unsure, tests=bogofilter, spamicity=0.520000, version=1.2.4 X-CMAE-Envelope: MS4xfNYogrN6MT1fR+oX+BndpZe5gwelFKOQfu0yHaa7tPEkBYAu9lFj5Gk3qoAlugXzif2NSDK2JsP/gxAh2Y/ekm5LqfAotSDFSkKRihmu0Qlpldz+89CE fP0yRI5EBLl51yQxk4bjT0K+rbcq0HKxlLg0Pfl0NONGIt9lN6gX6BEOuLIS21v7iLZD8sG7shioRg== Archived-At: Subject: Re: [Danish] Application-Independent Client Identity through DANE X-BeenThere: danish@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Apr 2021 06:46:24 -0000 Hello Ash, Thanks for thinking along! > I'm especially interested in the name formation, and how you see that > fitting in with your protocol. > > Here's a broad pattern for your consideration: > > _servicename.identityname._identitytype.domain > > _servicename is optional, and indicates that an identity exists as one of > multiple sub-identities of an entity. Examples of this might be > _verification, _encryption, _ldapclient, etc... When you say _verification or _encryption you are being general; this should also have an _authentication tag to login users from a foreign domain ("Realm Crossover", draft-vanrein-internetwide-realm-crossover). However, _ldapclient would be one application protocol. That is what I want to avoid, but I agree some may prefer it. The DNS * wildcard may help out here. Your _servicename looks to me like two things, _protoname._cryptotask where (terse forms of) _encryption and _verification and _authentication may occur as _cryptotask and _ldapclient or * could be the _protoname. The * would allow domains to state generic application support. It may even be an idea to allow one * for both these. > identityname is the unique identifier for the identity, within the scope of > the identity type for the domain. This could be multiple labels > representing the serial number and model of an IoT device, or a hash of the > local part of an email address, as described in > https://tools.ietf.org/html/rfc8162 Here we differ. I would prefer to not mention the user identity, in any form, because you end up making things static and iterable. We've investigated DANE in SURFnet.nl and concluded that there were too many involved parties to consistently keep it up (without automation, which is far from trivial) and adding user identities does not help. It also means that adding users takes time. This includes adding temporary users (to address a frivolous webshop) or other creative forms that people may think of, and would get frustrated by this. DNS caching times suddenly become a nuisance, operators would set it low and DNSSEC would have to work much harder. So, my guess is that mentioning users in DNS will never get traction. Devices are different in this respect. This is why I proposed to reference a CA instead. Certificates can be issued by a fixed party, but retain dynamicity as long as the CA is dynamic (which is feasible when DNS does not need to change). > _identitytype serves multiple purposes. It provides a human-friendly means > of indicating the type of entities which are represented under this part of > the DNS hierarchy. It also provides a delegation point, so that the group > responsible for managing those identities may be limited to managing just > those identities. We think that this is useful because the people and > systems responsible for managing IoT device identities in DNS will > typically not be the same people and systems that manage the DNS records > for the organization's websites or email configuration. An example of this > might be _device, _smimecert, _smartcard, _hardwaretoken, etc... Basically compartmentalisation of the name space for purpose. Yes, I can see that work. It does mean that applications need to register their use but, it being a mere name, I could imagine registering it loosely, suggesting the "Specification Required" level, where an I-D would suffice. Let's say I called this CXOVER, for Certificate-based Realm Crossover, then I'd register "_cxover" as a label. I could write a spec if that is helpful, we then have something concrete to battle about. > domain is any number of labels, including the organizational domain. > > The TLSA record can definitely be used to convey a CA certificate, so I > think that you can do what you need to without modifying the record format. > Does the naming pattern described above fit with your use case? It's close, but I have some proposals. What I end up with, after adding your ideas above, would be _protoname._cryptotask._identitytype.domain IN TLSA ... with examples like _smtp._authn._cxover.example.com. IN TLSA ... *._authn._cxover.example.com. IN TLSA ... *._cxover.example.com. IN TLSA ... Note: _authn and _cxover seem to be saying similar things here. Curious what your feelings about this are. Thanks! -Rick From nobody Sun Apr 4 02:54:45 2021 Return-Path: X-Original-To: danish@ietfa.amsl.com Delivered-To: danish@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29A753A2026 for ; Sun, 4 Apr 2021 02:54:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.119 X-Spam-Level: X-Spam-Status: No, score=-2.119 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=openfortress.nl Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fx4SzE37c7Vs for ; Sun, 4 Apr 2021 02:54:39 -0700 (PDT) Received: from lb1-smtp-cloud7.xs4all.net (lb1-smtp-cloud7.xs4all.net [194.109.24.24]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADEEF3A2027 for ; Sun, 4 Apr 2021 02:54:38 -0700 (PDT) Received: from popmini.vanrein.org ([83.161.146.46]) by smtp-cloud7.xs4all.net with ESMTP id SzShl1uwMMxedSzSil4Wg2; Sun, 04 Apr 2021 11:54:33 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=openfortress.nl; i=rick@openfortress.nl; q=dns/txt; s=fame; t=1617530065; h=message-id : date : from : mime-version : to : subject : references : in-reply-to : content-type : content-transfer-encoding : date : from : subject; bh=+ggPwPpKfLCktBJkAyjKaWfTEYYAFPhGlKO1zgLe+9k=; b=MimNW+spbG53cHNS1jnP5wMqJ2/XcEKHKPpq8F5DjKP4erjiTYv+1lTC kWiiLlxIbkDV7UqI6yBSf3UtVAFOBhcZsPzltVN8ATqm5ZX/V29YE8YhKR c1ZPSEmxpzxs31MFuRS50i9vK6GyUBLRQf2FzlkQCPwBfW9LzbSIItOpc= Received: by fame.vanrein.org (Postfix, from userid 1006) id 1077B4F959; Sun, 4 Apr 2021 09:54:25 +0000 (UTC) X-Original-To: danish@ietf.org Received: from airhead.local (phantom.vanrein.org [83.161.146.46]) by fame.vanrein.org (Postfix) with ESMTPA id E60774F956; Sun, 4 Apr 2021 09:54:17 +0000 (UTC) Message-ID: <60698CC7.10804@openfortress.nl> Date: Sun, 04 Apr 2021 11:54:15 +0200 From: Rick van Rein User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: danish@ietf.org References: <60658198.2070902@openfortress.nl> <6066BAC6.2000801@openfortress.nl> <60680D1F.8060004@openfortress.nl> <60680F2C.3020308@openfortress.nl> In-Reply-To: <60680F2C.3020308@openfortress.nl> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Bogosity: Unsure, tests=bogofilter, spamicity=0.520000, version=1.2.4 X-CMAE-Envelope: MS4xfLhu910Dhq5rN3hInxGpHIDckaN+14uRuwIpnTgbvwHtmwQ9uQnY6NxpKxgd+b9VXIVY5LTzKOe3usc7sr5dLggrH4tJR2mVa/fU8WuABo8JgXnvnSEY xpNHo6/JSKFvHB+xCGIbBhikKtLOJOMIkYRBlW4tcuIuqZCncQ985V/OY45cw5m9nEmRyjHKCRrokw== Archived-At: Subject: Re: [Danish] Application-Independent Client Identity through DANE X-BeenThere: danish@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Apr 2021 09:54:44 -0000 Hi, > Let's say I called this CXOVER, for Certificate-based Realm Crossover, > then I'd register "_cxover" as a label. I could write a spec if that is > helpful, we then have something concrete to battle about. I played around with ideas and wrote draft-vanrein-cert-xover. I don't know exactly how it'd connect to Client DANE, many ways could work, but I now have a clear mind on what is required: - a general label like _cxover should have clearly defined meaning - that way, everyone would know the basis of trust - Realm Crossover has no other trust basis and needs clear semantics - cryptotasks _decrypt, _login, ... are likely generic to Client DANE - this could work by registering the _cxover name with IANA - the registration would point to the specification of trust Am I closing in on your idea of generic/specifc separation, while preserving the semantics needed to decide on trust matters? Cheers, -Rick From nobody Tue Apr 6 02:12:08 2021 Return-Path: X-Original-To: danish@ietfa.amsl.com Delivered-To: danish@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A4B23A1822 for ; Tue, 6 Apr 2021 02:12:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.809 X-Spam-Level: X-Spam-Status: No, score=-2.809 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=openfortress.nl Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1ZWT3N30iF3o for ; Tue, 6 Apr 2021 02:12:02 -0700 (PDT) Received: from lb2-smtp-cloud7.xs4all.net (lb2-smtp-cloud7.xs4all.net [194.109.24.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D05BC3A1825 for ; Tue, 6 Apr 2021 02:11:59 -0700 (PDT) Received: from popmini.vanrein.org ([83.161.146.46]) by smtp-cloud7.xs4all.net with ESMTP id ThkXlGq38MxedThkYlBtw2; Tue, 06 Apr 2021 11:11:54 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=openfortress.nl; i=rick@openfortress.nl; q=dns/txt; s=fame; t=1617700304; h=message-id : date : from : mime-version : to : cc : subject : references : in-reply-to : content-type : content-transfer-encoding : date : from : subject; bh=ObX/goqvo2mBMqy+CfIDiT087rXOnOyHT7/bOgngxxk=; b=j8bpIDYqxuadM0I2HDO6d94ERk9VXjTbJiJi9Fza1q4vgMq66tRDov2e T0Xb51luVmmV5SZ7jvx/qcPVTnWYWWjEntRR1dddONTsE75LUsJMZ1Yj5b 7iUx25UtYC9Q6MWCbXM5k3CA1xVGLAdif5JuuF9wPBlR+CuFkPSQfp8Ms= Received: by fame.vanrein.org (Postfix, from userid 1006) id ABBED501C1; Tue, 6 Apr 2021 09:11:36 +0000 (UTC) X-Original-To: danish@ietf.org Received: from airhead.local (phantom.vanrein.org [83.161.146.46]) by fame.vanrein.org (Postfix) with ESMTPA id 04B66501BE; Tue, 6 Apr 2021 09:11:35 +0000 (UTC) Message-ID: <606C25C5.1000105@openfortress.nl> Date: Tue, 06 Apr 2021 11:11:33 +0200 From: Rick van Rein User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: Ash Wilson CC: danish@ietf.org References: <60658198.2070902@openfortress.nl> <6066BAC6.2000801@openfortress.nl> <60680D1F.8060004@openfortress.nl> In-Reply-To: X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Bogosity: Unsure, tests=bogofilter, spamicity=0.520000, version=1.2.4 X-CMAE-Envelope: MS4xfA73J8imm/k/z/P83Dcd3Q23Q6VxbYA5nuqIeAUBJa6yV9wQGVWq2YamlNETfbg3BcRs7GrDSRkwkdRzL6dGC1s0SCSK0tkWycDt4yH6RmoV5Woh93zm gXjEY/hgH4DXajA/fJwwFZtCb36g5L7I985dD8NVmHhywVFDfsb4id8vGcaWiQY8fXw67q9LQyE3RQ== Archived-At: Subject: Re: [Danish] Application-Independent Client Identity through DANE X-BeenThere: danish@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2021 09:12:07 -0000 Hello Ash, > This is interesting. So, let me summarize what I understand so far: this > provides a way of conveying an organization's CA so that any sub-identity > may be authenticated without explicitly creating a record for every > sub-identity in DNS. Is my understanding correct? Yes. Although I barely focus on finding certificates, as I am assuming a rich user or server environment. It's interesting though. The central idea is to trust a domain on the basis of (root or intermediate) CA certificates in DANE; they might be stored or hashed in DNS. > Here's an overlap (maybe): In the PKIX-CD draft ( > https://datatracker.ietf.org/doc/draft-wilson-dane-pkix-cd/) we present a > method by which an authenticating entity may use the EE's DNS name and AKI > (both found in the certificate) to construct a URL for discovering the CA > certificate. That is an interesting idea, and perhaps not specific to client DANE. I would venture to guess that it solves a general problem, possibly even of finding a root CA that may be solely trusted on grounds of DANE. I was lazily proposing to put whole certificates into DNS, perhaps even for intermediate CAs. > Even if you don't publish the EE certs for DNS-based identities in DNS, you > can still use DNS to discover the trust chains. You can still get the DNS > name or email address out of the presented certificate and use that with > the AKI to construct a URL where the intermediate certificate that can > verify the EE certificate should be found. Yes. This is also a way to get away from a large-but-limited set of well-known CAs, so it might help in applications that are more diverse, such as a domain-local CA or even peer-to-peer networks that employ DNS. > If this pattern works for your use case, then you'll have some > cross-compatibility for other use cases, where we do need the certificate > to be discoverable in DNS (object security use cases) as well as having a > sort of transitional mode between traditional PKI and DANE for > authentication, both hinging around DNS names for entities. I think it *almost* works. Your "_device" is an example of an identity grouping label, but it is not clear to me if this is something that is formally registered or a local network choice. When formally registered, a specification could be attached that defines the semantics of that name. As a consequence, it would be possible to visit completely foreign domains for the first time to discover what their certificates are saying. The shared semantics are the pivotal point here; applications need to know what they can assume when they find such a label. This is a reason why SRV records work so well, yet are flexible for new specifications to adopt. It would be possible to make a choice to trust only configured domains to set a configured _label. Then, anyone can add names without formalities, but a label _client-identity would not have necessary meaning; the domain owner would not be expressing anything but data, with no necessarily implied meaning. So this idea of registered naming is vital to the idea of Realm Crossover. The ideas of with/without semantics can both be used with a _label that says "make no assumptions, unless you were configured to look underneath this one". Can you elaborate on that please? Cheers, -Rick From nobody Sun Apr 11 13:16:52 2021 Return-Path: X-Original-To: danish@ietfa.amsl.com Delivered-To: danish@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 037BD3A1C6E for ; Sun, 11 Apr 2021 13:16:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HNP1kYJNcIQ3 for ; Sun, 11 Apr 2021 13:16:46 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69F0E3A1C6B for ; Sun, 11 Apr 2021 13:16:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 9621438A73 for ; Sun, 11 Apr 2021 16:23:50 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id FxFWXGc9KanW for ; Sun, 11 Apr 2021 16:23:49 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 94AE338A15 for ; Sun, 11 Apr 2021 16:23:49 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 31E09BCA for ; Sun, 11 Apr 2021 16:16:44 -0400 (EDT) From: Michael Richardson To: danish@ietf.org X-Attribution: mcr X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: [Danish] DANE/QUIC discussion on ietf@ietf.org X-BeenThere: danish@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Apr 2021 20:16:51 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable There is a long thread about QUIC, DNS lookups and DANE on ietf@ietf.org. here is one message: https://mailarchive.ietf.org/arch/msg/ietf/CLB6HCPcwrQ= MdLtmcBH_EmjTBNc It has problem become one of these ping-pong threads. If there is some useful conclusion to DANISH, I haven't found it yet. I have started writing a strawman charter for DANISH, but I have been interrupted by AUTH48 processes. (yes! more than one! Woohoo!) =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAmBzWSsACgkQgItw+93Q 3WV4Ygf8DUeyfLYkkm3jpeITP/sOIvQOHrMjIQWfg/UWqvFf8Vk5DECBAaGzR/zy IOER41LnnO3AtaHIRhuz4XN6pW+d/mFPU7YiC58b+LpDkMzXr4RnqFiquhdTZPds mHbwbci58Ih92Odkn/paexBVSYZcVaw9JhKAYEHtcBnfn/0RQ394xHSd+VLo5f50 gXRR5DcptPoz4tguu46PDdv67b0w36qc5Wp+P6xi9d2RTdlaJtogJw1YzTs1FyEu hjUR0M7UWZORGZxQQGSk4Svoi0N0fjMa15iJDSiyVmttMhQq+EwIDOPYss8e0+dL /FaLNCvSuZrs/ba0dD34Acy4ICqHrg== =38Wl -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Apr 12 11:38:03 2021 Return-Path: X-Original-To: danish@ietfa.amsl.com Delivered-To: danish@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54FA63A124F for ; Mon, 12 Apr 2021 11:37:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=valimail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8RQcMqiQDLuN for ; Mon, 12 Apr 2021 11:37:47 -0700 (PDT) Received: from mail-qt1-x82f.google.com (mail-qt1-x82f.google.com [IPv6:2607:f8b0:4864:20::82f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 427073A11EB for ; Mon, 12 Apr 2021 11:37:44 -0700 (PDT) Received: by mail-qt1-x82f.google.com with SMTP id y12so10734715qtx.11 for ; Mon, 12 Apr 2021 11:37:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=p+vk7zMG8WD7c3u+SFuG+DTXoQpxwUijwE2IgpdYg7E=; b=eTCO9QcB9y/VbIQ5E/BV0tbJuMhcPmgh2P7XQxo11Tt9FFiuXOYsGKLM2v7A2oJWml Y1nZCl2dyU2yJCPJReD4ZPLPVDiI031LeLXu1UIRj4lHQZnGQUA5HxyAnwxngdmGthft wxwq6H8iFBCwQV7CyXtCBkgZpFjtU6kI9n2HSnHnHo0zubzGFl4m3liNN05Qddzx/owN 7O9MtQ1XJB1Edyh0ZRQQOFbXw1LYrRLipxhFc/xIVvEeSPsPdhMhPKb/U7SatJzcW8Wu euGzk28zLHDYNmEresdyyhjlTwDKno65ulCnaArGt10Y8OS8p97IEZVeV7SM1cc1iDhw Ap8w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=p+vk7zMG8WD7c3u+SFuG+DTXoQpxwUijwE2IgpdYg7E=; b=H9nPw7E0B7cbpq7qxWtFxuhONJi9dINLwO5+prMxstNA+dgyvKGd27UoLf8MhCQOPF 4lPLCF1wsYowApBeNK0Gtidjb6DCz75VBo0dKB6FjkPk6x44a4xzuzw80i9LpJw+gxDt qMNRbY4LdKiztHl6HVHr8AftqiN0wEorOdf9xrIg8NJITmYMd96ukdJAhBhLU/7/ozx/ 0pOW36qWiXslVNb5LkpXPOK7eV4xYSBKnlE1UbrOGLE+q9tVYTn3oCOFVvOWpDZR+B97 dnMMSST25Fn8/GoV7N16yYYw4D4jsB1Rfzq1KNITfQGgq/SUYbONm7E1zvcCIdetN94N GrwQ== X-Gm-Message-State: AOAM533FzzbA+LwBc8lIEsZkY5db0AhoTBk2+igpafZ1T4SzT5I+aPqK 0kRZZzo8f8BJo1rCT0fTF/SMjBbtQhObq9x0bWBru/HH7Sc= X-Google-Smtp-Source: ABdhPJzpbiPV8XvixMJYFptJ9//LpWFfxkn4WgP/vAY2Vrb8ieU1jCK4B+JnVJ01aIIDthk/oJYCdcVhMNSFQGq7nng= X-Received: by 2002:ac8:4783:: with SMTP id k3mr27526627qtq.231.1618252662563; Mon, 12 Apr 2021 11:37:42 -0700 (PDT) MIME-Version: 1.0 References: <22071.1618172204@localhost> In-Reply-To: <22071.1618172204@localhost> From: Ash Wilson Date: Mon, 12 Apr 2021 11:37:30 -0700 Message-ID: To: Michael Richardson Cc: danish@ietf.org Content-Type: multipart/alternative; boundary="0000000000001c06a105bfcacf31" Archived-At: Subject: Re: [Danish] DANE/QUIC discussion on ietf@ietf.org X-BeenThere: danish@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Apr 2021 18:38:00 -0000 --0000000000001c06a105bfcacf31 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Michael, Thanks for the heads-up on that thread. While there's no apparent mention of DANISH, I think that some of these discussion points will re-emerge... especially when we talk about a transitional mode for DANE. I'll definitely be revisiting that thread as DANISH evolves. -Ash On Sun, Apr 11, 2021 at 1:16 PM Michael Richardson wrote: > > There is a long thread about QUIC, DNS lookups and DANE on ietf@ietf.org. > here is one message: > https://mailarchive.ietf.org/arch/msg/ietf/CLB6HCPcwrQMdLtmcBH_EmjTBNc > > It has problem become one of these ping-pong threads. > If there is some useful conclusion to DANISH, I haven't found it yet. > > I have started writing a strawman charter for DANISH, but I have been > interrupted by AUTH48 processes. (yes! more than one! Woohoo!) > > > > > > > -- > Michael Richardson . o O ( IPv6 I=C3=B8T consul= ting ) > Sandelman Software Works Inc, Ottawa and Worldwide > > > > > -- > Danish mailing list > Danish@ietf.org > https://www.ietf.org/mailman/listinfo/danish > --=20 *Ash Wilson* | Technical Director *e:* ash.wilson@valimail.com 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. --0000000000001c06a105bfcacf31 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Michael,
Thanks for the heads-up on that thre= ad. While there's no apparent mention of DANISH, I think that some of t= hese discussion points will re-emerge... especially when we talk about a tr= ansitional mode for DANE.=C2=A0
I'll definitely be revisiting that = thread as DANISH evolves.

-Ash

On Sun, Apr 11= , 2021 at 1:16 PM Michael Richardson <mcr+ietf@sandelman.ca> wrote:

There is a long thread about QUIC, DNS lookups and DANE on ietf@ietf.org.
here is one message: https://m= ailarchive.ietf.org/arch/msg/ietf/CLB6HCPcwrQMdLtmcBH_EmjTBNc

It has problem become one of these ping-pong threads.
If there is some useful conclusion to DANISH, I haven't found it yet.
I have started writing a strawman charter for DANISH, but I have been
interrupted by AUTH48 processes.=C2=A0 (yes! more than one! Woohoo!)






--
Michael Richardson <mcr+IETF@sandelman.ca>=C2=A0 =C2=A0. o O ( IPv6 I=C3=B8T co= nsulting )
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Sandelman Software Works Inc, Otta= wa and Worldwide




--
Danish mailing list
Danish@ietf.org https://www.ietf.org/mailman/listinfo/danish


--

Ash Wilson | Technical Dire= ctor

=

This email and all d= ata transmitted with it contains confidential and/or proprietary informatio= n 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 o= f 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 sy= stem.

--0000000000001c06a105bfcacf31-- From nobody Wed Apr 14 11:47:35 2021 Return-Path: X-Original-To: danish@ietfa.amsl.com Delivered-To: danish@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60FD23A1B4E for ; Wed, 14 Apr 2021 11:47:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.087 X-Spam-Level: X-Spam-Status: No, score=-2.087 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=valimail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XIHwLKSdCSs7 for ; Wed, 14 Apr 2021 11:47:29 -0700 (PDT) Received: from mail-qv1-xf36.google.com (mail-qv1-xf36.google.com [IPv6:2607:f8b0:4864:20::f36]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E59F3A1B4D for ; Wed, 14 Apr 2021 11:47:29 -0700 (PDT) Received: by mail-qv1-xf36.google.com with SMTP id i11so4913481qvu.10 for ; Wed, 14 Apr 2021 11:47:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=MnGFi7YJHgB+rn63ICZxYpCPEql3aofQapmS7FNbiEA=; b=MtYwwSWmuoycPCRfnFxo/xISsaW0uCF0k4b2jWL5ELV9xakFZYzRW68BxaGglbEd4E CW49zlrS054cleyR+uOpJPzxy+3iJTBeZS2+2409Cac69Lqb95dd14wYGPK5vj7xYQYV E0znT/vTQFBvm9iscYmOjT4/HKQzyMm5h0VXMA/5kIXqsYa7mlgdr7z7ijPPlRlODcU6 goBHzkLhVy/EMQEDRrpWt4BFvFCBJD5kkbv9Lzl2YNZBdFtvrZBM4alYMKRom2nKy9dC zwgDv/nlUAqYErXbMA70v0xBsNxtcmYru5TWYaILVMpMFwmKoO+29/foV1IHtwCh0ukt OSRA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=MnGFi7YJHgB+rn63ICZxYpCPEql3aofQapmS7FNbiEA=; b=OClSkqCLYZVYU/siC5PfHf8LXip+WbECxDT1Jf5NL/bqZZyJMHUWkojsvh/poLqosu xpLph25hKbu81RvZEHzpOlvWCdrFifFfK7uMf4Yo9HJjxCkT3tsw7+ESH4lm7rrzkWs9 nCg091nvnUr4SxVrYbn4xgWoho0gKATPNC/HnEbSb1E0EUwyNLO79FnTXBmAA12vwE+D A2Z00hwcmSfjSEjGit/GggOyWMYR32f8x/MQMFqlJwPeoHQNaiULX0V+fPG4ZDJWOJdE olPh1hsdS8fLL+NsM77+hfNj5Jv9W3OonXKTRmmjjV1UelnrllrizfNKckQzv7sbgvKE 63CA== X-Gm-Message-State: AOAM530xXlGRBgdDrxQNPP4V6A52BAriNPQSwTtiLGvnFvfuRv7UQIUg uOGp3d0L50vplmJy9yxY1mggJ58aNsupRSAPkg0ZwV2wGzQ= X-Google-Smtp-Source: ABdhPJw5Ku3EDjed0ma/aeOJFnrfeQC8o0A1AcDp/i5ncyAVf/vFeeGLtSfDXd7EpVmgaQsZbHnXKDgPbCiowzXqxwE= X-Received: by 2002:a0c:9e17:: with SMTP id p23mr26323348qve.7.1618426047249; Wed, 14 Apr 2021 11:47:27 -0700 (PDT) MIME-Version: 1.0 References: <60658198.2070902@openfortress.nl> <6066BAC6.2000801@openfortress.nl> <60680D1F.8060004@openfortress.nl> <606C25C5.1000105@openfortress.nl> In-Reply-To: <606C25C5.1000105@openfortress.nl> From: Ash Wilson Date: Wed, 14 Apr 2021 11:47:16 -0700 Message-ID: To: Rick van Rein Cc: danish@ietf.org Content-Type: multipart/alternative; boundary="000000000000a4527c05bff32d9c" Archived-At: Subject: Re: [Danish] Application-Independent Client Identity through DANE X-BeenThere: danish@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Apr 2021 18:47:34 -0000 --000000000000a4527c05bff32d9c Content-Type: text/plain; charset="UTF-8" Hi Rick, Sorry to keep you waiting on a reply. I agree with you that we will need a registry of identity grouping labels, if the construct does not fit within another existing registry. The use case for discovering CA certificates makes sense to me, and with such a mechanism, you can simplify the use of private PKI for establishing TLS sessions. Having an underscore label representing the client identity type, immediately to the left of the identity grouping label, could fit for generic discovery of CA certificates via TLSA records, secured by DNSSEC. This sounds like it would require a change in how TLS works, and for this case we will also need a registry of client identity types. But I think this might work, and it doesn't necessarily need to carry the complexity of the PKIX-CD discovery pattern as long as you have DNSSEC configured for your zone. What are your thoughts on signing and encryption for object security use cases? How do you see entity certificate discovery happening? -Ash On Tue, Apr 6, 2021 at 2:11 AM Rick van Rein wrote: > Hello Ash, > > > This is interesting. So, let me summarize what I understand so far: this > > provides a way of conveying an organization's CA so that any sub-identity > > may be authenticated without explicitly creating a record for every > > sub-identity in DNS. Is my understanding correct? > > Yes. Although I barely focus on finding certificates, as I am assuming > a rich user or server environment. It's interesting though. > > The central idea is to trust a domain on the basis of (root or > intermediate) CA certificates in DANE; they might be stored or hashed in > DNS. > > > Here's an overlap (maybe): In the PKIX-CD draft ( > > https://datatracker.ietf.org/doc/draft-wilson-dane-pkix-cd/) we present > a > > method by which an authenticating entity may use the EE's DNS name and > AKI > > (both found in the certificate) to construct a URL for discovering the CA > > certificate. > > That is an interesting idea, and perhaps not specific to client DANE. I > would venture to guess that it solves a general problem, possibly even > of finding a root CA that may be solely trusted on grounds of DANE. I > was lazily proposing to put whole certificates into DNS, perhaps even > for intermediate CAs. > > > Even if you don't publish the EE certs for DNS-based identities in DNS, > you > > can still use DNS to discover the trust chains. You can still get the DNS > > name or email address out of the presented certificate and use that with > > the AKI to construct a URL where the intermediate certificate that can > > verify the EE certificate should be found. > > Yes. This is also a way to get away from a large-but-limited set of > well-known CAs, so it might help in applications that are more diverse, > such as a domain-local CA or even peer-to-peer networks that employ DNS. > > > If this pattern works for your use case, then you'll have some > > cross-compatibility for other use cases, where we do need the certificate > > to be discoverable in DNS (object security use cases) as well as having a > > sort of transitional mode between traditional PKI and DANE for > > authentication, both hinging around DNS names for entities. > > I think it *almost* works. > > Your "_device" is an example of an identity grouping label, but it is > not clear to me if this is something that is formally registered or a > local network choice. > > When formally registered, a specification could be attached that defines > the semantics of that name. As a consequence, it would be possible to > visit completely foreign domains for the first time to discover what > their certificates are saying. The shared semantics are the pivotal > point here; applications need to know what they can assume when they > find such a label. This is a reason why SRV records work so well, yet > are flexible for new specifications to adopt. > > It would be possible to make a choice to trust only configured domains > to set a configured _label. Then, anyone can add names without > formalities, but a label _client-identity would not have necessary > meaning; the domain owner would not be expressing anything but data, > with no necessarily implied meaning. So this idea of registered naming > is vital to the idea of Realm Crossover. > > The ideas of with/without semantics can both be used with a _label that > says "make no assumptions, unless you were configured to look underneath > this one". > > Can you elaborate on that please? > > > Cheers, > -Rick > -- *Ash Wilson* | Technical Director *e:* ash.wilson@valimail.com 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. --000000000000a4527c05bff32d9c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Rick,
Sorry to=C2=A0keep you waiting on = a reply.
I agree with you that we will need a registry of identity gro= uping labels,=C2=A0if the construct does not fit within another existing re= gistry.

The use case for discovering CA certificates mak= es sense to me, and with such a mechanism, you can simplify the use of priv= ate PKI for establishing TLS sessions. Having an underscore label represent= ing the client identity type, immediately to the left of the identity group= ing label, could fit for generic discovery of CA certificates via TLSA reco= rds, secured by DNSSEC. This sounds like it would require a change in how T= LS works, and for this case we will also need a registry of client identity= types. But I think this might work, and it doesn't necessarily need to= carry the complexity of the PKIX-CD discovery pattern as long as you have = DNSSEC configured for your zone.

What are your tho= ughts on signing and encryption for object security use cases? How do you s= ee entity certificate discovery happening?

-Ash

On Tue, Apr 6, 2021 at 2:11 AM Rick van Rein <rick@openfortress.nl> wrote:
Hello Ash,

> This is interesting. So, let me summarize what I understand so far: th= is
> provides a way of conveying an organization's CA so that any sub-i= dentity
> may be authenticated without explicitly creating a record for every > sub-identity in DNS. Is my understanding correct?

Yes.=C2=A0 Although I barely focus on finding certificates, as I am assumin= g
a rich user or server environment.=C2=A0 It's interesting though.

The central idea is to trust a domain on the basis of (root or
intermediate) CA certificates in DANE; they might be stored or hashed in DNS.

> Here's an overlap (maybe): In the PKIX-CD draft (
> https://datatracker.ietf.org/doc/dra= ft-wilson-dane-pkix-cd/) we present a
> method by which an authenticating entity may use the EE's DNS name= and AKI
> (both found in the certificate) to construct a URL for discovering the= CA
> certificate.

That is an interesting idea, and perhaps not specific to client DANE.=C2=A0= I
would venture to guess that it solves a general problem, possibly even
of finding a root CA that may be solely trusted on grounds of DANE.=C2=A0 I=
was lazily proposing to put whole certificates into DNS, perhaps even
for intermediate CAs.

> Even if you don't publish the EE certs for DNS-based identities in= DNS, you
> can still use DNS to discover the trust chains. You can still get the = DNS
> name or email address out of the presented certificate and use that wi= th
> the AKI to construct a URL where the intermediate certificate that can=
> verify the EE certificate should be found.

Yes.=C2=A0 This is also a way to get away from a large-but-limited set of well-known CAs, so it might help in applications that are more diverse,
such as a domain-local CA or even peer-to-peer networks that employ DNS.
> If this pattern works for your use case, then you'll have some
> cross-compatibility for other use cases, where we do need the certific= ate
> to be discoverable in DNS (object security use cases) as well as havin= g a
> sort of transitional mode between traditional PKI and DANE for
> authentication, both hinging around DNS names for entities.

I think it *almost* works.

Your "_device" is an example of an identity grouping label, but i= t is
not clear to me if this is something that is formally registered or a
local network choice.

When formally registered, a specification could be attached that defines the semantics of that name.=C2=A0 As a consequence, it would be possible to=
visit completely foreign domains for the first time to discover what
their certificates are saying.=C2=A0 The shared semantics are the pivotal point here; applications need to know what they can assume when they
find such a label.=C2=A0 This is a reason why SRV records work so well, yet=
are flexible for new specifications to adopt.

It would be possible to make a choice to trust only configured domains
to set a configured _label.=C2=A0 Then, anyone can add names without
formalities, but a label _client-identity would not have necessary
meaning; the domain owner would not be expressing anything but data,
with no necessarily implied meaning.=C2=A0 So this idea of registered namin= g
is vital to the idea of Realm Crossover.

The ideas of with/without semantics can both be used with a _label that
says "make no assumptions, unless you were configured to look undernea= th
this one".

Can you elaborate on that please?


Cheers,
=C2=A0-Rick


--

Ash Wilson | Technical Dire= ctor

=

This email and all d= ata transmitted with it contains confidential and/or proprietary informatio= n 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 o= f 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 sy= stem.

--000000000000a4527c05bff32d9c-- From nobody Tue Apr 20 01:58:35 2021 Return-Path: X-Original-To: danish@ietfa.amsl.com Delivered-To: danish@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 585A33A18F0 for ; Tue, 20 Apr 2021 01:58:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.119 X-Spam-Level: X-Spam-Status: No, score=-2.119 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=openfortress.nl Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MKxzkMW6Mlv2 for ; Tue, 20 Apr 2021 01:58:28 -0700 (PDT) Received: from lb1-smtp-cloud8.xs4all.net (lb1-smtp-cloud8.xs4all.net [194.109.24.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9E8B3A18F1 for ; Tue, 20 Apr 2021 01:58:25 -0700 (PDT) Received: from popmini.vanrein.org ([83.161.146.46]) by smtp.xs4all.nl with ESMTP id YmD6lPIxBuz3GYmD7lutnY; Tue, 20 Apr 2021 10:58:21 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=openfortress.nl; i=rick@openfortress.nl; q=dns/txt; s=fame; t=1618909091; h=message-id : date : from : mime-version : to : cc : subject : references : in-reply-to : content-type : content-transfer-encoding : date : from : subject; bh=3DTbTIex3HJ/nBljjXtmKhdLHlQ3b4d2pzejFTdSCe4=; b=iabP2t+q8j0sK0sZX+kHXgRzO0Vlr+vQGG+o+W9ycbaZxz7Anj2lQkmt FQHMNDcqpyXU6K3odIiZdQNf0NU0monSKEpHknqrV0QTirvmGD2Nvi6Ab4 z3f4vOa1nLoRWoji0/ulmjSEpRSptQ6J5C87BqPUSqmT8bM+yRAkyUkbY= Received: by fame.vanrein.org (Postfix, from userid 1006) id EDA2A512AC; Tue, 20 Apr 2021 08:58:03 +0000 (UTC) X-Original-To: danish@ietf.org Received: from airhead.local (phantom.vanrein.org [83.161.146.46]) by fame.vanrein.org (Postfix) with ESMTPA id 6C224512A9; Tue, 20 Apr 2021 08:57:57 +0000 (UTC) Message-ID: <607E9793.3060100@openfortress.nl> Date: Tue, 20 Apr 2021 10:57:55 +0200 From: Rick van Rein User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: Ash Wilson CC: danish@ietf.org References: <60658198.2070902@openfortress.nl> <6066BAC6.2000801@openfortress.nl> <60680D1F.8060004@openfortress.nl> <606C25C5.1000105@openfortress.nl> In-Reply-To: X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Bogosity: Unsure, tests=bogofilter, spamicity=0.520000, version=1.2.4 X-CMAE-Envelope: MS4xfBaMZnVmQuE0kcKBJAj3YCE/1YMXdsHsMl9q5SFfnNGqLTxot0LI0BfXZj82zqyJQbcL7V+iqSJzL4LjB0k55DJTwYGzFUlNKfjr0PalyUsa022wHIy3 tbk6o8S56oYVYcANAWgHkO5iwq9UsPQKhVqSnaBGkKDU2AxlXWLw22iIx8bNU8OH/mqljbZTGevx8g== Archived-At: Subject: Re: [Danish] Application-Independent Client Identity through DANE X-BeenThere: danish@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Apr 2021 08:58:33 -0000 Hello Ash, > I agree with you that we will need a registry of identity grouping > labels, if the construct does not fit within another existing registry. I hadn't checked if a suitable registry already exists, but the "Underscored and Globally Scoped DNS Node Names" could be it, because RFC 8552 defines it as just what I had in mind. https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#underscored-globally-scoped-dns-node-names Note that these are "static" _labels, defined under Expert Review, to be assigned structure/semantics while at it, which is what I meant. These are not "dynamic" _node123 labels that could be defined by clients, though that would be possible under a static _label too. I am not sure what you are looking for. > The use case for discovering CA certificates makes sense to me, and with > such a mechanism, you can simplify the use of private PKI for establishing > TLS sessions. Having an underscore label representing the client identity > type, immediately to the left of the identity grouping label, could fit for > generic discovery of CA certificates via TLSA records, secured by DNSSEC. Yes, that's a nice and terse summary of what I have in mind. > This sounds like it would require a change in how TLS works, Not the protocol, but the trust evaluation. It's not that different from server DANE applications though. In fact, trust in a client/peer certificate is often defined locally. One of those local definitions could be to adopt the "CXOVER" or "Certificate Crossover" mechanism. > and for this > case we will also need a registry of client identity types. But I think > this might work, and it doesn't necessarily need to carry the complexity of > the PKIX-CD discovery pattern as long as you have DNSSEC configured for > your zone. This is not mine to judge. > What are your thoughts on signing and encryption for object security use > cases? Before you mentioned sigverify and encrypt, which are the pivotal points where trust is needed. I'd say that the technical operations with these names are not what users need; they need to use them in protocol settings for purposes: authentication, integrity validation, and indeed from-here-to-recipient privacy. > How do you see entity certificate discovery happening? Ehm, use cases... 1. TLS clients would transmit the identity that the want trusted. The other TLS peer retrieves the uid=,dc=,dc= from the certificate and does a TLSA lookup for the dc=,dc= domain to validate the CA and trust the uid=,dc=,dc= remote TLS client. 2. S/MIME signatures https://tools.ietf.org/html/rfc5652#section-5.1 intends for signerInfos-mentioned certificates to be contained in the certificates set. Validation retrieves the uid=,dc=,dc= from the certificate and does a TLSA lookup for the dc=,dc= domain to validate the CA and trust the uid=,dc=,dc= sender identity. S/MIME signatures intend to include the certificate chain. 3. S/MIME encryption https://tools.ietf.org/html/rfc5652#section-5.2 is cryptographically initialised by the sending party, so this is the case that requires download of certificates. To validate the certificate retrieved from such a download, the uid=,dc=,dc= in the certificate is verified against the intended recipient and then the sender does a TLSA lookup or the dc=,dc= domain and validates the downloaded certificate can be trusted; it then sends S/MIME content which intends to include the certificate chain(s). For downloading in 3, I tend to prefer the standards' prescribed choice of LDAP because of its rich semantics. For small devices there may be other considerations, but they are likely to be less rich, and so not a general solution. (BTW, I have made a very small LDAP stack too, but to date it has only been unit-tested.) Inviting opinions :) Cheers, -Rick From nobody Tue Apr 20 02:09:21 2021 Return-Path: X-Original-To: danish@ietfa.amsl.com Delivered-To: danish@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65D723A195A for ; Tue, 20 Apr 2021 02:09:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.108 X-Spam-Level: X-Spam-Status: No, score=-2.108 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=openfortress.nl Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kTI7_5Xyn7dJ for ; Tue, 20 Apr 2021 02:09:14 -0700 (PDT) Received: from lb3-smtp-cloud8.xs4all.net (lb3-smtp-cloud8.xs4all.net [194.109.24.29]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 759953A195C for ; Tue, 20 Apr 2021 02:09:14 -0700 (PDT) Received: from popmini.vanrein.org ([83.161.146.46]) by smtp.xs4all.nl with ESMTP id YmNblPQDpuz3GYmNcluxXW; Tue, 20 Apr 2021 11:09:12 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=openfortress.nl; i=rick@openfortress.nl; q=dns/txt; s=fame; t=1618909742; h=message-id : date : from : mime-version : to : cc : subject : references : in-reply-to : content-type : content-transfer-encoding : date : from : subject; bh=i+sPcRB3KyVZU2PumHCMGI+zaKNwCIQuv59ixCnez+w=; b=EGgA7Gr5gWGBIxbZE7jbLhm/n4/CnYILJRb5z0d4Kp3kEL/GT/RlcmHl x7xoZSQA4bIvt3eAjOzsb43V4+y4Clzr8HgBnBfbHvb25EuoizMArRfuqU ybNl8u07+e46qKfI83w4IScZpm0AH8Ec6YmTTges60KGbSgRRkgWXy3co= Received: by fame.vanrein.org (Postfix, from userid 1006) id 686F6512B1; Tue, 20 Apr 2021 09:08:55 +0000 (UTC) X-Original-To: danish@ietf.org Received: from airhead.local (phantom.vanrein.org [83.161.146.46]) by fame.vanrein.org (Postfix) with ESMTPA id 3D150512AB; Tue, 20 Apr 2021 09:08:55 +0000 (UTC) Message-ID: <607E9A25.9070709@openfortress.nl> Date: Tue, 20 Apr 2021 11:08:53 +0200 From: Rick van Rein User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: Ash Wilson CC: danish@ietf.org References: <60658198.2070902@openfortress.nl> <6066BAC6.2000801@openfortress.nl> <60680D1F.8060004@openfortress.nl> <606C25C5.1000105@openfortress.nl> <607E9793.3060100@openfortress.nl> In-Reply-To: <607E9793.3060100@openfortress.nl> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Bogosity: Unsure, tests=bogofilter, spamicity=0.520000, version=1.2.4 X-CMAE-Envelope: MS4xfI/Pkv0wnJZA9uSeQrbZQ6vJ4bBhtiROfRRzw+SLSgIwuEDQ8dEpRI/STCH0JH2yu6CBqyGPsK6VsCYYD6VR87jwZWLzTn1MqYSzyRlJdAgaUvtTIzo5 GidQHaerXQXQ4PLjOviXKUTJ8GlOTJ4Ew3yqyNiCNZu98QOjQhadEI2iHJ7xRu5JmN8AJBR5+DsPRA== Archived-At: Subject: Re: [Danish] Application-Independent Client Identity through DANE X-BeenThere: danish@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Apr 2021 09:09:20 -0000 Ah, Through the Unscored Named Registry I found a useful RFC: >> How do you see entity certificate discovery happening? Have you seen RFC 4386? (New to me.) There's no _COAP prefix yet, which might be helpful for IoT. -Rick