From nobody Thu Jun 3 15:34: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 B6FC43A1D27 for ; Thu, 3 Jun 2021 15:34:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, 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=cert.org 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 K92WjHUiA9le for ; Thu, 3 Jun 2021 15:33:57 -0700 (PDT) Received: from veto.sei.cmu.edu (veto.sei.cmu.edu [147.72.252.17]) (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 C446E3A1D2C for ; Thu, 3 Jun 2021 15:33:57 -0700 (PDT) Received: from delp.sei.cmu.edu (delp.sei.cmu.edu [10.64.21.31]) by veto.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 153MXuh5045601 for ; Thu, 3 Jun 2021 18:33:56 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 veto.sei.cmu.edu 153MXuh5045601 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1622759636; bh=aR9G9QCfqubL8nX0P0oVEXrGgWYBguD8xFuNJaduLro=; h=From:To:Subject:Date:From; b=AKU569TnVYhz8sC/SSNBZv9H51Scsec1Q8ovpX4wczdCdmtZ6BqUNxSLkH4v5Jwxw DjcZeDTqQCLPIZO5KSN5gqpx3PB/hqpRRrQACP9xZsUlL1odfeFOc6UFcU8AtodCya UCTWflBEv/WrXderZvlLtJVytiwuQMHYwYpYm4xk= Received: from MORRIS.ad.sei.cmu.edu (morris.ad.sei.cmu.edu [147.72.252.46]) by delp.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 153MXrki020099 for ; Thu, 3 Jun 2021 18:33:53 -0400 Received: from MORRIS.ad.sei.cmu.edu (147.72.252.46) by MORRIS.ad.sei.cmu.edu (147.72.252.46) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.4; Thu, 3 Jun 2021 18:33:53 -0400 Received: from MORRIS.ad.sei.cmu.edu ([fe80::555b:9498:552e:d1bb]) by MORRIS.ad.sei.cmu.edu ([fe80::555b:9498:552e:d1bb%13]) with mapi id 15.01.2242.008; Thu, 3 Jun 2021 18:33:53 -0400 From: Roman Danyliw To: "danish@ietf.org" Thread-Topic: [Danish] Proposed DANISH charter Thread-Index: AddYsZHuKMGRqRkSQcSAOxCg1ghvsQ== Date: Thu, 3 Jun 2021 22:33:51 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.202.236] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Danish] Proposed DANISH charter 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, 03 Jun 2021 22:34:03 -0000 Hi! Thanks for all of the work to date in refining the charter. Proposed clari= fications and questions noted below. > -----Original Message----- > On Fri, 21 May 2021 05:24, Ash Wilson wrote: >=20 > Hi everyone, > I've updated the text stating DANE's original purpose, according to > recommendations from Paul and Jacques. >=20 > Any other comments or suggestions for clarification? We've had some dialo= gue > and I want to make sure that anything that's not sufficiently clear for a= charter- > level doc is appropriately addressed. >=20 > ----- > Objective > DANE's original purpose only covered authentication for the TLS server id= entity. > 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 o= f > DANE for domain owners who have not yet implemented DNSSEC.. It would be useful to clarify the applicable use cases of DANISH. The subse= quent text, describes a "messaging security" and "object security" use case= . The text above describes a "client identity and message sender identity = use cases". How many use cases are really in play? It would be unrealisti= c to define them in detail here, but as they are framing the scope of work,= they should at least superficial be introduced. If I understand the objective correctly, would this be a fair restatement (= note that this doesn't address the confusion noted above around the use cas= e names): Objective The now closed DANE working group (WG) produced a mechanism that supported = authentication of TLS server identities via a DNSSEC-secured infrastructure= . Operational experience with DANE has validated the utility of a DNS-enab= led mechanism for discovering authenticated keys, but has also shown that r= eliance on DNSSEC is a significant barrier to adoption. The DANE AutheNtication for Iot Service Hardening (DANISH) WG seeks to exte= nd DANE to encompass client or message sender identities. DANISH will also = define a mechanism for messaging use cases that allows DANE DNS record type= s to be secured by the Web PKI as a transition strategy for domain owners w= ho have not yet implemented a DNSSEC-based trust model. > Problem statement This problem statement text below doesn't seem to motivate the four use cas= es noted above. For example object security noted in the work scope doesn= 't come up at all here. > Using DANE for representing client identities safely allows authenticatio= n > across CAs and prevents impersonation, because DNSSEC is used instead of = a > CA certificate and its associated trust hierarchy to bind an identity's n= ame 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 pri= vate > PKIs participating in application deployment. These are very dense sentences. It made is challenging for me to parse the= problem -- rather it seems to instead state a solution: using DANE for cli= ent identities because DNSEC, secured through the trusted DNS root trust an= chors. It would seem to me that this text should cover the need for client= identities (the DANISH name even applies application for IOT) as motivated= by the second sentence of the objective section (" ... extend the DANE sta= ndard to encompass client identity and message sender identity use cases") = and then transition to the ubiquity and common trust anchor that could be r= elied upon via DANE/DNSSEC Nit, I wouldn't use the phrase "_[e]veryone_ agrees" > The greatest barrier to DANE adoption has been the DNSSEC requirement. > DANISH will seek to provide a method of certificate and trust chain disco= very > for private PKIs, to enable the messaging security use case. This alterna= tive > mode will allow the use of Web PKI to securely discover certificates, in= the > absence of DNSSEC.=20 The messaging use case envisioned here needs more description. Some of the= text also feel duplicative of what's said in the objective and scope of wo= rk. > This allows for a gradual DANE adoption where DNSSEC is > not in the initial set of requirements. If the application owner wishes t= o use > DANE for mutual TLS authentication, the application owner must then > configure DNSSEC for the zone. > Scope of work My proposed edits/comments below are intended to make the discrete lines of= work clear and distinct. > The DANISH group will produce an architecture document describing the > primary application components, and their interaction patterns.=20 This is clear. For symmetry with the text below, I might restate it to be: * Specify the use cases and= an architecture describing the primary application components and their in= teraction patterns > DANISH will > establish usage conventions for DANE DNS records to represent client iden= tity > for TLS connections and how to perform public key discovery for object se= curity > use cases.=20 Is this the same as saying: * Specify operational practices and usage conventions for representing clie= nt identities for TLS connections in DANE DNS records * Standardize a protocol (?) and operational practices for public key disco= very in support of the object security use case > DANISH will also define any required TLS protocol updates to support > client authentication using DANE.=20 Is this the same as saying: * Standardize protocol extensions or updates to TLS v1.3 needed 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 spec= ific > use cases, as a transitional mode from Web PKI to the DNSSEC-based trust > model. This text doesn't seems to align with the style of the rest. Is this the s= ame as saying: ** Standardize a protocol (?) and specify operational practices to use the = Web PKI to discover certificates and trust chains via DANE DNS record types= in the absence of DNSSEC in support of the message security use case Got to this point in the scope of work description. Of the four named use = cases, only object security was called out in this scope. Is there are rea= son for that? > While modifications to the following standards are not within the scope o= f the > DANISH charter, the DANISH working group will take care to ensure a poten= tial > path for interoperability with the following standards, enabling potentia= l future > work: JOSE, COSE, Oauth2, MLS, EAP-TLS, SMIMEA (RFC 8162), SIP (RFC 5922)= , > Proxy headers (RFC 7239), IANA email authentication headers, and TCP prox= y > TLVs standardized by haproxy. I applaud the citation of related work and ensure things are appropriately = coordinated. However, this list seems rather long. A successful DANISH WG= of the future can re-charter when needed. Please list only activities/wor= k that needs active coordination or the work that provides design constrain= ts to the proposed solutions per the specified milestones in this charter. As one of the activities above noted a "define any required TLS protocol up= dates", listing coordination with the TLS working seems helpful. Irrespective of the prose, for a complete charter, milestones with notional= delivery dates are needed. Regards, Roman From nobody Wed Jun 9 12:58:37 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 DFAAF3A241C for ; Wed, 9 Jun 2021 12:58:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.683 X-Spam-Level: X-Spam-Status: No, score=-0.683 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_IMAGE_ONLY_28=1.404, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=no 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 u6OaCMduJwko for ; Wed, 9 Jun 2021 12:58:30 -0700 (PDT) Received: from mail-qt1-x829.google.com (mail-qt1-x829.google.com [IPv6:2607:f8b0:4864:20::829]) (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 B75BB3A241B for ; Wed, 9 Jun 2021 12:58:30 -0700 (PDT) Received: by mail-qt1-x829.google.com with SMTP id e3so7435808qte.0 for ; Wed, 09 Jun 2021 12:58:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:from:date:message-id:subject:to; bh=WTCHZq5dN20pdJ+RPbSLE/rDS3i3ANqcV1NRNUX1m6I=; b=dPK4HRXqmT3tVcMbWW9PDhPtzrKOxJ8ptMQ7gmfvCI4s78OyrGMZEi0YyfTWl8Niis iDL8oHsUnvMrovT7mxffwiQVgySHw4Z1U4LjiYnf+dKfkEvOlZGQkLYo98VPd++rzSDG GozVysae3e+ghdUmUS0jH39cYaz6lSFevk+kS6KcFB4H2ZvHHpknOkk4+sIWfAD15hJT 8/wqmLoalN6BI1GSFKNHIR1qV3kLDFAueuAef7Z3O51gcfxqTY7f7Uotv1cfsI3+9S9w xd5qcxuiykQgnB8fewi7vd03+/5lrfgWfm2cwkN1gVHE5wZcJvLoHMBLulcuG0EEuJ1p ykXg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=WTCHZq5dN20pdJ+RPbSLE/rDS3i3ANqcV1NRNUX1m6I=; b=S+RKnAm3uKq+7OXJ5AlraocP0votZjK5RL7qW/poNb/EZp4qfrcJwrghBv0AEbS6Vr jG+2gUBL5NMj++T/+GoN4cFbgswfrMDMYvZxintvu9TaDwc0Lj+pP4j2jdO0sJs6WjSt 9Ob79+p5kzabouR1KzmMMKoedGxy3u+SA8Qfwl1s4C5viLzqKSbJ1vi18ps7/jL8ad+V W0FrcBdts7JHf8ki99R5RAhduZze/yxWOBxSYUBrXFd+bJyA/iQMlb1FwvC724IfE+qx kvnN9cdMymL3M93hn27nK1UPvRRH3R3ui1E3lQRHVcEjRbr9Zt/k1I7H1yhgh1WttRo+ me5Q== X-Gm-Message-State: AOAM533HhQ4qOkrikZWygzKywcbPmLfd2zZrECcnvTL1y0Ijzy3ZyQ8P Fmuqmau/OG9UxM0DcgcKQdSsNaRXadcGAvehfI8c8XhP2sO7Kw== X-Google-Smtp-Source: ABdhPJwXceWqVANnm2DRdqz6NP+cwCEKAUvcOl5vztFMSSlG7zHEKHx2Vmt4ebN+wB0R249JMuXjtWOjrW6QlNFyOhQ= X-Received: by 2002:ac8:5fd5:: with SMTP id k21mr1654617qta.231.1623268708428; Wed, 09 Jun 2021 12:58:28 -0700 (PDT) MIME-Version: 1.0 From: Ash Wilson Date: Wed, 9 Jun 2021 12:58:17 -0700 Message-ID: To: danish@ietf.org Content-Type: multipart/alternative; boundary="000000000000bdbebe05c45ab276" Archived-At: Subject: [Danish] Walking a trust chain via TLSA records 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, 09 Jun 2021 19:58:36 -0000 --000000000000bdbebe05c45ab276 Content-Type: text/plain; charset="UTF-8" Bringing this on the list for broader discussion... How might one discover an entire certificate chain using just TLSA records? The PKIXCD draft proposes the use of a web URL for certificate chain discovery, but what if we wanted to do all this via TLSA records and DNSSEC? Referencing the labeling pattern in https://www.ietf.org/archive/id/draft-wilson-dane-pkix-cd-01.html#section-3.4, a proposed pattern might be: ${SKI}.${IDENTITY_DOMAIN} For a device with DANE ID 12345._device.vendor.example: the CA certificate which may be used to validate the entity certificate may be found in a TLSA record at ${SKI}._device.vendor.example, where ${SKI} is the subjectKeyID of the CA certificate, which is inferred from the authorityKeyID of the entity certificate. Any thoughts on this? -- *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. --000000000000bdbebe05c45ab276 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Bringing this on the list for broader discussion...
How might one discover an entire certificate chain using just TLSA records= ? The PKIXCD draft proposes the use of a web URL for certificate chain disc= overy, but what if we wanted to do all this via TLSA records and DNSSEC?
Referencing the labeling pattern in https://www.ietf.or= g/archive/id/draft-wilson-dane-pkix-cd-01.html#section-3.4, a proposed = pattern might be:

${SKI}.${IDENTITY_DOMAIN}

For a device with= DANE ID 12345._device.vendor.example: the CA certificate which may be used= to validate the entity certificate may be found in a TLSA record at ${SKI}= ._device.vendor.example, where ${SKI} is the subjectKeyID of the CA certifi= cate, which is inferred from the authorityKeyID of the entity certificate.<= br>
Any thoughts on this?

--

Ash Wilson= | Technical Director

This email and all data transmitted with it contains confiden= tial and/or proprietary information intended solely for the use of individu= al(s) authorized to receive it. If you are not an intended and authorized r= ecipient you are hereby notified of any use, disclosure, copying or distrib= ution of the information included in this transmission is prohibited and ma= y be unlawful. Please immediately notify the sender by replying to this ema= il and then delete it from your system.

--000000000000bdbebe05c45ab276-- From nobody Wed Jun 9 13:38:36 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 4440A3A2559 for ; Wed, 9 Jun 2021 13:38:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-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 14B4_PjjMW3b for ; Wed, 9 Jun 2021 13:38:33 -0700 (PDT) Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (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 E1CB23A2557 for ; Wed, 9 Jun 2021 13:38:32 -0700 (PDT) Received: by straasha.imrryr.org (Postfix, from userid 1001) id CD049C15B1; Wed, 9 Jun 2021 16:38:30 -0400 (EDT) Date: Wed, 9 Jun 2021 16:38:30 -0400 From: Viktor Dukhovni To: danish@ietf.org Message-ID: Reply-To: danish@ietf.org References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Archived-At: Subject: Re: [Danish] Walking a trust chain via TLSA records 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, 09 Jun 2021 20:38:35 -0000 On Wed, Jun 09, 2021 at 12:58:17PM -0700, Ash Wilson wrote: > Bringing this on the list for broader discussion... > > How might one discover an entire certificate chain using just TLSA records? > The PKIXCD draft proposes the use of a web URL for certificate chain > discovery, but what if we wanted to do all this via TLSA records and DNSSEC? Can you explain what problem this is intended to solve? It is rather unclear why or wherefore "discovering the entire" chain is something one needs to do. In many protocols, including e.g. TLS and S/MIME, the presented signature certificates are a complete chain, and all one needs to do is validate that chain via a suitable trust-anchor. With a traditional PKI that trust anchor is one of many static locally trusted CAs. With DANE, that trust anchor is provided via a TLSA record, that chains back via signed DS/DNSKEY pairs to the root DNSKEY RRSet. Either way, whatever chain you intended to "discover" should be presented by whoever signed the message along with the signature. The only thing remaining to "discover" is the applicable trust anchor. -- Viktor. From nobody Sat Jun 12 08:25:27 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 6EAC73A16F8 for ; Sat, 12 Jun 2021 08:25:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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_NONE=-0.0001, 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 hlnreDlJbVmB for ; Sat, 12 Jun 2021 08:25:20 -0700 (PDT) Received: from mail-qv1-xf35.google.com (mail-qv1-xf35.google.com [IPv6:2607:f8b0:4864:20::f35]) (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 737243A16FA for ; Sat, 12 Jun 2021 08:25:20 -0700 (PDT) Received: by mail-qv1-xf35.google.com with SMTP id x6so13280557qvx.4 for ; Sat, 12 Jun 2021 08:25:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:from:date:message-id:subject:to; bh=+uwROYO4BdZWY68vLwdQ5AHzeP28YFutV+aFxaJWdA0=; b=OL9tvM38WEKsBMILBuwxScQQpWnjnQ1L13hdYw7lM1pe2+CWlkdZQ3IF2d/OB8Td14 tK/ZmJVd5qmf5rqf/WRL4zXK0uV48AnLoo//PO6zoVJsJYZAQy9GNKMSN/6Nq+u5r0rp qNL44g6WZkZyEcHTXbBtzSl9/2WilkLwbChi0EdaVep5cnmNy7T0r0rP4PPAYzD0AaVF +vF3y3nNAg+uy0gzsNpdVznntVaUP6Kbg5YBM5t4XVaCBflPvzjV7sUn4A6DT3vr9bD+ YrVmYI8LblL1lc0V66+8NEOzvDGiWLoZZ7Ly45sANrhv31yaRMJgrfv7WquiJlYNO1BE Q3OA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=+uwROYO4BdZWY68vLwdQ5AHzeP28YFutV+aFxaJWdA0=; b=ThZ8bGM1wul7D+PRQf9KdhD45pvlWXI+ggOcWz6eDaYovS6eJsmi9XB2r2S3rdxn4s 7RJ9lgbpCqDuAIvjwQPLSnHx6h1CJuwRPJUepUf7Nalgd5ymFvw2h5qK5HIEobXRP+Nl 6MCyPFG91S+HQhkVo5henXy1JZKanHGEfmWI3isxnyfqbGIoPVfzXdMv5gC+1QORZPov N33ZbuQAWqikOunCktzfJ/B992XdlIm6K/6iqn8yqr7llxtWyUXtyeW5bQZIiW6N3T/7 YxZDbB35ul6hESLy2hujbBbha66ZRBmJMZ88JAYGFzHsSVJ3Cq6I7Vr4DI2VQXFk983A Rg/Q== X-Gm-Message-State: AOAM531Vqw/XFNPPWQg+g2gSowuaPL+LQ24a8vcqnCu7SuuiQtvcQahE Ajyz9bKFnOI/cE7NAcF/fmnkIkwgQtToSELKlOyZqZLrk/x+ww== X-Google-Smtp-Source: ABdhPJx7MGY676ZJjadMG54dfAQs+aICqIU9beVTN+nUm0W2imbt6YyXgx/Zn5loBwEsa2mMF4ly1BboQ75zlzEDYfE= X-Received: by 2002:a0c:e54c:: with SMTP id n12mr10293189qvm.20.1623511518300; Sat, 12 Jun 2021 08:25:18 -0700 (PDT) MIME-Version: 1.0 From: Ash Wilson Date: Sat, 12 Jun 2021 08:25:07 -0700 Message-ID: To: danish@ietf.org Content-Type: multipart/alternative; boundary="000000000000565db105c4933b7f" Archived-At: Subject: [Danish] Proposed WG Charter 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, 12 Jun 2021 15:25:26 -0000 --000000000000565db105c4933b7f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Greetings, This is the final text for the proposed charter. We are seeking support for the formation of the working group, as well as support for implementation, adoption, and documentation efforts. -- -Objective The now closed DANE working group (WG) produced a mechanism that supported authentication of TLS server identities via a DNSSEC-secured infrastructure. Operational experience with DANE has validated the utility of a DNS-enabled mechanism for discovering authenticated keys, but has also shown that reliance on DNSSEC is a significant barrier to adoption. The DANE AutheNtication for Iot Service Hardening (DANISH) WG seeks to extend DANE to encompass TLS client and message sender identities. DANISH will also define a mechanism for messaging use cases that allows DANE DNS record types to be secured by the Web PKI as a transition strategy for domain owners who have not yet implemented a DNSSEC-based trust model. -Problem statement The process of establishing trust in public-key-authenticated identity typically involves the use of a Public Key Infrastructure (PKI), and a shared PKI root of trust between the parties exchanging public keys. A Certificate Authority (CA) is one example of a PKI which can be used for establishing trust in public keys. CAs only guarantee the uniqueness of an identity=E2=80=99s name within the context of the CA, and multiple CAs may = sign certificates for different entities bearing the same name. DNSSEC is another PKI, which is bound to the DNS namespace. The DNS namespace, together with DNSSEC, forms the most widely-recognized namespace and authenticated discovery mechanism on the Internet. DANE builds on this authenticated discovery mechanism to enable public key-based TLS authentication which is resilient to impersonation, but only for TLS server identities. The use of CA-based PKI alone for client and message sender authentication creates the possibility of naming collisions when multiple CAs are trusted within the same application. In response to the challenges related to ambiguity between identities issued by different CAs, application owners frequently choose to onboard IoT devices to a single CA. This process of credential issuance can be time-consuming, which is further exacerbated by the sheer number of entities participating in large-scale IoT deployments. Expanding the use cases for DANE to support the representation of TLS client and message sender identities will enable unambiguous authentication across CAs, for client/server TLS sessions as well as message-oriented information flows. The greatest barrier to DANE adoption has been the DNSSEC requirement. DANISH will provide a method of certificate and trust chain discovery for private PKIs, to enable the messaging security use case, in a manner which will work securely in the absence of DNSSEC. This allows for a gradual DANE adoption where DNSSEC is not in the initial set of requirements. -Scope of work DANISH will specify the TLS session and message security use cases and an architecture describing the primary components and 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 message security use cases, like the establishment of message sender identity. DANISH will coordinate with the TLS working group to define any required TLS v1.3 protocol updates required to support client authentication using DANE. DANISH will standardize a protocol and specify operational recommendations for the use of Web PKI to authenticate the discovery of private PKI certificates and trust chains via DANE DNS record types, in the absence of DNSSEC, in support of the message security use case. 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:SMIMEA (RFC 8162), Proxy headers (RFC 7239), IANA email authentication headers, and TCP proxy TLVs standardized by haproxy. -Deliverables: DANISH architecture document 9 months DANE for client certificates (current draft) 6 months DANE for TLS client authentication (current draft) 6 months DANE Transitional Mode Definition and Operational Guidance (non-DNSSEC) 1 year --=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. --000000000000565db105c4933b7f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Greetings,

This is the final text for t= he proposed=C2=A0charter. We are seeking support for the formation of the w= orking group, as well as support for implementation, adoption, and document= ation efforts.

--
-Objective
The no= w closed DANE working group (WG) produced a mechanism that supported authen= tication of TLS server identities via a DNSSEC-secured infrastructure.=C2= =A0 Operational experience with DANE has validated the utility of a DNS-ena= bled mechanism for discovering authenticated keys, but has also shown that = reliance on DNSSEC is a significant barrier to adoption.

The DANE Au= theNtication for Iot Service Hardening (DANISH) WG seeks to extend DANE to = encompass TLS client and message sender identities. DANISH will also define= a mechanism for messaging use cases that allows DANE DNS record types to b= e secured by the Web PKI as a transition strategy for domain owners who hav= e not yet implemented a DNSSEC-based trust model.

-Problem statement=
The process of establishing trust in public-key-authenticated identity = typically involves the use of a Public Key Infrastructure (PKI), and a shar= ed PKI root of trust between the parties exchanging public keys. A Certific= ate Authority (CA) is one example of a PKI which can be used for establishi= ng trust in public keys. CAs only guarantee the uniqueness of an identity= =E2=80=99s name within the context of the CA, and multiple CAs may sign cer= tificates for different entities bearing the same name. DNSSEC is another P= KI, which is bound to the DNS namespace.

The DNS namespace, togethe= r with DNSSEC, forms the most widely-recognized namespace and authenticated= discovery mechanism on the Internet. DANE builds on this authenticated dis= covery mechanism to enable public key-based TLS authentication which is res= ilient to impersonation, but only for TLS server identities.

The use= of CA-based PKI alone for client and message sender authentication creates= the possibility of naming collisions when multiple CAs are trusted within = the same application. In response to the challenges related to ambiguity be= tween identities issued by different CAs, application owners frequently cho= ose to onboard IoT devices to a single CA. This process of credential issua= nce can be time-consuming, which is further exacerbated by the sheer number= of entities participating in large-scale IoT deployments.

Expanding= the use cases for DANE to support the representation of TLS client and mes= sage sender identities will enable unambiguous authentication across CAs, f= or client/server TLS sessions as well as message-oriented information flows= .

The greatest barrier to DANE adoption has been the DNSSEC require= ment. DANISH will provide a method of certificate and trust chain discovery= for private PKIs, to enable the messaging security use case, in a manner w= hich will work securely in the absence of DNSSEC. This allows for a gradual= DANE adoption where DNSSEC is not in the initial set of requirements.
<= br>-Scope of work
DANISH will specify the TLS session and message securi= ty use cases and an architecture describing the primary components and inte= raction patterns.

DANISH will establish usage conventions for DANE = DNS records to represent client identity for TLS connections and how to per= form public key discovery for message security use cases, like the establis= hment of message sender identity.

DANISH will coordinate with the T= LS working group to define any required TLS v1.3 protocol updates required = to support client authentication using DANE.

DANISH will standardiz= e a protocol and specify operational recommendations for the use of Web PKI= to authenticate the discovery of private PKI certificates and trust chains= via DANE DNS record types, in the absence of DNSSEC, in support of the mes= sage security use case.

While modifications to the following standa= rds are not within the scope of the DANISH charter, the DANISH working grou= p will take care to ensure a potential path for interoperability with the f= ollowing standards, enabling potential future work:SMIMEA (RFC 8162), Proxy= headers (RFC 7239), IANA email authentication headers, and TCP proxy TLVs = standardized by haproxy.

-Deliverables:
DANISH architecture docum= ent
9 months
DANE for client certificates (current draft)
6 mont= hs
DANE for TLS client authentication (current draft)
=C2=A0 6 month= s
DANE Transitional Mode Definition and Operational Guidance (non-DNSSEC= )
1 year



--

Ash Wilson | Technical Director

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

--000000000000565db105c4933b7f-- From nobody Sat Jun 12 09:56:15 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 649683A19C4 for ; Sat, 12 Jun 2021 09:56:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 6QvFpWg4ajp6 for ; Sat, 12 Jun 2021 09:56:07 -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 B82A43A19C3 for ; Sat, 12 Jun 2021 09:56:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 6D8DD38B37 for ; Sat, 12 Jun 2021 12:57:04 -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 oh4-sNoLhlZf for ; Sat, 12 Jun 2021 12:57:04 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id E152338B30 for ; Sat, 12 Jun 2021 12:57:03 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 902DA78B for ; Sat, 12 Jun 2021 12:56:04 -0400 (EDT) From: Michael Richardson To: danish@ietf.org In-Reply-To: References: 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: Re: [Danish] Proposed WG Charter 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, 12 Jun 2021 16:56:13 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Thanks Ash for doing such a good job on this charter. {I appologize for being rather lame in responding to the charter discussions in the past few weeks... some kind of COVID induced mid-life depression around turning 50, and being unable to stay up all night writing code} The charter feels a bit long/detailed I think, with content that maybe belongs in a problem statement draft.... But, if the IESG doesn't mind that, I don't. Some thoughts as I read it again: > but has also > shown that reliance on DNSSEC is a significant barrier to adoption. also: > The greatest barrier to DANE adoption has been the DNSSEC requirement. Reading this, I wonder if we really understand why DNSSEC has been so hard = to get deployed among Enterprise entities. TLDs have done it, because ICANN forced them to. As evidence, we don't need DLV anymore (I was involved in running it, and decommissioning it). What I'm trying to say/ask: if there in fact some work in understanding this? An increasing number of DNS Registrars support DS records, and CDS is supposed to make this even easier. Adding DNSSEC to a DNS server seems (to me), *significantly* easier than operating a private CA, but its also apples vs oranges. > This allows for a gradual DANE > adoption where DNSSEC is not in the initial set of requirements. It seems that if we make something that makes DNSSEC less important, that DNSSEC will never become important. > In response to the challenges related to ambiguity between identities > issued by different CAs, application owners frequently choose to onboard > IoT devices to a single CA. This process of credential issuance can be > time-consuming, which is further exacerbated by the sheer number of > entities participating in large-scale IoT deployments. So I understand why a single CA solves the potential identity confusion. I don't understand why the scale matters here. That sentence seems almost a non-sequitor. I think that the charter needs to introduce the message use case. Or maybe delegate that more clearly. =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+93Q3WUFAmDE5yQACgkQgItw+93Q 3WX0eQf+Igm2IOntqOZ/9oZ+GDMwhOw0eV+27T5R2ccfFP8OnCvW0NXoxnm/Rr6w ykmxZ/YdNxx4Dh2H6DnO06m8/mqUO31nOAMHT8X9G6DhbeJgG8uZ2jQ68w9elJKG EpAaGRc+q8goDMDi335B2eOzZX2v18jYj+iDD8+uJLfCWcXj7biYBfqwd4FYWyyY ZtuU4K8tX6jnnFPW1CQu/VK5abC15f1O3tD93zAR9sZuV0GE/1Aq9dlf6NRfR+2I fqrSsEfVKaCIjE+ytGDM7NvqvIKOsShrB1jZs8Fq06iaw4I2fjm1t6MDOw+Qyp/d 7FmgYC/sV3GuaKrt87TQcGCv1Wwm5Q== =tOOa -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun Jun 13 13:52:49 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 961613A0D64 for ; Sun, 13 Jun 2021 13:52:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 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] 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 Z8hkoJy8HfUZ for ; Sun, 13 Jun 2021 13:52:45 -0700 (PDT) Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (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 C20443A0D66 for ; Sun, 13 Jun 2021 13:52:44 -0700 (PDT) Received: by straasha.imrryr.org (Postfix, from userid 1001) id 3029CC424D; Sun, 13 Jun 2021 16:52:43 -0400 (EDT) Date: Sun, 13 Jun 2021 16:52:43 -0400 From: Viktor Dukhovni To: danish@ietf.org Message-ID: Reply-To: danish@ietf.org References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Archived-At: Subject: Re: [Danish] Proposed WG Charter 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, 13 Jun 2021 20:52:48 -0000 On Sat, Jun 12, 2021 at 08:25:07AM -0700, Ash Wilson wrote: > This is the final text for the proposed charter. We are seeking > support for the formation of the working group, as well as support for > implementation, adoption, and documentation efforts. I see that others have commented positively on the charter, and yet somehow for me it seems rather muddled. It is not clear to me what the motivating use-cases really are, nor how DANISH would resolve the key difficulties in those use-cases. There is no explanation of whether the perceived barriers to DNSSEC adoption are on the authoritative or resolver side, or who are the primary intended users (consumer, enterprise, other?) for PKI a la DANISH. > The now closed DANE working group (WG) produced a mechanism that > supported authentication of TLS server identities via a DNSSEC-secured > infrastructure. Operational experience with DANE has validated the > utility of a DNS-enabled mechanism for discovering authenticated keys, > but has also shown that reliance on DNSSEC is a significant barrier to > adoption. The term "discovering authentication keys" is not defined here. It is not clear that avoiding DNSSEC will make things simpler. Which is the more important barrier here, zone signing, or access to validating resolvers? > The DANE AutheNtication for Iot Service Hardening (DANISH) WG seeks to > extend DANE to encompass TLS client and message sender identities. Extending DANE to client auth is certainly an option for "devices" that one might reasonably want to register in DNS. > DANISH will also define a mechanism for messaging use cases that > allows DANE DNS record types to be secured by the Web PKI as a > transition strategy for domain owners who have not yet implemented a > DNSSEC-based trust model. The phrase "DANE DNS record types" is not defined. Nor is it clear what it might for DNS records to be "secured by the Web PKI". Here you speak of "domain owners", placing the focus on the signer side. Signing domains, and keeping them signed, is at this point sufficiently easy, that there's no longer any justifiable reason to design work-arounds for barriers to zone signing. If that's the obstacle, I am not at all sympathetic to ugly work-arounds that simply postpone doing it right. > A Certificate Authority (CA) is one example of a PKI which can be used for FWIW, the established term of art is "Certification Authority". > establishing trust in public keys. CAs only guarantee the uniqueness of an > identity’s name within the context of the CA, and multiple CAs may sign > certificates for different entities bearing the same name. DNSSEC is > another PKI, which is bound to the DNS namespace. The use of "uniqueness" here is rather unclear. There's nothing wrong with multiple certificates each binding a key to some shared name, it just means that all the keys are associated with the same subject. Nor is it necessarily a problem if such bindings are obtained from multiple CAs (provided they are all properly validated and authorised). > The DNS namespace, together with DNSSEC, forms the most widely-recognized > namespace and authenticated discovery mechanism on the Internet. Not clear what this is intended to convey. > DANE builds on this authenticated discovery mechanism to enable public > key-based TLS authentication which is resilient to impersonation, but > only for TLS server identities. More precisely, how one locates the relevant RFC6698/7671 TLSA records for use with TLS is presently only defined for the server side of a TLS connection. > The use of CA-based PKI alone for client and message sender authentication > creates the possibility of naming collisions when multiple CAs are trusted > within the same application. It is rather unclear what this is getting at. Perhaps it i trying to evoke lack of effective name constraints in the WebPKI? > In response to the challenges related to ambiguity between identities > issued by different CAs, application owners frequently choose to > onboard IoT devices to a single CA. Again, what exactly is this tryign to get at? > Expanding the use cases for DANE to support the representation of TLS > client and message sender identities will enable unambiguous authentication > across CAs, for client/server TLS sessions as well as message-oriented > information flows. It seems that solving "ambiguity" is a major concern. So the term needs a clear definition and some motivating examples. > The greatest barrier to DANE adoption has been the DNSSEC requirement. But which barriers if any are applicable to the DANISH use-case? DNSSEC zone signing? DNSSEC resolution on roaming devices? Or tools to automate publishing data in DNS (signed or not), monitoring, ... > DANISH will provide a method of certificate and trust chain discovery for > private PKIs, What is "trust chain discovery"? How is different from including all the relevant certificates with the message? What is "certificate discovery"? What makes these relevant to IoT? > to enable the messaging security use case, in a manner which will work > securely in the absence of DNSSEC. Why is avoiding DNSSEC simpler than making it more compelling to deploy? > -Scope of work > DANISH will specify the TLS session and message security use cases and an > architecture describing the primary components and interaction patterns. I think the charter should go some way to clarifying the intended use cases. -- Viktor. From nobody Sun Jun 13 15:21:57 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 88D683A11BD for ; Sun, 13 Jun 2021 15:21:55 -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, SPF_HELO_NONE=0.001, SPF_NONE=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=nohats.ca 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 BmtZOdJpRPjk for ; Sun, 13 Jun 2021 15:21:50 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (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 C6BCF3A11B8 for ; Sun, 13 Jun 2021 15:21:50 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 4G38FQ3HgJzCb7 for ; Mon, 14 Jun 2021 00:21:46 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1623622906; bh=d98VKBhpnd8FOS/xJGUyW1IxAC4J1MZYGN4UNBr37ys=; h=From:Subject:Date:References:In-Reply-To:To; b=KdBi8At/adXBLjP1XvUnKRdur5uP98PnuGsePYxAnnyrMh/D94c3RyocJD4d15JYU z4YwAsjZghhQC1/ltuFuvz1gn6ecLoSTaAhWYjZVjMmi0+R41nR/yDvfAz8qz0Lf7M PJUVdrBmU5vk7de1juGVTN7IJWsLbFHh4Fz4TzvM= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id AiC5QnvSVU6Q for ; Mon, 14 Jun 2021 00:21:45 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [193.110.157.194]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS for ; Mon, 14 Jun 2021 00:21:45 +0200 (CEST) Received: from smtpclient.apple (unknown [193.110.157.209]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by bofh.nohats.ca (Postfix) with ESMTPSA id D237182456 for ; Sun, 13 Jun 2021 18:21:43 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Paul Wouters Mime-Version: 1.0 (1.0) Date: Sun, 13 Jun 2021 18:21:42 -0400 Message-Id: References: In-Reply-To: To: danish@ietf.org X-Mailer: iPhone Mail (18E212) Archived-At: Subject: Re: [Danish] Proposed WG Charter 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, 13 Jun 2021 22:21:56 -0000 On Jun 13, 2021, at 16:52, Viktor Dukhovni wrote: >=20 > =EF=BB=BFOn Sat, Jun 12, 2021 at 08:25:07AM -0700, Ash Wilson wrote: >=20 >> This is the final text for the proposed charter. We are seeking >> support for the formation of the working group, as well as support for >> implementation, adoption, and documentation efforts. >=20 > I see that others have commented positively on the charter, and yet > somehow for me it seems rather muddled. It is not clear to me what > the motivating use-cases really are, nor how DANISH would resolve > the key difficulties in those use-cases. Same here. I did give feedback in the past already but especially the =E2=80= =9Cclient verification with and without dnssec=E2=80=9D seem to be two widel= y different problems. And the one without dnssec (webpki) already exists ? > Extending DANE to client auth is certainly an option for "devices" that > one might reasonably want to register in DNS. I have given this some thought in the last few weeks and I haven=E2=80=99t b= een able to find a use case where one actually wants client authentication u= sing some IoT device on mobile data network. All use cases I can think of wo= uld not want to expose the client via public dnssec key registry or via publ= ic CA certs. I=E2=80=99d love to hear an example practical use case for DANI= SH. Paul= From nobody Sun Jun 13 16:04:36 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 CE2DD3A139C for ; Sun, 13 Jun 2021 16:04:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 BTp0O7oEokju for ; Sun, 13 Jun 2021 16:04:30 -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 071AE3A1399 for ; Sun, 13 Jun 2021 16:04:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 693B738B1E for ; Sun, 13 Jun 2021 19:05:31 -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 M1xEyATkUkQI for ; Sun, 13 Jun 2021 19:05:30 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id B83DF38AF1 for ; Sun, 13 Jun 2021 19:05:30 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id B57E3C9B for ; Sun, 13 Jun 2021 19:04:26 -0400 (EDT) From: Michael Richardson To: danish@ietf.org In-Reply-To: References: 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: Re: [Danish] Proposed WG Charter 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, 13 Jun 2021 23:04:35 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Viktor Dukhovni wrote: >> The now closed DANE working group (WG) produced a mechanism that >> supported authentication of TLS server identities via a DNSSEC-secur= ed >> infrastructure. Operational experience with DANE has validated the >> utility of a DNS-enabled mechanism for discovering authenticated key= s, >> but has also shown that reliance on DNSSEC is a significant barrier = to >> adoption. > The term "discovering authentication keys" is not defined here. It is > not clear that avoiding DNSSEC will make things simpler. Which is the > more important barrier here, zone signing, or access to validating > resolvers? I think that those are good questions, but it may be too much for a charter. I don't think charters should worry about definitions :-) We had a lot of nodding at the BOF. Looking at the conflicts and having watched the conflicting WG sessions (and who making noise there and not at our BOF) I'm sure that this at least party due to some people being elsewhere :-) >> A Certificate Authority (CA) is one example of a PKI which can be us= ed for > FWIW, the established term of art is "Certification Authority". :-) What a great discussion that was a year ago, eh? >> to enable the messaging security use case, in a manner which will wo= rk >> securely in the absence of DNSSEC. > Why is avoiding DNSSEC simpler than making it more compelling to depl= oy? I see this as a sticking point. Those who like DNSSEC will dislike working around it. Those who think DNSSEC will never sail will use this to sink it. >> -Scope of work >> DANISH will specify the TLS session and message security use cases a= nd an >> architecture describing the primary components and interaction patte= rns. > I think the charter should go some way to clarifying the intended use > cases. I think that's actually more than a charter should say. The charter needs to specific enough to tell people if they are interested = in the problem, and motivate them enough to read a use case document. =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+93Q3WUFAmDGjvoACgkQgItw+93Q 3WVDEAf/VD01Nr9cBWN2ODaIX/UProdUU2Y4j982anFHOlt9NupfPlpkiPCTUtHb EU96Zm2e8tI05vmQGfzIHg9eLrFvN1JtloF0/oJsCXdB4GTgIVyNkqlDJw2L45c0 tBhZrkJ9Cofzwyn3ITNc2gQ2aLUj4C/rU0P8KrI0qbfg3DCpiDT4JgFoXPZccx4t pI9xoSVpY77rgzV5H7c2kFBtKx/jpxnVWPa32mbwqtVv5l9k8uI1EtbeZSz16Yk9 9kZBQgP2ZxtNyYvX6LNw3jGbu1R0LlfI3kBtSnsrVOqKqT0KsLsrTHxGKCSF26Je 6OWd3IXGgKVgyCaD24aeU0oafDxreQ== =4YJE -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun Jun 13 16:14:10 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 279043A13FA for ; Sun, 13 Jun 2021 16:14:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.5 X-Spam-Level: X-Spam-Status: No, score=-1.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.398, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=no 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 Qikp0yP4fptK for ; Sun, 13 Jun 2021 16:14:05 -0700 (PDT) Received: from mail.proper.com (Opus1.Proper.COM [207.182.41.91]) (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 9DC633A13F8 for ; Sun, 13 Jun 2021 16:14:05 -0700 (PDT) Received: from [10.32.60.51] (76-209-242-70.lightspeed.mtryca.sbcglobal.net [76.209.242.70]) (authenticated bits=0) by mail.proper.com (8.15.2/8.15.2) with ESMTPSA id 15DNDipR096882 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Sun, 13 Jun 2021 16:13:46 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: mail.proper.com: Host 76-209-242-70.lightspeed.mtryca.sbcglobal.net [76.209.242.70] claimed to be [10.32.60.51] From: Paul Hoffman To: danish@ietf.org Date: Sun, 13 Jun 2021 16:14:02 -0700 X-Mailer: MailMate (1.14r5798) Message-ID: In-Reply-To: <4978.1623625466@localhost> References: <4978.1623625466@localhost> MIME-Version: 1.0 Content-Type: text/plain; format=flowed Archived-At: Subject: Re: [Danish] Proposed WG Charter 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, 13 Jun 2021 23:14:08 -0000 On 13 Jun 2021, at 16:04, Michael Richardson wrote: > I see this as a sticking point. > Those who like DNSSEC will dislike working around it. > Those who think DNSSEC will never sail will use this to sink it. If the charter of this WG is to sink DNSSEC, that needs to be stated explicitly in the charter, and then say why this work should not be in other PKI-based WGs. > > I think the charter should go some way to clarifying the > intended use > > cases. > > I think that's actually more than a charter should say. I could not disagree more strongly. > The charter needs to specific enough to tell people if they are > interested in > the problem, and motivate them enough to read a use case document. Charters are not documents to attract participants, they are descriptions of intended work. Given that this thread has brought out some significant disagreements on the use cases, the listing of use cases is all that much more imperative. --Paul Hoffman From nobody Sun Jun 13 16:39:50 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 51E2B3A14F7 for ; Sun, 13 Jun 2021 16:39:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 obC_O_0IVxO2 for ; Sun, 13 Jun 2021 16:39:43 -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 803D43A14F5 for ; Sun, 13 Jun 2021 16:39:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 2EDE038B1E; Sun, 13 Jun 2021 19:40:45 -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 TjUrzhzn18x4; Sun, 13 Jun 2021 19:40:44 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 7116238B1A; Sun, 13 Jun 2021 19:40:44 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 55B3BC9B; Sun, 13 Jun 2021 19:39:40 -0400 (EDT) From: Michael Richardson To: Paul Hoffman cc: danish@ietf.org In-Reply-To: References: <4978.1623625466@localhost> 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 Content-Transfer-Encoding: quoted-printable Date: Sun, 13 Jun 2021 19:39:40 -0400 Message-ID: <14718.1623627580@localhost> Archived-At: Subject: Re: [Danish] Proposed WG Charter 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, 13 Jun 2021 23:39:48 -0000 Paul Hoffman wrote: >> I see this as a sticking point. >> Those who like DNSSEC will dislike working around it. >> Those who think DNSSEC will never sail will use this to sink it. > If the charter of this WG is to sink DNSSEC, that needs to be stated > explicitly in the charter, and then say why this work should not be = in other > PKI-based WGs. you said it better than I. >> > I think the charter should go some way to clarifying the intended= use >> > cases. >> >> I think that's actually more than a charter should say. > I could not disagree more strongly. I suspect that we are in agreement. It has to deal with the use cases, but I don't think it should go "some wa= y". There is a reason we write use case documents. >> The charter needs to specific enough to tell people if they are int= erested >> in >> the problem, and motivate them enough to read a use case document. > Charters are not documents to attract participants, they are descrip= tions of > intended work. Given that this thread has brought out some significa= nt > disagreements on the use cases, the listing of use cases is all that= much > more imperative. Let me invert your point in order to also violently agree with it. I didn't say that it was about attracting participants, but when people ge= t to it, it must be clear enough to tell them if they are in the right place= . So, a charter should have enough details so that someone can tell: a) if the WG is *not* working on some problem that they have. ("move along, nothing to see here". That is, to "distract" participants. Although we don't useally consider "distract" to be opposite of attract) That's why we saying what's out of scope is so important. b) what problems the WG is working on. Note that use cases are not the same as problems. Clearly related. The RATS WG charter does not go into use cases at all. We (I) wrote/collected a use case document (never to be published) very ea= rly in the process so that the WG could focus better. Parts of it, moved into the a= rchitecture. -- ] Never tell me the odds! | ipv6 mesh networ= ks [ ] Michael Richardson, Sandelman Software Works | IoT architect= [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [ From nobody Sun Jun 13 16:53:32 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 647203A1588 for ; Sun, 13 Jun 2021 16:53:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 I3sGBqLaQ_px for ; Sun, 13 Jun 2021 16:53:26 -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 8D2C43A1587 for ; Sun, 13 Jun 2021 16:53:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id C3F7D38B1E for ; Sun, 13 Jun 2021 19:54:29 -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 sYoboUsslMQd for ; Sun, 13 Jun 2021 19:54:28 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id B5E6438B1C for ; Sun, 13 Jun 2021 19:54:28 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 91D9AC9B for ; Sun, 13 Jun 2021 19:53:24 -0400 (EDT) From: Michael Richardson To: danish@ietf.org In-Reply-To: References: 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: Re: [Danish] Proposed WG Charter 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, 13 Jun 2021 23:53:31 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I think that the charter has too many words and too many goals. I suggest leaving the DNSSEC-less stuff to a recharter. Where was that github for this.... =3D=3D=3D=3D I suggest the following shorter charter =2DObjective The DANE AutheNtication for Iot Service Hardening (DANISH) WG seeks to extend DANE to encompass TLS client authentication using certificates. The WG will also use DANE to establish identities for store and forward of messages using sender identities. [better wording sought] =2DProblem statement The process of establishing trust in public-key-authenticated identity typically involves the use of a Public Key Infrastructure (PKI), and a shared PKI root of trust between the parties exchanging public keys. A Certification Authority (CA) is one example of a PKI which can be used for establishing trust in public keys. The DNS namespace, together with DNSSEC, forms the most widely-recognized namespace and authenticated discovery mechanism on the Internet. DANE builds on this authenticated discovery mechanism to enable public key-= based TLS authentication which is resilient to impersonation, but only for TLS server identities. In response to the challenges related to ambiguity between identities issued by different CAs, application owners frequently choose to onboard IoT devic= es to a single private CA specific to that vertical. This creates a silo effect where different parts of large deployment can not communicate. For instance the heating cooling system of a building can not authenticate the lighting control system. Many IoT deployments use some kind of message bus (for instance MQTT) to exchange data, and there is a strong desire to add message-level security (MLS) to the objects which are exchanged. While there is TLS for connectio= n security, it does not extend to what is communicated and so does not convey authority to make a claim, while a MLS would provide that. A DNS name is a useful unique identifier to which humans interact with well, and which can be used (thanks to DNSSEC and DANE) to attach a key by which = to authenticate the message sender identity. =2DScope of work DANISH will specify the TLS session and message security use cases and an architecture describing the primary components and 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 message security use cases, like the establishment of message sender identity. DANISH will coordinate with the TLS working group to define any required TLS v1.3 protocol updates required to support client authentication using DANE. {XXX cross this out? DANISH will standardize a protocol and specify operational recommendations for the use of Web PKI to authenticate the discovery of private PKI certificates and trust chains via DANE DNS record types, in the absence of DNSSEC, in support of the message security use case. } 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:SMIMEA (RFC 8162), Proxy headers (RFC 7239), IANA email authentication headers, and TCP proxy TLVs standardized by haproxy. =2DDeliverables: DANISH architecture document 9 months DANE for client certificates (current draft) 6 months DANE for TLS client authentication (current draft) 6 months =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+93Q3WUFAmDGmnQACgkQgItw+93Q 3WUaLgf+NzmH7jIQafqJEAbmsRUoNCcgfs8jq227krOL7hz2ioE4i3P1rtYsUuOM ehu+Me9abkr33flZqYeCOfLJTzdeQrmeMTVEziaW+6oai2tdgRjSNXbbBErtTEoy gFztsWu0FtRGEFJJSohVS2uQ9/1yIpf6FkmZVqG84HtpGGUPVAf90T5TbJJBDdpJ dxCudIFgfRcAcJ/gjur6gv+rCnKLCsmM4qE3rgjN4NOtuZ1FrmL3ZDp95TpSo51Y s/qfgqk6fnwtdlOl6TPq874myQFVjDoBetjcQf513MBcaLDR4xx2qnlwWqO6qcfV ELSxN8H5NqA2T6UV2+GCsmqhiXk1Lg== =kxzo -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Jun 14 07:40:47 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 DEEB73A26C4 for ; Mon, 14 Jun 2021 07:40:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 bm-RlH9R7WSO for ; Mon, 14 Jun 2021 07:40:42 -0700 (PDT) Received: from nestor.zerospam.ca (nestor.zerospam.ca [209.172.38.88]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4174F3A26C2 for ; Mon, 14 Jun 2021 07:40:42 -0700 (PDT) X-ZEROSPAM_FILTERED: true Received: from nestor.zerospam.ca (localhost [127.0.0.1]) by nestor.zerospam.ca (Postfix) with ESMTP id 4G3Yyw69dqz8sX6 for ; Mon, 14 Jun 2021 10:40:40 -0400 (EDT) Authentication-Results: nestor.zerospam.ca (ip=192.228.22.11); spf=none smtp.helo=mx1.cira.ca; spf=pass smtp.mailfrom=Jacques.Latour@cira.ca; dkim=none; dmarc=none (action=none) reason="No DMARC policy found" header.from=cira.ca Received: from 127.0.0.1 (127.0.0.1:12000) (original ip: 192.228.22.11) by nestor.zerospam.ca (Themis) with ESMTP id nPf2j3d1PhHdpVpSD48; Mon, 14 Jun 2021 10:40:39 -0400 Received: from mx1.cira.ca (nat.crp.cira.ca [192.228.22.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by nestor.zerospam.ca (Postfix) with ESMTPS id 4G3Yyv6ZfSz8sXC for ; Mon, 14 Jun 2021 10:40:39 -0400 (EDT) Received: from CRP-EX16-02.CORP.CIRA.CA (10.2.36.121) by CRP-EX16-02.CORP.CIRA.CA (10.2.36.121) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.2242.4; Mon, 14 Jun 2021 10:40:38 -0400 Received: from CRP-EX16-02.CORP.CIRA.CA ([fe80::5d8a:4d4c:25ca:f689]) by CRP-EX16-02.CORP.CIRA.CA ([fe80::5d8a:4d4c:25ca:f689%14]) with mapi id 15.01.2242.004; Mon, 14 Jun 2021 10:40:38 -0400 From: Jacques Latour To: "danish@ietf.org" Thread-Topic: IoT Device Identification with TLSA via Danish Thread-Index: AddhKvcSXHMYMAB6StqY1oKWkaM4dw== Date: Mon, 14 Jun 2021 14:40:38 +0000 Message-ID: <02cb8931e16c4ccaa6eed1b89c0a20b6@cira.ca> Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.2.36.1] Content-Type: multipart/alternative; boundary="_000_02cb8931e16c4ccaa6eed1b89c0a20b6ciraca_" MIME-Version: 1.0 Archived-At: Subject: [Danish] IoT Device Identification with TLSA via Danish 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, 14 Jun 2021 14:40:46 -0000 --_000_02cb8931e16c4ccaa6eed1b89c0a20b6ciraca_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Today I presented at the ICANN DNSSEC workshop the potential results of DAN= ISH working group which I think should include the entire scope having a mu= tual TLSA validated TLS session from an IoT device to a server. https://github.com/CIRALabs/CIRA-Secure-IoT-Registry/blob/master/CIRA%20-%2= 0Challenges%20in%20DNSSEC%20IoT%20Registry%20-%20ICANN%202021-6-14.pdf In addition, I was thinking there should be a 4th TLSA certificate usage, t= ype 0 or 4, for TLSA to show cert that are revoked, if we know for sure the= certificate is revoked then it should be presented and queried/answered as= such, an authoritative answer signed with DNSSEC to say certificate is re= voked, not to be trusted anymore. NSEC says it does not exists, this usage= would be very clear. This works for client identity, not sure for other TL= SA use cases. Jacques --_000_02cb8931e16c4ccaa6eed1b89c0a20b6ciraca_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

Today I presented at the ICANN DNSSEC workshop the p= otential results of DANISH working group which I think should include the e= ntire scope having a mutual TLSA validated TLS session from an IoT device t= o a server.

 

https://github.com/CIRALabs/CIRA-Secure-IoT-= Registry/blob/master/CIRA%20-%20Challenges%20in%20DNSSEC%20IoT%20Registry%2= 0-%20ICANN%202021-6-14.pdf

 

In addition, I was thinking there should be a 4= th TLSA certificate usage, type 0 or 4, for TLSA to show cert that ar= e revoked, if we know for sure the certificate is revoked then it should be= presented and queried/answered as such,  an authoritative answer signed with DNSSEC to say certificate = is revoked, not to be trusted anymore.  NSEC says it does not exists, = this usage would be very clear. This works for client identity, not sure fo= r other TLSA use cases.

 

Jacques

 

 

--_000_02cb8931e16c4ccaa6eed1b89c0a20b6ciraca_-- From nobody Mon Jun 14 08:30: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 860FC3A281B for ; Mon, 14 Jun 2021 08:30:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.178 X-Spam-Level: X-Spam-Status: No, score=-3.178 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_MED=-2.3, 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 SQb8z6Ql7yDl for ; Mon, 14 Jun 2021 08:30:30 -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 F3BC93A2819 for ; Mon, 14 Jun 2021 08:30:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 6571638C54 for ; Mon, 14 Jun 2021 11:31:32 -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 Mdu97y67Mrif for ; Mon, 14 Jun 2021 11:31:31 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 0E9D838C52 for ; Mon, 14 Jun 2021 11:31:31 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 7C393236 for ; Mon, 14 Jun 2021 11:30:24 -0400 (EDT) From: Michael Richardson cc: danish@ietf.org In-Reply-To: <18269.1623628404@localhost> References: <18269.1623628404@localhost> 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: Re: [Danish] Proposed WG Charter 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, 14 Jun 2021 15:30:35 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Michael Richardson wrote: > I think that the charter has too many words and too many goals. > I suggest leaving the DNSSEC-less stuff to a recharter. > Where was that github for this.... > =3D=3D=3D=3D I suggest the following shorter charter > -Objective > The DANE AutheNtication for Iot Service Hardening (DANISH) WG seeks to > extend DANE to encompass TLS client authentication using certificates. > The WG will also use DANE to establish identities for store and forwa= rd of > messages using sender identities. [better wording sought] I was asked offlist if we mean to speak about message security vs object security. I think that our community has some overlapping notions here. The contrast was made between OSCORE (message) vs COSE (object). I think, but I could be wrong, that the IETF MLS WG is actually creating things with object security. I think that this contributes to the confusio= n. I think that the goal is probably best described as object security. If others agree, then we should probably use that term in the charter. =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+93Q3WUFAmDHdhAACgkQgItw+93Q 3WVkzggAur10CQHIXFLf1lnk1Tt+KbRY2aWk3sk1V7obpV0tXGBRSTRYdD4MpC2N P15KHQWe6NUarleHBftHQkJk5G0Yv61t72tkN4ikeGIcmGnUrTfukThE5c8NIAbU edW58R5tkXmVw/eTDEVpPEMokuBeliRQtC0YtVsXllxWRT4ATpeVwYJL8TMwK5Zb hAARo/VAEdCRuTXs/5EZHEgkJs4LCiChMA0dza6ty85dafK1KxODVszlmPbyrouQ SSxhZgASiEP5dG6r0pmUtjGzMFI1qApBrYIGORVSzFeuD4hmKemICmIGHDxAjO8y Zezl9ipM1dpGjiCfn4r2uiUZlydcdg== =hMfr -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Jun 14 08:35:30 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 030203A285C for ; Mon, 14 Jun 2021 08:35:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-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 D_FMrNi_1CdR for ; Mon, 14 Jun 2021 08:35:18 -0700 (PDT) Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (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 8A25E3A284C for ; Mon, 14 Jun 2021 08:35:18 -0700 (PDT) Received: by straasha.imrryr.org (Postfix, from userid 1001) id 1B27DC4DB3; Mon, 14 Jun 2021 11:35:17 -0400 (EDT) Date: Mon, 14 Jun 2021 11:35:17 -0400 From: Viktor Dukhovni To: danish@ietf.org Message-ID: Reply-To: danish@ietf.org References: <02cb8931e16c4ccaa6eed1b89c0a20b6@cira.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <02cb8931e16c4ccaa6eed1b89c0a20b6@cira.ca> Archived-At: Subject: Re: [Danish] IoT Device Identification with TLSA via Danish 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, 14 Jun 2021 15:35:29 -0000 On Mon, Jun 14, 2021 at 02:40:38PM +0000, Jacques Latour wrote: > Today I presented at the ICANN DNSSEC workshop the potential results > of DANISH working group which I think should include the entire scope > having a mutual TLSA validated TLS session from an IoT device to a > server. > > https://github.com/CIRALabs/CIRA-Secure-IoT-Registry/blob/master/CIRA%20-%20Challenges%20in%20DNSSEC%20IoT%20Registry%20-%20ICANN%202021-6-14.pdf Thanks. > In addition, I was thinking there should be a 4th TLSA certificate > usage, type 0 or 4, for TLSA to show cert that are revoked, if we know > for sure the certificate is revoked then it should be presented and > queried/answered as such, an authoritative answer signed with DNSSEC > to say certificate is revoked, not to be trusted anymore. Picking nits, we already have four usages: - PKIX-TA(0) - PKIX-EE(1) - DANE-TA(2) - DANE-EE(3) but more importantly, there is no need for publishing revocation via DANE TLSA, since all the certificates that don't match are effectively revoked. Therefore, the robust way to revoke all known and even *unknown* compromised certificates is to publish only PKIX-EE(1) or DANE-EE(3) TLSA records matching the legitimate certificate of the service. If the goal is to deal with a known compromised key (the only use case handled by "revocation"), then exclusive use of PKIX-EE/DANE-EE records need only extend past the original expiration of the would be revoked certificate, after which time, one can return the service to using PKIX-TA/DANE-TA if desired. Better still, just always use DANE-EE/PKIX-EE and revocation is something you never have to worry about. DANE obviates certificate revocation, good riddance. -- Viktor. From nobody Mon Jun 14 13:34:19 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 602553A0AD6 for ; Mon, 14 Jun 2021 13:34:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, 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 mf280gXAhYDn for ; Mon, 14 Jun 2021 13:34:09 -0700 (PDT) Received: from mail-qk1-x72b.google.com (mail-qk1-x72b.google.com [IPv6:2607:f8b0:4864:20::72b]) (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 74FEB3A0AD5 for ; Mon, 14 Jun 2021 13:34:09 -0700 (PDT) Received: by mail-qk1-x72b.google.com with SMTP id k11so38194048qkk.1 for ; Mon, 14 Jun 2021 13:34:09 -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; bh=KMcTBlXVsAb/7JtBZ9W4vS7FpP5K7UEEhn8ZcKJviEM=; b=R3/yw0qhfBzc8WGwdW/aQddfwHlcFCNhvQuYWpHcweWaA/2RH6yiPpW4x1Dhs+2sxt 1qci12lOVPwwpcet+6n2p/3BOXttPUp5kLha3CmP8ZZGxJ/PYbpC8ARIOAUI5qG4XSVM yS4myzZVHvO5Dek3aVJJGqzU3HKhVaC7g4NSHcsUTsFgQbNRGhj8mwlBop1lAReVpZcR WqWt6GVdozFzaQ88r+0sjroOiiAqGU/QsyCgJQtGVhlZ+Lo7ycy/fQV5UZ+Tx1JVjnxZ 1a0FBHn815nirIcwFTI0Dkn7RIoZ9YBByP8g59FLcCNXLPgzzP9ekFg3M4B0C+ACo4da tpsA== 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; bh=KMcTBlXVsAb/7JtBZ9W4vS7FpP5K7UEEhn8ZcKJviEM=; b=Dmz/F4D1I1lt8uiGgwntczVJb8G1O1XeqNDIRQ9fU1FCHoe+eODonfvqTvL59fjDaM JEXCLznHfhTyqcyW+uihnXn3Dkwn7rfNL+rRPu+tuL60X3jlVYluHjW9GN6e7mXNzuyd fZK/5XceTGHnciYGDzy9u64aN63/4xtMX5WzTsSytMVG995YVXPP8uy1sJu0RcTcadkV Ls8MXQPs6S5XhX7MdW0Etykf0OtNaNxN+N9NkBtVsyr0x4sxPZ+Ylw1oFOzNTf6oZgYS r7UORfVNdKH1sAmgyH7PIP4LvuMXjVRG0wbWO9SFIxEu0HVQEvcx3KeMKpn06X+m2sKx WORg== X-Gm-Message-State: AOAM5307k24+l2icSieEuLlkT+YIoqoJkYWaRzmihDuvMLOvHn/fyvnR jzHvzklmrU9HAOYoKke6L7zYmTJBJAOsYLUZRnHURHHfNdM= X-Google-Smtp-Source: ABdhPJwiFM8S5Byw7m0s5EDRJHE9MoaH6t45Zh/zDcfb+yM4CHR899eZg7MmA48KGKyI8fRTQZhfYvTNMsbxMzbCSvw= X-Received: by 2002:a05:620a:136b:: with SMTP id d11mr18308972qkl.423.1623702847596; Mon, 14 Jun 2021 13:34:07 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ash Wilson Date: Mon, 14 Jun 2021 13:33:56 -0700 Message-ID: To: danish@ietf.org Content-Type: multipart/alternative; boundary="00000000000073ba2705c4bfc71c" Archived-At: Subject: Re: [Danish] Proposed WG Charter 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, 14 Jun 2021 20:34:17 -0000 --00000000000073ba2705c4bfc71c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Viktor, Thanks for the detailed feedback! Responses in-line below... On Sun, Jun 13, 2021 at 1:52 PM Viktor Dukhovni wrote: > On Sat, Jun 12, 2021 at 08:25:07AM -0700, Ash Wilson wrote: > > > This is the final text for the proposed charter. We are seeking > > support for the formation of the working group, as well as support for > > implementation, adoption, and documentation efforts. > > I see that others have commented positively on the charter, and yet > somehow for me it seems rather muddled. It is not clear to me what > the motivating use-cases really are, nor how DANISH would resolve > the key difficulties in those use-cases. > > There is no explanation of whether the perceived barriers to DNSSEC > adoption are on the authoritative or resolver side, or who are the > primary intended users (consumer, enterprise, other?) for PKI a la > DANISH. > I think that a proper survey to understand what DNSSEC adoption is struggling would be a worthwhile endeavor, and registrars are in a great position to do that well. The objections I've encountered to DNSSEC (in having conversations with would-be implementers) relate generally to a perception that the benefits do not outweigh the risks. Some of those risks are related to technology challenges, and some relate to hiring the right skillset to maintain and troubleshoot a DNSSEC-protected domain. In changing the location of DNSSEC in the adoption path for DNS-based identities, we allow organizations to experience some success and build confidence in the DNS-based identity strategy, which will further incentivize the eventual adoption of DNSSEC. > > The now closed DANE working group (WG) produced a mechanism that > > supported authentication of TLS server identities via a DNSSEC-secured > > infrastructure. Operational experience with DANE has validated the > > utility of a DNS-enabled mechanism for discovering authenticated keys, > > but has also shown that reliance on DNSSEC is a significant barrier to > > adoption. > > The term "discovering authentication keys" is not defined here. It is > not clear that avoiding DNSSEC will make things simpler. Which is the > more important barrier here, zone signing, or access to validating > resolvers? > Would replacing 'discovering authenticated keys' with 'discovering keys or hashes to support TLS server authentication' remedy the lack of clarity? A DNS-based public key discovery mechanism for authenticating message signatures, which does not rely on DNSSEC, may be experimented with and adopted by any domain. If DNSSEC is a requirement for the message security use case (public key discovery for signature validation), then only 2.47% of all .com domains may even experiment with it. Justifying a transition to DNSSEC for an organization can be an uphill battle. If DNSSEC is a requirement for further exploration of a strategy that's already shown success, the chance of eventual adoption of DNSSEC will be greater. > > The DANE AutheNtication for Iot Service Hardening (DANISH) WG seeks to > > extend DANE to encompass TLS client and message sender identities. > > Extending DANE to client auth is certainly an option for "devices" that > one might reasonably want to register in DNS. > > > DANISH will also define a mechanism for messaging use cases that > > allows DANE DNS record types to be secured by the Web PKI as a > > transition strategy for domain owners who have not yet implemented a > > DNSSEC-based trust model. > > The phrase "DANE DNS record types" is not defined. Nor is it clear what > it might for DNS records to be "secured by the Web PKI". > Detail was intentionally left out of this part. We had some discussion at the last BoF, and a draft process https://datatracker.ietf.org/doc/draft-wilson-dane-pkix-cd/ also exists in the form of running code. However, there may be a more elegant way to approach this, and we didn't want to go into exhaustive detail on the transitional mode when the final state (TLS protocol support for DANE client identity) still needs more discussion and detail added to the specification. This informed the timing components of the deliverables section of this charter, where we expect to complete the specification for the desired end-state, and then ensure the transitional mode is appropriately aligned. > Here you speak of "domain owners", placing the focus on the signer side. > Signing domains, and keeping them signed, is at this point sufficiently > easy, that there's no longer any justifiable reason to design > work-arounds for barriers to zone signing. If that's the obstacle, I am > not at all sympathetic to ugly work-arounds that simply postpone doing > it right. > > > A Certificate Authority (CA) is one example of a PKI which can be used > for > > FWIW, the established term of art is "Certification Authority". > > > establishing trust in public keys. CAs only guarantee the uniqueness of > an > > identity=E2=80=99s name within the context of the CA, and multiple CAs = may sign > > certificates for different entities bearing the same name. DNSSEC is > > another PKI, which is bound to the DNS namespace. > > The use of "uniqueness" here is rather unclear. There's nothing wrong > with multiple certificates each binding a key to some shared name, it > just means that all the keys are associated with the same subject. Nor > is it necessarily a problem if such bindings are obtained from multiple > CAs (provided they are all properly validated and authorised). > The challenge is in ensuring that an entity is bound to the correct role in an application. If there is ambiguity in assigning information to its source, or determining the appropriateness of a source for providing the information to the application, then the information is not trustworthy. In a broader context, machines are being trusted not only to collect information and perform actions, but increasingly to decide when certain actions are to be performed. A more concrete example might be a system which manages the addition of chemicals (fluoride, etc) to a city's water supply, in response to telemetry from sensors. If a sensor can be impersonated via naming collision (intentionally or otherwise), a decision made by a machine to react to sensor telemetry could have a profoundly negative effect on the human population of the city. > > The DNS namespace, together with DNSSEC, forms the most widely-recogniz= ed > > namespace and authenticated discovery mechanism on the Internet. > > Not clear what this is intended to convey. > > An agreement on one namespace is essential for preventing naming collisions. > > DANE builds on this authenticated discovery mechanism to enable public > > key-based TLS authentication which is resilient to impersonation, but > > only for TLS server identities. > > More precisely, how one locates the relevant RFC6698/7671 TLSA records > for use with TLS is presently only defined for the server side of a TLS > connection. > > > The use of CA-based PKI alone for client and message sender > authentication > > creates the possibility of naming collisions when multiple CAs are > trusted > > within the same application. > > It is rather unclear what this is getting at. Perhaps it i trying to > evoke lack of effective name constraints in the WebPKI? Yes, you are correct. > > > In response to the challenges related to ambiguity between identities > > issued by different CAs, application owners frequently choose to > > onboard IoT devices to a single CA. > > Again, what exactly is this tryign to get at? > Time is spent onboarding devices to the same PKI, to avoid naming collisions. > > > Expanding the use cases for DANE to support the representation of TLS > > client and message sender identities will enable unambiguous > authentication > > across CAs, for client/server TLS sessions as well as message-oriented > > information flows. > > It seems that solving "ambiguity" is a major concern. So the term needs > a clear definition and some motivating examples. > Ambiguity here refers to naming collisions possible when using multiple PKI within the same application. What do you think about using "naming collision-free authentication across CAs" instead? > > > The greatest barrier to DANE adoption has been the DNSSEC requirement. > > But which barriers if any are applicable to the DANISH use-case? DNSSEC > zone signing? DNSSEC resolution on roaming devices? Or tools to > automate publishing data in DNS (signed or not), monitoring, ... > > DNSSEC zone signing > > DANISH will provide a method of certificate and trust chain discovery f= or > > private PKIs, > > What is "trust chain discovery"? How is different from including all > the relevant certificates with the message? What is "certificate > discovery"? What makes these relevant to IoT? IoT applications frequently have network constraints which make the in-message transmission of certificates and chains impractical or impossible. For example: A device uses a cellular connection to transmit water level measurements to a central service, for a city's storm water management application. Since falsified measurements could lead to chaos, we want signatures on all of those measurements so that we have some measure of sender authentication/attribution. The cellular bill would be substantially higher if the cert/chain were transmitted along with every measurement and signature. Compare that to just transmitting the measurement, the device's DNS name, and a signature. The authenticating central application can then use a less constrained network connection to perform out-of-band certificate discovery, based on the sending device's name, found in the message itself. > > > to enable the messaging security use case, in a manner which will work > > securely in the absence of DNSSEC. > > Why is avoiding DNSSEC simpler than making it more compelling to deploy? > Allowing some limited success with DNS-based identity is expected to further incentivize adoption of DNSSEC. This isn't about avoiding DNSSEC. Rather, it's about postponing the requirement so that an organization can demonstrate value in an identity strategy that eventually requires DNSSEC. > > > -Scope of work > > DANISH will specify the TLS session and message security use cases and = an > > architecture describing the primary components and interaction patterns= . > > I think the charter should go some way to clarifying the intended use > cases. > > -- > Viktor. > > -- > 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. --00000000000073ba2705c4bfc71c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Viktor,=C2=A0
Thanks for the detailed fe= edback! Responses in-line below...

On Sun, Jun 13, 2021 at 1:52 PM Viktor Du= khovni <ietf= -dane@dukhovni.org> wrote:
On Sat, Jun 12, 2021 at 08:25:07AM -0700, Ash Wilson wrot= e:

> This is the final text for the proposed charter. We are seeking
> support for the formation of the working group, as well as support for=
> implementation, adoption, and documentation efforts.

I see that others have commented positively on the charter, and yet
somehow for me it seems rather muddled.=C2=A0 It is not clear to me what the motivating use-cases really are, nor how DANISH would resolve
the key difficulties in those use-cases.

There is no explanation of whether the perceived barriers to DNSSEC
adoption are on the authoritative or resolver side, or who are the
primary intended users (consumer, enterprise, other?) for PKI a la
DANISH.
I think that a proper=C2=A0survey to understan= d what=C2=A0DNSSEC adoption is struggling would be a worthwhile endeavor, a= nd registrars are in a great=C2=A0position to do that well. The objections = I've encountered to DNSSEC (in having conversations with would-be imple= menters) relate generally to a perception that the benefits do not outweigh= the risks. Some of those risks are related to technology challenges, and s= ome relate to hiring the right skillset to maintain and troubleshoot a DNSS= EC-protected domain. In changing the location of DNSSEC in the adoption pat= h for DNS-based identities, we allow organizations to experience some succe= ss and build confidence in the DNS-based identity strategy, which will furt= her incentivize the eventual adoption of DNSSEC.


> The now closed DANE working group (WG) produced a mechanism that
> supported authentication of TLS server identities via a DNSSEC-secured=
> infrastructure.=C2=A0 Operational experience with DANE has validated t= he
> utility of a DNS-enabled mechanism for discovering authenticated keys,=
> but has also shown that reliance on DNSSEC is a significant barrier to=
> adoption.

The term "discovering authentication keys" is not defined here.= =C2=A0 It is
not clear that avoiding DNSSEC will make things simpler.=C2=A0 Which is the=
more important barrier here, zone signing, or access to validating
resolvers?

Would replacing 'discove= ring authenticated keys' with 'discovering keys or hashes to suppor= t TLS server authentication' remedy the lack of clarity?

=
A DNS-based public key discovery mechanism for authenticating me= ssage signatures, which does not rely on DNSSEC, may be experimented with a= nd adopted by any domain. If DNSSEC is a requirement for the message securi= ty use case (public key discovery for signature validation), then only 2.47= % of all .com domains may even experiment with it. Justifying a transition = to DNSSEC for an organization can be an uphill battle. If DNSSEC is a requi= rement for further exploration of a strategy that's already shown succe= ss, the chance of eventual adoption of DNSSEC will be greater.=C2=A0
<= div>

> The DANE AutheNtication for Iot Service Hardening (DANISH) WG seeks to=
> extend DANE to encompass TLS client and message sender identities.

Extending DANE to client auth is certainly an option for "devices"= ; that
one might reasonably want to register in DNS.

> DANISH will also define a mechanism for messaging use cases that
> allows DANE DNS record types to be secured by the Web PKI as a
> transition strategy for domain owners who have not yet implemented a > DNSSEC-based trust model.

The phrase "DANE DNS record types" is not defined.=C2=A0 Nor is i= t clear what
it might for DNS records to be "secured by the Web PKI".
=C2=A0
Detail was intentionally left out of this par= t. We had some discussion at the last BoF, and a draft process=C2=A0https://datatracker.ietf.org/doc/draft-wilson-dane-pkix-cd/=C2= =A0also exists in the form of running code. However, there may be a more el= egant way to approach this, and we didn't want to go into exhaustive de= tail on the transitional mode when the final state (TLS protocol support fo= r DANE client identity) still needs more discussion and detail added to the= specification. This informed the timing components of the deliverables sec= tion of this charter, where we expect to complete the specification for the= desired end-state, and then ensure the transitional mode is appropriately = aligned.


Here you speak of "domain owners", placing the focus on the signe= r side.
Signing domains, and keeping them signed, is at this point sufficiently
easy, that there's no longer any justifiable reason to design
work-arounds for barriers to zone signing.=C2=A0 If that's the obstacle= , I am
not at all sympathetic to ugly work-arounds that simply postpone doing
it right.

> A Certificate Authority (CA) is one example of a PKI which can be used= for

FWIW, the established term of art is "Certification Authority".
> establishing trust in public keys. CAs only guarantee the uniqueness o= f an
> identity=E2=80=99s name within the context of the CA, and multiple CAs= may sign
> certificates for different entities bearing the same name. DNSSEC is > another PKI, which is bound to the DNS namespace.

The use of "uniqueness" here is rather unclear.=C2=A0 There's= nothing wrong
with multiple certificates each binding a key to some shared name, it
just means that all the keys are associated with the same subject.=C2=A0 No= r
is it necessarily a problem if such bindings are obtained from multiple
CAs (provided they are all properly validated and authorised).

The challenge is in ensuring that an entity is boun= d to the correct role in an application. If there is ambiguity in assigning= information to its source, or determining the appropriateness of a source = for providing the information to the application, then the information is n= ot trustworthy. In a broader context, machines are being trusted not only t= o collect information and perform actions, but increasingly to decide when = certain actions are to be performed. A more concrete example might be a sys= tem which manages the addition of chemicals (fluoride, etc) to a city's= water supply, in response to telemetry from sensors. If a sensor can be im= personated via naming collision (intentionally or otherwise), a decision ma= de by a machine to react to sensor telemetry could have a profoundly negati= ve effect on the human population of the city.=C2=A0


> The DNS namespace, together with DNSSEC, forms the most widely-recogni= zed
> namespace and authenticated discovery mechanism on the Internet.

Not clear what this is intended to convey.

An agreement on one namespace is essential for preven= ting naming collisions.
=C2=A0
> DANE builds on this authenticated discovery mechanism to enable public=
> key-based TLS authentication which is resilient to impersonation, but<= br> > only for TLS server identities.

More precisely, how one locates the relevant RFC6698/7671 TLSA records
for use with TLS is presently only defined for the server side of a TLS
connection.

> The use of CA-based PKI alone for client and message sender authentica= tion
> creates the possibility of naming collisions when multiple CAs are tru= sted
> within the same application.

It is rather unclear what this is getting at.=C2=A0 Perhaps it i trying to<= br> evoke lack of effective name constraints in the WebPKI?=C2=A0
<= div>
Yes, you are correct.
=C2=A0
> In response to the challenges related to ambiguity between identities<= br> > issued by different CAs, application owners frequently choose to
> onboard IoT devices to a single CA.

Again, what exactly is this tryign to get at?

Time is spent onboarding devices to the same PKI, to avoid naming co= llisions.=C2=A0

> Expanding the use cases for DANE to support the representation of TLS<= br> > client and message sender identities will enable unambiguous authentic= ation
> across CAs, for client/server TLS sessions as well as message-oriented=
> information flows.

It seems that solving "ambiguity" is a major concern.=C2=A0 So th= e term needs
a clear definition and some motivating examples.
=C2= =A0
Ambiguity here refers to naming collisions possible when usin= g multiple PKI within the same application.
What do you think abo= ut using "naming collision-free authentication across CAs" instea= d?

> The greatest barrier to DANE adoption has been the DNSSEC requirement.=

But which barriers if any are applicable to the DANISH use-case?=C2=A0 DNSS= EC
zone signing?=C2=A0 DNSSEC resolution on roaming devices?=C2=A0 Or tools to=
automate publishing data in DNS (signed or not), monitoring, ...

DNSSEC zone signing
=C2=A0
> DANISH will provide a method of certificate and trust chain discovery = for
> private PKIs,

What is "trust chain discovery"?=C2=A0 How is different from incl= uding all
the relevant certificates with the message?=C2=A0 What is "certificate=
discovery"?=C2=A0 What makes these relevant to IoT?
= =C2=A0
IoT applications frequently have network constraints which= make the in-message transmission of certificates and chains impractical or= impossible.

For example: A device uses a cellular= connection to transmit water level measurements to a central service, for = a city's storm water management application. Since falsified measuremen= ts could lead to chaos, we want signatures on all of those measurements so = that we have some measure of sender authentication/attribution. The cellula= r bill would be substantially higher if the cert/chain were transmitted alo= ng with every measurement and signature. Compare that to just transmitting = the measurement, the device's DNS name, and a signature. The authentica= ting central application can then use a less constrained network connection= to perform out-of-band certificate discovery, based on the sending device&= #39;s name, found in the message itself.
=C2=A0
> to enable the messaging security use case, in a manner which will work=
> securely in the absence of DNSSEC.

Why is avoiding DNSSEC simpler than making it more compelling to deploy?

Allowing some limited success with DNS-ba= sed identity is expected to further incentivize adoption of DNSSEC. This is= n't about avoiding DNSSEC. Rather, it's about postponing the requir= ement so that an organization can demonstrate value in an identity strategy= that eventually requires DNSSEC.

> -Scope of work
> DANISH will specify the TLS session and message security use cases and= an
> architecture describing the primary components and interaction pattern= s.

I think the charter should go some way to clarifying the intended use
cases.

--
=C2=A0 =C2=A0 Viktor.

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


--
=
--00000000000073ba2705c4bfc71c-- From nobody Mon Jun 14 14:13:32 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 4F3983A0CDC for ; Mon, 14 Jun 2021 14:13:29 -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 SwjsG5VJk0xF for ; Mon, 14 Jun 2021 14:13:23 -0700 (PDT) Received: from mail-qv1-xf35.google.com (mail-qv1-xf35.google.com [IPv6:2607:f8b0:4864:20::f35]) (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 1A81A3A0CDB for ; Mon, 14 Jun 2021 14:13:22 -0700 (PDT) Received: by mail-qv1-xf35.google.com with SMTP id e18so21226390qvm.10 for ; Mon, 14 Jun 2021 14:13:22 -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; bh=9Qz9GVKRb4pwEdHKTz33jZ7QbqiEpYn5yjSh4Zwttx0=; b=XOsWtw0gEx7nAMk2HuPoaatTnvF2vzNuXhU26xSeyRijdA4bzxENrW2uW98LxhCgqi SKuICSwop9Gx5yD3e1fRi75VSiB5mVZ8fyB5xrpsqhP32A8WhGwuO9U4SYiMRzNvrcDK KEeYLpVWCqvRLXCI8NILTq4gq5HAz83/eI9a2IGRE4Qu0AXS5YBuN9zQR5hFg0r73Nw2 TMA6pzGT5QFQKTrjYTByM6i+PwWLjJsrSYDs7JnFifwDUsZOBxst8lAHJmB48GXo9rqi Eaxs/3cxXDZmqpaFiEvbrbMbKI1Sa6U64R0jD//W8JmIaygrVf2wNj5xe/Gv2av34CfC MzeA== 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; bh=9Qz9GVKRb4pwEdHKTz33jZ7QbqiEpYn5yjSh4Zwttx0=; b=Gj8aIwwIRekYUi1Tj8uMAnVo2LIkRVx+7r7foImjUa479mlX8cmlQOo0QJt50ycKQW m4wkiiflVxyL91agXA/Y3mSCDtqp8b9jWcTo5mItRJKPR91eljH5ff1NsKvKZveX1XtC 6pL8O9LHaXHhmSQekrvopF2VMSSt+8y97laYeKGAoaDwJoId3EG3D/wgSUrWqhxSVrdr d6lomEbG7MFUbsdWaGU1sZAHTJ/6Fc4UAJYBMrM2gO5yd499ao9ra/XVga250hkF12v3 i+aGNy9kNPxiKBmSbZPSfZZjrqCYerckMs9Z2l5P24WZXluGeXmrbsp0YwVlb6NLE/hL Co9Q== X-Gm-Message-State: AOAM533UVHTUuGvFyLN4P1k78RJwySayrtpvaF1CRmG3cDvuKtkv/qQ8 7AiyBS/+/QsSB8c2pF7EsRX+lTY3FaHIUzyGiC8S6LremO4= X-Google-Smtp-Source: ABdhPJwCkp8krlk/d9MDR+g0JOXn7GXg/zFFyVfvMFQKtRzaobkaGrkZapwE6LMTDhoYgpR2FwbN55vFDszePhRxWyc= X-Received: by 2002:a05:6214:334:: with SMTP id j20mr1164954qvu.7.1623705201309; Mon, 14 Jun 2021 14:13:21 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ash Wilson Date: Mon, 14 Jun 2021 14:13:10 -0700 Message-ID: To: Paul Wouters , danish@ietf.org Content-Type: multipart/alternative; boundary="000000000000be8cef05c4c0532f" Archived-At: Subject: Re: [Danish] Proposed WG Charter 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, 14 Jun 2021 21:13:29 -0000 --000000000000be8cef05c4c0532f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sorry, meant to reply to the list. On Mon, Jun 14, 2021 at 2:05 PM Ash Wilson wrote: > Hi Paul, > > Very often, mobile data used for IoT ends up going into a message broker > or message queueing system, and the central application subscribes or > otherwise consumes information from the messaging middleware. Without som= e > sort of verifiable sender identity attached to the message itself, the > identity of the sender and the integrity of the message is assumed based = on > the integrity of all middleware involved in passing messages. If we inclu= de > the sender's DNS name in the message and protect it with a signature, the= n > it may be verified by the central application, independent of the transpo= rt > over which it arrives. Then, mobile data network authentication becomes > more about protecting availability and performance than preventing > impersonation in a message-oriented application. Use cases centering arou= nd > mobile network identities are a little more nuanced, and the available > mechanisms can vary based on the mobile operator's tech stack. That's > probably a better conversation for 3GPP. > > Consider that if a messaging middleware platform is trusted by multiple > sophisticated smart cities applications, and none of those applications > implement message authentication, the messaging middleware platform itsel= f > becomes an attractive target for a well-resourced adversary. Simply signi= ng > the messages passing through the system removes the pressure on the broke= r > to ensure integrity, and reduces the value of a compromised broker. > > On Sun, Jun 13, 2021 at 3:22 PM Paul Wouters wrote: > >> On Jun 13, 2021, at 16:52, Viktor Dukhovni >> wrote: >> > >> > =EF=BB=BFOn Sat, Jun 12, 2021 at 08:25:07AM -0700, Ash Wilson wrote: >> > >> >> This is the final text for the proposed charter. We are seeking >> >> support for the formation of the working group, as well as support fo= r >> >> implementation, adoption, and documentation efforts. >> > >> > I see that others have commented positively on the charter, and yet >> > somehow for me it seems rather muddled. It is not clear to me what >> > the motivating use-cases really are, nor how DANISH would resolve >> > the key difficulties in those use-cases. >> >> Same here. I did give feedback in the past already but especially the >> =E2=80=9Cclient verification with and without dnssec=E2=80=9D seem to be= two widely >> different problems. And the one without dnssec (webpki) already exists ? >> >> > Extending DANE to client auth is certainly an option for "devices" tha= t >> > one might reasonably want to register in DNS. >> >> I have given this some thought in the last few weeks and I haven=E2=80= =99t been >> able to find a use case where one actually wants client authentication >> using some IoT device on mobile data network. All use cases I can think = of >> would not want to expose the client via public dnssec key registry or vi= a >> public CA certs. I=E2=80=99d love to hear an example practical use case = for DANISH. >> >> Paul >> -- >> Danish mailing list >> Danish@ietf.org >> https://www.ietf.org/mailman/listinfo/danish >> > > > -- > > *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 prohibit= ed > and may be unlawful. Please immediately notify the sender by replying to > this email and then delete it from your system. > --=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. --000000000000be8cef05c4c0532f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Sorry, meant to reply to the list.

On Mon, Jun 14, 202= 1 at 2:05 PM Ash Wilson <ash.= wilson@valimail.com> wrote:
Hi Paul,

Very often,= mobile data used for IoT ends up going into a message broker or message qu= eueing system,=C2=A0and the central application subscribes or otherwise con= sumes information from the messaging middleware. Without some sort of verif= iable sender identity attached to the message itself, the identity of the s= ender and the integrity of the message is assumed based on the integrity of= all middleware involved in passing messages. If we include the sender'= s DNS name in the message and protect it with a signature, then it may be v= erified by the central application,=C2=A0independent of the transport over = which it arrives. Then, mobile data network authentication becomes more abo= ut protecting availability and performance than preventing impersonation in= a message-oriented=C2=A0application. Use cases centering around mobile net= work identities are a little more nuanced,=C2=A0and the available mechanism= s can vary based on the mobile operator's tech stack. That's probab= ly a better conversation for 3GPP.

Consider that i= f a messaging middleware platform is trusted by multiple sophisticated smar= t cities applications, and none of those applications implement message aut= hentication, the messaging middleware platform itself becomes an attractive= target for a well-resourced adversary. Simply signing the messages passing= through the system removes the pressure on the broker to ensure integrity,= and reduces the value of a compromised broker.

On Sun, Jun 13, 2021= at 3:22 PM Paul Wouters <paul@nohats.ca> wrote:
On Jun 13, 2021, at 16:52, Viktor Dukhovni <ietf-dane@dukhovni.org= > wrote:
>
> =EF=BB=BFOn Sat, Jun 12, 2021 at 08:25:07AM -0700, Ash Wilson wrote: >
>> This is the final text for the proposed charter. We are seeking >> support for the formation of the working group, as well as support= for
>> implementation, adoption, and documentation efforts.
>
> I see that others have commented positively on the charter, and yet > somehow for me it seems rather muddled.=C2=A0 It is not clear to me wh= at
> the motivating use-cases really are, nor how DANISH would resolve
> the key difficulties in those use-cases.

Same here. I did give feedback in the past already but especially the =E2= =80=9Cclient verification with and without dnssec=E2=80=9D seem to be two w= idely different problems. And the one without dnssec (webpki) already exist= s ?

> Extending DANE to client auth is certainly an option for "devices= " that
> one might reasonably want to register in DNS.

I have given this some thought in the last few weeks and I haven=E2=80=99t = been able to find a use case where one actually wants client authentication= using some IoT device on mobile data network. All use cases I can think of= would not want to expose the client via public dnssec key registry or via = public CA certs. I=E2=80=99d love to hear an example practical use case for= DANISH.

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


--


--

Ash Wilson | Technical Dire= ctor

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

--000000000000be8cef05c4c0532f-- From nobody Mon Jun 14 14:27:11 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 935363A0D7F for ; Mon, 14 Jun 2021 14:27:09 -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 sf4M68DUj9z1 for ; Mon, 14 Jun 2021 14:27:03 -0700 (PDT) Received: from mail-qk1-x72e.google.com (mail-qk1-x72e.google.com [IPv6:2607:f8b0:4864:20::72e]) (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 B59EF3A0D86 for ; Mon, 14 Jun 2021 14:27:03 -0700 (PDT) Received: by mail-qk1-x72e.google.com with SMTP id f70so24744614qke.13 for ; Mon, 14 Jun 2021 14:27:03 -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=oSJ/3HeZN0xfEuj6jQMmpq/4IoiFtWTz6bZbJywSpwE=; b=Mx65GxEvV73zYDeUB6cJTl1gevB2rPKPZAM3oPpTEbuxAZAo3RQVAnUyWhe8u3BTcp YOWI2QWEvu5k9kfZeMx7Xngc5uxvxi8CZZnShbr5Vn0yXA422S9h2OfVv8OfXpL66VVF mSsB8bBfNF4CehSqmNcg7oR4HHLqQB38ZRnKXP8Epu5Xoysz4NNMknugfJHFkulu34dn SqTzd3M+hT97sVPIYcC+ZSUfNRss1kzqGSibSeSOu5Zj/glkM6lXZicX0bOqGM5sTqnE IHIfGuHwg7n6P/s5sKaEjKMbL0ShSJozjDRf1/Ka+sSj6eEsZ3trU4XF6wh5I9dlc6nr vYIg== 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=oSJ/3HeZN0xfEuj6jQMmpq/4IoiFtWTz6bZbJywSpwE=; b=FAHEKfMm26AiUr4lD3YYMQS3fu2IAy3NgCBdO5zo15jy5ynzCxl1x+Z0Uw9zXl9nPg lVjeQiAqnaGUII8hmoHfHR/njcRWOzlAFL0tUEzljRjq+TqG7pjcr1bhX0GCVzicBfEq iQrjDroLV0bHRCJFORC1p4IDBj5OwIpUF2vmWZAJoLS88FgNQF5zLP5CiUF82IlNcPdP rM3DK8qqttOv9tbirwQGXxRc8qVI0HlQUcuDLsY4zl4PJjs4S4J2+qDGU6E9WjEw9309 ArPoMoJDvj6NQD8S9uljUsCMb45nsOahuVGQ46D+6tGl5C+gnugcLa52m4TZGuTvHQsN AM8g== X-Gm-Message-State: AOAM533YfFoTtQuMRRC0eFb1WymFztZkE/xzCxaUZ6v/SraLo1WQPnem x6uSI+NaHACY6Hv1zYvrLNGxIow51BS5Uk5x/lER/ixkWCs= X-Google-Smtp-Source: ABdhPJyJljP/vMoIPax8/EE4Pl8fWsfXl1JkqKeh25sCZOMaIh2o030wCl3cJp1TdEwWCAiAYiwu3nbK8o4AY2nqr/w= X-Received: by 2002:a37:d08:: with SMTP id 8mr18323061qkn.409.1623706021476; Mon, 14 Jun 2021 14:27:01 -0700 (PDT) MIME-Version: 1.0 References: <4978.1623625466@localhost> In-Reply-To: From: Ash Wilson Date: Mon, 14 Jun 2021 14:26:50 -0700 Message-ID: To: Paul Hoffman Cc: danish@ietf.org Content-Type: multipart/alternative; boundary="000000000000a144e305c4c084bc" Archived-At: Subject: Re: [Danish] Proposed WG Charter 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, 14 Jun 2021 21:27:10 -0000 --000000000000a144e305c4c084bc Content-Type: text/plain; charset="UTF-8" On Sun, Jun 13, 2021 at 4:14 PM Paul Hoffman wrote: > On 13 Jun 2021, at 16:04, Michael Richardson wrote: > > > I see this as a sticking point. > > Those who like DNSSEC will dislike working around it. > > Those who think DNSSEC will never sail will use this to sink it. > > If the charter of this WG is to sink DNSSEC, that needs to be stated > explicitly in the charter, and then say why this work should not be in > other PKI-based WGs. > This charter proposes the creation of an easier adoption path for DNS-based identities, which includes DNSSEC. I don't think anyone here wants to sink DNSSEC. > > > I think the charter should go some way to clarifying the > > intended use > > > cases. > > > > I think that's actually more than a charter should say. > > I could not disagree more strongly. > > > The charter needs to specific enough to tell people if they are > > interested in > > the problem, and motivate them enough to read a use case document. > > Charters are not documents to attract participants, they are > descriptions of intended work. Given that this thread has brought out > some significant disagreements on the use cases, the listing of use > cases is all that much more imperative. > > --Paul Hoffman > > -- > Danish mailing list > Danish@ietf.org > https://www.ietf.org/mailman/listinfo/danish > -- *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. --000000000000a144e305c4c084bc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sun, Jun 13, 2021 at 4:14 PM Paul = Hoffman <paul.hoffman@vpnc.org<= /a>> wrote:
O= n 13 Jun 2021, at 16:04, Michael Richardson wrote:

> I see this as a sticking point.
> Those who like DNSSEC will dislike working around it.
> Those who think DNSSEC will never sail will use this to sink it.

If the charter of this WG is to sink DNSSEC, that needs to be stated
explicitly in the charter, and then say why this work should not be in
other PKI-based WGs.
This charter pro= poses the creation of an easier adoption path for DNS-based identities, whi= ch includes DNSSEC. I don't think anyone here wants to sink DNSSEC.


>=C2=A0 =C2=A0 =C2=A0> I think the charter should go some way to clar= ifying the
> intended use
>=C2=A0 =C2=A0 =C2=A0> cases.
>
> I think that's actually more than a charter should say.

I could not disagree more strongly.

> The charter needs to specific enough to tell people if they are
> interested in
> the problem, and motivate them enough to read a use case document.

Charters are not documents to attract participants, they are
descriptions of intended work. Given that this thread has brought out
some significant disagreements on the use cases, the listing of use
cases is all that much more imperative.

--Paul Hoffman

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


--

Ash Wilson | Technical Dire= ctor

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

--000000000000a144e305c4c084bc-- From nobody Mon Jun 14 15:24:26 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 8AA173A109D for ; Mon, 14 Jun 2021 15:24:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, 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 TO7a1eecboM7 for ; Mon, 14 Jun 2021 15:24:17 -0700 (PDT) Received: from mail-qt1-x836.google.com (mail-qt1-x836.google.com [IPv6:2607:f8b0:4864:20::836]) (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 7BC963A109E for ; Mon, 14 Jun 2021 15:24:17 -0700 (PDT) Received: by mail-qt1-x836.google.com with SMTP id a15so9770950qtx.13 for ; Mon, 14 Jun 2021 15:24:17 -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; bh=zT9/G3+Ml/LTQD9QNJKTHJ/oOX2OibdklOfU7z5s0PA=; b=RbFPVmjxOm0uR4kJVXZ/FH80Vt1c+giwpc48QCoMUnjzunNtT0hmzuM9V0VTiVJJKe +ijnot+x6imRoUGXUHWdw9sI9UfTbDlQKRnZiUQOHnAEm2lWY0X/JESA5TdPLelYDHN0 NwEeyYq5dWztU2rL1kuiaUYMODkYgr/D1f93mJNyTTotMNQKNHxYdNW4NfWcnF4KgKY7 m8M9oHdnYnp8ee5B4aGTdNrY3DvvWpXkmmloXx+KcNvA+QQffWQsifjh+M1ya6o09cGV ufLyFgxCersdN9Zup24orbJMPuKEsN5XLcgdLYsC0ywEeu8EpKp551kkle9eRpoLEemY 5GdQ== 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; bh=zT9/G3+Ml/LTQD9QNJKTHJ/oOX2OibdklOfU7z5s0PA=; b=fPitvsMWkCpcdT364cirC6d6f1uC+RF2/Bph1Ds18bFwUKWRYYQ49MW+bvnT4PVoNb wgBTX4yTYiZKhP+MPfmhQZp4aTPFtM7GBcHeyK8IUNiEJ/ufO3ybJA6Jj/nAScXkpdMx Q1a7mfLlJqnZqWRT6RrRTNROftnWK55GzZaxPAnsTL+ZkAiAHi8y+jbo7JPqZ6OyLVjX vCM+ZYQ2akji+iE/toIt+6a/220PBYd8gYjUvxhbHRodliVKGpvdn58Y8jKStA0J1hiF lJ4BY/dgnUjbn9Do9bDSfPfOGJJzW75R+hvJcK9A8n8S5BG25f/nX9bZArzTRObBSWNI ECeA== X-Gm-Message-State: AOAM531Hc1LeNgnxSIZ686pAZ4OkBk6/aUl9VW9KNMgaHgMMKpIS1P2T 2rbZX5PRmVLHjb7UdFNXF3wA8bR51ftnlAJHvARr2A== X-Google-Smtp-Source: ABdhPJwMM2y2HbXr9lWHv3mcQY2nzHlVQFxRvXohtFHwRv0zrST+aKGcja4TVQlpglgna6xISPHs3PvQuf667C1dtOE= X-Received: by 2002:ac8:5b86:: with SMTP id a6mr4200030qta.231.1623709455299; Mon, 14 Jun 2021 15:24:15 -0700 (PDT) MIME-Version: 1.0 References: <2920.1623516964@localhost> In-Reply-To: From: Ash Wilson Date: Mon, 14 Jun 2021 15:24:04 -0700 Message-ID: To: Michael Richardson , danish@ietf.org Content-Type: multipart/alternative; boundary="0000000000004d4eec05c4c15181" Archived-At: Subject: Re: [Danish] Proposed WG Charter 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, 14 Jun 2021 22:24:24 -0000 --0000000000004d4eec05c4c15181 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Failed to reply to all earlier- here's the message back in-channel. On Mon, Jun 14, 2021 at 10:53 AM Ash Wilson wrote= : > Hi Mike, > Thanks for the feedback, responses in-line below... > > On Sat, Jun 12, 2021 at 9:56 AM Michael Richardson > wrote: > >> >> Thanks Ash for doing such a good job on this charter. >> {I appologize for being rather lame in responding to the charter >> discussions >> in the past few weeks... some kind of COVID induced mid-life depression >> around turning 50, and being unable to stay up all night writing code} >> >> The charter feels a bit long/detailed I think, with content that maybe >> belongs in a problem statement draft.... But, if the IESG doesn't mind >> that, >> I don't. >> >> Some thoughts as I read it again: >> >> > but has also >> > shown that reliance on DNSSEC is a significant barrier to adoption. >> >> also: >> > The greatest barrier to DANE adoption has been the DNSSEC requirement. >> >> Reading this, I wonder if we really understand why DNSSEC has been so >> hard to >> get deployed among Enterprise entities. TLDs have done it, because ICAN= N >> forced them to. >> As evidence, we don't need DLV anymore (I was involved in running it, an= d >> decommissioning it). What I'm trying to say/ask: if there in fact some >> work >> in understanding this? An increasing number of DNS Registrars support = DS >> records, and CDS is supposed to make this even easier. >> >> Adding DNSSEC to a DNS server seems (to me), *significantly* easier than >> operating a private CA, but its also apples vs oranges. > > > In conversation with folks outside this group, but related to the topic a= t > hand, the general perception is that the benefits of DNSSEC implementatio= n > do not outweigh the risk-related drawbacks. A few specific drawbacks cite= d > have been: an anticipated increase in time to resolve DNS-related issues > (uptime impact), a need for specialized knowledge in order to troubleshoo= t > DNSSEC-related issues (hiring, training, retention), interoperability > concerns with DNS-based load balancing and CDNs, and a general desire to > avoid adding complexity that doesn't tie to some sort of competitive > advantage for the business. This is anecdotal, and only represents the > conversations I've had in trying to understand the feasibility of creatin= g > the protocol. A proper survey, perhaps conducted by registrars, would be > quite useful for understanding and addressing the challenges that are > impeding DNSSEC adoption. > > >> >> >> > This allows for a gradual DANE >> > adoption where DNSSEC is not in the initial set of requirements. >> >> It seems that if we make something that makes DNSSEC less important, tha= t >> DNSSEC will never become important. >> > > DNSSEC is important. I think that the benefits just aren't overshadowing > the perceived risks. If DNSSEC is a requirement to even try a DNS-based > device identity strategy, R&D groups may just seek a path of less > resistance. Even if an R&D group purchases a separate domain for testing > with DNSSEC, they still have to sell the idea to the organization's > technical leadership before it can be adopted under the organizational > domain. Depending on the organization, that can be a big gamble. The R&D > group has little room to negotiate the topic of DNS-based device identity > with technical leadership, without a transitional mode. > > If we have a transitional protocol mode which allows gradual adoption, > enterprises can more easily demonstrate initial success with DNS-based > identities. The full set of benefits, like direct support in the TLS > protocol, can only be realized by completing the transition to DNSSEC. It= 's > much easier to justify the adoption of DNSSEC if it's tied to increasing > the success of an existing initiative. We certainly don't want to diminis= h > the importance of DNSSEC- this is about incentivizing implementation by > making it a part of an adoption path for DNS-based identities. > > >> > In response to the challenges related to ambiguity between identities >> > issued by different CAs, application owners frequently choose to onboa= rd >> > IoT devices to a single CA. This process of credential issuance can be >> > time-consuming, which is further exacerbated by the sheer number of >> > entities participating in large-scale IoT deployments. >> >> So I understand why a single CA solves the potential identity confusion. >> I don't understand why the scale matters here. That sentence seems almo= st >> a non-sequitor. >> > > Each device needing to be onboarded to an organizational PKI takes a > certain amount of time to establish an identity within that PKI. With a > large-scale deployment with many thousands of devices, the provisioning > process can be time consuming and impacts the cost of the project. If a > supplier ships devices with immediately useful DNS-based identities, then > the network and application onboarding time can be reduced, which has a > favorable impact on project cost. > > >> I think that the charter needs to introduce the message use case. >> Or maybe delegate that more clearly. > > Good point. I was trying to keep it concise, but left out some detail > where it could have been helpful. > >> -- >> Michael Richardson . o O ( IPv6 I=C3=B8T consu= lting >> ) >> 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. --0000000000004d4eec05c4c15181 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Failed to reply to all earlier- here's the messag= e back in-channel.

On Mon, Jun 14, 2021 at 10:53 AM Ash Wilson <ash.wilson@valimail.com> wrote:<= br>
Hi Mike,
Thanks for the feedback, responses in-line below..= .

On Sat, Jun 12, 2021 at 9:56 AM Michael Richardson <mcr+ietf@sandelman.ca>= ; wrote:

Thanks Ash for doing such a good job on this charter.
{I appologize for being rather lame in responding to the charter discussion= s
in the past few weeks... some kind of COVID induced mid-life depression
around turning 50, and being unable to stay up all night writing code}

The charter feels a bit long/detailed I think, with content that maybe
belongs in a problem statement draft.... But, if the IESG doesn't mind = that,
I don't.

Some thoughts as I read it again:

> but has also
> shown that reliance on DNSSEC is a significant barrier to adoption.
also:
> The greatest barrier to DANE adoption has been the DNSSEC requirement.=

Reading this, I wonder if we really understand why DNSSEC has been so hard = to
get deployed among Enterprise entities.=C2=A0 TLDs have done it, because IC= ANN
forced them to.
As evidence, we don't need DLV anymore (I was involved in running it, a= nd
decommissioning it).=C2=A0 What I'm trying to say/ask: if there in fact= some work
in understanding this?=C2=A0 =C2=A0An increasing number of DNS Registrars s= upport DS
records, and CDS is supposed to make this even easier.

Adding DNSSEC to a DNS server seems (to me), *significantly* easier than operating a private CA, but its also apples vs oranges.

In conversation with folks outside t= his group, but related to the topic at hand, the general perception is that= the benefits of DNSSEC implementation do not outweigh the risk-related dra= wbacks. A few specific drawbacks cited have been: an anticipated increase i= n time to resolve DNS-related issues (uptime impact), a need for specialize= d knowledge in order to troubleshoot DNSSEC-related issues (hiring, trainin= g, retention), interoperability concerns with DNS-based load balancing and = CDNs, and a general desire to avoid adding complexity that doesn't tie = to some sort of competitive advantage for the business. This is anecdotal, = and only represents the conversations I've had in trying to understand = the feasibility of creating the protocol. A proper survey, perhaps conducte= d by registrars, would be quite useful for understanding and addressing the= challenges that are impeding DNSSEC adoption.

<= /div>



> This allows for a gradual DANE
> adoption where DNSSEC is not in the initial set of requirements.

It seems that if we make something that makes DNSSEC less important, that DNSSEC will never become important.

DNSSEC is important. I think that the benefits just aren't ov= ershadowing the perceived risks. If DNSSEC is a requirement to even try a D= NS-based device identity strategy, R&D groups may just seek a path of l= ess resistance. Even if an R&D group purchases a separate domain for te= sting with DNSSEC, they still have to sell the idea to the organization'= ;s technical leadership before=C2=A0it can be adopted under the organizatio= nal domain. Depending on the organization, that can be a big gamble. The R&= amp;D group has little room to negotiate the topic of DNS-based device iden= tity with technical leadership, without a transitional mode.

If we have a transitional protocol mo= de which allows gradual adoption, enterprises can more easily demonstrate i= nitial success with DNS-based identities. The full set of benefits, like di= rect support in the TLS protocol, can only be realized by completing the tr= ansition to DNSSEC. It's much easier to justify the adoption of DNSSEC = if it's tied to increasing the success of an existing initiative. We ce= rtainly don't want to diminish the importance of DNSSEC- this is about = incentivizing implementation by making it a part of an adoption path for DN= S-based identities.


> In response to the challenges related to ambiguity between identities<= br> > issued by different CAs, application owners frequently choose to onboa= rd
> IoT devices to a single CA. This process of credential issuance can be=
> time-consuming, which is further exacerbated by the sheer number of > entities participating in large-scale IoT deployments.

So I understand why a single CA solves the potential identity confusion. I don't understand why the scale matters here.=C2=A0 That sentence seem= s almost
a non-sequitor.

Each device needing to = be onboarded to an organizational PKI takes a certain amount of time to est= ablish an identity within that PKI. With a large-scale deployment with many= thousands of devices, the provisioning process can be time consuming and i= mpacts the cost of the project. If a supplier ships devices with immediatel= y useful DNS-based identities, then the network and application onboarding = time can be reduced, which has a favorable impact on project cost.


I think that the charter needs to introduce the message use case.
Or maybe delegate that more clearly.=C2=A0
Good point. I w= as trying to keep it concise, but left out some detail where it could have = been helpful.
--
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 data tr= ansmitted with it contains confidential and/or proprietary information inte= nded solely for the use of individual(s) authorized to receive it. If you a= re not an intended and authorized recipient you are hereby notified of any = use, disclosure, copying or distribution of the information included in thi= s transmission is prohibited and may be unlawful. Please immediately notify= the sender by replying to this email and then delete it from your system.<= /span>

--0000000000004d4eec05c4c15181-- From nobody Mon Jun 14 17:01:17 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 5DEED3A146B for ; Mon, 14 Jun 2021 17:01:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 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] 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 p3FW2BrENFHb for ; Mon, 14 Jun 2021 17:01:14 -0700 (PDT) Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (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 00CB83A146A for ; Mon, 14 Jun 2021 17:01:13 -0700 (PDT) Received: by straasha.imrryr.org (Postfix, from userid 1001) id 7D02CC5255; Mon, 14 Jun 2021 20:01:10 -0400 (EDT) Date: Mon, 14 Jun 2021 20:01:10 -0400 From: Viktor Dukhovni To: danish@ietf.org Message-ID: Reply-To: danish@ietf.org References: <4978.1623625466@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Archived-At: Subject: Re: [Danish] Proposed WG Charter 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, 15 Jun 2021 00:01:15 -0000 On Mon, Jun 14, 2021 at 02:26:50PM -0700, Ash Wilson wrote: > > If the charter of this WG is to sink DNSSEC, that needs to be stated > > explicitly in the charter, and then say why this work should not be in > > other PKI-based WGs. > > This charter proposes the creation of an easier adoption path for > DNS-based identities, which includes DNSSEC. I don't think anyone here > wants to sink DNSSEC. Well, but it sends a needlessly discouraging message, many of the purported difficulties with signing authoritative DNSSEC zones are anecdotal and outdated. Yes, not all registrars support DNSSEC equally well, but there are many registrars to choose from, vote with your feet and $$. Almost 15.2 million domains are already signed, the time has come to stop working around the right way to securely publish data in DNS. Piling on work-arounds does in fact hinder DNSSEC adoption, and we should seriously consider putting an end to this. -- Viktor. From nobody Mon Jun 14 17:11: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 4BC163A14B9 for ; Mon, 14 Jun 2021 17:11:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-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 lamvX0RScGkS for ; Mon, 14 Jun 2021 17:11:01 -0700 (PDT) Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (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 757B73A14B8 for ; Mon, 14 Jun 2021 17:11:01 -0700 (PDT) Received: by straasha.imrryr.org (Postfix, from userid 1001) id 420D2C551D; Mon, 14 Jun 2021 20:11:00 -0400 (EDT) Date: Mon, 14 Jun 2021 20:11:00 -0400 From: Viktor Dukhovni To: danish@ietf.org Message-ID: Reply-To: danish@ietf.org References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Archived-At: Subject: Re: [Danish] Proposed WG Charter 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, 15 Jun 2021 00:11:03 -0000 On Mon, Jun 14, 2021 at 02:13:10PM -0700, Ash Wilson wrote: > Very often, mobile data used for IoT ends up going into a message broker > or message queueing system, and the central application subscribes or > otherwise consumes information from the messaging middleware. Without some > sort of verifiable sender identity attached to the message itself, the > identity of the sender and the integrity of the message is assumed based on > the integrity of all middleware involved in passing messages. If we include > the sender's DNS name in the message and protect it with a signature, then > it may be verified by the central application, independent of the transport > over which it arrives. The encapsulation is then basically CMS I guess. Which supports attaching a signature and the signer's certificate chain to a message (as well as encrypting the message to the recipient(s)). > Consider that if a messaging middleware platform is trusted by > multiple sophisticated smart cities applications, and none of those > applications implement message authentication, the messaging > middleware platform itself becomes an attractive target for a > well-resourced adversary. Simply signing the messages passing through > the system removes the pressure on the broker to ensure integrity, and > reduces the value of a compromised broker. And I guess the proposal on the table is to use DNS as the identity database for clients, with TLSA records enabling the use of enterprise, or vendor CAs client onboarding. If the verifiers are then infrastructure services, they're more than capable of running a validating resolver, and sites sophisticated enough to operate a private CA are more than capable of signing their doain. Working around DNSSEC in this design seems rather more complex than just using it. -- Viktor. From nobody Mon Jun 14 18:00: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 D4E063A166D for ; Mon, 14 Jun 2021 18:00:07 -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, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 qN1JCaomnSRE for ; Mon, 14 Jun 2021 18:00:03 -0700 (PDT) Received: from mail-ed1-x52a.google.com (mail-ed1-x52a.google.com [IPv6:2a00:1450:4864:20::52a]) (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 53D873A166C for ; Mon, 14 Jun 2021 18:00:03 -0700 (PDT) Received: by mail-ed1-x52a.google.com with SMTP id ba2so47051352edb.2 for ; Mon, 14 Jun 2021 18:00:03 -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; bh=7yWpK5IlUqo69/yw0fXzhPUsUs5rDHFXupAlmwEsCK8=; b=RyfT1XuVFyfTvm8ygw7lTNrD+ABNCXQ4AeXPqJgc6IzZVFobMmPMMn6+hjUAJ3Yav5 ZV67s6e1iMMiEI9tWej/upKb0+LazmK1hFYtpNpHOT0rpmT9uvfb+Ovzu04CRkIzxUH7 XlkyKnIHNXDnT12GJe4R1MCAEHVGLdapzKsw52HkQ0RwMh7By2bkEKADxmTi1vu8+wg6 3FSjIEha3Ab/UeanJnlGjaM2hgYt9LtTUO5qNaUC6sQDPlE9ym3Ts+GxcY9TMQEkGMzn lv0d1uoQK8cWyWV8rd4QcIZ8G9nm2sNtwhqBjZZXDgQmsDz1r38oK6MyiaOucnRwGCPg vEkQ== 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; bh=7yWpK5IlUqo69/yw0fXzhPUsUs5rDHFXupAlmwEsCK8=; b=HC4sedgdn+W54otuZijqy5/jGaHls1Llopt4TU4MHVlV078Ywq9r6zlLibX2OW2emg FaRkvnCjGCuxNR84h0DMcCo2QlTowckOcL8yMAOrgV1allUOOYHRhgcFLvfP51OKFWlf tqsJWhAsO67xtTvIXh1Kq41NzZaFvD08I/2BbAgOj3+GQ02/JnK/2g5TnWIZ4DwNTLZW YTZsX9lzgly4Hj9UZQWXTmC6dtxSRwYSwjyMesCEIEOCO2SjG8HWu/4OtxJhRE5Jx0Vm HzBerGb9aWjJhD4rIeN8yCVmNOZ3JSnW8sdsf7D1WGxeBr9KTiCifOQrmVn6rMH4S/K8 tX7Q== X-Gm-Message-State: AOAM532NlQUK6sxeFyDXR6wbMtARVVDbG6/CzfRXNlrFFOp9bqg6cnTJ eMe88nzDvbfFQ33yV6f+U0cJnfOwCedTYXm37H8FClWx X-Google-Smtp-Source: ABdhPJxCcuWevkz2SRUuA3psmN5yGjqks6IdcHKT4rMMfYm30pU2JXqVor2xRz78v9G5KiGRrjOWfNB7r+nDRzvpfHs= X-Received: by 2002:aa7:d602:: with SMTP id c2mr20264278edr.317.1623718796252; Mon, 14 Jun 2021 17:59:56 -0700 (PDT) MIME-Version: 1.0 References: <4978.1623625466@localhost> In-Reply-To: From: Shumon Huque Date: Mon, 14 Jun 2021 20:59:45 -0400 Message-ID: To: danish@ietf.org Content-Type: multipart/alternative; boundary="00000000000010d84e05c4c37e5c" Archived-At: Subject: Re: [Danish] Proposed WG Charter 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, 15 Jun 2021 01:00:08 -0000 --00000000000010d84e05c4c37e5c Content-Type: text/plain; charset="UTF-8" On Mon, Jun 14, 2021 at 8:01 PM Viktor Dukhovni wrote: > On Mon, Jun 14, 2021 at 02:26:50PM -0700, Ash Wilson wrote: > > > > If the charter of this WG is to sink DNSSEC, that needs to be stated > > > explicitly in the charter, and then say why this work should not be in > > > other PKI-based WGs. > > > > This charter proposes the creation of an easier adoption path for > > DNS-based identities, which includes DNSSEC. I don't think anyone here > > wants to sink DNSSEC. > > Well, but it sends a needlessly discouraging message, many of the > purported difficulties with signing authoritative DNSSEC zones are > anecdotal and outdated. Yes, not all registrars support DNSSEC equally > well, but there are many registrars to choose from, vote with your feet > and $$. Almost 15.2 million domains are already signed, the time has > come to stop working around the right way to securely publish data in > DNS. > > Piling on work-arounds does in fact hinder DNSSEC adoption, and we > should seriously consider putting an end to this. > The BoF proponents have no desire to sink DNSSEC. It's the opposite in fact, but we also want to provide interim mechanisms for environments that don't have DNSSEC yet. I can also say from personal experience that deploying DNSSEC in a large complex enterprise remains extremely challenging. Some of the largest commercial DNS providers in the world have had constant challenges handling the scale of my employer's signed DNS (ask me offline sometime and I'll spill the beans). And just a few weeks ago, I found another critical DNSSEC bug in one of the major open source DNS implementations. Shumon. --00000000000010d84e05c4c37e5c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Jun 14, 2021 at 8:01 PM Viktor Du= khovni <ietf-dane@dukhovni.org= > wrote:
On Mon, Jun 14, 2021 at 02:26:50PM -0700, Ash Wi= lson wrote:

> > If the charter of this WG is to sink DNSSEC, that needs to be sta= ted
> > explicitly in the charter, and then say why this work should not = be in
> > other PKI-based WGs.
>
> This charter proposes the creation of an easier adoption path for
> DNS-based identities, which includes DNSSEC. I don't think anyone = here
> wants to sink DNSSEC.

Well, but it sends a needlessly discouraging message, many of the
purported difficulties with signing authoritative DNSSEC zones are
anecdotal and outdated.=C2=A0 Yes, not all registrars support DNSSEC equall= y
well, but there are many registrars to choose from, vote with your feet
and $$.=C2=A0 Almost 15.2 million domains are already signed, the time has<= br> come to stop working around the right way to securely publish data in
DNS.

Piling on work-arounds does in fact hinder DNSSEC adoption, and we
should seriously consider putting an end to this.

=
The BoF proponents have no desire to sink DNSSEC. It's the opposi= te
in fact, but we also want to provide int= erim mechanisms for environments
that don&#= 39;t have DNSSEC yet.

I can also say from personal experience that deploying = DNSSEC in
a large complex enterprise remain= s extremely challenging. Some of the
large= st commercial DNS providers in the world have had constant
challenges handling the scale of my employer's signed = DNS (ask me
offline sometime and I'll spill the beans). And just a f= ew weeks ago, I
found another critical DNSS= EC bug in one of the major open source
DNS = implementations.

Shumon.

--00000000000010d84e05c4c37e5c-- From nobody Mon Jun 14 18:29:25 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 4A62F3A18BB for ; Mon, 14 Jun 2021 18:29:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-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 SbQKRUoSfi_3 for ; Mon, 14 Jun 2021 18:29:21 -0700 (PDT) Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (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 C0CF23A18B8 for ; Mon, 14 Jun 2021 18:29:20 -0700 (PDT) Received: by straasha.imrryr.org (Postfix, from userid 1001) id B8012C53CC; Mon, 14 Jun 2021 21:29:18 -0400 (EDT) Date: Mon, 14 Jun 2021 21:29:18 -0400 From: Viktor Dukhovni To: danish@ietf.org Message-ID: Reply-To: danish@ietf.org References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Archived-At: Subject: Re: [Danish] Proposed WG Charter 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, 15 Jun 2021 01:29:23 -0000 On Mon, Jun 14, 2021 at 01:33:56PM -0700, Ash Wilson wrote: > > There is no explanation of whether the perceived barriers to DNSSEC > > adoption are on the authoritative or resolver side, or who are the > > primary intended users (consumer, enterprise, other?) for PKI a la > > DANISH. > > The objections I've encountered to DNSSEC (in having conversations > with would-be implementers) relate generally to a perception that the > benefits do not outweigh the risks. Without some concrete justification for these perceptions, one might treat them as mere superstition. There are many wrong and outdated memes out there, and some of them are worth dispelling. We can document best practices, substantial improvements in softwaree stacks that make ongoing signing largely effortless, ... > Some of those risks are related to technology challenges, and some > relate to hiring the right skillset to maintain and troubleshoot a > DNSSEC-protected domain. But instead of crippling the next generation of technology, it may well make more sense to address those issues (and they are in any case getting actively addressed). > In changing the location of DNSSEC in the adoption path for DNS-based > identities, we allow organizations to experience some success and > build confidence in the DNS-based identity strategy, which will > further incentivize the eventual adoption of DNSSEC. But the resulting protocol starts to look like a chimera. Let's first design a clean protocol, and then see whether there's a need to remove actual barriers to adoption. > > The term "discovering authentication keys" is not defined here. It is > > not clear that avoiding DNSSEC will make things simpler. Which is the > > more important barrier here, zone signing, or access to validating > > resolvers? > > Would replacing 'discovering authenticated keys' with 'discovering keys or > hashes to support TLS server authentication' remedy the lack of clarity? No, the actual problem is with this whole of "discovering" something. What exactly are you looking to discover. Perhaps you mean to say that you want locate trust-anchors (possibly just EE key bindings) for a given idenity. That'd much less hand-wavy than "discovering authenticated keys". > A DNS-based public key discovery mechanism for authenticating message > signatures, My problem is the phrase "key discovery", I don't know of any well understood mean for that phrase. > which does not rely on DNSSEC, may be experimented with and adopted by > any domain. I'd like to see the use-cases clearly stated, before jumping to "does not rely on DNSSEC". > If DNSSEC is a requirement for the message security use case (public > key discovery for signature validation), then only 2.47% of all .com > domains may even experiment with it. That's not true at all. Only the domains that want to do this need to get signed, and there's nobody standing in their way. > Justifying a transition to DNSSEC for an organization can be an uphill > battle. If DNSSEC is a requirement for further exploration of a > strategy that's already shown success, the chance of eventual adoption > of DNSSEC will be greater. Or, more likely, we'll enshrine yet another ugly work-around that'll be with us for decades to come. > > The phrase "DANE DNS record types" is not defined. Nor is it clear > > what it might for DNS records to be "secured by the Web PKI". > > Detail was intentionally left out of this part. Nevertheless, we can't just pepper the charter with meaningless phrases, if it is going to be stated, it should be sufficiently well defined to be understable. > > The use of "uniqueness" here is rather unclear. There's nothing wrong > > with multiple certificates each binding a key to some shared name, it > > just means that all the keys are associated with the same subject. Nor > > is it necessarily a problem if such bindings are obtained from multiple > > CAs (provided they are all properly validated and authorised). > > The challenge is in ensuring that an entity is bound to the correct role in > an application. If there is ambiguity in assigning information to its > source, or determining the appropriateness of a source for providing the > information to the application, then the information is not trustworthy. You're misusing the term "uniqueness". It seems you're looking for something akin to name constraints that limit which CAs are authorised to bind keys to names in a particular namespace. That's not "uniqueness". Rather it is name-constrained federation, where each part of the namespace is delegated to a select set of trust anchors. The charter suffers from a very non-standard fuzzy vocabulary, and needs more attention to either widely understood, and/or clearly explained definitions. > In a broader context, machines are being trusted not only to collect > information and perform actions, but increasingly to decide when > certain actions are to be performed. A more concrete example might be > a system which manages the addition of chemicals (fluoride, etc) to a > city's water supply, in response to telemetry from sensors. If a > sensor can be impersonated via naming collision (intentionally or > otherwise), Your use of "naming collisions" is non-standard. Collisions have nothing to do with it. The problem is who's trusted, not whether the same name appears in more than one certificate. > > > The DNS namespace, together with DNSSEC, forms the most widely-recognized > > > namespace and authenticated discovery mechanism on the Internet. > > > > Not clear what this is intended to convey. > > > > An agreement on one namespace is essential for preventing naming > collisions. This looks misguided, again, it isn't about collisions. > > > The use of CA-based PKI alone for client and message sender > > > authentication creates the possibility of naming collisions when > > > multiple CAs are trusted within the same application. > > > > It is rather unclear what this is getting at. Perhaps it is trying to > > evoke lack of effective name constraints in the WebPKI? > > Yes, you are correct. This needs better language in the charter. > > > In response to the challenges related to ambiguity between > > > identities issued by different CAs, application owners frequently > > > choose to onboard IoT devices to a single CA. > > > > Again, what exactly is this tryign to get at? > > Time is spent onboarding devices to the same PKI, to avoid naming > collisions. You keep using that phrase, ... but it does not carry your intended meaning. > > It seems that solving "ambiguity" is a major concern. So the term needs > > a clear definition and some motivating examples. > > Ambiguity here refers to naming collisions possible when using > multiple PKI within the same application. What do you think about > using "naming collision-free authentication across CAs" instead? I want to see a charter which does not mention the word "collision", which is not at all what you have in mind. > > But which barriers if any are applicable to the DANISH use-case? DNSSEC > > zone signing? DNSSEC resolution on roaming devices? Or tools to > > automate publishing data in DNS (signed or not), monitoring, ... > > DNSSEC zone signing Then expect serious pushback, because zone signing is a solved problem, the more difficult challenge is validation in captive portals, ..., but that seems to be a rather marginal concern in the intended use-cases. > > What is "trust chain discovery"? How is different from including all > > the relevant certificates with the message? What is "certificate > > discovery"? What makes these relevant to IoT? > > IoT applications frequently have network constraints which make the > in-message transmission of certificates and chains impractical or > impossible. Then they can mediate their communications through a proxy that augments the signed message with the missing certificates. Also with DANE-EE(3) only the leaf certificate needs to be provided, and it can be basically just the public key and a self-signature, or even an RFC7250 raw public key. > For example: A device uses a cellular connection to transmit water level > measurements to a central service, for a city's storm water management > application. Since falsified measurements could lead to chaos, we want > signatures on all of those measurements so that we have some measure of > sender authentication/attribution. The cellular bill would be substantially > higher if the cert/chain were transmitted along with every measurement and > signature. Compare that to just transmitting the measurement, the device's > DNS name, and a signature. > The authenticating central application can then > use a less constrained network connection to perform out-of-band > certificate discovery, based on the sending device's name, found in the > message itself. Or just use DANE-EE(3) and there's no need for any "certificate discovery". But if sending only the signature and not even the EE cert is desired, a TLSA "3 1 0" record can provide the bare public key, and you're done. Presto magic, not certificates at all to discover. > > Why is avoiding DNSSEC simpler than making it more compelling to deploy? > > Allowing some limited success with DNS-based identity is expected to > further incentivize adoption of DNSSEC. This isn't about avoiding DNSSEC. > Rather, it's about postponing the requirement so that an organization can > demonstrate value in an identity strategy that eventually requires DNSSEC. I am increasingly coming aroung to the view that this meme is outdated and no longer justifiable. There's no "eventually". -- Viktor. From nobody Mon Jun 14 18:34: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 EC0823A18F3 for ; Mon, 14 Jun 2021 18:34:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-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 Fw4cvvgf2Srs for ; Mon, 14 Jun 2021 18:34:32 -0700 (PDT) Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (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 CE4D13A18F0 for ; Mon, 14 Jun 2021 18:34:32 -0700 (PDT) Received: by straasha.imrryr.org (Postfix, from userid 1001) id C28E4C541A; Mon, 14 Jun 2021 21:34:30 -0400 (EDT) Date: Mon, 14 Jun 2021 21:34:30 -0400 From: Viktor Dukhovni To: danish@ietf.org Message-ID: Reply-To: danish@ietf.org References: <4978.1623625466@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Archived-At: Subject: Re: [Danish] Proposed WG Charter 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, 15 Jun 2021 01:34:34 -0000 On Mon, Jun 14, 2021 at 08:59:45PM -0400, Shumon Huque wrote: > I can also say from personal experience that deploying DNSSEC in > a large complex enterprise remains extremely challenging. Some of the > largest commercial DNS providers in the world have had constant > challenges handling the scale of my employer's signed DNS (ask me > offline sometime and I'll spill the beans). And just a few weeks ago, I > found another critical DNSSEC bug in one of the major open source > DNS implementations. For new applications one need not sign an existing legacy domain, it is easy to register a new dedicated domain that's signed from the getgo. There may be some minor obstacles along the way, but it rather looks like the software stacks are or will soon be ready to meet them head on. The specs produced by DANISH will not change the world overnight, the design should not be anchored in the past. -- Viktor. From nobody Tue Jun 15 06:31:00 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 0A4513A306F for ; Tue, 15 Jun 2021 06:30:59 -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_PASS=-0.001, UNPARSEABLE_RELAY=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 Oqnw-HfUf0hc for ; Tue, 15 Jun 2021 06:30:54 -0700 (PDT) Received: from nestor.zerospam.ca (nestor.zerospam.ca [209.172.38.88]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9224A3A306C for ; Tue, 15 Jun 2021 06:30:54 -0700 (PDT) X-ZEROSPAM_FILTERED: true Received: from nestor.zerospam.ca (localhost [127.0.0.1]) by nestor.zerospam.ca (Postfix) with ESMTP id 4G48Mw63nPz8sY6 for ; Tue, 15 Jun 2021 09:30:52 -0400 (EDT) Authentication-Results: nestor.zerospam.ca (ip=192.228.22.11); spf=none smtp.helo=mx1.cira.ca; spf=pass smtp.mailfrom=Jacques.Latour@cira.ca; dkim=none; dmarc=none (action=none) reason="No DMARC policy found" header.from=cira.ca Received: from 127.0.0.1 (127.0.0.1:12000) (original ip: 192.228.22.11) by nestor.zerospam.ca (Themis) with ESMTP id ziauZmPkFnD6YPedpev; Tue, 15 Jun 2021 09:30:50 -0400 Received: from mx1.cira.ca (nat.crp.cira.ca [192.228.22.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by nestor.zerospam.ca (Postfix) with ESMTPS id 4G48Mm2klYz8sWY for ; Tue, 15 Jun 2021 09:30:44 -0400 (EDT) Received: from CRP-EX16-02.CORP.CIRA.CA (10.2.36.121) by CRP-EX16-02.CORP.CIRA.CA (10.2.36.121) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.2242.4; Tue, 15 Jun 2021 09:30:43 -0400 Received: from CRP-EX16-02.CORP.CIRA.CA ([fe80::5d8a:4d4c:25ca:f689]) by CRP-EX16-02.CORP.CIRA.CA ([fe80::5d8a:4d4c:25ca:f689%14]) with mapi id 15.01.2242.004; Tue, 15 Jun 2021 09:30:43 -0400 From: Jacques Latour To: "danish@ietf.org" Thread-Topic: [EXT] Re: [Danish] IoT Device Identification with TLSA via Danish Thread-Index: AddhKvcSXHMYMAB6StqY1oKWkaM4dwAKXBKAACTZG3A= Date: Tue, 15 Jun 2021 13:30:43 +0000 Message-ID: <90e0d38f1a394b79987b5f1517cc157e@cira.ca> References: <02cb8931e16c4ccaa6eed1b89c0a20b6@cira.ca> In-Reply-To: Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_ee0e450f-d653-41c9-9b6c-2295bb19e3b2_Enabled=true; MSIP_Label_ee0e450f-d653-41c9-9b6c-2295bb19e3b2_SetDate=2021-06-15T13:30:42Z; MSIP_Label_ee0e450f-d653-41c9-9b6c-2295bb19e3b2_Method=Standard; MSIP_Label_ee0e450f-d653-41c9-9b6c-2295bb19e3b2_Name=Confidential; MSIP_Label_ee0e450f-d653-41c9-9b6c-2295bb19e3b2_SiteId=f349b30c-7550-4f17-88da-269417631f54; MSIP_Label_ee0e450f-d653-41c9-9b6c-2295bb19e3b2_ActionId=fb41d273-71bd-476d-8f6a-cbaa27eb74e4; MSIP_Label_ee0e450f-d653-41c9-9b6c-2295bb19e3b2_ContentBits=2 x-originating-ip: [10.2.36.1] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Danish] [EXT] Re: IoT Device Identification with TLSA via Danish 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, 15 Jun 2021 13:30:59 -0000 Top post: I think in the context of IoT Device Client Identity, the identit= y of an individual device can be revoked for other reasons than a compromis= e, for example if an IoT device is repurposed for a new use, then a new ide= ntity would be provisioned for the new purpose (new customer, new network),= I think having a method of knowing that the old identity is revoked (say f= or 3 months) would be useful. We would know for sure that the reprovisioni= ng of a new identity to the IoT device didn't work. Something like a CDS 0= 0 0 for TLSA. CLASSIFICATION:CONFIDENTIAL -----Original Message----- From: Danish On Behalf Of Viktor Dukhovni Sent: June 14, 2021 11:35 AM To: danish@ietf.org Subject: [EXT] Re: [Danish] IoT Device Identification with TLSA via Danish On Mon, Jun 14, 2021 at 02:40:38PM +0000, Jacques Latour wrote: > Today I presented at the ICANN DNSSEC workshop the potential results=20 > of DANISH working group which I think should include the entire scope=20 > having a mutual TLSA validated TLS session from an IoT device to a=20 > server. >=20 > https://github.com/CIRALabs/CIRA-Secure-IoT-Registry/blob/master/CIRA% > 20-%20Challenges%20in%20DNSSEC%20IoT%20Registry%20-%20ICANN%202021-6-1 > 4.pdf Thanks. > In addition, I was thinking there should be a 4th TLSA certificate=20 > usage, type 0 or 4, for TLSA to show cert that are revoked, if we know=20 > for sure the certificate is revoked then it should be presented and=20 > queried/answered as such, an authoritative answer signed with DNSSEC=20 > to say certificate is revoked, not to be trusted anymore. Picking nits, we already have four usages: - PKIX-TA(0) - PKIX-EE(1) - DANE-TA(2) - DANE-EE(3) but more importantly, there is no need for publishing revocation via DANE T= LSA, since all the certificates that don't match are effectively revoked. Therefore, the robust way to revoke all known and even *unknown* compromise= d certificates is to publish only PKIX-EE(1) or DANE-EE(3) TLSA records mat= ching the legitimate certificate of the service. If the goal is to deal with a known compromised key (the only use case hand= led by "revocation"), then exclusive use of PKIX-EE/DANE-EE records need on= ly extend past the original expiration of the would be revoked certificate,= after which time, one can return the service to using PKIX-TA/DANE-TA if d= esired. Better still, just always use DANE-EE/PKIX-EE and revocation is something y= ou never have to worry about. DANE obviates certificate revocation, good riddance. --=20 Viktor. -- Danish mailing list Danish@ietf.org https://www.ietf.org/mailman/listinfo/danish From nobody Tue Jun 15 06:56:17 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 E87E83A311B for ; Tue, 15 Jun 2021 06:56:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 uNsJxeBtk_az for ; Tue, 15 Jun 2021 06:56:13 -0700 (PDT) Received: from nestor.zerospam.ca (nestor.zerospam.ca [209.172.38.88]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19E153A311D for ; Tue, 15 Jun 2021 06:56:12 -0700 (PDT) X-ZEROSPAM_FILTERED: true Received: from nestor.zerospam.ca (localhost [127.0.0.1]) by nestor.zerospam.ca (Postfix) with ESMTP id 4G48x71HWlz8sWW for ; Tue, 15 Jun 2021 09:56:11 -0400 (EDT) Authentication-Results: nestor.zerospam.ca (ip=192.228.22.11); spf=none smtp.helo=mx1.cira.ca; spf=pass smtp.mailfrom=Jacques.Latour@cira.ca; dkim=none; dmarc=none (action=none) reason="No DMARC policy found" header.from=cira.ca Received: from 127.0.0.1 (127.0.0.1:12000) (original ip: 192.228.22.11) by nestor.zerospam.ca (Themis) with ESMTP id 533vdgTgaqR599kjNqx; Tue, 15 Jun 2021 09:56:10 -0400 Received: from mx1.cira.ca (nat.crp.cira.ca [192.228.22.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by nestor.zerospam.ca (Postfix) with ESMTPS id 4G48x636qdz8sWY for ; Tue, 15 Jun 2021 09:56:10 -0400 (EDT) Received: from CRP-EX16-02.CORP.CIRA.CA (10.2.36.121) by CRP-EX16-02.CORP.CIRA.CA (10.2.36.121) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.2242.4; Tue, 15 Jun 2021 09:56:09 -0400 Received: from CRP-EX16-02.CORP.CIRA.CA ([fe80::5d8a:4d4c:25ca:f689]) by CRP-EX16-02.CORP.CIRA.CA ([fe80::5d8a:4d4c:25ca:f689%14]) with mapi id 15.01.2242.004; Tue, 15 Jun 2021 09:56:09 -0400 From: Jacques Latour To: "danish@ietf.org" Thread-Topic: [EXT] Re: [Danish] Proposed WG Charter Thread-Index: AQHXYKh9LPXluHi4CUyn6iU6AfzdfasS1VUAgAF0YQCAACsfAIAAEF6AgAAJtgCAAIbcAA== Date: Tue, 15 Jun 2021 13:56:09 +0000 Message-ID: References: <4978.1623625466@localhost> In-Reply-To: Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.2.36.1] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Danish] [EXT] Re: Proposed WG Charter 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, 15 Jun 2021 13:56:16 -0000 =20 > The specs produced by DANISH will not change the world overnight, the des= ign > should not be anchored in the past. I agree that anchoring in the past might not be the best path forward. If = one has to write code to support the past, might as well support future / D= NSSEC... From nobody Tue Jun 15 06:57:15 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 5B7A23A3124 for ; Tue, 15 Jun 2021 06:57:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-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 OoLWwaCDnV17 for ; Tue, 15 Jun 2021 06:57:11 -0700 (PDT) Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (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 AC6C63A3122 for ; Tue, 15 Jun 2021 06:57:11 -0700 (PDT) Received: by straasha.imrryr.org (Postfix, from userid 1001) id 81F19C5D04; Tue, 15 Jun 2021 09:57:10 -0400 (EDT) Date: Tue, 15 Jun 2021 09:57:10 -0400 From: Viktor Dukhovni To: danish@ietf.org Message-ID: Reply-To: danish@ietf.org References: <02cb8931e16c4ccaa6eed1b89c0a20b6@cira.ca> <90e0d38f1a394b79987b5f1517cc157e@cira.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <90e0d38f1a394b79987b5f1517cc157e@cira.ca> Archived-At: Subject: Re: [Danish] [EXT] Re: IoT Device Identification with TLSA via Danish 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, 15 Jun 2021 13:57:13 -0000 On Tue, Jun 15, 2021 at 01:30:43PM +0000, Jacques Latour wrote: > Top post: I think in the context of IoT Device Client Identity, the > identity of an individual device can be revoked for other reasons than > a compromise, for example if an IoT device is repurposed for a new > use, then a new identity would be provisioned for the new purpose (new > customer, new network), I think having a method of knowing that the > old identity is revoked (say for 3 months) would be useful. We would > know for sure that the reprovisioning of a new identity to the IoT > device didn't work. Something like a CDS 0 0 0 for TLSA. This still does not make a case for revocation TLSA records. These would needlessly complicate existing implementations. The current design is that any matching TLSA record is sufficient for a valid outcome, and unsupported (unusable) TLSA record types can be safely ignored. Adding revocation records breaks the semantics. And, as I pointed out, the revocation record is redundant. Just publish "3 1 0" or "3 1 1" and you've renounced *all* other keys, by specifying only the valid key(s). -- Viktor. From nobody Tue Jun 15 10:22: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 630EB3A371F for ; Tue, 15 Jun 2021 10:22:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 mu9SQO8Pail2 for ; Tue, 15 Jun 2021 10:21:56 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A6D83A3724 for ; Tue, 15 Jun 2021 10:21:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 6B44338C13 for ; Tue, 15 Jun 2021 13:23:05 -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 zQvFS--vgM0n for ; Tue, 15 Jun 2021 13:23:05 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id DF78438C06 for ; Tue, 15 Jun 2021 13:23:04 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 5359E240 for ; Tue, 15 Jun 2021 13:21:54 -0400 (EDT) From: Michael Richardson To: danish@ietf.org In-Reply-To: References: <4978.1623625466@localhost> 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: Re: [Danish] Proposed WG Charter 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, 15 Jun 2021 17:22:02 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Viktor Dukhovni wrote: >> I can also say from personal experience that deploying DNSSEC in >> a large complex enterprise remains extremely challenging. Some of the >> largest commercial DNS providers in the world have had constant >> challenges handling the scale of my employer's signed DNS (ask me >> offline sometime and I'll spill the beans). And just a few weeks ago= , I >> found another critical DNSSEC bug in one of the major open source >> DNS implementations. > For new applications one need not sign an existing legacy domain, > it is easy to register a new dedicated domain that's signed from > the getgo. I was going to say the same thing. It also has the advantage of not having to deal with the marketing departme= nt. {However, it's a shame that example.com can't register devices.example.com directly.... or rather that DNSSEC can't jump over the insecured example.com.} So one winds up with devices-example.com or some such situation. > There may be some minor obstacles along the way, but it rather looks > like the software stacks are or will soon be ready to meet them head = on. > The specs produced by DANISH will not change the world overnight, the > design should not be anchored in the past. We are in agreement here: that's why I removed the mitigation as a work it= em from the initial charter. I think that we should still think about it thou= gh. =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+93Q3WUFAmDI4bIACgkQgItw+93Q 3WWTtAgAh8xCGICiT11N3PvhFLcVuNYO41d+N2DLYzdBxbDNGVCQnVRdSYrQKjbC N3r0NjiZ0aSDIZfC/AL68VipBo0rZFqt9Gk7djGujip+tHNp7NWWfMsHFC8h7if4 eRB3fi0umkHwoL1PMKzNN9ILAgy7EwgXxBsTYSY95tflm9yXDVbQ5yToBcs48SA0 jv+lKekngcOot86R6Gy+c9jExGzpj2M28Znd3HGlH3PSugpXpupINld37xqXS21q hJ5G7l0/FwAtVQfI1KZESiHe+mEOy2N3F0+fJXe4M70zuPxJdlj/QMgfXitnuAsN dd89gneJ/WUaYbuPRn6j/9C8BMkiow== =ASCe -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Jun 15 10:26:53 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 92FBB3A3745 for ; Tue, 15 Jun 2021 10:26:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, 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 2SoAP213UlXz for ; Tue, 15 Jun 2021 10:26:45 -0700 (PDT) Received: from mail-qv1-xf31.google.com (mail-qv1-xf31.google.com [IPv6:2607:f8b0:4864:20::f31]) (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 F1AA43A374A for ; Tue, 15 Jun 2021 10:26:44 -0700 (PDT) Received: by mail-qv1-xf31.google.com with SMTP id u13so59198qvt.7 for ; Tue, 15 Jun 2021 10:26: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; bh=gLosEar1pJxYTZyvgQhfLqlmJ0otuUicOc9r2DBroFM=; b=BwaZk2XBuRBpGkLz3en7rz6bqSu/lsW5p0JzAy2y8cxkZWTDgIIqQpAfveK+xYjuTG Mzl94eQNMhRvl/OC1pyep1iUcIjsvu0GNAoyD63i2bQjOPVH9Dj87xgTah2o+736Q4u3 VID5xWFfZHt3vxACK2cpXtUwqF9IxgPrBtWIYl4hivj0FruAoIYlroJsz3f/sL1xAu5A cX1sZTkrCCuDp1zGIDnlWQZmv7wMRyFmOYW+b1i0NoDOxF5J65rbuaURW7Y7eA5kJfx4 6tGS9RPkXHekw/EJehEEFD10t/gfoPju9dBUP32n2EJQ/qgR7POwUquMV/S1d/SYQKmT SOcw== 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; bh=gLosEar1pJxYTZyvgQhfLqlmJ0otuUicOc9r2DBroFM=; b=aeQCYu2Zjq6GKOeKZVj4bjr1JdeO0XZAZ+462VpjqxJ5N33kIIpjJieLZR1KzP+4Xz 6z54w2RUecmG0TPcKimsDWpJuMxEGhgjJN3tz0H8gYkcZVgdRWndqdg7my43bBpkunag hQ6VKJQvrJYxODzt/2bNs4Y6uUA8IpoCD8SYTXK+qfEJoNX2aEtItiz3ZBXIfkdWZtS0 h8euOnRJ6wxYj0OrN+VGAKWnJLIDwJcb40JsaRa1rDxNsV5fl5bDJBNpZ9Xw9Zx9P2sQ WAlaH7FlQfeSHKaQJ+AxgLVkS1OXJS2iCKBu8iGjvZvfQoqk7GKeZeFXlmZXVuoF0NMr 6Tuw== X-Gm-Message-State: AOAM532Fzc/WyxHSEANPcZxVEP+0LYXZYUUqFoXOQfb6uuiW4PUGezq4 Ehw6TDbE/VPPp62ttPFvnL3yM9NVHzVAn3DRj12j3q9OF0vT1g== X-Google-Smtp-Source: ABdhPJx3PQ8zl5ZbxRvNgr2lHT7Oq481jiYNHzU5+P8qHU7n3TiTtWQESYkX6qaUHQwgBWbWHhbmf1jHpUC3mKzQ1wA= X-Received: by 2002:ad4:4ea8:: with SMTP id ed8mr5184278qvb.58.1623778002734; Tue, 15 Jun 2021 10:26:42 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ash Wilson Date: Tue, 15 Jun 2021 10:26:31 -0700 Message-ID: To: danish@ietf.org Content-Type: multipart/alternative; boundary="0000000000000c240105c4d1478c" Archived-At: Subject: Re: [Danish] Proposed WG Charter 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, 15 Jun 2021 17:26:52 -0000 --0000000000000c240105c4d1478c Content-Type: text/plain; charset="UTF-8" Viktor, Bringing it back first to what we agree on: DNSSEC adoption has historically suffered from technical and perception challenges. Many of those technical challenges have been resolved, but still remain on the forefront of the would-be adopter's mind when considering the adoption of DNSSEC. The IETF does a great job of prioritizing the investment of time and effort in getting these issues resolved and documented. The current adoption of DNSSEC is disappointing. That number is currently 2.47% for the .com TLD (citing this time: http://rick.eng.br/dnssecstat/) Not all CS college programs include DNSSEC (or PKI, for that matter) at sufficient depth. Graduates aren't prepared to champion DNSSEC implementation in the face of DNSSEC's perception problems in the enterprise. Now, some things we may not agree on: Self-directed learning (in lieu of sufficient academic instruction) is usually driven by some sort of curiosity, and encouraged by the availability of the right materials. For DNSSEC, the right materials exist. DNSSEC is one of the best-documented sets of standards on the Internet. How-to guides are abundant. Nobody can say that DNSSEC isn't well-documented. Organizations with large DNSSEC footprints stand to benefit greatly from DNSSEC adoption. Compared with configuring DNSSEC on a new domain, which is a very simple and straightforward process, large organizations can face a level of complexity that cannot be effectively automated. It is easier to justify the adoption of DNSSEC as a part of a broader initiative that adds some business value beyond improving the security of an existing use case. Within an organization which has not already adopted DNSSEC, it is easier to justify initial exploration into a design pattern if DNSSEC is not in the initial set of requirements. This makes the assumption that exploration happens with oversight of enterprise technical leadership. It is easier to justify the adoption of DNSSEC to business leadership if it increases the value of an existing initiative, which is already showing success. The risk/return balance then has some demonstrated benefit, which makes a stronger argument against perceived risk. If DNSSEC is in the initial set of requirements for DNS-based IoT device identity, the desire to experiment with DNS-based device identity faces an increased likelihood of rejection when compared to an adoption path where DNSSEC is an eventual, rather than an initial, requirement. Offering a transitional mode will make DNSSEC easier to justify, because it brings more value to an initiative that can already show some limited success. Within an application where DANE TLSA records are already being used for verifying message signatures, the ability to perform mutual TLS authentication using TLSA records becomes a compelling argument in favor implementing DNSSEC, even for an organization which has historically been resistant to DNSSEC. I am proposing the use of DANE in TLS client authentication as the gating factor for requiring DNSSEC. Offering a transitional mode will positively affect the overall adoption of DNSSEC. To what degree is up for debate, but I think that we can both agree that some positive effect on the overall adoption of DNSSEC will result from having a transitional mode. Where you and I seem to disagree is whether the complexity involved is worth it. On Mon, Jun 14, 2021 at 6:29 PM Viktor Dukhovni wrote: > On Mon, Jun 14, 2021 at 01:33:56PM -0700, Ash Wilson wrote: > > > > There is no explanation of whether the perceived barriers to DNSSEC > > > adoption are on the authoritative or resolver side, or who are the > > > primary intended users (consumer, enterprise, other?) for PKI a la > > > DANISH. > > > > The objections I've encountered to DNSSEC (in having conversations > > with would-be implementers) relate generally to a perception that the > > benefits do not outweigh the risks. > > Without some concrete justification for these perceptions, one might > treat them as mere superstition. There are many wrong and outdated > memes out there, and some of them are worth dispelling. We can document > best practices, substantial improvements in softwaree stacks that make > ongoing signing largely effortless, ... > > Some of those risks are related to technology challenges, and some > > relate to hiring the right skillset to maintain and troubleshoot a > > DNSSEC-protected domain. > > But instead of crippling the next generation of technology, it may > well make more sense to address those issues (and they are in any > case getting actively addressed). > > > In changing the location of DNSSEC in the adoption path for DNS-based > > identities, we allow organizations to experience some success and > > build confidence in the DNS-based identity strategy, which will > > further incentivize the eventual adoption of DNSSEC. > > But the resulting protocol starts to look like a chimera. Let's first > design a clean protocol, and then see whether there's a need to remove > actual barriers to adoption. > > > > The term "discovering authentication keys" is not defined here. It is > > > not clear that avoiding DNSSEC will make things simpler. Which is the > > > more important barrier here, zone signing, or access to validating > > > resolvers? > > > > Would replacing 'discovering authenticated keys' with 'discovering keys > or > > hashes to support TLS server authentication' remedy the lack of clarity? > > No, the actual problem is with this whole of "discovering" something. > What exactly are you looking to discover. Perhaps you mean to say that > you want locate trust-anchors (possibly just EE key bindings) for a > given idenity. That'd much less hand-wavy than "discovering > authenticated keys". > > > A DNS-based public key discovery mechanism for authenticating message > > signatures, > > My problem is the phrase "key discovery", I don't know of any well > understood mean for that phrase. > > > which does not rely on DNSSEC, may be experimented with and adopted by > > any domain. > > I'd like to see the use-cases clearly stated, before jumping to "does > not rely on DNSSEC". > > > If DNSSEC is a requirement for the message security use case (public > > key discovery for signature validation), then only 2.47% of all .com > > domains may even experiment with it. > > That's not true at all. Only the domains that want to do this need to > get signed, and there's nobody standing in their way. > > > Justifying a transition to DNSSEC for an organization can be an uphill > > battle. If DNSSEC is a requirement for further exploration of a > > strategy that's already shown success, the chance of eventual adoption > > of DNSSEC will be greater. > > Or, more likely, we'll enshrine yet another ugly work-around that'll be > with us for decades to come. > > > > The phrase "DANE DNS record types" is not defined. Nor is it clear > > > what it might for DNS records to be "secured by the Web PKI". > > > > Detail was intentionally left out of this part. > > Nevertheless, we can't just pepper the charter with meaningless > phrases, if it is going to be stated, it should be sufficiently > well defined to be understable. > > > > The use of "uniqueness" here is rather unclear. There's nothing wrong > > > with multiple certificates each binding a key to some shared name, it > > > just means that all the keys are associated with the same subject. Nor > > > is it necessarily a problem if such bindings are obtained from multiple > > > CAs (provided they are all properly validated and authorised). > > > > The challenge is in ensuring that an entity is bound to the correct role > in > > an application. If there is ambiguity in assigning information to its > > source, or determining the appropriateness of a source for providing the > > information to the application, then the information is not trustworthy. > > You're misusing the term "uniqueness". It seems you're looking for > something akin to name constraints that limit which CAs are authorised > to bind keys to names in a particular namespace. That's not > "uniqueness". Rather it is name-constrained federation, where each > part of the namespace is delegated to a select set of trust anchors. > > The charter suffers from a very non-standard fuzzy vocabulary, and needs > more attention to either widely understood, and/or clearly explained > definitions. > > > In a broader context, machines are being trusted not only to collect > > information and perform actions, but increasingly to decide when > > certain actions are to be performed. A more concrete example might be > > a system which manages the addition of chemicals (fluoride, etc) to a > > city's water supply, in response to telemetry from sensors. If a > > sensor can be impersonated via naming collision (intentionally or > > otherwise), > > Your use of "naming collisions" is non-standard. Collisions have > nothing to do with it. The problem is who's trusted, not whether > the same name appears in more than one certificate. > > > > > The DNS namespace, together with DNSSEC, forms the most > widely-recognized > > > > namespace and authenticated discovery mechanism on the Internet. > > > > > > Not clear what this is intended to convey. > > > > > > An agreement on one namespace is essential for preventing naming > > collisions. > > This looks misguided, again, it isn't about collisions. > > > > > The use of CA-based PKI alone for client and message sender > > > > authentication creates the possibility of naming collisions when > > > > multiple CAs are trusted within the same application. > > > > > > It is rather unclear what this is getting at. Perhaps it is trying to > > > evoke lack of effective name constraints in the WebPKI? > > > > Yes, you are correct. > > This needs better language in the charter. > > > > > In response to the challenges related to ambiguity between > > > > identities issued by different CAs, application owners frequently > > > > choose to onboard IoT devices to a single CA. > > > > > > Again, what exactly is this tryign to get at? > > > > Time is spent onboarding devices to the same PKI, to avoid naming > > collisions. > > You keep using that phrase, ... but it does not carry your intended > meaning. > > > > It seems that solving "ambiguity" is a major concern. So the term > needs > > > a clear definition and some motivating examples. > > > > Ambiguity here refers to naming collisions possible when using > > multiple PKI within the same application. What do you think about > > using "naming collision-free authentication across CAs" instead? > > I want to see a charter which does not mention the word "collision", > which is not at all what you have in mind. > > > > But which barriers if any are applicable to the DANISH use-case? > DNSSEC > > > zone signing? DNSSEC resolution on roaming devices? Or tools to > > > automate publishing data in DNS (signed or not), monitoring, ... > > > > DNSSEC zone signing > > Then expect serious pushback, because zone signing is a solved problem, > the more difficult challenge is validation in captive portals, ..., but > that seems to be a rather marginal concern in the intended use-cases. > > > > What is "trust chain discovery"? How is different from including all > > > the relevant certificates with the message? What is "certificate > > > discovery"? What makes these relevant to IoT? > > > > IoT applications frequently have network constraints which make the > > in-message transmission of certificates and chains impractical or > > impossible. > > Then they can mediate their communications through a proxy that > augments the signed message with the missing certificates. Also > with DANE-EE(3) only the leaf certificate needs to be provided, > and it can be basically just the public key and a self-signature, > or even an RFC7250 raw public key. > > > For example: A device uses a cellular connection to transmit water level > > measurements to a central service, for a city's storm water management > > application. Since falsified measurements could lead to chaos, we want > > signatures on all of those measurements so that we have some measure of > > sender authentication/attribution. The cellular bill would be > substantially > > higher if the cert/chain were transmitted along with every measurement > and > > signature. Compare that to just transmitting the measurement, the > device's > > DNS name, and a signature. > > > The authenticating central application can then > > use a less constrained network connection to perform out-of-band > > certificate discovery, based on the sending device's name, found in the > > message itself. > > Or just use DANE-EE(3) and there's no need for any "certificate > discovery". But if sending only the signature and not even the > EE cert is desired, a TLSA "3 1 0" record can provide the bare > public key, and you're done. Presto magic, not certificates at > all to discover. > > > > Why is avoiding DNSSEC simpler than making it more compelling to > deploy? > > > > Allowing some limited success with DNS-based identity is expected to > > further incentivize adoption of DNSSEC. This isn't about avoiding DNSSEC. > > Rather, it's about postponing the requirement so that an organization can > > demonstrate value in an identity strategy that eventually requires > DNSSEC. > > I am increasingly coming aroung to the view that this meme is outdated > and no longer justifiable. There's no "eventually". > > -- > Viktor. > > -- > Danish mailing list > Danish@ietf.org > https://www.ietf.org/mailman/listinfo/danish > -- *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. --0000000000000c240105c4d1478c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Viktor,

Bringing it back first to= what we agree on:

DNSSEC adoption has historically suff= ered from technical and perception challenges. Many of those technical chal= lenges have been resolved, but still remain on the forefront of the would-b= e adopter's mind when considering the adoption of DNSSEC. The IETF does= a great job of prioritizing the investment of time and effort in getting t= hese issues resolved and documented.

The current a= doption of DNSSEC is disappointing. That number is currently 2.47% for the = .com TLD (citing this time: http= ://rick.eng.br/dnssecstat/)

Not all CS college= programs include DNSSEC (or PKI, for that matter) at sufficient depth. Gra= duates aren't prepared to champion DNSSEC implementation in the face of= DNSSEC's perception problems in the enterprise.=C2=A0
Now, some things we may not agree on:

Self-directed learning (in lieu of sufficient academic instruction) is usu= ally driven by some sort of curiosity,=C2=A0and encouraged by the availabil= ity of the right materials.

For DNSSEC, the right = materials exist. DNSSEC is one of the best-documented sets of standards on = the Internet. How-to guides are abundant. Nobody can say that DNSSEC isn= 9;t well-documented.

Organizations with large DNSS= EC footprints stand to benefit greatly from DNSSEC adoption. Compared with = configuring DNSSEC on a new domain, which is a very simple and straightforw= ard process, large organizations can face a level of complexity that cannot= be effectively automated.

It is easier to justify= the adoption of DNSSEC as a part of a broader initiative that adds some bu= siness value beyond improving the security of an existing use case.

Within an organization which=C2=A0has not already adopted= DNSSEC, it is easier to justify initial exploration into a design pattern = if DNSSEC is not in the initial set of requirements. This makes the assumpt= ion that exploration happens with oversight of enterprise technical leaders= hip.

It is easier to justify the adoption of DNSSE= C to business leadership if it increases the value of an existing initiativ= e, which is already showing success. The risk/return balance then has some = demonstrated benefit, which makes a stronger argument against perceived ris= k.

If DNSSEC is in the initial set of requirements= for DNS-based IoT device identity, the desire to experiment with DNS-based= device identity faces an increased likelihood of rejection when compared t= o an adoption path where DNSSEC is an eventual,=C2=A0rather than an initial= , requirement.

Offering a transitional mode will m= ake DNSSEC easier to justify, because it brings more value to an initiative= that can already show some limited success.

Withi= n an application where DANE TLSA records are already being used for verifyi= ng message signatures, the ability to perform mutual TLS authentication usi= ng TLSA records becomes a compelling argument in favor implementing DNSSEC,= even for an organization which has historically been resistant to DNSSEC. = I am proposing the use of DANE in TLS client authentication as the gating f= actor for requiring DNSSEC.

Offering a transitiona= l mode will positively affect the overall adoption of DNSSEC. To what degre= e is up for debate, but I think that we can both agree that some positive e= ffect on the overall adoption of DNSSEC will result from having a transitio= nal mode. Where you and I seem to disagree is whether the complexity involv= ed is worth it.=C2=A0

<= div dir=3D"ltr" class=3D"gmail_attr">
On Mon, Jun 14, 2021 at 6:29 PM Viktor Dukhovni <ietf-dane@dukhovni.org> wrote:
On Mon, Jun 14, 2021 at = 01:33:56PM -0700, Ash Wilson wrote:

> > There is no explanation of whether the perceived barriers to DNSS= EC
> > adoption are on the authoritative or resolver side, or who are th= e
> > primary intended users (consumer, enterprise, other?) for PKI a l= a
> > DANISH.
>
> The objections I've encountered to DNSSEC (in having conversations=
> with would-be implementers) relate generally to a perception that the<= br> > benefits do not outweigh the risks.

Without some concrete justification for these perceptions, one might
treat them as mere superstition.=C2=A0 There are many wrong and outdated memes out there, and some of them are worth dispelling.=C2=A0 We can docume= nt
best practices, substantial improvements in softwaree stacks that make
ongoing signing largely effortless, ...=C2=A0

> Some of those risks are related to technology challenges, and some
> relate to hiring the right skillset to maintain and troubleshoot a
> DNSSEC-protected domain.

But instead of crippling the next generation of technology, it may
well make more sense to address those issues (and they are in any
case getting actively addressed).

> In changing the location of DNSSEC in the adoption path for DNS-based<= br> > identities, we allow organizations to experience some success and
> build confidence in the DNS-based identity strategy, which will
> further incentivize the eventual adoption of DNSSEC.

But the resulting protocol starts to look like a chimera.=C2=A0 Let's f= irst
design a clean protocol, and then see whether there's a need to remove<= br> actual barriers to adoption.

> > The term "discovering authentication keys" is not defin= ed here.=C2=A0 It is
> > not clear that avoiding DNSSEC will make things simpler.=C2=A0 Wh= ich is the
> > more important barrier here, zone signing, or access to validatin= g
> > resolvers?
>
> Would replacing 'discovering authenticated keys' with 'dis= covering keys or
> hashes to support TLS server authentication' remedy the lack of cl= arity?

No, the actual problem is with this whole of "discovering" someth= ing.
What exactly are you looking to discover.=C2=A0 Perhaps you mean to say tha= t
you want locate trust-anchors (possibly just EE key bindings) for a
given idenity.=C2=A0 That'd much less hand-wavy than "discovering<= br> authenticated keys".

> A DNS-based public key discovery mechanism for authenticating message<= br> > signatures,

My problem is the phrase "key discovery", I don't know of any= well
understood mean for that phrase.

> which does not rely on DNSSEC, may be experimented with and adopted by=
> any domain.

I'd like to see the use-cases clearly stated, before jumping to "d= oes
not rely on DNSSEC".

> If DNSSEC is a requirement for the message security use case (public > key discovery for signature validation), then only 2.47% of all .com > domains may even experiment with it.

That's not true at all.=C2=A0 Only the domains that want to do this nee= d to
get signed, and there's nobody standing in their way.

> Justifying a transition to DNSSEC for an organization can be an uphill=
> battle. If DNSSEC is a requirement for further exploration of a
> strategy that's already shown success, the chance of eventual adop= tion
> of DNSSEC will be greater.

Or, more likely, we'll enshrine yet another ugly work-around that'l= l be
with us for decades to come.

> > The phrase "DANE DNS record types" is not defined.=C2= =A0 Nor is it clear
> > what it might for DNS records to be "secured by the Web PKI&= quot;.
>
> Detail was intentionally left out of this part.

Nevertheless, we can't just pepper the charter with meaningless
phrases, if it is going to be stated, it should be sufficiently
well defined to be understable.

> > The use of "uniqueness" here is rather unclear.=C2=A0 T= here's nothing wrong
> > with multiple certificates each binding a key to some shared name= , it
> > just means that all the keys are associated with the same subject= .=C2=A0 Nor
> > is it necessarily a problem if such bindings are obtained from mu= ltiple
> > CAs (provided they are all properly validated and authorised). >
> The challenge is in ensuring that an entity is bound to the correct ro= le in
> an application. If there is ambiguity in assigning information to its<= br> > source, or determining the appropriateness of a source for providing t= he
> information to the application, then the information is not trustworth= y.

You're misusing the term "uniqueness".=C2=A0 It seems you'= ;re looking for
something akin to name constraints that limit which CAs are authorised
to bind keys to names in a particular namespace.=C2=A0 That's not
"uniqueness".=C2=A0 =C2=A0Rather it is name-constrained federatio= n, where each
part of the namespace is delegated to a select set of trust anchors.

The charter suffers from a very non-standard fuzzy vocabulary, and needs more attention to either widely understood, and/or clearly explained
definitions.

> In a broader context, machines are being trusted not only to collect > information and perform actions, but increasingly to decide when
> certain actions are to be performed. A more concrete example might be<= br> > a system which manages the addition of chemicals (fluoride, etc) to a<= br> > city's water supply, in response to telemetry from sensors. If a > sensor can be impersonated via naming collision (intentionally or
> otherwise),

Your use of "naming collisions" is non-standard.=C2=A0 Collisions= have
nothing to do with it.=C2=A0 The problem is who's trusted, not whether<= br> the same name appears in more than one certificate.

> > > The DNS namespace, together with DNSSEC, forms the most wide= ly-recognized
> > > namespace and authenticated discovery mechanism on the Inter= net.
> >
> > Not clear what this is intended to convey.
> >
> > An agreement on one namespace is essential for preventing naming<= br> > collisions.

This looks misguided, again, it isn't about collisions.

> > > The use of CA-based PKI alone for client and message sender<= br> > > > authentication creates the possibility of naming collisions = when
> > > multiple CAs are trusted within the same application.
> >
> > It is rather unclear what this is getting at.=C2=A0 Perhaps it is= trying to
> > evoke lack of effective name constraints in the WebPKI?
>
> Yes, you are correct.

This needs better language in the charter.

> > > In response to the challenges related to ambiguity between > > > identities issued by different CAs, application owners frequ= ently
> > > choose to onboard IoT devices to a single CA.
> >
> > Again, what exactly is this tryign to get at?
>
> Time is spent onboarding devices to the same PKI, to avoid naming
> collisions.

You keep using that phrase, ... but it does not carry your intended
meaning.

> > It seems that solving "ambiguity" is a major concern.= =C2=A0 So the term needs
> > a clear definition and some motivating examples.
>
> Ambiguity here refers to naming collisions possible when using
> multiple PKI within the same application.=C2=A0 What do you think abou= t
> using "naming collision-free authentication across CAs" inst= ead?

I want to see a charter which does not mention the word "collision&quo= t;,
which is not at all what you have in mind.

> > But which barriers if any are applicable to the DANISH use-case?= =C2=A0 DNSSEC
> > zone signing?=C2=A0 DNSSEC resolution on roaming devices?=C2=A0 O= r tools to
> > automate publishing data in DNS (signed or not), monitoring, ...<= br> >
> DNSSEC zone signing

Then expect serious pushback, because zone signing is a solved problem,
the more difficult challenge is validation in captive portals, ..., but
that seems to be a rather marginal concern in the intended use-cases.

> > What is "trust chain discovery"?=C2=A0 How is different= from including all
> > the relevant certificates with the message?=C2=A0 What is "c= ertificate
> > discovery"?=C2=A0 What makes these relevant to IoT?
>
> IoT applications frequently have network constraints which make the > in-message transmission of certificates and chains impractical or
> impossible.

Then they can mediate their communications through a proxy that
augments the signed message with the missing certificates.=C2=A0 Also
with DANE-EE(3) only the leaf certificate needs to be provided,
and it can be basically just the public key and a self-signature,
or even an RFC7250 raw public key.

> For example: A device uses a cellular connection to transmit water lev= el
> measurements to a central service, for a city's storm water manage= ment
> application. Since falsified measurements could lead to chaos, we want=
> signatures on all of those measurements so that we have some measure o= f
> sender authentication/attribution. The cellular bill would be substant= ially
> higher if the cert/chain were transmitted along with every measurement= and
> signature. Compare that to just transmitting the measurement, the devi= ce's
> DNS name, and a signature.

> The authenticating central application can then
> use a less constrained network connection to perform out-of-band
> certificate discovery, based on the sending device's name, found i= n the
> message itself.

Or just use DANE-EE(3) and there's no need for any "certificate discovery".=C2=A0 But if sending only the signature and not even the EE cert is desired, a TLSA "3 1 0" record can provide the bare public key, and you're done.=C2=A0 Presto magic, not certificates at all to discover.

> > Why is avoiding DNSSEC simpler than making it more compelling to = deploy?
>
> Allowing some limited success with DNS-based identity is expected to > further incentivize adoption of DNSSEC. This isn't about avoiding = DNSSEC.
> Rather, it's about postponing the requirement so that an organizat= ion can
> demonstrate value in an identity strategy that eventually requires DNS= SEC.

I am increasingly coming aroung to the view that this meme is outdated
and no longer justifiable.=C2=A0 There's no "eventually".

--
=C2=A0 =C2=A0 Viktor.

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


--

Ash Wilson | Technical Dire= ctor

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

--0000000000000c240105c4d1478c-- From nobody Tue Jun 15 10:45:33 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 3782D3A37E0 for ; Tue, 15 Jun 2021 10:45:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, 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 vRApQXKJccNm for ; Tue, 15 Jun 2021 10:45:27 -0700 (PDT) Received: from mail-qv1-xf30.google.com (mail-qv1-xf30.google.com [IPv6:2607:f8b0:4864:20::f30]) (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 2AB953A37DC for ; Tue, 15 Jun 2021 10:45:26 -0700 (PDT) Received: by mail-qv1-xf30.google.com with SMTP id r19so101740qvw.5 for ; Tue, 15 Jun 2021 10:45:26 -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=KTin0/8nb275s1s7lKTQEmcCDeKtg5/J8hxs2+fK/9A=; b=F25S97q+T4k/HwSXZDS9h7rJK8tELuzDO+G53C4M9uRvbXs2ZgcXbeePjXOipNZ4E6 6TuDP5SM4Gv3JFPksz37Gp9uxkMVgRfM4H/cyn9/tQgNSOyafZa6zIhrMMhuiNzyO0pw LdbXWi/j0qMnP+YLHORtANycfqKvlF8Q8UtN5t2GA9pvhmky8bxgcWYXEaoQXW4jXKib Q2oEQif8yUu604tRMckC75FOBnNVecXMzjE3yo7HcKDhdKYJ+NSePNkd3E/aUBwFc69P cCxmPXUkMCq+i5L4woF7JqJfzxXxAtNz/O/TDdipeBJTPumNNjze4Wtd7Uy9OpcTMHjD hWgw== 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=KTin0/8nb275s1s7lKTQEmcCDeKtg5/J8hxs2+fK/9A=; b=C/tZRXsznA3wtwlO1+vXzt+FxVoJYKvcLl2Y10vZZQQaKUnLtJmEDC8uqJF3oobS5w B2uwZFoL3MGLbLcd4KHvcYNxScd+HcqM8cg8YBbQytObZPlf5LTkR9UvFDuzlpBE9ziX 3EGMcmKJ2+MaKD3uQLjl6c6t/C0sVSMeWHNKN1AtZGjcePtFl0AEx3dT2TIu1TRhqolI 12811zVrW4PBuVGo5x8okMsRFLERo4CZmTgPQR54gS7wFMgAwBjlCY+uQxlk2+VGJ/Ry 5NNXJDqnRzPM2/nf5SKi01ZvT1q/B7WZvX7lB+Wfjt/+VcWRhyb8k60n19DRjC1aqAeC CAiA== X-Gm-Message-State: AOAM531jwtdBPwyByXKRU+nrJMUfC057h/J+rjGRiYiBIcNzqcXX5pgK rKrRY47hXIqcNGcPhaHmQFXjvLd/N4A1Dg6cdoWqR4zi+5s= X-Google-Smtp-Source: ABdhPJx8B6+7rq+s9eqWZfzSmiVtogACQ+6cOtmqwOYEWaGUam4+DlnHswZXwQmLILXc0dmrbQ64edH71juVUMfaD0Y= X-Received: by 2002:a05:6214:c6b:: with SMTP id t11mr6159969qvj.31.1623779125027; Tue, 15 Jun 2021 10:45:25 -0700 (PDT) MIME-Version: 1.0 References: <4978.1623625466@localhost> <9617.1623777714@localhost> In-Reply-To: <9617.1623777714@localhost> From: Ash Wilson Date: Tue, 15 Jun 2021 10:45:13 -0700 Message-ID: To: Michael Richardson Cc: danish@ietf.org Content-Type: multipart/alternative; boundary="000000000000f0f99805c4d18909" Archived-At: Subject: Re: [Danish] Proposed WG Charter X-BeenThere: danish@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DANE AutheNtication for Iot Service Hardening List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jun 2021 17:45:32 -0000 --000000000000f0f99805c4d18909 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Jun 15, 2021 at 10:22 AM Michael Richardson wrote: > > Viktor Dukhovni wrote: > >> I can also say from personal experience that deploying DNSSEC in > >> a large complex enterprise remains extremely challenging. Some of > the > >> largest commercial DNS providers in the world have had constant > >> challenges handling the scale of my employer's signed DNS (ask me > >> offline sometime and I'll spill the beans). And just a few weeks > ago, I > >> found another critical DNSSEC bug in one of the major open source > >> DNS implementations. > > > For new applications one need not sign an existing legacy domain, > > it is easy to register a new dedicated domain that's signed from > > the getgo. > > I was going to say the same thing. > It also has the advantage of not having to deal with the marketing > department. > > {However, it's a shame that example.com can't register devices.example.co= m > directly.... or rather that DNSSEC can't jump over the insecured > example.com.} > So one winds up with devices-example.com or some such situation. > Purchasing a new domain for work use, when you work within a large company, isn't always quick or easy. Sometimes you have an existing delegation to work with (labs.example) and if DNSSEC is not a requirement for exploration, you don't need to go through justification and procurement before getting started. > > There may be some minor obstacles along the way, but it rather look= s > > like the software stacks are or will soon be ready to meet them hea= d > on. > > > The specs produced by DANISH will not change the world overnight, t= he > > design should not be anchored in the past. > > We are in agreement here: that's why I removed the mitigation as a work > item > from the initial charter. I think that we should still think about it > though. > > -- > 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. --000000000000f0f99805c4d18909 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Jun 15, 2021 at 10:22 AM Mich= ael Richardson <mcr+ietf@sand= elman.ca> wrote:

Viktor Dukhovni <ietf-dane@dukhovni.org> wrote:
=C2=A0 =C2=A0 >> I can also say from personal experience that deployi= ng DNSSEC in
=C2=A0 =C2=A0 >> a large complex enterprise remains extremely challen= ging. Some of the
=C2=A0 =C2=A0 >> largest commercial DNS providers in the world have h= ad constant
=C2=A0 =C2=A0 >> challenges handling the scale of my employer's s= igned DNS (ask me
=C2=A0 =C2=A0 >> offline sometime and I'll spill the beans). And = just a few weeks ago, I
=C2=A0 =C2=A0 >> found another critical DNSSEC bug in one of the majo= r open source
=C2=A0 =C2=A0 >> DNS implementations.

=C2=A0 =C2=A0 > For new applications one need not sign an existing legac= y domain,
=C2=A0 =C2=A0 > it is easy to register a new dedicated domain that's= signed from
=C2=A0 =C2=A0 > the getgo.

I was going to say the same thing.
It also has the advantage of not having to deal with the marketing departme= nt.

{However, it's a shame that example.com can't register devices.exampl= e.com
directly.... or rather that DNSSEC can't jump over the insecured
example= .com.}
So one winds up with devices-example.com or some such situation.

Purchasing a new domain for work use, when y= ou work within a large company, isn't always quick or easy. Sometimes y= ou have an existing delegation to work with (labs.example) and if DNSSEC is= not a requirement for exploration, you don't need to go through justif= ication and procurement before getting started.=C2=A0

<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">
=C2=A0 =C2=A0 > There may be some minor obstacles along the way, but it = rather looks
=C2=A0 =C2=A0 > like the software stacks are or will soon be ready to me= et them head on.

=C2=A0 =C2=A0 > The specs produced by DANISH will not change the world o= vernight, the
=C2=A0 =C2=A0 > design should not be anchored in the past.

We are in agreement here:=C2=A0 that's why I removed the mitigation as = a work item
from the initial charter.=C2=A0 I think that we should still think about it= though.

--
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 data tr= ansmitted with it contains confidential and/or proprietary information inte= nded solely for the use of individual(s) authorized to receive it. If you a= re not an intended and authorized recipient you are hereby notified of any = use, disclosure, copying or distribution of the information included in thi= s transmission is prohibited and may be unlawful. Please immediately notify= the sender by replying to this email and then delete it from your system.<= /span>

--000000000000f0f99805c4d18909-- From nobody Tue Jun 15 11:38:38 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 08A9D3A395F for ; Tue, 15 Jun 2021 11:38:36 -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 s8UbVk5sDgr4 for ; Tue, 15 Jun 2021 11:38:31 -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 DFDFB3A395B for ; Tue, 15 Jun 2021 11:38:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 6731C38C31; Tue, 15 Jun 2021 14:39:37 -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 47vseerJI6Pf; Tue, 15 Jun 2021 14:39:36 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 4689538C06; Tue, 15 Jun 2021 14:39:36 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 804E6240; Tue, 15 Jun 2021 14:38:25 -0400 (EDT) From: Michael Richardson To: Jacques Latour , "danish\@ietf.org" In-Reply-To: <90e0d38f1a394b79987b5f1517cc157e@cira.ca> References: <02cb8931e16c4ccaa6eed1b89c0a20b6@cira.ca> <90e0d38f1a394b79987b5f1517cc157e@cira.ca> 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: Re: [Danish] [EXT] Re: IoT Device Identification with TLSA via Danish X-BeenThere: danish@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DANE AutheNtication for Iot Service Hardening List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jun 2021 18:38:36 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Jacques Latour wrote: > Top post: I think in the context of IoT Device Client Identity, the > identity of an individual device can be revoked for other reasons than > a compromise, for example if an IoT device is repurposed for a new us= e, > then a new identity would be provisioned for the new purpose (new > customer, new network), I think having a method of knowing that the o= ld > identity is revoked (say for 3 months) would be useful. We would know > for sure that the reprovisioning of a new identity to the IoT device > didn't work. A premise of DANISH is that the device comes with an identity, supplied by = a manufacturer. This is the part where the device does not need to go through an onboarding process (to a private CA), but rather it's enough to configure the name of the device into an authorization list. If the device is repurposed, then it won't get a new name. (that would require that it be onboarded with a name name, right?) So, in order to repurpose a device, it needs to be removed from whatever authorization list it was on, and then added to the new authorization list. Revoking the certificate would keep the device from being able to be used in the new purpose. {I personally think that this is a negative of DANISH. Maybe it's not a core aspect of it, but it seems like it to me.} =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+93Q3WUFAmDI86EACgkQgItw+93Q 3WVAnAf/c5nYNIj59f0q79e9qXjemdCYq/GTOzsZPM6FFlSbYfUnsm6MbGw+IBDn t29Ft/jQl3+CUP8ygQU2F4NLhqOFrHgZU0ga21cnndpqUUkicil+YgIRFyXYYgg4 sdf+OeV514piK7kRdgxKa7ijyiyLid/OWiYTjb8OlBUMSViUToZ5NwLLucSgG3pz ea+fGxG1xhBjNa+D30gEoyEoSJ+OycR0qmZ/o4at/UEXazquJ+CdGdZjObAQt23P 7YWOOysJypAtmq+ZUiQKxVZSleO7hYcMbELN855kcgoccWT2kOpffLdWR0qBQe/R NnhdnGeDSIt0Tii0kZGeAmyG323+ww== =e+nJ -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Jun 15 11:49:56 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 2BA083A39B4 for ; Tue, 15 Jun 2021 11:49:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-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 ZyoRStFov6M9 for ; Tue, 15 Jun 2021 11:49:49 -0700 (PDT) Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (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 A0AAD3A39AF for ; Tue, 15 Jun 2021 11:49:49 -0700 (PDT) Received: by straasha.imrryr.org (Postfix, from userid 1001) id 417D8C5D55; Tue, 15 Jun 2021 14:49:48 -0400 (EDT) Date: Tue, 15 Jun 2021 14:49:48 -0400 From: Viktor Dukhovni To: danish@ietf.org Message-ID: Reply-To: danish@ietf.org References: <02cb8931e16c4ccaa6eed1b89c0a20b6@cira.ca> <90e0d38f1a394b79987b5f1517cc157e@cira.ca> <32259.1623782305@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <32259.1623782305@localhost> Archived-At: Subject: Re: [Danish] [EXT] Re: IoT Device Identification with TLSA via Danish X-BeenThere: danish@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DANE AutheNtication for Iot Service Hardening List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jun 2021 18:49:54 -0000 On Tue, Jun 15, 2021 at 02:38:25PM -0400, Michael Richardson wrote: > A premise of DANISH is that the device comes with an identity, > supplied by a manufacturer. This is the part where the device does > not need to go through an onboarding process (to a private CA), but > rather it's enough to configure the name of the device into an > authorization list. > > If the device is repurposed, then it won't get a new name. (that would > require that it be onboarded with a name name, right?) This sounds like a provisioning + de-provisioning lifecycle issue, rather than an authentication issue. DANE is concerned only with authentication. Questions of authorisation are out of scope for DANE (and by extension the parts of DANISH that deal with validating certificate chains, ...). > So, in order to repurpose a device, it needs to be removed from > whatever authorization list it was on, and then added to the new > authorization list. Definitely, and the new authorisation list is perhaps a problem for an entirely new owner. > Revoking the certificate would keep the device from being able to be > used in the new purpose. Certificate revocation is not the right mechanism for dealing with authorisation changes. key, and bind that > {I personally think that this is a negative of DANISH. Maybe it's not > a core aspect of it, but it seems like it to me.} If the key is immutable for the lifetime of the device, and not strongly protected against extraction by its previous owner, then change of ownership potentially leaves the new owner unsure whether the device is still "trustworthy" (assuming it was ever trustworthy to begin with, ...walks away muttering something about supply chain security under his breath...) -- Viktor. From nobody Tue Jun 15 12:14:34 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 8DEF93A3ABF for ; Tue, 15 Jun 2021 12:14:24 -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, SPF_HELO_NONE=0.001, SPF_NONE=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=nohats.ca 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 KxEnko7dDbim for ; Tue, 15 Jun 2021 12:14:20 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (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 4F2F23A3AF0 for ; Tue, 15 Jun 2021 12:14:11 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 4G4J006DMkzCyd; Tue, 15 Jun 2021 21:14:08 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1623784448; bh=7OG7eNKlq9r1SrEk60SwrtyYweEQhZllkpqUWmBvVcM=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=nCmRTGrganGbiGIwF48ouVWKBiQoLpEs27cs+Juns21bZFy5lkQBbDzznCxPOiNgL 9UQ7sqDX4Eyn5EKcc8y6md6oWdxbc0wKqHHuItyqNrI08/1spUvvoK0ELe0CdY+oXp feM0EeT2XrzcdEeDfZO9lsgcyFfnJt+x7guYhX2Q= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id 2ZMdBeAj8_Hb; Tue, 15 Jun 2021 21:14:07 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [193.110.157.194]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Tue, 15 Jun 2021 21:14:07 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 911288354D; Tue, 15 Jun 2021 15:14:06 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 8CC1B8354C; Tue, 15 Jun 2021 15:14:06 -0400 (EDT) Date: Tue, 15 Jun 2021 15:14:06 -0400 (EDT) From: Paul Wouters To: Ash Wilson cc: danish@ietf.org In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=ISO-8859-15 Content-Transfer-Encoding: 8BIT Archived-At: Subject: Re: [Danish] Proposed WG Charter X-BeenThere: danish@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DANE AutheNtication for Iot Service Hardening List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jun 2021 19:14:33 -0000 On Mon, 14 Jun 2021, Ash Wilson wrote: > Very often, mobile data used for IoT ends up going into a message broker or message queueing system, and the central application subscribes or otherwise > consumes information from the messaging middleware. Without some sort of verifiable sender identity attached to the message itself, the identity of the > sender and the integrity of the message is assumed based on the integrity of all middleware involved in passing messages. If we include the sender's DNS > name in the message and protect it with a signature, then it may be verified by the central application, independent of the transport over which it > arrives. Then, mobile data network authentication becomes more about protecting availability and performance than preventing impersonation in a > message-oriented application. Use cases centering around mobile network identities are a little more nuanced, and the available mechanisms can vary based > on the mobile operator's tech stack. That's probably a better conversation for 3GPP. But the price of this method is revealing the DNS FQDN and IP of the IoT device. I can't come up with a use case where an IoT device would gain more than it loses from announcing to the world who it is and where it is. Traditionally, this is all done using public/private CA's where the client conveys it identity securely via TLS client authentication using a certificate, or by not authenticating the TLS client and forcint the client to do an authentication after the TLS connection has estbalishes, eg via Basic Auth at the HTTP level. > Consider that if a messaging middleware platform is trusted by multiple sophisticated smart cities applications, and none of those applications implement > message authentication, the messaging middleware platform itself becomes an attractive target for a well-resourced adversary. Simply signing the messages > passing through the system removes the pressure on the broker to ensure integrity, and reduces the value of a compromised broker. But again, at a price of exposing the identity and the IP address / locatin of the client. That makes it vulnerable to DoS attacks, eg flood pings to its IP, or more subtle timing attacks - eg I ping it but depending on the response time I can infer it is busy or not with its actual job. Paul From nobody Tue Jun 15 12:23: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 388213A3A9B for ; Tue, 15 Jun 2021 12:23: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, SPF_HELO_NONE=0.001, SPF_NONE=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=nohats.ca 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 6BifdgShv98x for ; Tue, 15 Jun 2021 12:23:48 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (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 5A5C33A3A99 for ; Tue, 15 Jun 2021 12:23:48 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 4G4JC70VtvzD0h for ; Tue, 15 Jun 2021 21:23:47 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1623785027; bh=8yhjGAuEVokxwvVNRxamUy45plCi/nr+lS4Yheiqabc=; h=Date:From:To:Subject:In-Reply-To:References; b=mhHAxYYxj/NKwoBma+P0DXH63ran+w2hXUGGHw2C9RzR1IP909qJe5XYGU0VR425n 3YAH3fV+kD+ILFnX1AZvWuu2wizmBT6IZNk7Y7Z9UxUhxB2vxjIUKsqkCXVIW5ztUN x2N8UespOYkf05vHnWW6Ujk6ue7O+nelJRHkWDMQ= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id 7OGRQEaK6lJ4 for ; Tue, 15 Jun 2021 21:23:46 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [193.110.157.194]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS for ; Tue, 15 Jun 2021 21:23:46 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id BCE788355C; Tue, 15 Jun 2021 15:23:44 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id B69F28355B for ; Tue, 15 Jun 2021 15:23:44 -0400 (EDT) Date: Tue, 15 Jun 2021 15:23:44 -0400 (EDT) From: Paul Wouters To: danish@ietf.org In-Reply-To: Message-ID: <534b6dc4-4d7b-e648-4131-885ce72a2ec1@nohats.ca> References: <02cb8931e16c4ccaa6eed1b89c0a20b6@cira.ca> <90e0d38f1a394b79987b5f1517cc157e@cira.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [Danish] [EXT] Re: IoT Device Identification with TLSA via Danish X-BeenThere: danish@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DANE AutheNtication for Iot Service Hardening List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jun 2021 19:23:54 -0000 On Tue, 15 Jun 2021, Viktor Dukhovni wrote: > On Tue, Jun 15, 2021 at 01:30:43PM +0000, Jacques Latour wrote: > >> Top post: I think in the context of IoT Device Client Identity, the >> identity of an individual device can be revoked for other reasons than >> a compromise, for example if an IoT device is repurposed for a new >> use, then a new identity would be provisioned for the new purpose (new >> customer, new network), I think having a method of knowing that the >> old identity is revoked (say for 3 months) would be useful. We would >> know for sure that the reprovisioning of a new identity to the IoT >> device didn't work. Something like a CDS 0 0 0 for TLSA. > > This still does not make a case for revocation TLSA records. These > would needlessly complicate existing implementations. The current > design is that any matching TLSA record is sufficient for a valid > outcome, and unsupported (unusable) TLSA record types can be safely > ignored. > > Adding revocation records breaks the semantics. And, as I pointed > out, the revocation record is redundant. Just publish "3 1 0" or > "3 1 1" and you've renounced *all* other keys, by specifying only > the valid key(s). I do have to agree with Viktor here. If you drop this assumption and publish revoked keys in TLSA, then you are basically mixing signals. The TLSA record says "valid", but now you _still_ have to do PKIX to determine if it is in fact not "invalid". This also kind of leads to a security level that is the lowerst of the two systems combined. Furthremo, it people start depending on revocation of certs inside TLSA, it will forever intertwine DNSSEC and PKIX into the future, and like Viktor already said, that would actually harm DNSSEC deployment instead of making an easier migration path to it. Paul From nobody Tue Jun 15 12:45:57 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 0BD793A3B95 for ; Tue, 15 Jun 2021 12:45:55 -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, SPF_HELO_NONE=0.001, SPF_NONE=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=nohats.ca 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 Url3zd_ZK0WO for ; Tue, 15 Jun 2021 12:45:50 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (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 7F6593A3B97 for ; Tue, 15 Jun 2021 12:45:50 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 4G4JhX5tPhzD0h; Tue, 15 Jun 2021 21:45:48 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1623786348; bh=qT8HRZusWt33f/cETLI9ODDkIKQ8sIHJt+2M2dCYC8s=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=QiLVuNwNtOYk1ghqyp59ECaWyiFX7ien7o/JovcwW8TfB2TN8Cx5Hg+xweLGY+Osy HTIF2Z8QtnARMx1suT+zzILi1mZ7XpdfYQpx7RR3RKKpAo0xIc7dNiBVZODRlLGHf/ B5fk3gdi1PUwXDkDGjdhBKBuWgaweHNiP2VdvJ2w= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id cHOE7S2h__q1; Tue, 15 Jun 2021 21:45:47 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [193.110.157.194]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Tue, 15 Jun 2021 21:45:47 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id EAB358356B; Tue, 15 Jun 2021 15:45:45 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id E40608356A; Tue, 15 Jun 2021 15:45:45 -0400 (EDT) Date: Tue, 15 Jun 2021 15:45:45 -0400 (EDT) From: Paul Wouters To: Ash Wilson cc: danish@ietf.org In-Reply-To: Message-ID: <36214e75-e77d-adba-4f50-e1fafd874d48@nohats.ca> References: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT Archived-At: Subject: Re: [Danish] Proposed WG Charter X-BeenThere: danish@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DANE AutheNtication for Iot Service Hardening List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jun 2021 19:45:55 -0000 On Tue, 15 Jun 2021, Ash Wilson wrote: > It is easier to justify the adoption of DNSSEC as a part of a broader initiative that adds some business value beyond improving the security of an > existing use case. > > Within an organization which has not already adopted DNSSEC, it is easier to justify initial exploration into a design pattern if DNSSEC is not in the > initial set of requirements. This makes the assumption that exploration happens with oversight of enterprise technical leadership. > > It is easier to justify the adoption of DNSSEC to business leadership if it increases the value of an existing initiative, which is already showing > success. The risk/return balance then has some demonstrated benefit, which makes a stronger argument against perceived risk. These arguments all applied to PKIX as well. Getting SSL on your server was "too hard" and "too cumbersum" and traction was really low to improve that, despite the strong case for it giving additional security. Then ACME and LetsEncrypt came and automation solved this problem. If DNSSEC is too difficult to do inhouse now, let your DNS hoster do it. Route 53 supports it via a checkbox. Cloudflare supports it via a checkbox. One click, done. Keep using the same TLS REST API to submit DNS updates. It just gets signed. Maybe some opensource tools need improving, eg lets get octodns to support DNSSEC fully. Let's improve knot/bind's methods for "editing" a zone so it works with DNSSEC. > If DNSSEC is in the initial set of requirements for DNS-based IoT device identity, the desire to experiment with DNS-based device identity faces an > increased likelihood of rejection when compared to an adoption path where DNSSEC is an eventual, rather than an initial, requirement. I would really prefer the IETF does not engage with putting security aspects in DNS records that are spoofable, and depend on a pluggable non-DNS security stack for validation of these insecure records. > Offering a transitional mode will make DNSSEC easier to justify The transition mode will never transition further towards DNSSEC. And as pointed out in this thread, that would be harmfull to DNSSEC deployment, not helping transition to it. > but I think that we can both agree that some positive effect on the overall adoption of DNSSEC will result from having a transitional mode. I don't think so. Paul From nobody Tue Jun 15 12:49: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 CD46B3A3BAF for ; Tue, 15 Jun 2021 12:49:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 XXyUGQTimmEo for ; Tue, 15 Jun 2021 12:49:01 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3A4B3A3BAD for ; Tue, 15 Jun 2021 12:49:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id A514138C2A; Tue, 15 Jun 2021 15:50:11 -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 SoByJKLoSBTo; Tue, 15 Jun 2021 15:50:10 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 5882038C23; Tue, 15 Jun 2021 15:50:10 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 657CE240; Tue, 15 Jun 2021 15:48:59 -0400 (EDT) From: Michael Richardson To: Paul Wouters , Ash Wilson , danish@ietf.org In-Reply-To: References: 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: Re: [Danish] Proposed WG Charter X-BeenThere: danish@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DANE AutheNtication for Iot Service Hardening List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jun 2021 19:49:09 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Paul Wouters wrote: > But the price of this method is revealing the DNS FQDN and IP of the = IoT > device. I can't come up with a use case where an IoT device would gain > more than it loses from announcing to the world who it is and where i= t is. Any communication from location FOO to MQTT server BAR, announces the device to anyone that can see the traffic. TLS1.3 does not send certificates in the clear, so neither would it send TLS Client IDs to get the certificate in the clear. By making TLS client side certificate authentication easier to manager, we eliminate (default!) passwords in the device. =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+93Q3WUFAmDJBCsACgkQgItw+93Q 3WUTmAgAtWh+qscAMWP/b+AJ+SLFDY4K0P0Noa154trVUsFL/u9vQf7l4ljb16by pIzXriyEBmnJP+M+kuMG3uqmPJeBwRUy4Tj2zXPf5RefMwOjGK+XhiWLlYQozDSR yrETqw0hAtbKLlSxXYyBaGbGmRRq0PPNtv0gRhTFbJx2MqzNQf1wA0QlvO2jJwxh BjUokGlPAZ6UAgARfNZgqDqHUHxfA/xkne6fte9XfSBAN0nuppI8cma0w0ofOLmL R2xQHnyD+0C+3Hz4mIuzplW1ge+1BAE/X8Aszv5voXs1oI2mgCOwjpbmDxRyMkPI Go98ZKBy+7qIZuCkZuxCVXCn8+35rg== =vAaP -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Jun 15 12:54: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 E74543A3BCE for ; Tue, 15 Jun 2021 12:54:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, 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 OElzwAntDKt2 for ; Tue, 15 Jun 2021 12:53:55 -0700 (PDT) Received: from mail-qv1-xf31.google.com (mail-qv1-xf31.google.com [IPv6:2607:f8b0:4864:20::f31]) (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 2C0A23A3BCB for ; Tue, 15 Jun 2021 12:53:55 -0700 (PDT) Received: by mail-qv1-xf31.google.com with SMTP id f5so321001qvu.8 for ; Tue, 15 Jun 2021 12:53:54 -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=vEY82GUFf0l+YqAqBFHqqI8KbggVeybp9MZ5nwmWPRc=; b=fpUwjDxtj0fz39jL+HCMON5olIuKxVfpWG9/nM0JK5oEiL5yWQJEIE8cxVcK12XJPY EHDYPbyNn1w+e/uOOfn0iIc0rhLq7ZXsC8KyAjugbwR9xDaWiPVEyTPUuMjcSNqWTXZ2 AqFhQXP3AOR3+mv1JppSMzXQmLGCxw/03Dwt/WEY6MmB9/oKNFnZBc85WjMpgpfL6rmG vEMR+hMFch+OxTLpRFWVFxQKf/Ek4Ed5ehvtRAg9IqkMmidZgtGnX07NoZUWLyFF9k3i 4RXGkmTs6BQ+464E48LpadPBICrtY12wrT0cSU9J3Su8Bvaxs/x+i2OybPvySSD45qdr caBA== 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=vEY82GUFf0l+YqAqBFHqqI8KbggVeybp9MZ5nwmWPRc=; b=AfN/psB+OyQCn1DCQC54wadVxQ3eM+z1/WfwdauNKuYKgBNL/72mQlcKFLxGTJ1FEJ nJ2g70aI4MocqwqKsz+g81+juM04PZYZMUjWB/XCaCz0O+YRH+JWvt6orUHHzV7qlniN mU/fIJDeWmbBBGTY6axoZTxXL9BrX8SuH9xgzm8PLAJnGVZZSWUY3BCPvxbjZMAwuQn1 r5pbjcIaKIDfL34wwGWzVq9RLuYkZY+J8Qe20W0jERPiv9L6gn8M/vswtpKV8KDZ8T2Q QFddnQXK6X/rEPlOEmKEzC9908zA8mIWIbqQeLef+HlA4wQpcIo4KaLJCvkBtxx+pSqh f7Sw== X-Gm-Message-State: AOAM5320O7JLP2vTARJJrSBOrEYX8JyREPx5yKnxUozSYfJe39MtvtK0 oLjMZrehPnXRXO83GTCq0WTlFL08d5uRxsJVedRbsVGBNyQ= X-Google-Smtp-Source: ABdhPJwaN6yRQ24gQbe1NddZwszrIwx7H7jva4dp/HKfhvbGw/K7ALKYr5xARNhzUZuIQfKbLZDI6wHRorre6GChLMg= X-Received: by 2002:a05:6214:c6b:: with SMTP id t11mr6707060qvj.31.1623786833201; Tue, 15 Jun 2021 12:53:53 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ash Wilson Date: Tue, 15 Jun 2021 12:53:42 -0700 Message-ID: To: Paul Wouters Cc: danish@ietf.org Content-Type: multipart/alternative; boundary="0000000000006261fc05c4d35571" Archived-At: Subject: Re: [Danish] Proposed WG Charter X-BeenThere: danish@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DANE AutheNtication for Iot Service Hardening List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jun 2021 19:54:02 -0000 --0000000000006261fc05c4d35571 Content-Type: text/plain; charset="UTF-8" Hi Paul, Thanks for the feedback, responses/clarification in-line below. On Tue, Jun 15, 2021 at 12:14 PM Paul Wouters wrote: > On Mon, 14 Jun 2021, Ash Wilson wrote: > > > Very often, mobile data used for IoT ends up going into a message broker > or message queueing system, and the central application subscribes or > otherwise > > consumes information from the messaging middleware. Without some sort of > verifiable sender identity attached to the message itself, the identity of > the > > sender and the integrity of the message is assumed based on the > integrity of all middleware involved in passing messages. If we include the > sender's DNS > > name in the message and protect it with a signature, then it may be > verified by the central application, independent of the transport over > which it > > arrives. Then, mobile data network authentication becomes more about > protecting availability and performance than preventing impersonation in a > > message-oriented application. Use cases centering around mobile network > identities are a little more nuanced, and the available mechanisms can vary > based > > on the mobile operator's tech stack. That's probably a better > conversation for 3GPP. > > But the price of this method is revealing the DNS FQDN and IP of the IoT > device. I can't come up with a use case where an IoT device would gain > more than it loses from announcing to the world who it is and where it is. > The use case where messaging middleware is used to get the message from the device to the service prevents the establishment of a TLS connection directly between the producer and consumer of the information. In many cases, the producer of the information doesn't even have IP connectivity. The producer (mobile UE, pick your term) sends messages through the provider network which eventually is presented for consumption by the provider. A number of message-passing layers may still exist between the mobile provider and the actual consumer of the messages produced by the device. The device has no IP to reveal, and the DNS FQDN is the sender's identity. . Some concept of sender identity is required for authentication and authorization. The application shouldn't trust information that cannot be attributed. If DNS is used as the public key discovery mechanism, the authenticity of the payload and the identity of the sender can be verified by the consuming application, even in the absence of a direct TLS connection, and for senders which do not even have IP connectivity. > Traditionally, this is all done using public/private CA's where the > client conveys it identity securely via TLS client authentication > using a certificate, or by not authenticating the TLS client and > forcint the client to do an authentication after the TLS connection > has estbalishes, eg via Basic Auth at the HTTP level. > Correct, for environments where a direct connection between the device and the core application are possible. Message brokers and other middleware layers prevent the establishment of a direct TLS connection between producer and consumer. Without a method for determining message sender identity, authn/authz from the perspective of the consumer is assumed based on the assumed integrity of every hop between the producer and consumer. > > > Consider that if a messaging middleware platform is trusted by multiple > sophisticated smart cities applications, and none of those applications > implement > > message authentication, the messaging middleware platform itself becomes > an attractive target for a well-resourced adversary. Simply signing the > messages > > passing through the system removes the pressure on the broker to ensure > integrity, and reduces the value of a compromised broker. > > But again, at a price of exposing the identity and the IP address / > locatin of the client. That makes it vulnerable to DoS attacks, eg > flood pings to its IP, or more subtle timing attacks - eg I ping it but > depending on the response time I can infer it is busy or not with its > actual job. > Paul > -- *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. --0000000000006261fc05c4d35571 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Paul,
Thanks for the feedback, responses= /clarification in-line below.

On Tue, Jun 15, 2021 at 12:14 PM Paul Wouters= <paul@nohats.ca> wrote:
On Mon, 14 Jun 2021, A= sh Wilson wrote:

> Very often, mobile data used for IoT ends up going into a message brok= er or message queueing system,=C2=A0and the central application subscribes = or otherwise
> consumes information from the messaging middleware. Without some sort = of verifiable sender identity attached to the message itself, the identity = of the
> sender and the integrity of the message is assumed based on the integr= ity of all middleware involved in passing messages. If we include the sende= r's DNS
> name in the message and protect it with a signature, then it may be ve= rified by the central application,=C2=A0independent of the transport over w= hich it
> arrives. Then, mobile data network authentication becomes more about p= rotecting availability and performance than preventing impersonation in a > message-oriented=C2=A0application. Use cases centering around mobile n= etwork identities are a little more nuanced,=C2=A0and the available mechani= sms can vary based
> on the mobile operator's tech stack. That's probably a better = conversation for 3GPP.

But the price of this method is revealing the DNS FQDN and IP of the IoT device. I can't come up with a use case where an IoT device would gain<= br> more than it loses from announcing to the world who it is and where it is.<= br>

=C2=A0The use case where messaging midd= leware is used to get the message from the device to the service prevents t= he establishment of a TLS connection directly between the producer and cons= umer of the information. In many cases, the producer of the information doe= sn't even have IP connectivity. The producer (mobile UE, pick your term= ) sends messages through the provider network which eventually is presented= for consumption by the provider. A number of message-passing layers may st= ill exist between the mobile provider and the actual consumer of the messag= es produced by the device.=C2=A0 The device has no IP to reveal, and the DN= S FQDN is the sender's identity. .

Some concep= t of sender identity is required for authentication and authorization. The= =C2=A0application shouldn't trust information that cannot be attributed= . If DNS is used as the public key discovery mechanism, the authenticity of= the payload and the identity of the sender can be verified by the consumin= g application, even in the absence of a direct TLS connection, and for send= ers which do not even have IP connectivity.


Traditionally, this is all done using public/private CA's where the
client conveys it identity securely via TLS client authentication
using a certificate, or by not authenticating the TLS client and
forcint the client to do an authentication after the TLS connection
has estbalishes, eg via Basic Auth at the HTTP level.
= Correct, for environments where a direct connection between the device and = the core application are possible. Message brokers and other middleware lay= ers prevent the establishment of a direct TLS connection between producer a= nd consumer. Without a method for determining message sender identity, auth= n/authz from the perspective of the consumer is assumed based on the assume= d integrity of every hop between the producer and consumer.

> Consider that if a messaging middleware platform is trusted by multipl= e sophisticated smart cities applications, and none of those applications i= mplement
> message authentication, the messaging middleware platform itself becom= es an attractive target for a well-resourced adversary. Simply signing the = messages
> passing through the system removes the pressure on the broker to ensur= e integrity, and reduces the value of a compromised broker.

But again, at a price of exposing the identity and the IP address /
locatin of the client. That makes it vulnerable to DoS attacks, eg
flood pings to its IP, or more subtle timing attacks - eg I ping it but
depending on the response time I can infer it is busy or not with its
actual job.=C2=A0

Paul


--

Ash Wilson | Technical Dire= ctor

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

--0000000000006261fc05c4d35571-- From nobody Tue Jun 15 12:57: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 4FCBC3A3BE8 for ; Tue, 15 Jun 2021 12:57:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 WHrF6HIt4Fzr for ; Tue, 15 Jun 2021 12:57:01 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC31C3A3BE6 for ; Tue, 15 Jun 2021 12:57:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 1873C38C23 for ; Tue, 15 Jun 2021 15:58:12 -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 gFinn7dZcxt7 for ; Tue, 15 Jun 2021 15:58:11 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 7901838BDF for ; Tue, 15 Jun 2021 15:58:11 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 7EDD8240 for ; Tue, 15 Jun 2021 15:57:00 -0400 (EDT) From: Michael Richardson To: danish@ietf.org In-Reply-To: References: <02cb8931e16c4ccaa6eed1b89c0a20b6@cira.ca> <90e0d38f1a394b79987b5f1517cc157e@cira.ca> <32259.1623782305@localhost> 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: Re: [Danish] [EXT] Re: IoT Device Identification with TLSA via Danish X-BeenThere: danish@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DANE AutheNtication for Iot Service Hardening List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jun 2021 19:57:06 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Viktor Dukhovni wrote: >> {I personally think that this is a negative of DANISH. Maybe it's n= ot >> a core aspect of it, but it seems like it to me.} > If the key is immutable for the lifetime of the device, and not > strongly protected against extraction by its previous owner, then > change of ownership potentially leaves the new owner unsure whether > the device is still "trustworthy" (assuming it was ever trustworthy > to begin with, ...walks away muttering something about supply chain > security under his breath...) Yes, that's the point. The immutability for the lifetime of the device is a source of great power, but also a problem. We should consider if we can use either subcerts/delegated certificates here in a useful way. https://datatracker.ietf.org/doc/draft-ietf-acme-star-delegation/ https://datatracker.ietf.org/doc/draft-ietf-tls-subcerts/ I have considered that using them would be appropriate when the IDevID is stored at the far side of a really slow I2C/SPI bus into a TPM. You don't = want to use it for "day to day" operations in that case. =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+93Q3WUFAmDJBgwACgkQgItw+93Q 3WX3AQf/RQPT7GPnVexZ7jXpsZoSLxqp44BMR/CTYelj2VnhZ3BEvCkAkxUgZ/do wSCwjESt3aR5i6ySih5i9YrqVU4TPvj3Q9RLfAoPJ5fYOPfCoAjLfzXedjE6BF38 L0+ViDWxxfos6z5SKsg1Bkf2CmhsMTpZvQUdH7ATZdYYe0kKJ1xlk96gNVccqi/x TFjCXJvVAejDuE/eR54Rl6zHKoHKn4spp5vaesH9wnOMryrLcBLLUmwMZpxBar1j XG8fmPLufUo1uaFu5bhuuTn8tjb2j5I1sKn64ZUNMKYDFb6PS+Xlx32SjQr1/cbb Fo2QXFoPsJNM50S7ktKiCRnemb4SQQ== =OqpQ -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Jun 15 13:06:31 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 4314A3A3C00 for ; Tue, 15 Jun 2021 13:06:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, 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 aIk96QYwndSo for ; Tue, 15 Jun 2021 13:06:25 -0700 (PDT) Received: from mail-qv1-xf29.google.com (mail-qv1-xf29.google.com [IPv6:2607:f8b0:4864:20::f29]) (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 D93CF3A3C27 for ; Tue, 15 Jun 2021 13:06:24 -0700 (PDT) Received: by mail-qv1-xf29.google.com with SMTP id c10so344813qvo.9 for ; Tue, 15 Jun 2021 13:06:24 -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=oUr3pR/sGcuDu/gC/J72YgJBcuuNtom55gv1gxRMN7o=; b=Xn8jyIKhI9YqkbdoiqfU5OEFqTco+FeMOq6Y0CyiBF/4QxLuRFT9VXmOBIgvy7d8lE 1CY8r69v+3kmt4vdo8U9vTNnaHNPghb34IBLNPh9364A38BX8pn8bvGTFTYaSFkkVPgp csTJrLPApFuP+QPSZ+yc8FZlmNwf5zTCZfO414tCKWM1N5e0NEglWzAjCFKvDIZOFEW+ wlVobeci3HXLHR4e62sGLGs61SazCoqjNkkSt97nrB5S4+L2tpYHwA4D1kGS83lh0xoa VleOCeCXEqyfEXg1aQOJLJaUvJCFQ2xRLB0elRBWjLflxax8LU+1YOsVGwhmdzgAQDI1 qsjQ== 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=oUr3pR/sGcuDu/gC/J72YgJBcuuNtom55gv1gxRMN7o=; b=TqExHzgujH2mkHqgWyiHMebMzKGIF+PUxe0vXlKCUIy3B5p5DTbMG36E5CR2BD/R3d XvDHRM5rCYMqvOtj7BkOQwfOJ5ezrfsP2FP1jIGXupZMFiVYipHo9c2pg+majROczEuK H/WAwqBkXhA66db4gphsl7SBlclAG9vSI4ovYMPs03rznaDi4IO5rjxI6vhBiVacqNZ2 OBOimzoGV5lirulFyW6ygpzWFakR6lxhB2WGmAMPaKR4dq4V+T9JR0qD2fsy/SnX5zXR m5G3O3VMlJYYYC6s+2KEP7YEXNaYnpqsOhZZg5N05+69q0Xvj+G7O4LsjgF8vyD7jDa6 fn2A== X-Gm-Message-State: AOAM532JPExZDqexXz8XYKicsJryY2A4i6v8/GotWrNe9KFZZpqYB1dd cbcWKbcukU8QIlVniBv4AzgK0q+Zp+nbgCG6Za4893IAMPI= X-Google-Smtp-Source: ABdhPJyczHvLJV7+OFYJ+zWURgeDDWNL8ylw7wOAinzasEzU9R8of+lo2Hktewzn349F9Nf/NEOJLZxYJQ25AVea6es= X-Received: by 2002:ad4:4ea8:: with SMTP id ed8mr5861176qvb.58.1623787583301; Tue, 15 Jun 2021 13:06:23 -0700 (PDT) MIME-Version: 1.0 References: <02cb8931e16c4ccaa6eed1b89c0a20b6@cira.ca> <90e0d38f1a394b79987b5f1517cc157e@cira.ca> <32259.1623782305@localhost> <24225.1623787020@localhost> In-Reply-To: <24225.1623787020@localhost> From: Ash Wilson Date: Tue, 15 Jun 2021 13:06:12 -0700 Message-ID: To: Michael Richardson Cc: danish@ietf.org Content-Type: multipart/alternative; boundary="00000000000017ffd505c4d3826c" Archived-At: Subject: Re: [Danish] [EXT] Re: IoT Device Identification with TLSA via Danish X-BeenThere: danish@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DANE AutheNtication for Iot Service Hardening List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jun 2021 20:06:30 -0000 --00000000000017ffd505c4d3826c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable FWIW, I'm a fan of immutable DNS names and rotating certs. If the device can rotate its own certificate with the CA, then an automation component between the CA and DNS server can manage the rotation for DANE via TLSA records. It only gets easier over time to guess private keys. Being able to rotate them would be a big advantage over the lifetime recommendation in IEEE 802.1AR for device certs. On Tue, Jun 15, 2021 at 12:57 PM Michael Richardson wrote: > > Viktor Dukhovni wrote: > >> {I personally think that this is a negative of DANISH. Maybe it's > not > >> a core aspect of it, but it seems like it to me.} > > > If the key is immutable for the lifetime of the device, and not > > strongly protected against extraction by its previous owner, then > > change of ownership potentially leaves the new owner unsure whether > > the device is still "trustworthy" (assuming it was ever trustworthy > > to begin with, ...walks away muttering something about supply chain > > security under his breath...) > > Yes, that's the point. > The immutability for the lifetime of the device is a source of great powe= r, > but also a problem. > > We should consider if we can use either subcerts/delegated certificates > here > in a useful way. > https://datatracker.ietf.org/doc/draft-ietf-acme-star-delegation/ > https://datatracker.ietf.org/doc/draft-ietf-tls-subcerts/ > > I have considered that using them would be appropriate when the IDevID is > stored at the far side of a really slow I2C/SPI bus into a TPM. You don'= t > want > to use it for "day to day" operations in that case. > > -- > 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. --00000000000017ffd505c4d3826c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
FWIW, I'm a fan of immutable DNS names and rotating ce= rts. If the device can rotate its own certificate with the CA, then an auto= mation component between the CA and DNS server can manage the rotation for = DANE via TLSA records.

It only gets easier over time to = guess private keys. Being able to rotate them would be a big advantage over= the lifetime recommendation in IEEE 802.1AR for device certs.
<= br>
On Tue,= Jun 15, 2021 at 12:57 PM Michael Richardson <mcr+ietf@sandelman.ca> wrote:

Viktor Dukhovni <ietf-dane@dukhovni.org> wrote:
=C2=A0 =C2=A0 >> {I personally think that this is a negative of DANIS= H.=C2=A0 Maybe it's not
=C2=A0 =C2=A0 >> a core aspect of it, but it seems like it to me.}
=C2=A0 =C2=A0 > If the key is immutable for the lifetime of the device, = and not
=C2=A0 =C2=A0 > strongly protected against extraction by its previous ow= ner, then
=C2=A0 =C2=A0 > change of ownership potentially leaves the new owner uns= ure whether
=C2=A0 =C2=A0 > the device is still "trustworthy" (assuming it= was ever trustworthy
=C2=A0 =C2=A0 > to begin with, ...walks away muttering something about s= upply chain
=C2=A0 =C2=A0 > security under his breath...)

Yes, that's the point.
The immutability for the lifetime of the device is a source of great power,=
but also a problem.

We should consider if we can use either subcerts/delegated certificates her= e
in a useful way.
=C2=A0 https://datatracker.ietf.org= /doc/draft-ietf-acme-star-delegation/
=C2=A0 https://datatracker.ietf.org/doc/dra= ft-ietf-tls-subcerts/

I have considered that using them would be appropriate when the IDevID is stored at the far side of a really slow I2C/SPI bus into a TPM.=C2=A0 You d= on't want
to use it for "day to day" operations in that case.

--
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 data tr= ansmitted with it contains confidential and/or proprietary information inte= nded solely for the use of individual(s) authorized to receive it. If you a= re not an intended and authorized recipient you are hereby notified of any = use, disclosure, copying or distribution of the information included in thi= s transmission is prohibited and may be unlawful. Please immediately notify= the sender by replying to this email and then delete it from your system.<= /span>

--00000000000017ffd505c4d3826c-- From nobody Tue Jun 15 13:36:25 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 1F1A13A3CF9 for ; Tue, 15 Jun 2021 13:36:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-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 wg3fBvES6T8Q for ; Tue, 15 Jun 2021 13:36:22 -0700 (PDT) Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (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 E71743A3C37 for ; Tue, 15 Jun 2021 13:36:21 -0700 (PDT) Received: by straasha.imrryr.org (Postfix, from userid 1001) id 99B84C6190; Tue, 15 Jun 2021 16:36:20 -0400 (EDT) Date: Tue, 15 Jun 2021 16:36:20 -0400 From: Viktor Dukhovni To: danish@ietf.org Message-ID: Reply-To: danish@ietf.org References: <02cb8931e16c4ccaa6eed1b89c0a20b6@cira.ca> <90e0d38f1a394b79987b5f1517cc157e@cira.ca> <32259.1623782305@localhost> <24225.1623787020@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Archived-At: Subject: Re: [Danish] [EXT] Re: IoT Device Identification with TLSA via Danish X-BeenThere: danish@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DANE AutheNtication for Iot Service Hardening List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jun 2021 20:36:23 -0000 On Tue, Jun 15, 2021 at 01:06:12PM -0700, Ash Wilson wrote: > FWIW, I'm a fan of immutable DNS names and rotating certs. If the device > can rotate its own certificate with the CA, then an automation component > between the CA and DNS server can manage the rotation for DANE via TLSA > records. This sounds reasonable, of course there needs to be some way to prevent the previous owner from also being able to rotate the device key based on knowledge of the previous key. Which means, that key rollover locks the previous key out of future device metadata updates. -- Viktor. From nobody Tue Jun 15 13:43: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 B7F983A3D35 for ; Tue, 15 Jun 2021 13:43:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 zg7cmP8PKdPv for ; Tue, 15 Jun 2021 13:43:30 -0700 (PDT) Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (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 3D7933A3D3A for ; Tue, 15 Jun 2021 13:43:30 -0700 (PDT) Received: by straasha.imrryr.org (Postfix, from userid 1001) id 449DCC5D7F; Tue, 15 Jun 2021 16:43:29 -0400 (EDT) Date: Tue, 15 Jun 2021 16:43:29 -0400 From: Viktor Dukhovni To: danish@ietf.org Message-ID: Reply-To: danish@ietf.org References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Archived-At: Subject: Re: [Danish] Proposed WG Charter X-BeenThere: danish@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DANE AutheNtication for Iot Service Hardening List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jun 2021 20:43:35 -0000 On Tue, Jun 15, 2021 at 10:26:31AM -0700, Ash Wilson wrote: > DNSSEC adoption has historically suffered from technical and perception challenges. ------------ ---------- The technical issues are solvable, and much progress has been made and continues. It is time to move beyond the historical misperceptions. > The current adoption of DNSSEC is disappointing. That number is currently > 2.47% for the .com TLD (citing this time: http://rick.eng.br/dnssecstat/) This is misleading. What's more interesting is the marginal rate of adoption of new domain registrations. Recent measurements show this to be around 20%! We can make this even more appealing by actually using DNSSEC in our standards. > Not all CS college programs include DNSSEC (or PKI, for that matter) at > sufficient depth. Graduates aren't prepared to champion DNSSEC > implementation in the face of DNSSEC's perception problems in the > enterprise. Or DNS at all, or networking, ... people learn on the job. > For DNSSEC, the right materials exist. DNSSEC is one of the best-documented > sets of standards on the Internet. How-to guides are abundant. Nobody can > say that DNSSEC isn't well-documented. I can definitely say that, because best-practices are not as well understood as they should be, and the tools have improved dramatically recently, so some relearning is required, and the tutorials have not yet caught up. There's work to be done, but none of if significantly insurmountable. -- Viktor. From nobody Tue Jun 15 14:33:40 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 6D6443A3EAB for ; Tue, 15 Jun 2021 14:33:38 -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 QuhqcfCFPxNx for ; Tue, 15 Jun 2021 14:33:33 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 969F13A3EA6 for ; Tue, 15 Jun 2021 14:33:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 2C3FB38B0A; Tue, 15 Jun 2021 17:34:43 -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 X8kD1zV-gMOC; Tue, 15 Jun 2021 17:34:42 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 9F7DC38AD9; Tue, 15 Jun 2021 17:34:42 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 67C47AC6; Tue, 15 Jun 2021 17:33:31 -0400 (EDT) From: Michael Richardson To: Ash Wilson cc: danish@ietf.org In-Reply-To: References: <02cb8931e16c4ccaa6eed1b89c0a20b6@cira.ca> <90e0d38f1a394b79987b5f1517cc157e@cira.ca> <32259.1623782305@localhost> <24225.1623787020@localhost> 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: Re: [Danish] [EXT] Re: IoT Device Identification with TLSA via Danish X-BeenThere: danish@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DANE AutheNtication for Iot Service Hardening List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jun 2021 21:33:39 -0000 --=-=-= Content-Type: text/plain Ash Wilson wrote: > FWIW, I'm a fan of immutable DNS names and rotating certs. If the device > can rotate its own certificate with the CA, then an automation component > between the CA and DNS server can manage the rotation for DANE via TLSA > records. > It only gets easier over time to guess private keys. Being able to rotate > them would be a big advantage over the lifetime recommendation in IEEE > 802.1AR for device certs. I agree. If we can safely rotate private keys that are otherwise buried deep in a device, then great, that improves things. But, we shouldn't design on the assumption that this is the only way. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | IoT architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAmDJHKsACgkQgItw+93Q 3WXduAgAmPs9rmFBNGZmg/KmaoW6X6sXEKQTYEEyrzY2w1L3ukLfBRkI8Z3IAAZ1 W5wbO8NkBKepj4SSfobl+hBFR7gUe5IykZE5ex3Q0ek58KHVM3hFamSjOCEy99KY ZwfLNFNhGcEx8lA0+HUedCgEFmVB0C28Yb+nPzIqGYq5z9txne38HwSaHYpdnA6k d8hKupjwx7iZUEy+YbQ4GyIxNqQ+p7zc/knqpIQM+YSpBvTiQY4h8PWY+42MUHc8 H/ltwHZ0Z15dbWq7AdgvAWcOsf5fR62w8rDuxEKAxCsstLDTsoidCcCrXkWQO0nW bL7yMzAUPw2FgBsdFdx05Pumis5Wbw== =sS2D -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Jun 16 04:11: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 DD2723A1197 for ; Wed, 16 Jun 2021 04:11:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=KjKsE7QE; dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=KjKsE7QE 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 2zMA-v8KQ-BE for ; Wed, 16 Jun 2021 04:11:48 -0700 (PDT) Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05on2048.outbound.protection.outlook.com [40.107.20.48]) (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 70A4A3A1186 for ; Wed, 16 Jun 2021 04:11:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=XXxIZbKA0kmYbM3heBsfznyYq7IDM9vAeKv8p+ibuxI=; b=KjKsE7QETyTFh1Kq61/6N1xFFpXrnRDYvpVxnThMqNXQrsg7vp8wMkTKkucQzisdLLcOhnUyJExU47TSFGgNHt0QqIq88wS+/aPgvwPnzlFjAg4XoFnTN7kcRDnWVm9G72T+0RBathliEmaItsFXGDSzC8yPDyBBUl5ku3RPa8E= Received: from AM6PR01CA0053.eurprd01.prod.exchangelabs.com (2603:10a6:20b:e0::30) by AM8PR08MB5665.eurprd08.prod.outlook.com (2603:10a6:20b:1da::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4219.22; Wed, 16 Jun 2021 11:11:45 +0000 Received: from AM5EUR03FT019.eop-EUR03.prod.protection.outlook.com (2603:10a6:20b:e0:cafe::fa) by AM6PR01CA0053.outlook.office365.com (2603:10a6:20b:e0::30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4242.15 via Frontend Transport; Wed, 16 Jun 2021 11:11:45 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; ietf.org; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com;ietf.org; dmarc=pass action=none header.from=arm.com; Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 63.35.35.123 as permitted sender) receiver=protection.outlook.com; client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com; Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by AM5EUR03FT019.mail.protection.outlook.com (10.152.16.104) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4242.16 via Frontend Transport; Wed, 16 Jun 2021 11:11:44 +0000 Received: ("Tessian outbound d8701fbbf774:v93"); Wed, 16 Jun 2021 11:11:44 +0000 X-CR-MTA-TID: 64aa7808 Received: from e13cc244b56d.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 78A7D480-F8DC-4AFF-BE15-B94458F1314A.1; Wed, 16 Jun 2021 11:11:38 +0000 Received: from EUR03-AM5-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id e13cc244b56d.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Wed, 16 Jun 2021 11:11:38 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=aM2tsyq8sHmW3ZTUOc3Tc/xdFsg80DVikoC7LUtC+iC5g41z7LrbLkQ3UcXVhTo6wnyjHLTVKxG3iKQSQZN3VhJyOJCN3et5ZyjNSGo6/Ocny3izQauh0fh7W21zpjTKWnOAZpKC2ZrnBHZ/QNLM18rwQhmo9HMEkbKJvvoUvKw3WwC+Pm2LuVLGIWImXz1q5vUv/HPqwDjTo0Y18ae1IgufkDfTQi5cgL/dgpRcziHhznV2vZu5C+uk8JHs79Qf+Zg876Ms4SnBAqHAcxRll6oAPn1fudSDGnxbeI4xYUERJgR44Sgl1TBhLYtVOii3uU7m3YycvKG5xuRYMCjolg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=XXxIZbKA0kmYbM3heBsfznyYq7IDM9vAeKv8p+ibuxI=; b=eX6mLL7cWl4GEsqAuL+bWsIXEnK1P7ELcyC2NYtZ0OfIIVUdBds6MF0YMBw6LKGGdFiUVrwAtGxt32mVT964+ajVe28GLB2Jo2lQNoDCqeiMv8Mz5EW4SgLkdRmNsskBqY+cbHHWAnf82jUEK7vtXCdSDWXqzls1Ttw6zR3LLHdei/8uhOeGdydsOhn2win3hfYCVkIQrh3yY4um0W2D3WRoYvHep9og3i2Mroaqqh0JhVd0aDUl3YJlgQbjySEKaNHKVfz8DPwYKII5ckNn+vu/cjp1D89f9sI/rqjrwYldlY0rKDKlh8LmcgQVz95bfLIr/E0lbEU8IsongqVnfw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=XXxIZbKA0kmYbM3heBsfznyYq7IDM9vAeKv8p+ibuxI=; b=KjKsE7QETyTFh1Kq61/6N1xFFpXrnRDYvpVxnThMqNXQrsg7vp8wMkTKkucQzisdLLcOhnUyJExU47TSFGgNHt0QqIq88wS+/aPgvwPnzlFjAg4XoFnTN7kcRDnWVm9G72T+0RBathliEmaItsFXGDSzC8yPDyBBUl5ku3RPa8E= Received: from DBBPR08MB5915.eurprd08.prod.outlook.com (2603:10a6:10:20d::17) by DBBPR08MB6282.eurprd08.prod.outlook.com (2603:10a6:10:20c::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4242.18; Wed, 16 Jun 2021 11:11:35 +0000 Received: from DBBPR08MB5915.eurprd08.prod.outlook.com ([fe80::69cf:4429:a804:7f41]) by DBBPR08MB5915.eurprd08.prod.outlook.com ([fe80::69cf:4429:a804:7f41%3]) with mapi id 15.20.4219.026; Wed, 16 Jun 2021 11:11:35 +0000 From: Hannes Tschofenig To: "danish@ietf.org" Thread-Topic: Charter Text and the Problem Statement Thread-Index: Addin8Z32g6ibl9RQiW6iIvXVU0Whw== Date: Wed, 16 Jun 2021 11:11:35 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ts-tracking-id: BF75DBE6BA6509488F15B46BD0861B7E.0 x-checkrecipientchecked: true Authentication-Results-Original: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=arm.com; x-originating-ip: [80.92.119.239] x-ms-publictraffictype: Email X-MS-Office365-Filtering-Correlation-Id: 0af97437-64a1-40a1-0d1e-08d930b786ed x-ms-traffictypediagnostic: DBBPR08MB6282:|AM8PR08MB5665: X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true nodisclaimer: true x-ms-oob-tlc-oobclassifiers: OLM:3826;OLM:8882; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: AUtKbdh8oOGQyqtMe2xirqe8S5ZHUHTmDWAVgkhKN5HklPaFM08Drzi/x3TNwyxRYUOrfuPTdBmbW3ILD+c1S6g6c+tDHcDuw8ZMh/j1PjP2cDKn8ei52OpTAF9THvdVpzvGt7kGnemLbzl69qHNCLFesLoNNAyN/GTOqQPQEcnYHhOt2JxhgiuRA+ggo/zPuKOisx48Fx14nRKQF0uQPGTRe72HFEmyPMMOI5OnqariDe5Xzt1ec6kKhlvesdLuqF0Wy3kJq01uPMmSSWWbts9wG966vsQ3XWL/XCTFs0bRj9GCIaG2WqR1gBevpA/BYM9etHLuF4gTzzL9IXSs9iMPnHKa5PzXSKviTgDjdDBVg5YwXwuIbXn9ZK7uIdCMTG5w14ayvpGEyaygrI5vImowWl/0s6ckR11KSTlKNja7nXPorAseOX+FEC0ndi1OFUjEFgPAsQqRzxi3rwBkY8IXzP7kNpUumdCp9DqRvuOeqNv4CwDsY/m1e+jMivPx1lEzSelewHJbciJoPMFrZs7sNrHmTT1h5ncIaD2z/EF0MtpUK/LF85qG+pxd8xLPM/NqtRhpVSGlZWcafyuK1nJsD4Q9uOOm3uJxxrtxJiA= X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DBBPR08MB5915.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(39850400004)(396003)(376002)(366004)(346002)(136003)(66476007)(66946007)(8676002)(33656002)(64756008)(83380400001)(76116006)(5660300002)(66446008)(66556008)(316002)(71200400001)(52536014)(122000001)(38100700002)(7696005)(9686003)(6506007)(186003)(26005)(55016002)(478600001)(8936002)(6916009)(86362001)(2906002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?nudNT3tgLiCo+mqM8KqM2n7hvRHAxX40joYcX3s4WDxEoYu0327WOwHDFJHy?= =?us-ascii?Q?mAp1R8ylBPHvGs0mM1ie6+PwntrBYJ7Y1y80FaBNKn8peGWWR9LP3yLCV35O?= =?us-ascii?Q?iDpSvsOeMd37veE719w7vYFgyTM0bEeZBn6pNRM8aaY5QVf6pSwpq2FfctjT?= =?us-ascii?Q?IgBt/rJ3Fj3XnFyqJJuO6RbHnXmu8iBvGJ5vhrV+3g9swL2ZgZ8C4pzs8v91?= =?us-ascii?Q?Md2CMmPiAZXGa7RUw+drHcxIwcHb/j0jfaNk5DfMnfmbn+WaH4gGetAKO6Wv?= =?us-ascii?Q?tG6H6XiDFmLtneKR9dn0o6JJgKTg8Tgff2YMMYh82paH2Ap71GQws3s46uQl?= =?us-ascii?Q?EF/SpGQsUNwaplUPVZzBKBsgQuAWXzmhSm4Gn/iW6h2NjjpUaIwWiLzhUlLM?= =?us-ascii?Q?9XG3mQW0LHVl6/cB+0poWNyTF7msduLbkamZajprPQqgx7D8S3MuZZPPzBMe?= =?us-ascii?Q?i1HAfg0K1KlnYvL4TLQzWMbw8dPtgA7GXdwofPOnAUnYUTSTu8A0SgQEHglr?= =?us-ascii?Q?GM01kSkeFvkduu6kGzxhp8o7qj72MELYGw9fxpmZ56MrFDzw/2QYO8nq92ea?= =?us-ascii?Q?sg0WLztsIWnIhhKez5s4TYQc1dx0odVKC5iBwe0lJc/2Kgme2F2mLFWHPIgn?= =?us-ascii?Q?ne9X0xXkd3kkvD9e62iytgKpolnDuhifhUTm4NylA5ODEMoh89lyi7v9bjSX?= =?us-ascii?Q?YtVPj8ub69O5lMhS9ojHuuHSM9vBnMCvuTddS2F4u67fc5/yTjpc9Knh4r4L?= =?us-ascii?Q?A4s9zuXF1/RsU5e//Jgnfy6jUCVO4N4KVWVOGgP2+YoAsvunesP7eP/arxeD?= =?us-ascii?Q?QW1XJoDLYaUfSgJmfpWm+k6wIajCGJX21cKonc0iy7hh8bdUyr96L5q6AF5F?= =?us-ascii?Q?uE2s6nL66oMTbKmgmFr05+wD1tUbqgNpeHFj8cBT1VkKeWSRERYefU6wgKlu?= =?us-ascii?Q?BpQfrTExC+bIAQx53h9R+esNwylO6WibcGwcxYi+1JqLlg4YpBx05lwArqxr?= =?us-ascii?Q?+sGTxAXwmcyYXH3pjb/CyJa+cfs33QJxGLdRAlTYvsEsyTnt5jFEK4iPGghR?= =?us-ascii?Q?djRFgE75DCK2DmUT6d/jpMrAoqQ/VoWaE+GA7iW2znqNLtjhR0N65zNkgO3u?= =?us-ascii?Q?aaX1GKqBZB7UCbQmtTGZib/6gLfETD+eD0zG+pC+wLafpLgfOCuQQTbV4x3U?= =?us-ascii?Q?/CQ5Vrv0QZ8Y3YGL3H6D3KL4QWVv3vlTUmlUU6cxhAeKV3nHcOhyBsfeapkO?= =?us-ascii?Q?Hb8zbYG9LHXqEuM9p+laO6LppOdwPkMiAPo3QRrSzXv2sQdHVtmT3Jjz4dq9?= =?us-ascii?Q?djC33KtEU0VRPwJPIlz4B68/?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_DBBPR08MB5915066E1CE5BDB2D695A8DAFA0F9DBBPR08MB5915eurp_" MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBBPR08MB6282 Original-Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: AM5EUR03FT019.eop-EUR03.prod.protection.outlook.com X-MS-Office365-Filtering-Correlation-Id-Prvs: 3cd132f2-022a-4447-af28-08d930b78142 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: u6JD6CLfjS/hhu43X9rdYoyFkjhzQaYeM7n87AFBZxLc+lwbJ9nMBcc4Q0/DY6PvMCBtWEF6Vbv1Umh1kfXxozPXxAcOfSJdH8SDrhVpDvPYR2BjFQguBikdFw3ZDPFQLY/vPh/V0XcsywFQxw23eJXjJN6UeqGI/JSR2YNVyYS2ymAh6WY55XEtr9DpueQb10izCE/w292Pd/XH9yEDKAqb0OUnAq4wziqTaiQwrePXf0r8HaPo34wrtBw4gHGpnNe7bo9EPayeiakvg+zxKGARSZr6j8bDwar3c4fdpiI+KIv8ayS/is0vNSeRmjIEP7MBrKcYiBqo+ZQiZI18iXd4/QB66vIjddzs3XfuDVilHcddR+elu+/IR+uIPpm/2mdoWeOGWkt2RnBUvCh0hPh7VSfDGYnRS+GltmEUG1MzF60M8Eab4+tKrftqPhsX8xADjpSaFUdye6FJPsmsnX6x4K3Y+8EjRgDvwufc5rn60/q6wGComF+sJm1XywXCp1nDUadrrZmiYOopj2LQgEbdSwt9+r9JMTR/XqPhuhLAPpFEnc5hPmSRcPHOXztUua+i3UhZjqFqCBdh6koYgmj2ZouMAaedyF6TgljgyDcA1WVHYkoyFnvUns+FJoVQE20YH3uGv/Z0PwYCY9p2uNLDVRlAV7hMaE1WaCaUnPs= X-Forefront-Antispam-Report: CIP:63.35.35.123; CTRY:IE; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:64aa7808-outbound-1.mta.getcheckrecipient.com; PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; CAT:NONE; SFS:(4636009)(376002)(39860400002)(396003)(346002)(136003)(46966006)(36840700001)(70586007)(2906002)(478600001)(186003)(316002)(26005)(8676002)(47076005)(336012)(70206006)(55016002)(82740400003)(33656002)(6506007)(6916009)(8936002)(356005)(86362001)(81166007)(7696005)(52536014)(36860700001)(82310400003)(5660300002)(83380400001)(9686003); DIR:OUT; SFP:1101; X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Jun 2021 11:11:44.9766 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 0af97437-64a1-40a1-0d1e-08d930b786ed X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d; Ip=[63.35.35.123]; Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com] X-MS-Exchange-CrossTenant-AuthSource: AM5EUR03FT019.eop-EUR03.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM8PR08MB5665 Archived-At: Subject: [Danish] Charter Text and the Problem Statement X-BeenThere: danish@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DANE AutheNtication for Iot Service Hardening List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jun 2021 11:11:54 -0000 --_000_DBBPR08MB5915066E1CE5BDB2D695A8DAFA0F9DBBPR08MB5915eurp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, I have been reading through the charter text in an attempt to understand th= e problem statement. Two problems are mentioned: 1) Challenges with naming collisions in the IoT space. 2) Credential issuance is time consuming. Ad 1: Reading through the text it feels like naming collisions are a big th= ing in IoT. I have not heard about those problems. Could you elaborate? You add that "In response to the challenges related to ambiguity between identities issued by different CAs, application owners frequently choose to onboard IoT devices to a single CA.". Is that a good o= r a bad development? Ad 2: Is it really true that credential issuance is time consuming? Why is = that? For whom is it time consuming? Ciao Hannes PS: You use the term "Certificate Authority (CA)". It is actually called "C= ertification Authority". IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you. --_000_DBBPR08MB5915066E1CE5BDB2D695A8DAFA0F9DBBPR08MB5915eurp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

I have been reading through the charter text in an attempt= to understand the problem statement.

 

Two problems are mentioned:

 

1)  Challenges with naming collisions in the IoT space= .

 

2)  Credential issuance is time consuming.<= /span>

 

Ad 1: Reading through the text it feels like naming collisions are a b=
ig thing in IoT. I have not heard about those problems. Could you elaborate=
? 
You add that “In response to the challenges related to
ambiguity between identities issued by different CAs, application owne=
rs
frequently choose to onboard IoT devices to a single CA.”. Is th=
at a good or a bad development?

 

Ad 2: Is it really true that credential issuance is time c= onsuming? Why is that? For whom is it time consuming?

 

Ciao

Hannes

 

PS: You use the term “Certificate Authority (CA)R= 21;. It is actually called “Certification Authority”.

 

 

IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in any medium. Thank you. --_000_DBBPR08MB5915066E1CE5BDB2D695A8DAFA0F9DBBPR08MB5915eurp_-- From nobody Wed Jun 16 06:32: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 39FCB3A18A0 for ; Wed, 16 Jun 2021 06:32:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 T5CMsUbOJ2jJ for ; Wed, 16 Jun 2021 06:32:40 -0700 (PDT) Received: from nestor.zerospam.ca (nestor.zerospam.ca [209.172.38.88]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4ECFD3A18A4 for ; Wed, 16 Jun 2021 06:32:40 -0700 (PDT) X-ZEROSPAM_FILTERED: true Received: from nestor.zerospam.ca (localhost [127.0.0.1]) by nestor.zerospam.ca (Postfix) with ESMTP id 4G4mMV5kk8z8sXk for ; Wed, 16 Jun 2021 09:32:38 -0400 (EDT) Authentication-Results: nestor.zerospam.ca (ip=192.228.22.11); spf=none smtp.helo=mx1.cira.ca; spf=pass smtp.mailfrom=Jacques.Latour@cira.ca; dkim=none; dmarc=none (action=none) reason="No DMARC policy found" header.from=cira.ca Received: from 127.0.0.1 (127.0.0.1:12000) (original ip: 192.228.22.11) by nestor.zerospam.ca (Themis) with ESMTP id zPcM5SbRF4zXveQ7Ti8; Wed, 16 Jun 2021 09:32:37 -0400 Received: from mx1.cira.ca (nat.crp.cira.ca [192.228.22.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by nestor.zerospam.ca (Postfix) with ESMTPS id 4G4mMT4GrQz8sX7 for ; Wed, 16 Jun 2021 09:32:37 -0400 (EDT) Received: from CRP-EX16-02.CORP.CIRA.CA (10.2.36.121) by CRP-EX16-02.CORP.CIRA.CA (10.2.36.121) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.2242.10; Wed, 16 Jun 2021 09:32:36 -0400 Received: from CRP-EX16-02.CORP.CIRA.CA ([fe80::c50f:56f4:1f3c:b748]) by CRP-EX16-02.CORP.CIRA.CA ([fe80::c50f:56f4:1f3c:b748%14]) with mapi id 15.01.2242.010; Wed, 16 Jun 2021 09:32:36 -0400 From: Jacques Latour To: "danish@ietf.org" Thread-Topic: [Danish] [EXT] Re: IoT Device Identification with TLSA via Danish Thread-Index: AQHXYe5aH02gAzTO9UCMWeYXrUdSAqsWoBHQ Date: Wed, 16 Jun 2021 13:32:36 +0000 Message-ID: <124285d6c067429daea7a44afe6fa65a@cira.ca> References: <02cb8931e16c4ccaa6eed1b89c0a20b6@cira.ca> <90e0d38f1a394b79987b5f1517cc157e@cira.ca> In-Reply-To: Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_ee0e450f-d653-41c9-9b6c-2295bb19e3b2_Enabled=true; MSIP_Label_ee0e450f-d653-41c9-9b6c-2295bb19e3b2_SetDate=2021-06-16T13:32:35Z; MSIP_Label_ee0e450f-d653-41c9-9b6c-2295bb19e3b2_Method=Standard; MSIP_Label_ee0e450f-d653-41c9-9b6c-2295bb19e3b2_Name=Confidential; MSIP_Label_ee0e450f-d653-41c9-9b6c-2295bb19e3b2_SiteId=f349b30c-7550-4f17-88da-269417631f54; MSIP_Label_ee0e450f-d653-41c9-9b6c-2295bb19e3b2_ActionId=2ff3c675-648e-4a92-a9a5-7599973b5d29; MSIP_Label_ee0e450f-d653-41c9-9b6c-2295bb19e3b2_ContentBits=2 x-originating-ip: [10.2.36.1] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Danish] [EXT] Re: IoT Device Identification with TLSA via Danish X-BeenThere: danish@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DANE AutheNtication for Iot Service Hardening List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jun 2021 13:32:43 -0000 Viktor, > Adding revocation records breaks the semantics. =20 I'm with you here. >And, as I pointed out, the revocation record is redundant. Just publish "= 3 1 0" or > "3 1 1" and you've renounced *all* other keys, by specifying only the val= id key(s). Two scenarios, first, if the IoT device has a new identity then we publish = a new TLSA - done, old key are to be untrusted. This works. All good. Second scenario for IoT device that can have their identity reprovisioned, = if an IoT device is compromised/not to be trusted/not to be used for whatev= er reasons, a NSEC record does not represent that status, but could we put = a 0 (?) value 4th TLSA Certificate Association Data field, the presence of= the TLSA would show it exists, the null cert value would show don't use, b= ut it exists, so the logic on the server could be different to figure out w= hat do to with that IoT device, instead of a nonexistence record. Jack CLASSIFICATION:CONFIDENTIAL From nobody Wed Jun 16 07:22:19 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 67BD63A1A67 for ; Wed, 16 Jun 2021 07:22:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 0qtngKDIvCh3 for ; Wed, 16 Jun 2021 07:22:12 -0700 (PDT) Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (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 C0DE73A1A64 for ; Wed, 16 Jun 2021 07:22:12 -0700 (PDT) Received: from smtpclient.apple (unknown [192.168.1.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by straasha.imrryr.org (Postfix) with ESMTPSA id B33D1C6AC8 for ; Wed, 16 Jun 2021 10:22:09 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) From: Viktor Dukhovni In-Reply-To: <124285d6c067429daea7a44afe6fa65a@cira.ca> Date: Wed, 16 Jun 2021 10:22:09 -0400 Content-Transfer-Encoding: quoted-printable Reply-To: danish@ietf.org Message-Id: <78243327-FB93-4187-AEDD-D08682F17038@dukhovni.org> References: <02cb8931e16c4ccaa6eed1b89c0a20b6@cira.ca> <90e0d38f1a394b79987b5f1517cc157e@cira.ca> <124285d6c067429daea7a44afe6fa65a@cira.ca> To: danish@ietf.org X-Mailer: Apple Mail (2.3654.100.0.2.22) Archived-At: Subject: Re: [Danish] [EXT] Re: IoT Device Identification with TLSA via Danish X-BeenThere: danish@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DANE AutheNtication for Iot Service Hardening List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jun 2021 14:22:18 -0000 > On 16 Jun 2021, at 9:32 am, Jacques Latour = wrote: >=20 > An NSEC record does not represent that status, If DANE is a required (not opportunistic) mechanism for the use-case, then NSEC does in fact indicate that the DNS name is no longer valid for authentication, but otherwise ... > but could we put a 0 (?) value 4th TLSA Certificate Association Data = field, A SHA-256 hash that is all zero (all 32 byhtes or 64 hex nibbles) can be used as an effective way to disclaim all keys. _foo.name.example IN TLSA 3 1 1 = 0000000000000000000000000000000000000000000000000000000000000000 > so the logic on the server could be different to figure out what do to = with that IoT device, instead of a nonexistence record. The device would only authenticate if its public key has a SHA2-256 hash that is all zero. It is not publicly known how to find such a 2nd pre-image for SHA2-256, and believed to be out of reach of even nation state security agencies. --=20 Viktor. From nobody Wed Jun 16 14:28:10 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 CD0E23A2703 for ; Wed, 16 Jun 2021 14:28:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, 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 RYR33yao9Yr9 for ; Wed, 16 Jun 2021 14:28:01 -0700 (PDT) Received: from mail-qt1-x82e.google.com (mail-qt1-x82e.google.com [IPv6:2607:f8b0:4864:20::82e]) (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 4BE093A1CA4 for ; Wed, 16 Jun 2021 14:28:01 -0700 (PDT) Received: by mail-qt1-x82e.google.com with SMTP id z4so3096005qts.4 for ; Wed, 16 Jun 2021 14:28:01 -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=nEAghKixQ040zj+NEelYzBSd0tkgLmn8iWyw7WbPCPU=; b=fqUXLYqBF6JyBELKrzEd7bWI7lSxqd/H6WSyybRHxfFK1HWXN3HcjDkAkRJGEfDFGC BuC1SPJWkMmEDb+gThwi1V5p6AuEncnmzwJh6lglUXQ1N/juzZpKvgAns3lK+wwjUi6P xjXEj/68u4wvVOp1SPWnYNZZxJsKR32c7f/TQ04QVYqJtdmqNah8H3U9v5U/V9bjpmaf se8WBYVJDcgPqpoZQ0bD8tpNESs7e2UNJPkGTvXLqlrXFgsRTpKCJ5QV97Fmug2sXvjY IKjs5Zi0iTMC+9rT24wPQlM/gbFGjHEW5N+9iyKvVysdnPwoxDqhJ0Xc7s4zZfCFr5S1 v5ew== 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=nEAghKixQ040zj+NEelYzBSd0tkgLmn8iWyw7WbPCPU=; b=m+63ijWiOT5gvpXHMfTR76phEZTb6e21Z6bw+yd7IKNpEt/oAA7SLWg+JKSmfPLyM/ kghzFr6PaEpmAD1zGITjwHi/tYFNb3BgQRvy3yMhZplthWbmYyy2orW2cIstZxIhiRDH Y9/rxDzmXo+fV4NV19qAOPBU0kUgCTyYgMYETtwY7LxACvi5X2SBvisQO7xkGc3E0VEX BN4o/1mgidLVBOEBXv+Vc6lNcukqtt9zzOPS7bQ+WnahQxt2wf0Euk7Xm3wR0CK9Ql5r VCwnxHmfdU9Of4DnF5zjoW2Tx6TQB7uWN0zHFKMTvRZ4YR/dDwJyQYffHcRlFnpZ8HkH JWyQ== X-Gm-Message-State: AOAM531VZrYupt2SkwPXT23x4Zh6M9atW1cC2Pqe1B9JVplAp2tri1iw dr1yL7y+YsX5dmdsuPUUEJ9bRVA1EI+mvid4wv8nvg== X-Google-Smtp-Source: ABdhPJyLJQFYLwKEPOK7y5qDitNj33mY5UNI68sxTUlmoQckqL2Ekv7Xd4ZIJxS5ryssxtvl/D8T1P9c5SIBz0QpfrM= X-Received: by 2002:aed:30cd:: with SMTP id 71mr1825232qtf.31.1623878878955; Wed, 16 Jun 2021 14:27:58 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ash Wilson Date: Wed, 16 Jun 2021 14:27:48 -0700 Message-ID: To: Hannes Tschofenig Cc: "danish@ietf.org" Content-Type: multipart/alternative; boundary="000000000000bd235f05c4e8c375" Archived-At: Subject: Re: [Danish] Charter Text and the Problem Statement X-BeenThere: danish@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DANE AutheNtication for Iot Service Hardening List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jun 2021 21:28:08 -0000 --000000000000bd235f05c4e8c375 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Hannes, Thanks for the questions, and apologies for keeping you waiting on answers/clarification. On Wed, Jun 16, 2021 at 4:12 AM Hannes Tschofenig wrote: > Hi all, > > > > I have been reading through the charter text in an attempt to understand > the problem statement. > > > > Two problems are mentioned: > > > > 1) Challenges with naming collisions in the IoT space. > > > > 2) Credential issuance is time consuming. > > > > Ad 1: Reading through the text it feels like naming collisions are a big = thing in IoT. I have not heard about those problems. Could you elaborate? > > Certainly. I'll use a hospital as an example environment. Within a hospital, it is desirable to implement 802.1x authentication using EAP-TLS for access to protected networks. EAP-TLS enables the use of PKI-based identity to authenticate an entity for network access. When implementing EAP-TLS for network access, RADIUS is a common protocol/server used for authentication behind the switch or wireless access point. Guidance for configuring RADIUS recommends the use of only one CA certificate for authenticating supplicant certificates. This guidance can be found in the wild in Freeradius configuration files for EAP-TLS, related to the 'ca_file' configuration directive. CAs guarantee the uniqueness of an entity's name within the scope of the CA, but have no method for enforcing name uniqueness across other CAs. For instance, CA1 and CA2 may both sign certificates for entities with the same name. If CA1 and CA2 are both trusted by the RADIUS server, and two entities named "medicaldevice123" exist, one per CA, then the resulting ambiguity makes it difficult to appropriately apply access controls. This ambiguity is mitigated by operating a single organizational PKI, and requiring identities issued by that single organizational PKI for EAP-TLS authentication. Onboarding devices to organizational PKI requires time and effort. Oftentimes some sort of skilled labor and/or dedicated infrastructure for automating the onboarding process is involved. DANE allows us to bind a DNS name to a public key, and mitigates the ambiguities introduced by the use of multiple CAs. An organization can only issue working identities within its own namespace in DNS. Since naming ambiguity can be mitigated using DANE, we may now choose to use manufacturer-issued PKI, represented in DNS, for authenticating entities. >From the hospital's standpoint, the IT staff no longer needs to manage the process of onboarding devices to organizational PKI. The device arrives on-site with an identity which can be immediately used for network authentication. > You add that =E2=80=9CIn response to the challenges related to > > ambiguity between identities issued by different CAs, application owners > > frequently choose to onboard IoT devices to a single CA.=E2=80=9D. Is tha= t a good or a bad development? > > It is a good development if the organization really wants to directly manage all of the credentials for all of the application participants. The effort and rationale behind BRSKI (RFC 8995) suggests a desire to make onboarding to organizational PKI easier to automate. If a supplier issues a trustworthy identity for a device, and DNS prevents another PKI from issuing working credentials under the same name, then issuing another identity via organizational PKI becomes superfluous. This is where we think that time and effort can be saved, because the skills required for onboarding do not need to include the management and issuance of identities under organizational PKI. > > > Ad 2: Is it really true that credential issuance is time consuming? Why i= s > that? For whom is it time consuming? > Credential issuance very often requires the device and the person bootstrapping the identity to be in the same place. Some platforms and protocols exist to make that process easier (like BRSKI) or less human-involving. The time investment seems to be on the part of both the manufacturer (in issuing the IDevID) as well as the organizational IT staff, who manage the organizational PKI. > > > Ciao > > Hannes > > > > PS: You use the term =E2=80=9CCertificate Authority (CA)=E2=80=9D. It is = actually called > =E2=80=9CCertification Authority=E2=80=9D. > > > > > IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose the > contents to any other person, use it for any purpose, or store or copy th= e > information in any medium. Thank you. > -- > 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. --000000000000bd235f05c4e8c375 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Hannes,
Thanks for the questions, = and apologies for keeping you waiting on answers/clarification.
=
On Wed= , Jun 16, 2021 at 4:12 AM Hannes Tschofenig <Hannes.Tschofenig@arm.com> wrote= :

Hi all,

=C2=A0

I have been reading through the charter text in an attempt t= o understand the problem statement.

=C2=A0

Two problems are mentioned:

=C2=A0

=C2=A0 Challenges with naming collisions in the IoT space.<= /u>

=C2=A0

=C2=A0 Credential issuance is time consuming.

=C2=A0

Ad 1: Reading through the text it feels like naming collisions are a b=
ig thing in IoT. I have not heard about those problems. Could you elaborate=
?
Certainly. I'll use a hospital as= an example environment.

Within a hospital, it is = desirable to implement 802.1x authentication using EAP-TLS for access to pr= otected networks. EAP-TLS enables the use of PKI-based identity to=C2=A0aut= henticate an entity for network access.

When imple= menting EAP-TLS for network access, RADIUS is a common protocol/server used= for authentication behind the switch or wireless access point. Guidance fo= r configuring RADIUS recommends the use of only one CA certificate for auth= enticating supplicant=C2=A0certificates. This guidance can be found in the = wild in Freeradius configuration files for EAP-TLS, related to the 'ca_= file' configuration directive.=C2=A0

CAs guara= ntee the uniqueness of an entity's name within the scope of the CA, but= have no method for enforcing name uniqueness across other=C2=A0CAs. For in= stance, CA1 and CA2 may both sign certificates=C2=A0for entities with the s= ame name. If CA1 and CA2 are both trusted by the RADIUS server, and two ent= ities named "medicaldevice123" exist, one per CA, then the result= ing ambiguity makes it difficult to appropriately apply access controls. Th= is ambiguity is=C2=A0mitigated by operating a single organizational PKI, an= d requiring identities issued by that single organizational PKI for EAP-TLS= authentication.=C2=A0

Onboarding devices to organ= izational PKI requires time and effort. Oftentimes some sort of skilled lab= or and/or dedicated infrastructure for automating the onboarding process is= involved. DANE allows us to bind a DNS name to a public key, and mitigates= the ambiguities introduced by the use of multiple CAs. An organization can= only issue working identities within its own namespace in DNS. Since namin= g ambiguity can be mitigated using DANE, we may now choose to use manufactu= rer-issued PKI, represented in DNS, for authenticating entities.
=
From the hospital's standpoint, the IT staff no longer n= eeds to manage the process of onboarding devices to organizational PKI. The= device arrives on-site with an identity which can be immediately used for = network=C2=A0authentication.
You add that =E2=80=9CIn response to the challenges related to<=
u>
ambiguity between identities issued by different CAs, application owne=
rs
frequently choose to onboard IoT devices to a single CA.=E2=80=9D. Is =
that a good or a bad development?=C2=A0
= It is a good development if the organization really wants to directly manag= e all of the credentials for all of the application participants. The effor= t and rationale behind BRSKI (RFC 8995) suggests a desire to make onboardin= g to organizational PKI easier to automate.=C2=A0

= If a supplier issues a trustworthy identity for a device, and DNS prevents = another PKI from issuing working credentials under the same name, then issu= ing another identity via organizational PKI becomes superfluous. This is wh= ere we think that time and effort can be saved, because the skills required= for onboarding do not need to include the management and issuance of ident= ities under organizational PKI.

=C2=A0

Ad 2: Is it really true that credential issuance is time con= suming? Why is that? For whom is it time consuming?

<= /blockquote>
Credential issuance very often requires the device and the= person bootstrapping the identity to be in the same place. Some platforms = and protocols exist to make that process easier (like BRSKI) or less human-= involving. The time investment seems to be on the part of both the manufact= urer (in issuing the IDevID) as well as the organizational IT staff, who ma= nage the organizational PKI.=C2=A0

=C2=A0

Ciao

Hannes

=C2=A0

PS: You use the term =E2=80=9CCertificate Authority (CA)=E2= =80=9D. It is actually called =E2=80=9CCertification Authority=E2=80=9D.=

=C2=A0

=C2=A0

IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in any medium. Thank you.
--
Danish mailing list
Danish@ietf.org https://www.ietf.org/mailman/listinfo/danish


--
=
--000000000000bd235f05c4e8c375-- From nobody Wed Jun 16 15:00:57 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 1974C3A284D for ; Wed, 16 Jun 2021 15:00:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-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 nBNCWlUUXHgZ for ; Wed, 16 Jun 2021 15:00:53 -0700 (PDT) Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (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 EC21C3A2849 for ; Wed, 16 Jun 2021 15:00:52 -0700 (PDT) Received: by straasha.imrryr.org (Postfix, from userid 1001) id 57B3BC70B9; Wed, 16 Jun 2021 18:00:50 -0400 (EDT) Date: Wed, 16 Jun 2021 18:00:50 -0400 From: Viktor Dukhovni To: danish@ietf.org Message-ID: Reply-To: danish@ietf.org References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Archived-At: Subject: Re: [Danish] Charter Text and the Problem Statement X-BeenThere: danish@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DANE AutheNtication for Iot Service Hardening List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jun 2021 22:00:55 -0000 On Wed, Jun 16, 2021 at 02:27:48PM -0700, Ash Wilson wrote: > CAs guarantee the uniqueness of an entity's name within the scope of the > CA, but have no method for enforcing name uniqueness across other CAs. Uniqueness is not the property you're looking for. It doesn't matter how many keys a CA binds the same name to, so long as all those keys are legitimately associated with the same entity. Overlap is perfectly normal, e.g. across renewals CAs don't typically revoke the (soon(ish) to expire) previous certificate. Nor does it matter if more CAs assign the same name to some subset of the same keys, provided they're expected/authorised to do so. All that matters is whether the verifier is willing to trust a given CA to for names in a given namespace, and it is here that it is quite reasonable to not place trust in every CA on the planet when provisioning cameras, electronic locks, uranium isotope centrifuges, ... This is not about "uniqueness", rather it is about assurance, sometimes you need to run your own CA, because the CA/B forum CAs don't provide the required assurance levels and sometimes are presumed actively hostile. > For instance, CA1 and CA2 may both sign certificates for entities with > the same name. If CA1 and CA2 are both trusted by the RADIUS server, > and two entities named "medicaldevice123" exist, one per CA, then the > resulting ambiguity makes it difficult to appropriately apply access > controls. No, the problem only happens when the two are not the same, but CAs issuing certificates from publically trusted keys should only sign assertions about globally valid names, so there are no "collisions", there is only authorised or unauthorised issuance. > This ambiguity is mitigated by operating a single organizational PKI, > and requiring identities issued by that single organizational PKI for > EAP-TLS authentication. There is no ambiguity or uniqueness problem. There is only a trust / authorisation problem. > Oftentimes some sort of skilled labor and/or dedicated infrastructure for > automating the onboarding process is involved. DANE allows us to bind a DNS > name to a public key, and mitigates the ambiguities introduced by the use > of multiple CAs. No, rather DANE gives a natural global namespace, with natural name constraints, so that only the signing keys of the authoritative zone (and potentially its parent zones if compelled to transfer domain control, or hypotheticall, but much less likely forge non-delegated responses) can be used to sign TLSA RRsets for a given name. So with DANE there is a natural single naming authority, that is absent with WebPKI. > An organization can only issue working identities within its own > namespace in DNS. Since naming ambiguity can be mitigated using DANE, > we may now choose to use manufacturer-issued PKI, represented in DNS, > for authenticating entities. We're converging to the same observations, but your terminology is sadly misleading and regrettable. Please remove all referce to uniqueness and ambiguity, and instead clarify the actual desire for a single naming authority trusted by the verifier. It can be the device manufacturer (if not trusted, why use the device), but in some environments, the user may elect to reconfigure the device with their own keys and DNS name and avoid reliance on outside parties. > From the hospital's standpoint, the IT staff no longer needs to manage > the process of onboarding devices to organizational PKI. The device > arrives on-site with an identity which can be immediately used for > network authentication. Perhaps so, though some equipment is sufficiently critical that it will need to remain working even if the outside vendor is no longer reachable or even in business. In which case one would want to use one's own internal DNS servers proximate to the devices in question. > If a supplier issues a trustworthy identity for a device, and DNS prevents > another PKI from issuing working credentials under the same name, DNSSEC provides natural name constraints. It is then up to the user whether to trust the device vendor for authenticity and availability during or beyond the initial device onboarding. > then issuing another identity via organizational PKI becomes > superfluous. This is where we think that time and effort can be saved, > because the skills required for onboarding do not need to include the > management and issuance of identities under organizational PKI. You might also simplify onboarding, but the device is then promptly reconfigured with an internal name and keys. It suffices to wipe the TLSA RRs from DNS when the device is deprovisioned, the keys are then no longer sensitive (after the TLSA RRSIGs expire), but wiping those too is generally prudent. -- Viktor. From nobody Wed Jun 16 23:43:44 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 A783B3A0DFC for ; Wed, 16 Jun 2021 23:43:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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=armh.onmicrosoft.com header.b=yx8xuWn0; dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=yx8xuWn0 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 lnSR374pEksI for ; Wed, 16 Jun 2021 23:43:36 -0700 (PDT) Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05on2071.outbound.protection.outlook.com [40.107.20.71]) (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 5CDCC3A0DFB for ; Wed, 16 Jun 2021 23:43:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=GS+mlz+cO3cj/3fjK/icjmkwTg/eDKOvPRhoL4Go6r4=; b=yx8xuWn0J6kcpIbI5P75EMPrVgVSqlR9Aekq5kXWa7A5opJyefpSdtxp+ac/GbfS5rKtMYYlYHSHlDJsNEfW7RJJSv+IRhpcwlSXJVtJOabfChz59C1+kvwy1jFe7T9OnTh9AzBvyDH6WoGq8QEaUOX4ygagtQ6csB51GX6foHo= Received: from DU2PR04CA0354.eurprd04.prod.outlook.com (2603:10a6:10:2b4::7) by AS8PR08MB6629.eurprd08.prod.outlook.com (2603:10a6:20b:319::5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4242.18; Thu, 17 Jun 2021 06:43:31 +0000 Received: from DB5EUR03FT015.eop-EUR03.prod.protection.outlook.com (2603:10a6:10:2b4:cafe::97) by DU2PR04CA0354.outlook.office365.com (2603:10a6:10:2b4::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4242.19 via Frontend Transport; Thu, 17 Jun 2021 06:43:32 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; ietf.org; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com;ietf.org; dmarc=pass action=none header.from=arm.com; Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 63.35.35.123 as permitted sender) receiver=protection.outlook.com; client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com; Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by DB5EUR03FT015.mail.protection.outlook.com (10.152.20.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4242.16 via Frontend Transport; Thu, 17 Jun 2021 06:43:30 +0000 Received: ("Tessian outbound d5fe3fdc5a40:v93"); Thu, 17 Jun 2021 06:43:30 +0000 X-CR-MTA-TID: 64aa7808 Received: from b12d3c4efbe2.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 05EF7E5F-6934-4A13-8EFC-564581F505FB.1; Thu, 17 Jun 2021 06:43:24 +0000 Received: from EUR04-VI1-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id b12d3c4efbe2.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Thu, 17 Jun 2021 06:43:24 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=byzzogEdo21qzgB+NffjD2wPJgSDSSzNLkw3qzxHPbqlw3HheBMcdrDfy0DsPaxYTSta+tDfIFU+O7FgSlFULzwWw7HA1r70Ord6nRtj8K/vV1mAs5ShrW99umM10txdzuDIHVO26HWaXy9Dvj0FWUKmima++/F11lU9WkB8DTUWLjYtT71vrnX/rOIFjUrNDtBFcGiZgI5LXUfmzqKfbfOspG8U/aMXxWCyI7CtT5T5hl5gUavLyFpTAgZkr0KznFviZrMCcF6tJS6nTk0CKpz5suLb6TS9gjJrIEcqDsUADMYmQ7nTTBjOq1XuS2+iUyKV8SR0lB4+YCI9OgGWXg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=GS+mlz+cO3cj/3fjK/icjmkwTg/eDKOvPRhoL4Go6r4=; b=JIr2IKU5GUjnJ8TbifzoRzmUCcXR16DPFfEpuf8urbHJfAAxZ2nCkBytcyS2V/rT2oUMrGGe0jb8+TsZdUq3owiTDGLLj4jAFvbYfcv9bpZVQsorqWXqBQJozigIEPYfz+7v9fcIG71GcWelv6T1YCn9Aq39al1hZzhH7gLeGUC+OfOYqZmuYOyhWe6LApBGfEwAJObToVUOMRPYmdKSGHLMWaCc1kmIidqNLmj4j2uBsTdn3Y+QbHmXIl3ZWy8il9h4FyUaykn3/Kag+flhhiaAmJZDzV+gWOJgv0Cw0sRqcfH+3FQHHNLuTk9GTQQ2Kyt6sWh3ZXslSLojrpe2gg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=GS+mlz+cO3cj/3fjK/icjmkwTg/eDKOvPRhoL4Go6r4=; b=yx8xuWn0J6kcpIbI5P75EMPrVgVSqlR9Aekq5kXWa7A5opJyefpSdtxp+ac/GbfS5rKtMYYlYHSHlDJsNEfW7RJJSv+IRhpcwlSXJVtJOabfChz59C1+kvwy1jFe7T9OnTh9AzBvyDH6WoGq8QEaUOX4ygagtQ6csB51GX6foHo= Received: from DBBPR08MB5915.eurprd08.prod.outlook.com (2603:10a6:10:20d::17) by DB6PR0801MB1735.eurprd08.prod.outlook.com (2603:10a6:4:3a::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4219.23; Thu, 17 Jun 2021 06:43:21 +0000 Received: from DBBPR08MB5915.eurprd08.prod.outlook.com ([fe80::69cf:4429:a804:7f41]) by DBBPR08MB5915.eurprd08.prod.outlook.com ([fe80::69cf:4429:a804:7f41%3]) with mapi id 15.20.4242.019; Thu, 17 Jun 2021 06:43:21 +0000 From: Hannes Tschofenig To: Ash Wilson CC: "danish@ietf.org" Thread-Topic: [Danish] Charter Text and the Problem Statement Thread-Index: Addin8Z32g6ibl9RQiW6iIvXVU0WhwAVq2gAABL3x4A= Date: Thu, 17 Jun 2021 06:43:21 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ts-tracking-id: 06B08EAA017DD84BB7E682E8CD23E7B6.0 x-checkrecipientchecked: true Authentication-Results-Original: valimail.com; dkim=none (message not signed) header.d=none; valimail.com; dmarc=none action=none header.from=arm.com; x-originating-ip: [80.92.119.239] x-ms-publictraffictype: Email X-MS-Office365-Filtering-Correlation-Id: bca79ebe-bccc-4f18-735c-08d9315b37fe x-ms-traffictypediagnostic: DB6PR0801MB1735:|AS8PR08MB6629: X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true nodisclaimer: true x-ms-oob-tlc-oobclassifiers: OLM:9508;OLM:9508; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: KqpuAEJrcvj7O7yQVARaYLSN2pYooEmD9BOLBUb0qL5rSBuMBOHnf2qgUuxPXDY4vhIFSlOWtvTw73mt5cc7ZASTfvyyS7li60wQ7n47pOS++ZCFfbiIVYvNn4MpfOiVRr8P4b2btbtyAS47uVE5NvCjuRfDhROYoLGdlu/D2E51XRhx0LzY21XYgyg0OiUORpnbxN6ieh6APxMa0RiGVJDWLUXzpRf5WC1EACHD9pVUEypjqzseXfz0/2Bod6dD7CZeTnJAA5QuTzqmg3JrVFVSMjmho00Q52iWNvsBoi/Vh7DWLbCSfD9YElEkAuVN7TTyX/h/yZjqdImgGJdZaYjkRZlHWjfzX3E0mUqpdM3tbKKiHM30MZcu7xLxJzO+QLkTK6yzir5OHcyLxAdaitmzyhmSWaGrKEEhKp7EnhrTVdNk9niSleQoSaJg0zJQpOqbDhJykct3UAmxKvx0mf7KSLbzvB6WzOOcrshW+X96XpMgtPYl2X4VpEM/xQTkXFplhuaJStiS+K57qGryUhcj3C507bSb8BqnVvhax0lbHl8sNCLs6LxLZLbfkBiTQpsESaJnUePDTFovrwEb05LAnCjWZ0NQJDjiIsNLtXM6hOIiV3LXWK77dYVTfbYqV3kxHsKvyA2IrHPQ9vg8MhDtHLtF0ivu3RfXpZtseUq0b1ek8xKlJXDoKY+sP+3bMQO026rmWwfzUHUIW3oeLC/FDEjbOP9eztF93vY5fgA= X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DBBPR08MB5915.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(376002)(346002)(396003)(366004)(39850400004)(136003)(2906002)(966005)(478600001)(33656002)(83380400001)(166002)(4326008)(8936002)(316002)(6916009)(8676002)(9686003)(55016002)(71200400001)(38100700002)(64756008)(66556008)(122000001)(66446008)(66476007)(76116006)(66946007)(5660300002)(53546011)(6506007)(52536014)(7696005)(186003)(86362001)(26005); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?YTZMREJYRCtDUHhOZVZzV2tsMDAxZTMvNWJ2c2VLTmN6VzVPWDdnRmdNSEE4?= =?utf-8?B?K2lTbXFLK2s0ZnNXVzdoQTg4ZHJ5VnRGdHU1MWVkd25kWTU2MFB4b1dmeWE0?= =?utf-8?B?bk5tRElKdjQrM0hCUmVLZkc2aUhBNytWWWVjejkzRHJTTkpZNG9HMytWcnhE?= =?utf-8?B?RGxaellzVmlOM052dlJZbUcwdGMyb202S3hzbkVZZkVKbjBwQ0lydVE0OXk5?= =?utf-8?B?SEpLaEZOWGdNckdYUXVEMmYxd1paZ09rSjJIbHEvbGJhWHJ2VHZsS1l0WDhE?= =?utf-8?B?S1BTN3d2aXYxK3RlQmlndytvOVVDWFA3bXdWQ1V3L2dvMjY1UkE2V0FzbE4y?= =?utf-8?B?WklGcEFqOGxWY3pvN0NDeGZIVzR0bm5HK0tHeHIxbWdpK3NiREMzWUZ0bXlj?= =?utf-8?B?TjRkR3FhZHdkWkRML0N0SElkZUF3RThUUFMxbWxBMlorY0ZGbDVaL1pKcVlN?= =?utf-8?B?RkNxT1VQdDl2Q2FVMWpkRHJ2QlBzazd0OStadE9LeG5sNE5ObWptUC9wY1Z4?= =?utf-8?B?YVRNYjk4dE1qZ0MvVWNmak5yTy9idkRxdWtxYWZwUXRvR1l5ZnR1ZkdpQWYr?= =?utf-8?B?R0dPK3ZveGJCMGJFSmVZWlNUSzMwMWV4Q0l5U2FtTExIcUZNMlAzZHJXRlR1?= =?utf-8?B?bGxBazNZLzhhZWVra0w2Z0V1YklhOWlBT05MRmc2M3lpUXo2c2JEOUNUc24y?= =?utf-8?B?dEM4UmZqSWdVSVhQZ0pZN3p0aXFTbS9EUlQ4WUpyVFgxWld2eDVDZzBlcGNo?= =?utf-8?B?OUdlVldnWTV2RXF6S1JHSHBaT2Y3L00wanhUbE1yakdUMnpKcUNtaS9wN1ZP?= =?utf-8?B?WHVJelpVdGo5Ums1Zk03Z1lJaWVTTzVJMWZid2lXRjliNjlzcHpoMUIxakph?= =?utf-8?B?NStyWjZSdmpPdkEwL1RqNS9paFZxR0prblAxOGJzSjhiVUZDckF1ZSthSG1w?= =?utf-8?B?UTE4N3dkRURnbFhZSnlJQ1dOY0NIR25waUFHQ0VIdVQ1cFNlVlFsT3FENnpr?= =?utf-8?B?OWJtMTNNdmcvcjZnZnJlWlRFOXdnWUQ3aXlpOXJBeiszN0JuaXdSMmRzQ2Q2?= =?utf-8?B?aTB0V3FOTUZ5QVlQaXdMa0YvL2R2a1VjRDE5Sm50SW8zbkQzSXE5WHlYTENZ?= =?utf-8?B?d3pEVTJxN05GVmp2MmtLVFFHaTdMN3VqR1hFVU95b0svMGM3NWx4cERPTDBN?= =?utf-8?B?V05Gd01SMUZxaG1tWHJ4MUFHbWFCOWZuWnNaeDluMGlmS3N3aEFGb1ZwL3ZG?= =?utf-8?B?MEtNdStuc1NHbWhnMit3SmZwR2NoMEZKTUhmVnBCdzg0c280czRwKzc4Vk1K?= =?utf-8?B?YXRRV3A5eGJKSVcrdWpOVUhjWkQ1NmJwNFpvM0VyVy9LODZGZFBzZFU1T29U?= =?utf-8?B?YTBQVzFMM3c2bFE4Wkd1blpHOCtWbHZsZ3FzWW1QNyt1VHR4REl2RXR0RFFQ?= =?utf-8?B?cFBoUWVaUU5tOTlPTkM1dWd0RDh4RDQwQSttT2hoUkQ3aXNqaVN1Q3ZjaEhQ?= =?utf-8?B?SStxZHppSlg2cDhObnlNUzMydk4rSFlEaEJ1WGZFbUREUDBseHZCQUV3Uk5m?= =?utf-8?B?Wi94VHUwOVpzeEt6d29oMWVhR2pQMkwyeVl6cjdjbC9KOGF2RnJJbWRBS2RX?= =?utf-8?B?Z0xrcVlVcWhJU2JjQjJubzVYanlJTm1aQUxyUGZFN1k5bS9rSUNyVFVOWjdq?= =?utf-8?B?YzVDR1Z3UEpOSTBldTZQTlU2MEg1ZUN4WjlzUHFyZWxnY2M0OXk2N0tza05B?= =?utf-8?Q?Jg0qkTdjfy/jYDfmy+qtnEUKaKgWjoLGd9X+wR5?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_DBBPR08MB5915D8FC201DFEB31F7D8EA8FA0E9DBBPR08MB5915eurp_" MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR0801MB1735 Original-Authentication-Results: valimail.com; dkim=none (message not signed) header.d=none; valimail.com; dmarc=none action=none header.from=arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: DB5EUR03FT015.eop-EUR03.prod.protection.outlook.com X-MS-Office365-Filtering-Correlation-Id-Prvs: 931f3580-2382-4dca-35c4-08d9315b3302 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: OsUME4ahMqNAQV1kcmK5Oxu1Wa3Rh4bV7dv3h24ylh0UZ8hTJWXY3mpO7fxXeqXJdpNr6TIkEJgEC1lEijnm97cRRx4qTnRosZNcEXzmojYkwVzTuZu7ugSE41wCBfWN/W39ZoxUXUflGYRxlLCZN/Hl/LJoxbf+fCvqkC5ziEwOZPzrbZiHdkAbIqDWUOTLnJwzb1pELPFhzo+zmc14IlXKaM6r+e5CQ/vmP2uP0XMMon4p+fX1d/lJJVgNkhLafdKdTb3V9nIM2BbidKtXWQ5NzUeWig82bSnC2NwK3G92lFIg+6FDk5Zv7hU9oLf6UJBLjqu/NbeFzEroThlKoVlkjqJRGF/JkGUy/0ymcoFdzntyDN5/voviCTqqxjgzt12qaRig4vA6hlcil4R+8k+h+CSjEiwESgMsY1DDiiLRf2TH+lbWYzZ2OvpBTVqhnze9r2/t3Doj9OQXFWSuDyiOonBiFyOgrifWitu/XIxHpH5JF0ULa9kcRTMYjl7r0W18WUUUBjtEyFRam83u1r75agfoTze/rY8amAx2ozrBm8p/MnYS7cmVf24jylHTbFVm+RpQ1uRzV3m81H379B6WMFzWYQeQxujn3BztPUEPJBaKarqDgtSpypeVWQPehkL1DeEb2yIlid3o+zrbNYkkDWWhpkRpqsFK34hFuLvLVUCwNkrpzdM6V3HO1qOP9g0/CqXxfoQs1a0NeGl+OFaMz67BhEuIzD8bhJq8RVzWfT8NvKpypIrhiaThLrNFZj6a/GOCmz4o4NhFOTBnig== X-Forefront-Antispam-Report: CIP:63.35.35.123; CTRY:IE; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:64aa7808-outbound-1.mta.getcheckrecipient.com; PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; CAT:NONE; SFS:(4636009)(39860400002)(346002)(396003)(136003)(376002)(46966006)(36840700001)(6506007)(4326008)(86362001)(6862004)(70586007)(70206006)(9686003)(53546011)(33964004)(30864003)(33656002)(55016002)(7696005)(81166007)(82310400003)(336012)(26005)(5660300002)(47076005)(2906002)(166002)(478600001)(316002)(83380400001)(52536014)(966005)(186003)(8676002)(8936002)(82740400003)(356005)(36860700001); DIR:OUT; SFP:1101; X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Jun 2021 06:43:30.0743 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: bca79ebe-bccc-4f18-735c-08d9315b37fe X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d; Ip=[63.35.35.123]; Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com] X-MS-Exchange-CrossTenant-AuthSource: DB5EUR03FT015.eop-EUR03.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR08MB6629 Archived-At: Subject: Re: [Danish] Charter Text and the Problem Statement X-BeenThere: danish@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DANE AutheNtication for Iot Service Hardening List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jun 2021 06:43:42 -0000 --_000_DBBPR08MB5915D8FC201DFEB31F7D8EA8FA0E9DBBPR08MB5915eurp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzIGZvciB5b3VyIGZlZWRiYWNrLCBBc2guDQoNCkl0IGlzIGludGVyZXN0aW5nIHRoYXQg eW91IG1lbnRpb24gdGhlIG5ldHdvcmsgYWNjZXNzIGF1dGhlbnRpY2F0aW9uIHVzZSBjYXNlLiBE byB5b3UgZW52aXNpb24gRUFQLVRMUyBpbiBjb21iaW5hdGlvbiB3aXRoIERhbmlzaCB0byB3b3Jr IGFyY2hpdGVjdHVyYWxseSBkaWZmZXJlbnRseSB0aGFuIHRoZSBjdXJyZW50IEVBUC1UTFMtYmFz ZWQgYXBwcm9hY2g/DQoNCllvdSB3cml0ZToNCuKAnENyZWRlbnRpYWwgaXNzdWFuY2UgdmVyeSBv ZnRlbiByZXF1aXJlcyB0aGUgZGV2aWNlIGFuZCB0aGUgcGVyc29uIGJvb3RzdHJhcHBpbmcgdGhl IGlkZW50aXR5IHRvIGJlIGluIHRoZSBzYW1lIHBsYWNl4oCdDQoNCkJpbmRpbmcgdGhlIHVzZXIg dG8gaGlzIG9yIGhlciBkZXZpY2UgdHlwaWNhbGx5IHRha2VzIHNvbWUgdGltZS4gSXQgb2Z0ZW4g cmVxdWlyZXMgdGhlIHVzZXIgdG8gbG9nIGludG8gc29tZSBzZXJ2aWNlIGFuZCB0byDigJxhZGTi gJ0gdGhlIG5ldyBkZXZpY2Ugb2Z0ZW4gYnkgZGVtb25zdHJhdGluZyBwaHlzaWNhbCBwb3NzZXNz aW9uLiBPZiBjb3Vyc2UsIHRoaXMgaXMgdGhlIHdheSBob3cgaXQgd29ya3MgZm9yIGVuZCBjb25z dW1lciBwcm9kdWN0cywgd2hlcmUgc2NhbGFiaWxpdHkgaXMgbGVzcyBvZiBhbiBpc3N1ZSBiZWNh dXNlIHlvdSBhcmUgcHJvYmFibHkgbm90IGdvaW5nIHRvIGJ1eSB0aG91c2FuZHMgb2Ygc21hcnQg Y29mZmVlIG1hY2hpbmVzLiBGb3IgYSBjb21tZXJjaWFsIHNldHVwLCB0aGUgcHJvY2VzcyBvZnRl biB3b3JrcyBkaWZmZXJlbnQgYnV0IGl0IHZlcnkgbXVjaCBkZXBlbmRzIG9uIHRoZSB0eXBlIG9m IGluZHVzdHJ5IHZlcnRpY2FsIHlvdSBhcmUgaW4uIFRoZXJlIGlzIG9mdGVuIGEgbm9uLWlycmVs ZXZhbnQgY29uZmlndXJhdGlvbiBzdGVwIGludm9sdmVkIGFzIHdlbGwuIEZvciBleGFtcGxlLCB3 aXRoIGNvbW1lcmNpYWwgaW5kb29yIGxpZ2h0aW5nIHByb2Zlc3Npb25hbHMgbmVlZCB0byBjb25m aWd1cmUgZGlmZmVyZW50IGxpZ2h0aW5nIHRoZW1lcy4NCg0KSSBkb27igJl0IHNlZSBhbnkgb2Yg dGhpcyB1c2VyLXJlbGF0ZWQgaW50ZXJhY3Rpb24gYmVpbmcgY292ZXJlZCBhcyBwYXJ0IG9mIHRo ZSBjaGFydGVyZWQgd29yay4NCg0KQ2lhbw0KSGFubmVzDQoNCkZyb206IEFzaCBXaWxzb24gPGFz aC53aWxzb25AdmFsaW1haWwuY29tPg0KU2VudDogV2VkbmVzZGF5LCBKdW5lIDE2LCAyMDIxIDEx OjI4IFBNDQpUbzogSGFubmVzIFRzY2hvZmVuaWcgPEhhbm5lcy5Uc2Nob2ZlbmlnQGFybS5jb20+ DQpDYzogZGFuaXNoQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW0RhbmlzaF0gQ2hhcnRlciBUZXh0 IGFuZCB0aGUgUHJvYmxlbSBTdGF0ZW1lbnQNCg0KSGkgSGFubmVzLA0KVGhhbmtzIGZvciB0aGUg cXVlc3Rpb25zLCBhbmQgYXBvbG9naWVzIGZvciBrZWVwaW5nIHlvdSB3YWl0aW5nIG9uIGFuc3dl cnMvY2xhcmlmaWNhdGlvbi4NCg0KT24gV2VkLCBKdW4gMTYsIDIwMjEgYXQgNDoxMiBBTSBIYW5u ZXMgVHNjaG9mZW5pZyA8SGFubmVzLlRzY2hvZmVuaWdAYXJtLmNvbTxtYWlsdG86SGFubmVzLlRz Y2hvZmVuaWdAYXJtLmNvbT4+IHdyb3RlOg0KSGkgYWxsLA0KDQpJIGhhdmUgYmVlbiByZWFkaW5n IHRocm91Z2ggdGhlIGNoYXJ0ZXIgdGV4dCBpbiBhbiBhdHRlbXB0IHRvIHVuZGVyc3RhbmQgdGhl IHByb2JsZW0gc3RhdGVtZW50Lg0KDQpUd28gcHJvYmxlbXMgYXJlIG1lbnRpb25lZDoNCg0KDQox KSAgQ2hhbGxlbmdlcyB3aXRoIG5hbWluZyBjb2xsaXNpb25zIGluIHRoZSBJb1Qgc3BhY2UuDQoN Cg0KDQoyKSAgQ3JlZGVudGlhbCBpc3N1YW5jZSBpcyB0aW1lIGNvbnN1bWluZy4NCg0KDQpBZCAx OiBSZWFkaW5nIHRocm91Z2ggdGhlIHRleHQgaXQgZmVlbHMgbGlrZSBuYW1pbmcgY29sbGlzaW9u cyBhcmUgYSBiaWcgdGhpbmcgaW4gSW9ULiBJIGhhdmUgbm90IGhlYXJkIGFib3V0IHRob3NlIHBy b2JsZW1zLiBDb3VsZCB5b3UgZWxhYm9yYXRlPw0KQ2VydGFpbmx5LiBJJ2xsIHVzZSBhIGhvc3Bp dGFsIGFzIGFuIGV4YW1wbGUgZW52aXJvbm1lbnQuDQoNCldpdGhpbiBhIGhvc3BpdGFsLCBpdCBp cyBkZXNpcmFibGUgdG8gaW1wbGVtZW50IDgwMi4xeCBhdXRoZW50aWNhdGlvbiB1c2luZyBFQVAt VExTIGZvciBhY2Nlc3MgdG8gcHJvdGVjdGVkIG5ldHdvcmtzLiBFQVAtVExTIGVuYWJsZXMgdGhl IHVzZSBvZiBQS0ktYmFzZWQgaWRlbnRpdHkgdG8gYXV0aGVudGljYXRlIGFuIGVudGl0eSBmb3Ig bmV0d29yayBhY2Nlc3MuDQoNCldoZW4gaW1wbGVtZW50aW5nIEVBUC1UTFMgZm9yIG5ldHdvcmsg YWNjZXNzLCBSQURJVVMgaXMgYSBjb21tb24gcHJvdG9jb2wvc2VydmVyIHVzZWQgZm9yIGF1dGhl bnRpY2F0aW9uIGJlaGluZCB0aGUgc3dpdGNoIG9yIHdpcmVsZXNzIGFjY2VzcyBwb2ludC4gR3Vp ZGFuY2UgZm9yIGNvbmZpZ3VyaW5nIFJBRElVUyByZWNvbW1lbmRzIHRoZSB1c2Ugb2Ygb25seSBv bmUgQ0EgY2VydGlmaWNhdGUgZm9yIGF1dGhlbnRpY2F0aW5nIHN1cHBsaWNhbnQgY2VydGlmaWNh dGVzLiBUaGlzIGd1aWRhbmNlIGNhbiBiZSBmb3VuZCBpbiB0aGUgd2lsZCBpbiBGcmVlcmFkaXVz IGNvbmZpZ3VyYXRpb24gZmlsZXMgZm9yIEVBUC1UTFMsIHJlbGF0ZWQgdG8gdGhlICdjYV9maWxl JyBjb25maWd1cmF0aW9uIGRpcmVjdGl2ZS4NCg0KQ0FzIGd1YXJhbnRlZSB0aGUgdW5pcXVlbmVz cyBvZiBhbiBlbnRpdHkncyBuYW1lIHdpdGhpbiB0aGUgc2NvcGUgb2YgdGhlIENBLCBidXQgaGF2 ZSBubyBtZXRob2QgZm9yIGVuZm9yY2luZyBuYW1lIHVuaXF1ZW5lc3MgYWNyb3NzIG90aGVyIENB cy4gRm9yIGluc3RhbmNlLCBDQTEgYW5kIENBMiBtYXkgYm90aCBzaWduIGNlcnRpZmljYXRlcyBm b3IgZW50aXRpZXMgd2l0aCB0aGUgc2FtZSBuYW1lLiBJZiBDQTEgYW5kIENBMiBhcmUgYm90aCB0 cnVzdGVkIGJ5IHRoZSBSQURJVVMgc2VydmVyLCBhbmQgdHdvIGVudGl0aWVzIG5hbWVkICJtZWRp Y2FsZGV2aWNlMTIzIiBleGlzdCwgb25lIHBlciBDQSwgdGhlbiB0aGUgcmVzdWx0aW5nIGFtYmln dWl0eSBtYWtlcyBpdCBkaWZmaWN1bHQgdG8gYXBwcm9wcmlhdGVseSBhcHBseSBhY2Nlc3MgY29u dHJvbHMuIFRoaXMgYW1iaWd1aXR5IGlzIG1pdGlnYXRlZCBieSBvcGVyYXRpbmcgYSBzaW5nbGUg b3JnYW5pemF0aW9uYWwgUEtJLCBhbmQgcmVxdWlyaW5nIGlkZW50aXRpZXMgaXNzdWVkIGJ5IHRo YXQgc2luZ2xlIG9yZ2FuaXphdGlvbmFsIFBLSSBmb3IgRUFQLVRMUyBhdXRoZW50aWNhdGlvbi4N Cg0KT25ib2FyZGluZyBkZXZpY2VzIHRvIG9yZ2FuaXphdGlvbmFsIFBLSSByZXF1aXJlcyB0aW1l IGFuZCBlZmZvcnQuIE9mdGVudGltZXMgc29tZSBzb3J0IG9mIHNraWxsZWQgbGFib3IgYW5kL29y IGRlZGljYXRlZCBpbmZyYXN0cnVjdHVyZSBmb3IgYXV0b21hdGluZyB0aGUgb25ib2FyZGluZyBw cm9jZXNzIGlzIGludm9sdmVkLiBEQU5FIGFsbG93cyB1cyB0byBiaW5kIGEgRE5TIG5hbWUgdG8g YSBwdWJsaWMga2V5LCBhbmQgbWl0aWdhdGVzIHRoZSBhbWJpZ3VpdGllcyBpbnRyb2R1Y2VkIGJ5 IHRoZSB1c2Ugb2YgbXVsdGlwbGUgQ0FzLiBBbiBvcmdhbml6YXRpb24gY2FuIG9ubHkgaXNzdWUg d29ya2luZyBpZGVudGl0aWVzIHdpdGhpbiBpdHMgb3duIG5hbWVzcGFjZSBpbiBETlMuIFNpbmNl IG5hbWluZyBhbWJpZ3VpdHkgY2FuIGJlIG1pdGlnYXRlZCB1c2luZyBEQU5FLCB3ZSBtYXkgbm93 IGNob29zZSB0byB1c2UgbWFudWZhY3R1cmVyLWlzc3VlZCBQS0ksIHJlcHJlc2VudGVkIGluIERO UywgZm9yIGF1dGhlbnRpY2F0aW5nIGVudGl0aWVzLg0KDQpGcm9tIHRoZSBob3NwaXRhbCdzIHN0 YW5kcG9pbnQsIHRoZSBJVCBzdGFmZiBubyBsb25nZXIgbmVlZHMgdG8gbWFuYWdlIHRoZSBwcm9j ZXNzIG9mIG9uYm9hcmRpbmcgZGV2aWNlcyB0byBvcmdhbml6YXRpb25hbCBQS0kuIFRoZSBkZXZp Y2UgYXJyaXZlcyBvbi1zaXRlIHdpdGggYW4gaWRlbnRpdHkgd2hpY2ggY2FuIGJlIGltbWVkaWF0 ZWx5IHVzZWQgZm9yIG5ldHdvcmsgYXV0aGVudGljYXRpb24uDQoNCllvdSBhZGQgdGhhdCDigJxJ biByZXNwb25zZSB0byB0aGUgY2hhbGxlbmdlcyByZWxhdGVkIHRvDQoNCmFtYmlndWl0eSBiZXR3 ZWVuIGlkZW50aXRpZXMgaXNzdWVkIGJ5IGRpZmZlcmVudCBDQXMsIGFwcGxpY2F0aW9uIG93bmVy cw0KDQpmcmVxdWVudGx5IGNob29zZSB0byBvbmJvYXJkIElvVCBkZXZpY2VzIHRvIGEgc2luZ2xl IENBLuKAnS4gSXMgdGhhdCBhIGdvb2Qgb3IgYSBiYWQgZGV2ZWxvcG1lbnQ/DQpJdCBpcyBhIGdv b2QgZGV2ZWxvcG1lbnQgaWYgdGhlIG9yZ2FuaXphdGlvbiByZWFsbHkgd2FudHMgdG8gZGlyZWN0 bHkgbWFuYWdlIGFsbCBvZiB0aGUgY3JlZGVudGlhbHMgZm9yIGFsbCBvZiB0aGUgYXBwbGljYXRp b24gcGFydGljaXBhbnRzLiBUaGUgZWZmb3J0IGFuZCByYXRpb25hbGUgYmVoaW5kIEJSU0tJIChS RkMgODk5NSkgc3VnZ2VzdHMgYSBkZXNpcmUgdG8gbWFrZSBvbmJvYXJkaW5nIHRvIG9yZ2FuaXph dGlvbmFsIFBLSSBlYXNpZXIgdG8gYXV0b21hdGUuDQoNCklmIGEgc3VwcGxpZXIgaXNzdWVzIGEg dHJ1c3R3b3J0aHkgaWRlbnRpdHkgZm9yIGEgZGV2aWNlLCBhbmQgRE5TIHByZXZlbnRzIGFub3Ro ZXIgUEtJIGZyb20gaXNzdWluZyB3b3JraW5nIGNyZWRlbnRpYWxzIHVuZGVyIHRoZSBzYW1lIG5h bWUsIHRoZW4gaXNzdWluZyBhbm90aGVyIGlkZW50aXR5IHZpYSBvcmdhbml6YXRpb25hbCBQS0kg YmVjb21lcyBzdXBlcmZsdW91cy4gVGhpcyBpcyB3aGVyZSB3ZSB0aGluayB0aGF0IHRpbWUgYW5k IGVmZm9ydCBjYW4gYmUgc2F2ZWQsIGJlY2F1c2UgdGhlIHNraWxscyByZXF1aXJlZCBmb3Igb25i b2FyZGluZyBkbyBub3QgbmVlZCB0byBpbmNsdWRlIHRoZSBtYW5hZ2VtZW50IGFuZCBpc3N1YW5j ZSBvZiBpZGVudGl0aWVzIHVuZGVyIG9yZ2FuaXphdGlvbmFsIFBLSS4NCg0KQWQgMjogSXMgaXQg cmVhbGx5IHRydWUgdGhhdCBjcmVkZW50aWFsIGlzc3VhbmNlIGlzIHRpbWUgY29uc3VtaW5nPyBX aHkgaXMgdGhhdD8gRm9yIHdob20gaXMgaXQgdGltZSBjb25zdW1pbmc/DQpDcmVkZW50aWFsIGlz c3VhbmNlIHZlcnkgb2Z0ZW4gcmVxdWlyZXMgdGhlIGRldmljZSBhbmQgdGhlIHBlcnNvbiBib290 c3RyYXBwaW5nIHRoZSBpZGVudGl0eSB0byBiZSBpbiB0aGUgc2FtZSBwbGFjZS4gU29tZSBwbGF0 Zm9ybXMgYW5kIHByb3RvY29scyBleGlzdCB0byBtYWtlIHRoYXQgcHJvY2VzcyBlYXNpZXIgKGxp a2UgQlJTS0kpIG9yIGxlc3MgaHVtYW4taW52b2x2aW5nLiBUaGUgdGltZSBpbnZlc3RtZW50IHNl ZW1zIHRvIGJlIG9uIHRoZSBwYXJ0IG9mIGJvdGggdGhlIG1hbnVmYWN0dXJlciAoaW4gaXNzdWlu ZyB0aGUgSURldklEKSBhcyB3ZWxsIGFzIHRoZSBvcmdhbml6YXRpb25hbCBJVCBzdGFmZiwgd2hv IG1hbmFnZSB0aGUgb3JnYW5pemF0aW9uYWwgUEtJLg0KDQpDaWFvDQpIYW5uZXMNCg0KUFM6IFlv dSB1c2UgdGhlIHRlcm0g4oCcQ2VydGlmaWNhdGUgQXV0aG9yaXR5IChDQSnigJ0uIEl0IGlzIGFj dHVhbGx5IGNhbGxlZCDigJxDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eeKAnS4NCg0KDQpJTVBPUlRB TlQgTk9USUNFOiBUaGUgY29udGVudHMgb2YgdGhpcyBlbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRz IGFyZSBjb25maWRlbnRpYWwgYW5kIG1heSBhbHNvIGJlIHByaXZpbGVnZWQuIElmIHlvdSBhcmUg bm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1l ZGlhdGVseSBhbmQgZG8gbm90IGRpc2Nsb3NlIHRoZSBjb250ZW50cyB0byBhbnkgb3RoZXIgcGVy c29uLCB1c2UgaXQgZm9yIGFueSBwdXJwb3NlLCBvciBzdG9yZSBvciBjb3B5IHRoZSBpbmZvcm1h dGlvbiBpbiBhbnkgbWVkaXVtLiBUaGFuayB5b3UuDQotLQ0KRGFuaXNoIG1haWxpbmcgbGlzdA0K RGFuaXNoQGlldGYub3JnPG1haWx0bzpEYW5pc2hAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RhbmlzaA0KDQoNCi0tDQpBc2ggV2lsc29uIHwgVGVjaG5p Y2FsIERpcmVjdG9yDQplOiBhc2gud2lsc29uQHZhbGltYWlsLmNvbTxtYWlsdG86YXNoLndpbHNv bkB2YWxpbWFpbC5jb20+DQpbaHR0cHM6Ly9ob3N0ZWQtcGFja2FnZXMuczMtdXMtd2VzdC0xLmFt YXpvbmF3cy5jb20vVmFsaW1haWwrTG9nby5wbmddDQoNClRoaXMgZW1haWwgYW5kIGFsbCBkYXRh IHRyYW5zbWl0dGVkIHdpdGggaXQgY29udGFpbnMgY29uZmlkZW50aWFsIGFuZC9vciBwcm9wcmll dGFyeSBpbmZvcm1hdGlvbiBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgaW5kaXZpZHVh bChzKSBhdXRob3JpemVkIHRvIHJlY2VpdmUgaXQuIElmIHlvdSBhcmUgbm90IGFuIGludGVuZGVk IGFuZCBhdXRob3JpemVkIHJlY2lwaWVudCB5b3UgYXJlIGhlcmVieSBub3RpZmllZCBvZiBhbnkg dXNlLCBkaXNjbG9zdXJlLCBjb3B5aW5nIG9yIGRpc3RyaWJ1dGlvbiBvZiB0aGUgaW5mb3JtYXRp b24gaW5jbHVkZWQgaW4gdGhpcyB0cmFuc21pc3Npb24gaXMgcHJvaGliaXRlZCBhbmQgbWF5IGJl IHVubGF3ZnVsLiBQbGVhc2UgaW1tZWRpYXRlbHkgbm90aWZ5IHRoZSBzZW5kZXIgYnkgcmVwbHlp bmcgdG8gdGhpcyBlbWFpbCBhbmQgdGhlbiBkZWxldGUgaXQgZnJvbSB5b3VyIHN5c3RlbS4NCg0K SU1QT1JUQU5UIE5PVElDRTogVGhlIGNvbnRlbnRzIG9mIHRoaXMgZW1haWwgYW5kIGFueSBhdHRh Y2htZW50cyBhcmUgY29uZmlkZW50aWFsIGFuZCBtYXkgYWxzbyBiZSBwcml2aWxlZ2VkLiBJZiB5 b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5k ZXIgaW1tZWRpYXRlbHkgYW5kIGRvIG5vdCBkaXNjbG9zZSB0aGUgY29udGVudHMgdG8gYW55IG90 aGVyIHBlcnNvbiwgdXNlIGl0IGZvciBhbnkgcHVycG9zZSwgb3Igc3RvcmUgb3IgY29weSB0aGUg aW5mb3JtYXRpb24gaW4gYW55IG1lZGl1bS4gVGhhbmsgeW91Lg0K --_000_DBBPR08MB5915D8FC201DFEB31F7D8EA8FA0E9DBBPR08MB5915eurp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYg MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpEZW5nWGlhbjsNCglwYW5vc2UtMToy IDEgNiAwIDMgMSAxIDEgMSAxO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsN CglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30NCkBmb250LWZh Y2UNCgl7Zm9udC1mYW1pbHk6IlxARGVuZ1hpYW4iOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEg MSAxIDE7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3Jt YWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxp bmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0 aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHls ZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGluOw0KCWZvbnQtc2l6 ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpzcGFuLkhUTUxQcmVmb3Jt YXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCglt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVk IjsNCglmb250LWZhbWlseTpDb25zb2xhczt9DQpzcGFuLkVtYWlsU3R5bGUyMg0KCXttc28tc3R5 bGUtdHlwZTpwZXJzb25hbC1jb21wb3NlOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNl cmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5 cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBh Z2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBp biAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30N Ci0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6 ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBn dGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2 OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0t LT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxl IiBzdHlsZT0id29yZC13cmFwOmJyZWFrLXdvcmQiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24x Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5rcyBmb3IgeW91ciBmZWVkYmFjaywgQXNoLiA8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SXQgaXMgaW50ZXJlc3RpbmcgdGhhdCB5b3UgbWVudGlv biB0aGUgbmV0d29yayBhY2Nlc3MgYXV0aGVudGljYXRpb24gdXNlIGNhc2UuIERvIHlvdSBlbnZp c2lvbiBFQVAtVExTIGluIGNvbWJpbmF0aW9uIHdpdGggRGFuaXNoIHRvIHdvcmsgYXJjaGl0ZWN0 dXJhbGx5IGRpZmZlcmVudGx5IHRoYW4gdGhlIGN1cnJlbnQgRUFQLVRMUy1iYXNlZCBhcHByb2Fj aD88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+WW91IHdyaXRlOiA8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPuKAnENyZWRlbnRpYWwgaXNzdWFuY2UgdmVyeSBvZnRlbiByZXF1 aXJlcyB0aGUgZGV2aWNlIGFuZCB0aGUgcGVyc29uIGJvb3RzdHJhcHBpbmcgdGhlIGlkZW50aXR5 IHRvIGJlIGluIHRoZSBzYW1lIHBsYWNl4oCdPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkJpbmRp bmcgdGhlIHVzZXIgdG8gaGlzIG9yIGhlciBkZXZpY2UgdHlwaWNhbGx5IHRha2VzIHNvbWUgdGlt ZS4gSXQgb2Z0ZW4gcmVxdWlyZXMgdGhlIHVzZXIgdG8gbG9nIGludG8gc29tZSBzZXJ2aWNlIGFu ZCB0byDigJxhZGTigJ0gdGhlIG5ldyBkZXZpY2Ugb2Z0ZW4gYnkgZGVtb25zdHJhdGluZyBwaHlz aWNhbCBwb3NzZXNzaW9uLiBPZiBjb3Vyc2UsIHRoaXMgaXMgdGhlIHdheSBob3cgaXQgd29ya3Mg Zm9yIGVuZA0KIGNvbnN1bWVyIHByb2R1Y3RzLCB3aGVyZSBzY2FsYWJpbGl0eSBpcyBsZXNzIG9m IGFuIGlzc3VlIGJlY2F1c2UgeW91IGFyZSBwcm9iYWJseSBub3QgZ29pbmcgdG8gYnV5IHRob3Vz YW5kcyBvZiBzbWFydCBjb2ZmZWUgbWFjaGluZXMuIEZvciBhIGNvbW1lcmNpYWwgc2V0dXAsIHRo ZSBwcm9jZXNzIG9mdGVuIHdvcmtzIGRpZmZlcmVudCBidXQgaXQgdmVyeSBtdWNoIGRlcGVuZHMg b24gdGhlIHR5cGUgb2YgaW5kdXN0cnkgdmVydGljYWwgeW91IGFyZQ0KIGluLiBUaGVyZSBpcyBv ZnRlbiBhIG5vbi1pcnJlbGV2YW50IGNvbmZpZ3VyYXRpb24gc3RlcCBpbnZvbHZlZCBhcyB3ZWxs LiBGb3IgZXhhbXBsZSwgd2l0aCBjb21tZXJjaWFsIGluZG9vciBsaWdodGluZyBwcm9mZXNzaW9u YWxzIG5lZWQgdG8gY29uZmlndXJlIGRpZmZlcmVudCBsaWdodGluZyB0aGVtZXMuPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkkgZG9u4oCZdCBzZWUgYW55IG9mIHRoaXMgdXNlci1yZWxhdGVkIGlu dGVyYWN0aW9uIGJlaW5nIGNvdmVyZWQgYXMgcGFydCBvZiB0aGUgY2hhcnRlcmVkIHdvcmsuDQo8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Q2lhbzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+SGFubmVzPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29s aWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxiPkZyb206PC9iPiBBc2ggV2lsc29uICZsdDthc2gud2lsc29uQHZhbGltYWls LmNvbSZndDsgPGJyPg0KPGI+U2VudDo8L2I+IFdlZG5lc2RheSwgSnVuZSAxNiwgMjAyMSAxMToy OCBQTTxicj4NCjxiPlRvOjwvYj4gSGFubmVzIFRzY2hvZmVuaWcgJmx0O0hhbm5lcy5Uc2Nob2Zl bmlnQGFybS5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBkYW5pc2hAaWV0Zi5vcmc8YnI+DQo8Yj5T dWJqZWN0OjwvYj4gUmU6IFtEYW5pc2hdIENoYXJ0ZXIgVGV4dCBhbmQgdGhlIFByb2JsZW0gU3Rh dGVtZW50PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSBI YW5uZXMsPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhbmtz IGZvciB0aGUgcXVlc3Rpb25zLCBhbmQgYXBvbG9naWVzIGZvciBrZWVwaW5nIHlvdSB3YWl0aW5n IG9uIGFuc3dlcnMvY2xhcmlmaWNhdGlvbi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gV2VkLCBKdW4gMTYsIDIwMjEgYXQgNDoxMiBBTSBI YW5uZXMgVHNjaG9mZW5pZyAmbHQ7PGEgaHJlZj0ibWFpbHRvOkhhbm5lcy5Uc2Nob2ZlbmlnQGFy bS5jb20iIHRhcmdldD0iX2JsYW5rIj5IYW5uZXMuVHNjaG9mZW5pZ0Bhcm0uY29tPC9hPiZndDsg d3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4g Ni4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPkhpIGFsbCwNCjwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPkkgaGF2ZSBi ZWVuIHJlYWRpbmcgdGhyb3VnaCB0aGUgY2hhcnRlciB0ZXh0IGluIGFuIGF0dGVtcHQgdG8gdW5k ZXJzdGFuZCB0aGUgcHJvYmxlbSBzdGF0ZW1lbnQuDQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5Ud28gcHJvYmxlbXMgYXJlIG1l bnRpb25lZDo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+MSk8L3Nw YW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBO ZXcgUm9tYW4mcXVvdDssc2VyaWYiPiZuYnNwOw0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5DaGFsbGVuZ2Vz IHdpdGggbmFtaW5nIGNvbGxpc2lvbnMgaW4gdGhlIElvVCBzcGFjZS48L3NwYW4+PG86cD48L286 cD48L3A+DQo8cD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDsiPjIpPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj4mbmJzcDsNCjwvc3Bhbj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 OyI+Q3JlZGVudGlhbCBpc3N1YW5jZSBpcyB0aW1lIGNvbnN1bWluZy48L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86 cD48L286cD48L3A+DQo8cHJlPkFkIDE6IFJlYWRpbmcgdGhyb3VnaCB0aGUgdGV4dCBpdCBmZWVs cyBsaWtlIG5hbWluZyBjb2xsaXNpb25zIGFyZSBhIGJpZyB0aGluZyBpbiBJb1QuIEkgaGF2ZSBu b3QgaGVhcmQgYWJvdXQgdGhvc2UgcHJvYmxlbXMuIENvdWxkIHlvdSBlbGFib3JhdGU/IDxvOnA+ PC9vOnA+PC9wcmU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkNlcnRhaW5seS4gSSdsbCB1c2UgYSBob3NwaXRhbCBhcyBhbiBleGFt cGxlIGVudmlyb25tZW50LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5XaXRoaW4gYSBob3NwaXRhbCwgaXQgaXMgZGVzaXJhYmxlIHRvIGltcGxl bWVudCA4MDIuMXggYXV0aGVudGljYXRpb24gdXNpbmcgRUFQLVRMUyBmb3IgYWNjZXNzIHRvIHBy b3RlY3RlZCBuZXR3b3Jrcy4gRUFQLVRMUyBlbmFibGVzIHRoZSB1c2Ugb2YgUEtJLWJhc2VkIGlk ZW50aXR5IHRvJm5ic3A7YXV0aGVudGljYXRlIGFuIGVudGl0eSBmb3IgbmV0d29yayBhY2Nlc3Mu PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldo ZW4gaW1wbGVtZW50aW5nIEVBUC1UTFMgZm9yIG5ldHdvcmsgYWNjZXNzLCBSQURJVVMgaXMgYSBj b21tb24gcHJvdG9jb2wvc2VydmVyIHVzZWQgZm9yIGF1dGhlbnRpY2F0aW9uIGJlaGluZCB0aGUg c3dpdGNoIG9yIHdpcmVsZXNzIGFjY2VzcyBwb2ludC4gR3VpZGFuY2UgZm9yIGNvbmZpZ3VyaW5n IFJBRElVUyByZWNvbW1lbmRzIHRoZSB1c2Ugb2Ygb25seSBvbmUgQ0EgY2VydGlmaWNhdGUgZm9y IGF1dGhlbnRpY2F0aW5nDQogc3VwcGxpY2FudCZuYnNwO2NlcnRpZmljYXRlcy4gVGhpcyBndWlk YW5jZSBjYW4gYmUgZm91bmQgaW4gdGhlIHdpbGQgaW4gRnJlZXJhZGl1cyBjb25maWd1cmF0aW9u IGZpbGVzIGZvciBFQVAtVExTLCByZWxhdGVkIHRvIHRoZSAnY2FfZmlsZScgY29uZmlndXJhdGlv biBkaXJlY3RpdmUuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkNBcyBndWFyYW50ZWUgdGhlIHVuaXF1ZW5lc3Mgb2YgYW4gZW50aXR5 J3MgbmFtZSB3aXRoaW4gdGhlIHNjb3BlIG9mIHRoZSBDQSwgYnV0IGhhdmUgbm8gbWV0aG9kIGZv ciBlbmZvcmNpbmcgbmFtZSB1bmlxdWVuZXNzIGFjcm9zcyBvdGhlciZuYnNwO0NBcy4gRm9yIGlu c3RhbmNlLCBDQTEgYW5kIENBMiBtYXkgYm90aCBzaWduIGNlcnRpZmljYXRlcyZuYnNwO2ZvciBl bnRpdGllcyB3aXRoIHRoZSBzYW1lIG5hbWUuIElmIENBMQ0KIGFuZCBDQTIgYXJlIGJvdGggdHJ1 c3RlZCBieSB0aGUgUkFESVVTIHNlcnZlciwgYW5kIHR3byBlbnRpdGllcyBuYW1lZCAmcXVvdDtt ZWRpY2FsZGV2aWNlMTIzJnF1b3Q7IGV4aXN0LCBvbmUgcGVyIENBLCB0aGVuIHRoZSByZXN1bHRp bmcgYW1iaWd1aXR5IG1ha2VzIGl0IGRpZmZpY3VsdCB0byBhcHByb3ByaWF0ZWx5IGFwcGx5IGFj Y2VzcyBjb250cm9scy4gVGhpcyBhbWJpZ3VpdHkgaXMmbmJzcDttaXRpZ2F0ZWQgYnkgb3BlcmF0 aW5nIGEgc2luZ2xlIG9yZ2FuaXphdGlvbmFsDQogUEtJLCBhbmQgcmVxdWlyaW5nIGlkZW50aXRp ZXMgaXNzdWVkIGJ5IHRoYXQgc2luZ2xlIG9yZ2FuaXphdGlvbmFsIFBLSSBmb3IgRUFQLVRMUyBh dXRoZW50aWNhdGlvbi4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+T25ib2FyZGluZyBkZXZpY2VzIHRvIG9yZ2FuaXphdGlvbmFsIFBL SSByZXF1aXJlcyB0aW1lIGFuZCBlZmZvcnQuIE9mdGVudGltZXMgc29tZSBzb3J0IG9mIHNraWxs ZWQgbGFib3IgYW5kL29yIGRlZGljYXRlZCBpbmZyYXN0cnVjdHVyZSBmb3IgYXV0b21hdGluZyB0 aGUgb25ib2FyZGluZyBwcm9jZXNzIGlzIGludm9sdmVkLiBEQU5FIGFsbG93cyB1cyB0byBiaW5k IGEgRE5TIG5hbWUgdG8gYSBwdWJsaWMga2V5LA0KIGFuZCBtaXRpZ2F0ZXMgdGhlIGFtYmlndWl0 aWVzIGludHJvZHVjZWQgYnkgdGhlIHVzZSBvZiBtdWx0aXBsZSBDQXMuIEFuIG9yZ2FuaXphdGlv biBjYW4gb25seSBpc3N1ZSB3b3JraW5nIGlkZW50aXRpZXMgd2l0aGluIGl0cyBvd24gbmFtZXNw YWNlIGluIEROUy4gU2luY2UgbmFtaW5nIGFtYmlndWl0eSBjYW4gYmUgbWl0aWdhdGVkIHVzaW5n IERBTkUsIHdlIG1heSBub3cgY2hvb3NlIHRvIHVzZSBtYW51ZmFjdHVyZXItaXNzdWVkIFBLSSwg cmVwcmVzZW50ZWQNCiBpbiBETlMsIGZvciBhdXRoZW50aWNhdGluZyBlbnRpdGllcy48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RnJvbSB0aGUg aG9zcGl0YWwncyBzdGFuZHBvaW50LCB0aGUgSVQgc3RhZmYgbm8gbG9uZ2VyIG5lZWRzIHRvIG1h bmFnZSB0aGUgcHJvY2VzcyBvZiBvbmJvYXJkaW5nIGRldmljZXMgdG8gb3JnYW5pemF0aW9uYWwg UEtJLiBUaGUgZGV2aWNlIGFycml2ZXMgb24tc2l0ZSB3aXRoIGFuIGlkZW50aXR5IHdoaWNoIGNh biBiZSBpbW1lZGlhdGVseSB1c2VkIGZvciBuZXR3b3JrJm5ic3A7YXV0aGVudGljYXRpb24uPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFy Z2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxwcmU+WW91 IGFkZCB0aGF0IOKAnEluIHJlc3BvbnNlIHRvIHRoZSBjaGFsbGVuZ2VzIHJlbGF0ZWQgdG88bzpw PjwvbzpwPjwvcHJlPg0KPHByZT5hbWJpZ3VpdHkgYmV0d2VlbiBpZGVudGl0aWVzIGlzc3VlZCBi eSBkaWZmZXJlbnQgQ0FzLCBhcHBsaWNhdGlvbiBvd25lcnM8bzpwPjwvbzpwPjwvcHJlPg0KPHBy ZT5mcmVxdWVudGx5IGNob29zZSB0byBvbmJvYXJkIElvVCBkZXZpY2VzIHRvIGEgc2luZ2xlIENB LuKAnS4gSXMgdGhhdCBhIGdvb2Qgb3IgYSBiYWQgZGV2ZWxvcG1lbnQ/Jm5ic3A7PG86cD48L286 cD48L3ByZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+SXQgaXMgYSBnb29kIGRldmVsb3BtZW50IGlmIHRoZSBvcmdhbml6YXRpb24g cmVhbGx5IHdhbnRzIHRvIGRpcmVjdGx5IG1hbmFnZSBhbGwgb2YgdGhlIGNyZWRlbnRpYWxzIGZv ciBhbGwgb2YgdGhlIGFwcGxpY2F0aW9uIHBhcnRpY2lwYW50cy4gVGhlIGVmZm9ydCBhbmQgcmF0 aW9uYWxlIGJlaGluZCBCUlNLSSAoUkZDIDg5OTUpIHN1Z2dlc3RzIGEgZGVzaXJlIHRvIG1ha2Ug b25ib2FyZGluZyB0byBvcmdhbml6YXRpb25hbA0KIFBLSSBlYXNpZXIgdG8gYXV0b21hdGUuJm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PklmIGEgc3VwcGxpZXIgaXNzdWVzIGEgdHJ1c3R3b3J0aHkgaWRlbnRpdHkgZm9yIGEgZGV2aWNl LCBhbmQgRE5TIHByZXZlbnRzIGFub3RoZXIgUEtJIGZyb20gaXNzdWluZyB3b3JraW5nIGNyZWRl bnRpYWxzIHVuZGVyIHRoZSBzYW1lIG5hbWUsIHRoZW4gaXNzdWluZyBhbm90aGVyIGlkZW50aXR5 IHZpYSBvcmdhbml6YXRpb25hbCBQS0kgYmVjb21lcyBzdXBlcmZsdW91cy4gVGhpcyBpcyB3aGVy ZSB3ZSB0aGluaw0KIHRoYXQgdGltZSBhbmQgZWZmb3J0IGNhbiBiZSBzYXZlZCwgYmVjYXVzZSB0 aGUgc2tpbGxzIHJlcXVpcmVkIGZvciBvbmJvYXJkaW5nIGRvIG5vdCBuZWVkIHRvIGluY2x1ZGUg dGhlIG1hbmFnZW1lbnQgYW5kIGlzc3VhbmNlIG9mIGlkZW50aXRpZXMgdW5kZXIgb3JnYW5pemF0 aW9uYWwgUEtJLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4g MGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5BZCAyOiBJcyBpdCBy ZWFsbHkgdHJ1ZSB0aGF0IGNyZWRlbnRpYWwgaXNzdWFuY2UgaXMgdGltZSBjb25zdW1pbmc/IFdo eSBpcyB0aGF0PyBGb3Igd2hvbSBpcyBpdCB0aW1lIGNvbnN1bWluZz88L3NwYW4+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkNyZWRlbnRpYWwgaXNzdWFuY2UgdmVyeSBvZnRlbiByZXF1aXJlcyB0aGUgZGV2 aWNlIGFuZCB0aGUgcGVyc29uIGJvb3RzdHJhcHBpbmcgdGhlIGlkZW50aXR5IHRvIGJlIGluIHRo ZSBzYW1lIHBsYWNlLiBTb21lIHBsYXRmb3JtcyBhbmQgcHJvdG9jb2xzIGV4aXN0IHRvIG1ha2Ug dGhhdCBwcm9jZXNzIGVhc2llciAobGlrZSBCUlNLSSkgb3IgbGVzcyBodW1hbi1pbnZvbHZpbmcu IFRoZSB0aW1lIGludmVzdG1lbnQNCiBzZWVtcyB0byBiZSBvbiB0aGUgcGFydCBvZiBib3RoIHRo ZSBtYW51ZmFjdHVyZXIgKGluIGlzc3VpbmcgdGhlIElEZXZJRCkgYXMgd2VsbCBhcyB0aGUgb3Jn YW5pemF0aW9uYWwgSVQgc3RhZmYsIHdobyBtYW5hZ2UgdGhlIG9yZ2FuaXphdGlvbmFsIFBLSS4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2 LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Q2lhbzwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPkhhbm5lczwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOzwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPlBT OiBZb3UgdXNlIHRoZSB0ZXJtIOKAnENlcnRpZmljYXRlIEF1dGhvcml0eSAoQ0Ep4oCdLiBJdCBp cyBhY3R1YWxseSBjYWxsZWQg4oCcQ2VydGlmaWNhdGlvbiBBdXRob3JpdHnigJ0uPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5i c3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5J TVBPUlRBTlQgTk9USUNFOiBUaGUgY29udGVudHMgb2YgdGhpcyBlbWFpbCBhbmQgYW55IGF0dGFj aG1lbnRzIGFyZSBjb25maWRlbnRpYWwgYW5kIG1heSBhbHNvIGJlIHByaXZpbGVnZWQuIElmIHlv dSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRl ciBpbW1lZGlhdGVseSBhbmQgZG8gbm90IGRpc2Nsb3NlIHRoZSBjb250ZW50cyB0byBhbnkgb3Ro ZXIgcGVyc29uLA0KIHVzZSBpdCBmb3IgYW55IHB1cnBvc2UsIG9yIHN0b3JlIG9yIGNvcHkgdGhl IGluZm9ybWF0aW9uIGluIGFueSBtZWRpdW0uIFRoYW5rIHlvdS4NCjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tLSA8YnI+DQpEYW5pc2ggbWFpbGluZyBsaXN0 PGJyPg0KPGEgaHJlZj0ibWFpbHRvOkRhbmlzaEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPkRh bmlzaEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2RhbmlzaCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vZGFuaXNoPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3Rl Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnIgY2xlYXI9ImFsbCI+DQo8bzpwPjwv bzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LS0gPG86cD48L286cD48L3A+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+QXNoIFdpbHNvbjwvc3Bh bj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJp YWwmcXVvdDssc2Fucy1zZXJpZiI+IHwgVGVjaG5pY2FsIERpcmVjdG9yPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox Mi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+ZTo8L3NwYW4+ PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LHNhbnMtc2VyaWYiPg0KPGEgaHJlZj0ibWFpbHRvOmFzaC53aWxzb25AdmFsaW1haWwu Y29tIiB0YXJnZXQ9Il9ibGFuayI+YXNoLndpbHNvbkB2YWxpbWFpbC5jb208L2E+DQo8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj48aW1n IGJvcmRlcj0iMCIgd2lkdGg9IjE3NSIgaGVpZ2h0PSI0MyIgc3R5bGU9IndpZHRoOjEuODI1aW47 aGVpZ2h0Oi40NWluIiBpZD0iX3gwMDAwX2kxMDI1IiBzcmM9Imh0dHBzOi8vaG9zdGVkLXBhY2th Z2VzLnMzLXVzLXdlc3QtMS5hbWF6b25hd3MuY29tL1ZhbGltYWlsK0xvZ28ucG5nIj48L3NwYW4+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv dDssc2Fucy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjow aW47YmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZh bWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM2NjY2NjYiPlRoaXMgZW1h aWwgYW5kIGFsbCBkYXRhIHRyYW5zbWl0dGVkIHdpdGggaXQgY29udGFpbnMgY29uZmlkZW50aWFs IGFuZC9vciBwcm9wcmlldGFyeSBpbmZvcm1hdGlvbiBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1 c2Ugb2YgaW5kaXZpZHVhbChzKSBhdXRob3JpemVkDQogdG8gcmVjZWl2ZSBpdC4gSWYgeW91IGFy ZSBub3QgYW4gaW50ZW5kZWQgYW5kIGF1dGhvcml6ZWQgcmVjaXBpZW50IHlvdSBhcmUgaGVyZWJ5 IG5vdGlmaWVkIG9mIGFueSB1c2UsIGRpc2Nsb3N1cmUsIGNvcHlpbmcgb3IgZGlzdHJpYnV0aW9u IG9mIHRoZSBpbmZvcm1hdGlvbiBpbmNsdWRlZCBpbiB0aGlzIHRyYW5zbWlzc2lvbiBpcyBwcm9o aWJpdGVkIGFuZCBtYXkgYmUgdW5sYXdmdWwuIFBsZWFzZSBpbW1lZGlhdGVseSBub3RpZnkgdGhl IHNlbmRlcg0KIGJ5IHJlcGx5aW5nIHRvIHRoaXMgZW1haWwgYW5kIHRoZW4gZGVsZXRlIGl0IGZy b20geW91ciBzeXN0ZW0uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KSU1QT1JUQU5UIE5PVElDRTogVGhlIGNvbnRlbnRzIG9mIHRoaXMgZW1haWwgYW5kIGFu eSBhdHRhY2htZW50cyBhcmUgY29uZmlkZW50aWFsIGFuZCBtYXkgYWxzbyBiZSBwcml2aWxlZ2Vk LiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2Ugbm90aWZ5IHRo ZSBzZW5kZXIgaW1tZWRpYXRlbHkgYW5kIGRvIG5vdCBkaXNjbG9zZSB0aGUgY29udGVudHMgdG8g YW55IG90aGVyIHBlcnNvbiwgdXNlIGl0IGZvciBhbnkgcHVycG9zZSwNCiBvciBzdG9yZSBvciBj b3B5IHRoZSBpbmZvcm1hdGlvbiBpbiBhbnkgbWVkaXVtLiBUaGFuayB5b3UuDQo8L2JvZHk+DQo8 L2h0bWw+DQo= --_000_DBBPR08MB5915D8FC201DFEB31F7D8EA8FA0E9DBBPR08MB5915eurp_-- From nobody Thu Jun 17 08:17:46 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 C05B93A23EC for ; Thu, 17 Jun 2021 08:17:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=isi-edu.20150623.gappssmtp.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 VHjW5l6wARX6 for ; Thu, 17 Jun 2021 08:17:43 -0700 (PDT) Received: from mail-oo1-xc2a.google.com (mail-oo1-xc2a.google.com [IPv6:2607:f8b0:4864:20::c2a]) (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 0AD7E3A23E7 for ; Thu, 17 Jun 2021 08:17:42 -0700 (PDT) Received: by mail-oo1-xc2a.google.com with SMTP id y18-20020a4ae7120000b02902496b7708cfso1659489oou.9 for ; Thu, 17 Jun 2021 08:17:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isi-edu.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=D9a2WjXBTQqPtc4sCvki72qu2VygW1WZJbXpYH3J8VQ=; b=nrOu8E++KkU6qZ58/l3WZ3QK7VHLZHxOYfSYtphXd7xpU3gk0Inl/pqlBnoKNYiXCI gsRtetSY71iAopvxmTilifjX5rgnyzPKAolTuZZcLuWCUs+zvOG6Lsh7nOuRx5mL5mLe I8Xd0LoIs4etkKvQGdNFoJNb6yNeMVkz+7x9N/0+RmFQOJUykaC1Ujj6O9PgTxc2JJzG nXqCRE/8TXiO2MKW1lb3MRLow4FR7+9yW1CLXNqb0g3G4n0U8EBqGyKyiaOHEZ9iAk/X ZEng6DVtv+fSK5qdva+X/lfMHB10BqrmMt8TUVOvQ+USg1UNRy21o3aCvQq+QXCpzWTk /mgA== 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; bh=D9a2WjXBTQqPtc4sCvki72qu2VygW1WZJbXpYH3J8VQ=; b=Q41aFx0fpVYVq12V+DNiYMjjvNM4iaJOzj3tBY9JoVCkSZeMnEd587zy5W/pofzhrf czWOEz9O37VKulMMH9uKYTX5KS+8ryRbCs05nXEIBxxqUsyyADKKjNJrpupMQWaDbhog HYxxMZpsNbPGpPyZbtjz1gZp+08mr7O8LRXLyJCt7oCTv81NkFp26kyueli4s6RwnGsB rheLBQF/T0Xaxv7LpCB8Lz6IXnw3k7EG2VvZwXSGiwhhDSHMJNpcpCDuyjx50SowjNB9 lIk3QDpky1mP238eXHqVz0L9VJ+o9gv1VcNBAUETfpgu6cjQwbtBqCElq5on6aehrkWB C3yw== X-Gm-Message-State: AOAM531K0nDGfIwtK+0UtA9vWgAtpMWtg9GfgK5BdSZnDCPQwH14J4vc eoIY0FqwklmYXuPqtAjeuq8HxPRo9+9jK9aqcfjwOzi1mg0= X-Google-Smtp-Source: ABdhPJxcVGmkZ8Kv+QTn+hDuV/DgrPgejQoD6yIteJ9HMMPp5L+KzfJBH8rQ4pbtXxoc/FcitN9Xa4Nmmhnjdf7jUmU= X-Received: by 2002:a4a:6107:: with SMTP id n7mr4990153ooc.12.1623943061462; Thu, 17 Jun 2021 08:17:41 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Wes Hardaker Date: Thu, 17 Jun 2021 08:17:04 -0700 Message-ID: To: danish@ietf.org Content-Type: multipart/alternative; boundary="00000000000050771405c4f7b5b8" Archived-At: Subject: Re: [Danish] Charter Text and the Problem Statement X-BeenThere: danish@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DANE AutheNtication for Iot Service Hardening List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jun 2021 15:17:45 -0000 --00000000000050771405c4f7b5b8 Content-Type: text/plain; charset="UTF-8" > > > > We're converging to the same observations, but your terminology is sadly > misleading and regrettable. That could have probably been phrased in a more polite manner (regardless of whether you're right or not). -- Wes Hardaker USC/ISI --00000000000050771405c4f7b5b8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


We're converging to the same observations, but your terminology is sadl= y
misleading and regrettable.=C2=A0=C2=A0

Tha= t could have probably been phrased in a more polite manner (regardless of w= hether you're right or not).
--
Wes Hardaker
USC/ISI
<= /div>
--00000000000050771405c4f7b5b8-- From nobody Thu Jun 17 11:22:06 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 B2D703A2930 for ; Thu, 17 Jun 2021 11:22:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, 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 tYFQI64Wb1YO for ; Thu, 17 Jun 2021 11:21:58 -0700 (PDT) Received: from mail-qt1-x830.google.com (mail-qt1-x830.google.com [IPv6:2607:f8b0:4864:20::830]) (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 0AA0C3A292E for ; Thu, 17 Jun 2021 11:21:57 -0700 (PDT) Received: by mail-qt1-x830.google.com with SMTP id o20so5486295qtr.8 for ; Thu, 17 Jun 2021 11:21:57 -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=ijjVQftg16faP1Uq3QclcDoz3phLy4/rrd547LWV4oA=; b=fXCecL2g/amoC0yXGP7iAitkSzyxJ41ciBDEPhCh4zTYzs9xgLORndVlpHGOLG1ID+ NfmG7KEZldN/DvbpuNeCk6xSF3xX3eq40HpiySqDpIYEds+GO3Nlon41Zk2OHUuuW6Zp 5vo/r4I7fyLnUBQTztK2mJ8uq6CQMKrf+Kx9q+3l9buzu23XzlhIYnd0m5J5zN/hspeR vkn2eIGkkA/ez6fx05dZ3vOsCIMX+CFT6+gYxgt+05gSPt7YWqWqx/gSoZc+Nt9oXF95 iqtTmytGiLebQpnV2tDTmxSyjJXfGUOzR+WC38HPWevbPtOyHUN35ywhyKR0j2l4BTsB ClJw== 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=ijjVQftg16faP1Uq3QclcDoz3phLy4/rrd547LWV4oA=; b=c7UfDyKq5Osp03qQ0OE9RU7a138+xgd4DaVHRImPFQluHWq/svfhv9SgA7GLPkkAcF 9NMdU32aJdkm0FhPoeythXhKBmPH9a7naEgBiQi/R/JfdDLHXgR3f7+mMarr8nJxVAUD r1alnZn9pcWKC7HFhwEieMf4DN+FLtCXkrZfc/TSA4voQH141YVi0C2TDmVctfAYp5pJ Mxr/yBDxdfNfQJ++6uJyoQqJgiLx4Z0400t0p928dRv8IyUcpuqNBFVQyCeAbAU+X55r nby9sD2XfjquK+sx3BuFpW+bH8zZ7n097VfTfxka7i7IHWee0t3tYm/4M4yPXyZjs4mN 6slA== X-Gm-Message-State: AOAM5323rE3IK+2dVrBa4z0DyGVwQCBhN99zpa8FFzE87TwAmKVZ/5tp PXFFRkdG6JAjxDXPh0kLx9mCTXwS9tkzZVPod29i6qOljQcXcg== X-Google-Smtp-Source: ABdhPJzZZFnw/GRgnNJ8uTNwE5FZBJKCOJDm+s/TANSrF+qSEteEoAu1SqhTXddR3EMLRllO4quyrSi8ejAmCkgWCR0= X-Received: by 2002:aed:30cd:: with SMTP id 71mr6416408qtf.31.1623954115907; Thu, 17 Jun 2021 11:21:55 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ash Wilson Date: Thu, 17 Jun 2021 11:21:44 -0700 Message-ID: To: Hannes Tschofenig Cc: "danish@ietf.org" Content-Type: multipart/alternative; boundary="00000000000035e34705c4fa489a" Archived-At: Subject: Re: [Danish] Charter Text and the Problem Statement X-BeenThere: danish@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DANE AutheNtication for Iot Service Hardening List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jun 2021 18:22:04 -0000 --00000000000035e34705c4fa489a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Hannes, Great questions, responses in-line below... On Wed, Jun 16, 2021 at 11:43 PM Hannes Tschofenig < Hannes.Tschofenig@arm.com> wrote: > Thanks for your feedback, Ash. > > > > It is interesting that you mention the network access authentication use > case. Do you envision EAP-TLS in combination with Danish to work > architecturally differently than the current EAP-TLS-based approach? > We hope to minimize the amount of work required to enable DANE client ID for EAP-TLS. Some challenges remain with EAP-TLS in conjunction with TLS 1.3: https://datatracker.ietf.org/doc/html/draft-ietf-emu-eap-tls13-16. Supporting TLS 1.2 for EAP-TLS and DANE would likely be more straightforward, but I do not know whether there's much interest in updating TLS 1.2 to cover this use case. DANE server authentication with EAP-TLS brings another challenge: the absence of IP connectivity prior to authentication. This could be remedied by https://datatracker.ietf.org/doc/html/draft-ietf-tls-dnssec-chain-extension= -07, if the work on that draft were to continue. There are also challenges with validating the chain, tied to root key rotation. Devices which remain unplugged too long may not be able to authenticate. On the other hand, it is a best practice to ensure that a device is patched before putting it into production, and updating roots of trust fits within the scope of that sort of activity. If only DANE for client authentication is supported in EAP-TLS, which is the likely initial outcome, the challenge of getting the authentication server's CA certificate onto the device still exists. This still represents a reduction in effort on the part of the IT staff, but not a perfect zero-touch onboarding unless the supplier also provisions the CA certs for the authentication server... and in the case of WiFi, the SSID to associate with. Still, we think this represents a substantial improvement in the onboarding experience for the implementer. > > You write: > > =E2=80=9CCredential issuance very often requires the device and the perso= n > bootstrapping the identity to be in the same place=E2=80=9D > > > > Binding the user to his or her device typically takes some time. It often > requires the user to log into some service and to =E2=80=9Cadd=E2=80=9D t= he new device > often by demonstrating physical possession. Of course, this is the way ho= w > it works for end consumer products, where scalability is less of an issue > because you are probably not going to buy thousands of smart coffee > machines. For a commercial setup, the process often works different but i= t > very much depends on the type of industry vertical you are in. There is > often a non-irrelevant configuration step involved as well. For example, > with commercial indoor lighting professionals need to configure different > lighting themes. > > > > I don=E2=80=99t see any of this user-related interaction being covered as= part of > the chartered work. > DANE can be useful for home IoT. I think that it could reduce the complexity of automation wherever private PKI is being managed in the consumer's environment, and accelerate and simplify the onboarding experience. IETF is accessible and wide-reaching, and seems like the right place to present and refine the design pattern that might be adopted later by other standards (like CHIP/Matter). I'm also operating under the assumption that enterprise IoT has a more recognized need for interoperability and simpler secure onboarding processes. That is a big assumption, and only based on my observations thus far. I'm open to including the home consumer's perspective in this effort, if you think it's worthwhile. As far as describing the general onboarding experience for the implementer, I had hoped to include that in the architecture document along with examples of how DANE might interface with and support other standards in the broader ecosystem. In trying to keep the charter concise, I think we left out some important information. You bring up an interesting point, with the configuration of lighting profiles during fixture installation. The expectation is that with DANE as the authentication protocol, the variety of suppliers producing devices for a given application might be able to agree on a format for representing configuration information, and devices can securely retrieve it from the system that manages the application's configuration. I think that it would be especially useful to show how DANE works with other discovery protocols (mDNS, for instance) in the process of retrieving the device's configuration. Where do you think this fits best? In the architecture document, or would another format be a better fit for this? > > Ciao > > Hannes > > > > *From:* Ash Wilson > *Sent:* Wednesday, June 16, 2021 11:28 PM > *To:* Hannes Tschofenig > *Cc:* danish@ietf.org > *Subject:* Re: [Danish] Charter Text and the Problem Statement > > > > Hi Hannes, > > Thanks for the questions, and apologies for keeping you waiting on > answers/clarification. > > > > On Wed, Jun 16, 2021 at 4:12 AM Hannes Tschofenig < > Hannes.Tschofenig@arm.com> wrote: > > Hi all, > > > > I have been reading through the charter text in an attempt to understand > the problem statement. > > > > Two problems are mentioned: > > > > 1) Challenges with naming collisions in the IoT space. > > > > 2) Credential issuance is time consuming. > > > > Ad 1: Reading through the text it feels like naming collisions are a big = thing in IoT. I have not heard about those problems. Could you elaborate? > > Certainly. I'll use a hospital as an example environment. > > > > Within a hospital, it is desirable to implement 802.1x authentication > using EAP-TLS for access to protected networks. EAP-TLS enables the use o= f > PKI-based identity to authenticate an entity for network access. > > > > When implementing EAP-TLS for network access, RADIUS is a common > protocol/server used for authentication behind the switch or wireless > access point. Guidance for configuring RADIUS recommends the use of only > one CA certificate for authenticating supplicant certificates. This > guidance can be found in the wild in Freeradius configuration files for > EAP-TLS, related to the 'ca_file' configuration directive. > > > > CAs guarantee the uniqueness of an entity's name within the scope of the > CA, but have no method for enforcing name uniqueness across other CAs. Fo= r > instance, CA1 and CA2 may both sign certificates for entities with the sa= me > name. If CA1 and CA2 are both trusted by the RADIUS server, and two > entities named "medicaldevice123" exist, one per CA, then the resulting > ambiguity makes it difficult to appropriately apply access controls. This > ambiguity is mitigated by operating a single organizational PKI, and > requiring identities issued by that single organizational PKI for EAP-TLS > authentication. > > > > Onboarding devices to organizational PKI requires time and effort. > Oftentimes some sort of skilled labor and/or dedicated infrastructure for > automating the onboarding process is involved. DANE allows us to bind a D= NS > name to a public key, and mitigates the ambiguities introduced by the use > of multiple CAs. An organization can only issue working identities within > its own namespace in DNS. Since naming ambiguity can be mitigated using > DANE, we may now choose to use manufacturer-issued PKI, represented in DN= S, > for authenticating entities. > > > > From the hospital's standpoint, the IT staff no longer needs to manage th= e > process of onboarding devices to organizational PKI. The device arrives > on-site with an identity which can be immediately used for > network authentication. > > You add that =E2=80=9CIn response to the challenges related to > > ambiguity between identities issued by different CAs, application owners > > frequently choose to onboard IoT devices to a single CA.=E2=80=9D. Is tha= t a good or a bad development? > > It is a good development if the organization really wants to directly > manage all of the credentials for all of the application participants. Th= e > effort and rationale behind BRSKI (RFC 8995) suggests a desire to make > onboarding to organizational PKI easier to automate. > > > > If a supplier issues a trustworthy identity for a device, and DNS prevent= s > another PKI from issuing working credentials under the same name, then > issuing another identity via organizational PKI becomes superfluous. This > is where we think that time and effort can be saved, because the skills > required for onboarding do not need to include the management and issuanc= e > of identities under organizational PKI. > > > > Ad 2: Is it really true that credential issuance is time consuming? Why i= s > that? For whom is it time consuming? > > Credential issuance very often requires the device and the person > bootstrapping the identity to be in the same place. Some platforms and > protocols exist to make that process easier (like BRSKI) or less > human-involving. The time investment seems to be on the part of both the > manufacturer (in issuing the IDevID) as well as the organizational IT > staff, who manage the organizational PKI. > > > > Ciao > > Hannes > > > > PS: You use the term =E2=80=9CCertificate Authority (CA)=E2=80=9D. It is = actually called > =E2=80=9CCertification Authority=E2=80=9D. > > > > > > IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose the > contents to any other person, use it for any purpose, or store or copy th= e > information in any medium. Thank you. > > -- > Danish mailing list > Danish@ietf.org > https://www.ietf.org/mailman/listinfo/danish > > > > > -- > > *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 prohibit= ed > and may be unlawful. Please immediately notify the sender by replying to > this email and then delete it from your system. > IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose the > contents to any other person, use it for any purpose, or store or copy th= e > information in any medium. Thank you. > --=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. --00000000000035e34705c4fa489a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Hannes,
Great questions, responses in-li= ne below...

On Wed, Jun 16, 2021 at 11:43 PM Hannes Tschofenig <Hannes.Tschofenig@arm.com> wro= te:

Thanks for your feedback, Ash.

=C2=A0

It is interesting that you mention the network acces= s authentication use case. Do you envision EAP-TLS in combination with Dani= sh to work architecturally differently than the current EAP-TLS-based appro= ach?


We hope to minimize th= e=C2=A0amount of work required to enable DANE client ID for EAP-TLS. Some c= hallenges remain with EAP-TLS in conjunction with TLS 1.3: https://datat= racker.ietf.org/doc/html/draft-ietf-emu-eap-tls13-16. Supporting TLS 1.= 2 for EAP-TLS and DANE would likely be more straightforward, but I do not k= now whether there's much interest in updating TLS 1.2 to cover this use= case.

DANE server authentication with EAP-TLS bri= ngs another challenge: the absence of IP connectivity prior to authenticati= on. This could be remedied by=C2=A0https://datatracker.ietf= .org/doc/html/draft-ietf-tls-dnssec-chain-extension-07, if the work on = that draft were to continue. There are also challenges with validating the = chain, tied to root key rotation. Devices which remain unplugged too long m= ay not be able to authenticate. On the other hand, it is a best practice to= ensure that a device is patched before putting it into production, and upd= ating roots of trust fits within the scope of that sort of activity.
<= div>
If only DANE for client authentication is supported in E= AP-TLS, which is the likely initial outcome, the challenge of getting the a= uthentication server's CA certificate onto the device still exists. Thi= s still represents a reduction in effort on the part of the IT staff, but n= ot a perfect zero-touch onboarding unless the supplier also provisions the = CA certs for the authentication server... and in the case of WiFi, the SSID= to associate with. Still, we think this represents a substantial improveme= nt in the onboarding experience for the=C2=A0implementer.

=C2=A0

You write:

=E2=80=9CCredential issuance very often requires the= device and the person bootstrapping the identity to be in the same place= =E2=80=9D

=C2=A0

Binding the user to his or her device typically take= s some time. It often requires the user to log into some service and to =E2= =80=9Cadd=E2=80=9D the new device often by demonstrating physical possessio= n. Of course, this is the way how it works for end consumer products, where scalability is less of an issue because you are p= robably not going to buy thousands of smart coffee machines. For a commerci= al setup, the process often works different but it very much depends on the= type of industry vertical you are in. There is often a non-irrelevant configuration step involved as well. F= or example, with commercial indoor lighting professionals need to configure= different lighting themes.

=C2=A0

I don=E2=80=99t see any of this user-related interac= tion being covered as part of the chartered work.


DANE can be useful for home IoT. I think that it cou= ld reduce the complexity of automation wherever private PKI is being manage= d in the consumer's environment, and accelerate and simplify the onboar= ding experience. IETF is accessible and wide-reaching, and seems like the r= ight place to present and refine the design pattern that might be adopted l= ater by other standards (like CHIP/Matter). I'm also operating under th= e assumption that enterprise IoT has a more recognized need for interoperab= ility and simpler secure=C2=A0onboarding processes. That is a big assumptio= n, and only based on my observations thus far. I'm open to including th= e home consumer's perspective in this effort, if you think it's wor= thwhile.

As far as describing the general onboardi= ng experience for the implementer, I had hoped to include that in the archi= tecture document along with examples of how DANE might interface with and s= upport other standards in the broader ecosystem. In trying to keep the char= ter concise, I think we left out some important information.

=
You bring up an interesting point, with the configuration of lig= hting profiles during fixture installation. The expectation is that with DA= NE as the authentication protocol, the variety of suppliers producing devic= es for a given application might be able to agree on a format for represent= ing configuration information, and devices can securely retrieve it from th= e system that manages=C2=A0the application's configuration. I think tha= t it would be especially useful to show how DANE works with other discovery= protocols (mDNS, for instance) in the process of retrieving the device'= ;s configuration. Where do you think this fits best? In the architecture do= cument, or would another format be a better fit for this?

=C2=A0

Ciao

Hannes

=C2=A0

From: Ash Wilson <ash.wilson@valimail.com>
Sent: Wednesday, June 16, 2021 11:28 PM
To: Hannes Tschofenig <Hannes.Tschofenig@arm.com>
Cc: danish@ietf= .org
Subject: Re: [Danish] Charter Text and the Problem Statement<= u>

=C2=A0

Hi Hannes,

Thanks for the questions, and apologies for keeping = you waiting on answers/clarification.

=C2=A0

On Wed, Jun 16, 2021 at 4:12 AM Hannes Tschofenig &l= t;Hannes.Tsc= hofenig@arm.com> wrote:

Hi all,

=C2=A0

I have been reading through the charter text in an attempt t= o understand the problem statement.

=C2=A0

Two problems are mentioned:

=C2=A0

1)=C2=A0 C= hallenges with naming collisions in the IoT space.

=C2= =A0

2)=C2=A0 C= redential issuance is time consuming.

=C2=A0

Ad 1: Reading through the text it feels like naming collisions are a b=
ig thing in IoT. I have not heard about those problems. Could you elaborate=
?

Certainly. I'll use a hospital as an example env= ironment.

=C2=A0

Within a hospital, it is desirable to implement 802.= 1x authentication using EAP-TLS for access to protected networks. EAP-TLS e= nables the use of PKI-based identity to=C2=A0authenticate an entity for net= work access.

=C2=A0

When implementing EAP-TLS for network access, RADIUS= is a common protocol/server used for authentication behind the switch or w= ireless access point. Guidance for configuring RADIUS recommends the use of= only one CA certificate for authenticating supplicant=C2=A0certificates. This guidance can be found in the wild in Fr= eeradius configuration files for EAP-TLS, related to the 'ca_file' = configuration directive.=C2=A0

=C2=A0

CAs guarantee the uniqueness of an entity's name= within the scope of the CA, but have no method for enforcing name uniquene= ss across other=C2=A0CAs. For instance, CA1 and CA2 may both sign certifica= tes=C2=A0for entities with the same name. If CA1 and CA2 are both trusted by the RADIUS server, and two entities named &quo= t;medicaldevice123" exist, one per CA, then the resulting ambiguity ma= kes it difficult to appropriately apply access controls. This ambiguity is= =C2=A0mitigated by operating a single organizational PKI, and requiring identities issued by that single organizational PKI for= EAP-TLS authentication.=C2=A0

=C2=A0

Onboarding devices to organizational PKI requires ti= me and effort. Oftentimes some sort of skilled labor and/or dedicated infra= structure for automating the onboarding process is involved. DANE allows us= to bind a DNS name to a public key, and mitigates the ambiguities introduced by the use of multiple CAs. An or= ganization can only issue working identities within its own namespace in DN= S. Since naming ambiguity can be mitigated using DANE, we may now choose to= use manufacturer-issued PKI, represented in DNS, for authenticating entities.

=C2=A0

From the hospital's standpoint, the IT staff no = longer needs to manage the process of onboarding devices to organizational = PKI. The device arrives on-site with an identity which can be immediately u= sed for network=C2=A0authentication.

You add that =E2=80=9CIn response to the challenges related to<=
u>
ambiguity between identities issued by different CAs, application owne=
rs
frequently choose to onboard IoT devices to a single CA.=E2=80=9D. Is =
that a good or a bad development?=C2=A0

It is a good development if the organization really = wants to directly manage all of the credentials for all of the application = participants. The effort and rationale behind BRSKI (RFC 8995) suggests a d= esire to make onboarding to organizational PKI easier to automate.=C2=A0

=C2=A0

If a supplier issues a trustworthy identity for a de= vice, and DNS prevents another PKI from issuing working credentials under t= he same name, then issuing another identity via organizational PKI becomes = superfluous. This is where we think that time and effort can be saved, because the skills required for onboard= ing do not need to include the management and issuance of identities under = organizational PKI.

=C2=A0

Ad 2: Is it really true that credential issuance is time con= suming? Why is that? For whom is it time consuming?

Credential issuance very often requires the device a= nd the person bootstrapping the identity to be in the same place. Some plat= forms and protocols exist to make that process easier (like BRSKI) or less = human-involving. The time investment seems to be on the part of both the manufacturer (in issuing the IDevID) a= s well as the organizational IT staff, who manage the organizational PKI.= =C2=A0

=C2=A0

Ciao

Hannes

=C2=A0

PS: You use the term =E2=80=9CCertificate Authority (CA)=E2= =80=9D. It is actually called =E2=80=9CCertification Authority=E2=80=9D.

=C2=A0

=C2=A0

IMPORTANT NOTICE: The contents of this email and any= attachments are confidential and may also be privileged. If you are not th= e intended recipient, please notify the sender immediately and do not discl= ose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Th= ank you.

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


=C2=A0

--

Ash Wilson | Technical Director

e: ash.wilson@val= imail.com

This email and all data tra= nsmitted with it contains confidential and/or proprietary information inten= ded 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 inf= ormation included in this transmission is prohibited and may be unlawful. P= lease immediately notify the sender by replying to this email and then delete it from your system.

IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in any medium. Thank you.


--

Ash Wilson | Technical Dire= ctor

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

--00000000000035e34705c4fa489a-- From nobody Thu Jun 17 13:14:06 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 5C85A3A2C80 for ; Thu, 17 Jun 2021 13:14:04 -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 zzwRrcL1wp-u for ; Thu, 17 Jun 2021 13:14:02 -0700 (PDT) Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (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 9A6363A2C7E for ; Thu, 17 Jun 2021 13:14:02 -0700 (PDT) Received: by straasha.imrryr.org (Postfix, from userid 1001) id F0DEEC7B37; Thu, 17 Jun 2021 16:13:59 -0400 (EDT) Date: Thu, 17 Jun 2021 16:13:59 -0400 From: Viktor Dukhovni To: danish@ietf.org Message-ID: Reply-To: danish@ietf.org References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Archived-At: Subject: Re: [Danish] Charter Text and the Problem Statement X-BeenThere: danish@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DANE AutheNtication for Iot Service Hardening List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jun 2021 20:14:05 -0000 On Thu, Jun 17, 2021 at 11:21:44AM -0700, Ash Wilson wrote: > DANE server authentication with EAP-TLS brings another challenge: the > absence of IP connectivity prior to authentication. This could be remedied > by https://datatracker.ietf.org/doc/html/draft-ietf-tls-dnssec-chain-extension-07, > if the work on that draft were to continue. That seems rather unlikely in the short term, but in the meantime https://datatracker.ietf.org/doc/draft-dukhovni-tls-dnssec-chain/ will soon be published via the ISE. > There are also challenges with validating the chain, tied to root key > rotation. Devices which remain unplugged too long may not be able to > authenticate. On the other hand, it is a best practice to ensure that > a device is patched before putting it into production, and updating > roots of trust fits within the scope of that sort of activity. Indeed a device that's been on the shelf for O(1 year) or more may well find that the root key has been rolled. There is therefore a need for a mechanism to allow it to "catch up" by updating its software and trust anchors. Secure update of dormant devices is a tricky problem, that may not have a one size fits all solution, there's likely a continuum of tradeoffs between convenience and security. -- Viktor. From nobody Fri Jun 18 08:42:36 2021 Return-Path: X-Original-To: danish@ietf.org Delivered-To: danish@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D7DFB3A158F; Fri, 18 Jun 2021 08:42:33 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: cmorgan@amsl.com, danish-chairs@ietf.org, danish@ietf.org, rdd@cert.org X-Test-IDTracker: no X-IETF-IDTracker: 7.32.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <162403095335.17292.14269217015277307686@ietfa.amsl.com> Date: Fri, 18 Jun 2021 08:42:33 -0700 Archived-At: Subject: [Danish] danish - New Meeting Session Request for IETF 111 X-BeenThere: danish@ietf.org X-Mailman-Version: 2.1.29 List-Id: DANE AutheNtication for Iot Service Hardening List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jun 2021 15:42:34 -0000 A new meeting session request has just been submitted by Cindy Morgan, on behalf of the danish working group. --------------------------------------------------------- Working Group Name: DANE AutheNtication for Iot Service Hardening Area Name: Security Area Session Requester: Cindy Morgan Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 50 Conflicts to Avoid: Chair Conflict: RFCEFDP, IABOPEN, ASDF, CELLAR, ROLL Technology Overlap: TLS, EMU, ANIMA, IOTOPS People who must be present: Michael Richardson Roman Danyliw Wes Hardaker Resources Requested: Special Requests: --------------------------------------------------------- From nobody Fri Jun 18 09:12:31 2021 Return-Path: X-Original-To: danish@ietf.org Delivered-To: danish@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 019E43A16BE; Fri, 18 Jun 2021 09:12:28 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: danish-chairs@ietf.org, danish@ietf.org, lflynn@amsl.com, rdd@cert.org X-Test-IDTracker: no X-IETF-IDTracker: 7.32.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <162403274735.18120.7206204028701419326@ietfa.amsl.com> Date: Fri, 18 Jun 2021 09:12:27 -0700 Archived-At: Subject: [Danish] danish - Update to a Meeting Session Request for IETF 111 X-BeenThere: danish@ietf.org X-Mailman-Version: 2.1.29 List-Id: DANE AutheNtication for Iot Service Hardening List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jun 2021 16:12:28 -0000 An update to a meeting session request has just been submitted by Liz Flynn, on behalf of the danish working group. --------------------------------------------------------- Working Group Name: DANE AutheNtication for Iot Service Hardening Area Name: Security Area Session Requester: Liz Flynn Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 50 Conflicts to Avoid: Chair Conflict: rfcefdp iabopen asdf cellar roll dnsop Technology Overlap: tls emu anima iotops dprive People who must be present: Michael Richardson Roman Danyliw Wes Hardaker Resources Requested: Special Requests: --------------------------------------------------------- From nobody Sat Jun 19 05:48:06 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 418913A0CF8 for ; Sat, 19 Jun 2021 05:48:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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=armh.onmicrosoft.com header.b=sr8j5+r7; dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=sr8j5+r7 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 zgich4G_Id8c for ; Sat, 19 Jun 2021 05:47:59 -0700 (PDT) Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05on2050.outbound.protection.outlook.com [40.107.20.50]) (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 9CE9D3A0CF4 for ; Sat, 19 Jun 2021 05:47:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=3k0qFs3cd4jHAg0nbrq03j6oWhwwsmN9pkL84HNcNS8=; b=sr8j5+r72v/BTbbEFNvEd63nTkiEb8LYOtelyrGcPHBKdE9nU/QN370Npo8i0ZRdsXesYcUiH2zXaIqcZGZAbrZ+H2fo2efVhGU8rCOvM3xuyNmBPRy2/UeNDfW/aEpld7nOx6mmJa05YrhAf0dftBDZErRr/rYmpFFP6/1y1zM= Received: from AM6PR04CA0061.eurprd04.prod.outlook.com (2603:10a6:20b:f0::38) by VI1PR08MB3104.eurprd08.prod.outlook.com (2603:10a6:803:42::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4242.19; Sat, 19 Jun 2021 12:47:51 +0000 Received: from AM5EUR03FT056.eop-EUR03.prod.protection.outlook.com (2603:10a6:20b:f0:cafe::62) by AM6PR04CA0061.outlook.office365.com (2603:10a6:20b:f0::38) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4242.16 via Frontend Transport; Sat, 19 Jun 2021 12:47:51 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; ietf.org; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com;ietf.org; dmarc=pass action=none header.from=arm.com; Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 63.35.35.123 as permitted sender) receiver=protection.outlook.com; client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com; Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by AM5EUR03FT056.mail.protection.outlook.com (10.152.17.224) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4242.16 via Frontend Transport; Sat, 19 Jun 2021 12:47:50 +0000 Received: ("Tessian outbound f88ae75fbd47:v96"); Sat, 19 Jun 2021 12:47:50 +0000 X-CR-MTA-TID: 64aa7808 Received: from dd7b76e47903.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id BE52D4F1-91C5-44AA-B44C-AD7E384A645B.1; Sat, 19 Jun 2021 12:47:43 +0000 Received: from EUR05-VI1-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id dd7b76e47903.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Sat, 19 Jun 2021 12:47:43 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Tvn2TMT9JBSt9sWpH07UMgXDNJuXooeU5161VfQbM9Dwu95GK8LGh3Q5sHDipfu1OBYDae6UFgZ2TSpyVmMqLdgIaZsgdHKEvYtQ2fFNHf2jC3wFLXaNZ8h7GIRhDIxQ9kBmjArPNg+w5+tYi3+ehS+cEAdzrGywbvwST0PyNvJ9FCAgfWjLIqUXkSdTGGTluoBEpqvuvyuT+K7xUSf7gHl35eikfp7jeOY8F6NVzmRlqrYfDpryai0f1Wy5zxLnQdiLO6v5aZdvqa9xQumM4XDcRj1QaeTi7GMLrLGWe+lHTHjy5+p97//Q8J73XzpUToDNmJ9JRRsgLoajQSIr/Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=3k0qFs3cd4jHAg0nbrq03j6oWhwwsmN9pkL84HNcNS8=; b=VUL3+CjcucHcV3cnROVzMadoQMr+wGIK8q4m1yJ81Qi+4tCHT3VX0S7eei5eCSAoUEdBL3fxbodRA400jezrC9lgFOgwn5SGGxlUIwMdGQYA2itOPKwA3ldbWG7TUg+VH4FXylWQRu482iXaVCOd2Peq9jsqWkD4btLhMQNCYY+H0BI1zpNoZA3X9/CxV5WQ2T68k4E82u6S75WIb3y2TlwKOdp7mFWY2ir6B/y1yeGoPe4acENT/Xvwb5ghvKyRLqPcuxAf8wDBh3tbJwyKGAzzuKyD8xVacTbdPxjPyrmPV9lNqPT4BUrbjWqAZqjfVpbqs/adtpMW1+bRGsvZWQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=3k0qFs3cd4jHAg0nbrq03j6oWhwwsmN9pkL84HNcNS8=; b=sr8j5+r72v/BTbbEFNvEd63nTkiEb8LYOtelyrGcPHBKdE9nU/QN370Npo8i0ZRdsXesYcUiH2zXaIqcZGZAbrZ+H2fo2efVhGU8rCOvM3xuyNmBPRy2/UeNDfW/aEpld7nOx6mmJa05YrhAf0dftBDZErRr/rYmpFFP6/1y1zM= Received: from DBBPR08MB5915.eurprd08.prod.outlook.com (2603:10a6:10:20d::17) by DB8PR08MB5019.eurprd08.prod.outlook.com (2603:10a6:10:e0::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4242.21; Sat, 19 Jun 2021 12:47:39 +0000 Received: from DBBPR08MB5915.eurprd08.prod.outlook.com ([fe80::69cf:4429:a804:7f41]) by DBBPR08MB5915.eurprd08.prod.outlook.com ([fe80::69cf:4429:a804:7f41%3]) with mapi id 15.20.4242.023; Sat, 19 Jun 2021 12:47:39 +0000 From: Hannes Tschofenig To: Ash Wilson CC: "danish@ietf.org" Thread-Topic: [Danish] Charter Text and the Problem Statement Thread-Index: Addin8Z32g6ibl9RQiW6iIvXVU0WhwAVq2gAABL3x4AAGNNDAAAroAeQ Date: Sat, 19 Jun 2021 12:47:39 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ts-tracking-id: 18255F622DC5A84B869BC078048A2185.0 x-checkrecipientchecked: true Authentication-Results-Original: valimail.com; dkim=none (message not signed) header.d=none; valimail.com; dmarc=none action=none header.from=arm.com; x-originating-ip: [80.92.123.248] x-ms-publictraffictype: Email X-MS-Office365-Filtering-Correlation-Id: 6439f534-daac-4bb5-e6f2-08d9332072d8 x-ms-traffictypediagnostic: DB8PR08MB5019:|VI1PR08MB3104: X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true nodisclaimer: true x-ms-oob-tlc-oobclassifiers: OLM:6430;OLM:6430; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: 1r60h/E05g7poXoEbboVu+xQsPvDffd0jBwkozVgvac3lOrK9GUoWVekyTKOXuBtlMYzw7XkqFjsXwver2mr5LpQX9iFOlBzhmvWDQN3AjlHe6aQcMUaMJxnwPXZlDHM/npxi4KN1nBVeZOrZZqja6IaVasSVlgylxx2tlZk6sMfGQgMpI5uunggzCsuD1sBY8nbFD7mca4anddmPXJb0BYM1W1DrIa8XFHbsYGqzBUGqKIdpMZ+X3j49qHk4l6jZe1aIyPPTnc9UIAnSYquatwDn+G/GDZp7L7QD5tXJlPMH4lJMF3kW7GsuiZmNiBubJKvTwC2rg733dHlFKczWdqnxfzkXB0Ncy84AE4TJo8hC++g8wW2YNFIAIHbBuxcZVmA50QKfMkKChquIEsQ5xVVFWdJuFS83X+K11lPytZKQ1im/wkF2szpRQthRvfgHluueaZJ1pDIq0si2bL/DWdDALErRrxfpnUMuz6t8BQRChAvR1LQ6oeG7J4L/w3i23ETenvRSK50vvLv4pc1OVaRfSJ8RUMxpC3YPYyXlRcxo4C5nQYWFkvlIvdffEjQTbrlMI7Cn9fBAfhniFHpobIt20A/FN3jPGpYACqFSnmxLfNfr+W5q62XHJZ81O5Z1dOFIwb+xa3/Y+oRjyoiJqDWPVonCHV+49DaIr+oI6p6RBB0moxsamukRns2T1N6OAbTC0us2KYmvTz584uGjy8tr/cdtXYCvf18+xZ9hnPduj5p9wSwscTad2nj9+QH X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DBBPR08MB5915.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(396003)(136003)(366004)(39850400004)(376002)(346002)(2906002)(478600001)(7696005)(316002)(6916009)(52536014)(966005)(66446008)(64756008)(66556008)(66476007)(76116006)(66946007)(33656002)(8676002)(5660300002)(26005)(122000001)(38100700002)(186003)(86362001)(6506007)(53546011)(71200400001)(4326008)(30864003)(8936002)(9686003)(9326002)(55016002)(166002)(83380400001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?RE52UmpGMStDaXBIdUFxUFhLM2lwVG5rSUI3THhVNitaSUkzTklRSHp2TWR1?= =?utf-8?B?RzZpS0NVbnRDWURSQmFZSTkzdG1BOFg3a283bEJITCtjelRCLy9mL0MvZHlt?= =?utf-8?B?MHU2clBqZi9VcENEaXMzM1BId3BqSStEMnFWWVViRFdvTVJtTnkrMHl6RkNo?= =?utf-8?B?RVhvdWpjUk9HZUJoU2pqRUk1K2svMm93ZzMwN1VrZ3c1ODY2ZGd4L2JHS1No?= =?utf-8?B?bjY1ME9xby9FeWIxVnROdmtiUWJyZmQ2WitlMlJ1VG5BelhlMWdBU2NvRkZa?= =?utf-8?B?eElGUEUxQW9qVkFBbjlxTENUWS9FNFpBVHh5N29GVkQ2d2N4VUI2aGtJOExY?= =?utf-8?B?RlFDRWpENGwxcU1KSFVLUHhyOTdjV05tT2U4d0QwNEtNVnJ5dWRBMHlZTGFv?= =?utf-8?B?Z1hwdjB5Tld6cWR0Q1NKdnQ1V0hJaGJyQ29CaFlWMFpMWFFGTG44Ujd3djA5?= =?utf-8?B?L251KzdmK1I4K0JPeURxSmJZbFBJcjJVUndhQUI2R3l6TEl3TDdtODlaSVV4?= =?utf-8?B?RSsvRHl6ODlIbFlQdmVFQjh3NmtRZnRkL2xaL0JLQmErcWJEWXdTY2RZYXJ5?= =?utf-8?B?c2VOWmY4YnhiQ0w0ZWVhemExQmUreG5vbVdwM1JtR1NaejJkS3ZjcWk0dWdE?= =?utf-8?B?VFBRK0JSRmNCMThmaGZKTmcyMnViR29vV3VsbTQ4eHVlSzhENU5KcVZHaDcw?= =?utf-8?B?dGdieFVjcFdrYUx0M2N3b3BKMTUvcU1ub2w5VHFWdVY0cXZBVjNDTjZWcUpa?= =?utf-8?B?bWZUZFNzbEdUZ2dERGFEZXBhUDVjOVVnTW1iZTMxL1JDRGM0OXN3ZmJLYTVa?= =?utf-8?B?ZmIzVGpuOExUdDhkMzU0M1JzUHk5ZkRLNjk4bmFHU2paYzRZNERwbjVGNThL?= =?utf-8?B?cG5yQVN1T3lqWEJWa0krTmxQNHE1M0JCNUZjT1diQmx3cm9YK2RqTnpUb3ZM?= =?utf-8?B?bDAvM0JwQnF5U2ZYWG9lNlRGMWhIODU5cnJCWnEyTGllZ3hHaTJrRFQrOGh1?= =?utf-8?B?ZUJoVDI1V2Z3R1JKeGZWaERvcXJ4cDI3RnN5aFd0bVhoY3UzV2F4cnVZdG4w?= =?utf-8?B?SXRnR3FyczBNYU5DZTJOcDVlQ0tVQkNwOXZadjN0elN2bDNlYUUwVW44dFpo?= =?utf-8?B?UzUvckJNRXRiQUFGc2tLcHU0dGtWSW9VT1drYkUydUFEVENweGRBd29UYzd3?= =?utf-8?B?dlRmdlhza0YzdjVuR2dCTFlwK29GK2FVOUZrZGVWei9vM0JSRFNmbFJmWDBT?= =?utf-8?B?cks3SWVyYnN0T3NkRGR1TnN5SEFWRUdzK3cyWUxLa1JGR3VMTVFCOGtBVWx6?= =?utf-8?B?ODlNL1RIN0xWUC9HWU9ySUlLOWY2cWpITW92T05scVZNbWdJOEtDS2lHL1Nh?= =?utf-8?B?WUtMdTRXNmdtVlYxd3ZGQ3psTDBBTkNVRU5ja3BpeExZeHcwc3dLNm5aam1Q?= =?utf-8?B?YkYzbmtMWXRGbktHaS9kZEN3MzhaNm4zV0diOGZBbDRhVWNJZDZKNitIc2Rt?= =?utf-8?B?Ri9oeVh6Yk1XZ2Z0cHhSWGRFSlhUVW5ObVJ2NmJZMGFaS3pxcjVzUG1FT09B?= =?utf-8?B?eENET3NCUlJqK0JKVVQwSXIzazJKU2wwMFluN1k0VVgyNDNOZ01ZUzhCV2Ry?= =?utf-8?B?ZGhuNzI0Qy9KWS9NRkFFVnFqOHEyZVBHODJwQ2hVajhySUtseFQzY3dLcjI2?= =?utf-8?B?cjc4ZFlPYVVnYVRmNHlKV21zcHRvaEtpUksrb3MxS0hQQjFOUjlxY2dsYmx2?= =?utf-8?Q?soPcnWTYO/Iweeb9Es=3D?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_DBBPR08MB5915C107E3620968DFE34D97FA0C9DBBPR08MB5915eurp_" MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB8PR08MB5019 Original-Authentication-Results: valimail.com; dkim=none (message not signed) header.d=none; valimail.com; dmarc=none action=none header.from=arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: AM5EUR03FT056.eop-EUR03.prod.protection.outlook.com X-MS-Office365-Filtering-Correlation-Id-Prvs: fca033f0-7152-4aaf-d951-08d933206c10 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: MIOWwxOAZ/thBJhpxwBryjMkunBbjcShI9sY4gQsGS9NgsQi2WxnOrTuHL3Ud4dDDcdKDfsjF/j8F7A2HpR/4grSQFP1Kl1qP6hbKDDifLInF9sWKh15QOrZpxOky5FUwHCbDi89SZ9RATl/tzRivdtjXVbaomaZblIWngM5hl6Nb+YMrP1W+sVFafCT+C2x9VtbIcfYU0IAwGbggZ7n6baKzV98zGPJWusb/SEk5DF5o7v8xtfW/T8F36/hPbYGPMql8DPKFHm7zXSbelIAC2D92RmO1VMgcw62lC59rN0OIgMs/skcwafsUvaRfroTZLHyxKXEsGHPFG97f6ub2tqFadIKt7QF+VHF06L9DSdnLznXaU/ijIkl9CFB28cQqlfuTQnuqhxfb1FujhnoTT25mppba+dSzgIAtbzW3ZqZED0/gAgEf/3n54+BTHswUG9PwdLDlasUcqw5zVZrKQzbE/qUr8Y4vih52dFzfNB5OggRRDOBr6MwmcUs423nZfvSlZWeIbtbrjRk7v3CIfWza/bSmrW1/NB5/3k3uLk5Jj07x+hPMFiljiAqpryb2WkVdmDVTcFx+1feDGXHRGVT/RYV8NtDzqOjheGa85HElQ37dICrCBw6uCS8fi38d0SoDcpQ4iIPaApDgHRsSaiNNIYUzdIFCJ8sJdHqwCpqSBiK3eaIHKJKxBtYCYyApHrBP23JA9ENG4QssxqBFPXRcYZX4UL0qrKFEqwWYHDugOhAizqDV3XR0vGyGnEIJUVdaH8QrJIAaoJcsWa6bsXWVqnEB5x3RNYj30totjRnkQWe82fFLXYuFevINjIV X-Forefront-Antispam-Report: CIP:63.35.35.123; CTRY:IE; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:64aa7808-outbound-1.mta.getcheckrecipient.com; PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; CAT:NONE; SFS:(4636009)(346002)(396003)(39850400004)(376002)(136003)(36840700001)(46966006)(70586007)(70206006)(53546011)(83380400001)(6862004)(81166007)(6506007)(5660300002)(7696005)(9686003)(55016002)(4326008)(33964004)(30864003)(2906002)(8936002)(8676002)(82310400003)(82740400003)(316002)(52536014)(47076005)(166002)(966005)(336012)(33656002)(9326002)(186003)(26005)(86362001)(36860700001)(356005)(478600001)(579004); DIR:OUT; SFP:1101; X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Jun 2021 12:47:50.7673 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 6439f534-daac-4bb5-e6f2-08d9332072d8 X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d; Ip=[63.35.35.123]; Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com] X-MS-Exchange-CrossTenant-AuthSource: AM5EUR03FT056.eop-EUR03.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR08MB3104 Archived-At: Subject: Re: [Danish] Charter Text and the Problem Statement X-BeenThere: danish@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DANE AutheNtication for Iot Service Hardening List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Jun 2021 12:48:04 -0000 --_000_DBBPR08MB5915C107E3620968DFE34D97FA0C9DBBPR08MB5915eurp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQXNoLA0KDQpJZiB0aGUgbmV0d29yayBhY2Nlc3MgYXV0aGVudGljYXRpb24gdXNlIGNhc2Ug d2l0aCBFQVAtVExTIGlzIGltcG9ydGFudCB0byB5b3UgdGhlbiBJIGJlbGlldmUgaXQgd291bGQg YmUgZ29vZCB0byBhZGQgaXQgYXMgYSBtaWxlc3RvbmUgb24gdGhlIGNoYXJ0ZXIuIFlvdSBjYW5u b3QgdXNlIGFuIGltcGxlbWVudGF0aW9uIG9mIGRyYWZ0LWlldGYtZW11LWVhcC10bHMxMyBhbmQg YXNzdW1lIGFueSBvZiB0aGUgREFORSBmdW5jdGlvbmFsaXR5IHRvIHdvcmsuIFlvdSB3b3VsZCBp bmRlZWQgaGF2ZSB0byByZWx5IG9uIGRyYWZ0LWlldGYtdGxzLWRuc3NlYy1jaGFpbi1leHRlbnNp b24gYmVjYXVzZSBub3QgaGF2aW5nIG5ldHdvcmsgY29ubmVjdGl2aXR5IGlzIHRoZSBtYWluIHJl YXNvbiB3aHkgeW91IHdvdWxkIGJlIHJ1bm5pbmcgdGhlIEVBUC1UTFMgZXhjaGFuZ2UgaW4gdGhl IGZpcnN0IHBsYWNlLg0KDQpSZWdhcmRpbmcg4oCcYmVzdCBwcmFjdGljZSB0byBlbnN1cmUgdGhh dCBhIGRldmljZSBpcyBwYXRjaGVkIGJlZm9yZSBwdXR0aW5nIGl0IGludG8gcHJvZHVjdGlvbiwg YW5kIHVwZGF0aW5nIHJvb3RzIG9mIHRydXN0IGZpdHMgd2l0aGluIHRoZSBzY29wZSBvZiB0aGF0 IHNvcnQgb2YgYWN0aXZpdHnigJ06IEkgZG9u4oCZdCB0aGluayB0aGVyZSBpcyBhbnkgZXhwZWN0 YXRpb24gdGhhdCB0aGUgZGV2aWNlIHdpbGwgYmUgdXBkYXRlZCBiZWZvcmUgaXQgaXMgcHV0IGlu IHByb2R1Y3Rpb24gKGkuZS4gcG93ZXJlZCBvbiBmb3IgdGhlIGZpcnN0IHRpbWUpLiBZb3UgY2Fu IGFzc3VtZSB0aGF0IHRoZSBkZXZpY2UsIHdoZW4gaXQgY29tZXMgb25saW5lIGZvciB0aGUgZmly c3QgdGltZSBhbmQgcmVhY2hlcyBvdXQgdG8gdGhlIGRldmljZSBtYW5hZ2VtZW50IHNlcnZlciwg Z2V0cyBhIGZpcm13YXJlIHVwZGF0ZS4gSGF2aW5nIHRoYXQgZmlybXdhcmUgdXBkYXRlIGhhcHBl biBiZWZvcmUgaXQgaXMgY29ubmVjdGVkIHRvIHRoZSBuZXR3b3JrIGlzIGV4dHJlbWVseSB1bmxp a2VseS4NCg0KRUFQLVRMUyBpcyBhbHNvIG5vdCBhbiBJb1QgZGV2aWNlIG9uYm9hcmRpbmcgcHJv dG9jb2wuIEZyb20gdGhlIGNoYXJ0ZXIgdGV4dCBJIGFtIGFsc28gbm90IGFzc3VtaW5nIHRoYXQg eW91IGFyZSBhdHRlbXB0aW5nIHRvIGRlZmluZSBhIG5ldyBJb1Qgb25ib2FyZGluZyBwcm90b2Nv bCBvciBkbyB5b3U/DQoNClJlZ2FyZGluZyB0aGUgaG9tZSBJb1QgZW52aXJvbm1lbnQ6IEkgd291 bGQgbm90IGNvdW50IG9uIENISVAvTWF0dGVyIHJlLXVzaW5nIHlvdXIgd29yay4gTXkgdW5kZXJz dGFuZGluZyBpcyB0aGF0IHRoZXkgYXJlIGNyZWF0aW5nIHRoZWlyIG93biBzb2x1dGlvbnMuIFNp bmNlIHRoZSBob21lIGVudmlyb25tZW50IGlzIHZlcnkgZnJhZ21lbnRlZCwgaXQgbWlnaHQgbm90 IGJlIHRoZSBlYXNpZXN0IHBsYWNlIHRvIHN0YXJ0LiBPZiBjb3Vyc2UsIHlvdXIgY29tcGFueSBt YXkgcGxheSBhbmQgdGhhdCBmaWVsZCBhbmQgc28geW91IG1pZ2h0IGhhdmUgYSB3YXkgdG8gZ2V0 IHRoZSBvdXRjb21lIG9mIERBTklTSCBkZXBsb3llZCB0aGVyZS4NCg0KSSBhbSBzdGlsbCB0cnlp bmcgdG8gZmlndXJlIG91dCBob3cgREFOSVNIIGZpdHMgaW50byB0aGUgbGFyZ2VyIHBpY3R1cmUg YW5kIGhlbmNlIEkgYW0gbG9va2luZyBmb3J3YXJkIHRvIHJlYWQgYW4gYXJjaGl0ZWN0dXJlIGRv Y3VtZW50LiBJcyB0aGUgYSBwcmUtZHJhZnQgYXZhaWxhYmxlIGFscmVhZHk/DQoNCkNpYW8NCkhh bm5lcw0KDQpGcm9tOiBBc2ggV2lsc29uIDxhc2gud2lsc29uQHZhbGltYWlsLmNvbT4NClNlbnQ6 IFRodXJzZGF5LCBKdW5lIDE3LCAyMDIxIDg6MjIgUE0NClRvOiBIYW5uZXMgVHNjaG9mZW5pZyA8 SGFubmVzLlRzY2hvZmVuaWdAYXJtLmNvbT4NCkNjOiBkYW5pc2hAaWV0Zi5vcmcNClN1YmplY3Q6 IFJlOiBbRGFuaXNoXSBDaGFydGVyIFRleHQgYW5kIHRoZSBQcm9ibGVtIFN0YXRlbWVudA0KDQpI aSBIYW5uZXMsDQpHcmVhdCBxdWVzdGlvbnMsIHJlc3BvbnNlcyBpbi1saW5lIGJlbG93Li4uDQoN Ck9uIFdlZCwgSnVuIDE2LCAyMDIxIGF0IDExOjQzIFBNIEhhbm5lcyBUc2Nob2ZlbmlnIDxIYW5u ZXMuVHNjaG9mZW5pZ0Bhcm0uY29tPG1haWx0bzpIYW5uZXMuVHNjaG9mZW5pZ0Bhcm0uY29tPj4g d3JvdGU6DQpUaGFua3MgZm9yIHlvdXIgZmVlZGJhY2ssIEFzaC4NCg0KSXQgaXMgaW50ZXJlc3Rp bmcgdGhhdCB5b3UgbWVudGlvbiB0aGUgbmV0d29yayBhY2Nlc3MgYXV0aGVudGljYXRpb24gdXNl IGNhc2UuIERvIHlvdSBlbnZpc2lvbiBFQVAtVExTIGluIGNvbWJpbmF0aW9uIHdpdGggRGFuaXNo IHRvIHdvcmsgYXJjaGl0ZWN0dXJhbGx5IGRpZmZlcmVudGx5IHRoYW4gdGhlIGN1cnJlbnQgRUFQ LVRMUy1iYXNlZCBhcHByb2FjaD8NCg0KV2UgaG9wZSB0byBtaW5pbWl6ZSB0aGUgYW1vdW50IG9m IHdvcmsgcmVxdWlyZWQgdG8gZW5hYmxlIERBTkUgY2xpZW50IElEIGZvciBFQVAtVExTLiBTb21l IGNoYWxsZW5nZXMgcmVtYWluIHdpdGggRUFQLVRMUyBpbiBjb25qdW5jdGlvbiB3aXRoIFRMUyAx LjM6IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtaWV0Zi1lbXUt ZWFwLXRsczEzLTE2LiBTdXBwb3J0aW5nIFRMUyAxLjIgZm9yIEVBUC1UTFMgYW5kIERBTkUgd291 bGQgbGlrZWx5IGJlIG1vcmUgc3RyYWlnaHRmb3J3YXJkLCBidXQgSSBkbyBub3Qga25vdyB3aGV0 aGVyIHRoZXJlJ3MgbXVjaCBpbnRlcmVzdCBpbiB1cGRhdGluZyBUTFMgMS4yIHRvIGNvdmVyIHRo aXMgdXNlIGNhc2UuDQoNCkRBTkUgc2VydmVyIGF1dGhlbnRpY2F0aW9uIHdpdGggRUFQLVRMUyBi cmluZ3MgYW5vdGhlciBjaGFsbGVuZ2U6IHRoZSBhYnNlbmNlIG9mIElQIGNvbm5lY3Rpdml0eSBw cmlvciB0byBhdXRoZW50aWNhdGlvbi4gVGhpcyBjb3VsZCBiZSByZW1lZGllZCBieSBodHRwczov L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWlldGYtdGxzLWRuc3NlYy1jaGFp bi1leHRlbnNpb24tMDcsIGlmIHRoZSB3b3JrIG9uIHRoYXQgZHJhZnQgd2VyZSB0byBjb250aW51 ZS4gVGhlcmUgYXJlIGFsc28gY2hhbGxlbmdlcyB3aXRoIHZhbGlkYXRpbmcgdGhlIGNoYWluLCB0 aWVkIHRvIHJvb3Qga2V5IHJvdGF0aW9uLiBEZXZpY2VzIHdoaWNoIHJlbWFpbiB1bnBsdWdnZWQg dG9vIGxvbmcgbWF5IG5vdCBiZSBhYmxlIHRvIGF1dGhlbnRpY2F0ZS4gT24gdGhlIG90aGVyIGhh bmQsIGl0IGlzIGEgYmVzdCBwcmFjdGljZSB0byBlbnN1cmUgdGhhdCBhIGRldmljZSBpcyBwYXRj aGVkIGJlZm9yZSBwdXR0aW5nIGl0IGludG8gcHJvZHVjdGlvbiwgYW5kIHVwZGF0aW5nIHJvb3Rz IG9mIHRydXN0IGZpdHMgd2l0aGluIHRoZSBzY29wZSBvZiB0aGF0IHNvcnQgb2YgYWN0aXZpdHku DQoNCklmIG9ubHkgREFORSBmb3IgY2xpZW50IGF1dGhlbnRpY2F0aW9uIGlzIHN1cHBvcnRlZCBp biBFQVAtVExTLCB3aGljaCBpcyB0aGUgbGlrZWx5IGluaXRpYWwgb3V0Y29tZSwgdGhlIGNoYWxs ZW5nZSBvZiBnZXR0aW5nIHRoZSBhdXRoZW50aWNhdGlvbiBzZXJ2ZXIncyBDQSBjZXJ0aWZpY2F0 ZSBvbnRvIHRoZSBkZXZpY2Ugc3RpbGwgZXhpc3RzLiBUaGlzIHN0aWxsIHJlcHJlc2VudHMgYSBy ZWR1Y3Rpb24gaW4gZWZmb3J0IG9uIHRoZSBwYXJ0IG9mIHRoZSBJVCBzdGFmZiwgYnV0IG5vdCBh IHBlcmZlY3QgemVyby10b3VjaCBvbmJvYXJkaW5nIHVubGVzcyB0aGUgc3VwcGxpZXIgYWxzbyBw cm92aXNpb25zIHRoZSBDQSBjZXJ0cyBmb3IgdGhlIGF1dGhlbnRpY2F0aW9uIHNlcnZlci4uLiBh bmQgaW4gdGhlIGNhc2Ugb2YgV2lGaSwgdGhlIFNTSUQgdG8gYXNzb2NpYXRlIHdpdGguIFN0aWxs LCB3ZSB0aGluayB0aGlzIHJlcHJlc2VudHMgYSBzdWJzdGFudGlhbCBpbXByb3ZlbWVudCBpbiB0 aGUgb25ib2FyZGluZyBleHBlcmllbmNlIGZvciB0aGUgaW1wbGVtZW50ZXIuDQoNCg0KWW91IHdy aXRlOg0K4oCcQ3JlZGVudGlhbCBpc3N1YW5jZSB2ZXJ5IG9mdGVuIHJlcXVpcmVzIHRoZSBkZXZp Y2UgYW5kIHRoZSBwZXJzb24gYm9vdHN0cmFwcGluZyB0aGUgaWRlbnRpdHkgdG8gYmUgaW4gdGhl IHNhbWUgcGxhY2XigJ0NCg0KQmluZGluZyB0aGUgdXNlciB0byBoaXMgb3IgaGVyIGRldmljZSB0 eXBpY2FsbHkgdGFrZXMgc29tZSB0aW1lLiBJdCBvZnRlbiByZXF1aXJlcyB0aGUgdXNlciB0byBs b2cgaW50byBzb21lIHNlcnZpY2UgYW5kIHRvIOKAnGFkZOKAnSB0aGUgbmV3IGRldmljZSBvZnRl biBieSBkZW1vbnN0cmF0aW5nIHBoeXNpY2FsIHBvc3Nlc3Npb24uIE9mIGNvdXJzZSwgdGhpcyBp cyB0aGUgd2F5IGhvdyBpdCB3b3JrcyBmb3IgZW5kIGNvbnN1bWVyIHByb2R1Y3RzLCB3aGVyZSBz Y2FsYWJpbGl0eSBpcyBsZXNzIG9mIGFuIGlzc3VlIGJlY2F1c2UgeW91IGFyZSBwcm9iYWJseSBu b3QgZ29pbmcgdG8gYnV5IHRob3VzYW5kcyBvZiBzbWFydCBjb2ZmZWUgbWFjaGluZXMuIEZvciBh IGNvbW1lcmNpYWwgc2V0dXAsIHRoZSBwcm9jZXNzIG9mdGVuIHdvcmtzIGRpZmZlcmVudCBidXQg aXQgdmVyeSBtdWNoIGRlcGVuZHMgb24gdGhlIHR5cGUgb2YgaW5kdXN0cnkgdmVydGljYWwgeW91 IGFyZSBpbi4gVGhlcmUgaXMgb2Z0ZW4gYSBub24taXJyZWxldmFudCBjb25maWd1cmF0aW9uIHN0 ZXAgaW52b2x2ZWQgYXMgd2VsbC4gRm9yIGV4YW1wbGUsIHdpdGggY29tbWVyY2lhbCBpbmRvb3Ig bGlnaHRpbmcgcHJvZmVzc2lvbmFscyBuZWVkIHRvIGNvbmZpZ3VyZSBkaWZmZXJlbnQgbGlnaHRp bmcgdGhlbWVzLg0KDQpJIGRvbuKAmXQgc2VlIGFueSBvZiB0aGlzIHVzZXItcmVsYXRlZCBpbnRl cmFjdGlvbiBiZWluZyBjb3ZlcmVkIGFzIHBhcnQgb2YgdGhlIGNoYXJ0ZXJlZCB3b3JrLg0KDQpE QU5FIGNhbiBiZSB1c2VmdWwgZm9yIGhvbWUgSW9ULiBJIHRoaW5rIHRoYXQgaXQgY291bGQgcmVk dWNlIHRoZSBjb21wbGV4aXR5IG9mIGF1dG9tYXRpb24gd2hlcmV2ZXIgcHJpdmF0ZSBQS0kgaXMg YmVpbmcgbWFuYWdlZCBpbiB0aGUgY29uc3VtZXIncyBlbnZpcm9ubWVudCwgYW5kIGFjY2VsZXJh dGUgYW5kIHNpbXBsaWZ5IHRoZSBvbmJvYXJkaW5nIGV4cGVyaWVuY2UuIElFVEYgaXMgYWNjZXNz aWJsZSBhbmQgd2lkZS1yZWFjaGluZywgYW5kIHNlZW1zIGxpa2UgdGhlIHJpZ2h0IHBsYWNlIHRv IHByZXNlbnQgYW5kIHJlZmluZSB0aGUgZGVzaWduIHBhdHRlcm4gdGhhdCBtaWdodCBiZSBhZG9w dGVkIGxhdGVyIGJ5IG90aGVyIHN0YW5kYXJkcyAobGlrZSBDSElQL01hdHRlcikuIEknbSBhbHNv IG9wZXJhdGluZyB1bmRlciB0aGUgYXNzdW1wdGlvbiB0aGF0IGVudGVycHJpc2UgSW9UIGhhcyBh IG1vcmUgcmVjb2duaXplZCBuZWVkIGZvciBpbnRlcm9wZXJhYmlsaXR5IGFuZCBzaW1wbGVyIHNl Y3VyZSBvbmJvYXJkaW5nIHByb2Nlc3Nlcy4gVGhhdCBpcyBhIGJpZyBhc3N1bXB0aW9uLCBhbmQg b25seSBiYXNlZCBvbiBteSBvYnNlcnZhdGlvbnMgdGh1cyBmYXIuIEknbSBvcGVuIHRvIGluY2x1 ZGluZyB0aGUgaG9tZSBjb25zdW1lcidzIHBlcnNwZWN0aXZlIGluIHRoaXMgZWZmb3J0LCBpZiB5 b3UgdGhpbmsgaXQncyB3b3J0aHdoaWxlLg0KDQoNCkFzIGZhciBhcyBkZXNjcmliaW5nIHRoZSBn ZW5lcmFsIG9uYm9hcmRpbmcgZXhwZXJpZW5jZSBmb3IgdGhlIGltcGxlbWVudGVyLCBJIGhhZCBo b3BlZCB0byBpbmNsdWRlIHRoYXQgaW4gdGhlIGFyY2hpdGVjdHVyZSBkb2N1bWVudCBhbG9uZyB3 aXRoIGV4YW1wbGVzIG9mIGhvdyBEQU5FIG1pZ2h0IGludGVyZmFjZSB3aXRoIGFuZCBzdXBwb3J0 IG90aGVyIHN0YW5kYXJkcyBpbiB0aGUgYnJvYWRlciBlY29zeXN0ZW0uIEluIHRyeWluZyB0byBr ZWVwIHRoZSBjaGFydGVyIGNvbmNpc2UsIEkgdGhpbmsgd2UgbGVmdCBvdXQgc29tZSBpbXBvcnRh bnQgaW5mb3JtYXRpb24uDQoNCllvdSBicmluZyB1cCBhbiBpbnRlcmVzdGluZyBwb2ludCwgd2l0 aCB0aGUgY29uZmlndXJhdGlvbiBvZiBsaWdodGluZyBwcm9maWxlcyBkdXJpbmcgZml4dHVyZSBp bnN0YWxsYXRpb24uIFRoZSBleHBlY3RhdGlvbiBpcyB0aGF0IHdpdGggREFORSBhcyB0aGUgYXV0 aGVudGljYXRpb24gcHJvdG9jb2wsIHRoZSB2YXJpZXR5IG9mIHN1cHBsaWVycyBwcm9kdWNpbmcg ZGV2aWNlcyBmb3IgYSBnaXZlbiBhcHBsaWNhdGlvbiBtaWdodCBiZSBhYmxlIHRvIGFncmVlIG9u IGEgZm9ybWF0IGZvciByZXByZXNlbnRpbmcgY29uZmlndXJhdGlvbiBpbmZvcm1hdGlvbiwgYW5k IGRldmljZXMgY2FuIHNlY3VyZWx5IHJldHJpZXZlIGl0IGZyb20gdGhlIHN5c3RlbSB0aGF0IG1h bmFnZXMgdGhlIGFwcGxpY2F0aW9uJ3MgY29uZmlndXJhdGlvbi4gSSB0aGluayB0aGF0IGl0IHdv dWxkIGJlIGVzcGVjaWFsbHkgdXNlZnVsIHRvIHNob3cgaG93IERBTkUgd29ya3Mgd2l0aCBvdGhl ciBkaXNjb3ZlcnkgcHJvdG9jb2xzIChtRE5TLCBmb3IgaW5zdGFuY2UpIGluIHRoZSBwcm9jZXNz IG9mIHJldHJpZXZpbmcgdGhlIGRldmljZSdzIGNvbmZpZ3VyYXRpb24uIFdoZXJlIGRvIHlvdSB0 aGluayB0aGlzIGZpdHMgYmVzdD8gSW4gdGhlIGFyY2hpdGVjdHVyZSBkb2N1bWVudCwgb3Igd291 bGQgYW5vdGhlciBmb3JtYXQgYmUgYSBiZXR0ZXIgZml0IGZvciB0aGlzPw0KDQoNCkNpYW8NCkhh bm5lcw0KDQpGcm9tOiBBc2ggV2lsc29uIDxhc2gud2lsc29uQHZhbGltYWlsLmNvbTxtYWlsdG86 YXNoLndpbHNvbkB2YWxpbWFpbC5jb20+Pg0KU2VudDogV2VkbmVzZGF5LCBKdW5lIDE2LCAyMDIx IDExOjI4IFBNDQpUbzogSGFubmVzIFRzY2hvZmVuaWcgPEhhbm5lcy5Uc2Nob2ZlbmlnQGFybS5j b208bWFpbHRvOkhhbm5lcy5Uc2Nob2ZlbmlnQGFybS5jb20+Pg0KQ2M6IGRhbmlzaEBpZXRmLm9y ZzxtYWlsdG86ZGFuaXNoQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtEYW5pc2hdIENoYXJ0ZXIg VGV4dCBhbmQgdGhlIFByb2JsZW0gU3RhdGVtZW50DQoNCkhpIEhhbm5lcywNClRoYW5rcyBmb3Ig dGhlIHF1ZXN0aW9ucywgYW5kIGFwb2xvZ2llcyBmb3Iga2VlcGluZyB5b3Ugd2FpdGluZyBvbiBh bnN3ZXJzL2NsYXJpZmljYXRpb24uDQoNCk9uIFdlZCwgSnVuIDE2LCAyMDIxIGF0IDQ6MTIgQU0g SGFubmVzIFRzY2hvZmVuaWcgPEhhbm5lcy5Uc2Nob2ZlbmlnQGFybS5jb208bWFpbHRvOkhhbm5l cy5Uc2Nob2ZlbmlnQGFybS5jb20+PiB3cm90ZToNCkhpIGFsbCwNCg0KSSBoYXZlIGJlZW4gcmVh ZGluZyB0aHJvdWdoIHRoZSBjaGFydGVyIHRleHQgaW4gYW4gYXR0ZW1wdCB0byB1bmRlcnN0YW5k IHRoZSBwcm9ibGVtIHN0YXRlbWVudC4NCg0KVHdvIHByb2JsZW1zIGFyZSBtZW50aW9uZWQ6DQoN Cg0KMSkgIENoYWxsZW5nZXMgd2l0aCBuYW1pbmcgY29sbGlzaW9ucyBpbiB0aGUgSW9UIHNwYWNl Lg0KDQoNCg0KMikgIENyZWRlbnRpYWwgaXNzdWFuY2UgaXMgdGltZSBjb25zdW1pbmcuDQoNCg0K QWQgMTogUmVhZGluZyB0aHJvdWdoIHRoZSB0ZXh0IGl0IGZlZWxzIGxpa2UgbmFtaW5nIGNvbGxp c2lvbnMgYXJlIGEgYmlnIHRoaW5nIGluIElvVC4gSSBoYXZlIG5vdCBoZWFyZCBhYm91dCB0aG9z ZSBwcm9ibGVtcy4gQ291bGQgeW91IGVsYWJvcmF0ZT8NCkNlcnRhaW5seS4gSSdsbCB1c2UgYSBo b3NwaXRhbCBhcyBhbiBleGFtcGxlIGVudmlyb25tZW50Lg0KDQpXaXRoaW4gYSBob3NwaXRhbCwg aXQgaXMgZGVzaXJhYmxlIHRvIGltcGxlbWVudCA4MDIuMXggYXV0aGVudGljYXRpb24gdXNpbmcg RUFQLVRMUyBmb3IgYWNjZXNzIHRvIHByb3RlY3RlZCBuZXR3b3Jrcy4gRUFQLVRMUyBlbmFibGVz IHRoZSB1c2Ugb2YgUEtJLWJhc2VkIGlkZW50aXR5IHRvIGF1dGhlbnRpY2F0ZSBhbiBlbnRpdHkg Zm9yIG5ldHdvcmsgYWNjZXNzLg0KDQpXaGVuIGltcGxlbWVudGluZyBFQVAtVExTIGZvciBuZXR3 b3JrIGFjY2VzcywgUkFESVVTIGlzIGEgY29tbW9uIHByb3RvY29sL3NlcnZlciB1c2VkIGZvciBh dXRoZW50aWNhdGlvbiBiZWhpbmQgdGhlIHN3aXRjaCBvciB3aXJlbGVzcyBhY2Nlc3MgcG9pbnQu IEd1aWRhbmNlIGZvciBjb25maWd1cmluZyBSQURJVVMgcmVjb21tZW5kcyB0aGUgdXNlIG9mIG9u bHkgb25lIENBIGNlcnRpZmljYXRlIGZvciBhdXRoZW50aWNhdGluZyBzdXBwbGljYW50IGNlcnRp ZmljYXRlcy4gVGhpcyBndWlkYW5jZSBjYW4gYmUgZm91bmQgaW4gdGhlIHdpbGQgaW4gRnJlZXJh ZGl1cyBjb25maWd1cmF0aW9uIGZpbGVzIGZvciBFQVAtVExTLCByZWxhdGVkIHRvIHRoZSAnY2Ff ZmlsZScgY29uZmlndXJhdGlvbiBkaXJlY3RpdmUuDQoNCkNBcyBndWFyYW50ZWUgdGhlIHVuaXF1 ZW5lc3Mgb2YgYW4gZW50aXR5J3MgbmFtZSB3aXRoaW4gdGhlIHNjb3BlIG9mIHRoZSBDQSwgYnV0 IGhhdmUgbm8gbWV0aG9kIGZvciBlbmZvcmNpbmcgbmFtZSB1bmlxdWVuZXNzIGFjcm9zcyBvdGhl ciBDQXMuIEZvciBpbnN0YW5jZSwgQ0ExIGFuZCBDQTIgbWF5IGJvdGggc2lnbiBjZXJ0aWZpY2F0 ZXMgZm9yIGVudGl0aWVzIHdpdGggdGhlIHNhbWUgbmFtZS4gSWYgQ0ExIGFuZCBDQTIgYXJlIGJv dGggdHJ1c3RlZCBieSB0aGUgUkFESVVTIHNlcnZlciwgYW5kIHR3byBlbnRpdGllcyBuYW1lZCAi bWVkaWNhbGRldmljZTEyMyIgZXhpc3QsIG9uZSBwZXIgQ0EsIHRoZW4gdGhlIHJlc3VsdGluZyBh bWJpZ3VpdHkgbWFrZXMgaXQgZGlmZmljdWx0IHRvIGFwcHJvcHJpYXRlbHkgYXBwbHkgYWNjZXNz IGNvbnRyb2xzLiBUaGlzIGFtYmlndWl0eSBpcyBtaXRpZ2F0ZWQgYnkgb3BlcmF0aW5nIGEgc2lu Z2xlIG9yZ2FuaXphdGlvbmFsIFBLSSwgYW5kIHJlcXVpcmluZyBpZGVudGl0aWVzIGlzc3VlZCBi eSB0aGF0IHNpbmdsZSBvcmdhbml6YXRpb25hbCBQS0kgZm9yIEVBUC1UTFMgYXV0aGVudGljYXRp b24uDQoNCk9uYm9hcmRpbmcgZGV2aWNlcyB0byBvcmdhbml6YXRpb25hbCBQS0kgcmVxdWlyZXMg dGltZSBhbmQgZWZmb3J0LiBPZnRlbnRpbWVzIHNvbWUgc29ydCBvZiBza2lsbGVkIGxhYm9yIGFu ZC9vciBkZWRpY2F0ZWQgaW5mcmFzdHJ1Y3R1cmUgZm9yIGF1dG9tYXRpbmcgdGhlIG9uYm9hcmRp bmcgcHJvY2VzcyBpcyBpbnZvbHZlZC4gREFORSBhbGxvd3MgdXMgdG8gYmluZCBhIEROUyBuYW1l IHRvIGEgcHVibGljIGtleSwgYW5kIG1pdGlnYXRlcyB0aGUgYW1iaWd1aXRpZXMgaW50cm9kdWNl ZCBieSB0aGUgdXNlIG9mIG11bHRpcGxlIENBcy4gQW4gb3JnYW5pemF0aW9uIGNhbiBvbmx5IGlz c3VlIHdvcmtpbmcgaWRlbnRpdGllcyB3aXRoaW4gaXRzIG93biBuYW1lc3BhY2UgaW4gRE5TLiBT aW5jZSBuYW1pbmcgYW1iaWd1aXR5IGNhbiBiZSBtaXRpZ2F0ZWQgdXNpbmcgREFORSwgd2UgbWF5 IG5vdyBjaG9vc2UgdG8gdXNlIG1hbnVmYWN0dXJlci1pc3N1ZWQgUEtJLCByZXByZXNlbnRlZCBp biBETlMsIGZvciBhdXRoZW50aWNhdGluZyBlbnRpdGllcy4NCg0KRnJvbSB0aGUgaG9zcGl0YWwn cyBzdGFuZHBvaW50LCB0aGUgSVQgc3RhZmYgbm8gbG9uZ2VyIG5lZWRzIHRvIG1hbmFnZSB0aGUg cHJvY2VzcyBvZiBvbmJvYXJkaW5nIGRldmljZXMgdG8gb3JnYW5pemF0aW9uYWwgUEtJLiBUaGUg ZGV2aWNlIGFycml2ZXMgb24tc2l0ZSB3aXRoIGFuIGlkZW50aXR5IHdoaWNoIGNhbiBiZSBpbW1l ZGlhdGVseSB1c2VkIGZvciBuZXR3b3JrIGF1dGhlbnRpY2F0aW9uLg0KDQpZb3UgYWRkIHRoYXQg 4oCcSW4gcmVzcG9uc2UgdG8gdGhlIGNoYWxsZW5nZXMgcmVsYXRlZCB0bw0KDQphbWJpZ3VpdHkg YmV0d2VlbiBpZGVudGl0aWVzIGlzc3VlZCBieSBkaWZmZXJlbnQgQ0FzLCBhcHBsaWNhdGlvbiBv d25lcnMNCg0KZnJlcXVlbnRseSBjaG9vc2UgdG8gb25ib2FyZCBJb1QgZGV2aWNlcyB0byBhIHNp bmdsZSBDQS7igJ0uIElzIHRoYXQgYSBnb29kIG9yIGEgYmFkIGRldmVsb3BtZW50Pw0KSXQgaXMg YSBnb29kIGRldmVsb3BtZW50IGlmIHRoZSBvcmdhbml6YXRpb24gcmVhbGx5IHdhbnRzIHRvIGRp cmVjdGx5IG1hbmFnZSBhbGwgb2YgdGhlIGNyZWRlbnRpYWxzIGZvciBhbGwgb2YgdGhlIGFwcGxp Y2F0aW9uIHBhcnRpY2lwYW50cy4gVGhlIGVmZm9ydCBhbmQgcmF0aW9uYWxlIGJlaGluZCBCUlNL SSAoUkZDIDg5OTUpIHN1Z2dlc3RzIGEgZGVzaXJlIHRvIG1ha2Ugb25ib2FyZGluZyB0byBvcmdh bml6YXRpb25hbCBQS0kgZWFzaWVyIHRvIGF1dG9tYXRlLg0KDQpJZiBhIHN1cHBsaWVyIGlzc3Vl cyBhIHRydXN0d29ydGh5IGlkZW50aXR5IGZvciBhIGRldmljZSwgYW5kIEROUyBwcmV2ZW50cyBh bm90aGVyIFBLSSBmcm9tIGlzc3Vpbmcgd29ya2luZyBjcmVkZW50aWFscyB1bmRlciB0aGUgc2Ft ZSBuYW1lLCB0aGVuIGlzc3VpbmcgYW5vdGhlciBpZGVudGl0eSB2aWEgb3JnYW5pemF0aW9uYWwg UEtJIGJlY29tZXMgc3VwZXJmbHVvdXMuIFRoaXMgaXMgd2hlcmUgd2UgdGhpbmsgdGhhdCB0aW1l IGFuZCBlZmZvcnQgY2FuIGJlIHNhdmVkLCBiZWNhdXNlIHRoZSBza2lsbHMgcmVxdWlyZWQgZm9y IG9uYm9hcmRpbmcgZG8gbm90IG5lZWQgdG8gaW5jbHVkZSB0aGUgbWFuYWdlbWVudCBhbmQgaXNz dWFuY2Ugb2YgaWRlbnRpdGllcyB1bmRlciBvcmdhbml6YXRpb25hbCBQS0kuDQoNCkFkIDI6IElz IGl0IHJlYWxseSB0cnVlIHRoYXQgY3JlZGVudGlhbCBpc3N1YW5jZSBpcyB0aW1lIGNvbnN1bWlu Zz8gV2h5IGlzIHRoYXQ/IEZvciB3aG9tIGlzIGl0IHRpbWUgY29uc3VtaW5nPw0KQ3JlZGVudGlh bCBpc3N1YW5jZSB2ZXJ5IG9mdGVuIHJlcXVpcmVzIHRoZSBkZXZpY2UgYW5kIHRoZSBwZXJzb24g Ym9vdHN0cmFwcGluZyB0aGUgaWRlbnRpdHkgdG8gYmUgaW4gdGhlIHNhbWUgcGxhY2UuIFNvbWUg cGxhdGZvcm1zIGFuZCBwcm90b2NvbHMgZXhpc3QgdG8gbWFrZSB0aGF0IHByb2Nlc3MgZWFzaWVy IChsaWtlIEJSU0tJKSBvciBsZXNzIGh1bWFuLWludm9sdmluZy4gVGhlIHRpbWUgaW52ZXN0bWVu dCBzZWVtcyB0byBiZSBvbiB0aGUgcGFydCBvZiBib3RoIHRoZSBtYW51ZmFjdHVyZXIgKGluIGlz c3VpbmcgdGhlIElEZXZJRCkgYXMgd2VsbCBhcyB0aGUgb3JnYW5pemF0aW9uYWwgSVQgc3RhZmYs IHdobyBtYW5hZ2UgdGhlIG9yZ2FuaXphdGlvbmFsIFBLSS4NCg0KQ2lhbw0KSGFubmVzDQoNClBT OiBZb3UgdXNlIHRoZSB0ZXJtIOKAnENlcnRpZmljYXRlIEF1dGhvcml0eSAoQ0Ep4oCdLiBJdCBp cyBhY3R1YWxseSBjYWxsZWQg4oCcQ2VydGlmaWNhdGlvbiBBdXRob3JpdHnigJ0uDQoNCg0KSU1Q T1JUQU5UIE5PVElDRTogVGhlIGNvbnRlbnRzIG9mIHRoaXMgZW1haWwgYW5kIGFueSBhdHRhY2ht ZW50cyBhcmUgY29uZmlkZW50aWFsIGFuZCBtYXkgYWxzbyBiZSBwcml2aWxlZ2VkLiBJZiB5b3Ug YXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIg aW1tZWRpYXRlbHkgYW5kIGRvIG5vdCBkaXNjbG9zZSB0aGUgY29udGVudHMgdG8gYW55IG90aGVy IHBlcnNvbiwgdXNlIGl0IGZvciBhbnkgcHVycG9zZSwgb3Igc3RvcmUgb3IgY29weSB0aGUgaW5m b3JtYXRpb24gaW4gYW55IG1lZGl1bS4gVGhhbmsgeW91Lg0KLS0NCkRhbmlzaCBtYWlsaW5nIGxp c3QNCkRhbmlzaEBpZXRmLm9yZzxtYWlsdG86RGFuaXNoQGlldGYub3JnPg0KaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kYW5pc2gNCg0KDQotLQ0KQXNoIFdpbHNvbiB8IFRl Y2huaWNhbCBEaXJlY3Rvcg0KZTogYXNoLndpbHNvbkB2YWxpbWFpbC5jb208bWFpbHRvOmFzaC53 aWxzb25AdmFsaW1haWwuY29tPg0KW2h0dHBzOi8vaG9zdGVkLXBhY2thZ2VzLnMzLXVzLXdlc3Qt MS5hbWF6b25hd3MuY29tL1ZhbGltYWlsK0xvZ28ucG5nXQ0KDQpUaGlzIGVtYWlsIGFuZCBhbGwg ZGF0YSB0cmFuc21pdHRlZCB3aXRoIGl0IGNvbnRhaW5zIGNvbmZpZGVudGlhbCBhbmQvb3IgcHJv cHJpZXRhcnkgaW5mb3JtYXRpb24gaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgdXNlIG9mIGluZGl2 aWR1YWwocykgYXV0aG9yaXplZCB0byByZWNlaXZlIGl0LiBJZiB5b3UgYXJlIG5vdCBhbiBpbnRl bmRlZCBhbmQgYXV0aG9yaXplZCByZWNpcGllbnQgeW91IGFyZSBoZXJlYnkgbm90aWZpZWQgb2Yg YW55IHVzZSwgZGlzY2xvc3VyZSwgY29weWluZyBvciBkaXN0cmlidXRpb24gb2YgdGhlIGluZm9y bWF0aW9uIGluY2x1ZGVkIGluIHRoaXMgdHJhbnNtaXNzaW9uIGlzIHByb2hpYml0ZWQgYW5kIG1h eSBiZSB1bmxhd2Z1bC4gUGxlYXNlIGltbWVkaWF0ZWx5IG5vdGlmeSB0aGUgc2VuZGVyIGJ5IHJl cGx5aW5nIHRvIHRoaXMgZW1haWwgYW5kIHRoZW4gZGVsZXRlIGl0IGZyb20geW91ciBzeXN0ZW0u DQpJTVBPUlRBTlQgTk9USUNFOiBUaGUgY29udGVudHMgb2YgdGhpcyBlbWFpbCBhbmQgYW55IGF0 dGFjaG1lbnRzIGFyZSBjb25maWRlbnRpYWwgYW5kIG1heSBhbHNvIGJlIHByaXZpbGVnZWQuIElm IHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBub3RpZnkgdGhlIHNl bmRlciBpbW1lZGlhdGVseSBhbmQgZG8gbm90IGRpc2Nsb3NlIHRoZSBjb250ZW50cyB0byBhbnkg b3RoZXIgcGVyc29uLCB1c2UgaXQgZm9yIGFueSBwdXJwb3NlLCBvciBzdG9yZSBvciBjb3B5IHRo ZSBpbmZvcm1hdGlvbiBpbiBhbnkgbWVkaXVtLiBUaGFuayB5b3UuDQoNCg0KLS0NCkFzaCBXaWxz b24gfCBUZWNobmljYWwgRGlyZWN0b3INCmU6IGFzaC53aWxzb25AdmFsaW1haWwuY29tPG1haWx0 bzphc2gud2lsc29uQHZhbGltYWlsLmNvbT4NCltodHRwczovL2hvc3RlZC1wYWNrYWdlcy5zMy11 cy13ZXN0LTEuYW1hem9uYXdzLmNvbS9WYWxpbWFpbCtMb2dvLnBuZ10NCg0KVGhpcyBlbWFpbCBh bmQgYWxsIGRhdGEgdHJhbnNtaXR0ZWQgd2l0aCBpdCBjb250YWlucyBjb25maWRlbnRpYWwgYW5k L29yIHByb3ByaWV0YXJ5IGluZm9ybWF0aW9uIGludGVuZGVkIHNvbGVseSBmb3IgdGhlIHVzZSBv ZiBpbmRpdmlkdWFsKHMpIGF1dGhvcml6ZWQgdG8gcmVjZWl2ZSBpdC4gSWYgeW91IGFyZSBub3Qg YW4gaW50ZW5kZWQgYW5kIGF1dGhvcml6ZWQgcmVjaXBpZW50IHlvdSBhcmUgaGVyZWJ5IG5vdGlm aWVkIG9mIGFueSB1c2UsIGRpc2Nsb3N1cmUsIGNvcHlpbmcgb3IgZGlzdHJpYnV0aW9uIG9mIHRo ZSBpbmZvcm1hdGlvbiBpbmNsdWRlZCBpbiB0aGlzIHRyYW5zbWlzc2lvbiBpcyBwcm9oaWJpdGVk IGFuZCBtYXkgYmUgdW5sYXdmdWwuIFBsZWFzZSBpbW1lZGlhdGVseSBub3RpZnkgdGhlIHNlbmRl ciBieSByZXBseWluZyB0byB0aGlzIGVtYWlsIGFuZCB0aGVuIGRlbGV0ZSBpdCBmcm9tIHlvdXIg c3lzdGVtLg0KDQpJTVBPUlRBTlQgTk9USUNFOiBUaGUgY29udGVudHMgb2YgdGhpcyBlbWFpbCBh bmQgYW55IGF0dGFjaG1lbnRzIGFyZSBjb25maWRlbnRpYWwgYW5kIG1heSBhbHNvIGJlIHByaXZp bGVnZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBub3Rp ZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBhbmQgZG8gbm90IGRpc2Nsb3NlIHRoZSBjb250ZW50 cyB0byBhbnkgb3RoZXIgcGVyc29uLCB1c2UgaXQgZm9yIGFueSBwdXJwb3NlLCBvciBzdG9yZSBv ciBjb3B5IHRoZSBpbmZvcm1hdGlvbiBpbiBhbnkgbWVkaXVtLiBUaGFuayB5b3UuDQo= --_000_DBBPR08MB5915C107E3620968DFE34D97FA0C9DBBPR08MB5915eurp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYg MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpEZW5nWGlhbjsNCglwYW5vc2UtMToy IDEgNiAwIDMgMSAxIDEgMSAxO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsN CglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30NCkBmb250LWZh Y2UNCgl7Zm9udC1mYW1pbHk6IlxARGVuZ1hpYW4iOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEg MSAxIDE7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3Jt YWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxp bmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0 aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHls ZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGluOw0KCWZvbnQtc2l6 ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpzcGFuLkhUTUxQcmVmb3Jt YXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCglt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVk IjsNCglmb250LWZhbWlseTpDb25zb2xhczt9DQpzcGFuLkVtYWlsU3R5bGUyMQ0KCXttc28tc3R5 bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJp ZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBl OmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdl IFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4g MS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQot LT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4 dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3Rl IG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpl eHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+ DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSIg c3R5bGU9IndvcmQtd3JhcDpicmVhay13b3JkIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSBBc2gsIDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5J ZiB0aGUgbmV0d29yayBhY2Nlc3MgYXV0aGVudGljYXRpb24gdXNlIGNhc2Ugd2l0aCBFQVAtVExT IGlzIGltcG9ydGFudCB0byB5b3UgdGhlbiBJIGJlbGlldmUgaXQgd291bGQgYmUgZ29vZCB0byBh ZGQgaXQgYXMgYSBtaWxlc3RvbmUgb24gdGhlIGNoYXJ0ZXIuIFlvdSBjYW5ub3QgdXNlIGFuIGlt cGxlbWVudGF0aW9uIG9mIGRyYWZ0LWlldGYtZW11LWVhcC10bHMxMyBhbmQgYXNzdW1lIGFueSBv ZiB0aGUgREFORQ0KIGZ1bmN0aW9uYWxpdHkgdG8gd29yay4gWW91IHdvdWxkIGluZGVlZCBoYXZl IHRvIHJlbHkgb24gZHJhZnQtaWV0Zi10bHMtZG5zc2VjLWNoYWluLWV4dGVuc2lvbiBiZWNhdXNl IG5vdCBoYXZpbmcgbmV0d29yayBjb25uZWN0aXZpdHkgaXMgdGhlIG1haW4gcmVhc29uIHdoeSB5 b3Ugd291bGQgYmUgcnVubmluZyB0aGUgRUFQLVRMUyBleGNoYW5nZSBpbiB0aGUgZmlyc3QgcGxh Y2UuDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UmVnYXJkaW5nIOKAnGJlc3QgcHJhY3RpY2Ug dG8gZW5zdXJlIHRoYXQgYSBkZXZpY2UgaXMgcGF0Y2hlZCBiZWZvcmUgcHV0dGluZyBpdCBpbnRv IHByb2R1Y3Rpb24sIGFuZCB1cGRhdGluZyByb290cyBvZiB0cnVzdCBmaXRzIHdpdGhpbiB0aGUg c2NvcGUgb2YgdGhhdCBzb3J0IG9mIGFjdGl2aXR54oCdOiBJIGRvbuKAmXQgdGhpbmsgdGhlcmUg aXMgYW55IGV4cGVjdGF0aW9uIHRoYXQgdGhlIGRldmljZSB3aWxsIGJlIHVwZGF0ZWQNCiBiZWZv cmUgaXQgaXMgcHV0IGluIHByb2R1Y3Rpb24gKGkuZS4gcG93ZXJlZCBvbiBmb3IgdGhlIGZpcnN0 IHRpbWUpLiBZb3UgY2FuIGFzc3VtZSB0aGF0IHRoZSBkZXZpY2UsIHdoZW4gaXQgY29tZXMgb25s aW5lIGZvciB0aGUgZmlyc3QgdGltZSBhbmQgcmVhY2hlcyBvdXQgdG8gdGhlIGRldmljZSBtYW5h Z2VtZW50IHNlcnZlciwgZ2V0cyBhIGZpcm13YXJlIHVwZGF0ZS4gSGF2aW5nIHRoYXQgZmlybXdh cmUgdXBkYXRlIGhhcHBlbiBiZWZvcmUNCiBpdCBpcyBjb25uZWN0ZWQgdG8gdGhlIG5ldHdvcmsg aXMgZXh0cmVtZWx5IHVubGlrZWx5LiA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RUFQLVRMUyBp cyBhbHNvIG5vdCBhbiBJb1QgZGV2aWNlIG9uYm9hcmRpbmcgcHJvdG9jb2wuIEZyb20gdGhlIGNo YXJ0ZXIgdGV4dCBJIGFtIGFsc28gbm90IGFzc3VtaW5nIHRoYXQgeW91IGFyZSBhdHRlbXB0aW5n IHRvIGRlZmluZSBhIG5ldyBJb1Qgb25ib2FyZGluZyBwcm90b2NvbCBvciBkbyB5b3U/DQo8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+UmVnYXJkaW5nIHRoZSBob21lIElvVCBlbnZpcm9ubWVudDog SSB3b3VsZCBub3QgY291bnQgb24gQ0hJUC9NYXR0ZXIgcmUtdXNpbmcgeW91ciB3b3JrLiBNeSB1 bmRlcnN0YW5kaW5nIGlzIHRoYXQgdGhleSBhcmUgY3JlYXRpbmcgdGhlaXIgb3duIHNvbHV0aW9u cy4gU2luY2UgdGhlIGhvbWUgZW52aXJvbm1lbnQgaXMgdmVyeSBmcmFnbWVudGVkLCBpdCBtaWdo dCBub3QgYmUgdGhlIGVhc2llc3QgcGxhY2UgdG8NCiBzdGFydC4gT2YgY291cnNlLCB5b3VyIGNv bXBhbnkgbWF5IHBsYXkgYW5kIHRoYXQgZmllbGQgYW5kIHNvIHlvdSBtaWdodCBoYXZlIGEgd2F5 IHRvIGdldCB0aGUgb3V0Y29tZSBvZiBEQU5JU0ggZGVwbG95ZWQgdGhlcmUuDQo8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+SSBhbSBzdGlsbCB0cnlpbmcgdG8gZmlndXJlIG91dCBob3cgREFOSVNI IGZpdHMgaW50byB0aGUgbGFyZ2VyIHBpY3R1cmUgYW5kIGhlbmNlIEkgYW0gbG9va2luZyBmb3J3 YXJkIHRvIHJlYWQgYW4gYXJjaGl0ZWN0dXJlIGRvY3VtZW50LiBJcyB0aGUgYSBwcmUtZHJhZnQg YXZhaWxhYmxlIGFscmVhZHk/PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkNpYW88bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhhbm5lczxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGlu IDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5Gcm9tOjwvYj4gQXNoIFdpbHNvbiAmbHQ7 YXNoLndpbHNvbkB2YWxpbWFpbC5jb20mZ3Q7IDxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwg SnVuZSAxNywgMjAyMSA4OjIyIFBNPGJyPg0KPGI+VG86PC9iPiBIYW5uZXMgVHNjaG9mZW5pZyAm bHQ7SGFubmVzLlRzY2hvZmVuaWdAYXJtLmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+IGRhbmlzaEBp ZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW0RhbmlzaF0gQ2hhcnRlciBUZXh0IGFu ZCB0aGUgUHJvYmxlbSBTdGF0ZW1lbnQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPkhpIEhhbm5lcyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkdyZWF0IHF1ZXN0aW9ucywgcmVzcG9uc2VzIGluLWxpbmUgYmVs b3cuLi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFdl ZCwgSnVuIDE2LCAyMDIxIGF0IDExOjQzIFBNIEhhbm5lcyBUc2Nob2ZlbmlnICZsdDs8YSBocmVm PSJtYWlsdG86SGFubmVzLlRzY2hvZmVuaWdAYXJtLmNvbSI+SGFubmVzLlRzY2hvZmVuaWdAYXJt LmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5n OjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlRoYW5rcyBmb3IgeW91ciBmZWVk YmFjaywgQXNoLg0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JdCBpcyBpbnRlcmVzdGlu ZyB0aGF0IHlvdSBtZW50aW9uIHRoZSBuZXR3b3JrIGFjY2VzcyBhdXRoZW50aWNhdGlvbiB1c2Ug Y2FzZS4gRG8geW91IGVudmlzaW9uIEVBUC1UTFMgaW4gY29tYmluYXRpb24gd2l0aCBEYW5pc2gg dG8gd29yayBhcmNoaXRlY3R1cmFsbHkgZGlmZmVyZW50bHkgdGhhbiB0aGUgY3VycmVudA0KIEVB UC1UTFMtYmFzZWQgYXBwcm9hY2g/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9i bG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2UgaG9wZSB0byBtaW5p bWl6ZSB0aGUmbmJzcDthbW91bnQgb2Ygd29yayByZXF1aXJlZCB0byBlbmFibGUgREFORSBjbGll bnQgSUQgZm9yIEVBUC1UTFMuIFNvbWUgY2hhbGxlbmdlcyByZW1haW4gd2l0aCBFQVAtVExTIGlu IGNvbmp1bmN0aW9uIHdpdGggVExTIDEuMzoNCjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtaWV0Zi1lbXUtZWFwLXRsczEzLTE2Ij5odHRwczovL2Rh dGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWlldGYtZW11LWVhcC10bHMxMy0xNjwv YT4uIFN1cHBvcnRpbmcgVExTIDEuMiBmb3IgRUFQLVRMUyBhbmQgREFORSB3b3VsZCBsaWtlbHkg YmUgbW9yZSBzdHJhaWdodGZvcndhcmQsIGJ1dCBJIGRvIG5vdCBrbm93IHdoZXRoZXIgdGhlcmUn cw0KIG11Y2ggaW50ZXJlc3QgaW4gdXBkYXRpbmcgVExTIDEuMiB0byBjb3ZlciB0aGlzIHVzZSBj YXNlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5EQU5FIHNlcnZlciBhdXRoZW50aWNhdGlvbiB3aXRoIEVBUC1UTFMgYnJpbmdzIGFub3RoZXIg Y2hhbGxlbmdlOiB0aGUgYWJzZW5jZSBvZiBJUCBjb25uZWN0aXZpdHkgcHJpb3IgdG8gYXV0aGVu dGljYXRpb24uIFRoaXMgY291bGQgYmUgcmVtZWRpZWQgYnkmbmJzcDs8YSBocmVmPSJodHRwczov L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWlldGYtdGxzLWRuc3NlYy1jaGFp bi1leHRlbnNpb24tMDciPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJh ZnQtaWV0Zi10bHMtZG5zc2VjLWNoYWluLWV4dGVuc2lvbi0wNzwvYT4sDQogaWYgdGhlIHdvcmsg b24gdGhhdCBkcmFmdCB3ZXJlIHRvIGNvbnRpbnVlLiBUaGVyZSBhcmUgYWxzbyBjaGFsbGVuZ2Vz IHdpdGggdmFsaWRhdGluZyB0aGUgY2hhaW4sIHRpZWQgdG8gcm9vdCBrZXkgcm90YXRpb24uIERl dmljZXMgd2hpY2ggcmVtYWluIHVucGx1Z2dlZCB0b28gbG9uZyBtYXkgbm90IGJlIGFibGUgdG8g YXV0aGVudGljYXRlLiBPbiB0aGUgb3RoZXIgaGFuZCwgaXQgaXMgYSBiZXN0IHByYWN0aWNlIHRv IGVuc3VyZSB0aGF0IGEgZGV2aWNlDQogaXMgcGF0Y2hlZCBiZWZvcmUgcHV0dGluZyBpdCBpbnRv IHByb2R1Y3Rpb24sIGFuZCB1cGRhdGluZyByb290cyBvZiB0cnVzdCBmaXRzIHdpdGhpbiB0aGUg c2NvcGUgb2YgdGhhdCBzb3J0IG9mIGFjdGl2aXR5LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JZiBvbmx5IERBTkUgZm9yIGNsaWVudCBhdXRo ZW50aWNhdGlvbiBpcyBzdXBwb3J0ZWQgaW4gRUFQLVRMUywgd2hpY2ggaXMgdGhlIGxpa2VseSBp bml0aWFsIG91dGNvbWUsIHRoZSBjaGFsbGVuZ2Ugb2YgZ2V0dGluZyB0aGUgYXV0aGVudGljYXRp b24gc2VydmVyJ3MgQ0EgY2VydGlmaWNhdGUgb250byB0aGUgZGV2aWNlIHN0aWxsIGV4aXN0cy4g VGhpcyBzdGlsbCByZXByZXNlbnRzIGEgcmVkdWN0aW9uIGluDQogZWZmb3J0IG9uIHRoZSBwYXJ0 IG9mIHRoZSBJVCBzdGFmZiwgYnV0IG5vdCBhIHBlcmZlY3QgemVyby10b3VjaCBvbmJvYXJkaW5n IHVubGVzcyB0aGUgc3VwcGxpZXIgYWxzbyBwcm92aXNpb25zIHRoZSBDQSBjZXJ0cyBmb3IgdGhl IGF1dGhlbnRpY2F0aW9uIHNlcnZlci4uLiBhbmQgaW4gdGhlIGNhc2Ugb2YgV2lGaSwgdGhlIFNT SUQgdG8gYXNzb2NpYXRlIHdpdGguIFN0aWxsLCB3ZSB0aGluayB0aGlzIHJlcHJlc2VudHMgYSBz dWJzdGFudGlhbA0KIGltcHJvdmVtZW50IGluIHRoZSBvbmJvYXJkaW5nIGV4cGVyaWVuY2UgZm9y IHRoZSZuYnNwO2ltcGxlbWVudGVyLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1 b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3Bh ZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBp biI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPllvdSB3cml0ZToNCjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj7igJxDcmVkZW50aWFsIGlzc3VhbmNlIHZlcnkgb2Z0 ZW4gcmVxdWlyZXMgdGhlIGRldmljZSBhbmQgdGhlIHBlcnNvbiBib290c3RyYXBwaW5nIHRoZSBp ZGVudGl0eSB0byBiZSBpbiB0aGUgc2FtZSBwbGFjZeKAnTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+QmluZGluZyB0aGUgdXNlciB0byBoaXMgb3IgaGVyIGRldmljZSB0eXBpY2FsbHkgdGFr ZXMgc29tZSB0aW1lLiBJdCBvZnRlbiByZXF1aXJlcyB0aGUgdXNlciB0byBsb2cgaW50byBzb21l IHNlcnZpY2UgYW5kIHRvIOKAnGFkZOKAnSB0aGUgbmV3IGRldmljZSBvZnRlbiBieSBkZW1vbnN0 cmF0aW5nIHBoeXNpY2FsDQogcG9zc2Vzc2lvbi4gT2YgY291cnNlLCB0aGlzIGlzIHRoZSB3YXkg aG93IGl0IHdvcmtzIGZvciBlbmQgY29uc3VtZXIgcHJvZHVjdHMsIHdoZXJlIHNjYWxhYmlsaXR5 IGlzIGxlc3Mgb2YgYW4gaXNzdWUgYmVjYXVzZSB5b3UgYXJlIHByb2JhYmx5IG5vdCBnb2luZyB0 byBidXkgdGhvdXNhbmRzIG9mIHNtYXJ0IGNvZmZlZSBtYWNoaW5lcy4gRm9yIGEgY29tbWVyY2lh bCBzZXR1cCwgdGhlIHByb2Nlc3Mgb2Z0ZW4gd29ya3MgZGlmZmVyZW50IGJ1dA0KIGl0IHZlcnkg bXVjaCBkZXBlbmRzIG9uIHRoZSB0eXBlIG9mIGluZHVzdHJ5IHZlcnRpY2FsIHlvdSBhcmUgaW4u IFRoZXJlIGlzIG9mdGVuIGEgbm9uLWlycmVsZXZhbnQgY29uZmlndXJhdGlvbiBzdGVwIGludm9s dmVkIGFzIHdlbGwuIEZvciBleGFtcGxlLCB3aXRoIGNvbW1lcmNpYWwgaW5kb29yIGxpZ2h0aW5n IHByb2Zlc3Npb25hbHMgbmVlZCB0byBjb25maWd1cmUgZGlmZmVyZW50IGxpZ2h0aW5nIHRoZW1l cy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkkgZG9u4oCZdCBzZWUgYW55IG9mIHRoaXMg dXNlci1yZWxhdGVkIGludGVyYWN0aW9uIGJlaW5nIGNvdmVyZWQgYXMgcGFydCBvZiB0aGUgY2hh cnRlcmVkIHdvcmsuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3Rl Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+REFORSBjYW4gYmUgdXNlZnVsIGZvciBo b21lIElvVC4gSSB0aGluayB0aGF0IGl0IGNvdWxkIHJlZHVjZSB0aGUgY29tcGxleGl0eSBvZiBh dXRvbWF0aW9uIHdoZXJldmVyIHByaXZhdGUgUEtJIGlzIGJlaW5nIG1hbmFnZWQgaW4gdGhlIGNv bnN1bWVyJ3MgZW52aXJvbm1lbnQsIGFuZCBhY2NlbGVyYXRlIGFuZCBzaW1wbGlmeSB0aGUgb25i b2FyZGluZyBleHBlcmllbmNlLiBJRVRGIGlzIGFjY2Vzc2libGUgYW5kDQogd2lkZS1yZWFjaGlu ZywgYW5kIHNlZW1zIGxpa2UgdGhlIHJpZ2h0IHBsYWNlIHRvIHByZXNlbnQgYW5kIHJlZmluZSB0 aGUgZGVzaWduIHBhdHRlcm4gdGhhdCBtaWdodCBiZSBhZG9wdGVkIGxhdGVyIGJ5IG90aGVyIHN0 YW5kYXJkcyAobGlrZSBDSElQL01hdHRlcikuIEknbSBhbHNvIG9wZXJhdGluZyB1bmRlciB0aGUg YXNzdW1wdGlvbiB0aGF0IGVudGVycHJpc2UgSW9UIGhhcyBhIG1vcmUgcmVjb2duaXplZCBuZWVk IGZvciBpbnRlcm9wZXJhYmlsaXR5DQogYW5kIHNpbXBsZXIgc2VjdXJlJm5ic3A7b25ib2FyZGlu ZyBwcm9jZXNzZXMuIFRoYXQgaXMgYSBiaWcgYXNzdW1wdGlvbiwgYW5kIG9ubHkgYmFzZWQgb24g bXkgb2JzZXJ2YXRpb25zIHRodXMgZmFyLiBJJ20gb3BlbiB0byBpbmNsdWRpbmcgdGhlIGhvbWUg Y29uc3VtZXIncyBwZXJzcGVjdGl2ZSBpbiB0aGlzIGVmZm9ydCwgaWYgeW91IHRoaW5rIGl0J3Mg d29ydGh3aGlsZS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BcyBm YXIgYXMgZGVzY3JpYmluZyB0aGUgZ2VuZXJhbCBvbmJvYXJkaW5nIGV4cGVyaWVuY2UgZm9yIHRo ZSBpbXBsZW1lbnRlciwgSSBoYWQgaG9wZWQgdG8gaW5jbHVkZSB0aGF0IGluIHRoZSBhcmNoaXRl Y3R1cmUgZG9jdW1lbnQgYWxvbmcgd2l0aCBleGFtcGxlcyBvZiBob3cgREFORSBtaWdodCBpbnRl cmZhY2Ugd2l0aCBhbmQgc3VwcG9ydCBvdGhlciBzdGFuZGFyZHMgaW4gdGhlIGJyb2FkZXIgZWNv c3lzdGVtLg0KIEluIHRyeWluZyB0byBrZWVwIHRoZSBjaGFydGVyIGNvbmNpc2UsIEkgdGhpbmsg d2UgbGVmdCBvdXQgc29tZSBpbXBvcnRhbnQgaW5mb3JtYXRpb24uPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPllvdSBicmluZyB1cCBhbiBpbnRl cmVzdGluZyBwb2ludCwgd2l0aCB0aGUgY29uZmlndXJhdGlvbiBvZiBsaWdodGluZyBwcm9maWxl cyBkdXJpbmcgZml4dHVyZSBpbnN0YWxsYXRpb24uIFRoZSBleHBlY3RhdGlvbiBpcyB0aGF0IHdp dGggREFORSBhcyB0aGUgYXV0aGVudGljYXRpb24gcHJvdG9jb2wsIHRoZSB2YXJpZXR5IG9mIHN1 cHBsaWVycyBwcm9kdWNpbmcgZGV2aWNlcyBmb3IgYSBnaXZlbiBhcHBsaWNhdGlvbg0KIG1pZ2h0 IGJlIGFibGUgdG8gYWdyZWUgb24gYSBmb3JtYXQgZm9yIHJlcHJlc2VudGluZyBjb25maWd1cmF0 aW9uIGluZm9ybWF0aW9uLCBhbmQgZGV2aWNlcyBjYW4gc2VjdXJlbHkgcmV0cmlldmUgaXQgZnJv bSB0aGUgc3lzdGVtIHRoYXQgbWFuYWdlcyZuYnNwO3RoZSBhcHBsaWNhdGlvbidzIGNvbmZpZ3Vy YXRpb24uIEkgdGhpbmsgdGhhdCBpdCB3b3VsZCBiZSBlc3BlY2lhbGx5IHVzZWZ1bCB0byBzaG93 IGhvdyBEQU5FIHdvcmtzIHdpdGggb3RoZXIgZGlzY292ZXJ5DQogcHJvdG9jb2xzIChtRE5TLCBm b3IgaW5zdGFuY2UpIGluIHRoZSBwcm9jZXNzIG9mIHJldHJpZXZpbmcgdGhlIGRldmljZSdzIGNv bmZpZ3VyYXRpb24uIFdoZXJlIGRvIHlvdSB0aGluayB0aGlzIGZpdHMgYmVzdD8gSW4gdGhlIGFy Y2hpdGVjdHVyZSBkb2N1bWVudCwgb3Igd291bGQgYW5vdGhlciBmb3JtYXQgYmUgYSBiZXR0ZXIg Zml0IGZvciB0aGlzPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGlu IDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPkNpYW88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+SGFubmVzPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpz b2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48Yj5Gcm9tOjwvYj4gQXNoIFdpbHNvbiAmbHQ7PGEgaHJlZj0ibWFpbHRv OmFzaC53aWxzb25AdmFsaW1haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+YXNoLndpbHNvbkB2YWxp bWFpbC5jb208L2E+Jmd0Ow0KPGJyPg0KPGI+U2VudDo8L2I+IFdlZG5lc2RheSwgSnVuZSAxNiwg MjAyMSAxMToyOCBQTTxicj4NCjxiPlRvOjwvYj4gSGFubmVzIFRzY2hvZmVuaWcgJmx0OzxhIGhy ZWY9Im1haWx0bzpIYW5uZXMuVHNjaG9mZW5pZ0Bhcm0uY29tIiB0YXJnZXQ9Il9ibGFuayI+SGFu bmVzLlRzY2hvZmVuaWdAYXJtLmNvbTwvYT4mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiA8YSBocmVmPSJt YWlsdG86ZGFuaXNoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+ZGFuaXNoQGlldGYub3JnPC9h Pjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW0RhbmlzaF0gQ2hhcnRlciBUZXh0IGFuZCB0aGUg UHJvYmxlbSBTdGF0ZW1lbnQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj5IaSBIYW5uZXMsPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj5UaGFua3MgZm9yIHRoZSBxdWVzdGlvbnMsIGFuZCBhcG9sb2dpZXMgZm9yIGtl ZXBpbmcgeW91IHdhaXRpbmcgb24gYW5zd2Vycy9jbGFyaWZpY2F0aW9uLjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+T24gV2VkLCBKdW4g MTYsIDIwMjEgYXQgNDoxMiBBTSBIYW5uZXMgVHNjaG9mZW5pZyAmbHQ7PGEgaHJlZj0ibWFpbHRv Okhhbm5lcy5Uc2Nob2ZlbmlnQGFybS5jb20iIHRhcmdldD0iX2JsYW5rIj5IYW5uZXMuVHNjaG9m ZW5pZ0Bhcm0uY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9j a3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0 O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1 LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5IaSBhbGwsDQo8L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5JIGhhdmUg YmVlbiByZWFkaW5nIHRocm91Z2ggdGhlIGNoYXJ0ZXIgdGV4dCBpbiBhbiBhdHRlbXB0IHRvIHVu ZGVyc3RhbmQgdGhlIHByb2JsZW0gc3RhdGVtZW50Lg0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+VHdvIHByb2JsZW1zIGFyZSBt ZW50aW9uZWQ6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjEpPC9z cGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMg TmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj4mbmJzcDsNCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Q2hhbGxlbmdl cyB3aXRoIG5hbWluZyBjb2xsaXNpb25zIGluIHRoZSBJb1Qgc3BhY2UuPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7Ij4yKTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+Jm5ic3A7DQo8L3NwYW4+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDsiPkNyZWRlbnRpYWwgaXNzdWFuY2UgaXMgdGltZSBjb25zdW1pbmcuPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHByZT5BZCAxOiBSZWFkaW5nIHRocm91Z2ggdGhlIHRleHQgaXQgZmVl bHMgbGlrZSBuYW1pbmcgY29sbGlzaW9ucyBhcmUgYSBiaWcgdGhpbmcgaW4gSW9ULiBJIGhhdmUg bm90IGhlYXJkIGFib3V0IHRob3NlIHByb2JsZW1zLiBDb3VsZCB5b3UgZWxhYm9yYXRlPyA8bzpw PjwvbzpwPjwvcHJlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPkNlcnRhaW5seS4gSSdsbCB1c2UgYSBob3NwaXRhbCBhcyBhbiBl eGFtcGxlIGVudmlyb25tZW50LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+V2l0aGluIGEgaG9zcGl0YWwsIGl0IGlzIGRlc2lyYWJsZSB0 byBpbXBsZW1lbnQgODAyLjF4IGF1dGhlbnRpY2F0aW9uIHVzaW5nIEVBUC1UTFMgZm9yIGFjY2Vz cyB0byBwcm90ZWN0ZWQgbmV0d29ya3MuIEVBUC1UTFMgZW5hYmxlcyB0aGUgdXNlIG9mIFBLSS1i YXNlZCBpZGVudGl0eSB0byZuYnNwO2F1dGhlbnRpY2F0ZQ0KIGFuIGVudGl0eSBmb3IgbmV0d29y ayBhY2Nlc3MuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj5XaGVuIGltcGxlbWVudGluZyBFQVAtVExTIGZvciBuZXR3b3JrIGFjY2Vzcywg UkFESVVTIGlzIGEgY29tbW9uIHByb3RvY29sL3NlcnZlciB1c2VkIGZvciBhdXRoZW50aWNhdGlv biBiZWhpbmQgdGhlIHN3aXRjaCBvciB3aXJlbGVzcyBhY2Nlc3MgcG9pbnQuIEd1aWRhbmNlIGZv ciBjb25maWd1cmluZyBSQURJVVMNCiByZWNvbW1lbmRzIHRoZSB1c2Ugb2Ygb25seSBvbmUgQ0Eg Y2VydGlmaWNhdGUgZm9yIGF1dGhlbnRpY2F0aW5nIHN1cHBsaWNhbnQmbmJzcDtjZXJ0aWZpY2F0 ZXMuIFRoaXMgZ3VpZGFuY2UgY2FuIGJlIGZvdW5kIGluIHRoZSB3aWxkIGluIEZyZWVyYWRpdXMg Y29uZmlndXJhdGlvbiBmaWxlcyBmb3IgRUFQLVRMUywgcmVsYXRlZCB0byB0aGUgJ2NhX2ZpbGUn IGNvbmZpZ3VyYXRpb24gZGlyZWN0aXZlLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Q0FzIGd1YXJhbnRlZSB0aGUgdW5pcXVl bmVzcyBvZiBhbiBlbnRpdHkncyBuYW1lIHdpdGhpbiB0aGUgc2NvcGUgb2YgdGhlIENBLCBidXQg aGF2ZSBubyBtZXRob2QgZm9yIGVuZm9yY2luZyBuYW1lIHVuaXF1ZW5lc3MgYWNyb3NzIG90aGVy Jm5ic3A7Q0FzLiBGb3IgaW5zdGFuY2UsIENBMSBhbmQgQ0EyIG1heSBib3RoDQogc2lnbiBjZXJ0 aWZpY2F0ZXMmbmJzcDtmb3IgZW50aXRpZXMgd2l0aCB0aGUgc2FtZSBuYW1lLiBJZiBDQTEgYW5k IENBMiBhcmUgYm90aCB0cnVzdGVkIGJ5IHRoZSBSQURJVVMgc2VydmVyLCBhbmQgdHdvIGVudGl0 aWVzIG5hbWVkICZxdW90O21lZGljYWxkZXZpY2UxMjMmcXVvdDsgZXhpc3QsIG9uZSBwZXIgQ0Es IHRoZW4gdGhlIHJlc3VsdGluZyBhbWJpZ3VpdHkgbWFrZXMgaXQgZGlmZmljdWx0IHRvIGFwcHJv cHJpYXRlbHkgYXBwbHkgYWNjZXNzIGNvbnRyb2xzLiBUaGlzDQogYW1iaWd1aXR5IGlzJm5ic3A7 bWl0aWdhdGVkIGJ5IG9wZXJhdGluZyBhIHNpbmdsZSBvcmdhbml6YXRpb25hbCBQS0ksIGFuZCBy ZXF1aXJpbmcgaWRlbnRpdGllcyBpc3N1ZWQgYnkgdGhhdCBzaW5nbGUgb3JnYW5pemF0aW9uYWwg UEtJIGZvciBFQVAtVExTIGF1dGhlbnRpY2F0aW9uLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+T25ib2FyZGluZyBkZXZpY2Vz IHRvIG9yZ2FuaXphdGlvbmFsIFBLSSByZXF1aXJlcyB0aW1lIGFuZCBlZmZvcnQuIE9mdGVudGlt ZXMgc29tZSBzb3J0IG9mIHNraWxsZWQgbGFib3IgYW5kL29yIGRlZGljYXRlZCBpbmZyYXN0cnVj dHVyZSBmb3IgYXV0b21hdGluZyB0aGUgb25ib2FyZGluZyBwcm9jZXNzIGlzDQogaW52b2x2ZWQu IERBTkUgYWxsb3dzIHVzIHRvIGJpbmQgYSBETlMgbmFtZSB0byBhIHB1YmxpYyBrZXksIGFuZCBt aXRpZ2F0ZXMgdGhlIGFtYmlndWl0aWVzIGludHJvZHVjZWQgYnkgdGhlIHVzZSBvZiBtdWx0aXBs ZSBDQXMuIEFuIG9yZ2FuaXphdGlvbiBjYW4gb25seSBpc3N1ZSB3b3JraW5nIGlkZW50aXRpZXMg d2l0aGluIGl0cyBvd24gbmFtZXNwYWNlIGluIEROUy4gU2luY2UgbmFtaW5nIGFtYmlndWl0eSBj YW4gYmUgbWl0aWdhdGVkIHVzaW5nDQogREFORSwgd2UgbWF5IG5vdyBjaG9vc2UgdG8gdXNlIG1h bnVmYWN0dXJlci1pc3N1ZWQgUEtJLCByZXByZXNlbnRlZCBpbiBETlMsIGZvciBhdXRoZW50aWNh dGluZyBlbnRpdGllcy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPkZyb20gdGhlIGhvc3BpdGFsJ3Mgc3RhbmRwb2ludCwgdGhlIElUIHN0 YWZmIG5vIGxvbmdlciBuZWVkcyB0byBtYW5hZ2UgdGhlIHByb2Nlc3Mgb2Ygb25ib2FyZGluZyBk ZXZpY2VzIHRvIG9yZ2FuaXphdGlvbmFsIFBLSS4gVGhlIGRldmljZSBhcnJpdmVzIG9uLXNpdGUg d2l0aCBhbiBpZGVudGl0eSB3aGljaA0KIGNhbiBiZSBpbW1lZGlhdGVseSB1c2VkIGZvciBuZXR3 b3JrJm5ic3A7YXV0aGVudGljYXRpb24uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1 b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3Bh ZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBw dDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8 cHJlPllvdSBhZGQgdGhhdCDigJxJbiByZXNwb25zZSB0byB0aGUgY2hhbGxlbmdlcyByZWxhdGVk IHRvPG86cD48L286cD48L3ByZT4NCjxwcmU+YW1iaWd1aXR5IGJldHdlZW4gaWRlbnRpdGllcyBp c3N1ZWQgYnkgZGlmZmVyZW50IENBcywgYXBwbGljYXRpb24gb3duZXJzPG86cD48L286cD48L3By ZT4NCjxwcmU+ZnJlcXVlbnRseSBjaG9vc2UgdG8gb25ib2FyZCBJb1QgZGV2aWNlcyB0byBhIHNp bmdsZSBDQS7igJ0uIElzIHRoYXQgYSBnb29kIG9yIGEgYmFkIGRldmVsb3BtZW50PyZuYnNwOzxv OnA+PC9vOnA+PC9wcmU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+SXQgaXMgYSBnb29kIGRldmVsb3BtZW50IGlmIHRoZSBvcmdh bml6YXRpb24gcmVhbGx5IHdhbnRzIHRvIGRpcmVjdGx5IG1hbmFnZSBhbGwgb2YgdGhlIGNyZWRl bnRpYWxzIGZvciBhbGwgb2YgdGhlIGFwcGxpY2F0aW9uIHBhcnRpY2lwYW50cy4gVGhlIGVmZm9y dCBhbmQgcmF0aW9uYWxlIGJlaGluZCBCUlNLSQ0KIChSRkMgODk5NSkgc3VnZ2VzdHMgYSBkZXNp cmUgdG8gbWFrZSBvbmJvYXJkaW5nIHRvIG9yZ2FuaXphdGlvbmFsIFBLSSBlYXNpZXIgdG8gYXV0 b21hdGUuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj5JZiBhIHN1cHBsaWVyIGlzc3VlcyBhIHRydXN0d29ydGh5IGlkZW50aXR5 IGZvciBhIGRldmljZSwgYW5kIEROUyBwcmV2ZW50cyBhbm90aGVyIFBLSSBmcm9tIGlzc3Vpbmcg d29ya2luZyBjcmVkZW50aWFscyB1bmRlciB0aGUgc2FtZSBuYW1lLCB0aGVuIGlzc3VpbmcgYW5v dGhlciBpZGVudGl0eSB2aWEgb3JnYW5pemF0aW9uYWwNCiBQS0kgYmVjb21lcyBzdXBlcmZsdW91 cy4gVGhpcyBpcyB3aGVyZSB3ZSB0aGluayB0aGF0IHRpbWUgYW5kIGVmZm9ydCBjYW4gYmUgc2F2 ZWQsIGJlY2F1c2UgdGhlIHNraWxscyByZXF1aXJlZCBmb3Igb25ib2FyZGluZyBkbyBub3QgbmVl ZCB0byBpbmNsdWRlIHRoZSBtYW5hZ2VtZW50IGFuZCBpc3N1YW5jZSBvZiBpZGVudGl0aWVzIHVu ZGVyIG9yZ2FuaXphdGlvbmFsIFBLSS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVv dGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFk ZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0 O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPkFkIDI6IElzIGl0IHJlYWxseSB0 cnVlIHRoYXQgY3JlZGVudGlhbCBpc3N1YW5jZSBpcyB0aW1lIGNvbnN1bWluZz8gV2h5IGlzIHRo YXQ/IEZvciB3aG9tIGlzIGl0IHRpbWUgY29uc3VtaW5nPzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj5DcmVkZW50aWFsIGlzc3VhbmNlIHZlcnkgb2Z0ZW4gcmVxdWlyZXMgdGhlIGRldmljZSBh bmQgdGhlIHBlcnNvbiBib290c3RyYXBwaW5nIHRoZSBpZGVudGl0eSB0byBiZSBpbiB0aGUgc2Ft ZSBwbGFjZS4gU29tZSBwbGF0Zm9ybXMgYW5kIHByb3RvY29scyBleGlzdCB0byBtYWtlIHRoYXQg cHJvY2VzcyBlYXNpZXINCiAobGlrZSBCUlNLSSkgb3IgbGVzcyBodW1hbi1pbnZvbHZpbmcuIFRo ZSB0aW1lIGludmVzdG1lbnQgc2VlbXMgdG8gYmUgb24gdGhlIHBhcnQgb2YgYm90aCB0aGUgbWFu dWZhY3R1cmVyIChpbiBpc3N1aW5nIHRoZSBJRGV2SUQpIGFzIHdlbGwgYXMgdGhlIG9yZ2FuaXph dGlvbmFsIElUIHN0YWZmLCB3aG8gbWFuYWdlIHRoZSBvcmdhbml6YXRpb25hbCBQS0kuJm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7 bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdp bi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7Ij5DaWFvPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90OyI+SGFubmVzPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+UFM6IFlvdSB1c2UgdGhlIHRlcm0g4oCcQ2Vy dGlmaWNhdGUgQXV0aG9yaXR5IChDQSnigJ0uIEl0IGlzIGFjdHVhbGx5IGNhbGxlZCDigJxDZXJ0 aWZpY2F0aW9uIEF1dGhvcml0eeKAnS48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SU1QT1JUQU5UIE5PVElDRTogVGhlIGNv bnRlbnRzIG9mIHRoaXMgZW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBhcmUgY29uZmlkZW50aWFs IGFuZCBtYXkgYWxzbyBiZSBwcml2aWxlZ2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQg cmVjaXBpZW50LCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkNCiBhbmQgZG8g bm90IGRpc2Nsb3NlIHRoZSBjb250ZW50cyB0byBhbnkgb3RoZXIgcGVyc29uLCB1c2UgaXQgZm9y IGFueSBwdXJwb3NlLCBvciBzdG9yZSBvciBjb3B5IHRoZSBpbmZvcm1hdGlvbiBpbiBhbnkgbWVk aXVtLiBUaGFuayB5b3UuDQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj4tLQ0KPGJyPg0KRGFuaXNoIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0 bzpEYW5pc2hAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5EYW5pc2hAaWV0Zi5vcmc8L2E+PGJy Pg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kYW5pc2gi IHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Rh bmlzaDwvYT48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48YnIgY2xlYXI9ImFsbCI+DQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPi0tDQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPkFzaCBXaWxzb248L3NwYW4+PC9iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNh bnMtc2VyaWYiPiB8IFRlY2huaWNhbCBEaXJlY3Rvcjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+ZTo8L3NwYW4+PC9iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNh bnMtc2VyaWYiPg0KPGEgaHJlZj0ibWFpbHRvOmFzaC53aWxzb25AdmFsaW1haWwuY29tIiB0YXJn ZXQ9Il9ibGFuayI+YXNoLndpbHNvbkB2YWxpbWFpbC5jb208L2E+DQo8L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPjxpbWcgYm9yZGVy PSIwIiB3aWR0aD0iMTc1IiBoZWlnaHQ9IjQzIiBzdHlsZT0id2lkdGg6MS44MjVpbjtoZWlnaHQ6 LjQ1aW4iIGlkPSJfeDAwMDBfaTEwMjYiIHNyYz0iaHR0cHM6Ly9ob3N0ZWQtcGFja2FnZXMuczMt dXMtd2VzdC0xLmFtYXpvbmF3cy5jb20vVmFsaW1haWwrTG9nby5wbmciPjwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGluO2JhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojNjY2NjY2Ij5UaGlzIGVtYWlsIGFuZCBhbGwgZGF0YSB0cmFuc21pdHRlZCB3 aXRoIGl0IGNvbnRhaW5zIGNvbmZpZGVudGlhbCBhbmQvb3IgcHJvcHJpZXRhcnkgaW5mb3JtYXRp b24gaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgdXNlIG9mIGluZGl2aWR1YWwocykgYXV0aG9yaXpl ZA0KIHRvIHJlY2VpdmUgaXQuIElmIHlvdSBhcmUgbm90IGFuIGludGVuZGVkIGFuZCBhdXRob3Jp emVkIHJlY2lwaWVudCB5b3UgYXJlIGhlcmVieSBub3RpZmllZCBvZiBhbnkgdXNlLCBkaXNjbG9z dXJlLCBjb3B5aW5nIG9yIGRpc3RyaWJ1dGlvbiBvZiB0aGUgaW5mb3JtYXRpb24gaW5jbHVkZWQg aW4gdGhpcyB0cmFuc21pc3Npb24gaXMgcHJvaGliaXRlZCBhbmQgbWF5IGJlIHVubGF3ZnVsLiBQ bGVhc2UgaW1tZWRpYXRlbHkgbm90aWZ5IHRoZSBzZW5kZXINCiBieSByZXBseWluZyB0byB0aGlz IGVtYWlsIGFuZCB0aGVuIGRlbGV0ZSBpdCBmcm9tIHlvdXIgc3lzdGVtLjwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPklN UE9SVEFOVCBOT1RJQ0U6IFRoZSBjb250ZW50cyBvZiB0aGlzIGVtYWlsIGFuZCBhbnkgYXR0YWNo bWVudHMgYXJlIGNvbmZpZGVudGlhbCBhbmQgbWF5IGFsc28gYmUgcHJpdmlsZWdlZC4gSWYgeW91 IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVy IGltbWVkaWF0ZWx5IGFuZCBkbyBub3QgZGlzY2xvc2UgdGhlIGNvbnRlbnRzIHRvIGFueSBvdGhl ciBwZXJzb24sDQogdXNlIGl0IGZvciBhbnkgcHVycG9zZSwgb3Igc3RvcmUgb3IgY29weSB0aGUg aW5mb3JtYXRpb24gaW4gYW55IG1lZGl1bS4gVGhhbmsgeW91Lg0KPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyIGNs ZWFyPSJhbGwiPg0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0tIDxv OnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2Vy aWYiPkFzaCBXaWxzb248L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPiB8IFRlY2huaWNhbCBEaXJl Y3Rvcjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNh bnMtc2VyaWYiPmU6PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250 LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj4NCjxhIGhyZWY9Im1haWx0bzph c2gud2lsc29uQHZhbGltYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmFzaC53aWxzb25AdmFsaW1h aWwuY29tPC9hPg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv dDssc2Fucy1zZXJpZiI+PGltZyBib3JkZXI9IjAiIHdpZHRoPSIxNzUiIGhlaWdodD0iNDMiIHN0 eWxlPSJ3aWR0aDoxLjgyNWluO2hlaWdodDouNDVpbiIgaWQ9Il94MDAwMF9pMTAyNSIgc3JjPSJo dHRwczovL2hvc3RlZC1wYWNrYWdlcy5zMy11cy13ZXN0LTEuYW1hem9uYXdzLmNvbS9WYWxpbWFp bCtMb2dvLnBuZyI+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIHN0eWxlPSJtYXJnaW46MGluO2JhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojNjY2NjY2Ij5UaGlzIGVtYWlsIGFuZCBhbGwgZGF0YSB0cmFuc21pdHRlZCB3aXRoIGl0IGNv bnRhaW5zIGNvbmZpZGVudGlhbCBhbmQvb3IgcHJvcHJpZXRhcnkgaW5mb3JtYXRpb24gaW50ZW5k ZWQgc29sZWx5IGZvciB0aGUgdXNlIG9mIGluZGl2aWR1YWwocykgYXV0aG9yaXplZA0KIHRvIHJl Y2VpdmUgaXQuIElmIHlvdSBhcmUgbm90IGFuIGludGVuZGVkIGFuZCBhdXRob3JpemVkIHJlY2lw aWVudCB5b3UgYXJlIGhlcmVieSBub3RpZmllZCBvZiBhbnkgdXNlLCBkaXNjbG9zdXJlLCBjb3B5 aW5nIG9yIGRpc3RyaWJ1dGlvbiBvZiB0aGUgaW5mb3JtYXRpb24gaW5jbHVkZWQgaW4gdGhpcyB0 cmFuc21pc3Npb24gaXMgcHJvaGliaXRlZCBhbmQgbWF5IGJlIHVubGF3ZnVsLiBQbGVhc2UgaW1t ZWRpYXRlbHkgbm90aWZ5IHRoZSBzZW5kZXINCiBieSByZXBseWluZyB0byB0aGlzIGVtYWlsIGFu ZCB0aGVuIGRlbGV0ZSBpdCBmcm9tIHlvdXIgc3lzdGVtLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCklNUE9SVEFOVCBOT1RJQ0U6IFRoZSBjb250ZW50cyBv ZiB0aGlzIGVtYWlsIGFuZCBhbnkgYXR0YWNobWVudHMgYXJlIGNvbmZpZGVudGlhbCBhbmQgbWF5 IGFsc28gYmUgcHJpdmlsZWdlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVu dCwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGFuZCBkbyBub3QgZGlzY2xv c2UgdGhlIGNvbnRlbnRzIHRvIGFueSBvdGhlciBwZXJzb24sIHVzZSBpdCBmb3IgYW55IHB1cnBv c2UsDQogb3Igc3RvcmUgb3IgY29weSB0aGUgaW5mb3JtYXRpb24gaW4gYW55IG1lZGl1bS4gVGhh bmsgeW91Lg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_DBBPR08MB5915C107E3620968DFE34D97FA0C9DBBPR08MB5915eurp_-- From nobody Sat Jun 19 05:51:33 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 6AD983A0D20 for ; Sat, 19 Jun 2021 05:51:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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=armh.onmicrosoft.com header.b=DlJIw6BD; dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=DlJIw6BD 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 LxXLg_tDKR1i for ; Sat, 19 Jun 2021 05:51:28 -0700 (PDT) Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05on2061.outbound.protection.outlook.com [40.107.20.61]) (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 6CDE93A0D1E for ; Sat, 19 Jun 2021 05:51:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=q3KUTT5qO3WroS6BMkJyRe0NuyD+ck76vWgvvLGp+k0=; b=DlJIw6BDZJG1j7WJGCdhULGTPT06cfxCZOyA91zwS+R/TspXWUH3DPVPUvZs1XrH+D6Qm8Bo1Dm1hBvwV+1xWmWabWx6YX+nmgj9FKquPXnxS0u8EOizz80z1Uu9xghDLLceHQWJVamaMRB9OvUHDFPCoVuHGXSQiH+aceswbVI= Received: from PR0P264CA0230.FRAP264.PROD.OUTLOOK.COM (2603:10a6:100:1e::26) by VI1PR08MB5392.eurprd08.prod.outlook.com (2603:10a6:803:131::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4242.18; Sat, 19 Jun 2021 12:51:24 +0000 Received: from VE1EUR03FT056.eop-EUR03.prod.protection.outlook.com (2603:10a6:100:1e:cafe::89) by PR0P264CA0230.outlook.office365.com (2603:10a6:100:1e::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4242.18 via Frontend Transport; Sat, 19 Jun 2021 12:51:24 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; ietf.org; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com;ietf.org; dmarc=pass action=none header.from=arm.com; Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 63.35.35.123 as permitted sender) receiver=protection.outlook.com; client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com; Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by VE1EUR03FT056.mail.protection.outlook.com (10.152.19.28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4242.16 via Frontend Transport; Sat, 19 Jun 2021 12:51:23 +0000 Received: ("Tessian outbound f945d55369ce:v96"); Sat, 19 Jun 2021 12:51:22 +0000 X-CR-MTA-TID: 64aa7808 Received: from a76260b396c3.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id E4C04E5F-2CE9-410A-97A4-D2BF58D84D00.1; Sat, 19 Jun 2021 12:51:17 +0000 Received: from EUR05-VI1-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id a76260b396c3.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Sat, 19 Jun 2021 12:51:17 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=b8+vbxDenuhtZYN1r6RFqCRQaLinCuJIGlo5lpOlGr1SEmTnSuYTfkLNjuyE+4otGxDo6Y1C1m1TzyvEQcQUwfPYb+JQ9Vt4m2+CLf2m9a3osZE0bF/U8mQqUi67VS4D8N0EgTlWKtlkViIiptqo5OijAVwQaIRLpFei2YHS9uiA9B8M4Uv4wgqJ3asTxgtnnXbWNmE942tiGqW7+NBQ/DDWIJTK97HlQ6rXc5CE+XWfzmC8XjhK+Cbo+uPDUIm3HZXGfH1igPg5M7Rz2T8Dgf/D02z559uVPRPy+AWtQaOj1/WStxcGhoUm/PZTERMwfrcpiuJLJQ05E7C5gFt3gg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=q3KUTT5qO3WroS6BMkJyRe0NuyD+ck76vWgvvLGp+k0=; b=DBVI+AV2Mk3+BZ0HYEECF3CvHSfyEmho0Xkn3psm3Ejywzm73jTyFz+V5xSZmvSO2Cg8ho7BrXqUTJ2dltXo40DDQ4hHo/El7+DdrKWhZBE8+l7Wn5vGT9D1VYFCkzQ8PZ2HXTAOlSlhwA+UmJTbs8wdr0f0sYzKI7YZwd0WeSNUMxovaTLU+q3RNKrYUFjztm2CfBsI6GJuf4VLx/bTTeKa4/nW9jCetfvvCklLOEiXP52w/M5VPtMpA9GGrAJm7aTfH5HwFS6nGM03tNwcWjXCNfCnrZz0qSKjBKCvOjM7U5gK9FZWSTuM5y/vARERWHbYHKn+mUkFvjAWsqu8pA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=q3KUTT5qO3WroS6BMkJyRe0NuyD+ck76vWgvvLGp+k0=; b=DlJIw6BDZJG1j7WJGCdhULGTPT06cfxCZOyA91zwS+R/TspXWUH3DPVPUvZs1XrH+D6Qm8Bo1Dm1hBvwV+1xWmWabWx6YX+nmgj9FKquPXnxS0u8EOizz80z1Uu9xghDLLceHQWJVamaMRB9OvUHDFPCoVuHGXSQiH+aceswbVI= Received: from DBBPR08MB5915.eurprd08.prod.outlook.com (2603:10a6:10:20d::17) by DB8PR08MB5019.eurprd08.prod.outlook.com (2603:10a6:10:e0::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4242.21; Sat, 19 Jun 2021 12:51:15 +0000 Received: from DBBPR08MB5915.eurprd08.prod.outlook.com ([fe80::69cf:4429:a804:7f41]) by DBBPR08MB5915.eurprd08.prod.outlook.com ([fe80::69cf:4429:a804:7f41%3]) with mapi id 15.20.4242.023; Sat, 19 Jun 2021 12:51:15 +0000 From: Hannes Tschofenig To: Jacques Latour , "danish@ietf.org" Thread-Topic: IoT Device Identification with TLSA via Danish Thread-Index: AddhKvcSXHMYMAB6StqY1oKWkaM4dwD3nhkg Date: Sat, 19 Jun 2021 12:51:15 +0000 Message-ID: References: <02cb8931e16c4ccaa6eed1b89c0a20b6@cira.ca> In-Reply-To: <02cb8931e16c4ccaa6eed1b89c0a20b6@cira.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ts-tracking-id: CD8C28FF370B9E45B0F1835888C29426.0 x-checkrecipientchecked: true Authentication-Results-Original: cira.ca; dkim=none (message not signed) header.d=none;cira.ca; dmarc=none action=none header.from=arm.com; x-originating-ip: [80.92.123.248] x-ms-publictraffictype: Email X-MS-Office365-Filtering-Correlation-Id: def93fbf-49ca-4ed3-2090-08d93320f191 x-ms-traffictypediagnostic: DB8PR08MB5019:|VI1PR08MB5392: X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true nodisclaimer: true x-ms-oob-tlc-oobclassifiers: OLM:10000;OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: Aom9NPsUERgpnmUdMM7X7ETreznVH4yQwcx2/iyJm3/A0t5rGrxeBdEdcmzkBWMvROCgykGpnSG4d7F/TXtI2wdzzfYQQLxUbdYKm5+mfr3hK+DmYc6NM/I7etaJrcToQhKz79KtUmhUHPrLOss51VUMyJYGXVOEGDGj+Bxri2D18rfCzZowtjrzqCXsaiAD6fybiI32RFyXpyClJsseJ7XH6jBkDLEjAWau3ibg/n5OTm+ZAbnS+0zXtS7DDE9qcMrDRLkEoQ9WGoY6l/EKdfDRyWihQs0NoIo+d9M68ddc+zJs5CyzaEpKI0Ie7U+vzJG1DgUR2RBk0fhg6t2OFzzKiwItSb4dsqEQE5XN7mfliWnmRG1VgSBd6twizPj2pHmkGfg0mRvX64AF9gqB502gx7ClusIcZFuHVG4TQN8bPUA8e3znq/RIL6grMZA3SP4CE80a/luffZ2Vvwc/pCE7BMeTmyebqa6WWDLykbz+URfJH1h/q4fKuRtusLMZcE5GFSceDnyFEpVL6D7rZ/PZSj/pp3FeVHytfiQSfpw57i1f85JzAeieEIy2dnsFAhcXJv7Y/ojqofML3AKSN9OI9xwUpT3Xbk3uVuGzm7Ho6pEZm2jZmexkHqhaB/kNcHDLddE+IYjOpM71iPMoTo8MZzTeydnlDGUDaoTlsryuM15hnNrsFvZ+4jM4eJgjSuZ3gercP4VuErhKpbfSFHtP8ugNzHX/Sv2GZqc21PY= X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DBBPR08MB5915.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(396003)(136003)(366004)(39850400004)(376002)(346002)(2906002)(478600001)(7696005)(316002)(52536014)(110136005)(966005)(66446008)(64756008)(66556008)(66476007)(76116006)(66946007)(33656002)(8676002)(5660300002)(26005)(122000001)(38100700002)(186003)(86362001)(6506007)(53546011)(71200400001)(8936002)(9686003)(9326002)(55016002)(166002)(83380400001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?VNI/z3VXG8pOc1Vg22Yb0Yl8JGsbQHgMkc/gU9UehX6bgMAO/ly8vD00v841?= =?us-ascii?Q?uSVbxo5PqbJJfp0s+ZkEL+ZeYn67NE9REWMjRAoO35+j1lxXDZOW4pXCrOHJ?= =?us-ascii?Q?5EjfdEXJ8F4viXBarB/m6x/7V/a9lKYvY7e/R2enWDQ5SVla3sSnCb1rqKTo?= =?us-ascii?Q?XvKZJJDI1beE4C8bFQLdfi+hep8MseFJ9/wvcjwUVopUi6FjTtuZBqUFRYjP?= =?us-ascii?Q?I2OKerBFceaO5pGmNaOrkDefGU7lXKXBxcLFe6cXEmeQuyWcamo47r/YArGt?= =?us-ascii?Q?V8DVBrgslAnCpIS9lRUMWV+tLCJdTecT5eRBnhsyH95scYKJbLQ7KY/R+M4q?= =?us-ascii?Q?3APPM3GVjTYjCLtEeW9/giQ+k7ATq0AGEZ117BdleoJ6iotUBB9MDuwABTU+?= =?us-ascii?Q?vG4qfhhVMybE+svZm9sdtrV1lNl+rlBSKLu5mX/FS+BBCzg0dwZsMW3hh797?= =?us-ascii?Q?azyApBuyKL2PA/EsGmm9k4rj/n1s10ZWP5m1hWsRRQ9VoIaRUyG4+3yC8/a5?= =?us-ascii?Q?PjhbdIfXuLa2dlS5+Fw0jsxfhZXM0SVNyXGWTJD92QTJxU2h9FpAG98472Me?= =?us-ascii?Q?HrWkQtw3KGEYWAl0dKhmzk2sULOlKyooOIL+mhqyXItoj5gUHYQ5vWEXHihX?= =?us-ascii?Q?aAcLtFoi+ns6iE2fbDh9h0sMr52OKXefPtCgFoSampPl60mGWQBV29+MNEKZ?= =?us-ascii?Q?uppxYa2CiwP8klG3BFu2ZDzcK+9CFRHf79rL8Mc8Yxk7ce49PnygkcZzavDW?= =?us-ascii?Q?PnC/MYejDb9MF5lloL3CHNK6x6lYYsMiuzYcwTKjdc2frOD/8saWSXxrPfnL?= =?us-ascii?Q?1L4yESLxHeKCnz2hhcVplYNNQrcKBet0hUiU32LeILj040s9mDg1S2h5yFNb?= =?us-ascii?Q?C4uu7AphFpoTySfgYl7+udgIeyh2ibXf9zTrdYlwT06OTjF/s7G5XXmUy7LR?= =?us-ascii?Q?e5yWfYY3TJD+gUSkqqb/CYqujluTZosCEhrx6MDRIJkdBaN9YJ+Po0DaClSE?= =?us-ascii?Q?xCOZkDsKDnur1YXlL6BaDNfyQNAE8T5pGbo7ewThd21fOG8nxk7+uY8vRNFT?= =?us-ascii?Q?djPg3sfv8SSgBRfzZj6vuHWmd3I0+T0eP5Nc+e2HUVwpO1I8ME0dGCaVpgby?= =?us-ascii?Q?YTNucbgbdyBLLLqgEUJYyITasnL19g076USc5p7bXfYiwiUa0mCL4Vftnpe9?= =?us-ascii?Q?gxZ7GZWvf46RADkmbeiOL1LzYlkX00yqNCJ+V3+5hvYP1+waDvL5N9OZ48Bp?= =?us-ascii?Q?9ihixYIMi1LCKtOUbCnITwTs4FzJOQ9u3aLfIGAPdtHqYyOgTBbDJGjc4BCq?= =?us-ascii?Q?u50gLaP9xyPX0mnxESOpmR3u?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_DBBPR08MB5915F04A83054BBEB4F9FE7BFA0C9DBBPR08MB5915eurp_" MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB8PR08MB5019 Original-Authentication-Results: cira.ca; dkim=none (message not signed) header.d=none;cira.ca; dmarc=none action=none header.from=arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: VE1EUR03FT056.eop-EUR03.prod.protection.outlook.com X-MS-Office365-Filtering-Correlation-Id-Prvs: 28821f79-ef70-49ba-4e88-08d93320ecc3 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: oSx5PDPEXeGrM7hZreEgvhhYItjwAMnKAEuPuT5acjNMHus0gF43w6hiJzEc9LcA7EfrZl3A2m82w7y3e91/QmscJ3Ra56MtXzklEWGfcpgNHYsg+lhNZYsDiqK4XjDzYNNJsGDcGrhrDbbXRwfbatUcmGA9NRsNMw0kX0KVQ7hZv8nw6HYTqV4hOQmrWPdr8hW+U3hyt+Y3/JZT5NzgCIj5nbtG0llEioTJkXceOIAPlFCLxJaHQEPaP+nL0LuRnR3qS9OmDbLh8U+MZJdL8dfHWv4h+R40JMJ8rRszu05FvN+DhbXOdky/p+xLD+RfkEnCdM6eegJi9gcx+f4iDvTOkJ/FbYNnFdTMwsF/TM9XiiMXQgvT4z1fhFbqHeH0teBvdcWl/AoDKG7EPkb5xPsboTPeWg2tH9y9DQU/1AUX21TwxoJtmiCnh53Kzbape+4T9qHqIJCjb1porqMqPTeaWLlb7gEIc1Qc4GlR1o0XygEQEdO9pLSh9aXQ0t/L6O1nL/1yeW8yOWKkBxsJJbKvb6KOwyq5ySonfe0up6XWQdfZ/NT2/G5/iWyU+18LXInjzmfAh7HAOcEFh4Q2KDNqvybaVmD25tbl82Kp5fytPeGA/z2lc5I893GxT3LSoiFegNRDY4e40sk0IgYtSoV6imcRG0T2//hoBqYVW/NQPvnRewu2IDofsVmUmY+QAVZVgAIFDoVNVhu6LUIZ6T5QXWJTm0NXIOl+XzPp+qEH9oz/gWGjAu0L0zJbWwLMIF7MSsHK0TdoaVSMPfgSsQ== X-Forefront-Antispam-Report: CIP:63.35.35.123; CTRY:IE; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:64aa7808-outbound-1.mta.getcheckrecipient.com; PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; CAT:NONE; SFS:(4636009)(346002)(136003)(376002)(39850400004)(396003)(36840700001)(46966006)(82310400003)(8936002)(110136005)(36860700001)(7696005)(70206006)(966005)(8676002)(166002)(9686003)(5660300002)(70586007)(47076005)(81166007)(478600001)(86362001)(356005)(82740400003)(55016002)(53546011)(52536014)(316002)(336012)(33656002)(83380400001)(26005)(6506007)(2906002)(186003)(9326002); DIR:OUT; SFP:1101; X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Jun 2021 12:51:23.2916 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: def93fbf-49ca-4ed3-2090-08d93320f191 X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d; Ip=[63.35.35.123]; Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com] X-MS-Exchange-CrossTenant-AuthSource: VE1EUR03FT056.eop-EUR03.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR08MB5392 Archived-At: Subject: Re: [Danish] IoT Device Identification with TLSA via Danish X-BeenThere: danish@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DANE AutheNtication for Iot Service Hardening List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Jun 2021 12:51:32 -0000 --_000_DBBPR08MB5915F04A83054BBEB4F9FE7BFA0C9DBBPR08MB5915eurp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Jacques, Thanks for sharing your slides. Since the slides are not meant to be self-e= xplanatory I have a question for you: What is an IoT registry for you? (You mention the term on slide 2 and it seems to be core to your presentati= on.) Ciao Hannes From: Danish On Behalf Of Jacques Latour Sent: Monday, June 14, 2021 4:41 PM To: danish@ietf.org Subject: [Danish] IoT Device Identification with TLSA via Danish Hi, Today I presented at the ICANN DNSSEC workshop the potential results of DAN= ISH working group which I think should include the entire scope having a mu= tual TLSA validated TLS session from an IoT device to a server. https://github.com/CIRALabs/CIRA-Secure-IoT-Registry/blob/master/CIRA%20-%2= 0Challenges%20in%20DNSSEC%20IoT%20Registry%20-%20ICANN%202021-6-14.pdf In addition, I was thinking there should be a 4th TLSA certificate usage, t= ype 0 or 4, for TLSA to show cert that are revoked, if we know for sure the= certificate is revoked then it should be presented and queried/answered as= such, an authoritative answer signed with DNSSEC to say certificate is re= voked, not to be trusted anymore. NSEC says it does not exists, this usage= would be very clear. This works for client identity, not sure for other TL= SA use cases. Jacques IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you. --_000_DBBPR08MB5915F04A83054BBEB4F9FE7BFA0C9DBBPR08MB5915eurp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Jacques,

 

Thanks for sharing your slides. Since the slides are= not meant to be self-explanatory I have a question for you: What is an IoT= registry for you?

(You mention the term on slide 2 and it seems to be = core to your presentation.)

 

Ciao

Hannes

 

From: Danish <danish-bounces@ietf.org> = On Behalf Of Jacques Latour
Sent: Monday, June 14, 2021 4:41 PM
To: danish@ietf.org
Subject: [Danish] IoT Device Identification with TLSA via Danish

 

Hi,

 

Today I presented at the ICANN DNSSEC workshop the p= otential results of DANISH working group which I think should include the e= ntire scope having a mutual TLSA validated TLS session from an IoT device t= o a server.

 

https://github.com/CIRALabs/CIRA-Secure-IoT-= Registry/blob/master/CIRA%20-%20Challenges%20in%20DNSSEC%20IoT%20Registry%2= 0-%20ICANN%202021-6-14.pdf

 

In addition, I was thinking there should be a 4= th TLSA certificate usage, type 0 or 4, for TLSA to show cert that ar= e revoked, if we know for sure the certificate is revoked then it should be= presented and queried/answered as such,  an authoritative answer signed with DNSSEC to say certificate = is revoked, not to be trusted anymore.  NSEC says it does not exists, = this usage would be very clear. This works for client identity, not sure fo= r other TLSA use cases.

 

Jacques

 

 

IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in any medium. Thank you. --_000_DBBPR08MB5915F04A83054BBEB4F9FE7BFA0C9DBBPR08MB5915eurp_-- From nobody Sat Jun 19 07:02:11 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 AF1BB3A10F9 for ; Sat, 19 Jun 2021 07:02:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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=armh.onmicrosoft.com header.b=2QkvFws/; dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=2QkvFws/ 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 QDVr7_DTH7mJ for ; Sat, 19 Jun 2021 07:02:05 -0700 (PDT) Received: from EUR05-AM6-obe.outbound.protection.outlook.com (mail-am6eur05on2048.outbound.protection.outlook.com [40.107.22.48]) (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 DB8333A10F4 for ; Sat, 19 Jun 2021 07:02:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=9doXPvTG6s8pzJtu9OuqbRR0BxJItE+deykQLOxPH90=; b=2QkvFws/6v9RYE8WaVmnk40iSJOttN0hJ2uLumklDjRp/euCMWcPpMTxwprkPyBryUjGqTw+K/hukuiasCo/4stMF35sT3pOqFHwCtFG5WrJzj99C95kO4qoWUNjLPZvFs+tykugKJdVPW/DkkAdpNBCMky88nQ8//eAXUoYAvE= Received: from DB6PR0801CA0049.eurprd08.prod.outlook.com (2603:10a6:4:2b::17) by AM5PR0801MB1795.eurprd08.prod.outlook.com (2603:10a6:203:2f::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4242.19; Sat, 19 Jun 2021 14:02:01 +0000 Received: from DB5EUR03FT005.eop-EUR03.prod.protection.outlook.com (2603:10a6:4:2b:cafe::c9) by DB6PR0801CA0049.outlook.office365.com (2603:10a6:4:2b::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4242.16 via Frontend Transport; Sat, 19 Jun 2021 14:02:01 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; ietf.org; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com;ietf.org; dmarc=pass action=none header.from=arm.com; Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 63.35.35.123 as permitted sender) receiver=protection.outlook.com; client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com; Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by DB5EUR03FT005.mail.protection.outlook.com (10.152.20.122) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4242.16 via Frontend Transport; Sat, 19 Jun 2021 14:02:01 +0000 Received: ("Tessian outbound f88ae75fbd47:v96"); Sat, 19 Jun 2021 14:02:01 +0000 X-CR-MTA-TID: 64aa7808 Received: from 30ff386e137a.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 944D11D7-D5EC-48AA-8FD5-A8F3AD968962.1; Sat, 19 Jun 2021 14:01:55 +0000 Received: from EUR04-HE1-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 30ff386e137a.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Sat, 19 Jun 2021 14:01:55 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=blBIaMTdEDhKQ0IfVuAj823Ldp8g6e00pMwiu0+IFHLS7YwQPAFkC36BTGdVd3CNfLE4j/GRGospzP0USsP6ME08Gm5edGIxSBw1oY1lMDWVQWpq23xXhK4/D/HWJMdDkOAGWI1HfYQiSlt5p6gPglbzVGdGulaGOx9lzo/LebYPPcRT13JWcIeBS3yKmA6KoRze50hXDqxRtgUrzhe2gybOESh3dYfse5gmaVJcDNhsqGDlkAlfzopxPtZPnN1wb4KTbAmtcb3CXbFnaP/1S3JBWeVbtCywsCAuVr43C75hlY+2PtBDJlBE6cvbqqC9R9BmR8D6D8dFEXd8aE86+Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=9doXPvTG6s8pzJtu9OuqbRR0BxJItE+deykQLOxPH90=; b=lk/IsSSxj6wWwVNb3LPB/SWA3+fNcvwdgMVl4Yc1l/4P+3+6yPjbFp9PUh1L3PP6fepRu0b5BXypxagD2bvAFYIGaFsRov+YKZsi+jKdVGPTtzELEQ4EtAFmu/pnL7dY4cBXF+gmzN7Ffa5TvGJiBPVk/jPwbhRERmYKOurNoB4yACuPPNhWnVvxtgmvuscbiiJzorr1zUEIYIERHCy83pWxSV2F1P32aSJNR/v+ZiHJUkRAidYkKo33Yn5XKshsjBohAOKJqmp/aVWGi8N8PylXTkM3itXOSXeTR8Po9k+XP3OhIfxU/dvPIJhSeEhJsmCxLE6fGXgm2oenBhs3qQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=9doXPvTG6s8pzJtu9OuqbRR0BxJItE+deykQLOxPH90=; b=2QkvFws/6v9RYE8WaVmnk40iSJOttN0hJ2uLumklDjRp/euCMWcPpMTxwprkPyBryUjGqTw+K/hukuiasCo/4stMF35sT3pOqFHwCtFG5WrJzj99C95kO4qoWUNjLPZvFs+tykugKJdVPW/DkkAdpNBCMky88nQ8//eAXUoYAvE= Received: from DBBPR08MB5915.eurprd08.prod.outlook.com (2603:10a6:10:20d::17) by DB7PR08MB3132.eurprd08.prod.outlook.com (2603:10a6:5:1c::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4242.19; Sat, 19 Jun 2021 14:01:49 +0000 Received: from DBBPR08MB5915.eurprd08.prod.outlook.com ([fe80::69cf:4429:a804:7f41]) by DBBPR08MB5915.eurprd08.prod.outlook.com ([fe80::69cf:4429:a804:7f41%3]) with mapi id 15.20.4242.023; Sat, 19 Jun 2021 14:01:49 +0000 From: Hannes Tschofenig To: Michael Richardson , Jacques Latour , "danish@ietf.org" Thread-Topic: [Danish] [EXT] Re: IoT Device Identification with TLSA via Danish Thread-Index: AQHXYeq1j4nc9HqrjUCxOrwF4awGj6sVZ2qAgAX7NOA= Date: Sat, 19 Jun 2021 14:01:49 +0000 Message-ID: References: <02cb8931e16c4ccaa6eed1b89c0a20b6@cira.ca> <90e0d38f1a394b79987b5f1517cc157e@cira.ca> <32259.1623782305@localhost> In-Reply-To: <32259.1623782305@localhost> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ts-tracking-id: DB25EC9E71CDFB488709EDF25A248E62.0 x-checkrecipientchecked: true Authentication-Results-Original: sandelman.ca; dkim=none (message not signed) header.d=none; sandelman.ca; dmarc=none action=none header.from=arm.com; x-originating-ip: [80.92.123.248] x-ms-publictraffictype: Email X-MS-Office365-Filtering-Correlation-Id: f6aa13f1-aa4f-46f9-3bff-08d9332acfb2 x-ms-traffictypediagnostic: DB7PR08MB3132:|AM5PR0801MB1795: X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true nodisclaimer: true x-ms-oob-tlc-oobclassifiers: OLM:10000;OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: WckIICZ2SHs/1T2nux9WCtFvqyAzjOw8AX77P85sRc7zbqlNOzu7gJRSf3QnjgibSA3vrTlR71W26DxW2YZ1AS/DaEkNRjAZ2MsYITFkxUBf/UcGpaNWGxyumn8czw6mVK6JVqrNXXMhfr/hg6wh9Cf/311cv6mupFGfatcGav4QetWaMWrYWPb0AojElLXJ8Gua/JC9Jsv/b3fhdXObhX5zSJGenjHwjh9w8EtWSjFV4HESzZSioMhvy0B+Zu7CnSmPl8z8V0ggx93vz0noT+KVAPrw+8ArJPWSBP4uiJQOQU3dmHNlFutekL8NBwV016cvpbwQhRXp+zfFVUj5FQKV+XOAF2fkOfPk6wkp5ZXYaCaivczSZetrdSk7vu1Bxa017PR6yOIEZK1gjrPQu3jtNjFeK6a9TaFMoH94B2wqhqcfP6mIehF5zWpZnYwykq0vs7aIYopD75NOFz/BnWnuwaynBLRmKUCAv5gaqQhPdDKkn2d5Cgwj5xCdGIbhbSSx/1C6sZB6WCz2dP2T7mKnnWCOYMkSAsJlZ75FOOPNCruwQ6dOw4QAmh0dP5CxSw8xGSvLRxKWTTEFRKoUoT14FUsKIqoGyS2o7vuz9Ko= X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DBBPR08MB5915.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(376002)(366004)(396003)(39850400004)(136003)(346002)(316002)(33656002)(6506007)(53546011)(110136005)(38100700002)(9686003)(55016002)(7696005)(86362001)(122000001)(186003)(26005)(478600001)(83380400001)(64756008)(66556008)(66476007)(66946007)(76116006)(66446008)(8936002)(8676002)(71200400001)(66574015)(2906002)(5660300002)(52536014); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?eWthMm4vT3R2b1VHUkJhTDdIMmRONktqZG52d1RjUnA5Sm9XWHNBN2tRSFNX?= =?utf-8?B?OWJicmRMc0lWRGMrRWdjeFZLOGRvQ2JnR1BMYVdTTkhZSnM3cFpldW95WHJn?= =?utf-8?B?TWt2YkFUYWhTTGpFTEpVMDhhc3VtZDA4RHc0MVc1QXk0MjVWeXBJUnVPaG1K?= =?utf-8?B?Nk5XSWpENzdRWFpsQ1Y0VmtSK2c3L1k4eFlZT0ZlYTRuNUwrVUR6d2tJSXcy?= =?utf-8?B?blh0WEF5VTFSbXJ6SWxDc01FTVk0QUlJazRVSnBKUmEyeDNHUnFLY1dHMGVF?= =?utf-8?B?d2JQc3N0TWFKZkQ2cWFzZ25UdmhIMXFWcTJiMlVWbXRheFNJcWZZdCtBaVI0?= =?utf-8?B?MUN6RDd0Mno3T1ducnpZelpidm5qRHU0aDY2MW5oZUZGY3ljRGRLVjBQN01E?= =?utf-8?B?dEFmNzRUY0ovS0M2cVl1MGhPQ2FNNEFuR3pNQWxZM3dJMVI0N2w4eHlFb1Za?= =?utf-8?B?Uzl1ZFpIRmc1TlZkOGZxZW1CTjB6S3N5MWU5L3VVMCswSXV6ek5UYTduZ1BM?= =?utf-8?B?QUZzWFZxaGV4aG1HaDFPRkhDdFArNWZDQzdmMXMyUVJsbVlZb3EydC91OFdl?= =?utf-8?B?d1IyUXh6c092cjdiQWFzcXRydzlYYzVlUHp3aHU3Q0JDV0dZNzdXOWQ4czlw?= =?utf-8?B?RVZlWEY5N0I2a1JwWGdNakxwL1QxNGpFQU9wZ3hkQWhONFdBQ1czOWNlLzhq?= =?utf-8?B?Z1JPSzRzdXpMN0xqR202TGd1NXVQVEpYMnFsZHN2T2pwV2xnZDFrcVFUTnFV?= =?utf-8?B?VTNCeW8zNUlpcnR1N3BROWZkbUswRnhFR2NhOUoxUEdsN3ZIZXVhL2RLMmtk?= =?utf-8?B?Smx6clhOZGdDME5raElxZEV1WDJTcWdZZUJYREFhVysyM0EzdFpsazI4dC96?= =?utf-8?B?aC82UjdpWWlPYU9mWk1RVHdETUF5RDVjMnpGVU1RbldhT2ZOdXRvVTBoNk1J?= =?utf-8?B?b0VUeFUyYS84OTR1UEJBYmRKMFUrV0ZVUjdxak4zV1hyRU1zRFFTRzNJaXoy?= =?utf-8?B?MFNDOFlUN2l2d0d2VHJDWDBJamdpRGNmNmNrM1RydlhtUUpzMWt2RWYrazdi?= =?utf-8?B?UFF0Q1grdmVHaFF5NjBJVFk5OWxwZ2h0b056RzBsQXZ5c1RsZUlRcFgrWVMr?= =?utf-8?B?dGNzVE01TXE2MkFVbHEwSEdyUC9MV091azlqbHdPaTN3a3RZajZERmI0NktX?= =?utf-8?B?dEdxOG14OE5BTU8xeS9Rb3dDWTU1dkdDWTdJVE9UQ1lHZUQrcDlQK01YQWxu?= =?utf-8?B?aEk2UFU4ZnNxTTFHenZCZE9xWjZyTi80TitZaERCc3RnOHBQcmdwRUk0QllO?= =?utf-8?B?U0oxVGlRTjl0V3l3akJjdTlYaXIxWGtHbm5oaEpMaUJ2RkxmZWErMGE4SWVo?= =?utf-8?B?WHNTN21Tb2tpUk9mb0JJZlgyeHNadzlpdG42T1Y0ajg3N0lmTGUzOG5DZ0Fo?= =?utf-8?B?L0VrRUNzbEVWS0RTRjFGcXgvcDhnT1RiYythWEVMM0RlUmFSM0FpUWh0SjU4?= =?utf-8?B?UWN0WGtuM2hQVDBIUlVsUGxzT2ZsY1gzeWhGUzQwR1hqM3ZDSjNJSHBJdE12?= =?utf-8?B?V01SbGtxbGJIWEVQNGJZTHNPcjNKZ2hoQnE5ajYwWUpxS2c3Uy9yNVB3VVN0?= =?utf-8?B?UUpMMXlFamEzVU94aGEzalk2eTQrSmJVQXZFYnpYdDdFcTBvdDI1YVl4OEcx?= =?utf-8?B?em1va1RtSDFtY1BPUVh2ZU5rUjNNeENtcWVXM3JTdHI2aTB5aHpHMFljL1hn?= =?utf-8?Q?VxZ0m1tPhgzJSyCBiNMygx1dqR3IfeoLxf9ClOO?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR08MB3132 Original-Authentication-Results: sandelman.ca; dkim=none (message not signed) header.d=none; sandelman.ca; dmarc=none action=none header.from=arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: DB5EUR03FT005.eop-EUR03.prod.protection.outlook.com X-MS-Office365-Filtering-Correlation-Id-Prvs: 1a0f960c-ba71-427d-5722-08d9332ac882 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: jM/mJ6PUgU0Ors5MuwyTRx6jOl8lR5mMVOaB1JJNAXhmC/YBnc27OgNCloWnhdLwQ7dMc2066OgVhjyjHHcGECu8qLVi8OE8ZLF2FTuvNP8p9H3kMpqZmjaJKqwJH9vV4SRx+zNyTFH1w/xvYGWqONwOEhUgdgiHK5boXk4+4CLmJEoGLVNgPb68qQ5RDSnF6N9ixdPUNYXLSHNkx+YZnOhALTB9IIkp1PHS9CP8p6vGo/pE7GSPQWgPfZJulvhcsmgGbS3GKIDJ4XneDF5Gnde8pb1+thKXXbVzL8TcinH7Pn2ISw6KXaXFHKHYxJQanRudWL90d00xxKD2e2GJf569zbFFYfPA57Tf811UMN68OLXSvTa69AKmsTVGRvoC6hP5BjQDs1VD0DDjhxp2sWMrwOOILEywAEnoSGHE43Prjokn6OSxG+1WQblFyOpDL6xZvkUvOHut1X/arzVct4PmSvGhFIu8jHkF6jZdt9PTDjkJGVxb3YZX7IengM01HO8FfU/qg8ohNWQ1crocv1t6oPPvoSJlERTuNHBkPjFynTF72cU9eXg7fopHbFgP2Oq1Kwao5vw+QtI/9LE8+LwXEgNs/tEiNn4kuoVAVi76rzh4m/v18Gv2qb6GFGQ2Xz6vWp3jKncBt0E/YT6owEwkijW3h/uoA/M0Zf88NCc= X-Forefront-Antispam-Report: CIP:63.35.35.123; CTRY:IE; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:64aa7808-outbound-1.mta.getcheckrecipient.com; PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; CAT:NONE; SFS:(4636009)(396003)(136003)(39850400004)(346002)(376002)(36840700001)(46966006)(7696005)(82310400003)(26005)(82740400003)(81166007)(9686003)(33656002)(2906002)(53546011)(66574015)(8676002)(86362001)(55016002)(83380400001)(6506007)(356005)(186003)(36860700001)(47076005)(316002)(110136005)(5660300002)(8936002)(52536014)(336012)(70586007)(70206006)(478600001); DIR:OUT; SFP:1101; X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Jun 2021 14:02:01.5783 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: f6aa13f1-aa4f-46f9-3bff-08d9332acfb2 X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d; Ip=[63.35.35.123]; Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com] X-MS-Exchange-CrossTenant-AuthSource: DB5EUR03FT005.eop-EUR03.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0801MB1795 Archived-At: Subject: Re: [Danish] [EXT] Re: IoT Device Identification with TLSA via Danish X-BeenThere: danish@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DANE AutheNtication for Iot Service Hardening List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Jun 2021 14:02:10 -0000 SGkgTWljaGFlbCwgSGkgSmFjcXVlcywNCg0KSSBmb3VuZCB0aGlzIGVtYWlsIHRocmVhZCBhbmQg d2FzIHdvbmRlcmluZyBhYm91dCBvbmUgYXNwZWN0IGluIHRoZSBjb250ZXh0IG9mIGF1dGhvcml6 YXRpb24gbGlzdHMuDQoNCldoZXJlIGFyZSB0aGVzZSBhdXRob3JpemF0aW9uIGxpc3RzIHN0b3Jl ZCBhbmQgd2hvIGNyZWF0ZXMgdGhlbT8NCkluIHdoYXQgeW91IHVzZSBjYXNlcyBkbyB5b3UgbmVl ZCB0byBjb25maWd1cmUgdGhlc2UgYXV0aG9yaXphdGlvbiBsaXN0cz8NCg0KQ2lhbw0KSGFubmVz DQoNClBTOiBJIHdvdWxkIGF2b2lkIHRvIHVzZSB0aGUgdGVybSAiaWRlbnRpdHkiIGJlY2F1c2Ug aGVyZSB3ZSBhcmUgb25seSB0YWxraW5nIGFib3V0IGFuIGlkZW50aWZpZXIuIElkZW50aXR5IGhh cyBzbyBtdWNoIGJhZ2dhZ2UsIHdoaWNoIGlzIHByb2JhYmx5IG5vdCB1c2VmdWwgaW4gdGhpcyBj b250ZXh0Lg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogRGFuaXNoIDxkYW5p c2gtYm91bmNlc0BpZXRmLm9yZz4gT24gQmVoYWxmIE9mIE1pY2hhZWwgUmljaGFyZHNvbg0KU2Vu dDogVHVlc2RheSwgSnVuZSAxNSwgMjAyMSA4OjM4IFBNDQpUbzogSmFjcXVlcyBMYXRvdXIgPEph Y3F1ZXMuTGF0b3VyQGNpcmEuY2E+OyBkYW5pc2hAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbRGFu aXNoXSBbRVhUXSBSZTogSW9UIERldmljZSBJZGVudGlmaWNhdGlvbiB3aXRoIFRMU0EgdmlhIERh bmlzaA0KDQoNCkphY3F1ZXMgTGF0b3VyIDxKYWNxdWVzLkxhdG91ckBjaXJhLmNhPiB3cm90ZToN CiAgICA+IFRvcCBwb3N0OiBJIHRoaW5rIGluIHRoZSBjb250ZXh0IG9mIElvVCBEZXZpY2UgQ2xp ZW50IElkZW50aXR5LCB0aGUNCiAgICA+IGlkZW50aXR5IG9mIGFuIGluZGl2aWR1YWwgZGV2aWNl IGNhbiBiZSByZXZva2VkIGZvciBvdGhlciByZWFzb25zIHRoYW4NCiAgICA+IGEgY29tcHJvbWlz ZSwgZm9yIGV4YW1wbGUgaWYgYW4gSW9UIGRldmljZSBpcyByZXB1cnBvc2VkIGZvciBhIG5ldyB1 c2UsDQogICAgPiB0aGVuIGEgbmV3IGlkZW50aXR5IHdvdWxkIGJlIHByb3Zpc2lvbmVkIGZvciB0 aGUgbmV3IHB1cnBvc2UgKG5ldw0KICAgID4gY3VzdG9tZXIsIG5ldyBuZXR3b3JrKSwgSSB0aGlu ayBoYXZpbmcgYSBtZXRob2Qgb2Yga25vd2luZyB0aGF0IHRoZSBvbGQNCiAgICA+IGlkZW50aXR5 IGlzIHJldm9rZWQgKHNheSBmb3IgMyBtb250aHMpIHdvdWxkIGJlIHVzZWZ1bC4gIFdlIHdvdWxk IGtub3cNCiAgICA+IGZvciBzdXJlIHRoYXQgdGhlIHJlcHJvdmlzaW9uaW5nIG9mIGEgbmV3IGlk ZW50aXR5IHRvIHRoZSBJb1QgZGV2aWNlDQogICAgPiBkaWRuJ3Qgd29yay4NCg0KQSBwcmVtaXNl IG9mIERBTklTSCBpcyB0aGF0IHRoZSBkZXZpY2UgY29tZXMgd2l0aCBhbiBpZGVudGl0eSwgc3Vw cGxpZWQgYnkgYSBtYW51ZmFjdHVyZXIuDQpUaGlzIGlzIHRoZSBwYXJ0IHdoZXJlIHRoZSBkZXZp Y2UgZG9lcyBub3QgbmVlZCB0byBnbyB0aHJvdWdoIGFuIG9uYm9hcmRpbmcgcHJvY2VzcyAodG8g YSBwcml2YXRlIENBKSwgYnV0IHJhdGhlciBpdCdzIGVub3VnaCB0byBjb25maWd1cmUgdGhlIG5h bWUgb2YgdGhlIGRldmljZSBpbnRvIGFuIGF1dGhvcml6YXRpb24gbGlzdC4NCg0KSWYgdGhlIGRl dmljZSBpcyByZXB1cnBvc2VkLCB0aGVuIGl0IHdvbid0IGdldCBhIG5ldyBuYW1lLiAodGhhdCB3 b3VsZCByZXF1aXJlIHRoYXQgaXQgYmUgb25ib2FyZGVkIHdpdGggYSBuYW1lIG5hbWUsIHJpZ2h0 PykgU28sIGluIG9yZGVyIHRvIHJlcHVycG9zZSBhIGRldmljZSwgaXQgbmVlZHMgdG8gYmUgcmVt b3ZlZCBmcm9tIHdoYXRldmVyIGF1dGhvcml6YXRpb24gbGlzdCBpdCB3YXMgb24sIGFuZCB0aGVu IGFkZGVkIHRvIHRoZSBuZXcgYXV0aG9yaXphdGlvbiBsaXN0Lg0KUmV2b2tpbmcgdGhlIGNlcnRp ZmljYXRlIHdvdWxkIGtlZXAgdGhlIGRldmljZSBmcm9tIGJlaW5nIGFibGUgdG8gYmUgdXNlZCBp biB0aGUgbmV3IHB1cnBvc2UuDQoNCntJIHBlcnNvbmFsbHkgdGhpbmsgdGhhdCB0aGlzIGlzIGEg bmVnYXRpdmUgb2YgREFOSVNILg0KTWF5YmUgaXQncyBub3QgYSBjb3JlIGFzcGVjdCBvZiBpdCwg YnV0IGl0IHNlZW1zIGxpa2UgaXQgdG8gbWUufQ0KDQotLQ0KTWljaGFlbCBSaWNoYXJkc29uIDxt Y3IrSUVURkBzYW5kZWxtYW4uY2E+ICAgLiBvIE8gKCBJUHY2IEnDuFQgY29uc3VsdGluZyApDQog ICAgICAgICAgIFNhbmRlbG1hbiBTb2Z0d2FyZSBXb3JrcyBJbmMsIE90dGF3YSBhbmQgV29ybGR3 aWRlDQoNCg0KDQoNCklNUE9SVEFOVCBOT1RJQ0U6IFRoZSBjb250ZW50cyBvZiB0aGlzIGVtYWls IGFuZCBhbnkgYXR0YWNobWVudHMgYXJlIGNvbmZpZGVudGlhbCBhbmQgbWF5IGFsc28gYmUgcHJp dmlsZWdlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIG5v dGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGFuZCBkbyBub3QgZGlzY2xvc2UgdGhlIGNvbnRl bnRzIHRvIGFueSBvdGhlciBwZXJzb24sIHVzZSBpdCBmb3IgYW55IHB1cnBvc2UsIG9yIHN0b3Jl IG9yIGNvcHkgdGhlIGluZm9ybWF0aW9uIGluIGFueSBtZWRpdW0uIFRoYW5rIHlvdS4NCg== From nobody Sat Jun 19 13:25:28 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 CB1233A1EF9 for ; Sat, 19 Jun 2021 13:25:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[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 NUE2Y-9M3X60 for ; Sat, 19 Jun 2021 13:25:21 -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 BC4F03A1EF6 for ; Sat, 19 Jun 2021 13:25:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 0CB0938BC0; Sat, 19 Jun 2021 16:26:45 -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 fCmiXCOHVFRn; Sat, 19 Jun 2021 16:26:43 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 1276038BA5; Sat, 19 Jun 2021 16:26:43 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id F3B73B75; Sat, 19 Jun 2021 16:25:16 -0400 (EDT) From: Michael Richardson To: Hannes Tschofenig , "danish\@ietf.org" In-Reply-To: References: <02cb8931e16c4ccaa6eed1b89c0a20b6@cira.ca> <90e0d38f1a394b79987b5f1517cc157e@cira.ca> <32259.1623782305@localhost> 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: Re: [Danish] [EXT] Re: IoT Device Identification with TLSA via Danish X-BeenThere: danish@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DANE AutheNtication for Iot Service Hardening List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Jun 2021 20:25:27 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hannes Tschofenig wrote: > I found this email thread and was wondering about one aspect in the > context of authorization lists. > Where are these authorization lists stored and who creates them? > In what you use cases do you need to configure these authorization li= sts? I can't speak for Ash and/or Shumon's projects where some of these requirements came out of. I've suggested that it would be great to know more about some of the experiences that have driven some of their requirements. I think that the IoT application operator creates the lists. I imagine that either an installer scans some (QR?) code on the sensor/actuator, or perhaps they identify the device to the operations cent= er by interacting with it. Somewhat like a brain surgeon poking neurons and observing what things it moves, or having the person report what they sense. Or like buzzing out wires: https://en.wikipedia.org/wiki/Signal_tracer =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+93Q3WUFAmDOUqwACgkQgItw+93Q 3WUpDggAhm5XnR+qO6fVd4wDWS6dSs7+yFmJeEcR+5k/MVtXgIEEyv7C87TQ3vxJ w427ZlQv+278xuyIvQygrb/lFsGD+y8ih9u5qyOKsl0CqxdpHjd0IHFJSF10dSwK uqkY6dVY/GPUA5HuprKnDkm5wtK5VaN+ayHoiEB53Op0N8C0AQdtQRDOPnC4BXNW 3cGJbTyvo/Ue0IFqB4k0MjwsdzOp9+zUJFMhBrtwhIsnHzZSfzwqYKnT8sMtNcsY 9PUEfBnZxWwceduMsUKb7pvoVSc94SAy05tJt+VrJHb+yKKj7sYG5ujdGVv1xNuZ 1HIw0m4jlpTIAtqC33WvvlWLxDy/xQ== =PgbV -----END PGP SIGNATURE----- --=-=-=-- From nobody Sat Jun 19 13:28:11 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 598CF3A1F0C for ; Sat, 19 Jun 2021 13:28:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[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 vkua08t2XNeN for ; Sat, 19 Jun 2021 13:28:05 -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 776273A1F0A for ; Sat, 19 Jun 2021 13:28:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 3985038BC0; Sat, 19 Jun 2021 16:29:30 -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 hWUrze8QoWG9; Sat, 19 Jun 2021 16:29:28 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id D1E5038BA5; Sat, 19 Jun 2021 16:29:27 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id BE0C8B75; Sat, 19 Jun 2021 16:28:01 -0400 (EDT) From: Michael Richardson To: Hannes Tschofenig , "danish\@ietf.org" In-Reply-To: References: 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: Re: [Danish] Charter Text and the Problem Statement X-BeenThere: danish@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DANE AutheNtication for Iot Service Hardening List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Jun 2021 20:28:10 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hannes Tschofenig wrote: > Regarding =E2=80=9Cbest practice to ensure that a device is patched b= efore > putting it into production, and updating roots of trust fits within t= he > scope of that sort of activity=E2=80=9D: I don=E2=80=99t think there = is any expectation > that the device will be updated before it is put in production > (i.e. powered on for the first time). You can assume that the device, > when it comes online for the first time and reaches out to the device > management server, gets a firmware update. Having that firmware update > happen before it is connected to the network is extremely unlikely. One can onboard onto a quarantine network on which firmware updates can occur, and then move to the production network. > EAP-TLS is also not an IoT device onboarding protocol. From the chart= er > text I am also not assuming that you are attempting to define a new I= oT > onboarding protocol or do you? Yes, but several people are trying to do EAP-TEAP-BRSKI. > I am still trying to figure out how DANISH fits into the larger pictu= re > and hence I am looking forward to read an architecture document. Is t= he > a pre-draft available already? I don't think so, but maybe that would be a good direction to consider. =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+93Q3WUFAmDOU1EACgkQgItw+93Q 3WWJ0AgAl/yrI+Loi6RfB2NdTh4VrpZ7iudvTdONxsf2AS1caf5mcNRBblsw3kEJ COS5bQpcmnTYVQZeEmOdwc/xzGRIJKLph7GKvjEVsKX+1ySZVQgsi9QEb353ExjT /LrENmDh8NUMIOZiy0+tQI2Ixc1IhgwRo9YIOJTCdM5/7i6fei2J4gzTQQHXikgO RpkejHfOo8CZcokBq1haIihfTQguBbnhyi9Sf6+rDqf0y0nrgoSXnDpjcV5mXyZF PXYAoUxruvE/3jfkbhfagO8YZsTIN/kUHd+Va9O7BlpZL9Mos/dlDFfv2rVAsHN/ Z+GXQyutYFh3wAnLykCdHF/1p5aHEQ== =6sXE -----END PGP SIGNATURE----- --=-=-=-- From nobody Sat Jun 19 21:47:33 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 7EF473A1A27 for ; Sat, 19 Jun 2021 21:47:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.198 X-Spam-Level: X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=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 SVo9Goe1UjIW for ; Sat, 19 Jun 2021 21:47:26 -0700 (PDT) Received: from mail-qk1-x731.google.com (mail-qk1-x731.google.com [IPv6:2607:f8b0:4864:20::731]) (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 ED2AB3A1A26 for ; Sat, 19 Jun 2021 21:47:25 -0700 (PDT) Received: by mail-qk1-x731.google.com with SMTP id j62so21610717qke.10 for ; Sat, 19 Jun 2021 21:47:25 -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=u/ZEXp4vby2rLKuQrM6sXWbfeeW78NhsJvS6I9ut9NQ=; b=RXKHOgiJtPskM89XhLPXPOIqn0St+vMr2ZPjdykiZbBmCqfsn5QeeQh8oAJJUHSYSb /kgKH45OhxgblJTfmQGeTh0FX4u5sCz2IJjWCZXAHw3ECDAJBwvFgek0Mf4rRrqpESU/ CZy7uhq89g7ZYiucFxRtBHgcVz7ZIglyHR/GC+sSF6SZH655xmHAQcIXwpuqiDFZdYp2 1c1H902NkTZURO25MV027byAk0bA7wcebL9tT9/7iBy2zGmiQ4L9F0UvTh3/1Ur3Fuj2 6Xf+eKPEfQHHDOprKifmP+jXnfoNLO/K2DudGihBTIBlZyPnEWLlD3ip49c8SoJOuGA5 WJdg== 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=u/ZEXp4vby2rLKuQrM6sXWbfeeW78NhsJvS6I9ut9NQ=; b=krHCJvejbQ9MS1he6VUWDLRxXBsJxwvP98aw0ArE6ygoQ3z/vdAIbOCAHNzMkRUwyQ 7sgiaXVST2DdEK/Qk/yBfp97rAV8TpIvhO+ei//djyN6SoQW8ErMbqRCAvq2r9es32hE 6RTLIXMdDTWz9hdOygIhewF3MtjR6GH/DpLNbFNfsmFgCdQlaBUMhI9qW9CUKqQMqNWq vlpAGruVy/4ZQ0sntqzxRMoXGfQggMo9zyaGM4KgYXvb6bYdsMbNp7QA9NY609dQaUKD r8vNoq404+7ddgcZO1r60vIMx7HES6bHBmBk94ns8NEg2TT9pdNRoao/Oryq7Tg+uD3f nACA== X-Gm-Message-State: AOAM532zsILQUyTfuQIqNpDCbUukP4USjMfnE7taZkoMBpx8wLSe3har 2fxozLicqT1L/aD8WxIbAjQpun1iSjBCfMzVfDd6dPYkesGOOA== X-Google-Smtp-Source: ABdhPJzTOVRfk6vEeU2oLCoJy06N3uxqch7M7wOfyYe+8PQACDWpvtY0WP0utHScxhILCzylPCWceR7H1c0bE1UPD6U= X-Received: by 2002:a37:a1cf:: with SMTP id k198mr16233538qke.409.1624164444071; Sat, 19 Jun 2021 21:47:24 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ash Wilson Date: Sat, 19 Jun 2021 21:47:12 -0700 Message-ID: To: Hannes Tschofenig Cc: "danish@ietf.org" Content-Type: multipart/alternative; boundary="000000000000bf00b805c52b400f" Archived-At: Subject: Re: [Danish] Charter Text and the Problem Statement X-BeenThere: danish@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DANE AutheNtication for Iot Service Hardening List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jun 2021 04:47:33 -0000 --000000000000bf00b805c52b400f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Jun 19, 2021 at 5:47 AM Hannes Tschofenig wrote: > Hi Ash, > > > > If the network access authentication use case with EAP-TLS is important t= o > you then I believe it would be good to add it as a milestone on the > charter. You cannot use an implementation of draft-ietf-emu-eap-tls13 and > assume any of the DANE functionality to work. You would indeed have to re= ly > on draft-ietf-tls-dnssec-chain-extension because not having network > connectivity is the main reason why you would be running the EAP-TLS > exchange in the first place. > The process of using DANE for authenticating an EAP-TLS supplicant, from the authentication server's perspective, is expected to be more straightforward. It is not unnatural for the authentication server to have the IP connectivity required to retrieve the TLSA record for authenticating the client's certificate. The complexity of getting DANE to work for allowing the supplicant to authenticate the authentication server is certainly more complicated, and also introduces a dependency on the DNSSEC chain extension. > > > Regarding =E2=80=9Cbest practice to ensure that a device is patched befor= e putting > it into production, and updating roots of trust fits within the scope of > that sort of activity=E2=80=9D: I don=E2=80=99t think there is any expect= ation that the > device will be updated before it is put in production (i.e. powered on fo= r > the first time). You can assume that the device, when it comes online for > the first time and reaches out to the device management server, gets a > firmware update. Having that firmware update happen before it is connecte= d > to the network is extremely unlikely. > > > EAP-TLS is also not an IoT device onboarding protocol. From the charter > text I am also not assuming that you are attempting to define a new IoT > onboarding protocol or do you? > We are being very careful with the scope of the charter, to stay focused on client authentication in the TLS handshake and public key discovery for authenticating messages. Addressing the nuances of EAP-TLS, especially for supporting TLS 1.3, seems like the sort of work we may want to re-charter to accomplish unless there's enough interest in the beginning to bring it in-scope. I'm very happy to hear that you're interested in how EAP-TLS will fit with this effort and I have no objection to including this in the charter, as long as the chairs are OK with it. > > > Regarding the home IoT environment: I would not count on CHIP/Matter > re-using your work. My understanding is that they are creating their own > solutions. Since the home environment is very fragmented, it might not be > the easiest place to start. Of course, your company may play and that fie= ld > and so you might have a way to get the outcome of DANISH deployed there. > > > I am still trying to figure out how DANISH fits into the larger picture > and hence I am looking forward to read an architecture document. Is the a > pre-draft available already? > The architecture document is very rough and not ready even for pre-draft review. I will prioritize improving this document and share it with you ASAP. > > > Ciao > > Hannes > > > > *From:* Ash Wilson > *Sent:* Thursday, June 17, 2021 8:22 PM > *To:* Hannes Tschofenig > *Cc:* danish@ietf.org > *Subject:* Re: [Danish] Charter Text and the Problem Statement > > > > Hi Hannes, > > Great questions, responses in-line below... > > > > On Wed, Jun 16, 2021 at 11:43 PM Hannes Tschofenig < > Hannes.Tschofenig@arm.com> wrote: > > Thanks for your feedback, Ash. > > > > It is interesting that you mention the network access authentication use > case. Do you envision EAP-TLS in combination with Danish to work > architecturally differently than the current EAP-TLS-based approach? > > > > We hope to minimize the amount of work required to enable DANE client ID > for EAP-TLS. Some challenges remain with EAP-TLS in conjunction with TLS > 1.3: https://datatracker.ietf.org/doc/html/draft-ietf-emu-eap-tls13-16. > Supporting TLS 1.2 for EAP-TLS and DANE would likely be more > straightforward, but I do not know whether there's much interest in > updating TLS 1.2 to cover this use case. > > > > DANE server authentication with EAP-TLS brings another challenge: the > absence of IP connectivity prior to authentication. This could be remedie= d > by > https://datatracker.ietf.org/doc/html/draft-ietf-tls-dnssec-chain-extensi= on-07, > if the work on that draft were to continue. There are also challenges wit= h > validating the chain, tied to root key rotation. Devices which remain > unplugged too long may not be able to authenticate. On the other hand, it > is a best practice to ensure that a device is patched before putting it > into production, and updating roots of trust fits within the scope of tha= t > sort of activity. > > > > If only DANE for client authentication is supported in EAP-TLS, which is > the likely initial outcome, the challenge of getting the authentication > server's CA certificate onto the device still exists. This still represen= ts > a reduction in effort on the part of the IT staff, but not a perfect > zero-touch onboarding unless the supplier also provisions the CA certs fo= r > the authentication server... and in the case of WiFi, the SSID to associa= te > with. Still, we think this represents a substantial improvement in the > onboarding experience for the implementer. > > > > > > You write: > > =E2=80=9CCredential issuance very often requires the device and the perso= n > bootstrapping the identity to be in the same place=E2=80=9D > > > > Binding the user to his or her device typically takes some time. It often > requires the user to log into some service and to =E2=80=9Cadd=E2=80=9D t= he new device > often by demonstrating physical possession. Of course, this is the way ho= w > it works for end consumer products, where scalability is less of an issue > because you are probably not going to buy thousands of smart coffee > machines. For a commercial setup, the process often works different but i= t > very much depends on the type of industry vertical you are in. There is > often a non-irrelevant configuration step involved as well. For example, > with commercial indoor lighting professionals need to configure different > lighting themes. > > > > I don=E2=80=99t see any of this user-related interaction being covered as= part of > the chartered work. > > > > DANE can be useful for home IoT. I think that it could reduce the > complexity of automation wherever private PKI is being managed in the > consumer's environment, and accelerate and simplify the onboarding > experience. IETF is accessible and wide-reaching, and seems like the righ= t > place to present and refine the design pattern that might be adopted late= r > by other standards (like CHIP/Matter). I'm also operating under the > assumption that enterprise IoT has a more recognized need for > interoperability and simpler secure onboarding processes. That is a big > assumption, and only based on my observations thus far. I'm open to > including the home consumer's perspective in this effort, if you think it= 's > worthwhile. > > > > > > As far as describing the general onboarding experience for the > implementer, I had hoped to include that in the architecture document alo= ng > with examples of how DANE might interface with and support other standard= s > in the broader ecosystem. In trying to keep the charter concise, I think = we > left out some important information. > > > > You bring up an interesting point, with the configuration of lighting > profiles during fixture installation. The expectation is that with DANE a= s > the authentication protocol, the variety of suppliers producing devices f= or > a given application might be able to agree on a format for representing > configuration information, and devices can securely retrieve it from the > system that manages the application's configuration. I think that it woul= d > be especially useful to show how DANE works with other discovery protocol= s > (mDNS, for instance) in the process of retrieving the device's > configuration. Where do you think this fits best? In the architecture > document, or would another format be a better fit for this? > > > > > > Ciao > > Hannes > > > > *From:* Ash Wilson > *Sent:* Wednesday, June 16, 2021 11:28 PM > *To:* Hannes Tschofenig > *Cc:* danish@ietf.org > *Subject:* Re: [Danish] Charter Text and the Problem Statement > > > > Hi Hannes, > > Thanks for the questions, and apologies for keeping you waiting on > answers/clarification. > > > > On Wed, Jun 16, 2021 at 4:12 AM Hannes Tschofenig < > Hannes.Tschofenig@arm.com> wrote: > > Hi all, > > > > I have been reading through the charter text in an attempt to understand > the problem statement. > > > > Two problems are mentioned: > > > > 1) Challenges with naming collisions in the IoT space. > > > > 2) Credential issuance is time consuming. > > > > Ad 1: Reading through the text it feels like naming collisions are a big = thing in IoT. I have not heard about those problems. Could you elaborate? > > Certainly. I'll use a hospital as an example environment. > > > > Within a hospital, it is desirable to implement 802.1x authentication > using EAP-TLS for access to protected networks. EAP-TLS enables the use o= f > PKI-based identity to authenticate an entity for network access. > > > > When implementing EAP-TLS for network access, RADIUS is a common > protocol/server used for authentication behind the switch or wireless > access point. Guidance for configuring RADIUS recommends the use of only > one CA certificate for authenticating supplicant certificates. This > guidance can be found in the wild in Freeradius configuration files for > EAP-TLS, related to the 'ca_file' configuration directive. > > > > CAs guarantee the uniqueness of an entity's name within the scope of the > CA, but have no method for enforcing name uniqueness across other CAs. Fo= r > instance, CA1 and CA2 may both sign certificates for entities with the sa= me > name. If CA1 and CA2 are both trusted by the RADIUS server, and two > entities named "medicaldevice123" exist, one per CA, then the resulting > ambiguity makes it difficult to appropriately apply access controls. This > ambiguity is mitigated by operating a single organizational PKI, and > requiring identities issued by that single organizational PKI for EAP-TLS > authentication. > > > > Onboarding devices to organizational PKI requires time and effort. > Oftentimes some sort of skilled labor and/or dedicated infrastructure for > automating the onboarding process is involved. DANE allows us to bind a D= NS > name to a public key, and mitigates the ambiguities introduced by the use > of multiple CAs. An organization can only issue working identities within > its own namespace in DNS. Since naming ambiguity can be mitigated using > DANE, we may now choose to use manufacturer-issued PKI, represented in DN= S, > for authenticating entities. > > > > From the hospital's standpoint, the IT staff no longer needs to manage th= e > process of onboarding devices to organizational PKI. The device arrives > on-site with an identity which can be immediately used for > network authentication. > > You add that =E2=80=9CIn response to the challenges related to > > ambiguity between identities issued by different CAs, application owners > > frequently choose to onboard IoT devices to a single CA.=E2=80=9D. Is tha= t a good or a bad development? > > It is a good development if the organization really wants to directly > manage all of the credentials for all of the application participants. Th= e > effort and rationale behind BRSKI (RFC 8995) suggests a desire to make > onboarding to organizational PKI easier to automate. > > > > If a supplier issues a trustworthy identity for a device, and DNS prevent= s > another PKI from issuing working credentials under the same name, then > issuing another identity via organizational PKI becomes superfluous. This > is where we think that time and effort can be saved, because the skills > required for onboarding do not need to include the management and issuanc= e > of identities under organizational PKI. > > > > Ad 2: Is it really true that credential issuance is time consuming? Why i= s > that? For whom is it time consuming? > > Credential issuance very often requires the device and the person > bootstrapping the identity to be in the same place. Some platforms and > protocols exist to make that process easier (like BRSKI) or less > human-involving. The time investment seems to be on the part of both the > manufacturer (in issuing the IDevID) as well as the organizational IT > staff, who manage the organizational PKI. > > > > Ciao > > Hannes > > > > PS: You use the term =E2=80=9CCertificate Authority (CA)=E2=80=9D. It is = actually called > =E2=80=9CCertification Authority=E2=80=9D. > > > > > > IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose the > contents to any other person, use it for any purpose, or store or copy th= e > information in any medium. Thank you. > > -- > Danish mailing list > Danish@ietf.org > https://www.ietf.org/mailman/listinfo/danish > > > > > -- > > *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 prohibit= ed > and may be unlawful. Please immediately notify the sender by replying to > this email and then delete it from your system. > > IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose the > contents to any other person, use it for any purpose, or store or copy th= e > information in any medium. Thank you. > > > > > -- > > *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 prohibit= ed > and may be unlawful. Please immediately notify the sender by replying to > this email and then delete it from your system. > IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose the > contents to any other person, use it for any purpose, or store or copy th= e > information in any medium. Thank you. > --=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. --000000000000bf00b805c52b400f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sat, Jun 19, 2021 at 5:47 AM Hanne= s Tschofenig <Hannes.Tschof= enig@arm.com> wrote:

Hi Ash,

=C2=A0

If the network access authentication use case with E= AP-TLS is important to you then I believe it would be good to add it as a m= ilestone on the charter. You cannot use an implementation of draft-ietf-emu= -eap-tls13 and assume any of the DANE functionality to work. You would indeed have to rely on draft-ietf-tls-dns= sec-chain-extension because not having network connectivity is the main rea= son why you would be running the EAP-TLS exchange in the first place.

The process of using DANE for authenticating an= EAP-TLS supplicant, from the authentication server's=C2=A0perspective,= is expected to be more straightforward. It is not unnatural for the authen= tication server to have the IP connectivity required to retrieve the TLSA r= ecord for=C2=A0authenticating the client's=C2=A0certificate. The comple= xity of getting DANE to work for allowing the supplicant to authenticate th= e authentication server is certainly more complicated, and also introduces = a dependency on the DNSSEC chain extension.

=C2=A0

Regarding =E2=80=9Cbest practice to ensure that a de= vice is patched before putting it into production, and updating roots of tr= ust fits within the scope of that sort of activity=E2=80=9D: I don=E2=80=99= t think there is any expectation that the device will be updated before it is put in production (i.e. powered on for the first time). You c= an assume that the device, when it comes online for the first time and reac= hes out to the device management server, gets a firmware update. Having tha= t firmware update happen before it is connected to the network is extremely unlikely.

=C2=A0

EAP-TLS is also not an IoT device onboarding protoco= l. From the charter text I am also not assuming that you are attempting to = define a new IoT onboarding protocol or do you?

We are being very careful with the scope of the charter, to stay focu= sed on client authentication in the TLS handshake and public key discovery = for authenticating messages. Addressing the nuances of EAP-TLS, especially = for supporting TLS 1.3, seems like the sort of work we may want to re-chart= er to accomplish unless there's enough interest in the beginning to bri= ng it in-scope. I'm very happy to hear that you're interested in ho= w EAP-TLS will=C2=A0fit with this effort and I have no objection to includi= ng this in the charter, as long as the chairs are OK with it.

=C2=A0

Regarding the home IoT environment: I would not coun= t on CHIP/Matter re-using your work. My understanding is that they are crea= ting their own solutions. Since the home environment is very fragmented, it= might not be the easiest place to start. Of course, your company may play and that field and so you might ha= ve a way to get the outcome of DANISH deployed there.=C2=A0

=

=C2=A0

I am still trying to figure out how DANISH fits into= the larger picture and hence I am looking forward to read an architecture = document. Is the a pre-draft available already?

=C2=A0The architecture document is very rough and not ready even for = pre-draft review.=C2=A0 I will prioritize improving this document and share= it with you ASAP.=C2=A0

=

=C2=A0

Ciao

Hannes

=C2=A0

From: Ash Wilson <ash.wilson@valimail.com>
Sent: Thursday, June 17, 2021 8:22 PM
To: Hannes Tschofenig <Hannes.Tschofenig@arm.com>
Cc: danish@ietf= .org
Subject: Re: [Danish] Charter Text and the Problem Statement<= u>

=C2=A0

Hi Hannes,

Great questions, responses in-line below...

=C2=A0

On Wed, Jun 16, 2021 at 11:43 PM Hannes Tschofenig &= lt;Hannes.Ts= chofenig@arm.com> wrote:

Thanks for your feedback, Ash.

=C2=A0

It is interesting that you mention the network acces= s authentication use case. Do you envision EAP-TLS in combination with Dani= sh to work architecturally differently than the current EAP-TLS-based approach?

=C2=A0

We hope to minimize the=C2=A0amount of work required= to enable DANE client ID for EAP-TLS. Some challenges remain with EAP-TLS = in conjunction with TLS 1.3: https://datatracker.ietf.org/doc/html/draft-ietf-emu-e= ap-tls13-16. Supporting TLS 1.2 for EAP-TLS and DANE would likely be mo= re straightforward, but I do not know whether there's much interest in updating TLS 1.2 to cover this use case.

=C2=A0

DANE server authentication with EAP-TLS brings anoth= er challenge: the absence of IP connectivity prior to authentication. This = could be remedied by=C2=A0https://datatra= cker.ietf.org/doc/html/draft-ietf-tls-dnssec-chain-extension-07, if the work on that draft were to continue. There are also challenges with= validating the chain, tied to root key rotation. Devices which remain unpl= ugged too long may not be able to authenticate. On the other hand, it is a = best practice to ensure that a device is patched before putting it into production, and updating roots of trust = fits within the scope of that sort of activity.

=C2=A0

If only DANE for client authentication is supported = in EAP-TLS, which is the likely initial outcome, the challenge of getting t= he authentication server's CA certificate onto the device still exists.= This still represents a reduction in effort on the part of the IT staff, but not a perfect zero-touch onboardin= g unless the supplier also provisions the CA certs for the authentication s= erver... and in the case of WiFi, the SSID to associate with. Still, we thi= nk this represents a substantial improvement in the onboarding experience for the=C2=A0implementer.<= u>

=C2=A0

=C2=A0

You write:

=E2=80=9CCredential issuance very often requires the= device and the person bootstrapping the identity to be in the same place= =E2=80=9D

=C2=A0

Binding the user to his or her device typically take= s some time. It often requires the user to log into some service and to =E2= =80=9Cadd=E2=80=9D the new device often by demonstrating physical possession. Of course, this is the way how it works for end consumer produ= cts, where scalability is less of an issue because you are probably not goi= ng to buy thousands of smart coffee machines. For a commercial setup, the p= rocess often works different but it very much depends on the type of industry vertical you are in. There is= often a non-irrelevant configuration step involved as well. For example, w= ith commercial indoor lighting professionals need to configure different li= ghting themes.

=C2=A0

I don=E2=80=99t see any of this user-related interac= tion being covered as part of the chartered work.

=C2=A0

DANE can be useful for home IoT. I think that it cou= ld reduce the complexity of automation wherever private PKI is being manage= d in the consumer's environment, and accelerate and simplify the onboar= ding experience. IETF is accessible and wide-reaching, and seems like the right place to present and refine the de= sign pattern that might be adopted later by other standards (like CHIP/Matt= er). I'm also operating under the assumption that enterprise IoT has a = more recognized need for interoperability and simpler secure=C2=A0onboarding processes. That is a big assumption, an= d only based on my observations thus far. I'm open to including the hom= e consumer's perspective in this effort, if you think it's worthwhi= le.

=C2=A0

=C2=A0

As far as describing the general onboarding experien= ce for the implementer, I had hoped to include that in the architecture doc= ument along with examples of how DANE might interface with and support othe= r standards in the broader ecosystem. In trying to keep the charter concise, I think we left out some important = information.

=C2=A0

You bring up an interesting point, with the configur= ation of lighting profiles during fixture installation. The expectation is = that with DANE as the authentication protocol, the variety of suppliers pro= ducing devices for a given application might be able to agree on a format for representing configuration informat= ion, and devices can securely retrieve it from the system that manages=C2= =A0the application's configuration. I think that it would be especially= useful to show how DANE works with other discovery protocols (mDNS, for instance) in the process of retrieving the device'= ;s configuration. Where do you think this fits best? In the architecture do= cument, or would another format be a better fit for this?

=C2=A0

=C2=A0

Ciao

Hannes

=C2=A0

From: Ash Wilson <ash.wilson@valimail.com>
Sent: Wednesday, June 16, 2021 11:28 PM
To: Hannes Tschofenig <Hannes.Tschofenig@arm.com>
Cc: danish@ietf= .org
Subject: Re: [Danish] Charter Text and the Problem Statement<= u>

=C2=A0

Hi Hannes,

Thanks for the questions, and apologies for keeping = you waiting on answers/clarification.

=C2=A0

On Wed, Jun 16, 2021 at 4:12 AM Hannes Tschofenig &l= t;Hannes.Tsc= hofenig@arm.com> wrote:

Hi all,

=C2=A0

I have been reading through the charter text in an attempt t= o understand the problem statement.

=C2=A0

Two problems are mentioned:

=C2=A0

1)=C2=A0 C= hallenges with naming collisions in the IoT space.

=C2= =A0

2)=C2=A0 C= redential issuance is time consuming.

=C2=A0

Ad 1: Reading through the text it feels like naming collisions are a b=
ig thing in IoT. I have not heard about those problems. Could you elaborate=
?

Certainly. I'll use a hospital as an example env= ironment.

=C2=A0

Within a hospital, it is desirable to implement 802.= 1x authentication using EAP-TLS for access to protected networks. EAP-TLS e= nables the use of PKI-based identity to=C2=A0authenticate an entity for network access.

=C2=A0

When implementing EAP-TLS for network access, RADIUS= is a common protocol/server used for authentication behind the switch or w= ireless access point. Guidance for configuring RADIUS recommends the use of only one CA certificate for authenticating supplican= t=C2=A0certificates. This guidance can be found in the wild in Freeradius c= onfiguration files for EAP-TLS, related to the 'ca_file' configurat= ion directive.=C2=A0

=C2=A0

CAs guarantee the uniqueness of an entity's name= within the scope of the CA, but have no method for enforcing name uniquene= ss across other=C2=A0CAs. For instance, CA1 and CA2 may both sign certificates=C2=A0for entities with the same name. If CA1 and CA2 are= both trusted by the RADIUS server, and two entities named "medicaldev= ice123" exist, one per CA, then the resulting ambiguity makes it diffi= cult to appropriately apply access controls. This ambiguity is=C2=A0mitigated by operating a single organizational PKI, and = requiring identities issued by that single organizational PKI for EAP-TLS a= uthentication.=C2=A0

=C2=A0

Onboarding devices to organizational PKI requires ti= me and effort. Oftentimes some sort of skilled labor and/or dedicated infra= structure for automating the onboarding process is involved. DANE allows us to bind a DNS name to a public key, and mitigates= the ambiguities introduced by the use of multiple CAs. An organization can= only issue working identities within its own namespace in DNS. Since namin= g ambiguity can be mitigated using DANE, we may now choose to use manufacturer-issued PKI, represented in DNS= , for authenticating entities.

=C2=A0

From the hospital's standpoint, the IT staff no = longer needs to manage the process of onboarding devices to organizational = PKI. The device arrives on-site with an identity which can be immediately used for network=C2=A0authentication.

You add that =E2=80=9CIn response to the challenges related to<=
u>
ambiguity between identities issued by different CAs, application owne=
rs
frequently choose to onboard IoT devices to a single CA.=E2=80=9D. Is =
that a good or a bad development?=C2=A0

It is a good development if the organization really = wants to directly manage all of the credentials for all of the application = participants. The effort and rationale behind BRSKI (RFC 8995) suggests a desire to make onboarding to organizational PKI easi= er to automate.=C2=A0

=C2=A0

If a supplier issues a trustworthy identity for a de= vice, and DNS prevents another PKI from issuing working credentials under t= he same name, then issuing another identity via organizational PKI becomes superfluous. This is where we think that time and effort can b= e saved, because the skills required for onboarding do not need to include = the management and issuance of identities under organizational PKI.<= u>

=C2=A0

Ad 2: Is it really true that credential issuance is time con= suming? Why is that? For whom is it time consuming?

Credential issuance very often requires the device a= nd the person bootstrapping the identity to be in the same place. Some plat= forms and protocols exist to make that process easier (like BRSKI) or less human-involving. The time investment seems to be on t= he part of both the manufacturer (in issuing the IDevID) as well as the org= anizational IT staff, who manage the organizational PKI.=C2=A0

=C2=A0

Ciao

Hannes

=C2=A0

PS: You use the term =E2=80=9CCertificate Authority (CA)=E2= =80=9D. It is actually called =E2=80=9CCertification Authority=E2=80=9D.

=C2=A0

=C2=A0

IMPORTANT NOTICE: The contents of this email and any= attachments are confidential and may also be privileged. If you are not th= e intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpo= se, or store or copy the information in any medium. Thank you.

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


=C2=A0

--

Ash Wilson | Technical Director

e: ash.wilson@val= imail.com

This email and all data tra= nsmitted with it contains confidential and/or proprietary information inten= ded 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 inf= ormation included in this transmission is prohibited and may be unlawful. P= lease immediately notify the sender by replying to this email and then delete it from your system.

IMPORTANT NOTICE: The contents of this email and any= attachments are confidential and may also be privileged. If you are not th= e intended recipient, please notify the sender immediately and do not discl= ose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Th= ank you.


=C2=A0

--

Ash Wilson | Technical Director

e: ash.wilson@val= imail.com

This email and all data tra= nsmitted with it contains confidential and/or proprietary information inten= ded 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 inf= ormation included in this transmission is prohibited and may be unlawful. P= lease immediately notify the sender by replying to this email and then delete it from your system.

IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in any medium. Thank you.


--

Ash Wilson | Technical Dire= ctor

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

--000000000000bf00b805c52b400f-- From nobody Sun Jun 20 01:12:57 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 C6A963A210D for ; Sun, 20 Jun 2021 01:12:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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=armh.onmicrosoft.com header.b=dZJj6Q3F; dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=dZJj6Q3F 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 yJN2Hy1jwCvz for ; Sun, 20 Jun 2021 01:12:50 -0700 (PDT) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40061.outbound.protection.outlook.com [40.107.4.61]) (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 8767C3A20D7 for ; Sun, 20 Jun 2021 01:12:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=aRXVQG+/Y/jawRmwPL3u+cKOqJB6QI2J2BejoBEY9qU=; b=dZJj6Q3F3Sfy6+Cgfx4dMKzV8BI+uOJr0PF6SNH9Zn68qmVl6V+MSyIpPdzuSQpqOrRQIfNvnky3BixUYInjYgimyU0TgotkBILMT2EmWBk3igqNrM+fxS/AwFxM8B3m/zYbHQXZ0YXACZgi37KZLfXZ0szzQTqm2L6hq8n2gVk= Received: from AM5PR1001CA0060.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:206:15::37) by VI1PR08MB4511.eurprd08.prod.outlook.com (2603:10a6:803:f9::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4242.19; Sun, 20 Jun 2021 08:12:45 +0000 Received: from AM5EUR03FT042.eop-EUR03.prod.protection.outlook.com (2603:10a6:206:15:cafe::b4) by AM5PR1001CA0060.outlook.office365.com (2603:10a6:206:15::37) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4242.16 via Frontend Transport; Sun, 20 Jun 2021 08:12:45 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; ietf.org; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com;ietf.org; dmarc=pass action=none header.from=arm.com; Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 63.35.35.123 as permitted sender) receiver=protection.outlook.com; client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com; Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by AM5EUR03FT042.mail.protection.outlook.com (10.152.17.168) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4242.16 via Frontend Transport; Sun, 20 Jun 2021 08:12:45 +0000 Received: ("Tessian outbound f945d55369ce:v96"); Sun, 20 Jun 2021 08:12:44 +0000 X-CR-MTA-TID: 64aa7808 Received: from 21e784386f29.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 251DA052-31E7-4B3C-9FCC-9B2F654A08C6.1; Sun, 20 Jun 2021 08:12:38 +0000 Received: from EUR05-VI1-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 21e784386f29.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Sun, 20 Jun 2021 08:12:38 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=IX0/BGyrewyE97hWpyVxd1Y+guH0/GtPcA8Rbwqh7mS+U5z2kQipc7b14cF8BSfH0GTu/5V4iZCK93an7D2Vtl+6y4UgT84YXyGn7WM1irGIDMeRDwfZ/I6irQoBjIChKHIYQgtNrdMoGO9TiEYd8wQdz3vkEQnkEYAjeF+BfT63gBgA3ocoXLYsZGYvOO//Gf/TcVmNKLEdZ6gsEaeTIJnL/rMjCimdVLO2GGjmtaE4vu+tpMJosqiONXnVC2JrwSys0F8WYPe6piwkjZUrQTDCDE7rqiPJIfoMUWVkab29MmPYqHqTgh9gOPOBCERYEhZ+3WIs5MpdfJomxatAaw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=aRXVQG+/Y/jawRmwPL3u+cKOqJB6QI2J2BejoBEY9qU=; b=ALi7Ne6OUMDIivPdCFJpYWhN+oRZ6Ef8ogGUxUKcUH4ltx8EXBsB+rlh9b6J6v35hwodgvs4QgjguJbdmAPUcnDK6Rkj5ZNgw6upUuiw6IvXFKPEQ4zwf1HwxYDdCiD57Rtp/5geb9Hkx7P+Ac/go0QiQ1cxX/hUmyIww00YVdndLBQW45YaPo17OVRADZkNNv4EXOiI05iTGp8WC7UuW2ao9eZUn4kkm7koCcrUXqHn5PW/ApWrOLgC1PFj6qeHndROuJ1Zzq4wWxDAF8szj33sFJbJPlixxm63W+Hc28gIPGeyai7e5edOK99W51Wt7tv/eYKZoKKQNz0p9Dfeig== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=aRXVQG+/Y/jawRmwPL3u+cKOqJB6QI2J2BejoBEY9qU=; b=dZJj6Q3F3Sfy6+Cgfx4dMKzV8BI+uOJr0PF6SNH9Zn68qmVl6V+MSyIpPdzuSQpqOrRQIfNvnky3BixUYInjYgimyU0TgotkBILMT2EmWBk3igqNrM+fxS/AwFxM8B3m/zYbHQXZ0YXACZgi37KZLfXZ0szzQTqm2L6hq8n2gVk= Received: from DBBPR08MB5915.eurprd08.prod.outlook.com (2603:10a6:10:20d::17) by DB9PR08MB6585.eurprd08.prod.outlook.com (2603:10a6:10:250::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4242.18; Sun, 20 Jun 2021 08:12:37 +0000 Received: from DBBPR08MB5915.eurprd08.prod.outlook.com ([fe80::69cf:4429:a804:7f41]) by DBBPR08MB5915.eurprd08.prod.outlook.com ([fe80::69cf:4429:a804:7f41%3]) with mapi id 15.20.4242.023; Sun, 20 Jun 2021 08:12:37 +0000 From: Hannes Tschofenig To: Michael Richardson , "danish@ietf.org" Thread-Topic: [Danish] Charter Text and the Problem Statement Thread-Index: Addin8Z32g6ibl9RQiW6iIvXVU0WhwAVq2gAABL3x4AAGNNDAAAroAeQAD1ePYAAGAHboA== Date: Sun, 20 Jun 2021 08:12:37 +0000 Message-ID: References: <23295.1624134481@localhost> In-Reply-To: <23295.1624134481@localhost> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ts-tracking-id: DCE41BEB30CDAF468476A6D05A2D3900.0 x-checkrecipientchecked: true Authentication-Results-Original: sandelman.ca; dkim=none (message not signed) header.d=none; sandelman.ca; dmarc=none action=none header.from=arm.com; x-originating-ip: [80.92.123.248] x-ms-publictraffictype: Email X-MS-Office365-Filtering-Correlation-Id: 84d05c6a-4eac-407e-a9cb-08d933c32f36 x-ms-traffictypediagnostic: DB9PR08MB6585:|VI1PR08MB4511: X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true nodisclaimer: true x-ms-oob-tlc-oobclassifiers: OLM:9508;OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: buiu/WD3mTxEr7VgirqgjAafMLlj9Kg8jhzKjvf5gJm9b3yzxASq7q521zkhImFfb7g5uA+XDh4y1fT/UpIvGrss3dyt6hGkZ9KMD++11Dahu7Dp5ogUw49tDMEMapHaq4E4bOTtHPNnsdmUzfQOb+xsWp4x/TdD1q9UV/cMQFMB8UL73Q8hz+nuv6RzIV7L6cIJYahvckDzJlDF2xlhwD3MQJJ9YmTaJs1/n87SfvmTPM9sT5JtLVOeNkhhbMCCbSiOZQ0FYWvYyqjC7TFWbT/hfTkf6SKLmgCoIO/hgEQwLFKCKenP7K2Hkv9umlGalKHQLYx2io3Ff9JDnEpWaepJ3HqHCJWj65m9r6Q62q6wkqIh3uSvSCIvJ2g9W9pRsqptnmCDGldjDPAG41j/KgQmgaaV7M/+AVYIErIjCwZ08KoX926dUkhTfxVBvmgkPnBpTXAg9saTz2UuzjUoeDzPBopYXry0zRXmQnlm364UqnfB86ci1gu+zxShfeJMyI2QPVbiGuL+UnDhQDs1tfiC4/ezZ40As2ZK0+i4iBhSCq6m54f+EV4wkHsuH0RjKFq7D9cJT+mLcXEYl96/u7F/P12KbegHxwactT2+Qg8= X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DBBPR08MB5915.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(396003)(39840400004)(136003)(346002)(376002)(366004)(478600001)(122000001)(186003)(53546011)(2906002)(66476007)(64756008)(66574015)(66946007)(7696005)(66446008)(8936002)(66556008)(316002)(9686003)(76116006)(83380400001)(38100700002)(86362001)(26005)(6506007)(55016002)(33656002)(8676002)(110136005)(71200400001)(5660300002)(52536014); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?aTQxTWE3ZmNKeWF1Z2p2a2p5NlBCaXNsZ0paQnJicmdxeUhCNC81ZW1PamI0?= =?utf-8?B?dFhzYnAwdk1nbEdWL1dpL2VuSHNlZWtCWVhqL1laSnZMRjNvOEl2VEN4Z1Jt?= =?utf-8?B?TDNoN3ZHcnRkaEdmYTJheXB3L2NOK0lEcEpiMlRObDRHdVlXMmMza01yU1Ni?= =?utf-8?B?dGk0QXdsM0VscEdpYWNiOHEvbmVSalRRK3kwMGxSVTVBaGNOb3pTazlRTjhJ?= =?utf-8?B?cUdsbjZlQVYrbmcwenppM3ZjTjF2ckdkUkhsOGJudGd4d1dnSEhSQlA4eGRn?= =?utf-8?B?N3NvOFRMR1hzWDQ1TkxrSjl2YzU3ZnJBME5BdVFLM3NsTmMwMFFNcDZPODJG?= =?utf-8?B?blYxK3k5L0MwV084MnVqTHZWZDhtNjlST2taWGFOS1JKVC81Q2VlSnA5NFRH?= =?utf-8?B?cE9Wa2VMNXhuSXBQWTZSY0c2cUpxQ2xYMW9rMTFKZHZEOHBPdkZ6VGFCTU5y?= =?utf-8?B?MFJ3VVdnOXhhQXpOUXdKcG8vSnNuNWNOUXNnaXNMREt5K3VSZnRiaFJpYXpz?= =?utf-8?B?RkswRlozNStFd2I0cjR5dW9lVEt4Y0lseExtZHBxTlFVRzRuT2xNM0NOenE0?= =?utf-8?B?OWh5azVZd3ZmUHFET3IzSTBLalZtSm5jYTYyV3I1MGxOdDNDMDgxekNDNXQ3?= =?utf-8?B?ell3dGI5SGpLcEdNY21FTUlXMUc0UEtHYnFHWkRoYUpFQ01oWENlbEpwREhi?= =?utf-8?B?cHFTWHZhRUc1SnZGblFCTENIK0s2WEZMYkEzVXZtMS9LQ25YRnRQN1lUQ0JT?= =?utf-8?B?RGJoL0NPWisrZzh1VkU2YlhnVjd5T1liUWVLWGQ0ZWx1VFBSRkNhQzRSbERL?= =?utf-8?B?L1VnbzdpVE9KV205dnBwb0JEL0FUVWUrc0RpRExPS052MXRVZjgybUVlZ1hz?= =?utf-8?B?dURxekl0SklzY0pSV1FGSGNLb080MFhHa2N2YWRUVUwxNFRUMFljakhKSnhm?= =?utf-8?B?OHlpV0dnWkx0eHZQc281SDQxdnBzSEk3c2tmdWhETGdvM3U1blhhanBiUCti?= =?utf-8?B?TDZiTkhtQ00weE1DL3RoWlNpZ2hzaW1yVE9lMW1CQWd2dGRpNFFVelRvNGM4?= =?utf-8?B?Z2JVK0pmdlR6RTlHREo0Y2NKcitSdjQvTjJoWk5Bd3o4UG8vamR1UHI4T1Ft?= =?utf-8?B?VHFGR1UyWWtWK1QwbllCY014WWY2ODVWUDFKL2Vsd3Avdy9QcTBOUnFwSW54?= =?utf-8?B?VzF4WXpsQzBGWnZIbFRUVWNVNTJQZWhBb3BJdzVSdVF3TGR4bmE0L3lDbk5H?= =?utf-8?B?TDdnaDdwL2xCT0xOTUpxRk9hSTBOM1F0VWlPZGlnODFyS21XMHRHZkx6OWNz?= =?utf-8?B?SFFHN2c2Vm1xSGdjRVhLK2tFRnR0YjZUbVJjLzJ1UldUVnFYV1dSem5RYVNG?= =?utf-8?B?RHZPdjdoVHRFSnhmcUxxc2J6bWU4cm5BakNmNDliMFZGL3kzN29oSnRzVEpv?= =?utf-8?B?Tzh1eWlqSGR0dWJYajhWUDdnckJoZmhvWlFXRzMzU3dKMlZ2eXVWejBPbSsy?= =?utf-8?B?bXZZU3p1Q2VjTFQyRmJrV1FQaVB0MnJNTFZDTHAvYng4RXJkNUQ1TENiSWRU?= =?utf-8?B?YWZUb0IvOXQrUTlWdG1JSzlLeFdtN2xSaDdBN1krbTU0NXBrQ09vYmxHbnM1?= =?utf-8?B?SEVXbGtxbk5WaVE1MEtkNjA5N0RPMzJRR3pYVkU0VmtkRkNmZmtyczJURDhk?= =?utf-8?B?N0g2L0RSY29ZRlBZY0w3VkpqSWp2MWRyT3hwSjBXQm15U2lTZGZzd21GemdK?= =?utf-8?Q?Ejucd5+0GsnPhhm6FjKDzxsHSSCkPsV/JpEhAQO?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB9PR08MB6585 Original-Authentication-Results: sandelman.ca; dkim=none (message not signed) header.d=none; sandelman.ca; dmarc=none action=none header.from=arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: AM5EUR03FT042.eop-EUR03.prod.protection.outlook.com X-MS-Office365-Filtering-Correlation-Id-Prvs: d84a7909-7d78-40f2-a6e8-08d933c32a61 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: QHn0F+yO2SgWd5Nn78yHqjbw6K/KT9fso9Q7J+164I7BUQGSvDc9Z3Nuyct0OSiP2lRXtQlXxsm8nctKhZphOcfzNHHF5QF7JVk3EsjJU5S0GxJo9CCxxs19u9Zto4uqlXVEe36IubYIBVwryv11LZY05+4SGWnOJVWAxw1H7k8x6aDa1JZV+uknrDgXVQ/zVzFwmNViheHvCF4B9ygPoM7L3yXIdChhf3/yNzf7cCFGjwP5sFRWpsSAuZMhIwTSHaRmfyIr2c9OgBP6BWCafbWcfloTrAnIb/DFbvSj/cTDMiPl5ikBrNyhJSjdqAJRPQwlJWk7neG54ZFa/LyZeaf2XXrAQ3lspeI8dK1QaHcdAMmZg9pl5UUmjuOdKVxNcq3HDl0/PR84Mkh0CDC9mduC4a2yFNM7+ShVPrIRRcNRpMpia+TFgsX8y/W/noy5pLBQ7Whm26XBGJIEFbEkbBba1nlDemHcwWQggelSKNP1FhM+gYiqPwK+ER3z9qCnp5twoG4BUw8dFQSF3XOtZ/Ww5HvwNtopQN3XvA4CY1yOWDOqec/OgslOTVib7HP8gl+N42u/Be+wa8EAwPGZVlZasXd6cv+xJZe2qNzM6QiBWFDJ7TUiGLdsjgX5dgEqnY0+B/zrQfioVkyWUGvByK5A6unzNHFaCi9vOCtdFvk= X-Forefront-Antispam-Report: CIP:63.35.35.123; CTRY:IE; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:64aa7808-outbound-1.mta.getcheckrecipient.com; PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; CAT:NONE; SFS:(4636009)(396003)(136003)(346002)(39840400004)(376002)(36840700001)(46966006)(26005)(9686003)(52536014)(33656002)(186003)(8676002)(5660300002)(8936002)(478600001)(2906002)(6506007)(53546011)(55016002)(7696005)(36860700001)(81166007)(356005)(82310400003)(66574015)(47076005)(316002)(86362001)(70586007)(70206006)(83380400001)(336012)(110136005); DIR:OUT; SFP:1101; X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Jun 2021 08:12:45.2742 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 84d05c6a-4eac-407e-a9cb-08d933c32f36 X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d; Ip=[63.35.35.123]; Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com] X-MS-Exchange-CrossTenant-AuthSource: AM5EUR03FT042.eop-EUR03.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR08MB4511 Archived-At: Subject: Re: [Danish] Charter Text and the Problem Statement X-BeenThere: danish@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DANE AutheNtication for Iot Service Hardening List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jun 2021 08:12:56 -0000 SGkgTWljaGFlbCwNCg0KWW91IG1lbnRpb24gIkVBUC1URUFQLUJSU0tJIiwgYW5vdGhlciB0ZWNo bm9sb2d5IHdoZXJlIEkgZG8gbm90IHByZWNpc2VseSBrbm93IGhvdyBpdCBpcyBzdXBwb3NlZCB0 byBmaXQgaW50byB0aGUgREFOSVNIIHdvcmsgKGlmIGF0IGFsbCkuDQoNCkkgc3RhcnRlZCB3aXRo IGEgc2ltcGxlIHRhc2s6IEkgcmVhZCB0aHJvdWdoIHRoZSBjaGFydGVyIHRleHQuIEkgZGlkbid0 IHVuZGVyc3Rvb2QgdGhlIHByb2JsZW0gc3RhdGVtZW50LiBUaGVuLCBJIGxvb2tlZCB0aHJvdWdo IHRoZSBtYWlsaW5nIGxpc3QgYW5kIGF0IHRoZSBzbGlkZXMgcHJlc2VudGVkIGF0IHRoZSBsYXN0 IG1lZXRpbmcuIEkgY2FuIGZpbmQgYSBsb3Qgb2Ygc29sdXRpb24gZGlzY3Vzc2lvbnMgYnV0IGxp dHRsZSBkaXNjdXNzaW9uIGFib3V0IHRoZSBwcm9ibGVtLg0KDQpJIGJlbGlldmUgSSBzaG91bGQg dW5kZXJzdGFuZCB0aGUgcHJvYmxlbSBzaW5jZSBJIGhhdmUgYmVlbiB3b3JraW5nIGluIHRoaXMg ZG9tYWluIGZvciBtYW55IHllYXJzLiBJdCBpcyBtb3N0IGxpa2VseSB0aGF0IHRoZSBwcm9ibGVt IGhhcyBiZWVuIHNvbHZlZCBhbHJlYWR5IG1hbnkgdGltZXMgYmVmb3JlIChzaW5jZSBJb1QgaXMg bm90IHJlYWxseSBhIG5ldyBmaWVsZCBhbnltb3JlKS4gTWF5YmUgdGhlIHByb3Bvc2VkIHNvbHV0 aW9uIGdpdmVzIGEgbmV3IHNwaW4gdG8gaXQuIE1heWJlIG5vdC4NCg0KSWYgdGhlIHByb2JsZW0g Y2Fubm90IGJlIGRlc2NyaWJlZCBwcm9wZXJseSB0aGVuIHRoZXJlIHdpbGwgYmUgYSBsb3Qgb2Yg cHJvYmxlbXMgbGF0ZXIgaW4gdGhpcyBncm91cC4gVGhlIHByb2JsZW0gZGVzY3JpcHRpb24gd2ls bCBhbHNvIGhlbHAgdG8gdW5kZXJzdGFuZCB3aG8gaW4gdGhlIGVjb3N5c3RlbSBuZWVkcyB0byBk byBzb21ldGhpbmcgdG8gdHVybiB0aGlzIGludG8gYSByZWFsaXR5Lg0KDQpDaWFvDQpIYW5uZXMN Cg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IE1pY2hhZWwgUmljaGFyZHNvbiA8 bWNyK2lldGZAc2FuZGVsbWFuLmNhPg0KU2VudDogU2F0dXJkYXksIEp1bmUgMTksIDIwMjEgMTA6 MjggUE0NClRvOiBIYW5uZXMgVHNjaG9mZW5pZyA8SGFubmVzLlRzY2hvZmVuaWdAYXJtLmNvbT47 IGRhbmlzaEBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtEYW5pc2hdIENoYXJ0ZXIgVGV4dCBhbmQg dGhlIFByb2JsZW0gU3RhdGVtZW50DQoNCg0KSGFubmVzIFRzY2hvZmVuaWcgPEhhbm5lcy5Uc2No b2ZlbmlnQGFybS5jb20+IHdyb3RlOg0KICAgID4gUmVnYXJkaW5nIOKAnGJlc3QgcHJhY3RpY2Ug dG8gZW5zdXJlIHRoYXQgYSBkZXZpY2UgaXMgcGF0Y2hlZCBiZWZvcmUNCiAgICA+IHB1dHRpbmcg aXQgaW50byBwcm9kdWN0aW9uLCBhbmQgdXBkYXRpbmcgcm9vdHMgb2YgdHJ1c3QgZml0cyB3aXRo aW4gdGhlDQogICAgPiBzY29wZSBvZiB0aGF0IHNvcnQgb2YgYWN0aXZpdHnigJ06IEkgZG9u4oCZ dCB0aGluayB0aGVyZSBpcyBhbnkgZXhwZWN0YXRpb24NCiAgICA+IHRoYXQgdGhlIGRldmljZSB3 aWxsIGJlIHVwZGF0ZWQgYmVmb3JlIGl0IGlzIHB1dCBpbiBwcm9kdWN0aW9uDQogICAgPiAoaS5l LiBwb3dlcmVkIG9uIGZvciB0aGUgZmlyc3QgdGltZSkuIFlvdSBjYW4gYXNzdW1lIHRoYXQgdGhl IGRldmljZSwNCiAgICA+IHdoZW4gaXQgY29tZXMgb25saW5lIGZvciB0aGUgZmlyc3QgdGltZSBh bmQgcmVhY2hlcyBvdXQgdG8gdGhlIGRldmljZQ0KICAgID4gbWFuYWdlbWVudCBzZXJ2ZXIsIGdl dHMgYSBmaXJtd2FyZSB1cGRhdGUuIEhhdmluZyB0aGF0IGZpcm13YXJlIHVwZGF0ZQ0KICAgID4g aGFwcGVuIGJlZm9yZSBpdCBpcyBjb25uZWN0ZWQgdG8gdGhlIG5ldHdvcmsgaXMgZXh0cmVtZWx5 IHVubGlrZWx5Lg0KDQpPbmUgY2FuIG9uYm9hcmQgb250byBhIHF1YXJhbnRpbmUgbmV0d29yayBv biB3aGljaCBmaXJtd2FyZSB1cGRhdGVzIGNhbiBvY2N1ciwgYW5kIHRoZW4gbW92ZSB0byB0aGUg cHJvZHVjdGlvbiBuZXR3b3JrLg0KDQogICAgPiBFQVAtVExTIGlzIGFsc28gbm90IGFuIElvVCBk ZXZpY2Ugb25ib2FyZGluZyBwcm90b2NvbC4gRnJvbSB0aGUgY2hhcnRlcg0KICAgID4gdGV4dCBJ IGFtIGFsc28gbm90IGFzc3VtaW5nIHRoYXQgeW91IGFyZSBhdHRlbXB0aW5nIHRvIGRlZmluZSBh IG5ldyBJb1QNCiAgICA+IG9uYm9hcmRpbmcgcHJvdG9jb2wgb3IgZG8geW91Pw0KDQpZZXMsIGJ1 dCBzZXZlcmFsIHBlb3BsZSBhcmUgdHJ5aW5nIHRvIGRvIEVBUC1URUFQLUJSU0tJLg0KDQogICAg PiBJIGFtIHN0aWxsIHRyeWluZyB0byBmaWd1cmUgb3V0IGhvdyBEQU5JU0ggZml0cyBpbnRvIHRo ZSBsYXJnZXIgcGljdHVyZQ0KICAgID4gYW5kIGhlbmNlIEkgYW0gbG9va2luZyBmb3J3YXJkIHRv IHJlYWQgYW4gYXJjaGl0ZWN0dXJlIGRvY3VtZW50LiBJcyB0aGUNCiAgICA+IGEgcHJlLWRyYWZ0 IGF2YWlsYWJsZSBhbHJlYWR5Pw0KDQpJIGRvbid0IHRoaW5rIHNvLCBidXQgbWF5YmUgdGhhdCB3 b3VsZCBiZSBhIGdvb2QgZGlyZWN0aW9uIHRvIGNvbnNpZGVyLg0KDQotLQ0KTWljaGFlbCBSaWNo YXJkc29uIDxtY3IrSUVURkBzYW5kZWxtYW4uY2E+ICAgLiBvIE8gKCBJUHY2IEnDuFQgY29uc3Vs dGluZyApDQogICAgICAgICAgIFNhbmRlbG1hbiBTb2Z0d2FyZSBXb3JrcyBJbmMsIE90dGF3YSBh bmQgV29ybGR3aWRlDQpJTVBPUlRBTlQgTk9USUNFOiBUaGUgY29udGVudHMgb2YgdGhpcyBlbWFp bCBhbmQgYW55IGF0dGFjaG1lbnRzIGFyZSBjb25maWRlbnRpYWwgYW5kIG1heSBhbHNvIGJlIHBy aXZpbGVnZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBu b3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBhbmQgZG8gbm90IGRpc2Nsb3NlIHRoZSBjb250 ZW50cyB0byBhbnkgb3RoZXIgcGVyc29uLCB1c2UgaXQgZm9yIGFueSBwdXJwb3NlLCBvciBzdG9y ZSBvciBjb3B5IHRoZSBpbmZvcm1hdGlvbiBpbiBhbnkgbWVkaXVtLiBUaGFuayB5b3UuDQo= From nobody Sun Jun 20 01:19:00 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 24D9B3A2135 for ; Sun, 20 Jun 2021 01:18:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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=armh.onmicrosoft.com header.b=plpyKv8w; dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=plpyKv8w 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 zIaI6CqdEIDs for ; Sun, 20 Jun 2021 01:18:52 -0700 (PDT) Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10042.outbound.protection.outlook.com [40.107.1.42]) (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 BDB2A3A2134 for ; Sun, 20 Jun 2021 01:18:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=vJIoEfnUvwqETBpE7fpdmqoZnfbhHnVE/ch84IkAa4U=; b=plpyKv8wXJEwURZ+nqxH0Py84q+n4Etl+K8b8sYnh24C3MnmL2g3ecXC/iBZQRCYvdezlR+d8Kw9bIudi0rDTSsYU90PFiY/RiNlcRaqpOExxLXg/erc8g8hv2PQp1zjtj+tQB65twS38/0JKdJ5fMLtNLUchEPqaJXSCKrwkyA= Received: from DB6PR07CA0015.eurprd07.prod.outlook.com (2603:10a6:6:2d::25) by AM0PR08MB4324.eurprd08.prod.outlook.com (2603:10a6:208:144::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4242.16; Sun, 20 Jun 2021 08:18:46 +0000 Received: from DB5EUR03FT043.eop-EUR03.prod.protection.outlook.com (2603:10a6:6:2d:cafe::5b) by DB6PR07CA0015.outlook.office365.com (2603:10a6:6:2d::25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4264.7 via Frontend Transport; Sun, 20 Jun 2021 08:18:46 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; ietf.org; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com;ietf.org; dmarc=pass action=none header.from=arm.com; Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 63.35.35.123 as permitted sender) receiver=protection.outlook.com; client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com; Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by DB5EUR03FT043.mail.protection.outlook.com (10.152.20.236) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4242.16 via Frontend Transport; Sun, 20 Jun 2021 08:18:45 +0000 Received: ("Tessian outbound 41e46b2c3cec:v96"); Sun, 20 Jun 2021 08:18:45 +0000 X-CR-MTA-TID: 64aa7808 Received: from cc4275ba8142.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 26F19F70-B017-4F5F-A5F3-D1EC3DAA1663.1; Sun, 20 Jun 2021 08:18:39 +0000 Received: from EUR05-AM6-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id cc4275ba8142.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Sun, 20 Jun 2021 08:18:39 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=iULSS8CBkw3cBpcTADfl9Z6F6A2Bm7bZjDKfUHVx/1bH3orPxtuZR1jUyOMH1E/u7ysFGfUAgyiDifJ4dCcJdOVu9yiXq+BjqO2qukF/koSsxKOlmDbaKCmh3LRQzH9496VQENwiFnIkOFD2SPmhR7KoodwKlPuHflSDnB1CLdhTIOBFFQH7YsFGUXSxGIAda/cn5lmdaYrGRbCAHNFMAUHvLVCCujLA/9NVE++rcfkH185ocoyHWvQf5ASwBzosLLIqjENJAHkmfpYoOi4Ov4D78LSBIIoWjwkiEkMVp9bZFbugUwTbBJMbdMkr5x6F02WvfpixGVwTpGueSUpdMA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=vJIoEfnUvwqETBpE7fpdmqoZnfbhHnVE/ch84IkAa4U=; b=AA17QblJ28HfepJoskzim5l7x+//E5d26BgUtvTlYjoFCNsBpboDvbsdXokSVsLLuNoLexrcvXbwLzSvOTzfxViBYER0J4Z8KzFYmZi5mDLFwAde23GQcicx4LOqN/ltzTdvPLhPe4jYqvqemZSAv7DuT3yXjsE19RpdVDAk39sUI+LOY1TLt3FCUeFdqVhUIGeEl/MwAni773AZfnkYxp2Q1zmQf15mhzVQarMH7AQixYQ8EMIxb2jti6NpHVZAC3u/qoMGC4n4rXDH03ZNQUV2QkF/uAVJjhOKRJCcgX5bPjUXi+343vInDMbYnREOqG0FpxB44ue/oE71Iuhi0Q== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=vJIoEfnUvwqETBpE7fpdmqoZnfbhHnVE/ch84IkAa4U=; b=plpyKv8wXJEwURZ+nqxH0Py84q+n4Etl+K8b8sYnh24C3MnmL2g3ecXC/iBZQRCYvdezlR+d8Kw9bIudi0rDTSsYU90PFiY/RiNlcRaqpOExxLXg/erc8g8hv2PQp1zjtj+tQB65twS38/0JKdJ5fMLtNLUchEPqaJXSCKrwkyA= Received: from DBBPR08MB5915.eurprd08.prod.outlook.com (2603:10a6:10:20d::17) by DBBPR08MB4507.eurprd08.prod.outlook.com (2603:10a6:10:d1::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4242.18; Sun, 20 Jun 2021 08:18:32 +0000 Received: from DBBPR08MB5915.eurprd08.prod.outlook.com ([fe80::69cf:4429:a804:7f41]) by DBBPR08MB5915.eurprd08.prod.outlook.com ([fe80::69cf:4429:a804:7f41%3]) with mapi id 15.20.4242.023; Sun, 20 Jun 2021 08:18:32 +0000 From: Hannes Tschofenig To: Ash Wilson CC: "danish@ietf.org" Thread-Topic: [Danish] Charter Text and the Problem Statement Thread-Index: Addin8Z32g6ibl9RQiW6iIvXVU0WhwAVq2gAABL3x4AAGNNDAAAroAeQAE7NSQAABzN/YA== Date: Sun, 20 Jun 2021 08:18:32 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ts-tracking-id: 572A9BF1275E6544B316E5EE2E61A164.0 x-checkrecipientchecked: true Authentication-Results-Original: valimail.com; dkim=none (message not signed) header.d=none; valimail.com; dmarc=none action=none header.from=arm.com; x-originating-ip: [80.92.123.248] x-ms-publictraffictype: Email X-MS-Office365-Filtering-Correlation-Id: 3fa57583-3707-4ae5-b43d-08d933c405a6 x-ms-traffictypediagnostic: DBBPR08MB4507:|AM0PR08MB4324: X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true nodisclaimer: true x-ms-oob-tlc-oobclassifiers: OLM:4941;OLM:4941; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: vQu09B2rOp7qIk1HOJeHHle8Zx+i2ZM8TdPbSxDcb9AE7l9H6QHRS0qdzrv0utWjuRdCweLL+VEdgJ/sOJaIPJjUsPbzz+7VulV49ymzpR2UZJ9vEPg0ahPMJ2UngCgPZmQ7MJ1sFKNSTGcmH6p/avNb2KcoPkGRPaIVFp5/2Hk4aF7dfDODZE6MfGoVjTzt4p7MHNNDYaj+XyG7NUw9UlXTF4HI28WNHZvITi9lADV9vbh3vVZZJ+9CxpOdyrzYwDPkuR6E8PnOUeb3nGne20Sv43Oemo1Wu7GjhKlnzMTcUwrfx2CV1HdS7JT+G/Oh6GCG1oa790PUtKoCLbqtDHOUtnMRN+7uQxsLxfbYLD+Xw3+BXwvC1jzuA9BEiJNxJ04FdoifJnN7/RwnCeYdFidMlXxWXkHofrXzRGSBsWuR0NOUNjKuI0Ac8wePJvQxpBvjr7ByGGSzLakId7ykpQkiimSVhQDsr+nhJN8Of+XsRIjhfgby4RocnNDKnePlftsn3n5vHCGbedglinqFOYYS22wa8q/M8BmZL+r4OLRuho6s2wgIZx/Hxzok/r/GC0SP0j8m28SZzbPDZjBkVzcDGQBLIZBDGZQwO1eVcujuLNpfhHBkAVZUTdJ8sRx2YkV3m2IA+hvkY95Sr0rhizKleSqVxldA9XCURIrgagTK6K2IZXDSPPQwNRMskyAdZ9DXzo4Alt2eDx5mlbX8cZneda4tOtmmPucykU5l80E3B33LyVqAmIy3O8bHWC0U X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DBBPR08MB5915.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(136003)(346002)(366004)(376002)(39840400004)(396003)(166002)(478600001)(83380400001)(4326008)(6916009)(76116006)(52536014)(5660300002)(966005)(9686003)(66446008)(66556008)(66476007)(9326002)(30864003)(66946007)(64756008)(86362001)(55016002)(2906002)(316002)(38100700002)(122000001)(8936002)(53546011)(33656002)(6506007)(8676002)(7696005)(186003)(26005)(71200400001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?aWZkcHBTNjZJMU9iWC9IR0k2ZzRPVWxoMGdkdk53U0ZWNDlBT1lWYWZrTzZT?= =?utf-8?B?OU9tSFIyMzl2TnhmK0h6TWw0eHBnSXcxSFJHK0IvQnQxb2gwc1hRTDA3M0pL?= =?utf-8?B?QlpCK0FYcUQwV25tZVFkMzZ6a2Y5OCtXYUMvQzJXTENNazNORS9rTkRQaC9v?= =?utf-8?B?Z1I5ZGFOS2lBUUNkREFzT1R6UFMxRWpua0RUalVPTFJjRXBxRjZxendGTkR1?= =?utf-8?B?RU9RSkkwZWs2MUVCVnRYR1lWQTZoN014Tzc4NUhGeFlzbFcrTjJXSG5xNENz?= =?utf-8?B?WGt5RmZKVWE4a1RlajFkSmlhem5NNUZFMEdsQjRMTUpER3pCMnlUTWNtTTBl?= =?utf-8?B?ZEwyTTdDSTJxWk1EQnhIOVFTbk1GMWl2RU53VGt0SGVEWHpkR0o1TlljcmVn?= =?utf-8?B?OHVhR25JTHFaTFduN1VEbGhDbGRoUSszU3dLbE45dHVuU1J5bkpPWXREQ00v?= =?utf-8?B?QVhRQlVKSHNGdmY1c1oxVmdSUXgzT1FlcXFyazJLVS9FamF4a3A0TkNGVUxm?= =?utf-8?B?SkdnRjZDY2huejE4V1lEclNmYkwvc2RGQ1hTdzVldG9oYTRlbTczQlduZk4v?= =?utf-8?B?cGZXZm1YK3BrNXZzTHQ5c0J6RVlQb3l2S0lyL3dRa3VoU1BPa2ZxSG5QSjVk?= =?utf-8?B?cGc1R3pkQVduUzZXaUZhaHh2OFhKT3ZlZWYyZFBCYkZXWWdwRkk3b1FNM3A0?= =?utf-8?B?NEh3VnRjUWhKaGw1dm1vWHIyOUN4ZVFrMDNLdkxMRU5oZUhDbnY3bWtORHRI?= =?utf-8?B?Q0c2TU03MkJSbjd5Wk1jSW9LZGxsWFpyQ0xOTlNpWG1SSXAyWnYzL1l2R0t2?= =?utf-8?B?VkxpMjZNU2Q3bjdpMUQrS1d4ZHFCVUVNZ0lNaDVkZ0h0NVcwUk8rMEpIRDNV?= =?utf-8?B?TG8rMXhpWUJaTnpEc0NOSlFYNlovUWp0K3lPUEZBQ2V2aFhicHpQeHJsS0ZH?= =?utf-8?B?TktGbi9FL3Q2dUdtbXYrZjdQVk9obllQaW9kSUFUS1VyUXhwbFdnSURkRUJ6?= =?utf-8?B?V2Z2OE9BZTRHandFYmp2b3FZSzZNditoYWhZTWRNSE04T2ZiMHUyZnoxVVI2?= =?utf-8?B?RTRlRDlLSEN3WEszdUlsU0pwbXRIU2xFZ0JKcXBUMHRHVDNvUjhyV29MR0w5?= =?utf-8?B?V2FuUU9xSjk5cml4cE9acTZjNnBHRjAyRVE5ZlF5bHJVMUVob0x3VjJaWUhh?= =?utf-8?B?d21qd29RUzB3Vnkya21ralNya0xPU0w5eDczeUk3NGprVDVvdlNPTVVMVGlU?= =?utf-8?B?QXF6ZytQUFVQaXB3b1JuRjhQUDcvZFVmRFNldXhQNDdIdDdEWmNkOGdVcCsv?= =?utf-8?B?MHNyb3VpVXZuMDl1dXMwV1hmbVZRTm54cnhRRnNyRG9QakRDeUpIbkpvZFM0?= =?utf-8?B?YkhNUDNpZkppSDVhbDNPOHFTb2tsSjNBZG90KzRMQlFnVHh6ZUk2bVJGeHVM?= =?utf-8?B?ZUNvY1BqTHRhV3lXK0V4L3I2RUN5dE9ub1pzaXQ4WHZjVEgrczRmTVFLR05O?= =?utf-8?B?cXNFblBjaDNmZ0pNRnh4TkNrYXJzblpQUzc4b2FQRWx0Q2JKRTNreldmS01E?= =?utf-8?B?VWtKS0JucTlyZHo5NGx5ZnpLNDQ3V2s0RU4zeGMvYk5MU1JoanlKMk0zMjJs?= =?utf-8?B?YWdUMk5FYTlLZFp6RkVHWjZjTmUzdnBFbitpZjlHbkdzcnNISWdETkpFUkto?= =?utf-8?B?MGJpRXpYTGQ2QldIbC83VHlDeUNmeWZ3cXZkUnFoMXY3czc3Y0xXWHU3UlFW?= =?utf-8?Q?qC2t6aecpWGtkNsrdHtDl94cvbgLCxmcbJ3Ohdw?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_DBBPR08MB59153F3F972DBB5EE70D5234FA0B9DBBPR08MB5915eurp_" MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBBPR08MB4507 Original-Authentication-Results: valimail.com; dkim=none (message not signed) header.d=none; valimail.com; dmarc=none action=none header.from=arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: DB5EUR03FT043.eop-EUR03.prod.protection.outlook.com X-MS-Office365-Filtering-Correlation-Id-Prvs: ad8078a7-070c-4eb6-e907-08d933c3fdef X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: dh8z4IbAoCZBgrNg4AxKC1Nc8jZEe8Z5Ycf7g0yd7YEDgCB1MipmvxqKVmmnRfskBl7Ua0IGBnfII10UeAMCw1fRl6j2H+zIBtvmaFYsmvy+dTftbaEP3E5HcKsG6scuJokH8MUUjdaCfo9yCFHiT65DlogY/V1fONOYkQK4813puSn93BCez6LVyWKmL3Kr6nyadv0x6Jp9MaEC+/027+8YMCVNFqZmexiDiIB7oiHjUYrwGVb0O7PpTwu6l6rpOlgtiiaKono1OfSiLU0oCrbDoRWf8i4SrRjf1TpynMcVT/EZP8BMABJMk1SN7yzRBx2ayv+vV+P6kXFcz3c/Es0XqKcOU4PP6PaRpVFKdcXw2cmntn0SozKPvkydxm7x3dY+p/brAQuGvz9LoeHTZyrwNiCdx9BfBS+NiV1YPjXKYk0AYtti5qj/B9AfATIPxQYiy45BtcTpOEy+tiuIIww69WcNBKCBW9NbEUAS2EdXDLZ0SX+GNUQKO+jD9/QZ4qZfNV5fOUR8VAknJOWmJ4mvlUJSTrvtJMmozvEp6EmwcsuoRWHnuVAgob3b/y5gDG68UugzOQltdhEbiyMN/AkS3jvv6TD9CAMqiLC0BIrE8uFjgoiZ73GyJ1HesVOqjqVYPMu2gEJClOe2/NkcAKF5KW/GCbGQnb5IWs2eqIhcbkgKZfNyXh3cTe0b2haK8fz1tNKN7MqkD+/nyldHDkKPGH5ZY2sjK3C19MKfWqvVyjyKCOPQfwdjQl/CsI7fQieJFsSMLciTNck7MT5rnDqzIvTKKlpIhme7zUEIlPrv8+LgQqR9V5w4A/o8zsCM X-Forefront-Antispam-Report: CIP:63.35.35.123; CTRY:IE; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:64aa7808-outbound-1.mta.getcheckrecipient.com; PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; CAT:NONE; SFS:(4636009)(396003)(136003)(346002)(376002)(39850400004)(36840700001)(46966006)(47076005)(6862004)(70586007)(336012)(82310400003)(52536014)(316002)(4326008)(36860700001)(8676002)(83380400001)(30864003)(33656002)(478600001)(26005)(33964004)(70206006)(9326002)(7696005)(2906002)(5660300002)(81166007)(356005)(166002)(186003)(82740400003)(966005)(53546011)(55016002)(6506007)(9686003)(8936002)(86362001)(579004)(559001); DIR:OUT; SFP:1101; X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Jun 2021 08:18:45.0983 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 3fa57583-3707-4ae5-b43d-08d933c405a6 X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d; Ip=[63.35.35.123]; Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com] X-MS-Exchange-CrossTenant-AuthSource: DB5EUR03FT043.eop-EUR03.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR08MB4324 Archived-At: Subject: Re: [Danish] Charter Text and the Problem Statement X-BeenThere: danish@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DANE AutheNtication for Iot Service Hardening List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jun 2021 08:18:58 -0000 --_000_DBBPR08MB59153F3F972DBB5EE70D5234FA0B9DBBPR08MB5915eurp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQXNoLA0KDQpJIGJlbGlldmUgeW91IGFuZCBvdGhlcnMgaW4gdGhlIGdyb3VwIGhhdmUgYSB2 aXNpb24gdGhhdCBzb21laG93IHJlbGF0ZXMgdG8gSW9UIHdoZXJlIHRoZSB1c2Ugb2YgREFORSBm b3IgY2xpZW50IGF1dGhlbnRpY2F0aW9uIGluIFRMUyBmaXRzIGluIHRoZXJlLiBXaGF0IGhhcyBu b3QgYmVlbiBkb25lIHlldCBpcyB0byBwdXQgdGhpcyB2aXNpb24gaW4gd3JpdGluZy4gSXQgbWF5 IGJlIHRoYXQgdGhpcyB2aXNpb24gaXMgbW9yZSBzb2x1dGlvbiBvcmllbnRlZCB0aGFuIHByb2Js ZW0gb3JpZW50ZWQgYnV0LCBpZiB5b3Ugd2FudCB0byBhdHRyYWN0IG90aGVycyBpbiB0aGUgd29y ayAoYXNzdW1pbmcgeW91IHdhbnQgdGhhdCksIHlvdSB3aWxsIGhhdmUgdG8gc29tZWhvdyBleHBs YWluIGhvdyB0aGVzZSBzbWFsbCBidWlsZGluZyBibG9ja3MgZW5hYmxlIHNvbWV0aGluZyBiaWdn ZXIuDQoNCkNpYW8NCkhhbm5lcw0KDQpGcm9tOiBBc2ggV2lsc29uIDxhc2gud2lsc29uQHZhbGlt YWlsLmNvbT4NClNlbnQ6IFN1bmRheSwgSnVuZSAyMCwgMjAyMSA2OjQ3IEFNDQpUbzogSGFubmVz IFRzY2hvZmVuaWcgPEhhbm5lcy5Uc2Nob2ZlbmlnQGFybS5jb20+DQpDYzogZGFuaXNoQGlldGYu b3JnDQpTdWJqZWN0OiBSZTogW0RhbmlzaF0gQ2hhcnRlciBUZXh0IGFuZCB0aGUgUHJvYmxlbSBT dGF0ZW1lbnQNCg0KDQoNCk9uIFNhdCwgSnVuIDE5LCAyMDIxIGF0IDU6NDcgQU0gSGFubmVzIFRz Y2hvZmVuaWcgPEhhbm5lcy5Uc2Nob2ZlbmlnQGFybS5jb208bWFpbHRvOkhhbm5lcy5Uc2Nob2Zl bmlnQGFybS5jb20+PiB3cm90ZToNCkhpIEFzaCwNCg0KSWYgdGhlIG5ldHdvcmsgYWNjZXNzIGF1 dGhlbnRpY2F0aW9uIHVzZSBjYXNlIHdpdGggRUFQLVRMUyBpcyBpbXBvcnRhbnQgdG8geW91IHRo ZW4gSSBiZWxpZXZlIGl0IHdvdWxkIGJlIGdvb2QgdG8gYWRkIGl0IGFzIGEgbWlsZXN0b25lIG9u IHRoZSBjaGFydGVyLiBZb3UgY2Fubm90IHVzZSBhbiBpbXBsZW1lbnRhdGlvbiBvZiBkcmFmdC1p ZXRmLWVtdS1lYXAtdGxzMTMgYW5kIGFzc3VtZSBhbnkgb2YgdGhlIERBTkUgZnVuY3Rpb25hbGl0 eSB0byB3b3JrLiBZb3Ugd291bGQgaW5kZWVkIGhhdmUgdG8gcmVseSBvbiBkcmFmdC1pZXRmLXRs cy1kbnNzZWMtY2hhaW4tZXh0ZW5zaW9uIGJlY2F1c2Ugbm90IGhhdmluZyBuZXR3b3JrIGNvbm5l Y3Rpdml0eSBpcyB0aGUgbWFpbiByZWFzb24gd2h5IHlvdSB3b3VsZCBiZSBydW5uaW5nIHRoZSBF QVAtVExTIGV4Y2hhbmdlIGluIHRoZSBmaXJzdCBwbGFjZS4NClRoZSBwcm9jZXNzIG9mIHVzaW5n IERBTkUgZm9yIGF1dGhlbnRpY2F0aW5nIGFuIEVBUC1UTFMgc3VwcGxpY2FudCwgZnJvbSB0aGUg YXV0aGVudGljYXRpb24gc2VydmVyJ3MgcGVyc3BlY3RpdmUsIGlzIGV4cGVjdGVkIHRvIGJlIG1v cmUgc3RyYWlnaHRmb3J3YXJkLiBJdCBpcyBub3QgdW5uYXR1cmFsIGZvciB0aGUgYXV0aGVudGlj YXRpb24gc2VydmVyIHRvIGhhdmUgdGhlIElQIGNvbm5lY3Rpdml0eSByZXF1aXJlZCB0byByZXRy aWV2ZSB0aGUgVExTQSByZWNvcmQgZm9yIGF1dGhlbnRpY2F0aW5nIHRoZSBjbGllbnQncyBjZXJ0 aWZpY2F0ZS4gVGhlIGNvbXBsZXhpdHkgb2YgZ2V0dGluZyBEQU5FIHRvIHdvcmsgZm9yIGFsbG93 aW5nIHRoZSBzdXBwbGljYW50IHRvIGF1dGhlbnRpY2F0ZSB0aGUgYXV0aGVudGljYXRpb24gc2Vy dmVyIGlzIGNlcnRhaW5seSBtb3JlIGNvbXBsaWNhdGVkLCBhbmQgYWxzbyBpbnRyb2R1Y2VzIGEg ZGVwZW5kZW5jeSBvbiB0aGUgRE5TU0VDIGNoYWluIGV4dGVuc2lvbi4NCg0KUmVnYXJkaW5nIOKA nGJlc3QgcHJhY3RpY2UgdG8gZW5zdXJlIHRoYXQgYSBkZXZpY2UgaXMgcGF0Y2hlZCBiZWZvcmUg cHV0dGluZyBpdCBpbnRvIHByb2R1Y3Rpb24sIGFuZCB1cGRhdGluZyByb290cyBvZiB0cnVzdCBm aXRzIHdpdGhpbiB0aGUgc2NvcGUgb2YgdGhhdCBzb3J0IG9mIGFjdGl2aXR54oCdOiBJIGRvbuKA mXQgdGhpbmsgdGhlcmUgaXMgYW55IGV4cGVjdGF0aW9uIHRoYXQgdGhlIGRldmljZSB3aWxsIGJl IHVwZGF0ZWQgYmVmb3JlIGl0IGlzIHB1dCBpbiBwcm9kdWN0aW9uIChpLmUuIHBvd2VyZWQgb24g Zm9yIHRoZSBmaXJzdCB0aW1lKS4gWW91IGNhbiBhc3N1bWUgdGhhdCB0aGUgZGV2aWNlLCB3aGVu IGl0IGNvbWVzIG9ubGluZSBmb3IgdGhlIGZpcnN0IHRpbWUgYW5kIHJlYWNoZXMgb3V0IHRvIHRo ZSBkZXZpY2UgbWFuYWdlbWVudCBzZXJ2ZXIsIGdldHMgYSBmaXJtd2FyZSB1cGRhdGUuIEhhdmlu ZyB0aGF0IGZpcm13YXJlIHVwZGF0ZSBoYXBwZW4gYmVmb3JlIGl0IGlzIGNvbm5lY3RlZCB0byB0 aGUgbmV0d29yayBpcyBleHRyZW1lbHkgdW5saWtlbHkuDQoNCkVBUC1UTFMgaXMgYWxzbyBub3Qg YW4gSW9UIGRldmljZSBvbmJvYXJkaW5nIHByb3RvY29sLiBGcm9tIHRoZSBjaGFydGVyIHRleHQg SSBhbSBhbHNvIG5vdCBhc3N1bWluZyB0aGF0IHlvdSBhcmUgYXR0ZW1wdGluZyB0byBkZWZpbmUg YSBuZXcgSW9UIG9uYm9hcmRpbmcgcHJvdG9jb2wgb3IgZG8geW91Pw0KV2UgYXJlIGJlaW5nIHZl cnkgY2FyZWZ1bCB3aXRoIHRoZSBzY29wZSBvZiB0aGUgY2hhcnRlciwgdG8gc3RheSBmb2N1c2Vk IG9uIGNsaWVudCBhdXRoZW50aWNhdGlvbiBpbiB0aGUgVExTIGhhbmRzaGFrZSBhbmQgcHVibGlj IGtleSBkaXNjb3ZlcnkgZm9yIGF1dGhlbnRpY2F0aW5nIG1lc3NhZ2VzLiBBZGRyZXNzaW5nIHRo ZSBudWFuY2VzIG9mIEVBUC1UTFMsIGVzcGVjaWFsbHkgZm9yIHN1cHBvcnRpbmcgVExTIDEuMywg c2VlbXMgbGlrZSB0aGUgc29ydCBvZiB3b3JrIHdlIG1heSB3YW50IHRvIHJlLWNoYXJ0ZXIgdG8g YWNjb21wbGlzaCB1bmxlc3MgdGhlcmUncyBlbm91Z2ggaW50ZXJlc3QgaW4gdGhlIGJlZ2lubmlu ZyB0byBicmluZyBpdCBpbi1zY29wZS4gSSdtIHZlcnkgaGFwcHkgdG8gaGVhciB0aGF0IHlvdSdy ZSBpbnRlcmVzdGVkIGluIGhvdyBFQVAtVExTIHdpbGwgZml0IHdpdGggdGhpcyBlZmZvcnQgYW5k IEkgaGF2ZSBubyBvYmplY3Rpb24gdG8gaW5jbHVkaW5nIHRoaXMgaW4gdGhlIGNoYXJ0ZXIsIGFz IGxvbmcgYXMgdGhlIGNoYWlycyBhcmUgT0sgd2l0aCBpdC4NCg0KUmVnYXJkaW5nIHRoZSBob21l IElvVCBlbnZpcm9ubWVudDogSSB3b3VsZCBub3QgY291bnQgb24gQ0hJUC9NYXR0ZXIgcmUtdXNp bmcgeW91ciB3b3JrLiBNeSB1bmRlcnN0YW5kaW5nIGlzIHRoYXQgdGhleSBhcmUgY3JlYXRpbmcg dGhlaXIgb3duIHNvbHV0aW9ucy4gU2luY2UgdGhlIGhvbWUgZW52aXJvbm1lbnQgaXMgdmVyeSBm cmFnbWVudGVkLCBpdCBtaWdodCBub3QgYmUgdGhlIGVhc2llc3QgcGxhY2UgdG8gc3RhcnQuIE9m IGNvdXJzZSwgeW91ciBjb21wYW55IG1heSBwbGF5IGFuZCB0aGF0IGZpZWxkIGFuZCBzbyB5b3Ug bWlnaHQgaGF2ZSBhIHdheSB0byBnZXQgdGhlIG91dGNvbWUgb2YgREFOSVNIIGRlcGxveWVkIHRo ZXJlLg0KDQpJIGFtIHN0aWxsIHRyeWluZyB0byBmaWd1cmUgb3V0IGhvdyBEQU5JU0ggZml0cyBp bnRvIHRoZSBsYXJnZXIgcGljdHVyZSBhbmQgaGVuY2UgSSBhbSBsb29raW5nIGZvcndhcmQgdG8g cmVhZCBhbiBhcmNoaXRlY3R1cmUgZG9jdW1lbnQuIElzIHRoZSBhIHByZS1kcmFmdCBhdmFpbGFi bGUgYWxyZWFkeT8NCiBUaGUgYXJjaGl0ZWN0dXJlIGRvY3VtZW50IGlzIHZlcnkgcm91Z2ggYW5k IG5vdCByZWFkeSBldmVuIGZvciBwcmUtZHJhZnQgcmV2aWV3LiAgSSB3aWxsIHByaW9yaXRpemUg aW1wcm92aW5nIHRoaXMgZG9jdW1lbnQgYW5kIHNoYXJlIGl0IHdpdGggeW91IEFTQVAuDQoNCkNp YW8NCkhhbm5lcw0KDQpGcm9tOiBBc2ggV2lsc29uIDxhc2gud2lsc29uQHZhbGltYWlsLmNvbTxt YWlsdG86YXNoLndpbHNvbkB2YWxpbWFpbC5jb20+Pg0KU2VudDogVGh1cnNkYXksIEp1bmUgMTcs IDIwMjEgODoyMiBQTQ0KVG86IEhhbm5lcyBUc2Nob2ZlbmlnIDxIYW5uZXMuVHNjaG9mZW5pZ0Bh cm0uY29tPG1haWx0bzpIYW5uZXMuVHNjaG9mZW5pZ0Bhcm0uY29tPj4NCkNjOiBkYW5pc2hAaWV0 Zi5vcmc8bWFpbHRvOmRhbmlzaEBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbRGFuaXNoXSBDaGFy dGVyIFRleHQgYW5kIHRoZSBQcm9ibGVtIFN0YXRlbWVudA0KDQpIaSBIYW5uZXMsDQpHcmVhdCBx dWVzdGlvbnMsIHJlc3BvbnNlcyBpbi1saW5lIGJlbG93Li4uDQoNCk9uIFdlZCwgSnVuIDE2LCAy MDIxIGF0IDExOjQzIFBNIEhhbm5lcyBUc2Nob2ZlbmlnIDxIYW5uZXMuVHNjaG9mZW5pZ0Bhcm0u Y29tPG1haWx0bzpIYW5uZXMuVHNjaG9mZW5pZ0Bhcm0uY29tPj4gd3JvdGU6DQpUaGFua3MgZm9y IHlvdXIgZmVlZGJhY2ssIEFzaC4NCg0KSXQgaXMgaW50ZXJlc3RpbmcgdGhhdCB5b3UgbWVudGlv biB0aGUgbmV0d29yayBhY2Nlc3MgYXV0aGVudGljYXRpb24gdXNlIGNhc2UuIERvIHlvdSBlbnZp c2lvbiBFQVAtVExTIGluIGNvbWJpbmF0aW9uIHdpdGggRGFuaXNoIHRvIHdvcmsgYXJjaGl0ZWN0 dXJhbGx5IGRpZmZlcmVudGx5IHRoYW4gdGhlIGN1cnJlbnQgRUFQLVRMUy1iYXNlZCBhcHByb2Fj aD8NCg0KV2UgaG9wZSB0byBtaW5pbWl6ZSB0aGUgYW1vdW50IG9mIHdvcmsgcmVxdWlyZWQgdG8g ZW5hYmxlIERBTkUgY2xpZW50IElEIGZvciBFQVAtVExTLiBTb21lIGNoYWxsZW5nZXMgcmVtYWlu IHdpdGggRUFQLVRMUyBpbiBjb25qdW5jdGlvbiB3aXRoIFRMUyAxLjM6IGh0dHBzOi8vZGF0YXRy YWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtaWV0Zi1lbXUtZWFwLXRsczEzLTE2LiBTdXBw b3J0aW5nIFRMUyAxLjIgZm9yIEVBUC1UTFMgYW5kIERBTkUgd291bGQgbGlrZWx5IGJlIG1vcmUg c3RyYWlnaHRmb3J3YXJkLCBidXQgSSBkbyBub3Qga25vdyB3aGV0aGVyIHRoZXJlJ3MgbXVjaCBp bnRlcmVzdCBpbiB1cGRhdGluZyBUTFMgMS4yIHRvIGNvdmVyIHRoaXMgdXNlIGNhc2UuDQoNCkRB TkUgc2VydmVyIGF1dGhlbnRpY2F0aW9uIHdpdGggRUFQLVRMUyBicmluZ3MgYW5vdGhlciBjaGFs bGVuZ2U6IHRoZSBhYnNlbmNlIG9mIElQIGNvbm5lY3Rpdml0eSBwcmlvciB0byBhdXRoZW50aWNh dGlvbi4gVGhpcyBjb3VsZCBiZSByZW1lZGllZCBieSBodHRwczovL2RhdGF0cmFja2VyLmlldGYu b3JnL2RvYy9odG1sL2RyYWZ0LWlldGYtdGxzLWRuc3NlYy1jaGFpbi1leHRlbnNpb24tMDcsIGlm IHRoZSB3b3JrIG9uIHRoYXQgZHJhZnQgd2VyZSB0byBjb250aW51ZS4gVGhlcmUgYXJlIGFsc28g Y2hhbGxlbmdlcyB3aXRoIHZhbGlkYXRpbmcgdGhlIGNoYWluLCB0aWVkIHRvIHJvb3Qga2V5IHJv dGF0aW9uLiBEZXZpY2VzIHdoaWNoIHJlbWFpbiB1bnBsdWdnZWQgdG9vIGxvbmcgbWF5IG5vdCBi ZSBhYmxlIHRvIGF1dGhlbnRpY2F0ZS4gT24gdGhlIG90aGVyIGhhbmQsIGl0IGlzIGEgYmVzdCBw cmFjdGljZSB0byBlbnN1cmUgdGhhdCBhIGRldmljZSBpcyBwYXRjaGVkIGJlZm9yZSBwdXR0aW5n IGl0IGludG8gcHJvZHVjdGlvbiwgYW5kIHVwZGF0aW5nIHJvb3RzIG9mIHRydXN0IGZpdHMgd2l0 aGluIHRoZSBzY29wZSBvZiB0aGF0IHNvcnQgb2YgYWN0aXZpdHkuDQoNCklmIG9ubHkgREFORSBm b3IgY2xpZW50IGF1dGhlbnRpY2F0aW9uIGlzIHN1cHBvcnRlZCBpbiBFQVAtVExTLCB3aGljaCBp cyB0aGUgbGlrZWx5IGluaXRpYWwgb3V0Y29tZSwgdGhlIGNoYWxsZW5nZSBvZiBnZXR0aW5nIHRo ZSBhdXRoZW50aWNhdGlvbiBzZXJ2ZXIncyBDQSBjZXJ0aWZpY2F0ZSBvbnRvIHRoZSBkZXZpY2Ug c3RpbGwgZXhpc3RzLiBUaGlzIHN0aWxsIHJlcHJlc2VudHMgYSByZWR1Y3Rpb24gaW4gZWZmb3J0 IG9uIHRoZSBwYXJ0IG9mIHRoZSBJVCBzdGFmZiwgYnV0IG5vdCBhIHBlcmZlY3QgemVyby10b3Vj aCBvbmJvYXJkaW5nIHVubGVzcyB0aGUgc3VwcGxpZXIgYWxzbyBwcm92aXNpb25zIHRoZSBDQSBj ZXJ0cyBmb3IgdGhlIGF1dGhlbnRpY2F0aW9uIHNlcnZlci4uLiBhbmQgaW4gdGhlIGNhc2Ugb2Yg V2lGaSwgdGhlIFNTSUQgdG8gYXNzb2NpYXRlIHdpdGguIFN0aWxsLCB3ZSB0aGluayB0aGlzIHJl cHJlc2VudHMgYSBzdWJzdGFudGlhbCBpbXByb3ZlbWVudCBpbiB0aGUgb25ib2FyZGluZyBleHBl cmllbmNlIGZvciB0aGUgaW1wbGVtZW50ZXIuDQoNCg0KWW91IHdyaXRlOg0K4oCcQ3JlZGVudGlh bCBpc3N1YW5jZSB2ZXJ5IG9mdGVuIHJlcXVpcmVzIHRoZSBkZXZpY2UgYW5kIHRoZSBwZXJzb24g Ym9vdHN0cmFwcGluZyB0aGUgaWRlbnRpdHkgdG8gYmUgaW4gdGhlIHNhbWUgcGxhY2XigJ0NCg0K QmluZGluZyB0aGUgdXNlciB0byBoaXMgb3IgaGVyIGRldmljZSB0eXBpY2FsbHkgdGFrZXMgc29t ZSB0aW1lLiBJdCBvZnRlbiByZXF1aXJlcyB0aGUgdXNlciB0byBsb2cgaW50byBzb21lIHNlcnZp Y2UgYW5kIHRvIOKAnGFkZOKAnSB0aGUgbmV3IGRldmljZSBvZnRlbiBieSBkZW1vbnN0cmF0aW5n IHBoeXNpY2FsIHBvc3Nlc3Npb24uIE9mIGNvdXJzZSwgdGhpcyBpcyB0aGUgd2F5IGhvdyBpdCB3 b3JrcyBmb3IgZW5kIGNvbnN1bWVyIHByb2R1Y3RzLCB3aGVyZSBzY2FsYWJpbGl0eSBpcyBsZXNz IG9mIGFuIGlzc3VlIGJlY2F1c2UgeW91IGFyZSBwcm9iYWJseSBub3QgZ29pbmcgdG8gYnV5IHRo b3VzYW5kcyBvZiBzbWFydCBjb2ZmZWUgbWFjaGluZXMuIEZvciBhIGNvbW1lcmNpYWwgc2V0dXAs IHRoZSBwcm9jZXNzIG9mdGVuIHdvcmtzIGRpZmZlcmVudCBidXQgaXQgdmVyeSBtdWNoIGRlcGVu ZHMgb24gdGhlIHR5cGUgb2YgaW5kdXN0cnkgdmVydGljYWwgeW91IGFyZSBpbi4gVGhlcmUgaXMg b2Z0ZW4gYSBub24taXJyZWxldmFudCBjb25maWd1cmF0aW9uIHN0ZXAgaW52b2x2ZWQgYXMgd2Vs bC4gRm9yIGV4YW1wbGUsIHdpdGggY29tbWVyY2lhbCBpbmRvb3IgbGlnaHRpbmcgcHJvZmVzc2lv bmFscyBuZWVkIHRvIGNvbmZpZ3VyZSBkaWZmZXJlbnQgbGlnaHRpbmcgdGhlbWVzLg0KDQpJIGRv buKAmXQgc2VlIGFueSBvZiB0aGlzIHVzZXItcmVsYXRlZCBpbnRlcmFjdGlvbiBiZWluZyBjb3Zl cmVkIGFzIHBhcnQgb2YgdGhlIGNoYXJ0ZXJlZCB3b3JrLg0KDQpEQU5FIGNhbiBiZSB1c2VmdWwg Zm9yIGhvbWUgSW9ULiBJIHRoaW5rIHRoYXQgaXQgY291bGQgcmVkdWNlIHRoZSBjb21wbGV4aXR5 IG9mIGF1dG9tYXRpb24gd2hlcmV2ZXIgcHJpdmF0ZSBQS0kgaXMgYmVpbmcgbWFuYWdlZCBpbiB0 aGUgY29uc3VtZXIncyBlbnZpcm9ubWVudCwgYW5kIGFjY2VsZXJhdGUgYW5kIHNpbXBsaWZ5IHRo ZSBvbmJvYXJkaW5nIGV4cGVyaWVuY2UuIElFVEYgaXMgYWNjZXNzaWJsZSBhbmQgd2lkZS1yZWFj aGluZywgYW5kIHNlZW1zIGxpa2UgdGhlIHJpZ2h0IHBsYWNlIHRvIHByZXNlbnQgYW5kIHJlZmlu ZSB0aGUgZGVzaWduIHBhdHRlcm4gdGhhdCBtaWdodCBiZSBhZG9wdGVkIGxhdGVyIGJ5IG90aGVy IHN0YW5kYXJkcyAobGlrZSBDSElQL01hdHRlcikuIEknbSBhbHNvIG9wZXJhdGluZyB1bmRlciB0 aGUgYXNzdW1wdGlvbiB0aGF0IGVudGVycHJpc2UgSW9UIGhhcyBhIG1vcmUgcmVjb2duaXplZCBu ZWVkIGZvciBpbnRlcm9wZXJhYmlsaXR5IGFuZCBzaW1wbGVyIHNlY3VyZSBvbmJvYXJkaW5nIHBy b2Nlc3Nlcy4gVGhhdCBpcyBhIGJpZyBhc3N1bXB0aW9uLCBhbmQgb25seSBiYXNlZCBvbiBteSBv YnNlcnZhdGlvbnMgdGh1cyBmYXIuIEknbSBvcGVuIHRvIGluY2x1ZGluZyB0aGUgaG9tZSBjb25z dW1lcidzIHBlcnNwZWN0aXZlIGluIHRoaXMgZWZmb3J0LCBpZiB5b3UgdGhpbmsgaXQncyB3b3J0 aHdoaWxlLg0KDQoNCkFzIGZhciBhcyBkZXNjcmliaW5nIHRoZSBnZW5lcmFsIG9uYm9hcmRpbmcg ZXhwZXJpZW5jZSBmb3IgdGhlIGltcGxlbWVudGVyLCBJIGhhZCBob3BlZCB0byBpbmNsdWRlIHRo YXQgaW4gdGhlIGFyY2hpdGVjdHVyZSBkb2N1bWVudCBhbG9uZyB3aXRoIGV4YW1wbGVzIG9mIGhv dyBEQU5FIG1pZ2h0IGludGVyZmFjZSB3aXRoIGFuZCBzdXBwb3J0IG90aGVyIHN0YW5kYXJkcyBp biB0aGUgYnJvYWRlciBlY29zeXN0ZW0uIEluIHRyeWluZyB0byBrZWVwIHRoZSBjaGFydGVyIGNv bmNpc2UsIEkgdGhpbmsgd2UgbGVmdCBvdXQgc29tZSBpbXBvcnRhbnQgaW5mb3JtYXRpb24uDQoN CllvdSBicmluZyB1cCBhbiBpbnRlcmVzdGluZyBwb2ludCwgd2l0aCB0aGUgY29uZmlndXJhdGlv biBvZiBsaWdodGluZyBwcm9maWxlcyBkdXJpbmcgZml4dHVyZSBpbnN0YWxsYXRpb24uIFRoZSBl eHBlY3RhdGlvbiBpcyB0aGF0IHdpdGggREFORSBhcyB0aGUgYXV0aGVudGljYXRpb24gcHJvdG9j b2wsIHRoZSB2YXJpZXR5IG9mIHN1cHBsaWVycyBwcm9kdWNpbmcgZGV2aWNlcyBmb3IgYSBnaXZl biBhcHBsaWNhdGlvbiBtaWdodCBiZSBhYmxlIHRvIGFncmVlIG9uIGEgZm9ybWF0IGZvciByZXBy ZXNlbnRpbmcgY29uZmlndXJhdGlvbiBpbmZvcm1hdGlvbiwgYW5kIGRldmljZXMgY2FuIHNlY3Vy ZWx5IHJldHJpZXZlIGl0IGZyb20gdGhlIHN5c3RlbSB0aGF0IG1hbmFnZXMgdGhlIGFwcGxpY2F0 aW9uJ3MgY29uZmlndXJhdGlvbi4gSSB0aGluayB0aGF0IGl0IHdvdWxkIGJlIGVzcGVjaWFsbHkg dXNlZnVsIHRvIHNob3cgaG93IERBTkUgd29ya3Mgd2l0aCBvdGhlciBkaXNjb3ZlcnkgcHJvdG9j b2xzIChtRE5TLCBmb3IgaW5zdGFuY2UpIGluIHRoZSBwcm9jZXNzIG9mIHJldHJpZXZpbmcgdGhl IGRldmljZSdzIGNvbmZpZ3VyYXRpb24uIFdoZXJlIGRvIHlvdSB0aGluayB0aGlzIGZpdHMgYmVz dD8gSW4gdGhlIGFyY2hpdGVjdHVyZSBkb2N1bWVudCwgb3Igd291bGQgYW5vdGhlciBmb3JtYXQg YmUgYSBiZXR0ZXIgZml0IGZvciB0aGlzPw0KDQoNCkNpYW8NCkhhbm5lcw0KDQpGcm9tOiBBc2gg V2lsc29uIDxhc2gud2lsc29uQHZhbGltYWlsLmNvbTxtYWlsdG86YXNoLndpbHNvbkB2YWxpbWFp bC5jb20+Pg0KU2VudDogV2VkbmVzZGF5LCBKdW5lIDE2LCAyMDIxIDExOjI4IFBNDQpUbzogSGFu bmVzIFRzY2hvZmVuaWcgPEhhbm5lcy5Uc2Nob2ZlbmlnQGFybS5jb208bWFpbHRvOkhhbm5lcy5U c2Nob2ZlbmlnQGFybS5jb20+Pg0KQ2M6IGRhbmlzaEBpZXRmLm9yZzxtYWlsdG86ZGFuaXNoQGll dGYub3JnPg0KU3ViamVjdDogUmU6IFtEYW5pc2hdIENoYXJ0ZXIgVGV4dCBhbmQgdGhlIFByb2Js ZW0gU3RhdGVtZW50DQoNCkhpIEhhbm5lcywNClRoYW5rcyBmb3IgdGhlIHF1ZXN0aW9ucywgYW5k IGFwb2xvZ2llcyBmb3Iga2VlcGluZyB5b3Ugd2FpdGluZyBvbiBhbnN3ZXJzL2NsYXJpZmljYXRp b24uDQoNCk9uIFdlZCwgSnVuIDE2LCAyMDIxIGF0IDQ6MTIgQU0gSGFubmVzIFRzY2hvZmVuaWcg PEhhbm5lcy5Uc2Nob2ZlbmlnQGFybS5jb208bWFpbHRvOkhhbm5lcy5Uc2Nob2ZlbmlnQGFybS5j b20+PiB3cm90ZToNCkhpIGFsbCwNCg0KSSBoYXZlIGJlZW4gcmVhZGluZyB0aHJvdWdoIHRoZSBj aGFydGVyIHRleHQgaW4gYW4gYXR0ZW1wdCB0byB1bmRlcnN0YW5kIHRoZSBwcm9ibGVtIHN0YXRl bWVudC4NCg0KVHdvIHByb2JsZW1zIGFyZSBtZW50aW9uZWQ6DQoNCg0KMSkgIENoYWxsZW5nZXMg d2l0aCBuYW1pbmcgY29sbGlzaW9ucyBpbiB0aGUgSW9UIHNwYWNlLg0KDQoNCg0KMikgIENyZWRl bnRpYWwgaXNzdWFuY2UgaXMgdGltZSBjb25zdW1pbmcuDQoNCg0KQWQgMTogUmVhZGluZyB0aHJv dWdoIHRoZSB0ZXh0IGl0IGZlZWxzIGxpa2UgbmFtaW5nIGNvbGxpc2lvbnMgYXJlIGEgYmlnIHRo aW5nIGluIElvVC4gSSBoYXZlIG5vdCBoZWFyZCBhYm91dCB0aG9zZSBwcm9ibGVtcy4gQ291bGQg eW91IGVsYWJvcmF0ZT8NCkNlcnRhaW5seS4gSSdsbCB1c2UgYSBob3NwaXRhbCBhcyBhbiBleGFt cGxlIGVudmlyb25tZW50Lg0KDQpXaXRoaW4gYSBob3NwaXRhbCwgaXQgaXMgZGVzaXJhYmxlIHRv IGltcGxlbWVudCA4MDIuMXggYXV0aGVudGljYXRpb24gdXNpbmcgRUFQLVRMUyBmb3IgYWNjZXNz IHRvIHByb3RlY3RlZCBuZXR3b3Jrcy4gRUFQLVRMUyBlbmFibGVzIHRoZSB1c2Ugb2YgUEtJLWJh c2VkIGlkZW50aXR5IHRvIGF1dGhlbnRpY2F0ZSBhbiBlbnRpdHkgZm9yIG5ldHdvcmsgYWNjZXNz Lg0KDQpXaGVuIGltcGxlbWVudGluZyBFQVAtVExTIGZvciBuZXR3b3JrIGFjY2VzcywgUkFESVVT IGlzIGEgY29tbW9uIHByb3RvY29sL3NlcnZlciB1c2VkIGZvciBhdXRoZW50aWNhdGlvbiBiZWhp bmQgdGhlIHN3aXRjaCBvciB3aXJlbGVzcyBhY2Nlc3MgcG9pbnQuIEd1aWRhbmNlIGZvciBjb25m aWd1cmluZyBSQURJVVMgcmVjb21tZW5kcyB0aGUgdXNlIG9mIG9ubHkgb25lIENBIGNlcnRpZmlj YXRlIGZvciBhdXRoZW50aWNhdGluZyBzdXBwbGljYW50IGNlcnRpZmljYXRlcy4gVGhpcyBndWlk YW5jZSBjYW4gYmUgZm91bmQgaW4gdGhlIHdpbGQgaW4gRnJlZXJhZGl1cyBjb25maWd1cmF0aW9u IGZpbGVzIGZvciBFQVAtVExTLCByZWxhdGVkIHRvIHRoZSAnY2FfZmlsZScgY29uZmlndXJhdGlv biBkaXJlY3RpdmUuDQoNCkNBcyBndWFyYW50ZWUgdGhlIHVuaXF1ZW5lc3Mgb2YgYW4gZW50aXR5 J3MgbmFtZSB3aXRoaW4gdGhlIHNjb3BlIG9mIHRoZSBDQSwgYnV0IGhhdmUgbm8gbWV0aG9kIGZv ciBlbmZvcmNpbmcgbmFtZSB1bmlxdWVuZXNzIGFjcm9zcyBvdGhlciBDQXMuIEZvciBpbnN0YW5j ZSwgQ0ExIGFuZCBDQTIgbWF5IGJvdGggc2lnbiBjZXJ0aWZpY2F0ZXMgZm9yIGVudGl0aWVzIHdp dGggdGhlIHNhbWUgbmFtZS4gSWYgQ0ExIGFuZCBDQTIgYXJlIGJvdGggdHJ1c3RlZCBieSB0aGUg UkFESVVTIHNlcnZlciwgYW5kIHR3byBlbnRpdGllcyBuYW1lZCAibWVkaWNhbGRldmljZTEyMyIg ZXhpc3QsIG9uZSBwZXIgQ0EsIHRoZW4gdGhlIHJlc3VsdGluZyBhbWJpZ3VpdHkgbWFrZXMgaXQg ZGlmZmljdWx0IHRvIGFwcHJvcHJpYXRlbHkgYXBwbHkgYWNjZXNzIGNvbnRyb2xzLiBUaGlzIGFt YmlndWl0eSBpcyBtaXRpZ2F0ZWQgYnkgb3BlcmF0aW5nIGEgc2luZ2xlIG9yZ2FuaXphdGlvbmFs IFBLSSwgYW5kIHJlcXVpcmluZyBpZGVudGl0aWVzIGlzc3VlZCBieSB0aGF0IHNpbmdsZSBvcmdh bml6YXRpb25hbCBQS0kgZm9yIEVBUC1UTFMgYXV0aGVudGljYXRpb24uDQoNCk9uYm9hcmRpbmcg ZGV2aWNlcyB0byBvcmdhbml6YXRpb25hbCBQS0kgcmVxdWlyZXMgdGltZSBhbmQgZWZmb3J0LiBP ZnRlbnRpbWVzIHNvbWUgc29ydCBvZiBza2lsbGVkIGxhYm9yIGFuZC9vciBkZWRpY2F0ZWQgaW5m cmFzdHJ1Y3R1cmUgZm9yIGF1dG9tYXRpbmcgdGhlIG9uYm9hcmRpbmcgcHJvY2VzcyBpcyBpbnZv bHZlZC4gREFORSBhbGxvd3MgdXMgdG8gYmluZCBhIEROUyBuYW1lIHRvIGEgcHVibGljIGtleSwg YW5kIG1pdGlnYXRlcyB0aGUgYW1iaWd1aXRpZXMgaW50cm9kdWNlZCBieSB0aGUgdXNlIG9mIG11 bHRpcGxlIENBcy4gQW4gb3JnYW5pemF0aW9uIGNhbiBvbmx5IGlzc3VlIHdvcmtpbmcgaWRlbnRp dGllcyB3aXRoaW4gaXRzIG93biBuYW1lc3BhY2UgaW4gRE5TLiBTaW5jZSBuYW1pbmcgYW1iaWd1 aXR5IGNhbiBiZSBtaXRpZ2F0ZWQgdXNpbmcgREFORSwgd2UgbWF5IG5vdyBjaG9vc2UgdG8gdXNl IG1hbnVmYWN0dXJlci1pc3N1ZWQgUEtJLCByZXByZXNlbnRlZCBpbiBETlMsIGZvciBhdXRoZW50 aWNhdGluZyBlbnRpdGllcy4NCg0KRnJvbSB0aGUgaG9zcGl0YWwncyBzdGFuZHBvaW50LCB0aGUg SVQgc3RhZmYgbm8gbG9uZ2VyIG5lZWRzIHRvIG1hbmFnZSB0aGUgcHJvY2VzcyBvZiBvbmJvYXJk aW5nIGRldmljZXMgdG8gb3JnYW5pemF0aW9uYWwgUEtJLiBUaGUgZGV2aWNlIGFycml2ZXMgb24t c2l0ZSB3aXRoIGFuIGlkZW50aXR5IHdoaWNoIGNhbiBiZSBpbW1lZGlhdGVseSB1c2VkIGZvciBu ZXR3b3JrIGF1dGhlbnRpY2F0aW9uLg0KDQpZb3UgYWRkIHRoYXQg4oCcSW4gcmVzcG9uc2UgdG8g dGhlIGNoYWxsZW5nZXMgcmVsYXRlZCB0bw0KDQphbWJpZ3VpdHkgYmV0d2VlbiBpZGVudGl0aWVz IGlzc3VlZCBieSBkaWZmZXJlbnQgQ0FzLCBhcHBsaWNhdGlvbiBvd25lcnMNCg0KZnJlcXVlbnRs eSBjaG9vc2UgdG8gb25ib2FyZCBJb1QgZGV2aWNlcyB0byBhIHNpbmdsZSBDQS7igJ0uIElzIHRo YXQgYSBnb29kIG9yIGEgYmFkIGRldmVsb3BtZW50Pw0KSXQgaXMgYSBnb29kIGRldmVsb3BtZW50 IGlmIHRoZSBvcmdhbml6YXRpb24gcmVhbGx5IHdhbnRzIHRvIGRpcmVjdGx5IG1hbmFnZSBhbGwg b2YgdGhlIGNyZWRlbnRpYWxzIGZvciBhbGwgb2YgdGhlIGFwcGxpY2F0aW9uIHBhcnRpY2lwYW50 cy4gVGhlIGVmZm9ydCBhbmQgcmF0aW9uYWxlIGJlaGluZCBCUlNLSSAoUkZDIDg5OTUpIHN1Z2dl c3RzIGEgZGVzaXJlIHRvIG1ha2Ugb25ib2FyZGluZyB0byBvcmdhbml6YXRpb25hbCBQS0kgZWFz aWVyIHRvIGF1dG9tYXRlLg0KDQpJZiBhIHN1cHBsaWVyIGlzc3VlcyBhIHRydXN0d29ydGh5IGlk ZW50aXR5IGZvciBhIGRldmljZSwgYW5kIEROUyBwcmV2ZW50cyBhbm90aGVyIFBLSSBmcm9tIGlz c3Vpbmcgd29ya2luZyBjcmVkZW50aWFscyB1bmRlciB0aGUgc2FtZSBuYW1lLCB0aGVuIGlzc3Vp bmcgYW5vdGhlciBpZGVudGl0eSB2aWEgb3JnYW5pemF0aW9uYWwgUEtJIGJlY29tZXMgc3VwZXJm bHVvdXMuIFRoaXMgaXMgd2hlcmUgd2UgdGhpbmsgdGhhdCB0aW1lIGFuZCBlZmZvcnQgY2FuIGJl IHNhdmVkLCBiZWNhdXNlIHRoZSBza2lsbHMgcmVxdWlyZWQgZm9yIG9uYm9hcmRpbmcgZG8gbm90 IG5lZWQgdG8gaW5jbHVkZSB0aGUgbWFuYWdlbWVudCBhbmQgaXNzdWFuY2Ugb2YgaWRlbnRpdGll cyB1bmRlciBvcmdhbml6YXRpb25hbCBQS0kuDQoNCkFkIDI6IElzIGl0IHJlYWxseSB0cnVlIHRo YXQgY3JlZGVudGlhbCBpc3N1YW5jZSBpcyB0aW1lIGNvbnN1bWluZz8gV2h5IGlzIHRoYXQ/IEZv ciB3aG9tIGlzIGl0IHRpbWUgY29uc3VtaW5nPw0KQ3JlZGVudGlhbCBpc3N1YW5jZSB2ZXJ5IG9m dGVuIHJlcXVpcmVzIHRoZSBkZXZpY2UgYW5kIHRoZSBwZXJzb24gYm9vdHN0cmFwcGluZyB0aGUg aWRlbnRpdHkgdG8gYmUgaW4gdGhlIHNhbWUgcGxhY2UuIFNvbWUgcGxhdGZvcm1zIGFuZCBwcm90 b2NvbHMgZXhpc3QgdG8gbWFrZSB0aGF0IHByb2Nlc3MgZWFzaWVyIChsaWtlIEJSU0tJKSBvciBs ZXNzIGh1bWFuLWludm9sdmluZy4gVGhlIHRpbWUgaW52ZXN0bWVudCBzZWVtcyB0byBiZSBvbiB0 aGUgcGFydCBvZiBib3RoIHRoZSBtYW51ZmFjdHVyZXIgKGluIGlzc3VpbmcgdGhlIElEZXZJRCkg YXMgd2VsbCBhcyB0aGUgb3JnYW5pemF0aW9uYWwgSVQgc3RhZmYsIHdobyBtYW5hZ2UgdGhlIG9y Z2FuaXphdGlvbmFsIFBLSS4NCg0KQ2lhbw0KSGFubmVzDQoNClBTOiBZb3UgdXNlIHRoZSB0ZXJt IOKAnENlcnRpZmljYXRlIEF1dGhvcml0eSAoQ0Ep4oCdLiBJdCBpcyBhY3R1YWxseSBjYWxsZWQg 4oCcQ2VydGlmaWNhdGlvbiBBdXRob3JpdHnigJ0uDQoNCg0KSU1QT1JUQU5UIE5PVElDRTogVGhl IGNvbnRlbnRzIG9mIHRoaXMgZW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBhcmUgY29uZmlkZW50 aWFsIGFuZCBtYXkgYWxzbyBiZSBwcml2aWxlZ2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5k ZWQgcmVjaXBpZW50LCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYW5kIGRv IG5vdCBkaXNjbG9zZSB0aGUgY29udGVudHMgdG8gYW55IG90aGVyIHBlcnNvbiwgdXNlIGl0IGZv ciBhbnkgcHVycG9zZSwgb3Igc3RvcmUgb3IgY29weSB0aGUgaW5mb3JtYXRpb24gaW4gYW55IG1l ZGl1bS4gVGhhbmsgeW91Lg0KLS0NCkRhbmlzaCBtYWlsaW5nIGxpc3QNCkRhbmlzaEBpZXRmLm9y ZzxtYWlsdG86RGFuaXNoQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9kYW5pc2gNCg0KDQotLQ0KQXNoIFdpbHNvbiB8IFRlY2huaWNhbCBEaXJlY3Rvcg0K ZTogYXNoLndpbHNvbkB2YWxpbWFpbC5jb208bWFpbHRvOmFzaC53aWxzb25AdmFsaW1haWwuY29t Pg0KW2h0dHBzOi8vaG9zdGVkLXBhY2thZ2VzLnMzLXVzLXdlc3QtMS5hbWF6b25hd3MuY29tL1Zh bGltYWlsK0xvZ28ucG5nXQ0KDQpUaGlzIGVtYWlsIGFuZCBhbGwgZGF0YSB0cmFuc21pdHRlZCB3 aXRoIGl0IGNvbnRhaW5zIGNvbmZpZGVudGlhbCBhbmQvb3IgcHJvcHJpZXRhcnkgaW5mb3JtYXRp b24gaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgdXNlIG9mIGluZGl2aWR1YWwocykgYXV0aG9yaXpl ZCB0byByZWNlaXZlIGl0LiBJZiB5b3UgYXJlIG5vdCBhbiBpbnRlbmRlZCBhbmQgYXV0aG9yaXpl ZCByZWNpcGllbnQgeW91IGFyZSBoZXJlYnkgbm90aWZpZWQgb2YgYW55IHVzZSwgZGlzY2xvc3Vy ZSwgY29weWluZyBvciBkaXN0cmlidXRpb24gb2YgdGhlIGluZm9ybWF0aW9uIGluY2x1ZGVkIGlu IHRoaXMgdHJhbnNtaXNzaW9uIGlzIHByb2hpYml0ZWQgYW5kIG1heSBiZSB1bmxhd2Z1bC4gUGxl YXNlIGltbWVkaWF0ZWx5IG5vdGlmeSB0aGUgc2VuZGVyIGJ5IHJlcGx5aW5nIHRvIHRoaXMgZW1h aWwgYW5kIHRoZW4gZGVsZXRlIGl0IGZyb20geW91ciBzeXN0ZW0uDQpJTVBPUlRBTlQgTk9USUNF OiBUaGUgY29udGVudHMgb2YgdGhpcyBlbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIGFyZSBjb25m aWRlbnRpYWwgYW5kIG1heSBhbHNvIGJlIHByaXZpbGVnZWQuIElmIHlvdSBhcmUgbm90IHRoZSBp bnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBh bmQgZG8gbm90IGRpc2Nsb3NlIHRoZSBjb250ZW50cyB0byBhbnkgb3RoZXIgcGVyc29uLCB1c2Ug aXQgZm9yIGFueSBwdXJwb3NlLCBvciBzdG9yZSBvciBjb3B5IHRoZSBpbmZvcm1hdGlvbiBpbiBh bnkgbWVkaXVtLiBUaGFuayB5b3UuDQoNCg0KLS0NCkFzaCBXaWxzb24gfCBUZWNobmljYWwgRGly ZWN0b3INCmU6IGFzaC53aWxzb25AdmFsaW1haWwuY29tPG1haWx0bzphc2gud2lsc29uQHZhbGlt YWlsLmNvbT4NCltodHRwczovL2hvc3RlZC1wYWNrYWdlcy5zMy11cy13ZXN0LTEuYW1hem9uYXdz LmNvbS9WYWxpbWFpbCtMb2dvLnBuZ10NCg0KVGhpcyBlbWFpbCBhbmQgYWxsIGRhdGEgdHJhbnNt aXR0ZWQgd2l0aCBpdCBjb250YWlucyBjb25maWRlbnRpYWwgYW5kL29yIHByb3ByaWV0YXJ5IGlu Zm9ybWF0aW9uIGludGVuZGVkIHNvbGVseSBmb3IgdGhlIHVzZSBvZiBpbmRpdmlkdWFsKHMpIGF1 dGhvcml6ZWQgdG8gcmVjZWl2ZSBpdC4gSWYgeW91IGFyZSBub3QgYW4gaW50ZW5kZWQgYW5kIGF1 dGhvcml6ZWQgcmVjaXBpZW50IHlvdSBhcmUgaGVyZWJ5IG5vdGlmaWVkIG9mIGFueSB1c2UsIGRp c2Nsb3N1cmUsIGNvcHlpbmcgb3IgZGlzdHJpYnV0aW9uIG9mIHRoZSBpbmZvcm1hdGlvbiBpbmNs dWRlZCBpbiB0aGlzIHRyYW5zbWlzc2lvbiBpcyBwcm9oaWJpdGVkIGFuZCBtYXkgYmUgdW5sYXdm dWwuIFBsZWFzZSBpbW1lZGlhdGVseSBub3RpZnkgdGhlIHNlbmRlciBieSByZXBseWluZyB0byB0 aGlzIGVtYWlsIGFuZCB0aGVuIGRlbGV0ZSBpdCBmcm9tIHlvdXIgc3lzdGVtLg0KSU1QT1JUQU5U IE5PVElDRTogVGhlIGNvbnRlbnRzIG9mIHRoaXMgZW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBh cmUgY29uZmlkZW50aWFsIGFuZCBtYXkgYWxzbyBiZSBwcml2aWxlZ2VkLiBJZiB5b3UgYXJlIG5v dCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRp YXRlbHkgYW5kIGRvIG5vdCBkaXNjbG9zZSB0aGUgY29udGVudHMgdG8gYW55IG90aGVyIHBlcnNv biwgdXNlIGl0IGZvciBhbnkgcHVycG9zZSwgb3Igc3RvcmUgb3IgY29weSB0aGUgaW5mb3JtYXRp b24gaW4gYW55IG1lZGl1bS4gVGhhbmsgeW91Lg0KDQoNCi0tDQpBc2ggV2lsc29uIHwgVGVjaG5p Y2FsIERpcmVjdG9yDQplOiBhc2gud2lsc29uQHZhbGltYWlsLmNvbTxtYWlsdG86YXNoLndpbHNv bkB2YWxpbWFpbC5jb20+DQpbaHR0cHM6Ly9ob3N0ZWQtcGFja2FnZXMuczMtdXMtd2VzdC0xLmFt YXpvbmF3cy5jb20vVmFsaW1haWwrTG9nby5wbmddDQoNClRoaXMgZW1haWwgYW5kIGFsbCBkYXRh IHRyYW5zbWl0dGVkIHdpdGggaXQgY29udGFpbnMgY29uZmlkZW50aWFsIGFuZC9vciBwcm9wcmll dGFyeSBpbmZvcm1hdGlvbiBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgaW5kaXZpZHVh bChzKSBhdXRob3JpemVkIHRvIHJlY2VpdmUgaXQuIElmIHlvdSBhcmUgbm90IGFuIGludGVuZGVk IGFuZCBhdXRob3JpemVkIHJlY2lwaWVudCB5b3UgYXJlIGhlcmVieSBub3RpZmllZCBvZiBhbnkg dXNlLCBkaXNjbG9zdXJlLCBjb3B5aW5nIG9yIGRpc3RyaWJ1dGlvbiBvZiB0aGUgaW5mb3JtYXRp b24gaW5jbHVkZWQgaW4gdGhpcyB0cmFuc21pc3Npb24gaXMgcHJvaGliaXRlZCBhbmQgbWF5IGJl IHVubGF3ZnVsLiBQbGVhc2UgaW1tZWRpYXRlbHkgbm90aWZ5IHRoZSBzZW5kZXIgYnkgcmVwbHlp bmcgdG8gdGhpcyBlbWFpbCBhbmQgdGhlbiBkZWxldGUgaXQgZnJvbSB5b3VyIHN5c3RlbS4NCg0K SU1QT1JUQU5UIE5PVElDRTogVGhlIGNvbnRlbnRzIG9mIHRoaXMgZW1haWwgYW5kIGFueSBhdHRh Y2htZW50cyBhcmUgY29uZmlkZW50aWFsIGFuZCBtYXkgYWxzbyBiZSBwcml2aWxlZ2VkLiBJZiB5 b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5k ZXIgaW1tZWRpYXRlbHkgYW5kIGRvIG5vdCBkaXNjbG9zZSB0aGUgY29udGVudHMgdG8gYW55IG90 aGVyIHBlcnNvbiwgdXNlIGl0IGZvciBhbnkgcHVycG9zZSwgb3Igc3RvcmUgb3IgY29weSB0aGUg aW5mb3JtYXRpb24gaW4gYW55IG1lZGl1bS4gVGhhbmsgeW91Lg0K --_000_DBBPR08MB59153F3F972DBB5EE70D5234FA0B9DBBPR08MB5915eurp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYg MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpEZW5nWGlhbjsNCglwYW5vc2UtMToy IDEgNiAwIDMgMSAxIDEgMSAxO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsN CglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30NCkBmb250LWZh Y2UNCgl7Zm9udC1mYW1pbHk6IlxARGVuZ1hpYW4iOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEg MSAxIDE7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3Jt YWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxp bmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0 aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHls ZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGluOw0KCWZvbnQtc2l6 ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpzcGFuLkhUTUxQcmVmb3Jt YXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCglt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVk IjsNCglmb250LWZhbWlseTpDb25zb2xhczt9DQpzcGFuLkVtYWlsU3R5bGUyMQ0KCXttc28tc3R5 bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJp ZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBl OmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdl IFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4g MS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQot LT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4 dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3Rl IG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpl eHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+ DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSIg c3R5bGU9IndvcmQtd3JhcDpicmVhay13b3JkIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSBBc2gsIDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5J IGJlbGlldmUgeW91IGFuZCBvdGhlcnMgaW4gdGhlIGdyb3VwIGhhdmUgYSB2aXNpb24gdGhhdCBz b21laG93IHJlbGF0ZXMgdG8gSW9UIHdoZXJlIHRoZSB1c2Ugb2YgREFORSBmb3IgY2xpZW50IGF1 dGhlbnRpY2F0aW9uIGluIFRMUyBmaXRzIGluIHRoZXJlLiBXaGF0IGhhcyBub3QgYmVlbiBkb25l IHlldCBpcyB0byBwdXQgdGhpcyB2aXNpb24gaW4gd3JpdGluZy4gSXQgbWF5IGJlIHRoYXQgdGhp cyB2aXNpb24NCiBpcyBtb3JlIHNvbHV0aW9uIG9yaWVudGVkIHRoYW4gcHJvYmxlbSBvcmllbnRl ZCBidXQsIGlmIHlvdSB3YW50IHRvIGF0dHJhY3Qgb3RoZXJzIGluIHRoZSB3b3JrIChhc3N1bWlu ZyB5b3Ugd2FudCB0aGF0KSwgeW91IHdpbGwgaGF2ZSB0byBzb21laG93IGV4cGxhaW4gaG93IHRo ZXNlIHNtYWxsIGJ1aWxkaW5nIGJsb2NrcyBlbmFibGUgc29tZXRoaW5nIGJpZ2dlci4NCjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5DaWFvPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5IYW5uZXM8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAj RTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGI+RnJvbTo8L2I+IEFzaCBXaWxzb24gJmx0O2FzaC53aWxzb25AdmFsaW1haWwuY29t Jmd0OyA8YnI+DQo8Yj5TZW50OjwvYj4gU3VuZGF5LCBKdW5lIDIwLCAyMDIxIDY6NDcgQU08YnI+ DQo8Yj5Ubzo8L2I+IEhhbm5lcyBUc2Nob2ZlbmlnICZsdDtIYW5uZXMuVHNjaG9mZW5pZ0Bhcm0u Y29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gZGFuaXNoQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8 L2I+IFJlOiBbRGFuaXNoXSBDaGFydGVyIFRleHQgYW5kIHRoZSBQcm9ibGVtIFN0YXRlbWVudDxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBTYXQsIEp1biAxOSwg MjAyMSBhdCA1OjQ3IEFNIEhhbm5lcyBUc2Nob2ZlbmlnICZsdDs8YSBocmVmPSJtYWlsdG86SGFu bmVzLlRzY2hvZmVuaWdAYXJtLmNvbSI+SGFubmVzLlRzY2hvZmVuaWdAYXJtLmNvbTwvYT4mZ3Q7 IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGlu IDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkhpIEFzaCwNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+SWYgdGhlIG5ldHdvcmsgYWNjZXNzIGF1dGhlbnRpY2F0aW9uIHVzZSBjYXNlIHdpdGgg RUFQLVRMUyBpcyBpbXBvcnRhbnQgdG8geW91IHRoZW4gSSBiZWxpZXZlIGl0IHdvdWxkIGJlIGdv b2QgdG8gYWRkIGl0IGFzIGEgbWlsZXN0b25lIG9uIHRoZSBjaGFydGVyLiBZb3UgY2Fubm90IHVz ZSBhbiBpbXBsZW1lbnRhdGlvbg0KIG9mIGRyYWZ0LWlldGYtZW11LWVhcC10bHMxMyBhbmQgYXNz dW1lIGFueSBvZiB0aGUgREFORSBmdW5jdGlvbmFsaXR5IHRvIHdvcmsuIFlvdSB3b3VsZCBpbmRl ZWQgaGF2ZSB0byByZWx5IG9uIGRyYWZ0LWlldGYtdGxzLWRuc3NlYy1jaGFpbi1leHRlbnNpb24g YmVjYXVzZSBub3QgaGF2aW5nIG5ldHdvcmsgY29ubmVjdGl2aXR5IGlzIHRoZSBtYWluIHJlYXNv biB3aHkgeW91IHdvdWxkIGJlIHJ1bm5pbmcgdGhlIEVBUC1UTFMgZXhjaGFuZ2UgaW4NCiB0aGUg Zmlyc3QgcGxhY2UuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3Rl Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBwcm9jZXNzIG9mIHVzaW5nIERBTkUg Zm9yIGF1dGhlbnRpY2F0aW5nIGFuIEVBUC1UTFMgc3VwcGxpY2FudCwgZnJvbSB0aGUgYXV0aGVu dGljYXRpb24gc2VydmVyJ3MmbmJzcDtwZXJzcGVjdGl2ZSwgaXMgZXhwZWN0ZWQgdG8gYmUgbW9y ZSBzdHJhaWdodGZvcndhcmQuIEl0IGlzIG5vdCB1bm5hdHVyYWwgZm9yIHRoZSBhdXRoZW50aWNh dGlvbiBzZXJ2ZXIgdG8gaGF2ZSB0aGUgSVAgY29ubmVjdGl2aXR5IHJlcXVpcmVkDQogdG8gcmV0 cmlldmUgdGhlIFRMU0EgcmVjb3JkIGZvciZuYnNwO2F1dGhlbnRpY2F0aW5nIHRoZSBjbGllbnQn cyZuYnNwO2NlcnRpZmljYXRlLiBUaGUgY29tcGxleGl0eSBvZiBnZXR0aW5nIERBTkUgdG8gd29y ayBmb3IgYWxsb3dpbmcgdGhlIHN1cHBsaWNhbnQgdG8gYXV0aGVudGljYXRlIHRoZSBhdXRoZW50 aWNhdGlvbiBzZXJ2ZXIgaXMgY2VydGFpbmx5IG1vcmUgY29tcGxpY2F0ZWQsIGFuZCBhbHNvIGlu dHJvZHVjZXMgYSBkZXBlbmRlbmN5IG9uIHRoZSBETlNTRUMNCiBjaGFpbiBleHRlbnNpb24uPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFy Z2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPlJlZ2FyZGluZyDigJxiZXN0IHByYWN0aWNlIHRvIGVuc3VyZSB0aGF0IGEgZGV2aWNlIGlz IHBhdGNoZWQgYmVmb3JlIHB1dHRpbmcgaXQgaW50byBwcm9kdWN0aW9uLCBhbmQgdXBkYXRpbmcg cm9vdHMgb2YgdHJ1c3QgZml0cyB3aXRoaW4gdGhlIHNjb3BlIG9mIHRoYXQgc29ydCBvZiBhY3Rp dml0eeKAnTogSSBkb27igJl0DQogdGhpbmsgdGhlcmUgaXMgYW55IGV4cGVjdGF0aW9uIHRoYXQg dGhlIGRldmljZSB3aWxsIGJlIHVwZGF0ZWQgYmVmb3JlIGl0IGlzIHB1dCBpbiBwcm9kdWN0aW9u IChpLmUuIHBvd2VyZWQgb24gZm9yIHRoZSBmaXJzdCB0aW1lKS4gWW91IGNhbiBhc3N1bWUgdGhh dCB0aGUgZGV2aWNlLCB3aGVuIGl0IGNvbWVzIG9ubGluZSBmb3IgdGhlIGZpcnN0IHRpbWUgYW5k IHJlYWNoZXMgb3V0IHRvIHRoZSBkZXZpY2UgbWFuYWdlbWVudCBzZXJ2ZXIsIGdldHMNCiBhIGZp cm13YXJlIHVwZGF0ZS4gSGF2aW5nIHRoYXQgZmlybXdhcmUgdXBkYXRlIGhhcHBlbiBiZWZvcmUg aXQgaXMgY29ubmVjdGVkIHRvIHRoZSBuZXR3b3JrIGlzIGV4dHJlbWVseSB1bmxpa2VseS48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5n OjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5FQVAtVExTIGlzIGFsc28gbm90IGFuIElvVCBkZXZp Y2Ugb25ib2FyZGluZyBwcm90b2NvbC4gRnJvbSB0aGUgY2hhcnRlciB0ZXh0IEkgYW0gYWxzbyBu b3QgYXNzdW1pbmcgdGhhdCB5b3UgYXJlIGF0dGVtcHRpbmcgdG8gZGVmaW5lIGEgbmV3IElvVCBv bmJvYXJkaW5nIHByb3RvY29sIG9yIGRvIHlvdT88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2UgYXJlIGJl aW5nIHZlcnkgY2FyZWZ1bCB3aXRoIHRoZSBzY29wZSBvZiB0aGUgY2hhcnRlciwgdG8gc3RheSBm b2N1c2VkIG9uIGNsaWVudCBhdXRoZW50aWNhdGlvbiBpbiB0aGUgVExTIGhhbmRzaGFrZSBhbmQg cHVibGljIGtleSBkaXNjb3ZlcnkgZm9yIGF1dGhlbnRpY2F0aW5nIG1lc3NhZ2VzLiBBZGRyZXNz aW5nIHRoZSBudWFuY2VzIG9mIEVBUC1UTFMsIGVzcGVjaWFsbHkgZm9yIHN1cHBvcnRpbmcgVExT DQogMS4zLCBzZWVtcyBsaWtlIHRoZSBzb3J0IG9mIHdvcmsgd2UgbWF5IHdhbnQgdG8gcmUtY2hh cnRlciB0byBhY2NvbXBsaXNoIHVubGVzcyB0aGVyZSdzIGVub3VnaCBpbnRlcmVzdCBpbiB0aGUg YmVnaW5uaW5nIHRvIGJyaW5nIGl0IGluLXNjb3BlLiBJJ20gdmVyeSBoYXBweSB0byBoZWFyIHRo YXQgeW91J3JlIGludGVyZXN0ZWQgaW4gaG93IEVBUC1UTFMgd2lsbCZuYnNwO2ZpdCB3aXRoIHRo aXMgZWZmb3J0IGFuZCBJIGhhdmUgbm8gb2JqZWN0aW9uIHRvDQogaW5jbHVkaW5nIHRoaXMgaW4g dGhlIGNoYXJ0ZXIsIGFzIGxvbmcgYXMgdGhlIGNoYWlycyBhcmUgT0sgd2l0aCBpdC48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1s ZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4t bGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ UmVnYXJkaW5nIHRoZSBob21lIElvVCBlbnZpcm9ubWVudDogSSB3b3VsZCBub3QgY291bnQgb24g Q0hJUC9NYXR0ZXIgcmUtdXNpbmcgeW91ciB3b3JrLiBNeSB1bmRlcnN0YW5kaW5nIGlzIHRoYXQg dGhleSBhcmUgY3JlYXRpbmcgdGhlaXIgb3duIHNvbHV0aW9ucy4gU2luY2UgdGhlIGhvbWUgZW52 aXJvbm1lbnQNCiBpcyB2ZXJ5IGZyYWdtZW50ZWQsIGl0IG1pZ2h0IG5vdCBiZSB0aGUgZWFzaWVz dCBwbGFjZSB0byBzdGFydC4gT2YgY291cnNlLCB5b3VyIGNvbXBhbnkgbWF5IHBsYXkgYW5kIHRo YXQgZmllbGQgYW5kIHNvIHlvdSBtaWdodCBoYXZlIGEgd2F5IHRvIGdldCB0aGUgb3V0Y29tZSBv ZiBEQU5JU0ggZGVwbG95ZWQgdGhlcmUuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJn aW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+SSBhbSBzdGlsbCB0cnlpbmcgdG8gZmlndXJlIG91dCBob3cgREFOSVNIIGZpdHMgaW50byB0 aGUgbGFyZ2VyIHBpY3R1cmUgYW5kIGhlbmNlIEkgYW0gbG9va2luZyBmb3J3YXJkIHRvIHJlYWQg YW4gYXJjaGl0ZWN0dXJlIGRvY3VtZW50LiBJcyB0aGUgYSBwcmUtZHJhZnQgYXZhaWxhYmxlIGFs cmVhZHk/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwO1RoZSBhcmNoaXRlY3R1cmUgZG9jdW1lbnQg aXMgdmVyeSByb3VnaCBhbmQgbm90IHJlYWR5IGV2ZW4gZm9yIHByZS1kcmFmdCByZXZpZXcuJm5i c3A7IEkgd2lsbCBwcmlvcml0aXplIGltcHJvdmluZyB0aGlzIGRvY3VtZW50IGFuZCBzaGFyZSBp dCB3aXRoIHlvdSBBU0FQLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90 ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRk aW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4i Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5DaWFvPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPkhhbm5lczxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+RnJvbTo8L2I+IEFzaCBXaWxzb24gJmx0OzxhIGhyZWY9 Im1haWx0bzphc2gud2lsc29uQHZhbGltYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmFzaC53aWxz b25AdmFsaW1haWwuY29tPC9hPiZndDsNCjxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgSnVu ZSAxNywgMjAyMSA4OjIyIFBNPGJyPg0KPGI+VG86PC9iPiBIYW5uZXMgVHNjaG9mZW5pZyAmbHQ7 PGEgaHJlZj0ibWFpbHRvOkhhbm5lcy5Uc2Nob2ZlbmlnQGFybS5jb20iIHRhcmdldD0iX2JsYW5r Ij5IYW5uZXMuVHNjaG9mZW5pZ0Bhcm0uY29tPC9hPiZndDs8YnI+DQo8Yj5DYzo8L2I+IDxhIGhy ZWY9Im1haWx0bzpkYW5pc2hAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5kYW5pc2hAaWV0Zi5v cmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbRGFuaXNoXSBDaGFydGVyIFRleHQgYW5k IHRoZSBQcm9ibGVtIFN0YXRlbWVudDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPkhpIEhhbm5lcyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+R3JlYXQgcXVlc3Rpb25zLCByZXNwb25zZXMgaW4tbGlu ZSBiZWxvdy4uLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPk9uIFdlZCwgSnVuIDE2LCAyMDIxIGF0IDExOjQzIFBNIEhhbm5lcyBUc2Nob2ZlbmlnICZs dDs8YSBocmVmPSJtYWlsdG86SGFubmVzLlRzY2hvZmVuaWdAYXJtLmNvbSIgdGFyZ2V0PSJfYmxh bmsiPkhhbm5lcy5Uc2Nob2ZlbmlnQGFybS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNv bGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0 LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBw dCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VGhhbmtzIGZvciB5b3Vy IGZlZWRiYWNrLCBBc2guDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkl0IGlzIGludGVy ZXN0aW5nIHRoYXQgeW91IG1lbnRpb24gdGhlIG5ldHdvcmsgYWNjZXNzIGF1dGhlbnRpY2F0aW9u IHVzZSBjYXNlLiBEbyB5b3UgZW52aXNpb24gRUFQLVRMUyBpbiBjb21iaW5hdGlvbiB3aXRoIERh bmlzaCB0byB3b3JrIGFyY2hpdGVjdHVyYWxseSBkaWZmZXJlbnRseSB0aGFuIHRoZSBjdXJyZW50 DQogRUFQLVRMUy1iYXNlZCBhcHByb2FjaD88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+V2UgaG9w ZSB0byBtaW5pbWl6ZSB0aGUmbmJzcDthbW91bnQgb2Ygd29yayByZXF1aXJlZCB0byBlbmFibGUg REFORSBjbGllbnQgSUQgZm9yIEVBUC1UTFMuIFNvbWUgY2hhbGxlbmdlcyByZW1haW4gd2l0aCBF QVAtVExTIGluIGNvbmp1bmN0aW9uIHdpdGggVExTIDEuMzoNCjxhIGhyZWY9Imh0dHBzOi8vZGF0 YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtaWV0Zi1lbXUtZWFwLXRsczEzLTE2IiB0 YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2Ry YWZ0LWlldGYtZW11LWVhcC10bHMxMy0xNjwvYT4uIFN1cHBvcnRpbmcgVExTIDEuMiBmb3IgRUFQ LVRMUyBhbmQgREFORSB3b3VsZCBsaWtlbHkgYmUgbW9yZSBzdHJhaWdodGZvcndhcmQsIGJ1dCBJ IGRvIG5vdCBrbm93IHdoZXRoZXIgdGhlcmUncyBtdWNoIGludGVyZXN0IGluIHVwZGF0aW5nIFRM UyAxLjIgdG8gY292ZXIgdGhpcyB1c2UgY2FzZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkRBTkUgc2VydmVyIGF1dGhlbnRpY2F0aW9u IHdpdGggRUFQLVRMUyBicmluZ3MgYW5vdGhlciBjaGFsbGVuZ2U6IHRoZSBhYnNlbmNlIG9mIElQ IGNvbm5lY3Rpdml0eSBwcmlvciB0byBhdXRoZW50aWNhdGlvbi4gVGhpcyBjb3VsZCBiZSByZW1l ZGllZCBieSZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0 bWwvZHJhZnQtaWV0Zi10bHMtZG5zc2VjLWNoYWluLWV4dGVuc2lvbi0wNyIgdGFyZ2V0PSJfYmxh bmsiPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtaWV0Zi10bHMt ZG5zc2VjLWNoYWluLWV4dGVuc2lvbi0wNzwvYT4sDQogaWYgdGhlIHdvcmsgb24gdGhhdCBkcmFm dCB3ZXJlIHRvIGNvbnRpbnVlLiBUaGVyZSBhcmUgYWxzbyBjaGFsbGVuZ2VzIHdpdGggdmFsaWRh dGluZyB0aGUgY2hhaW4sIHRpZWQgdG8gcm9vdCBrZXkgcm90YXRpb24uIERldmljZXMgd2hpY2gg cmVtYWluIHVucGx1Z2dlZCB0b28gbG9uZyBtYXkgbm90IGJlIGFibGUgdG8gYXV0aGVudGljYXRl LiBPbiB0aGUgb3RoZXIgaGFuZCwgaXQgaXMgYSBiZXN0IHByYWN0aWNlIHRvIGVuc3VyZSB0aGF0 IGEgZGV2aWNlDQogaXMgcGF0Y2hlZCBiZWZvcmUgcHV0dGluZyBpdCBpbnRvIHByb2R1Y3Rpb24s IGFuZCB1cGRhdGluZyByb290cyBvZiB0cnVzdCBmaXRzIHdpdGhpbiB0aGUgc2NvcGUgb2YgdGhh dCBzb3J0IG9mIGFjdGl2aXR5LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+SWYgb25seSBEQU5FIGZvciBjbGllbnQgYXV0aGVudGljYXRp b24gaXMgc3VwcG9ydGVkIGluIEVBUC1UTFMsIHdoaWNoIGlzIHRoZSBsaWtlbHkgaW5pdGlhbCBv dXRjb21lLCB0aGUgY2hhbGxlbmdlIG9mIGdldHRpbmcgdGhlIGF1dGhlbnRpY2F0aW9uIHNlcnZl cidzIENBIGNlcnRpZmljYXRlIG9udG8gdGhlDQogZGV2aWNlIHN0aWxsIGV4aXN0cy4gVGhpcyBz dGlsbCByZXByZXNlbnRzIGEgcmVkdWN0aW9uIGluIGVmZm9ydCBvbiB0aGUgcGFydCBvZiB0aGUg SVQgc3RhZmYsIGJ1dCBub3QgYSBwZXJmZWN0IHplcm8tdG91Y2ggb25ib2FyZGluZyB1bmxlc3Mg dGhlIHN1cHBsaWVyIGFsc28gcHJvdmlzaW9ucyB0aGUgQ0EgY2VydHMgZm9yIHRoZSBhdXRoZW50 aWNhdGlvbiBzZXJ2ZXIuLi4gYW5kIGluIHRoZSBjYXNlIG9mIFdpRmksIHRoZSBTU0lEIHRvIGFz c29jaWF0ZQ0KIHdpdGguIFN0aWxsLCB3ZSB0aGluayB0aGlzIHJlcHJlc2VudHMgYSBzdWJzdGFu dGlhbCBpbXByb3ZlbWVudCBpbiB0aGUgb25ib2FyZGluZyBleHBlcmllbmNlIGZvciB0aGUmbmJz cDtpbXBsZW1lbnRlci48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6 MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJn aW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj5Zb3Ugd3JpdGU6DQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ 4oCcQ3JlZGVudGlhbCBpc3N1YW5jZSB2ZXJ5IG9mdGVuIHJlcXVpcmVzIHRoZSBkZXZpY2UgYW5k IHRoZSBwZXJzb24gYm9vdHN0cmFwcGluZyB0aGUgaWRlbnRpdHkgdG8gYmUgaW4gdGhlIHNhbWUg cGxhY2XigJ08bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkJpbmRpbmcgdGhlIHVzZXIgdG8g aGlzIG9yIGhlciBkZXZpY2UgdHlwaWNhbGx5IHRha2VzIHNvbWUgdGltZS4gSXQgb2Z0ZW4gcmVx dWlyZXMgdGhlIHVzZXIgdG8gbG9nIGludG8gc29tZSBzZXJ2aWNlIGFuZCB0byDigJxhZGTigJ0g dGhlIG5ldyBkZXZpY2Ugb2Z0ZW4gYnkgZGVtb25zdHJhdGluZyBwaHlzaWNhbA0KIHBvc3Nlc3Np b24uIE9mIGNvdXJzZSwgdGhpcyBpcyB0aGUgd2F5IGhvdyBpdCB3b3JrcyBmb3IgZW5kIGNvbnN1 bWVyIHByb2R1Y3RzLCB3aGVyZSBzY2FsYWJpbGl0eSBpcyBsZXNzIG9mIGFuIGlzc3VlIGJlY2F1 c2UgeW91IGFyZSBwcm9iYWJseSBub3QgZ29pbmcgdG8gYnV5IHRob3VzYW5kcyBvZiBzbWFydCBj b2ZmZWUgbWFjaGluZXMuIEZvciBhIGNvbW1lcmNpYWwgc2V0dXAsIHRoZSBwcm9jZXNzIG9mdGVu IHdvcmtzIGRpZmZlcmVudCBidXQNCiBpdCB2ZXJ5IG11Y2ggZGVwZW5kcyBvbiB0aGUgdHlwZSBv ZiBpbmR1c3RyeSB2ZXJ0aWNhbCB5b3UgYXJlIGluLiBUaGVyZSBpcyBvZnRlbiBhIG5vbi1pcnJl bGV2YW50IGNvbmZpZ3VyYXRpb24gc3RlcCBpbnZvbHZlZCBhcyB3ZWxsLiBGb3IgZXhhbXBsZSwg d2l0aCBjb21tZXJjaWFsIGluZG9vciBsaWdodGluZyBwcm9mZXNzaW9uYWxzIG5lZWQgdG8gY29u ZmlndXJlIGRpZmZlcmVudCBsaWdodGluZyB0aGVtZXMuPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj5JIGRvbuKAmXQgc2VlIGFueSBvZiB0aGlzIHVzZXItcmVsYXRlZCBpbnRlcmFjdGlvbiBi ZWluZyBjb3ZlcmVkIGFzIHBhcnQgb2YgdGhlIGNoYXJ0ZXJlZCB3b3JrLjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj5EQU5FIGNhbiBiZSB1c2VmdWwgZm9yIGhvbWUgSW9ULiBJIHRoaW5rIHRoYXQg aXQgY291bGQgcmVkdWNlIHRoZSBjb21wbGV4aXR5IG9mIGF1dG9tYXRpb24gd2hlcmV2ZXIgcHJp dmF0ZSBQS0kgaXMgYmVpbmcgbWFuYWdlZCBpbiB0aGUgY29uc3VtZXIncyBlbnZpcm9ubWVudCwg YW5kIGFjY2VsZXJhdGUgYW5kDQogc2ltcGxpZnkgdGhlIG9uYm9hcmRpbmcgZXhwZXJpZW5jZS4g SUVURiBpcyBhY2Nlc3NpYmxlIGFuZCB3aWRlLXJlYWNoaW5nLCBhbmQgc2VlbXMgbGlrZSB0aGUg cmlnaHQgcGxhY2UgdG8gcHJlc2VudCBhbmQgcmVmaW5lIHRoZSBkZXNpZ24gcGF0dGVybiB0aGF0 IG1pZ2h0IGJlIGFkb3B0ZWQgbGF0ZXIgYnkgb3RoZXIgc3RhbmRhcmRzIChsaWtlIENISVAvTWF0 dGVyKS4gSSdtIGFsc28gb3BlcmF0aW5nIHVuZGVyIHRoZSBhc3N1bXB0aW9uIHRoYXQNCiBlbnRl cnByaXNlIElvVCBoYXMgYSBtb3JlIHJlY29nbml6ZWQgbmVlZCBmb3IgaW50ZXJvcGVyYWJpbGl0 eSBhbmQgc2ltcGxlciBzZWN1cmUmbmJzcDtvbmJvYXJkaW5nIHByb2Nlc3Nlcy4gVGhhdCBpcyBh IGJpZyBhc3N1bXB0aW9uLCBhbmQgb25seSBiYXNlZCBvbiBteSBvYnNlcnZhdGlvbnMgdGh1cyBm YXIuIEknbSBvcGVuIHRvIGluY2x1ZGluZyB0aGUgaG9tZSBjb25zdW1lcidzIHBlcnNwZWN0aXZl IGluIHRoaXMgZWZmb3J0LCBpZiB5b3UgdGhpbmsNCiBpdCdzIHdvcnRod2hpbGUuPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+QXMgZmFyIGFzIGRlc2NyaWJp bmcgdGhlIGdlbmVyYWwgb25ib2FyZGluZyBleHBlcmllbmNlIGZvciB0aGUgaW1wbGVtZW50ZXIs IEkgaGFkIGhvcGVkIHRvIGluY2x1ZGUgdGhhdCBpbiB0aGUgYXJjaGl0ZWN0dXJlIGRvY3VtZW50 IGFsb25nIHdpdGggZXhhbXBsZXMgb2YgaG93IERBTkUgbWlnaHQgaW50ZXJmYWNlDQogd2l0aCBh bmQgc3VwcG9ydCBvdGhlciBzdGFuZGFyZHMgaW4gdGhlIGJyb2FkZXIgZWNvc3lzdGVtLiBJbiB0 cnlpbmcgdG8ga2VlcCB0aGUgY2hhcnRlciBjb25jaXNlLCBJIHRoaW5rIHdlIGxlZnQgb3V0IHNv bWUgaW1wb3J0YW50IGluZm9ybWF0aW9uLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+WW91IGJyaW5nIHVwIGFuIGludGVyZXN0aW5nIHBv aW50LCB3aXRoIHRoZSBjb25maWd1cmF0aW9uIG9mIGxpZ2h0aW5nIHByb2ZpbGVzIGR1cmluZyBm aXh0dXJlIGluc3RhbGxhdGlvbi4gVGhlIGV4cGVjdGF0aW9uIGlzIHRoYXQgd2l0aCBEQU5FIGFz IHRoZSBhdXRoZW50aWNhdGlvbiBwcm90b2NvbCwgdGhlDQogdmFyaWV0eSBvZiBzdXBwbGllcnMg cHJvZHVjaW5nIGRldmljZXMgZm9yIGEgZ2l2ZW4gYXBwbGljYXRpb24gbWlnaHQgYmUgYWJsZSB0 byBhZ3JlZSBvbiBhIGZvcm1hdCBmb3IgcmVwcmVzZW50aW5nIGNvbmZpZ3VyYXRpb24gaW5mb3Jt YXRpb24sIGFuZCBkZXZpY2VzIGNhbiBzZWN1cmVseSByZXRyaWV2ZSBpdCBmcm9tIHRoZSBzeXN0 ZW0gdGhhdCBtYW5hZ2VzJm5ic3A7dGhlIGFwcGxpY2F0aW9uJ3MgY29uZmlndXJhdGlvbi4gSSB0 aGluayB0aGF0IGl0DQogd291bGQgYmUgZXNwZWNpYWxseSB1c2VmdWwgdG8gc2hvdyBob3cgREFO RSB3b3JrcyB3aXRoIG90aGVyIGRpc2NvdmVyeSBwcm90b2NvbHMgKG1ETlMsIGZvciBpbnN0YW5j ZSkgaW4gdGhlIHByb2Nlc3Mgb2YgcmV0cmlldmluZyB0aGUgZGV2aWNlJ3MgY29uZmlndXJhdGlv bi4gV2hlcmUgZG8geW91IHRoaW5rIHRoaXMgZml0cyBiZXN0PyBJbiB0aGUgYXJjaGl0ZWN0dXJl IGRvY3VtZW50LCBvciB3b3VsZCBhbm90aGVyIGZvcm1hdCBiZSBhIGJldHRlcg0KIGZpdCBmb3Ig dGhpcz88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAw aW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6 MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5DaWFv PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkhhbm5lczxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXYg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5n OjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+RnJvbTo8L2I+ IEFzaCBXaWxzb24gJmx0OzxhIGhyZWY9Im1haWx0bzphc2gud2lsc29uQHZhbGltYWlsLmNvbSIg dGFyZ2V0PSJfYmxhbmsiPmFzaC53aWxzb25AdmFsaW1haWwuY29tPC9hPiZndDsNCjxicj4NCjxi PlNlbnQ6PC9iPiBXZWRuZXNkYXksIEp1bmUgMTYsIDIwMjEgMTE6MjggUE08YnI+DQo8Yj5Ubzo8 L2I+IEhhbm5lcyBUc2Nob2ZlbmlnICZsdDs8YSBocmVmPSJtYWlsdG86SGFubmVzLlRzY2hvZmVu aWdAYXJtLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPkhhbm5lcy5Uc2Nob2ZlbmlnQGFybS5jb208L2E+ Jmd0Ozxicj4NCjxiPkNjOjwvYj4gPGEgaHJlZj0ibWFpbHRvOmRhbmlzaEBpZXRmLm9yZyIgdGFy Z2V0PSJfYmxhbmsiPmRhbmlzaEBpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6 IFtEYW5pc2hdIENoYXJ0ZXIgVGV4dCBhbmQgdGhlIFByb2JsZW0gU3RhdGVtZW50PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SGkgSGFubmVzLDxvOnA+ PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VGhhbmtzIGZvciB0aGUg cXVlc3Rpb25zLCBhbmQgYXBvbG9naWVzIGZvciBrZWVwaW5nIHlvdSB3YWl0aW5nIG9uIGFuc3dl cnMvY2xhcmlmaWNhdGlvbi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPk9uIFdlZCwgSnVuIDE2LCAyMDIxIGF0IDQ6MTIgQU0gSGFubmVz IFRzY2hvZmVuaWcgJmx0OzxhIGhyZWY9Im1haWx0bzpIYW5uZXMuVHNjaG9mZW5pZ0Bhcm0uY29t IiB0YXJnZXQ9Il9ibGFuayI+SGFubmVzLlRzY2hvZmVuaWdAYXJtLmNvbTwvYT4mZ3Q7IHdyb3Rl OjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0 O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJn aW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90OyI+SGkgYWxsLA0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+SSBoYXZlIGJlZW4gcmVhZGluZyB0aHJvdWdoIHRoZSBj aGFydGVyIHRleHQgaW4gYW4gYXR0ZW1wdCB0byB1bmRlcnN0YW5kIHRoZSBwcm9ibGVtIHN0YXRl bWVudC4NCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDsiPlR3byBwcm9ibGVtcyBhcmUgbWVudGlvbmVkOjwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4xKTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjcuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+Jm5i c3A7DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDsiPkNoYWxsZW5nZXMgd2l0aCBuYW1pbmcgY29sbGlzaW9ucyBp biB0aGUgSW9UIHNwYWNlLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJz cDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Mik8L3NwYW4+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTo3LjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVv dDssc2VyaWYiPiZuYnNwOw0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5DcmVkZW50aWFsIGlzc3VhbmNlIGlz IHRpbWUgY29uc3VtaW5nLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwcmU+QWQgMTog UmVhZGluZyB0aHJvdWdoIHRoZSB0ZXh0IGl0IGZlZWxzIGxpa2UgbmFtaW5nIGNvbGxpc2lvbnMg YXJlIGEgYmlnIHRoaW5nIGluIElvVC4gSSBoYXZlIG5vdCBoZWFyZCBhYm91dCB0aG9zZSBwcm9i bGVtcy4gQ291bGQgeW91IGVsYWJvcmF0ZT8gPG86cD48L286cD48L3ByZT4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5DZXJ0YWlu bHkuIEknbGwgdXNlIGEgaG9zcGl0YWwgYXMgYW4gZXhhbXBsZSBlbnZpcm9ubWVudC48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPldpdGhp biBhIGhvc3BpdGFsLCBpdCBpcyBkZXNpcmFibGUgdG8gaW1wbGVtZW50IDgwMi4xeCBhdXRoZW50 aWNhdGlvbiB1c2luZyBFQVAtVExTIGZvciBhY2Nlc3MgdG8gcHJvdGVjdGVkIG5ldHdvcmtzLiBF QVAtVExTIGVuYWJsZXMgdGhlIHVzZSBvZiBQS0ktYmFzZWQgaWRlbnRpdHkgdG8mbmJzcDthdXRo ZW50aWNhdGUNCiBhbiBlbnRpdHkgZm9yIG5ldHdvcmsgYWNjZXNzLjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+V2hlbiBpbXBsZW1lbnRp bmcgRUFQLVRMUyBmb3IgbmV0d29yayBhY2Nlc3MsIFJBRElVUyBpcyBhIGNvbW1vbiBwcm90b2Nv bC9zZXJ2ZXIgdXNlZCBmb3IgYXV0aGVudGljYXRpb24gYmVoaW5kIHRoZSBzd2l0Y2ggb3Igd2ly ZWxlc3MgYWNjZXNzIHBvaW50LiBHdWlkYW5jZSBmb3IgY29uZmlndXJpbmcgUkFESVVTDQogcmVj b21tZW5kcyB0aGUgdXNlIG9mIG9ubHkgb25lIENBIGNlcnRpZmljYXRlIGZvciBhdXRoZW50aWNh dGluZyBzdXBwbGljYW50Jm5ic3A7Y2VydGlmaWNhdGVzLiBUaGlzIGd1aWRhbmNlIGNhbiBiZSBm b3VuZCBpbiB0aGUgd2lsZCBpbiBGcmVlcmFkaXVzIGNvbmZpZ3VyYXRpb24gZmlsZXMgZm9yIEVB UC1UTFMsIHJlbGF0ZWQgdG8gdGhlICdjYV9maWxlJyBjb25maWd1cmF0aW9uIGRpcmVjdGl2ZS4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPkNBcyBndWFyYW50ZWUgdGhlIHVuaXF1ZW5lc3Mgb2YgYW4gZW50aXR5J3MgbmFtZSB3 aXRoaW4gdGhlIHNjb3BlIG9mIHRoZSBDQSwgYnV0IGhhdmUgbm8gbWV0aG9kIGZvciBlbmZvcmNp bmcgbmFtZSB1bmlxdWVuZXNzIGFjcm9zcyBvdGhlciZuYnNwO0NBcy4gRm9yIGluc3RhbmNlLCBD QTEgYW5kIENBMiBtYXkgYm90aA0KIHNpZ24gY2VydGlmaWNhdGVzJm5ic3A7Zm9yIGVudGl0aWVz IHdpdGggdGhlIHNhbWUgbmFtZS4gSWYgQ0ExIGFuZCBDQTIgYXJlIGJvdGggdHJ1c3RlZCBieSB0 aGUgUkFESVVTIHNlcnZlciwgYW5kIHR3byBlbnRpdGllcyBuYW1lZCAmcXVvdDttZWRpY2FsZGV2 aWNlMTIzJnF1b3Q7IGV4aXN0LCBvbmUgcGVyIENBLCB0aGVuIHRoZSByZXN1bHRpbmcgYW1iaWd1 aXR5IG1ha2VzIGl0IGRpZmZpY3VsdCB0byBhcHByb3ByaWF0ZWx5IGFwcGx5IGFjY2VzcyBjb250 cm9scy4gVGhpcw0KIGFtYmlndWl0eSBpcyZuYnNwO21pdGlnYXRlZCBieSBvcGVyYXRpbmcgYSBz aW5nbGUgb3JnYW5pemF0aW9uYWwgUEtJLCBhbmQgcmVxdWlyaW5nIGlkZW50aXRpZXMgaXNzdWVk IGJ5IHRoYXQgc2luZ2xlIG9yZ2FuaXphdGlvbmFsIFBLSSBmb3IgRUFQLVRMUyBhdXRoZW50aWNh dGlvbi4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPk9uYm9hcmRpbmcgZGV2aWNlcyB0byBvcmdhbml6YXRpb25hbCBQS0kgcmVx dWlyZXMgdGltZSBhbmQgZWZmb3J0LiBPZnRlbnRpbWVzIHNvbWUgc29ydCBvZiBza2lsbGVkIGxh Ym9yIGFuZC9vciBkZWRpY2F0ZWQgaW5mcmFzdHJ1Y3R1cmUgZm9yIGF1dG9tYXRpbmcgdGhlIG9u Ym9hcmRpbmcgcHJvY2VzcyBpcw0KIGludm9sdmVkLiBEQU5FIGFsbG93cyB1cyB0byBiaW5kIGEg RE5TIG5hbWUgdG8gYSBwdWJsaWMga2V5LCBhbmQgbWl0aWdhdGVzIHRoZSBhbWJpZ3VpdGllcyBp bnRyb2R1Y2VkIGJ5IHRoZSB1c2Ugb2YgbXVsdGlwbGUgQ0FzLiBBbiBvcmdhbml6YXRpb24gY2Fu IG9ubHkgaXNzdWUgd29ya2luZyBpZGVudGl0aWVzIHdpdGhpbiBpdHMgb3duIG5hbWVzcGFjZSBp biBETlMuIFNpbmNlIG5hbWluZyBhbWJpZ3VpdHkgY2FuIGJlIG1pdGlnYXRlZCB1c2luZw0KIERB TkUsIHdlIG1heSBub3cgY2hvb3NlIHRvIHVzZSBtYW51ZmFjdHVyZXItaXNzdWVkIFBLSSwgcmVw cmVzZW50ZWQgaW4gRE5TLCBmb3IgYXV0aGVudGljYXRpbmcgZW50aXRpZXMuPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5Gcm9tIHRoZSBo b3NwaXRhbCdzIHN0YW5kcG9pbnQsIHRoZSBJVCBzdGFmZiBubyBsb25nZXIgbmVlZHMgdG8gbWFu YWdlIHRoZSBwcm9jZXNzIG9mIG9uYm9hcmRpbmcgZGV2aWNlcyB0byBvcmdhbml6YXRpb25hbCBQ S0kuIFRoZSBkZXZpY2UgYXJyaXZlcyBvbi1zaXRlIHdpdGggYW4gaWRlbnRpdHkgd2hpY2gNCiBj YW4gYmUgaW1tZWRpYXRlbHkgdXNlZCBmb3IgbmV0d29yayZuYnNwO2F1dGhlbnRpY2F0aW9uLjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21h cmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4t Ym90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHByZT5Zb3UgYWRkIHRoYXQg4oCcSW4gcmVz cG9uc2UgdG8gdGhlIGNoYWxsZW5nZXMgcmVsYXRlZCB0bzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl PmFtYmlndWl0eSBiZXR3ZWVuIGlkZW50aXRpZXMgaXNzdWVkIGJ5IGRpZmZlcmVudCBDQXMsIGFw cGxpY2F0aW9uIG93bmVyczxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPmZyZXF1ZW50bHkgY2hvb3Nl IHRvIG9uYm9hcmQgSW9UIGRldmljZXMgdG8gYSBzaW5nbGUgQ0Eu4oCdLiBJcyB0aGF0IGEgZ29v ZCBvciBhIGJhZCBkZXZlbG9wbWVudD8mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkl0IGlz IGEgZ29vZCBkZXZlbG9wbWVudCBpZiB0aGUgb3JnYW5pemF0aW9uIHJlYWxseSB3YW50cyB0byBk aXJlY3RseSBtYW5hZ2UgYWxsIG9mIHRoZSBjcmVkZW50aWFscyBmb3IgYWxsIG9mIHRoZSBhcHBs aWNhdGlvbiBwYXJ0aWNpcGFudHMuIFRoZSBlZmZvcnQgYW5kIHJhdGlvbmFsZSBiZWhpbmQgQlJT S0kNCiAoUkZDIDg5OTUpIHN1Z2dlc3RzIGEgZGVzaXJlIHRvIG1ha2Ugb25ib2FyZGluZyB0byBv cmdhbml6YXRpb25hbCBQS0kgZWFzaWVyIHRvIGF1dG9tYXRlLiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SWYgYSBzdXBwbGll ciBpc3N1ZXMgYSB0cnVzdHdvcnRoeSBpZGVudGl0eSBmb3IgYSBkZXZpY2UsIGFuZCBETlMgcHJl dmVudHMgYW5vdGhlciBQS0kgZnJvbSBpc3N1aW5nIHdvcmtpbmcgY3JlZGVudGlhbHMgdW5kZXIg dGhlIHNhbWUgbmFtZSwgdGhlbiBpc3N1aW5nIGFub3RoZXIgaWRlbnRpdHkgdmlhIG9yZ2FuaXph dGlvbmFsDQogUEtJIGJlY29tZXMgc3VwZXJmbHVvdXMuIFRoaXMgaXMgd2hlcmUgd2UgdGhpbmsg dGhhdCB0aW1lIGFuZCBlZmZvcnQgY2FuIGJlIHNhdmVkLCBiZWNhdXNlIHRoZSBza2lsbHMgcmVx dWlyZWQgZm9yIG9uYm9hcmRpbmcgZG8gbm90IG5lZWQgdG8gaW5jbHVkZSB0aGUgbWFuYWdlbWVu dCBhbmQgaXNzdWFuY2Ugb2YgaWRlbnRpdGllcyB1bmRlciBvcmdhbml6YXRpb25hbCBQS0kuPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFy Z2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1i b3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7Ij5BZCAyOiBJcyBpdCByZWFsbHkgdHJ1ZSB0aGF0IGNyZWRlbnRpYWwgaXNzdWFu Y2UgaXMgdGltZSBjb25zdW1pbmc/IFdoeSBpcyB0aGF0PyBGb3Igd2hvbSBpcyBpdCB0aW1lIGNv bnN1bWluZz88L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1 b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Q3JlZGVudGlhbCBpc3N1YW5jZSB2 ZXJ5IG9mdGVuIHJlcXVpcmVzIHRoZSBkZXZpY2UgYW5kIHRoZSBwZXJzb24gYm9vdHN0cmFwcGlu ZyB0aGUgaWRlbnRpdHkgdG8gYmUgaW4gdGhlIHNhbWUgcGxhY2UuIFNvbWUgcGxhdGZvcm1zIGFu ZCBwcm90b2NvbHMgZXhpc3QgdG8gbWFrZSB0aGF0IHByb2Nlc3MgZWFzaWVyDQogKGxpa2UgQlJT S0kpIG9yIGxlc3MgaHVtYW4taW52b2x2aW5nLiBUaGUgdGltZSBpbnZlc3RtZW50IHNlZW1zIHRv IGJlIG9uIHRoZSBwYXJ0IG9mIGJvdGggdGhlIG1hbnVmYWN0dXJlciAoaW4gaXNzdWluZyB0aGUg SURldklEKSBhcyB3ZWxsIGFzIHRoZSBvcmdhbml6YXRpb25hbCBJVCBzdGFmZiwgd2hvIG1hbmFn ZSB0aGUgb3JnYW5pemF0aW9uYWwgUEtJLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAx LjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10 b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Q2lhbzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPkhhbm5lczwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDsiPlBTOiBZb3UgdXNlIHRoZSB0ZXJtIOKAnENlcnRpZmljYXRlIEF1dGhvcml0eSAoQ0Ep4oCd LiBJdCBpcyBhY3R1YWxseSBjYWxsZWQg4oCcQ2VydGlmaWNhdGlvbiBBdXRob3JpdHnigJ0uPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5i c3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPklNUE9SVEFOVCBOT1RJQ0U6IFRoZSBjb250ZW50cyBvZiB0aGlzIGVtYWlsIGFuZCBh bnkgYXR0YWNobWVudHMgYXJlIGNvbmZpZGVudGlhbCBhbmQgbWF5IGFsc28gYmUgcHJpdmlsZWdl ZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIG5vdGlmeSB0 aGUgc2VuZGVyIGltbWVkaWF0ZWx5DQogYW5kIGRvIG5vdCBkaXNjbG9zZSB0aGUgY29udGVudHMg dG8gYW55IG90aGVyIHBlcnNvbiwgdXNlIGl0IGZvciBhbnkgcHVycG9zZSwgb3Igc3RvcmUgb3Ig Y29weSB0aGUgaW5mb3JtYXRpb24gaW4gYW55IG1lZGl1bS4gVGhhbmsgeW91Lg0KPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+LS0NCjxicj4NCkRhbmlzaCBt YWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86RGFuaXNoQGlldGYub3JnIiB0YXJnZXQ9 Il9ibGFuayI+RGFuaXNoQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vZGFuaXNoIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kYW5pc2g8L2E+PG86cD48L286cD48L3A+DQo8 L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGJyIGNsZWFyPSJh bGwiPg0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4tLQ0KPG86 cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNl cmlmIj5Bc2ggV2lsc29uPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtm b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj4gfCBUZWNobmljYWwgRGly ZWN0b3I8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7 LHNhbnMtc2VyaWYiPmU6PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtm b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj4NCjxhIGhyZWY9Im1haWx0 bzphc2gud2lsc29uQHZhbGltYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmFzaC53aWxzb25AdmFs aW1haWwuY29tPC9hPg0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OyxzYW5zLXNlcmlmIj48aW1nIGJvcmRlcj0iMCIgd2lkdGg9IjE3NSIgaGVpZ2h0PSI0 MyIgc3R5bGU9IndpZHRoOjEuODI1aW47aGVpZ2h0Oi40NWluIiBpZD0iX3gwMDAwX2kxMDI3IiBz cmM9Imh0dHBzOi8vaG9zdGVkLXBhY2thZ2VzLnMzLXVzLXdlc3QtMS5hbWF6b25hd3MuY29tL1Zh bGltYWlsK0xvZ28ucG5nIj48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2lu OjBpbjtiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzY2NjY2NiI+VGhpcyBl bWFpbCBhbmQgYWxsIGRhdGEgdHJhbnNtaXR0ZWQgd2l0aCBpdCBjb250YWlucyBjb25maWRlbnRp YWwgYW5kL29yIHByb3ByaWV0YXJ5IGluZm9ybWF0aW9uIGludGVuZGVkIHNvbGVseSBmb3IgdGhl IHVzZSBvZiBpbmRpdmlkdWFsKHMpIGF1dGhvcml6ZWQNCiB0byByZWNlaXZlIGl0LiBJZiB5b3Ug YXJlIG5vdCBhbiBpbnRlbmRlZCBhbmQgYXV0aG9yaXplZCByZWNpcGllbnQgeW91IGFyZSBoZXJl Ynkgbm90aWZpZWQgb2YgYW55IHVzZSwgZGlzY2xvc3VyZSwgY29weWluZyBvciBkaXN0cmlidXRp b24gb2YgdGhlIGluZm9ybWF0aW9uIGluY2x1ZGVkIGluIHRoaXMgdHJhbnNtaXNzaW9uIGlzIHBy b2hpYml0ZWQgYW5kIG1heSBiZSB1bmxhd2Z1bC4gUGxlYXNlIGltbWVkaWF0ZWx5IG5vdGlmeSB0 aGUgc2VuZGVyDQogYnkgcmVwbHlpbmcgdG8gdGhpcyBlbWFpbCBhbmQgdGhlbiBkZWxldGUgaXQg ZnJvbSB5b3VyIHN5c3RlbS48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPklNUE9SVEFOVCBOT1RJQ0U6IFRoZSBjb250 ZW50cyBvZiB0aGlzIGVtYWlsIGFuZCBhbnkgYXR0YWNobWVudHMgYXJlIGNvbmZpZGVudGlhbCBh bmQgbWF5IGFsc28gYmUgcHJpdmlsZWdlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJl Y2lwaWVudCwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5DQogYW5kIGRvIG5v dCBkaXNjbG9zZSB0aGUgY29udGVudHMgdG8gYW55IG90aGVyIHBlcnNvbiwgdXNlIGl0IGZvciBh bnkgcHVycG9zZSwgb3Igc3RvcmUgb3IgY29weSB0aGUgaW5mb3JtYXRpb24gaW4gYW55IG1lZGl1 bS4gVGhhbmsgeW91Lg0KPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48YnIgY2xlYXI9ImFsbCI+DQo8bzpwPjwvbzpw PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPi0tDQo8bzpwPjwvbzpwPjwvcD4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPkFzaCBXaWxzb248 L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPiB8IFRlY2huaWNhbCBEaXJlY3Rvcjwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+ZTo8 L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPg0KPGEgaHJlZj0ibWFpbHRvOmFzaC53aWxzb25AdmFs aW1haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+YXNoLndpbHNvbkB2YWxpbWFpbC5jb208L2E+DQo8 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2Vy aWYiPjxpbWcgYm9yZGVyPSIwIiB3aWR0aD0iMTc1IiBoZWlnaHQ9IjQzIiBzdHlsZT0id2lkdGg6 MS44MjVpbjtoZWlnaHQ6LjQ1aW4iIGlkPSJfeDAwMDBfaTEwMjYiIHNyYz0iaHR0cHM6Ly9ob3N0 ZWQtcGFja2FnZXMuczMtdXMtd2VzdC0xLmFtYXpvbmF3cy5jb20vVmFsaW1haWwrTG9nby5wbmci Pjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGluO2JhY2tncm91bmQ6 d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJp YWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNjY2NjY2Ij5UaGlzIGVtYWlsIGFuZCBhbGwgZGF0 YSB0cmFuc21pdHRlZCB3aXRoIGl0IGNvbnRhaW5zIGNvbmZpZGVudGlhbCBhbmQvb3IgcHJvcHJp ZXRhcnkgaW5mb3JtYXRpb24gaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgdXNlIG9mIGluZGl2aWR1 YWwocykgYXV0aG9yaXplZA0KIHRvIHJlY2VpdmUgaXQuIElmIHlvdSBhcmUgbm90IGFuIGludGVu ZGVkIGFuZCBhdXRob3JpemVkIHJlY2lwaWVudCB5b3UgYXJlIGhlcmVieSBub3RpZmllZCBvZiBh bnkgdXNlLCBkaXNjbG9zdXJlLCBjb3B5aW5nIG9yIGRpc3RyaWJ1dGlvbiBvZiB0aGUgaW5mb3Jt YXRpb24gaW5jbHVkZWQgaW4gdGhpcyB0cmFuc21pc3Npb24gaXMgcHJvaGliaXRlZCBhbmQgbWF5 IGJlIHVubGF3ZnVsLiBQbGVhc2UgaW1tZWRpYXRlbHkgbm90aWZ5IHRoZSBzZW5kZXINCiBieSBy ZXBseWluZyB0byB0aGlzIGVtYWlsIGFuZCB0aGVuIGRlbGV0ZSBpdCBmcm9tIHlvdXIgc3lzdGVt Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPklNUE9SVEFOVCBOT1RJQ0U6IFRoZSBjb250ZW50cyBvZiB0aGlzIGVtYWls IGFuZCBhbnkgYXR0YWNobWVudHMgYXJlIGNvbmZpZGVudGlhbCBhbmQgbWF5IGFsc28gYmUgcHJp dmlsZWdlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIG5v dGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGFuZCBkbyBub3QgZGlzY2xvc2UgdGhlIGNvbnRl bnRzIHRvIGFueSBvdGhlciBwZXJzb24sDQogdXNlIGl0IGZvciBhbnkgcHVycG9zZSwgb3Igc3Rv cmUgb3IgY29weSB0aGUgaW5mb3JtYXRpb24gaW4gYW55IG1lZGl1bS4gVGhhbmsgeW91Lg0KPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGJyIGNsZWFyPSJhbGwiPg0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPi0tIDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LHNhbnMtc2VyaWYiPkFzaCBXaWxzb248L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPiB8 IFRlY2huaWNhbCBEaXJlY3Rvcjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPmU6PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj4NCjxh IGhyZWY9Im1haWx0bzphc2gud2lsc29uQHZhbGltYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmFz aC53aWxzb25AdmFsaW1haWwuY29tPC9hPg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+PGltZyBib3JkZXI9IjAiIHdpZHRoPSIxNzUi IGhlaWdodD0iNDMiIHN0eWxlPSJ3aWR0aDoxLjgyNWluO2hlaWdodDouNDVpbiIgaWQ9Il94MDAw MF9pMTAyNSIgc3JjPSJodHRwczovL2hvc3RlZC1wYWNrYWdlcy5zMy11cy13ZXN0LTEuYW1hem9u YXdzLmNvbS9WYWxpbWFpbCtMb2dvLnBuZyI+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGluO2JhY2tncm91bmQ6d2hpdGUiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojNjY2NjY2Ij5UaGlzIGVtYWlsIGFuZCBhbGwgZGF0YSB0cmFuc21p dHRlZCB3aXRoIGl0IGNvbnRhaW5zIGNvbmZpZGVudGlhbCBhbmQvb3IgcHJvcHJpZXRhcnkgaW5m b3JtYXRpb24gaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgdXNlIG9mIGluZGl2aWR1YWwocykgYXV0 aG9yaXplZA0KIHRvIHJlY2VpdmUgaXQuIElmIHlvdSBhcmUgbm90IGFuIGludGVuZGVkIGFuZCBh dXRob3JpemVkIHJlY2lwaWVudCB5b3UgYXJlIGhlcmVieSBub3RpZmllZCBvZiBhbnkgdXNlLCBk aXNjbG9zdXJlLCBjb3B5aW5nIG9yIGRpc3RyaWJ1dGlvbiBvZiB0aGUgaW5mb3JtYXRpb24gaW5j bHVkZWQgaW4gdGhpcyB0cmFuc21pc3Npb24gaXMgcHJvaGliaXRlZCBhbmQgbWF5IGJlIHVubGF3 ZnVsLiBQbGVhc2UgaW1tZWRpYXRlbHkgbm90aWZ5IHRoZSBzZW5kZXINCiBieSByZXBseWluZyB0 byB0aGlzIGVtYWlsIGFuZCB0aGVuIGRlbGV0ZSBpdCBmcm9tIHlvdXIgc3lzdGVtLjwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCklNUE9SVEFOVCBOT1RJQ0U6 IFRoZSBjb250ZW50cyBvZiB0aGlzIGVtYWlsIGFuZCBhbnkgYXR0YWNobWVudHMgYXJlIGNvbmZp ZGVudGlhbCBhbmQgbWF5IGFsc28gYmUgcHJpdmlsZWdlZC4gSWYgeW91IGFyZSBub3QgdGhlIGlu dGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGFu ZCBkbyBub3QgZGlzY2xvc2UgdGhlIGNvbnRlbnRzIHRvIGFueSBvdGhlciBwZXJzb24sIHVzZSBp dCBmb3IgYW55IHB1cnBvc2UsDQogb3Igc3RvcmUgb3IgY29weSB0aGUgaW5mb3JtYXRpb24gaW4g YW55IG1lZGl1bS4gVGhhbmsgeW91Lg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_DBBPR08MB59153F3F972DBB5EE70D5234FA0B9DBBPR08MB5915eurp_-- From nobody Sun Jun 20 07:48:33 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 B3B123A18E2 for ; Sun, 20 Jun 2021 07:48:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[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 dORVH4SJXg0c for ; Sun, 20 Jun 2021 07:48:27 -0700 (PDT) Received: from mail.hardakers.net (mail.hardakers.net [168.150.192.181]) (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 525C93A18E0 for ; Sun, 20 Jun 2021 07:48:27 -0700 (PDT) Received: from localhost (unknown [10.0.0.3]) by mail.hardakers.net (Postfix) with ESMTPA id 4D191275DC; Sun, 20 Jun 2021 07:48:24 -0700 (PDT) From: Wes Hardaker To: Ash Wilson Cc: Hannes Tschofenig , "danish@ietf.org" References: Date: Sun, 20 Jun 2021 07:48:24 -0700 In-Reply-To: (Ash Wilson's message of "Sat, 19 Jun 2021 21:47:12 -0700") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Danish] Charter Text and the Problem Statement X-BeenThere: danish@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DANE AutheNtication for Iot Service Hardening List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jun 2021 14:48:32 -0000 Ash Wilson writes: > I'm very happy to hear that you're interested in how EAP-TLS will=C2=A0fit > with this effort and I have no objection to including this in the > charter, as long as the chairs are OK with it. It does seem to me that EAP-TLS should be considered after the other parts of the problem space have a good start, unless that someone has a good case for why they have to be simultaneously worked on. And there is nothing wrong with making charter items that outline a series of things to do. I'd suggest that based on discussions to date, it sounds like there are now three major sections, none of which are huge, to work on: 1. An architecture document 2. Base protocol documents 3. EAP-TLS and other immediate follow on items, if there are agreements now this this really should be the next step (otherwise rechartering when 1 and 2 are done and decide on priorities then) --=20 Wes Hardaker USC/ISI From nobody Sun Jun 20 07:51:28 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 1E58D3A18F6 for ; Sun, 20 Jun 2021 07:51:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[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 y84m1JY_oVKJ for ; Sun, 20 Jun 2021 07:51:23 -0700 (PDT) Received: from mail.hardakers.net (mail.hardakers.net [168.150.192.181]) (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 9F2933A18F4 for ; Sun, 20 Jun 2021 07:51:23 -0700 (PDT) Received: from localhost (unknown [10.0.0.3]) by mail.hardakers.net (Postfix) with ESMTPA id 25061275DC; Sun, 20 Jun 2021 07:51:23 -0700 (PDT) From: Wes Hardaker To: Hannes Tschofenig Cc: Michael Richardson , "danish@ietf.org" References: <23295.1624134481@localhost> Date: Sun, 20 Jun 2021 07:51:23 -0700 In-Reply-To: (Hannes Tschofenig's message of "Sun, 20 Jun 2021 08:12:37 +0000") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [Danish] Charter Text and the Problem Statement X-BeenThere: danish@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DANE AutheNtication for Iot Service Hardening List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jun 2021 14:51:28 -0000 Hannes Tschofenig writes: > If the problem cannot be described properly then there will be a lot > of problems later in this group. I think starting with a problem statement and architecture document makes a lot of sense to me. In particular, during the last BOF there was an overview example that included a car driving into a home that reasonably explained the space. And recently on the list there was a description of onboarding a device in a hospital, that also sounded like a reasonable place to start. IMHO, it would be really nice to get these two, and possible other examples, fully flushed out with example DNS queries and documented some place that we could refer to them. But... the charter also needs a suitable shortened problem description, and that might be trickier since it seems like a longer description is almost necessary for most people to grasp the space. -- Wes Hardaker USC/ISI From nobody Sun Jun 20 09:14:07 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 10F0C3A1BA1 for ; Sun, 20 Jun 2021 09:14:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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=armh.onmicrosoft.com header.b=5hDyn6K4; dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=5hDyn6K4 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 aTqZhlX0F75i for ; Sun, 20 Jun 2021 09:14:01 -0700 (PDT) Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-eopbgr00053.outbound.protection.outlook.com [40.107.0.53]) (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 0572E3A1BA0 for ; Sun, 20 Jun 2021 09:14:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=zjXlfqVp2o9hbVKzTtNakKeUIhAt8/Z0pDKtAmDwdPw=; b=5hDyn6K4WFI+SSfxo82OcSlFVCXYN12lC1d8SaNAvjDwesPsmGoYIp8o0t7vCAoeDf2IqK9usLCdZPZ3JCtRqgwwV2lPOaqOxrL9IHDSxtT37iXvMVdFqxkRpJoGmi0tRDv7A9qyJ1U5kgmA8TWsFFMlBuJyz6k1lMPn8FQs+QU= Received: from AM6PR0502CA0061.eurprd05.prod.outlook.com (2603:10a6:20b:56::38) by AM6PR08MB4390.eurprd08.prod.outlook.com (2603:10a6:20b:be::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4242.18; Sun, 20 Jun 2021 16:13:57 +0000 Received: from AM5EUR03FT016.eop-EUR03.prod.protection.outlook.com (2603:10a6:20b:56:cafe::50) by AM6PR0502CA0061.outlook.office365.com (2603:10a6:20b:56::38) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4242.18 via Frontend Transport; Sun, 20 Jun 2021 16:13:57 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; ietf.org; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com;ietf.org; dmarc=pass action=none header.from=arm.com; Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 63.35.35.123 as permitted sender) receiver=protection.outlook.com; client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com; Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by AM5EUR03FT016.mail.protection.outlook.com (10.152.16.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4242.16 via Frontend Transport; Sun, 20 Jun 2021 16:13:57 +0000 Received: ("Tessian outbound f945d55369ce:v96"); Sun, 20 Jun 2021 16:13:56 +0000 X-CR-MTA-TID: 64aa7808 Received: from f8c2748e7ab1.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id E25676D7-23A3-4904-80F4-0912E7C3009B.1; Sun, 20 Jun 2021 16:13:51 +0000 Received: from EUR04-HE1-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id f8c2748e7ab1.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Sun, 20 Jun 2021 16:13:51 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=RkTKCEqiJM7c6J74xRj/PwLJUGei1xAhLPVr+25ulddK2mH9l+tQslmMd7njOGNcKnadgqUKKesh1NOfbmiCfWWwobK4FaIaJrxQqx67J7yS2RRGa+hDryERisjUzq/QYPC6a2WV7q63YRWuqJOgHG9Sf9uNbElg62QHy47lHty6NJVTXwA0Agbr8ne65SiMKoLHS4RZ+ApjvklKV5oM/coX1OlwPRX7vKf4H72AfobFjRe3tontt+SvSQRlNZo86FpQ8zWvnMvqVADxpMD1JgU+Y5fgTZzU05YXQuw0N3lo3O8Q76k2gXETeyeeNSxo3Fj6km9c2H8oJxCj1bAWaA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=zjXlfqVp2o9hbVKzTtNakKeUIhAt8/Z0pDKtAmDwdPw=; b=Dx1x50CkeU5aPBEmpjq7oIFTK9hYfBqnMRA0AYNp2VN5zoQX9xPKFldsa/YwxscfP5lQoEI66o3fJ0QL24jYBByU35cl60j28ArPKenv+g5jEhPeljYAObKvFK/w5VLZKSa0hMBNBqKgVw2IwLOpv1BQ7cNeO3CNQgjUPia2YTgfB/TNuF1gvdY6F5OMjTLW7EWOuC5v596Q3IjQwbFrhSkfwSggrEybURqbBPiqyxIcdhV0YNJ1LVS2vAzh/mdW++pyX7bbwpOV+LkoCkM2fZN3MCc40m9LLYi3rFYPr5dKZqXEDMMznZBeEZ6kpDsh5aLO84pH17JpVf2fwAYVGw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=zjXlfqVp2o9hbVKzTtNakKeUIhAt8/Z0pDKtAmDwdPw=; b=5hDyn6K4WFI+SSfxo82OcSlFVCXYN12lC1d8SaNAvjDwesPsmGoYIp8o0t7vCAoeDf2IqK9usLCdZPZ3JCtRqgwwV2lPOaqOxrL9IHDSxtT37iXvMVdFqxkRpJoGmi0tRDv7A9qyJ1U5kgmA8TWsFFMlBuJyz6k1lMPn8FQs+QU= Received: from DBBPR08MB5915.eurprd08.prod.outlook.com (2603:10a6:10:20d::17) by DB6PR0801MB1735.eurprd08.prod.outlook.com (2603:10a6:4:3a::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4242.21; Sun, 20 Jun 2021 16:13:49 +0000 Received: from DBBPR08MB5915.eurprd08.prod.outlook.com ([fe80::69cf:4429:a804:7f41]) by DBBPR08MB5915.eurprd08.prod.outlook.com ([fe80::69cf:4429:a804:7f41%3]) with mapi id 15.20.4242.023; Sun, 20 Jun 2021 16:13:47 +0000 From: Hannes Tschofenig To: Wes Hardaker CC: Michael Richardson , "danish@ietf.org" Thread-Topic: [Danish] Charter Text and the Problem Statement Thread-Index: Addin8Z32g6ibl9RQiW6iIvXVU0WhwAVq2gAABL3x4AAGNNDAAAroAeQAD1ePYAAGAHboAAOiVllAAKHOrA= Date: Sun, 20 Jun 2021 16:13:47 +0000 Message-ID: References: <23295.1624134481@localhost> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ts-tracking-id: 05284F94D6AAD043A1D6796BBC18A769.0 x-checkrecipientchecked: true Authentication-Results-Original: hardakers.net; dkim=none (message not signed) header.d=none; hardakers.net; dmarc=none action=none header.from=arm.com; x-originating-ip: [80.92.123.248] x-ms-publictraffictype: Email X-MS-Office365-Filtering-Correlation-Id: 40f070f8-c2aa-4f04-3eae-08d93406684d x-ms-traffictypediagnostic: DB6PR0801MB1735:|AM6PR08MB4390: X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true nodisclaimer: true x-ms-oob-tlc-oobclassifiers: OLM:10000;OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: hzlVOQy9EPRh0LPzU2acugs05zP243fzz+wifLO29UXnzusyrUYnrq7WW9Zl1sg2erWsiS0VawqYb2EE+crymlg2cY0s92KBAJO/H6iYxAGkkHL8xnAMYDbk+0Lo+mLw5yYGb1XNaMS5xNS9dJ/frZ/o2bDcU6ZZ420awQlqABpiOvlx16tTwRGkMcWK/rjTU7487ieagw/qhGjZKnIJK7mWgB53WUOvcPS/yUbO+OG8ot3zqK1TftBceP1x7llO8NRo74/0R6heHU3cJ9ay1XBgTm4OcmMpIs+YXLqSr2NelvST8ZYcINUo80bBiWLINbm277HXXrCy5hA3XFEFH2ZvR72rs9RGYtx+CEQl3m1YPN2G0Q8YtiQ4YhzQLSz+8OS39oclhZw4OMOpzwqLQRNzHQtUv628ujKxfFeHOY3dJZV+0qjAo1SCfjKJOG6QllRNZ/gIMDNEJ6gOWHpRcKLH821TzvDc/1zgxEkh4lGvQf6OLm25BDCvfK5br3aJY01x5UuuJcljpXjtmXi+APTMhf5oa2rsawY8mFUWNlw25+uPzwy3KKhGvKtr9cq7ALet5IPfoCkah1lS7zDDJK0njERCeSy9hbFXXJy3V8LXu33flRSUBCzpg9Y1CZpHb8pYQ5dZn9yclW6xASqAkmKfWEqoln729R5eB1+2dqevSpG8fnWEcp0NyvtYQqQYw2qzEC6gbsV2w9l4q2HpQ3+nYWfz+x9S17PqQca2jx/MZSGqhIIEspCEIfKpQqyV X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DBBPR08MB5915.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(39850400004)(346002)(396003)(376002)(136003)(366004)(966005)(53546011)(478600001)(6506007)(2906002)(186003)(86362001)(8936002)(26005)(83380400001)(9686003)(6916009)(33656002)(55016002)(8676002)(5660300002)(66476007)(71200400001)(66446008)(66556008)(316002)(64756008)(122000001)(38100700002)(76116006)(66946007)(4326008)(54906003)(52536014)(7696005); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?GwSPGGN3riN4/CmRlPCyORT7LyHQ/RuW2DzHQIB9BkEsObxkAQsVSX7BM41F?= =?us-ascii?Q?7SYG4bVIW0OBWzYZtTmt5hM7hF/SHa1yDLNAfRNTY1s2JK/Xd1zeI38nIT/u?= =?us-ascii?Q?4z5ue9YReafqeVdyMYQiH0EOr7Cm2oXYNKywGz88DA9S/mATXwq/6mREpth+?= =?us-ascii?Q?OgDtqSYQ+d4ZN72GZQ8sWdmeQwTDtzo1piwBf6PsSJRJaIPodVvE8G6bN5HN?= =?us-ascii?Q?lTIh0Gs/xj4dkoW+nhULLEtzfRLseR04bqSTwys7mJAKsodVE0cGeLUy8www?= =?us-ascii?Q?9rifbChnI/oWv8yM8d+QkzP/BK0DG/PCNlm9+Q1Zs9zbfW7T3JELyY8c79xO?= =?us-ascii?Q?LOeJlStUfRlrPPMx1G6qTXOI9X/yuJI/zEAfMpP0uF5BxpFx68D4DkJ1RLyl?= =?us-ascii?Q?RmB10AH0oXPl/w4ppBr2nNc2hJfuOVsPLMafZW3OzcINeaDXuudj05Lfq1cv?= =?us-ascii?Q?+qGvNUXAtlCK3WEZCInkGOia8SFCUOWv8nubdkgsM44uDqQrwaYlSbzaCjpS?= =?us-ascii?Q?oidBWUrELkNbECZRwxebxKVkrCjc6iDnO8R0ksjlQR1kfkwbJyuueA/gDo5B?= =?us-ascii?Q?BzjAzL/LC6XOI/OB5RIGMInSwOxLXAVpZB1Dpi0lsQkd4pshqQdCOTWTtddO?= =?us-ascii?Q?f+0JhfUvI1JpfcJ5gjatV91E7QUk7DCwtHAzh/lpS5tD86iCxZXN2ZccXV3o?= =?us-ascii?Q?xMNnNBo9dh25Mf48Y7+7pueaW+bhpWw5Hh3FoQmVIh9CYIgfX2CpzTQsgATU?= =?us-ascii?Q?yEktKR1ZaKvvoyPCRoQHxiCYZr0wL66eFPxKEP0O30ptw9ukQGnZQrnBjkRY?= =?us-ascii?Q?2wmCRNRrz1ERRxMyc+HFE96qdmvMu1hprUA3Rh7RY/+atW89rqLy/y+WCU+v?= =?us-ascii?Q?gYcFcRrR4/gPkyao1D9XwhlQMwXWNS7/qJghZHIk6i/QY6B1WVduRPRlY3e4?= =?us-ascii?Q?SU8pDR69iwd0EuYAIz4QLlstN4hKWij+OHqd6gGWgwEK6PTLhDOo1uWFBkjo?= =?us-ascii?Q?R35PXiUtq82nlDqDdP/RrUBzhsVdzPmFADg/i60NsZjucWp2jvUeK+faj8aC?= =?us-ascii?Q?mD/+XUl7g7STPCSdGRW7VXJYaqY3G3F8kOtB/zk8/hKpTr9Nf2m5MNGXuYA+?= =?us-ascii?Q?G/kyKaZbkxNbFEcSY7vXjoZslSwa5mb1kO2E0JvubP90nhx3dkOxFrIz3vhK?= =?us-ascii?Q?nRd2P1l1ZRQWy5vjFHsE1SJ0n/xT0EqTYkxUzT/PiqwerTa23JwebiUkVftF?= =?us-ascii?Q?iY7muMrfXvInNSVxJMi29OVGeb0KkJt1nuIx6T7wKqyWJimrSN1UAw3bhMrl?= =?us-ascii?Q?LVIXx9KTelkM59jAR7cntGZD?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR0801MB1735 Original-Authentication-Results: hardakers.net; dkim=none (message not signed) header.d=none; hardakers.net; dmarc=none action=none header.from=arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: AM5EUR03FT016.eop-EUR03.prod.protection.outlook.com X-MS-Office365-Filtering-Correlation-Id-Prvs: b94dd783-e44c-4bcb-4afe-08d934066254 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: hRjz5k9xX5WbnZqdZYKua8sijYhUcSekeEQAmUHHuk+5YqAe4D4YQY7qr7WRhkVQZNC6rZ8KYkjhE3uQMRnAFW+5n4kBM4Lw05JftbWOVEwn0gA4JZcv/ZrOfHjpiZOIz1/TMBJ6OyYeJ9nQIxpUYUvSuou4eFvVMyFKz6UZ/p0m6cm+8xBg1KFWjhd0AXG5iK58k0J+QLNB7tKmzsj+3QcgWre5N9k42G5WUl8DcyxhLMCyvgBRnabuaPFtTb1bMb5nlm9HtsLNUjTaIKuPv9LfTkHKYf4ekuMfV4Tyw3VuI1ZF3Gj31TmEBKEqFTJNYobkVh/mPI50vXsa2CePQrdY0lO+aFINS8Niw32kPYONljyEqq+BSCImk697HSU5/QO0H4j2fd807IQ/wLuJ4gAHXLQLDcCoaTwXvIIdvhOXcY1xJwxZnGwyT5VtzCMXtGkEaq7aUet+8HOk3L5Zm/VxDlUhR6cWLkQlvr6JPGqxEjcvQ4s3Ww6QsbDC9jUEiK1CELupHrqMWP/+QCOJ+SIxxvHxjMzS1zS10zSseTQ5A2x16Y5r0Jo9Ug9M/1IibiPRfunX92G31QE3CfzDk1jZtsQpOniRZwl/ew48tDPCibOj/63ydYZ4M5iAoWnDdDI76Y12RNyxGe1Hsp0TnWBTKXCmdv04rx3od5Wwu6xgI8UB99Zd1Jnxp6CW02KGiSY/LBXynqrqMtFJ3j7pGFdZF237FbwnqGfi268C+HEwqYNuOPM1t5XraamDm0myM98zHeq1KIUFxSjFTUvuIWQqsPTYguQpgXna01MEjRZRDfzL1lchYTN5W4PUaOMm X-Forefront-Antispam-Report: CIP:63.35.35.123; CTRY:IE; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:64aa7808-outbound-1.mta.getcheckrecipient.com; PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; CAT:NONE; SFS:(4636009)(376002)(39850400004)(346002)(136003)(396003)(46966006)(36840700001)(9686003)(55016002)(478600001)(33656002)(81166007)(70206006)(82310400003)(356005)(5660300002)(70586007)(83380400001)(52536014)(8676002)(8936002)(54906003)(2906002)(82740400003)(36860700001)(86362001)(6862004)(336012)(316002)(7696005)(6506007)(186003)(4326008)(53546011)(26005)(966005)(47076005); DIR:OUT; SFP:1101; X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Jun 2021 16:13:57.3357 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 40f070f8-c2aa-4f04-3eae-08d93406684d X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d; Ip=[63.35.35.123]; Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com] X-MS-Exchange-CrossTenant-AuthSource: AM5EUR03FT016.eop-EUR03.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR08MB4390 Archived-At: Subject: Re: [Danish] Charter Text and the Problem Statement X-BeenThere: danish@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DANE AutheNtication for Iot Service Hardening List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jun 2021 16:14:06 -0000 Hi Wes Talking about a specific use case makes a lot of sense. I guess you are referring to the taxi dash cam retention scenario from http= s://datatracker.ietf.org/meeting/110/materials/slides-110-danish-danish-bof= -slides-02 The example raises a few questions: * how does the network access authentication and authorization work? This i= s key because it secures the subsequent mDNS exchange as well. * how does the taxi car know that it has to talk to recorder56 in that gara= ge? * how does the recorder recognize that car54 is allowed to upload video dat= a (and to potentially access data)? I can easily see concerns about listing IoT devices in the DNS (publically = visible). How the device would obtain operational credentials since you rarely use th= e same (manufacturer-provisioned) key for all services? Ciao Hannes PS: I missed the example of onboarding a device in a hospital. -----Original Message----- From: Danish On Behalf Of Wes Hardaker Sent: Sunday, June 20, 2021 4:51 PM To: Hannes Tschofenig Cc: Michael Richardson ; danish@ietf.org Subject: Re: [Danish] Charter Text and the Problem Statement Hannes Tschofenig writes: > If the problem cannot be described properly then there will be a lot > of problems later in this group. I think starting with a problem statement and architecture document makes a= lot of sense to me. In particular, during the last BOF there was an overview example that inclu= ded a car driving into a home that reasonably explained the space. And recently on the list there was a description of onboarding a device in = a hospital, that also sounded like a reasonable place to start. IMHO, it would be really nice to get these two, and possible other examples= , fully flushed out with example DNS queries and documented some place that= we could refer to them. But... the charter also needs a suitable shortened problem description, an= d that might be trickier since it seems like a longer description is almost= necessary for most people to grasp the space. -- Wes Hardaker USC/ISI -- Danish mailing list Danish@ietf.org https://www.ietf.org/mailman/listinfo/danish IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you. From nobody Sun Jun 20 14:39:56 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 E25563A12C3 for ; Sun, 20 Jun 2021 14:39:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[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 y1jZd0XBEu_t for ; Sun, 20 Jun 2021 14:39:50 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08C353A12C1 for ; Sun, 20 Jun 2021 14:39:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 6F41638AE6; Sun, 20 Jun 2021 17:41:17 -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 Qg87pgV4f5iO; Sun, 20 Jun 2021 17:41:15 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 6294E38AA7; Sun, 20 Jun 2021 17:41:15 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 62EA518B; Sun, 20 Jun 2021 17:39:45 -0400 (EDT) From: Michael Richardson To: Wes Hardaker cc: Ash Wilson , "danish\@ietf.org" , Hannes Tschofenig In-Reply-To: References: 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: Re: [Danish] Charter Text and the Problem Statement X-BeenThere: danish@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DANE AutheNtication for Iot Service Hardening List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jun 2021 21:39:55 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Wes Hardaker wrote: >> I'm very happy to hear that you're interested in how EAP-TLS will=C2= =A0fit >> with this effort and I have no objection to including this in the >> charter, as long as the chairs are OK with it. > It does seem to me that EAP-TLS should be considered after the other > parts of the problem space have a good start, unless that someone has= a > good case for why they have to be simultaneously worked on. And there > is nothing wrong with making charter items that outline a series of > things to do. I'd suggest that based on discussions to date, it soun= ds > like there are now three major sections, none of which are huge, to w= ork > on: > 1. An architecture document > 2. Base protocol documents > 3. EAP-TLS and other immediate follow on items, if there are agreemen= ts > now this this really should be the next step (otherwise rechartering > when 1 and 2 are done and decide on priorities then) I agree 100% with this approach. I think that using EAP-TLS with client side certificates for network access could be a really useful thing. But, that it should come afterward as a milestone. =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+93Q3WUFAmDPtaEACgkQgItw+93Q 3WXsXgf/Z5m2TrWUCFuF+aEDGCvnF913rLX231FGtn1KYHOz3w71LH/u+ZMZ7v67 +vzTChaNFuNY1f0FMK1UDQZv1IYqRW/d/AcLFb8VOjOSELiA5s9kEIyWVdyLeLnk 26oxRNIeEy/wOHvWvkFWOPKGrCp89NvwBjPp8sxlVBS4iTATi/GEo0OhtzOwK8ZH l5/7K+y9FfxQbnLFU20yjQvrEtx4+V6bWiLG4lQpAdkIFOGeAB+6dmtuxYFqrPSU YHmhP91BHwfr3fxeQ0ngMvaFAKnrndaccZMMnnAXMg3vsHz+ivE2uARwlYGuKuIh GFEwY4jXN2f3s7/j/5k1eYc7BFMMJA== =6ljb -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun Jun 20 14:41:44 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 257813A12CD for ; Sun, 20 Jun 2021 14:41:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[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 zySJ6xosvFEN for ; Sun, 20 Jun 2021 14:41:37 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C9833A12CA for ; Sun, 20 Jun 2021 14:41:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 13B5B38AE6; Sun, 20 Jun 2021 17:43:06 -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 eEae3VWkWxlo; Sun, 20 Jun 2021 17:43:02 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 50B3F38AE3; Sun, 20 Jun 2021 17:43:02 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id D244418B; Sun, 20 Jun 2021 17:41:31 -0400 (EDT) From: Michael Richardson To: Hannes Tschofenig cc: "danish\@ietf.org" In-Reply-To: References: <23295.1624134481@localhost> 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: Re: [Danish] Charter Text and the Problem Statement X-BeenThere: danish@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DANE AutheNtication for Iot Service Hardening List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jun 2021 21:41:42 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hannes Tschofenig wrote: > You mention "EAP-TEAP-BRSKI", another technology where I do not > precisely know how it is supposed to fit into the DANISH work (if at > all). It isn't. The point is that there is work in EAP to do onboarding. If you use DANISH, then you don't need to onboard the device (i.e. enroll it with a new certificate), because you already have secure access to the correct certificate via DNS(SEC). > I started with a simple task: I read through the charter text. I didn= 't > understood the problem statement. Then, I looked through the mailing > list and at the slides presented at the last meeting. I can find a lot > of solution discussions but little discussion about the problem. Fair enough. I agree that we need improvements in the charter text, and I appreciate your comments. =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+93Q3WUFAmDPtgsACgkQgItw+93Q 3WW50AgAh2Q/q52bbH+ouXIQMOe2mivaWMv9FJXn/0Jlr65a6xMOkPvTpdBw0bTL 00nhSOKlcppqA5/Z80xGFz3ty9MaVzpiwjMx1Xt39gsTpGLYml+Y7X64d4iFpe5D RAqWFnQA2FXuK2fbHgSCp0jjHy6dIdQI/QC+k38OHzG1C0xXk6Uh/fO3FJY04WyN C9JYreeioGwIYdVh9Re/+Uni+qt+n9+crs50j2zKnwE7lfdICmTcq30UFVULHRFz 4T96LTkzx9RGsgGu76Q90I5UfL6lNWrW6k+mYE5/Z6pH6vAllYTuLMMSSScmQ4/P aKZNjd49euwaH1Oq1UDptLRE/jkJUw== =UMpJ -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun Jun 20 17:00:12 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 5998C3A18C8 for ; Sun, 20 Jun 2021 17:00:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[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 FLy5ydYq55Ur for ; Sun, 20 Jun 2021 17:00:06 -0700 (PDT) Received: from mail.hardakers.net (mail.hardakers.net [168.150.192.181]) (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 1F0903A18C6 for ; Sun, 20 Jun 2021 17:00:05 -0700 (PDT) Received: from localhost (unknown [10.0.0.3]) by mail.hardakers.net (Postfix) with ESMTPA id AB4E8276AA; Sun, 20 Jun 2021 17:00:03 -0700 (PDT) From: Wes Hardaker To: Hannes Tschofenig Cc: Wes Hardaker , Michael Richardson , "danish@ietf.org" References: <23295.1624134481@localhost> Date: Sun, 20 Jun 2021 17:00:03 -0700 In-Reply-To: (Hannes Tschofenig's message of "Sun, 20 Jun 2021 16:13:47 +0000") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [Danish] Charter Text and the Problem Statement X-BeenThere: danish@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DANE AutheNtication for Iot Service Hardening List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jun 2021 00:00:10 -0000 Hannes Tschofenig writes: > Hi Wes > > Talking about a specific use case makes a lot of sense. > I guess you are referring to the taxi dash cam retention scenario from > https://datatracker.ietf.org/meeting/110/materials/slides-110-danish-danish-bof-slides-02 > > The example raises a few questions: Many questions will come from examples, hence the need for them :-) Reminder: step one is getting the charter done and the WG formed *then* we can solve the problems. So we shouldn't go too far down this path at this time -- but we should agree on the problem space being tackled. > PS: I missed the example of onboarding a device in a hospital. https://mailarchive.ietf.org/arch/msg/danish/OkQzlyZoKlEar5-GU6HgtSz3ebY/ -- Wes Hardaker USC/ISI From nobody Sun Jun 20 22:04: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 E8A2F3A2213 for ; Sun, 20 Jun 2021 22:04:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=Zf25Iqy3; dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=Zf25Iqy3 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 nopMgwgeSwN7 for ; Sun, 20 Jun 2021 22:04:51 -0700 (PDT) Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-eopbgr00057.outbound.protection.outlook.com [40.107.0.57]) (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 B86793A2212 for ; Sun, 20 Jun 2021 22:04:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=OAE60zF6AM5MgR82ctD8HTUUPJPlGCI8iOOC87LM3gU=; b=Zf25Iqy3+0vU1ASVymvUh9KEznzeuEaGFptcoZi6k4ikna8K/wl4+b4ME2kCTfSPIaaORhe1DBfQj4KZ3BalCcPwzctThgyZimgRJ0nSlzqvmW8NkG9BPeUMYRJwwdTD2yz2GzbKZ/uD5A5yr+BjyhxTxPr6YisjJQDvgy3EKy0= Received: from FR0P281CA0059.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10:49::7) by AM0PR08MB3986.eurprd08.prod.outlook.com (2603:10a6:208:128::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4242.19; Mon, 21 Jun 2021 05:04:37 +0000 Received: from VE1EUR03FT044.eop-EUR03.prod.protection.outlook.com (2603:10a6:d10:49:cafe::2c) by FR0P281CA0059.outlook.office365.com (2603:10a6:d10:49::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4264.7 via Frontend Transport; Mon, 21 Jun 2021 05:04:37 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; ietf.org; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com;ietf.org; dmarc=pass action=none header.from=arm.com; Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 63.35.35.123 as permitted sender) receiver=protection.outlook.com; client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com; Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by VE1EUR03FT044.mail.protection.outlook.com (10.152.19.106) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4242.16 via Frontend Transport; Mon, 21 Jun 2021 05:04:36 +0000 Received: ("Tessian outbound 41e46b2c3cec:v96"); Mon, 21 Jun 2021 05:04:35 +0000 X-CR-MTA-TID: 64aa7808 Received: from ef7be9c91665.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 8DFF793C-B94E-48C5-9A9A-5788E8A38B68.1; Mon, 21 Jun 2021 05:04:29 +0000 Received: from EUR04-DB3-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id ef7be9c91665.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Mon, 21 Jun 2021 05:04:29 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=PJmYDrmbeumaib4QjRKYelUo5U1uVFeap/Ju6Cvb/ZTd7ZrS2Zg4bgNk4318s5VwxI65yH12Lp3kTQSJtZUTt40KnfqZSc0oc+/wFy14WwnXr0aFEl6g6ZrUv0c1bByl5mfolQQohas+JBaM77FO9qHeESqiRWD91pM+Z0gkmyC9QTcEG34EsmJfpbbmtOOQiijQw3JiQthi4oMHBR5X65FsWardSKmhsl7DgnSw2+nJp4FwvGvdf0JpxTmGt81nHRt81YaKCLebCVl+lQr5Zd6/3K4JbL4QDZ5x8KhhJuT4N1poZupgGumeKjll2whx9xnERKAo18fsrRiK0J8zRg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=OAE60zF6AM5MgR82ctD8HTUUPJPlGCI8iOOC87LM3gU=; b=YBcW1/KHj8QaW/ESdhI0hj8FVPuVcytHziOxkbEEfPLHLWmq8+LQ2V2uyNa0bUhe+CX96ha5eHiMsdKlFCr2e/6teVPqHnuE6/ViOZM64Yz+XJIdjDUKu1KdemyOnUILzZ1MCnYIycyQE7maVBTVoBVEZ3bA9uwZeeVWp4Wi1Ma78/cwS7nS5XEwp3eoaCh2DZ4di0RnC7E9dJMhJTQrlzonmE27L9hQpUG7Vv8qYCxexug4UtZvLQlVfFDoZKOVQiV76LuHVpfVOQsry8MxsnNsfH5JcN2F5QYqb46vO9y6emIbiIQW12tQSkg0PNhCzn7q8OZ9TzpeqNtmy224eA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=OAE60zF6AM5MgR82ctD8HTUUPJPlGCI8iOOC87LM3gU=; b=Zf25Iqy3+0vU1ASVymvUh9KEznzeuEaGFptcoZi6k4ikna8K/wl4+b4ME2kCTfSPIaaORhe1DBfQj4KZ3BalCcPwzctThgyZimgRJ0nSlzqvmW8NkG9BPeUMYRJwwdTD2yz2GzbKZ/uD5A5yr+BjyhxTxPr6YisjJQDvgy3EKy0= Received: from DBBPR08MB5915.eurprd08.prod.outlook.com (2603:10a6:10:20d::17) by DBBPR08MB6250.eurprd08.prod.outlook.com (2603:10a6:10:1f5::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4242.19; Mon, 21 Jun 2021 05:04:29 +0000 Received: from DBBPR08MB5915.eurprd08.prod.outlook.com ([fe80::69cf:4429:a804:7f41]) by DBBPR08MB5915.eurprd08.prod.outlook.com ([fe80::69cf:4429:a804:7f41%3]) with mapi id 15.20.4242.023; Mon, 21 Jun 2021 05:04:29 +0000 From: Hannes Tschofenig To: Wes Hardaker CC: Michael Richardson , "danish@ietf.org" Thread-Topic: [Danish] Charter Text and the Problem Statement Thread-Index: Addin8Z32g6ibl9RQiW6iIvXVU0WhwAVq2gAABL3x4AAGNNDAAAroAeQAD1ePYAAGAHboAAOiVllAAKHOrAAEKLBfAAKlq/w Date: Mon, 21 Jun 2021 05:04:28 +0000 Message-ID: References: <23295.1624134481@localhost> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ts-tracking-id: 937582BE5A2A994E9D5EB3AACC59F1A8.0 x-checkrecipientchecked: true Authentication-Results-Original: hardakers.net; dkim=none (message not signed) header.d=none; hardakers.net; dmarc=none action=none header.from=arm.com; x-originating-ip: [80.92.123.248] x-ms-publictraffictype: Email X-MS-Office365-Filtering-Correlation-Id: 1a70597d-a751-4e8c-c389-08d9347210e1 x-ms-traffictypediagnostic: DBBPR08MB6250:|AM0PR08MB3986: X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true nodisclaimer: true x-ms-oob-tlc-oobclassifiers: OLM:8273;OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: H4f1hkLxOIN8D7XgRTuCT7MuMTWA1l4BBxNR7S3o6SriB3C4qTMfh6wemW2X9uWThie5s9nmJyAmC4LwMeJBoctAoDXS1/jKDB6Zdl+37KiXl68EPUXqZL+tbNVEzz1+o2WGFFgNExS19bzDKb5Ul4mvT85acU/98RXraXRqwKLwIWTgrifHAxCOppng8g7pgRBPxcrpooD/E2FEMIusJHvzrDNETHRcgLGRXPV3JBEym0hsxM8y2Y+Ym1L4QM8OI/beP0ZYllfv+IM7tnjU9CE2F3CtkpIy0GtAmyqNxRGIzrpm+F+6jv54pP2qdhwUgEtScbQ6czegU2WqtqS/8yepMrs3vaoNnr1FJ8s2oIErrMvQTzObFhGBYjPXoPJW975gdm6hhvJoZp9DrTrMQHqmQfso0rAW/HvAEo0m+N+3ulLkF0gXPBEM0dDrv/XZtYr1tayKyXqf52p24zl8jE3InWkvmNkG4xgtOYiAIFBCsbsc7Zm2c8yztn9f++U0Mcx7HFiSufU+/jZsZplidYdVcKeCHQpRgbA8CoXhOPmC8qeTFOv/YB3uNE8CgAgX17OPyKSvyYI1s2r3ix00B+RhJBM5CUPdHakBbGfxIJc= X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DBBPR08MB5915.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(396003)(376002)(136003)(39850400004)(346002)(66946007)(76116006)(316002)(2906002)(83380400001)(71200400001)(4326008)(66556008)(66446008)(64756008)(122000001)(38100700002)(66476007)(33656002)(6506007)(54906003)(26005)(8936002)(5660300002)(186003)(55016002)(9686003)(7696005)(8676002)(52536014)(4744005)(86362001)(6916009)(478600001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?nO/x/8zKSrILp0lywy5Otc884rxYa/qhbRGDE55zvvCakdagfY7dJAj8WOuD?= =?us-ascii?Q?+aZReBuaJlYBrLe3e08Ph4g6B1z31zeowhZt/hZLfsjX4UfNRjG3Ro1Oq708?= =?us-ascii?Q?4ADb6JKRnJXPsd0KBdeMqG8ThGQC/1o1j3jd+zPTGov/P+ii82hQ05AOEbBt?= =?us-ascii?Q?ajMkqlkcb75/Fp/1e/z28enJUbup5d7j4yOsGR0/aClUNlFEQLz5ve5CYsGL?= =?us-ascii?Q?3+n8qSonhW6WjBmdZi4MHHD8Je9HbFYUf6cAAwyEcnAaOsB046w90tmtoJMK?= =?us-ascii?Q?MQBWSMc+OcrzbMDRQqdCoIOSfATuQ0XPRWbr6VJNztjShX6A/TIMPI/Vfrv4?= =?us-ascii?Q?sDffE5jxnaxxgbcN+FzUqruBvbHR+iA3BOht5soE/0zJMjTJr7w7PlnNG7H/?= =?us-ascii?Q?ci5kd/FhWI0rEIHzH+lse4rWYkiEZ57nOiAuHHZNzt3YG70Se7izvKaNHBFA?= =?us-ascii?Q?v8Qe0S4qbLnabOkNEj9udOUHzdk4CoLWbeJ+3XMFYxB+GOeD0IZj3sEqU8/j?= =?us-ascii?Q?6Kr4FFAaZKFqPZ9pV9fA/16QE6DGmaAalgxe01fMzm9AsQqgx/aBK7Tq3E2e?= =?us-ascii?Q?NhS6Ta/H2xrdhYuZDYJMZQhy2xWSosiD8z0X4AOERRdqc4J3xGoBux1rZWCj?= =?us-ascii?Q?GyV8FuZ3+5xE4cs4mMdbGp+A1R97Ajoam4XcfIBOyYobaSU/tk3Twi1kiLNa?= =?us-ascii?Q?jbjZ2OyZX9ZL3QB81NoOsAqNlVJK9+w/3sLZJqk8BBVZCN+mnqsMK+8dwVs3?= =?us-ascii?Q?IJRgne1BLBbwzLKQ7Qnhp5plyiubcQO6LrT4yIntKDd7d3ZlRcLkOq1r2aE/?= =?us-ascii?Q?LgIVAIWM2T2hL1/GK5P6VDg0Ndjxe4RQPr0NUS7Mh51y+1QlNGUc6oFjLYVr?= =?us-ascii?Q?QPQwNFA6YnP0GYod9dsKMPn/d7qFTMhlqnXO3mQaeLzUHBp5Gzb8W+HjtIKi?= =?us-ascii?Q?oVkBws/FRbD28hJsrrToSdN2FuLvpeiDj5h7z44DqJuiAQQLV8Du1scgPf4a?= =?us-ascii?Q?lfedpPk7+s9R69KxrGDZhBsTMy9nadAlSMXEd0HY3aGNvIq1h8C4i3IKKc99?= =?us-ascii?Q?uEPnoeREx19atBuNRAg0qpaNMKTBGyH4CY2mFudtCCM5CW4YkqPQOd2OT5o8?= =?us-ascii?Q?rZJZ96qVWbwCxbj7sHY/utEfSBw9MleielhnkuZKH90ntgbXh+46iQHqCvpj?= =?us-ascii?Q?hVdRcaRSaiwhdKR4c8UvTEB7yuYdQkX9IxTluN6KR/9U4FpQ8FZp7NL6KPdj?= =?us-ascii?Q?m7V7PNfLdpQBEq2CK2R0xlrWsSe+ffRkZxbQNSo/upYhVOBQP9AnmbECAdgx?= =?us-ascii?Q?jRlpBwxfb8syPtCPWCLIL5sc?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBBPR08MB6250 Original-Authentication-Results: hardakers.net; dkim=none (message not signed) header.d=none; hardakers.net; dmarc=none action=none header.from=arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: VE1EUR03FT044.eop-EUR03.prod.protection.outlook.com X-MS-Office365-Filtering-Correlation-Id-Prvs: fc58e39d-0662-4efa-b4d0-08d934720c94 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 1YjMNwQfokzR5easY+fCaWb8TAvxaOnXTNCmIScw/e9bKcJ4lEpyz6Ps+XpA+UjSYVdw6IhlTmPR/c+WYh7pFNXvVutx079UWzXhajoDUlJ2sA5x3YWXhlC6p5WoCN6eZOx6jgXg4qQ6lm2z0oUybXAV+Gw1wsE3qOeogFsT2QLEX0Q+p1OwD8Oe+M96NFv768XN7UaV7x7+UoRbx6GUUd4yqC1sDC1iYkzO0zW1aoRbeGT7HuEsaHhfub+PdM4819l3z8gInzScNfZN64kFjZ2wfVwr0it3oZ3CCiE0k1CW2+PxQN/Kry9z48SXmvjAMSzFUWVjCcVnujERnbb5UKtbB5dwTUyTwtADLIW1wdTUEbezsVBLyW+SSM92AKF9hCxCensoXXsl3h0g7gmUKovdhIg26reXqL/Q0kpClRASafD7anCGhmnBd1AJqNEAWjRZ4uMNqtRgqrc0agCAZNGQOLaCXbycK9OnKTTN8vXti0dJ1dUdwb5lLiN6ABAkkWaYy/8zCmB/iwTLubZjnM2TR7U3vj7qb1dQW3PYwuxLMaRQgOBFCV+AtEr/GYBSJPtr5b5X5/Z484l7hhYc+G1FVy3JZtgw7v1Qfb3PDL3xE/8hMxAgWvaXRfXByzoiMFrfjIXQIkJ2rIgK4bMfKg== X-Forefront-Antispam-Report: CIP:63.35.35.123; CTRY:IE; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:64aa7808-outbound-1.mta.getcheckrecipient.com; PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; CAT:NONE; SFS:(4636009)(346002)(376002)(136003)(396003)(39850400004)(46966006)(36840700001)(8936002)(5660300002)(47076005)(26005)(478600001)(33656002)(186003)(6506007)(54906003)(52536014)(86362001)(82310400003)(4744005)(70586007)(7696005)(36860700001)(9686003)(55016002)(8676002)(70206006)(83380400001)(82740400003)(356005)(81166007)(316002)(336012)(2906002)(6862004)(4326008); DIR:OUT; SFP:1101; X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Jun 2021 05:04:36.2545 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 1a70597d-a751-4e8c-c389-08d9347210e1 X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d; Ip=[63.35.35.123]; Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com] X-MS-Exchange-CrossTenant-AuthSource: VE1EUR03FT044.eop-EUR03.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR08MB3986 Archived-At: Subject: Re: [Danish] Charter Text and the Problem Statement X-BeenThere: danish@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DANE AutheNtication for Iot Service Hardening List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jun 2021 05:04:54 -0000 Hi Wes, > Reminder: step one is getting the charter done and the WG formed *then* w= e can solve the problems. So we shouldn't go too far down this path at thi= s time -- but we should agree on the problem space being tackled. In the good old days, we tried to figure out what problem to solve first an= d then formed a working group. Ciao Hannes IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you. From nobody Sun Jun 20 22:10: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 3F1023A2245 for ; Sun, 20 Jun 2021 22:10:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=wkmQgIYF; dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=wkmQgIYF 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 Pll54nq5WJdF for ; Sun, 20 Jun 2021 22:10:49 -0700 (PDT) Received: from EUR05-AM6-obe.outbound.protection.outlook.com (mail-am6eur05on2070.outbound.protection.outlook.com [40.107.22.70]) (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 8013B3A2243 for ; Sun, 20 Jun 2021 22:10:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=I8sIAPwilgirT5rhlHN1dEMW4Irfx3tonG4gzXc+Upc=; b=wkmQgIYF4etHfxYafAC4Nglm2GJhnF27eUtwU9niIZ3I90xFlN/+bL8Q5qc745r0JLHCdB+nW2UYFHCpy7JtbgdmUO8HEnJ1gog7MlPzlokSu7G1sZcBZjWuGKuiK2QQM0/4nQe8YYSKCNLwxgHC9A5m4iB0pq4XbirOLXvCnP0= Received: from DB3PR06CA0011.eurprd06.prod.outlook.com (2603:10a6:8:1::24) by DBBPR08MB5883.eurprd08.prod.outlook.com (2603:10a6:10:206::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4242.16; Mon, 21 Jun 2021 05:10:46 +0000 Received: from DB5EUR03FT019.eop-EUR03.prod.protection.outlook.com (2603:10a6:8:1:cafe::b4) by DB3PR06CA0011.outlook.office365.com (2603:10a6:8:1::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4242.18 via Frontend Transport; Mon, 21 Jun 2021 05:10:46 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; ietf.org; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com;ietf.org; dmarc=pass action=none header.from=arm.com; Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 63.35.35.123 as permitted sender) receiver=protection.outlook.com; client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com; Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by DB5EUR03FT019.mail.protection.outlook.com (10.152.20.163) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4242.16 via Frontend Transport; Mon, 21 Jun 2021 05:10:44 +0000 Received: ("Tessian outbound 92494750bf3c:v96"); Mon, 21 Jun 2021 05:10:44 +0000 X-CR-MTA-TID: 64aa7808 Received: from f289a8a1ab78.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 887DFD59-1A9A-4002-82E3-868A0B443666.1; Mon, 21 Jun 2021 05:10:38 +0000 Received: from EUR02-VE1-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id f289a8a1ab78.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Mon, 21 Jun 2021 05:10:38 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Ca5AuA9G9uDb10nBnC/tpbGpOcPfv/iVjkQmiBt+GCuI85wLORVyY7SK11JOWBNrOinMGhHK5KiPyhRF00m9Uv7XyClPIeffVddmkN1zM6iYTULbwGQvKS737+mM0VBDsSv3JBb3q8KD4fhKYHlTTv76H5PuD5Yg8qeiZJwfL8dlLlIsOVzkOtMAfoScqesJZbRFGb7GiYW7S4+oyvAEapMNUsnzmD/McwYMqSvbQa/BV8vN8AS8i2vSH9W/3dg6APi0n+zWohOY01NU3N6csYlrGSgZsQu16TQig46rKvxSUAE2jBRb4vpdE0Qd5ngTcnufqQsSETI7UZmbawykig== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=I8sIAPwilgirT5rhlHN1dEMW4Irfx3tonG4gzXc+Upc=; b=T29JpGOeUIHfVq51XPr3AyNm+KH1yjqML5PUzPl1Y6xOvMyBCq2E5JAyKRwng0gcSWyd9G1WOAHmWPShPimhV9ayVoNZfmtrF3ov444lSKXEd7bmNIG0R9yn4s7LNnW0ao5HgAJmOl/xnDboH5ElsYTVukUkS7msLqQfYIYQh7LUg0INwoK2p0RKTj6zDcE01zLKfuMab1JpuF7u8kWeTqTRJV9arm1GgiNiExtgYhdbJsbe7b87c0E6Ghy90SMRXknHRHSAK1+Xr4bS0VmmZqCFplDg82tqPP1bhJ0SmdO5MF+Hx/KFo979vhcHOD5TsKdgXoy3RIPTw8BIRvmRcA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=I8sIAPwilgirT5rhlHN1dEMW4Irfx3tonG4gzXc+Upc=; b=wkmQgIYF4etHfxYafAC4Nglm2GJhnF27eUtwU9niIZ3I90xFlN/+bL8Q5qc745r0JLHCdB+nW2UYFHCpy7JtbgdmUO8HEnJ1gog7MlPzlokSu7G1sZcBZjWuGKuiK2QQM0/4nQe8YYSKCNLwxgHC9A5m4iB0pq4XbirOLXvCnP0= Received: from DBBPR08MB5915.eurprd08.prod.outlook.com (2603:10a6:10:20d::17) by DBBPR08MB6250.eurprd08.prod.outlook.com (2603:10a6:10:1f5::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4242.19; Mon, 21 Jun 2021 05:10:37 +0000 Received: from DBBPR08MB5915.eurprd08.prod.outlook.com ([fe80::69cf:4429:a804:7f41]) by DBBPR08MB5915.eurprd08.prod.outlook.com ([fe80::69cf:4429:a804:7f41%3]) with mapi id 15.20.4242.023; Mon, 21 Jun 2021 05:10:37 +0000 From: Hannes Tschofenig To: Michael Richardson CC: "danish@ietf.org" Thread-Topic: [Danish] Charter Text and the Problem Statement Thread-Index: Addin8Z32g6ibl9RQiW6iIvXVU0WhwAVq2gAABL3x4AAGNNDAAAroAeQAD1ePYAAGAHboAAc2eSAAA9o/EA= Date: Mon, 21 Jun 2021 05:10:37 +0000 Message-ID: References: <23295.1624134481@localhost> <5631.1624225291@localhost> In-Reply-To: <5631.1624225291@localhost> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ts-tracking-id: C7057483F601F04283354F4EFD489AC6.0 x-checkrecipientchecked: true Authentication-Results-Original: sandelman.ca; dkim=none (message not signed) header.d=none; sandelman.ca; dmarc=none action=none header.from=arm.com; x-originating-ip: [80.92.123.248] x-ms-publictraffictype: Email X-MS-Office365-Filtering-Correlation-Id: b322628c-a682-435e-35fd-08d93472ec6d x-ms-traffictypediagnostic: DBBPR08MB6250:|DBBPR08MB5883: X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true nodisclaimer: true x-ms-oob-tlc-oobclassifiers: OLM:6430;OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: 09+0Cd528FEL3g2RLSNvlmZxmlz68siZSu/Z+Behcg4HPzCRZakVOYJjWDZarleuBx5EdFEdAJgNUV99ltKwNr230HOyAIUYRoZMshGkJXhkZedQNKmU9Lau8SUDiX9HKDoxqrJP13knBpqIAUTRKvfCH1TZyTas0eHrkN3G5ljiZzjmrbhEApMUqLy2w1usOtUM9kH8QAVhUmybS86KcJDh8AUNtK5vPe6xjGzvtTuBQdhHNBzYwKKEEVBz8kVocoI+2ivKLDsCJuLkYi31PFxwzs6j+tg+96U5FqmGfc2PNFD1L82N+OyHUviBv2LfUxqcQ1O9aVn+pNOMy6GCx+6x6IInIWsPwGQ2fbStpnOB8/D8YmLx5ROEws3dBXYCcbk05tV1aXZVnGFHIXr5mXBIT4ZxpzTQN6U2W3rBWJ4oseERRzvkBpkV/0dOMZJ47W6d0tyAerAEv/vCVYoTIxD7dUmzqumYngnh5M8ennNvK5GdNv4EIheaVLx8koG7+jK0q0Z8JBbk/PPoF8lp/wDr6fsjXs7Dkm0g2cgbXTzJPDw2ydaFndoonFEnuXMxLpNTLg0z2Gu2jssP5N7OQVzPFwBXNPyNwtzNgRdh6ao= X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DBBPR08MB5915.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(396003)(376002)(136003)(39850400004)(346002)(66946007)(76116006)(316002)(2906002)(83380400001)(71200400001)(4326008)(66556008)(66446008)(64756008)(122000001)(38100700002)(66476007)(33656002)(6506007)(26005)(8936002)(5660300002)(186003)(55016002)(9686003)(7696005)(8676002)(52536014)(4744005)(86362001)(478600001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?QWR5ZFY4bllHTTQrVkU0dUtrSFhCTlNUVW9mdmR0eW5XWU10MTZwOGN0Zm53?= =?utf-8?B?MjlLMzJaTk1CRXF2TkdodGlSQzN6QmJWeUhsTXNHcDM5bjJEK1pVQlU1T0Nv?= =?utf-8?B?Y0ZBSFB6SGpkaDljTjRNWVkwRG9NU0paaW5aM05Ccjd1WW16T1NqamtwVkdk?= =?utf-8?B?dU5ZWmwvdnV2emlNK0wrQUZobXNWZ0hUODdEZTR3SXUyZ3NvNkw3eFVXc1JK?= =?utf-8?B?Qy9ReHhyMms0STB6aUI5TUpQNVAvYnNNenUvYmZCZjExTkFkTVRQa3JCRU40?= =?utf-8?B?TFlWVVVMVHNtaWY0MHcwSEU0dStZV1ZwQ3BuTEJpT0xaNXBhOWI0NklNWkNN?= =?utf-8?B?c3dFS0lhMkcwTy9LcUEzQ1FjOEtOUURLOEZtYTBCdk1peUtiWDRWMXZrbm0w?= =?utf-8?B?NGc0VWNIZ291dnhvdGxkNHZKMkxtZk5EeDFXMGNROVZkSnFrNDR2ZjJnTXh6?= =?utf-8?B?OG8vd1AvbkdDV29ERm1DUndMaG5NRWdXNTZzY2R0ZEh6eWhQWVc4STRDcVV5?= =?utf-8?B?RkVQazd3dEE0ZXUxNnNCVEh3UVVuOWNoQlBVZFlGNFFwVm8rdFlLNzNoa1JW?= =?utf-8?B?elF6Qm83Vi9JWlMvZGtrNXRRNjFHUGd2MzhQbUVSWHAvUDNHa00vbEt6SVRE?= =?utf-8?B?STZOZFFybXUwSmRKblk4dmU5MnJVWFJlNTVqRVpXWXh3T25NeDBJaVR0N1Z4?= =?utf-8?B?YVBOdUtvRjhYZGQ3T2FzRUUvcnBWNDlJNlQ5VUJORkhEQVQ2bS9taVJCQ1dK?= =?utf-8?B?bDY1bGJtYVpmWmRsM1U0M1I0d3NaMVhiUFY5VmJxK0FTUGhYTW9ianU4YkQ2?= =?utf-8?B?UnhNUTZRYkpWZEFYdXlJc204ZVRlL0xCQnhFZ0o0aWl0MUJOZVpDNlNraGNu?= =?utf-8?B?b1FlNVFqcG9PWWdWanVtdUd6TmhodzRjSTNXdUNRUkswYmtBeEpBd3k3OUQw?= =?utf-8?B?S3psdVB5SXVGMEtjcS96S09hWnkzejZNZjQvSzVWSTFEMW5BYy9DckJMZHBU?= =?utf-8?B?aXp4ZVdLQTV3b1hpeDRHT3Z6TjJIR1JHUGxMK25LcitZWnhLRUNvUm5zZGhS?= =?utf-8?B?anZXSkxBV0toOWUrcm9uOHFPaFdJVTVic1FDd1R5ellSSFFSM24xOHlzZGRU?= =?utf-8?B?K21TMXMzZ2UrZ3NObVdzbWZNQjNwRmJDNnlORWFYS0xHOWhYZTB5U1hJOFlQ?= =?utf-8?B?RkdTUk02QWx3T0Y4Q2NQU0tWUVYyNW41aWRud29MY3hJNXo5T3A4Sk1uRm5s?= =?utf-8?B?THhqb29TU3NkQUFOQUlOWmtnT01mTlhpZ2JyUXVHaGpNVGJPNWpzUytjQm14?= =?utf-8?B?ckE0OEFqZlUraHJEUXcrOCt3cTRkRDNJMHAxVnJjNkRXV0tYemFhVHNVV0ND?= =?utf-8?B?NS9IY1BnN3NRZEVjUDVDVGx1dXNTazV6amVOZDhMSGdHOXYxOHVYcTJHbHA1?= =?utf-8?B?eGFVaTVsNFJISXNya1ozbkt6am9VbkJkbFJmaG56YlVhaForU1lLc1pTS3E1?= =?utf-8?B?aGR1OHBQZGVNYmY3Z1B0ZlNtQThaNEt6WFJ2Qkl2VFgzSFJzcW1FZzhSWlVJ?= =?utf-8?B?aktST1hTc3U3cFJoWTB6UjZwUDNCbUk3OGpDV2xPck01Z0ZyL0wwQk1Rb3lL?= =?utf-8?B?dURJaVFFb29sSks0SjcvZmdOdHhVTzJISUluT2YzZmdUSTZ2SGlBbkRPYm8w?= =?utf-8?B?MFlYaGpkVE5pMGV6eGZIK3d4d0Z6TEErMHlWUDdqN2kwaTFHZmZHYllGTkc5?= =?utf-8?Q?36HlJ4Mya2EcSwIhmNYyHGrp8a4flcrMny5E+JR?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBBPR08MB6250 Original-Authentication-Results: sandelman.ca; dkim=none (message not signed) header.d=none; sandelman.ca; dmarc=none action=none header.from=arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: DB5EUR03FT019.eop-EUR03.prod.protection.outlook.com X-MS-Office365-Filtering-Correlation-Id-Prvs: 2872b84c-54bb-43d6-558e-08d93472e81a X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: bRSI/q2QQg2+FV1pqy1aMkvFxSjBBJlW++LSFnF75y9pro1Pt1N3EHMy0FaShTjF1BwRNoHS7DOqrVzXelVxP8D8BT2+l+d0FffXf7yhe7OcW/wAGtU9s7mYsU89USvwSNI9Q8AcX92/lfi0qIYQW8GAtPg3d0oFia1HEaJA8aowBEym+Tu751cXNOaCbldUJOXClR30+8jmBdWYu5M4KDPiusraJ134ujKxlQ26Br7+xyEkrXB5SkUrqZvLkb7Nfafhx3S4+GEDgcT0mbeuKe5EuarfSi7KC3AwMd5jw0tWGKlNilWUZwcOMzkJDxBxjI1zN0Y2xwn5jE9j5qCbJOPeV7V+IQyVzfFyGjBPfKjvzOupuT8n3D++afN1PZJQ8PDYhDTf/nKLbrjNlivMJdQHG8oXUktLCFIBZN4a73rofT5XBRxOMRZsrpw0xAbiXsnGcyQ2UQfTAKOkRbDtU8OR4etSMDf62Y6l0z8mKqiko54F9W8OmzSeRECzfS4Jm/3YmELJxXJM2QdDMocJAzF1GGMInzkJbzmprB2aZCxf4Ik0ejsTrV3c7/3pSSWI1XjimfP+JffYBsMmc9obG29IHmvm6GsZyRGVZC2ft4jsTgcDszsKc3d9NVSrcI9Ee8EYFcZDyxrzXdmYI/i16OJY2oRolrxieVOvX3VJN0I= X-Forefront-Antispam-Report: CIP:63.35.35.123; CTRY:IE; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:64aa7808-outbound-1.mta.getcheckrecipient.com; PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; CAT:NONE; SFS:(4636009)(396003)(39850400004)(136003)(376002)(346002)(36840700001)(46966006)(8936002)(7696005)(356005)(186003)(316002)(36860700001)(26005)(6506007)(81166007)(8676002)(9686003)(82740400003)(83380400001)(47076005)(82310400003)(33656002)(55016002)(86362001)(4326008)(52536014)(2906002)(336012)(478600001)(4744005)(5660300002)(6862004)(70586007)(70206006); DIR:OUT; SFP:1101; X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Jun 2021 05:10:44.7062 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: b322628c-a682-435e-35fd-08d93472ec6d X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d; Ip=[63.35.35.123]; Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com] X-MS-Exchange-CrossTenant-AuthSource: DB5EUR03FT019.eop-EUR03.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBBPR08MB5883 Archived-At: Subject: Re: [Danish] Charter Text and the Problem Statement X-BeenThere: danish@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DANE AutheNtication for Iot Service Hardening List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jun 2021 05:10:53 -0000 SGkgTWljaGFlbCwNCg0KT25lIHJlbWFyazoNCg0KPiBJZiB5b3UgdXNlIERBTklTSCwgdGhlbiB5 b3UgZG9uJ3QgbmVlZCB0byBvbmJvYXJkIHRoZSBkZXZpY2UgKGkuZS4gZW5yb2xsIGl0IHdpdGgg YSBuZXcgY2VydGlmaWNhdGUpLCBiZWNhdXNlIHlvdSBhbHJlYWR5IGhhdmUgc2VjdXJlIGFjY2Vz cyB0byB0aGUgY29ycmVjdCBjZXJ0aWZpY2F0ZSB2aWEgRE5TKFNFQykuDQoNCkluIHRoZSBwYXN0 IHdlIHVzZWQgZGlmZmVyZW50IGtleXMgZm9yIGRpZmZlcmVudCBwdXJwb3Nlcy4gQSBtYW51ZmFj dHVyZXIgcHJvdmlkZWQga2V5IHdhcyB1c2VkIGZvciBhIHJlbGF0aXZlbHkgc21hbGwgbnVtYmVy IG9mIHRhc2tzICh0eXBpY2FsbHkgZm9yIG9idGFpbmluZyBvcGVyYXRpb25hbCBrZXlzKS4gRm9y IHVzZSB3aXRoIGFwcGxpY2F0aW9uIHNlcnZpY2VzIHdlIHVzZWQgYSBkaWZmZXJlbnQga2V5LiBX ZSB1c2VkIHlldCBhbm90aGVyIGtleSBmb3IgZmlybXdhcmUgdXBkYXRlcyBhbmQgYWdhaW4gYW5v dGhlciBmb3IgYXR0ZXN0YXRpb24uDQoNCldoYXQgaGFzIGNoYW5nZWQ/DQoNCkNpYW8NCkhhbm5l cw0KDQpJTVBPUlRBTlQgTk9USUNFOiBUaGUgY29udGVudHMgb2YgdGhpcyBlbWFpbCBhbmQgYW55 IGF0dGFjaG1lbnRzIGFyZSBjb25maWRlbnRpYWwgYW5kIG1heSBhbHNvIGJlIHByaXZpbGVnZWQu IElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBub3RpZnkgdGhl IHNlbmRlciBpbW1lZGlhdGVseSBhbmQgZG8gbm90IGRpc2Nsb3NlIHRoZSBjb250ZW50cyB0byBh bnkgb3RoZXIgcGVyc29uLCB1c2UgaXQgZm9yIGFueSBwdXJwb3NlLCBvciBzdG9yZSBvciBjb3B5 IHRoZSBpbmZvcm1hdGlvbiBpbiBhbnkgbWVkaXVtLiBUaGFuayB5b3UuDQo= From nobody Sun Jun 20 22:44:36 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 0E29E3A2386 for ; Sun, 20 Jun 2021 22:44:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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=armh.onmicrosoft.com header.b=WzCc+Oqo; dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=WzCc+Oqo 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 c8GnL51618yX for ; Sun, 20 Jun 2021 22:44:30 -0700 (PDT) Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on2046.outbound.protection.outlook.com [40.107.21.46]) (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 989B83A2382 for ; Sun, 20 Jun 2021 22:44:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=0gg4qMWFtYU5FOHxE8vc1EUYxQ7nK9JAsj7EaxWHGGM=; b=WzCc+Oqos2256C2DoK/87El8ZsFjt2YP+RYsLrcBZ9kjcJK9WyjME7aMwvY9/ArQo+udoexT9JRECTdN5uQT6IjkI8tbK09HQlZIt3CD6Maz9Dn/usc/Ak5+mIGVb45lcWAcuhKerGINGanFsjWFjDh7ZtKiP6OiuIfb4rEGyto= Received: from DB9PR06CA0014.eurprd06.prod.outlook.com (2603:10a6:10:1db::19) by DB7PR08MB3097.eurprd08.prod.outlook.com (2603:10a6:5:1d::27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4242.18; Mon, 21 Jun 2021 05:44:20 +0000 Received: from DB5EUR03FT038.eop-EUR03.prod.protection.outlook.com (2603:10a6:10:1db:cafe::58) by DB9PR06CA0014.outlook.office365.com (2603:10a6:10:1db::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4242.15 via Frontend Transport; Mon, 21 Jun 2021 05:44:20 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; ietf.org; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com;ietf.org; dmarc=pass action=none header.from=arm.com; Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 63.35.35.123 as permitted sender) receiver=protection.outlook.com; client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com; Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by DB5EUR03FT038.mail.protection.outlook.com (10.152.21.84) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4242.16 via Frontend Transport; Mon, 21 Jun 2021 05:44:19 +0000 Received: ("Tessian outbound f945d55369ce:v96"); Mon, 21 Jun 2021 05:44:19 +0000 X-CR-MTA-TID: 64aa7808 Received: from 18c096fe9760.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id C38F35ED-AB3D-4109-98A4-9BC4EFE053D8.1; Mon, 21 Jun 2021 05:44:13 +0000 Received: from EUR05-VI1-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 18c096fe9760.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Mon, 21 Jun 2021 05:44:13 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=kVj5Gj/qTWtbZaAXWR+3nVO8OCSWCCUdm6+wlM7pkXZVHzZncb+HKGC0YjQbvL7nG8SYEVSnZVbWZPFikNnCo0IupnANHcF1HPEHV5t5tgXBzmlH5bQ4og7gzzGi87N3imzw8kLPwLpvZStnQyL4igKIqNz67b7OBYL4LDsJ+APB+Fc6wsB/8VguCseExwmKrMF3rAoUVVVmGR1bLOefdyQW7lrJ6ZtXa6tsfRV/4a0W4Qm5wKzp2Un8zQVm9hd6VTj4crHuGzvz/q0k1EdpwoZa0gnqpmHnyHIYhKedM5oT3g+IT3Qf53X1uqniZ0u2V/QAlLWPx2kBdZYj0g+pHg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=0gg4qMWFtYU5FOHxE8vc1EUYxQ7nK9JAsj7EaxWHGGM=; b=Bq9ylEEunW0/bu6vZJ+0DgPnOe0Tvw6RRM3yB6AVieSSHmhFEAUWg2ODpXBtJ5oZZ6q6Btk+hdPj3VjyqtqyzHKn9senlRL4CmEVjAu3NITBw6UcB4dkedHbojPfZK6mSbIDHEwLLYeledhjDy0h/4DxjIiuiYUpZ/V3kkxCklY4aN3zGgwl3QZq2cz9Y/YfsCRQPpq1CPhM9Aa2rWkPJCVKkTriKrnO338b+8xxSbq8Bre0pOl/jIRGKQm78k+9znFXeC3DH6Rcv7uGch0C7V6Db50vs/NL/L9T5DB5PFflgK0LiwaBEBcOlsl9/FWmCAbbesRUwfjoByLzMRljTA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=0gg4qMWFtYU5FOHxE8vc1EUYxQ7nK9JAsj7EaxWHGGM=; b=WzCc+Oqos2256C2DoK/87El8ZsFjt2YP+RYsLrcBZ9kjcJK9WyjME7aMwvY9/ArQo+udoexT9JRECTdN5uQT6IjkI8tbK09HQlZIt3CD6Maz9Dn/usc/Ak5+mIGVb45lcWAcuhKerGINGanFsjWFjDh7ZtKiP6OiuIfb4rEGyto= Received: from DBBPR08MB5915.eurprd08.prod.outlook.com (2603:10a6:10:20d::17) by DB8PR08MB5196.eurprd08.prod.outlook.com (2603:10a6:10:ee::31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4242.21; Mon, 21 Jun 2021 05:44:11 +0000 Received: from DBBPR08MB5915.eurprd08.prod.outlook.com ([fe80::69cf:4429:a804:7f41]) by DBBPR08MB5915.eurprd08.prod.outlook.com ([fe80::69cf:4429:a804:7f41%3]) with mapi id 15.20.4242.023; Mon, 21 Jun 2021 05:44:11 +0000 From: Hannes Tschofenig To: Wes Hardaker CC: Michael Richardson , "danish@ietf.org" Thread-Topic: Hospital use case ... RE: [Danish] Charter Text and the Problem Statement Thread-Index: AddmXA+nzA3fKYPSR1yxZ9pLOHgoyQ== Date: Mon, 21 Jun 2021 05:44:11 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ts-tracking-id: AE6D3A96A5DCA348A406D557B71A08D1.0 x-checkrecipientchecked: true Authentication-Results-Original: hardakers.net; dkim=none (message not signed) header.d=none; hardakers.net; dmarc=none action=none header.from=arm.com; x-originating-ip: [80.92.123.248] x-ms-publictraffictype: Email X-MS-Office365-Filtering-Correlation-Id: 36bc8870-45cd-41c7-b628-08d934779d56 x-ms-traffictypediagnostic: DB8PR08MB5196:|DB7PR08MB3097: X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true nodisclaimer: true x-ms-oob-tlc-oobclassifiers: OLM:9508;OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: t1Nsq7+JlyJU3d7u257UC+JKFt+SgL/l/rnbiac9NMxaUBC99kEHKSWcRTbOYh6QHRhFNkhMymHTpc3I1j+8jK+PRgHaLk+nb4ROXI6/82LRIr6oT9hP3z1AgU1sSDbCUrzn5BPOfL1eZa8CKp8+PlMgqPA65CXP/EknQ7KJQSrmQ6q2rE1K16/W6fVQ3Zw6MKdJehIcVYu36wydH/Vp+UCql+tZu7krAVGwDwH2yAffnh1uOZgc5J2DljPZCe4aiF+RoplG9dXV+2VVVDHjK6fOQj+/CYKr1AbYFU7/axaOB9IxCFdOwBrX78ZXlLG+exPvmeR6GVz8iS6VBgV0BV7foeUjOWYxJ0KBnerhuoUOp8xeL4Ujgin2NVIoWbIWrUDYaiD6zp+TukECTBtGN3n0r1W93f1Zhp/HZhTBcNkuzGT6Yr4raF4sxM1zswAjRInyqFSKK6/iECyJAOoJ7eaDVVyng+cxtL8lVIL1dTdoo/SxGHSDLCaSSWg9m+3SB3PdbutzNcKMlPK5Uiv/1SyTn38XVogcZL3oz7/yN146B/EWfpdxnLFbgbTkmXZE0dlhHPxaDy4QY3C6UoNtNU99avyxhhoVuFCQwul5RPLQ92TCt3kyWu1Iky8a2mV+yJIjGyVczq5a08L6vdEbw5+r1FSKOgr2YX56oDryP5EO9qX0L04rS6jwcDn7/sdmfBl7wNVfANkawJkEJ68om/NEAAQ6hIIusLtMGcMEe0I= X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DBBPR08MB5915.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(39850400004)(366004)(346002)(396003)(376002)(136003)(7696005)(6506007)(83380400001)(186003)(26005)(76116006)(2906002)(966005)(38100700002)(122000001)(54906003)(8676002)(66574015)(478600001)(8936002)(86362001)(66946007)(316002)(52536014)(33656002)(71200400001)(55016002)(66446008)(64756008)(9686003)(66556008)(6916009)(4326008)(66476007)(5660300002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?UK855BIlrs7UNDVHeOxJlAnXqf6RAs+TtsFu0WH377RlJ7cmpjwabdzV68d4?= =?us-ascii?Q?QeXkCLSFDobvHSgnEOD1cC9QkuGxlnWhToApmGODRk7bYIImzRZ6gvT2hsoe?= =?us-ascii?Q?sSiI0UdAoFDR2FxF8qkrJzapO0XeOaLRTBfccH6ISTOL6csROE7d7CSY9J94?= =?us-ascii?Q?/599tD+FC6o9c/sThkebJv1499KAwxIWL6RZiaRlcF0XXcZeTETok033w8RI?= =?us-ascii?Q?O5nygg6aZHz4qp0Yqybpu+Wfii6GoLHhMQwlFgURPDxe5YnJ5tVEV4lsnDQW?= =?us-ascii?Q?1Xy3uLC5SHt+WMYilArL5YMKhjlp4RRU/eCCjJ5mIKh7zfzvOZsxicePI40l?= =?us-ascii?Q?HvY7kSdiSpdTUvY+Qf/7HErheQm6RtzKeL2CBuGW7XWvqDLY8ZA8Y8P9W/EU?= =?us-ascii?Q?VaOuOeL4V5Jdp9i8F1H7qNsLKg09cC1ZgRhfIta8Qr8Nv5zwA1zlgqnp0svR?= =?us-ascii?Q?zIE+9plrnEDGYzsrXJNpCqidHVgDA9v64HUAqtbrbwaN3a5RJIMr7s0cDdlC?= =?us-ascii?Q?fbpdJJxSLsBCs/p+UyI2EnTILuFLlLFeVuDEKlHMGugr46y72YACFqeHuoa0?= =?us-ascii?Q?s1mLGc1aAABSEUmIEtvA24pmQm5ajY3Bf3kiCwXHBa3TQHYkSrINxBrt117y?= =?us-ascii?Q?/2OsGfGGCpQxvZPeOY0Y7IylEEJv/kjCbwq4KWHhfxmCkpwrA6XG7gnerIye?= =?us-ascii?Q?GhuxeO4rtKBsismqwAJiEuMP6WkQTVWGmf6zp1GYS0hKN1XLsaDR3EJErJG7?= =?us-ascii?Q?Qip6YCInwMcuWpPRE5zQqalsLY585Cw7u8BnnRpjN3jbawyTwL6RjNFk14hH?= =?us-ascii?Q?gypK35oaUQG9P1Ezj6t3aWrlqS4eg6NkZnJAugkqbPHCHTJu9GSs85K7+uhR?= =?us-ascii?Q?rI+k+HBnkcmA0QEpuRZLTkADLZyrpZRfYLS2wCyfgEGFkN4/dL29Vs1DyrVz?= =?us-ascii?Q?59GVGbzm+fCbkXNsMPTlaOJIEA6dyzxP0Au/LB3K4AoR4sIavcNSRNHT+i5D?= =?us-ascii?Q?Od2mURa6WhOugTI9ZwRxaDwTxJugkIQKT3iun8DoAXzepe2QWk1tf+MuBDnS?= =?us-ascii?Q?n8xzj8ki9dTzxt3ahdkhj3BI78Xnn9+sqKJR3surRdpfTqVJXNiSnqUPzatf?= =?us-ascii?Q?w6nhSKDSdUuYbfbTleDf4FHtztspLzTp98Ld8j9iXpQW9GIOEa7K862WgxEn?= =?us-ascii?Q?xBwJBzlrjv2LBtbrFlR0sOnMOBH3LQWbWpkRkJEiZ4lmLk3p1HT/NkwFsBTE?= =?us-ascii?Q?3l41tZmoPzzdbGkcnia1ZZXFo7dOuPG3e35TlsDOCheRr/Yh6WNz3v8iDILP?= =?us-ascii?Q?NhafPEbz2oi8ND//u+RSH/ex?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB8PR08MB5196 Original-Authentication-Results: hardakers.net; dkim=none (message not signed) header.d=none; hardakers.net; dmarc=none action=none header.from=arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: DB5EUR03FT038.eop-EUR03.prod.protection.outlook.com X-MS-Office365-Filtering-Correlation-Id-Prvs: 89033ef9-dd53-440b-c4e9-08d934779865 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 51iv1sXKeU6mWtCNUYdp39xhh+ZeYEWjk69w81b1UUy703//R5qvucbdlQnLQNzO/1ZCdYxOFyJE9ymjpOjsM8tUQpOXQfpMtEjPZeLQfaqKBvBttzCGBLOFbhK38k0iE4m2RwlSKuS1g4h+f/Mg9AapDtuSWUbpr9txeZKRQSD7hdItjzu+96Fot48l390c7WA02aFOcytIUaNeW32yfsIzqZbhzlq3lOuKr5cp3lbH5RuGNWGBdJWKpHMVeWrohjB6lJM6ieDG2vEysYMzKIoqV+U4GXdPAz3qM2oSMhF5Qy0wrcfLHVjhIXHzgFFS+pFIXuLk4PMwY7rsmltQixmkpZTd1D4UDFX10JwX19HoQh4q9vtfm1u0A+5RizV7UWj8fH44aLVHuazJqCN/4rz11nT5Jf12hbqse0k17oGyjftKDUngpeQDLz/QdZEnTOporVu1+VgZa9ECOT3shiWsT2MZOrE7dfkPaxlJqkde4UfDaF74AjBslpo/SHnnUB6DIBguhWw0D1NV6BLG2eDwZO6bP3DP/4TeNIJSc79IUGFF7CthOAIIXe254IqCO03z0IP57D0Ywyl5D1fjF89MEPDhtH8JWtiO9q7SWGQJM9DlsvOrP1fneH/1L68+0i/j7p5mjsPdREZUJAvF6lTy4Tjmw16crSvg3dOcSZwBX929BJN6FTqiLLLPUvJdatXyHUJPMtGgYgcSKikMPT3Ci+RBAOGYV/TAY5oVhtqQ2xGHyK+funV3YQABrNDHkxm7M8gnTMmSkaA32LlESQ== X-Forefront-Antispam-Report: CIP:63.35.35.123; CTRY:IE; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:64aa7808-outbound-1.mta.getcheckrecipient.com; PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; CAT:NONE; SFS:(4636009)(396003)(346002)(136003)(39850400004)(376002)(46966006)(36840700001)(55016002)(336012)(54906003)(478600001)(316002)(966005)(66574015)(70206006)(9686003)(36860700001)(2906002)(7696005)(83380400001)(33656002)(6506007)(70586007)(8936002)(8676002)(5660300002)(52536014)(86362001)(82310400003)(26005)(356005)(6862004)(186003)(4326008)(47076005)(81166007)(82740400003); DIR:OUT; SFP:1101; X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Jun 2021 05:44:19.5024 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 36bc8870-45cd-41c7-b628-08d934779d56 X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d; Ip=[63.35.35.123]; Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com] X-MS-Exchange-CrossTenant-AuthSource: DB5EUR03FT038.eop-EUR03.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR08MB3097 Archived-At: Subject: [Danish] Hospital use case ... RE: Charter Text and the Problem Statement X-BeenThere: danish@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DANE AutheNtication for Iot Service Hardening List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jun 2021 05:44:35 -0000 Hi Wes, > PS: I missed the example of onboarding a device in a hospital. https://mailarchive.ietf.org/arch/msg/danish/OkQzlyZoKlEar5-GU6HgtSz3ebY/ Thanks for the pointer to the hospital use case. Here is the relevant text: " Within a hospital, it is desirable to implement 802.1x authentication using EAP-TLS for access to protected networks. EAP-TLS enables the use of PKI-based identity to authenticate an entity for network access. When implementing EAP-TLS for network access, RADIUS is a common protocol/server used for authentication behind the switch or wireless access point. Guidance for configuring RADIUS recommends the use of only one CA certificate for authenticating supplicant certificates. This guidance can be found in the wild in Freeradius configuration files for EAP-TLS, related to the 'ca_file' configuration directive. " Network access authentication is often misunderstood. The use of TLS for ne= twork access authentication was a convenience rather than a necessity. This means that there is functionality in TLS that is neither needed nor pa= rticularly useful for network access authentication. On the web, you want to use a PKI because a browser can access many differe= nt websites. Any browser should be able to access any website, ideally. The network access authentication model is different. There you have a one-= to-one relationship. One user with their device has credentials to access o= ne home AAA server. Why is that? It has to do with authorization. The home AAA grants access to= the visiting network via the backend AAA infrastructure. Only the home AAA= server knows about the user's authorization information. In that model, there is not much benefit of a PKI. All you need is a raw pu= blic key. Why are people still using a complex PKI infrastructure for network access = authentication? Well. I fear that most network administrators don't get the= point that they do not need to model their organizational hierarchy into t= he PKI infrastructure. So, what do we do? We offer them with solutions to compress certificates, c= ache certificates, etc. (see draft-ietf-emu-eaptlscert) when the correct an= swer would be different. Hence, the guidance you are mentioning above is actually pointing in the ri= ght direction. If you go into the other direction and basically let the supplicant tap int= o your browser trust anchor store then you have actually opened up the atta= ck possibility substantially because you can make regular web server certif= icates verify correctly during the EAP-TLS authentication. Ciao Hannes IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you. From nobody Mon Jun 21 07:40: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 188FD3A08FC for ; Mon, 21 Jun 2021 07:40:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_MED=-2.3, 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 qMRLGMOJi4Ou for ; Mon, 21 Jun 2021 07:40:44 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADA1C3A08FE for ; Mon, 21 Jun 2021 07:40:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id C90AD38ADE; Mon, 21 Jun 2021 10:42:13 -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 oMf5sWqouh-r; Mon, 21 Jun 2021 10:42:11 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id AF6D738ADC; Mon, 21 Jun 2021 10:42:11 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 16F0A9E; Mon, 21 Jun 2021 10:40:39 -0400 (EDT) From: Michael Richardson To: Hannes Tschofenig , "danish\@ietf.org" In-Reply-To: References: <23295.1624134481@localhost> <5631.1624225291@localhost> 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: Re: [Danish] Charter Text and the Problem Statement X-BeenThere: danish@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DANE AutheNtication for Iot Service Hardening List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jun 2021 14:40:53 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hannes Tschofenig wrote: >> If you use DANISH, then you don't need to onboard the device >> (i.e. enroll it with a new certificate), because you already have se= cure >> access to the correct certificate via DNS(SEC). > In the past we used different keys for different purposes. A > manufacturer provided key was used for a relatively small number of > tasks (typically for obtaining operational keys). For use with > application services we used a different key. We used yet another key > for firmware updates and again another for attestation. > What has changed? As you know I'm a big proponent of using an IDevID with an onboarding protocol to obtain an LDevID. I think that this is still an important path. But, it's not the only path! While I think your next comment might be about divergent paths causing mark= et confusion, I think that we are already there. There are presently a numb= er of incompatible systems out there that deliver keys from the factory to be used in production. I think that the DANISH might be an interesting way to publish *LDevID*s. While I might onboard a device into my network, in the future, imagine that different operational networks might need to interact without having an ownership relationship. For instance, any personal wearables you might have interacting with a variety of building or vehicle systems that you are in. How will I give you permission to turn on the lights in my house? I'd surely prefer to list that authorization by DNS name, rather than hash, right? =2D- ] Never tell me the odds! | ipv6 mesh network= s [ ] Michael Richardson, Sandelman Software Works | IoT architect = [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [ =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+93Q3WUFAmDQpOYACgkQgItw+93Q 3WUySAgAry3OgrDYEHeleIOYd/v6PKICIikuTPcM4FUT0sPA33nc3FoO79nS5F4y S7ZeqG3kkv8WsZOlhARhi397G39EenJTibqoPfmwSRXnuZq/N07088AUMlyNqBzb dl99y+hqXTXf/JilxyIe3avVRHr1dT40PQXBcJ3DsK3PWDG+DyCm6EFJqA5/EUUx wx60z+NpDpMBOgoxZGaGObDMrxV+gWYON3ms8vbn2A9UQgcD4jQeY4W0NQTUvZht Mwg6YElITJgLciGhezd4HNUUHo2X2Hetavr0oUNQtjcvjGI+vRMWE2RIcU832bO/ 4KnXrSoal+TdYiHNZixcxpqIAm32WA== =kX6P -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Jun 21 07:50:22 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 7125F3A0959 for ; Mon, 21 Jun 2021 07:50:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.003 X-Spam-Level: X-Spam-Status: No, score=0.003 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 NFBkK---r0Id for ; Mon, 21 Jun 2021 07:50:09 -0700 (PDT) Received: from albina.zerospam.ca (albina.zerospam.ca [199.27.221.82]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF2013A0906 for ; Mon, 21 Jun 2021 07:50:08 -0700 (PDT) X-ZEROSPAM_FILTERED: true Received: from albina.zerospam.ca (localhost [127.0.0.1]) by albina.zerospam.ca (Postfix) with ESMTP id 4G7srb4SwyzyN4; Mon, 21 Jun 2021 10:50:07 -0400 (EDT) Authentication-Results: albina.zerospam.ca (ip=192.228.22.11); spf=none smtp.helo=mx1.cira.ca; spf=pass smtp.mailfrom=Jacques.Latour@cira.ca; dkim=none; dmarc=none (action=none) reason="No DMARC policy found" header.from=cira.ca Received: from 127.0.0.1 (127.0.0.1:12000) (original ip: 192.228.22.11) by albina.zerospam.ca (Themis) with ESMTP id zZfXJj2AiKWdJkvubS1; Mon, 21 Jun 2021 10:50:06 -0400 Received: from mx1.cira.ca (nat.crp.cira.ca [192.228.22.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by albina.zerospam.ca (Postfix) with ESMTPS id 4G7srZ11zgzyN7; Mon, 21 Jun 2021 10:50:06 -0400 (EDT) Received: from CRP-EX16-02.CORP.CIRA.CA (10.2.36.121) by CRP-EX16-02.CORP.CIRA.CA (10.2.36.121) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.2242.10; Mon, 21 Jun 2021 10:50:05 -0400 Received: from CRP-EX16-02.CORP.CIRA.CA ([fe80::c50f:56f4:1f3c:b748]) by CRP-EX16-02.CORP.CIRA.CA ([fe80::c50f:56f4:1f3c:b748%14]) with mapi id 15.01.2242.010; Mon, 21 Jun 2021 10:50:05 -0400 From: Jacques Latour To: Hannes Tschofenig , "danish@ietf.org" Thread-Topic: [EXT] RE: IoT Device Identification with TLSA via Danish Thread-Index: AddhKvcSXHMYMAB6StqY1oKWkaM4dwD3nhkgAGhz3EA= Date: Mon, 21 Jun 2021 14:50:05 +0000 Message-ID: <7847f2fef4474c2c8ab7ea1b06d2d39b@cira.ca> References: <02cb8931e16c4ccaa6eed1b89c0a20b6@cira.ca> In-Reply-To: Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_ee0e450f-d653-41c9-9b6c-2295bb19e3b2_Enabled=true; MSIP_Label_ee0e450f-d653-41c9-9b6c-2295bb19e3b2_SetDate=2021-06-21T14:50:04Z; MSIP_Label_ee0e450f-d653-41c9-9b6c-2295bb19e3b2_Method=Standard; MSIP_Label_ee0e450f-d653-41c9-9b6c-2295bb19e3b2_Name=Confidential; MSIP_Label_ee0e450f-d653-41c9-9b6c-2295bb19e3b2_SiteId=f349b30c-7550-4f17-88da-269417631f54; MSIP_Label_ee0e450f-d653-41c9-9b6c-2295bb19e3b2_ActionId=024940c3-c741-41ca-8799-fc26e14044a4; MSIP_Label_ee0e450f-d653-41c9-9b6c-2295bb19e3b2_ContentBits=2 x-originating-ip: [10.2.36.1] Content-Type: multipart/alternative; boundary="_000_7847f2fef4474c2c8ab7ea1b06d2d39bciraca_" MIME-Version: 1.0 Archived-At: Subject: Re: [Danish] [EXT] RE: IoT Device Identification with TLSA via Danish X-BeenThere: danish@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DANE AutheNtication for Iot Service Hardening List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jun 2021 14:50:21 -0000 --_000_7847f2fef4474c2c8ab7ea1b06d2d39bciraca_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Hannes, Yes, in my presentation on very first slide I said "we presented the IoT Re= gistry many times in the past at many venues", the IoT Registry for us is a= n identity management system for mobile GMSA IoT SAFE enabled IoT devices. = It's the gateway between the mobile network operators and the cloud/ASPs. * See https://github.com/CIRALabs/CIRA-Secure-IoT-Registry/blob/38c3128= 651fbfcf8a0b5bd40523cd7dc12a5bc70/CIRA%20-%202020-01-22%20ICS%20Symposium.p= df In short, in the IoT Registry we track the identity of the IoT device (publ= ic key or certificate) to a unique eSIM ID via IoT SAFE. In this context, I'm a big fan of making available in the DNS w/DNSSEC the = individual IoT device identity via the proposed DANISH mechanisms. Jacques CLASSIFICATION:CONFIDENTIAL From: Hannes Tschofenig Sent: June 19, 2021 8:51 AM To: Jacques Latour ; danish@ietf.org Subject: [EXT] RE: IoT Device Identification with TLSA via Danish Hi Jacques, Thanks for sharing your slides. Since the slides are not meant to be self-e= xplanatory I have a question for you: What is an IoT registry for you? (You mention the term on slide 2 and it seems to be core to your presentati= on.) Ciao Hannes From: Danish > On B= ehalf Of Jacques Latour Sent: Monday, June 14, 2021 4:41 PM To: danish@ietf.org Subject: [Danish] IoT Device Identification with TLSA via Danish Hi, Today I presented at the ICANN DNSSEC workshop the potential results of DAN= ISH working group which I think should include the entire scope having a mu= tual TLSA validated TLS session from an IoT device to a server. https://github.com/CIRALabs/CIRA-Secure-IoT-Registry/blob/master/CIRA%20-%2= 0Challenges%20in%20DNSSEC%20IoT%20Registry%20-%20ICANN%202021-6-14.pdf In addition, I was thinking there should be a 4th TLSA certificate usage, t= ype 0 or 4, for TLSA to show cert that are revoked, if we know for sure the= certificate is revoked then it should be presented and queried/answered as= such, an authoritative answer signed with DNSSEC to say certificate is re= voked, not to be trusted anymore. NSEC says it does not exists, this usage= would be very clear. This works for client identity, not sure for other TL= SA use cases. Jacques IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you. --_000_7847f2fef4474c2c8ab7ea1b06d2d39bciraca_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Hannes,

 

Yes, in my presentation on very first slide I said &= #8220;we presented the IoT Registry many times in the past at many venues&#= 8221;, the IoT Registry for us is an identity management system for mobile = GMSA IoT SAFE enabled IoT devices. It’s the gateway between the mobile network operators and the cloud/ASPs.

 

 

In short, in the IoT Registry we track the identity = of the IoT device (public key or certificate) to a unique eSIM ID via IoT S= AFE.

 

In this context, I’m a big fan of making avail= able in the DNS w/DNSSEC the individual IoT device identity via the propose= d DANISH mechanisms.

 

Jacques

 

 

 

 

CLASSIFICATION:CONFIDENTIAL

From: Hannes Tschofenig <Hannes.Tschofenig= @arm.com>
Sent: June 19, 2021 8:51 AM
To: Jacques Latour <Jacques.Latour@cira.ca>; danish@ietf.org Subject: [EXT] RE: IoT Device Identification with TLSA via Danish

 

Hi Jacques,

 

Thanks for sharing your slides. Since the slides are= not meant to be self-explanatory I have a question for you: What is an IoT= registry for you?

(You mention the term on slide 2 and it seems to be = core to your presentation.)

 

Ciao

Hannes

 

From: Danish <danish-bounces@ietf.org> On Behalf Of Jacques Latour
Sent: Monday, June 14, 2021 4:41 PM
To: danish@ietf.org
Subject: [Danish] IoT Device Identification with TLSA via Danish

 

Hi,

 

Today I presented at the ICANN DNSSEC workshop the p= otential results of DANISH working group which I think should include the e= ntire scope having a mutual TLSA validated TLS session from an IoT device t= o a server.

 

https://github.com/CIRALabs/CIRA-Secure-IoT-= Registry/blob/master/CIRA%20-%20Challenges%20in%20DNSSEC%20IoT%20Registry%2= 0-%20ICANN%202021-6-14.pdf

 

In addition, I was thinking there should be a 4= th TLSA certificate usage, type 0 or 4, for TLSA to show cert that ar= e revoked, if we know for sure the certificate is revoked then it should be= presented and queried/answered as such,  an authoritative answer signed with DNSSEC to say certificate = is revoked, not to be trusted anymore.  NSEC says it does not exists, = this usage would be very clear. This works for client identity, not sure fo= r other TLSA use cases.

 

Jacques

 

 

IMPORTANT NOTICE: The contents of this email and any= attachments are confidential and may also be privileged. If you are not th= e intended recipient, please notify the sender immediately and do not discl= ose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Th= ank you.

--_000_7847f2fef4474c2c8ab7ea1b06d2d39bciraca_-- From nobody Mon Jun 21 08:26:36 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 D74B33A0B17 for ; Mon, 21 Jun 2021 08:26:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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=armh.onmicrosoft.com header.b=VIxBLS+G; dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=VIxBLS+G 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 hlUbAzxkUrEK for ; Mon, 21 Jun 2021 08:26:28 -0700 (PDT) Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60056.outbound.protection.outlook.com [40.107.6.56]) (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 5AFDC3A0B13 for ; Mon, 21 Jun 2021 08:26:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=M4GJavGQuUInEkEKfHbDq/gkvMhevLtPev/82jqcUU8=; b=VIxBLS+Gh0g2Pb8eK02SGGX8IRcLUuhHQGbMTss4iKWTMEjMQhK1SPpt0WETJ0220BV0dyiBivfJxjSqK3QIjjmJHrDgDWNjZnq7J06HexPNSriOpLGIePo96FzmFbr1PyebeAbsiB3z8Z6v8XAuBRZtvPeraqp7BMW5C/tktuQ= Received: from AM6PR10CA0026.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:209:89::39) by VI1PR08MB4270.eurprd08.prod.outlook.com (2603:10a6:803:f9::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4242.15; Mon, 21 Jun 2021 15:26:21 +0000 Received: from AM5EUR03FT028.eop-EUR03.prod.protection.outlook.com (2603:10a6:209:89:cafe::28) by AM6PR10CA0026.outlook.office365.com (2603:10a6:209:89::39) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4242.16 via Frontend Transport; Mon, 21 Jun 2021 15:26:21 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; ietf.org; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com;ietf.org; dmarc=pass action=none header.from=arm.com; Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 63.35.35.123 as permitted sender) receiver=protection.outlook.com; client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com; Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by AM5EUR03FT028.mail.protection.outlook.com (10.152.16.118) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4242.16 via Frontend Transport; Mon, 21 Jun 2021 15:26:21 +0000 Received: ("Tessian outbound f88ae75fbd47:v96"); Mon, 21 Jun 2021 15:26:20 +0000 X-CR-MTA-TID: 64aa7808 Received: from 808f7c5f525d.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id E8285B66-B3BE-42E3-B2A3-63EA93A9F71B.1; Mon, 21 Jun 2021 15:26:13 +0000 Received: from EUR05-DB8-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 808f7c5f525d.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Mon, 21 Jun 2021 15:26:13 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=EGskhw721ZKtth+gvZoU4RwBOaGhG8Y8UTjCbfcKq1BxBTVEBgoMBQ8fqUsFEz5LTZ1TpNaNDBq4qI7bKkMPq6pro0+EilnPqX0dboKuCZ/V/STA7+tYfYnlZQnXBBBAHA8XPXDbyj/GKNmTs6BB0Cu1X/4LG8LjNLeg0fWXqKSqvkv+Hvu/tPr7BOGVCCO2wsBjCnxBgDYJePQBFAAd8hpI/FOBwyIPL/jlJPijcI0H4To7ZEK2aeNrDZWNXLJucWyq7ehtYiun16HHy2IMmbYgoCARVgOs3byWkhOE3j2XARN1KmWsxlbx/Gfx/Ptdz6ymdUlNguh4EpAHOrsYtQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=M4GJavGQuUInEkEKfHbDq/gkvMhevLtPev/82jqcUU8=; b=MK2ALSR+fzPovh/z1h7zGsNi2Ug8SYjwxa+Il4IFA9SzbIg4iwpD7YJsJJ8Ta/VW8XZ06dEc7SlE8UOltyky2MhsDwBz8taZemD1+Y+3OyLtvsoUFb+d/yWaScN04iU1QxCNgJcTMH7XcQGH1otzT9J7OxhkKnejtWNxSSgb0irUCO5mQI5FJf+PlBFd781zD3O1hTOuIExSKfelRDSZWVS/JMoexED34jECVVYICDNgxEpFcI08yvyt5eqUL4ks4u7wk74ctZHSanYTky2uk3pzTg7O7TabMEVqosk8FnzEtzYzO65HbUU+D/UOK/FPgT2Xvs7OzVpvkfaziHSFMw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=M4GJavGQuUInEkEKfHbDq/gkvMhevLtPev/82jqcUU8=; b=VIxBLS+Gh0g2Pb8eK02SGGX8IRcLUuhHQGbMTss4iKWTMEjMQhK1SPpt0WETJ0220BV0dyiBivfJxjSqK3QIjjmJHrDgDWNjZnq7J06HexPNSriOpLGIePo96FzmFbr1PyebeAbsiB3z8Z6v8XAuBRZtvPeraqp7BMW5C/tktuQ= Received: from DBBPR08MB5915.eurprd08.prod.outlook.com (2603:10a6:10:20d::17) by DBBPR08MB5915.eurprd08.prod.outlook.com (2603:10a6:10:20d::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4242.19; Mon, 21 Jun 2021 15:26:12 +0000 Received: from DBBPR08MB5915.eurprd08.prod.outlook.com ([fe80::69cf:4429:a804:7f41]) by DBBPR08MB5915.eurprd08.prod.outlook.com ([fe80::69cf:4429:a804:7f41%3]) with mapi id 15.20.4242.023; Mon, 21 Jun 2021 15:26:12 +0000 From: Hannes Tschofenig To: Michael Richardson , "danish@ietf.org" Thread-Topic: [Danish] Charter Text and the Problem Statement Thread-Index: Addin8Z32g6ibl9RQiW6iIvXVU0WhwAVq2gAABL3x4AAGNNDAAAroAeQAD1ePYAAGAHboAAc2eSAAA9o/EAAFC7HgAAA1Rag Date: Mon, 21 Jun 2021 15:26:12 +0000 Message-ID: References: <23295.1624134481@localhost> <5631.1624225291@localhost> <11057.1624286439@localhost> In-Reply-To: <11057.1624286439@localhost> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ts-tracking-id: 5AA1C29C7BFF864DA6E71A1F1A10EE42.0 x-checkrecipientchecked: true Authentication-Results-Original: sandelman.ca; dkim=none (message not signed) header.d=none; sandelman.ca; dmarc=none action=none header.from=arm.com; x-originating-ip: [80.92.123.248] x-ms-publictraffictype: Email X-MS-Office365-Filtering-Correlation-Id: b7704b61-f68a-4129-9350-08d934c8ec59 x-ms-traffictypediagnostic: DBBPR08MB5915:|VI1PR08MB4270: X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true nodisclaimer: true x-ms-oob-tlc-oobclassifiers: OLM:9508;OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: 24yxyVw+uplRawxAZVe542sTXPI5HOEjTI/O8EM8X7Qij83OIvi43Hyf/bnHx16AabkKCDS8qEFIEjgNHo+YrYtdND+ilm5NOzLI7K/zV8KKYnIx9kPloce//0rzopvKIlE7E1U0vaj8QB8vw8PF3AiBR6lp1nK9SEP9nsOfzoEgvLwYlQnO6sjbJvloy/2RWsvc7A3nbn52Uu6k8qaRE0nca74tVcE1q+NoVauBlwfUFSTYo80q2ns0LLGvCsn5LGa91cwFRbm2/eNjM0rPQOuBAFEp0ivkzgW8eT3gEq3JrwHch6F1YyZOBHedagguf1QS/fwld1nuSf3DnjrfUF089eUYQGt5KXJRMg7DgsebsjLel3h7G1U4yoX5XN9GlwWpfwgv/+dc8CaaoQgnRu5slvL6syPHqXYhK/Wd1HfBvlTE4gNn8YrMaJNsRWkJgCLmemKHbtD0H3lkvny3v9zkAIOgpFLt41XMo50wgQtUNfkuT6H7P2/uqX1el62Vdcf0ihR9dO2tOXyrvC+CXN+tCFAZUAtOpu/fDKA1nEdII75t88JbAEN0WWB1OfAEM5hrddI1KwNwLrUq1FZkMCLa3p13xFMAqfweRoLTUDwwSvewR+h0os69YC+KiaXymkirSU4b0tXSqRERdg9Nf45DGMc6cf0gr9UDIx99/x39c+H3RFNMESGPBURS9IGSAmhBWSuuM8Qj/q9O/EmB1YosxYrdp1mjQauJ/Q4dA/E= X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DBBPR08MB5915.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(396003)(136003)(346002)(366004)(39860400002)(376002)(52536014)(6506007)(7696005)(53546011)(26005)(38100700002)(122000001)(186003)(8936002)(966005)(5660300002)(66574015)(478600001)(86362001)(66556008)(64756008)(66446008)(66476007)(66946007)(76116006)(33656002)(83380400001)(2906002)(8676002)(110136005)(316002)(71200400001)(55016002)(9686003); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?RUlIbXlnYXRaKytpVHBXajNrTkZ2ZFVUWlV1d1d2YXA1czhqam9xK3pPaUxX?= =?utf-8?B?ZjdySzduT21kL1BPNFU2YTU4SVgvd0VXaUV6ZlVTRElBNGhDcU1RQ05BczRV?= =?utf-8?B?UVFDSjY0dzh1VFZyV3NnamNsWk1zb0g0OFFLbUhHREdCSG1UVTRBdUZjRUdP?= =?utf-8?B?NEpvM1R4RllvZHJzREZNL2gzSzdrc2pqYjVLNm84MFl2QXFZTWNNbjBsUDFC?= =?utf-8?B?TElvbldiU1oreVlUZ1Y2WFhCa3MrYllETFI4QWtLTUdIMXZOaEkvaDIwdzFJ?= =?utf-8?B?OVVXWDBCTVdneXJBUWZsMUtyZlIyMTFlcFpLeTRGc1hvR2tkZGxtWDRSMEV0?= =?utf-8?B?V1hIbERYZGVmLzFUK29Ib0RIeWVUaUNpdjlyTkkvY1BtUXBnRWU2NEdiZVpT?= =?utf-8?B?Y0lVb0F6T1JIVnRYbHQvNko3V0U0VlB4dnRpVEJhd3prZm1wcm5MMWZkVzcv?= =?utf-8?B?dDZIYVhTeHVmdzlaYndVMFN6TjBKcDJmTTlURVVjbzFCR3FWeTNiQ0NtQXBn?= =?utf-8?B?UmFLbXBsbTRHd1NKQ2FoRU5YL3UyTWFwV2Jlb3NNd1FjaEN1TEZIaFdiK3Fh?= =?utf-8?B?RWlKUEMvUmRub0xvWFZnSjd5SkRtWGoyNUdGK2E0TkNaYld3LzVhcG95TlE0?= =?utf-8?B?NlNueVpCMjN2R2VJQU1wNFl2LzFSbDBzdnp3eDZEeC9oMzBDeGVlMGJtSWZo?= =?utf-8?B?aExQMzFONWJRMkJHcExNaGx5cnZ4V0Vkd3QzV1VCMjFhV25KdHBpSFNvaXFS?= =?utf-8?B?cVh0czZzbmRta2pyMXRpd2JPODl3TmNaekJGSnhHWGtFVjQ0WEc2dmRmSEVS?= =?utf-8?B?UE5ZbmhuNlllcmdRSFpmN1hvUlc2U2dIaUx5b2RhQklnZW14SDJPTSswb2Zm?= =?utf-8?B?TDhySUNtWlZweGt0c1FGZjFGZUdGQ1R2aUNpWFF6NkNjOWRsdmhmb0dTZ3Iy?= =?utf-8?B?R0xVS2Y1b1ZNcXpzNkZ1MXlrOWdpaUQ0Q3RCalRhQ2dNR3FTSUMxMy9JbXVn?= =?utf-8?B?bmpnTzRSVGRNVlB2b1JkWnJaVko5OWVNT0RKQXRtQ0dWZ0ZLUW94MjZrZ3pY?= =?utf-8?B?SWZIaDYyZ0xRNmd6VkVPYU1uOGM0T0lQbkNTU2wvaVkyUjN5U05jNUFSRjhj?= =?utf-8?B?ZzU0Qjdid2Vsek93c2plQ09yM0RQOXdNQUFjc1NEcTh2VzBRdERZWG9HeWZ3?= =?utf-8?B?K2V2anRpSm5BWGR4OFNYY1RteEExREpLTEwyWlZUcEMxb2N3RFRRREUwMmR6?= =?utf-8?B?bzdBalEwdjZCSHhFV2ZDM1FueE0xYU1DNHF6SmZnUlhGdWVjL1JpYkVoSmhq?= =?utf-8?B?VzFvVFdIYUlwc2pXZGVMaDFQeFRyR3UzQzhuOEhQUnJ3dnFOc3pXV2FNcmhz?= =?utf-8?B?N014OXRBSUx1a2IvV3VWUDJKYlN5QVBQYmhRMnIwNHdNZGRSSzZHdGVjZ0FU?= =?utf-8?B?Y0VmRlFCY0ZDWHVxVm9sRzF1QWpSU2Z4UjliVmpoK1RCN0RhZ1hodTRQd28w?= =?utf-8?B?bVlhTXVYZ21vMGtaQWxobFo2WFhTN1BtZ2ZMZjJvbEdKSVZGakIrdUI1U3RZ?= =?utf-8?B?SFdkc2VrdGo1UEJBVDVOMitPMi8yYlZtWlh1eDNZSUFPK1pPRENWNkNGQnlF?= =?utf-8?B?akhZUUdjaW55VWRjK1dheEJWalZzOGhTNTZyZDBSSExZSnV0WmhZTitFaUlL?= =?utf-8?B?WHY5Wlc2cDJTbFdEOGM3SHhEeHRvdzhvbDdXMHM5bEt6emFLNWJpajkvNkx5?= =?utf-8?Q?GknwUgh2ubLYE3Pr0mn7Y2oeFIfebq4jQPlTFcW?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBBPR08MB5915 Original-Authentication-Results: sandelman.ca; dkim=none (message not signed) header.d=none; sandelman.ca; dmarc=none action=none header.from=arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: AM5EUR03FT028.eop-EUR03.prod.protection.outlook.com X-MS-Office365-Filtering-Correlation-Id-Prvs: 27e51cbe-f474-41a7-9099-08d934c8e71a X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: BwlRfgVepceObqVKWQrNS5b3lzdkQuBviL6FDM9pwsyrelMlxa/v2ekSlqx8Td3lsYzPfs7x115rtMoTa4iNiryd9Rc8xACmSlbcPGyX6PpqOxsZ1o+W8SZ+D3hsPeKBQZ04SFrBv4dZ05pwWSbflx8G+NKa2T5ZNAdcs31NlwtmJW/CENLxLbK3FEOB55wWw/JoT2Bb5T78VChNqA0Nw+n7OYiMk0Z2OzzQSHryH4qUR0k48cLy5gerv+pxrl7ZV2nscrfVj3qL/PU98ZgT8zv2Bym8cEHFMHFxFOyAd7hUysdyVZq9yVHbjbIMFjtK2Q/yU+rS8eFz2daCfTqpGvpr2xp372C+L76Q4HVkfIvGfu64miwZJLHeGmQtLLsDmfoFHgfofzt6FoCQuJXmt71U/y+T0OiD6MxtWDmfU3WvwAyIDg5Wy7L/azLyY4N7XvyAcD1RVT9sqGcigOTyD78E24cbyx7URscWa0/+I/KdjxeWcWSiXY/aTve5YOH6Lae37DPyRuMl4Ktq6V1NEmyE7ed/3lQ8yn8KrpTOloDX/97Dq9IAgOs5i3f9gh7/m9oT7F4g8+FhCd8AvO3DaeSmbFNAh6CKNX3foUKs/yDBNrQFtdKtkQG8U/UOjFA1/RwOi0FP0WP/g2opcd4W+8ELafvSR+OlQtQLmq3wCyRo+G8yeuH++eRuV71/E2y9e1ncIwiOtN3rPGcjc7XIt5le95pj9DOLqyjwpXqSK4N2wjLU5uU/s9FefpjiIWHrBnqqXgSO/cDdevrmahZ3ag== X-Forefront-Antispam-Report: CIP:63.35.35.123; CTRY:IE; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:64aa7808-outbound-1.mta.getcheckrecipient.com; PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; CAT:NONE; SFS:(4636009)(136003)(376002)(39860400002)(396003)(346002)(46966006)(36840700001)(70206006)(26005)(966005)(33656002)(70586007)(53546011)(336012)(6506007)(52536014)(5660300002)(8936002)(2906002)(8676002)(9686003)(55016002)(186003)(316002)(7696005)(356005)(86362001)(66574015)(82740400003)(47076005)(81166007)(82310400003)(36860700001)(110136005)(83380400001)(478600001); DIR:OUT; SFP:1101; X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Jun 2021 15:26:21.2313 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: b7704b61-f68a-4129-9350-08d934c8ec59 X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d; Ip=[63.35.35.123]; Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com] X-MS-Exchange-CrossTenant-AuthSource: AM5EUR03FT028.eop-EUR03.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR08MB4270 Archived-At: Subject: Re: [Danish] Charter Text and the Problem Statement X-BeenThere: danish@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DANE AutheNtication for Iot Service Hardening List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jun 2021 15:26:34 -0000 SGkgTWljaGFlbCwNCg0KSSB3YXMgbm90IG5lY2Vzc2FyaWx5IHRoaW5raW5nIGFib3V0IElFRUUg ODAyLjFBUiBhbmQgdGhlIHdheSBCUlNLSSB1c2VzIGl0LiBCUlNLSSBpcyBraW5kIG9mIHNwZWNp YWwgaW4gdGhlIHdheSBpdCBpcyBkZXNpZ25lZC4NCg0KSW4gZ2VuZXJhbCwgaW4gc2VjdXJpdHkg dGhlcmUgaXMgdGhlIGlkZWEgdG8gdXNlIGRpZmZlcmVudCBrZXlzIGZvciBkaWZmZXJlbnQgcHVy cG9zZXMuIElmIHRoYXQgaGFzIGNoYW5nZWQgdGhlbiBJIGNvbXBsZXRlZCBtaXNzZWQgaXQuDQoN ClJlZ2FyZGluZyB0aGUgbWFuYWdlbWVudCBvZiBhY2Nlc3Mgd2l0aCB3ZWFyYWJsZXMgYW5kIHNt YXJ0IGhvbWUgZGVwbG95bWVudHMgdXNpbmcgc3RhbmRhcmRpemVkIHByb3RvY29scyBJIHRob3Vn aHQgdGhhdCB0aGlzIGlzIHdoeSB3ZSBkaWQgYWxsIHRoZSB3b3JrIGluIEFDRS4NCg0KQ2lhbw0K SGFubmVzDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBNaWNoYWVsIFJpY2hh cmRzb24gPG1jcitpZXRmQHNhbmRlbG1hbi5jYT4NClNlbnQ6IE1vbmRheSwgSnVuZSAyMSwgMjAy MSA0OjQxIFBNDQpUbzogSGFubmVzIFRzY2hvZmVuaWcgPEhhbm5lcy5Uc2Nob2ZlbmlnQGFybS5j b20+OyBkYW5pc2hAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbRGFuaXNoXSBDaGFydGVyIFRleHQg YW5kIHRoZSBQcm9ibGVtIFN0YXRlbWVudA0KDQoNCkhhbm5lcyBUc2Nob2ZlbmlnIDxIYW5uZXMu VHNjaG9mZW5pZ0Bhcm0uY29tPiB3cm90ZToNCiAgICA+PiBJZiB5b3UgdXNlIERBTklTSCwgdGhl biB5b3UgZG9uJ3QgbmVlZCB0byBvbmJvYXJkIHRoZSBkZXZpY2UNCiAgICA+PiAoaS5lLiBlbnJv bGwgaXQgd2l0aCBhIG5ldyBjZXJ0aWZpY2F0ZSksIGJlY2F1c2UgeW91IGFscmVhZHkgaGF2ZSBz ZWN1cmUNCiAgICA+PiBhY2Nlc3MgdG8gdGhlIGNvcnJlY3QgY2VydGlmaWNhdGUgdmlhIEROUyhT RUMpLg0KDQogICAgPiBJbiB0aGUgcGFzdCB3ZSB1c2VkIGRpZmZlcmVudCBrZXlzIGZvciBkaWZm ZXJlbnQgcHVycG9zZXMuIEENCiAgICA+IG1hbnVmYWN0dXJlciBwcm92aWRlZCBrZXkgd2FzIHVz ZWQgZm9yIGEgcmVsYXRpdmVseSBzbWFsbCBudW1iZXIgb2YNCiAgICA+IHRhc2tzICh0eXBpY2Fs bHkgZm9yIG9idGFpbmluZyBvcGVyYXRpb25hbCBrZXlzKS4gRm9yIHVzZSB3aXRoDQogICAgPiBh cHBsaWNhdGlvbiBzZXJ2aWNlcyB3ZSB1c2VkIGEgZGlmZmVyZW50IGtleS4gV2UgdXNlZCB5ZXQg YW5vdGhlciBrZXkNCiAgICA+IGZvciBmaXJtd2FyZSB1cGRhdGVzIGFuZCBhZ2FpbiBhbm90aGVy IGZvciBhdHRlc3RhdGlvbi4NCg0KICAgID4gV2hhdCBoYXMgY2hhbmdlZD8NCg0KQXMgeW91IGtu b3cgSSdtIGEgYmlnIHByb3BvbmVudCBvZiB1c2luZyBhbiBJRGV2SUQgd2l0aCBhbiBvbmJvYXJk aW5nIHByb3RvY29sIHRvIG9idGFpbiBhbiBMRGV2SUQuDQpJIHRoaW5rIHRoYXQgdGhpcyBpcyBz dGlsbCBhbiBpbXBvcnRhbnQgcGF0aC4gIEJ1dCwgaXQncyBub3QgdGhlIG9ubHkgcGF0aCENCg0K V2hpbGUgSSB0aGluayB5b3VyIG5leHQgY29tbWVudCBtaWdodCBiZSBhYm91dCBkaXZlcmdlbnQg cGF0aHMgY2F1c2luZyBtYXJrZXQNCmNvbmZ1c2lvbiwgIEkgdGhpbmsgdGhhdCB3ZSBhcmUgYWxy ZWFkeSB0aGVyZS4gICBUaGVyZSBhcmUgcHJlc2VudGx5IGEgbnVtYmVyDQpvZiBpbmNvbXBhdGli bGUgc3lzdGVtcyBvdXQgdGhlcmUgdGhhdCBkZWxpdmVyIGtleXMgZnJvbSB0aGUgZmFjdG9yeSB0 byBiZSB1c2VkIGluIHByb2R1Y3Rpb24uDQoNCkkgdGhpbmsgdGhhdCB0aGUgREFOSVNIIG1pZ2h0 IGJlIGFuIGludGVyZXN0aW5nIHdheSB0byBwdWJsaXNoICpMRGV2SUQqcy4NCldoaWxlIEkgbWln aHQgb25ib2FyZCBhIGRldmljZSBpbnRvIG15IG5ldHdvcmssIGluIHRoZSBmdXR1cmUsIGltYWdp bmUgdGhhdCBkaWZmZXJlbnQgb3BlcmF0aW9uYWwgbmV0d29ya3MgbWlnaHQgbmVlZCB0byBpbnRl cmFjdCB3aXRob3V0IGhhdmluZyBhbiBvd25lcnNoaXAgcmVsYXRpb25zaGlwLiAgRm9yIGluc3Rh bmNlLCBhbnkgcGVyc29uYWwgd2VhcmFibGVzIHlvdSBtaWdodCBoYXZlIGludGVyYWN0aW5nIHdp dGggYSB2YXJpZXR5IG9mIGJ1aWxkaW5nIG9yIHZlaGljbGUgc3lzdGVtcyB0aGF0IHlvdSBhcmUg aW4uDQpIb3cgd2lsbCBJIGdpdmUgeW91IHBlcm1pc3Npb24gdG8gdHVybiBvbiB0aGUgbGlnaHRz IGluIG15IGhvdXNlPw0KSSdkIHN1cmVseSBwcmVmZXIgdG8gbGlzdCB0aGF0IGF1dGhvcml6YXRp b24gYnkgRE5TIG5hbWUsIHJhdGhlciB0aGFuIGhhc2gsIHJpZ2h0Pw0KDQotLQ0KXSAgICAgICAg ICAgICAgIE5ldmVyIHRlbGwgbWUgdGhlIG9kZHMhICAgICAgICAgICAgICAgICB8IGlwdjYgbWVz aCBuZXR3b3JrcyBbDQpdICAgTWljaGFlbCBSaWNoYXJkc29uLCBTYW5kZWxtYW4gU29mdHdhcmUg V29ya3MgICAgICAgIHwgICAgSW9UIGFyY2hpdGVjdCAgIFsNCl0gICAgIG1jckBzYW5kZWxtYW4u Y2EgIGh0dHA6Ly93d3cuc2FuZGVsbWFuLmNhLyAgICAgICAgfCAgIHJ1Ynkgb24gcmFpbHMgICAg Ww0KDQoNCg0KDQotLQ0KTWljaGFlbCBSaWNoYXJkc29uIDxtY3IrSUVURkBzYW5kZWxtYW4uY2E+ ICAgLiBvIE8gKCBJUHY2IEnDuFQgY29uc3VsdGluZyApDQogICAgICAgICAgIFNhbmRlbG1hbiBT b2Z0d2FyZSBXb3JrcyBJbmMsIE90dGF3YSBhbmQgV29ybGR3aWRlDQoNCg0KDQoNCklNUE9SVEFO VCBOT1RJQ0U6IFRoZSBjb250ZW50cyBvZiB0aGlzIGVtYWlsIGFuZCBhbnkgYXR0YWNobWVudHMg YXJlIGNvbmZpZGVudGlhbCBhbmQgbWF5IGFsc28gYmUgcHJpdmlsZWdlZC4gSWYgeW91IGFyZSBu b3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVk aWF0ZWx5IGFuZCBkbyBub3QgZGlzY2xvc2UgdGhlIGNvbnRlbnRzIHRvIGFueSBvdGhlciBwZXJz b24sIHVzZSBpdCBmb3IgYW55IHB1cnBvc2UsIG9yIHN0b3JlIG9yIGNvcHkgdGhlIGluZm9ybWF0 aW9uIGluIGFueSBtZWRpdW0uIFRoYW5rIHlvdS4NCg== From nobody Mon Jun 21 09:42:07 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 437EA3A0FD7 for ; Mon, 21 Jun 2021 09:42:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[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 BqY0N5BAYBz6 for ; Mon, 21 Jun 2021 09:42:00 -0700 (PDT) Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (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 DE8063A0FD6 for ; Mon, 21 Jun 2021 09:42:00 -0700 (PDT) Received: from smtpclient.apple (unknown [192.168.1.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by straasha.imrryr.org (Postfix) with ESMTPSA id 67D0EC99D8 for ; Mon, 21 Jun 2021 12:41:59 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) From: Viktor Dukhovni In-Reply-To: Date: Mon, 21 Jun 2021 12:41:57 -0400 Content-Transfer-Encoding: quoted-printable Reply-To: danish@ietf.org Message-Id: <84B82C84-0C88-4EF3-B21C-C4713CE968C1@dukhovni.org> References: <23295.1624134481@localhost> <5631.1624225291@localhost> To: danish@ietf.org X-Mailer: Apple Mail (2.3654.100.0.2.22) Archived-At: Subject: Re: [Danish] Charter Text and the Problem Statement X-BeenThere: danish@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DANE AutheNtication for Iot Service Hardening List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jun 2021 16:42:05 -0000 > On 21 Jun 2021, at 1:10 am, Hannes Tschofenig = wrote: >=20 > In the past we used different keys for different purposes. A = manufacturer provided key was used for a relatively small number of = tasks (typically for obtaining operational keys). For use with = application services we used a different key. We used yet another key = for firmware updates and again another for attestation. >=20 > What has changed? FWIW, nothing about DANE suggests using a single key for multiple purposes. On the contrary for server identity, DANE has a much better story than WebPKI, because the server is authenticated by port and name, not just name, which makes it easier (with DANE-EE(3)) to field a separate key for each service endpoint. If we're extending DANE to client identities, we can again create application-specific names, with a separate key for each application: _app1.device12345.example.com. IN TLSA 3 1 1 ... _app2.device12345.example.com. IN TLSA 3 1 1 ... ... Just register appropriate special-use labels for each distinct application-specific key, perhaps even multiple keys for a single application where it makes sense to have key separation. If the protocol in question is unrelated to TLS, one should consider using a new record type, other than TLSA. There may be additional data beyond the key value or digest that would be beneficial to return. --=20 --=20 Viktor. From nobody Mon Jun 21 10:01:15 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 16B863A1164 for ; Mon, 21 Jun 2021 10:01:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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=armh.onmicrosoft.com header.b=lwLW1aYH; dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=lwLW1aYH 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 U7T4EyRGLZqz for ; Mon, 21 Jun 2021 10:01:09 -0700 (PDT) Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-he1eur04on060e.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe0d::60e]) (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 DB2593A1166 for ; Mon, 21 Jun 2021 10:01:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=73rF1igt0hCx6EETYLlYvGarh8ccdUurygn5iyQwAI4=; b=lwLW1aYH7dD84vFHtFVXeBfIXug0eTa6QU4lFCmF/uzOsiJdkiBzOY2QYHkz+ij+9p4L6Rg2atFwjMcO75UwdklJINcueAkGuyCUxmZ5GHi+yI+8GR3roBbeowj8Bs8kzZH6Vf07Z5wB1O17RvPtLntATHj+1MdX9tTgmkvRQnU= Received: from AM5PR0202CA0022.eurprd02.prod.outlook.com (2603:10a6:203:69::32) by DBBPR08MB6282.eurprd08.prod.outlook.com (2603:10a6:10:20c::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4242.18; Mon, 21 Jun 2021 17:01:04 +0000 Received: from VE1EUR03FT041.eop-EUR03.prod.protection.outlook.com (2603:10a6:203:69:cafe::c4) by AM5PR0202CA0022.outlook.office365.com (2603:10a6:203:69::32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4242.21 via Frontend Transport; Mon, 21 Jun 2021 17:01:04 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; ietf.org; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com;ietf.org; dmarc=pass action=none header.from=arm.com; Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 63.35.35.123 as permitted sender) receiver=protection.outlook.com; client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com; Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by VE1EUR03FT041.mail.protection.outlook.com (10.152.19.163) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4242.16 via Frontend Transport; Mon, 21 Jun 2021 17:01:03 +0000 Received: ("Tessian outbound 7f55dcc5b33a:v96"); Mon, 21 Jun 2021 17:01:03 +0000 X-CR-MTA-TID: 64aa7808 Received: from 05992012c0b1.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id FC7FDD26-C05C-45CF-9FE5-42C0FE34172C.1; Mon, 21 Jun 2021 17:00:58 +0000 Received: from EUR02-AM5-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 05992012c0b1.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Mon, 21 Jun 2021 17:00:58 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Rxy0IX6DYdvRt8IVm3x9SElRUX3UC/ScOi1xtgso/uixsmJvg5pPnvDVFNoVYl9QQVLCwSc7xFAJCjhutRQmIEUmHy8ULl1yUSOZV392PM0xyqGkCI28tg4L0SWUmJtKoTH8+UzRMbJo20E3x7s25lgbtpfYqPnrv7OKtsWLjpLBTuVYqJaPHtyxI792NkdgatTNcvnUugc+Ep28R8eVOiaWF7UymbLLSLT+r23UpdGauePz0fxczRToR6W9h2gMR2xYrtXkDuBsyDQqu4QrpnbQI/xYI5pK2vBh46iLd/ErxKNkcQ+s+QR20amvwxQtmR81f8g7rEVwA7PCCIwkGw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=73rF1igt0hCx6EETYLlYvGarh8ccdUurygn5iyQwAI4=; b=oJ8coT48g8pABXIAnrj4rc19VHxMwUr9+PaOv3+c/9LXqBchVpmFq/U2ylWeBoH3lGClHSqtw05GTzf8nTa0iTTy1gp122JK1NICA/2Ger5UwDhb7CRDMsvN0fVdydZXIdFG2PP46VWRWzCj5hcL9m2Iwog8gL0uTMVe/e+MjSIikK7K3ac3ZeoC/q8hVpkXB/JFdYflUU4Cik2VC78VtHnluct61G129m4IiKnN6sSHbTOh5LgXdsgl9UQorDWCxx6B3sGsWhy6gJgdGVaIa+3c0JO8RQKwTjc0bXs/PnTbuWrid+Sjjy0z2+tmpM6M8pKpQJW22J9NYtARt9zqtA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=73rF1igt0hCx6EETYLlYvGarh8ccdUurygn5iyQwAI4=; b=lwLW1aYH7dD84vFHtFVXeBfIXug0eTa6QU4lFCmF/uzOsiJdkiBzOY2QYHkz+ij+9p4L6Rg2atFwjMcO75UwdklJINcueAkGuyCUxmZ5GHi+yI+8GR3roBbeowj8Bs8kzZH6Vf07Z5wB1O17RvPtLntATHj+1MdX9tTgmkvRQnU= Received: from DBBPR08MB5915.eurprd08.prod.outlook.com (2603:10a6:10:20d::17) by DB8PR08MB4108.eurprd08.prod.outlook.com (2603:10a6:10:b1::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4242.21; Mon, 21 Jun 2021 17:00:56 +0000 Received: from DBBPR08MB5915.eurprd08.prod.outlook.com ([fe80::69cf:4429:a804:7f41]) by DBBPR08MB5915.eurprd08.prod.outlook.com ([fe80::69cf:4429:a804:7f41%3]) with mapi id 15.20.4242.023; Mon, 21 Jun 2021 17:00:56 +0000 From: Hannes Tschofenig To: "danish@ietf.org" Thread-Topic: [Danish] Charter Text and the Problem Statement Thread-Index: Addin8Z32g6ibl9RQiW6iIvXVU0WhwAVq2gAABL3x4AAGNNDAAAroAeQAD1ePYAAGAHboAAc2eSAAA9o/EAAGGtIgAAAdFUg Date: Mon, 21 Jun 2021 17:00:56 +0000 Message-ID: References: <23295.1624134481@localhost> <5631.1624225291@localhost> <84B82C84-0C88-4EF3-B21C-C4713CE968C1@dukhovni.org> In-Reply-To: <84B82C84-0C88-4EF3-B21C-C4713CE968C1@dukhovni.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ts-tracking-id: 6AEC3FDA463FD148B2835BC1AEA08163.0 x-checkrecipientchecked: true Authentication-Results-Original: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=arm.com; x-originating-ip: [80.92.123.248] x-ms-publictraffictype: Email X-MS-Office365-Filtering-Correlation-Id: 624e5caa-8173-4f15-876d-08d934d62790 x-ms-traffictypediagnostic: DB8PR08MB4108:|DBBPR08MB6282: X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true nodisclaimer: true x-ms-oob-tlc-oobclassifiers: OLM:10000;OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: rCU/aS5LTiZeJsVxD0kj0aencuskdZq9bPVGj55P26dCXtzGXezzZALmlexpBHUUZN849X4ZSgR+XYxJ/9ErR9aJEoN9WFVdJwGQJtwQC5USO/PTXf31NHKMcLI/jTNmhZW1/0oAEy6eejsMIbjymHrtZc3Am0N+xAMdujsODYGL/BJFftlq8YoIqhQqK84BVC4jiFkSOZGSLtC5shKRJYRVZdsS3HrV2KwHDN/yTTWOIXJbYvUpugWs5Fh3ohmOBVI+Q6cRqBpcz8LIIt6k0JqFQnIjw5JGVwLlh8z2wqX8L2uItQyX+L87XwyqISODzJ9fp4R2Dy8+wnsY7Pb/7i28Ai9bMoup3ciwYpCzdOTLKXzwIEYaIgCcBueVg81PDPywu57Nfzhq6kevGL9gSiFYHeaBUw5J9uAcr5euOkD0DgqPz7RWYpurjeM2e0r7YZ7s5iQOKrox6IfS2QUVlyVRcm2DktMr9uHDBASpoXakM/RtiZL+AkQV5kKXAJmqb/ymJzY3nzqOA/8clUefuRx1Tu1GFBzhVSM7l0v/PEnma0jDGAPkYmr8Xu+cn7QHPGfui3MDDmkRO4jhZk6MgMLv9VX2ma871P+KEBoMRphdwmaiXUo520ldE6J6oWfamXrjpe6YONU26jnqihFRrrPLAiCF/YBrUkfXPo2TBBEctifjZ0Hko7l0JspJ52XOPBkrQQuzGlayIEUaA/MAMw0yhKyWlXCfWs7CsOCXtWo= X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DBBPR08MB5915.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(346002)(39850400004)(136003)(396003)(376002)(38100700002)(76116006)(52536014)(55016002)(83380400001)(64756008)(66446008)(71200400001)(66946007)(122000001)(5660300002)(9686003)(66556008)(66476007)(478600001)(6506007)(53546011)(86362001)(2906002)(26005)(33656002)(186003)(6916009)(7696005)(8936002)(316002)(8676002)(966005); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?Qwk+hWTOyA5+qP5Cu7Sp4p3ubPh/BoPCCj6l5s8EOdnAasiOhPnae9sCQ3AK?= =?us-ascii?Q?qSebWIpe/FeJunMPu1CKsmH0SWs4vnYmCdGHGeMlgrNEKNZtUbL4z62MnJBM?= =?us-ascii?Q?XYEYQfBN7XSQSZTBccQ3bpp62+B2fr445q2y2C+Boi7HFxlE91absu3nwCFD?= =?us-ascii?Q?sZek6i9QG/nYHWFeDKzN0kFyEpuxo9P2St5UY5kldykBvH/SDvh3E7qzrEsV?= =?us-ascii?Q?7UsW8gFHa6E6UFn+IDjQgAhc8Z8LZmH4+X7p95c+Co46JCk/PaAbJhSkiGQ3?= =?us-ascii?Q?lEpYnnl2Fc/H+Qtwxt53MFDLVyUjNvJ/hjjIGFR+9cKBqBSyQ8LeIhDY5jUx?= =?us-ascii?Q?WKbtxRrjpQUXclp8Jh1EX79NSNmpwaF/EdEBV/XxMrSRTIhdpMkUm/IC71WC?= =?us-ascii?Q?MeMEe/ytWJr2sivTMtfyYN5YvL5nS3hyN7WOTG2jUKvQu1TihE3kQ/BgJBYs?= =?us-ascii?Q?exVo0zX4ENDGqtCb0KvGCpT3LqydM7IdxUnd6WDHsiKGrwRFfXNhB5zAs42D?= =?us-ascii?Q?XUK89E1BhR3gJgcnmB5t7qES+Qhb4E7eFKs/RHFdjnkbNof57aKdoN3DrQXN?= =?us-ascii?Q?cKEq+YpkgD7tD54weDRk16W1bv+uBF1gDNETq6XZU2q6i5wCqBnhszUVGheS?= =?us-ascii?Q?YTavgbpKkN+vjmSgyYYoFAGe6ruMjholuF4tRO/FizpxST2qLbawkuTiev0d?= =?us-ascii?Q?h4/O6x0uTfBH9/7KxjcYJV3SqZF5L5cq2uNJmTNX3uqRLQI/wDs2PeOc/KTx?= =?us-ascii?Q?OuVad9b1e2wbgxnuxS4//R3AXK8rTJYbutaSBFmzziyZSioWEzYM+W8zfbvP?= =?us-ascii?Q?KPlRnP9PDYMeI9eJr+cstQtjDriz1UqG4xuiWdZVSsh8L/54EIGZ7P+rsI9L?= =?us-ascii?Q?eRlTbd7DAtzQhnljLTNVsScZ6vb81mOaJfsTonCb57La6LdHCF6bqVMgAgY/?= =?us-ascii?Q?KX+Rko7ObKu5UpEvJqjLOBU1WDfp2Q+uSwNeHw1ruSH4Pe7ddIzUbtUQC/7s?= =?us-ascii?Q?lFzK+W8WXhMEYWf2JQcC77CJSEUKGcROybeFWdMfCRVQPoSlUs6j4hIRH6nm?= =?us-ascii?Q?MgI7jG2NPv7rmGmrzssRCep7huryr+9jhcCxd547nDOOxoW607ZIy8tEC/qa?= =?us-ascii?Q?xLz07QJEcqmCOqwII91M0pSp86q+f4sNNuzI+P+9fpcW7rC4JwbhGYHtongK?= =?us-ascii?Q?atH05TvW6wWF3kGpfxGn7hMwNaPpmuSq5Z1ztCd6KLgrnFh3wJ13Vswnb0jB?= =?us-ascii?Q?bsByHgOpj1ssNIApi04Wrqb0SOxy1GGtzF0IXpQ9JkvmZoucskX02naVzedi?= =?us-ascii?Q?Zoo6lLP0V+Q7HgP46ntasuy9?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB8PR08MB4108 Original-Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: VE1EUR03FT041.eop-EUR03.prod.protection.outlook.com X-MS-Office365-Filtering-Correlation-Id-Prvs: c59e1720-ff37-49fe-38ea-08d934d62321 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 5g94eVOB//NMdz5tKFlnzHrj3E0/ANermE3D0mcFc6738CeS3qhR03iGxqICqClA667847wQjFHSG9RgRDuzMwdhSmNRtiFAuC2qd4Eivz+WSsaN0WcjNHYgb9B7E0MObneeDxXzbRXFBkgVXOiOSGFE76DN+GvPtGSyctaBDOlIuRzdD4KKYPSOG2grwTm7k1ON2UZm7gHUx6GphwRIZCSCtuGfmn0iooXmNZ0E/g+d7/5R60vMP/kT2PmP/599YazsEi8Do0a7mpoQ27QZrlX9jJrq1DWfV0y8cDLOEp/GdbwCbeUAgj8NgIxQRg/o07b5W+yQkKc94VM32KC7CKLEHMk3PXWSi2yYm9Mcg3kCkZgs1iG650/UewF5aqQWlWtFTJ6Q8RZkczFMbYwcqRkkjBq7Ff+TYTEVMfddZxo+KzREre3ttlXUK7pHnwc44tOoqzpVudQf5qZFpEt0UINrJox0BzLS0itF2bsvsEafOATlTwD0qnosR4ee9+pmKHxVkb/0IozP9crfvFnkxsPDZjLXzxmdAnVFg37eyM2XLcfWxykzLqALLroJKJSc/ydCpfAXDf4KR/pKgW+Sn15k9aSfyHHPw2gsZYj8wO9/weF4pz2iD10I/vNaxBWFYZm8JqLiYjTlW5NOLQXUONTpUhNaWTga8TcJtiQm70QUtiQNqlJGVIU3v4c6eDprBc7MzOabAESyigXoVP2cWWE07YEXHK/g/QFsGqNUna6aYcmti/Q/tDPU/Skl0RbFUeTzjAGYQvU7E73JrljLFg== X-Forefront-Antispam-Report: CIP:63.35.35.123; CTRY:IE; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:64aa7808-outbound-1.mta.getcheckrecipient.com; PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; CAT:NONE; SFS:(4636009)(39840400004)(396003)(376002)(346002)(136003)(46966006)(36840700001)(33656002)(8936002)(966005)(52536014)(86362001)(5660300002)(356005)(478600001)(82310400003)(9686003)(55016002)(2906002)(83380400001)(6916009)(7696005)(336012)(70206006)(316002)(26005)(81166007)(6506007)(36860700001)(53546011)(8676002)(70586007)(47076005)(186003); DIR:OUT; SFP:1101; X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Jun 2021 17:01:03.9515 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 624e5caa-8173-4f15-876d-08d934d62790 X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d; Ip=[63.35.35.123]; Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com] X-MS-Exchange-CrossTenant-AuthSource: VE1EUR03FT041.eop-EUR03.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBBPR08MB6282 Archived-At: Subject: Re: [Danish] Charter Text and the Problem Statement X-BeenThere: danish@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DANE AutheNtication for Iot Service Hardening List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jun 2021 17:01:14 -0000 Hi Viktor, Thanks for the clarification. What other information do you envision storing in the DNS besides the publi= c keys? Ciao Hannes PS: Btw, I don't think the comparison to WebPKI is necessary because (a) th= e WebPKI is not used in the IoT context and (b) the WebPKI focuses on serve= r certificates. -----Original Message----- From: Danish On Behalf Of Viktor Dukhovni Sent: Monday, June 21, 2021 6:42 PM To: danish@ietf.org Subject: Re: [Danish] Charter Text and the Problem Statement > On 21 Jun 2021, at 1:10 am, Hannes Tschofenig = wrote: > > In the past we used different keys for different purposes. A manufacturer= provided key was used for a relatively small number of tasks (typically fo= r obtaining operational keys). For use with application services we used a = different key. We used yet another key for firmware updates and again anoth= er for attestation. > > What has changed? FWIW, nothing about DANE suggests using a single key for multiple purposes.= On the contrary for server identity, DANE has a much better story than We= bPKI, because the server is authenticated by port and name, not just name, = which makes it easier (with DANE-EE(3)) to field a separate key for each se= rvice endpoint. If we're extending DANE to client identities, we can again create applicati= on-specific names, with a separate key for each application: _app1.device12345.example.com. IN TLSA 3 1 1 ... _app2.device12345.example.com. IN TLSA 3 1 1 ... ... Just register appropriate special-use labels for each distinct application-= specific key, perhaps even multiple keys for a single application where it = makes sense to have key separation. If the protocol in question is unrelated to TLS, one should consider using = a new record type, other than TLSA. There may be additional data beyond th= e key value or digest that would be beneficial to return. -- -- Viktor. -- Danish mailing list Danish@ietf.org https://www.ietf.org/mailman/listinfo/danish IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you. From nobody Mon Jun 21 10:20:16 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 839F63A121D for ; Mon, 21 Jun 2021 10:20:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[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 t-hKLWhlnKzF for ; Mon, 21 Jun 2021 10:20:11 -0700 (PDT) Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (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 0AB7B3A1219 for ; Mon, 21 Jun 2021 10:20:10 -0700 (PDT) Received: from smtpclient.apple (unknown [192.168.1.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by straasha.imrryr.org (Postfix) with ESMTPSA id 272ADC99E1 for ; Mon, 21 Jun 2021 13:20:09 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) From: Viktor Dukhovni In-Reply-To: Date: Mon, 21 Jun 2021 13:20:07 -0400 Content-Transfer-Encoding: quoted-printable Reply-To: danish@ietf.org Message-Id: <6A26836B-1E05-44A9-9591-99D95B5140B4@dukhovni.org> References: <23295.1624134481@localhost> <5631.1624225291@localhost> <84B82C84-0C88-4EF3-B21C-C4713CE968C1@dukhovni.org> To: danish@ietf.org X-Mailer: Apple Mail (2.3654.100.0.2.22) Archived-At: Subject: Re: [Danish] Charter Text and the Problem Statement X-BeenThere: danish@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DANE AutheNtication for Iot Service Hardening List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jun 2021 17:20:16 -0000 > On 21 Jun 2021, at 1:00 pm, Hannes Tschofenig = wrote: >=20 > What other information do you envision storing in the DNS besides the = public keys? I don't have anything specific in mind. Just noting that TLSA isn't = necessarily the only RR type to consider. New RR types can be defined where it = makes sense to do so. The TLSA RR type was intended for use with TLS (server) = endpoints, but can reasonably be extended to TLS client identities. Other use-cases may warrant a different RRtype either because the = relevant fields are different, or because one specifically wants to avoid confusion with = TLS. Of course for client identity we get special-use labels to distinguish = between different application domains, so a common RRtype is OK if the fields = (e.g. usage, selector, mtype, data) work across multiple applications. --=20 Viktor. From nobody Mon Jun 21 13:34:43 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 91DB93A1828 for ; Mon, 21 Jun 2021 13:34:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_BLOCKED=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=seicmu.onmicrosoft.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 ZbumWUO003qm for ; Mon, 21 Jun 2021 13:34:38 -0700 (PDT) Received: from USG02-CY1-obe.outbound.protection.office365.us (mail-cy1usg02on0128.outbound.protection.office365.us [23.103.209.128]) (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 E0BCE3A182B for ; Mon, 21 Jun 2021 13:34:37 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector5401; d=microsoft.com; cv=none; b=j4TxsrLiY0IvSV++YjYEM4iRaEn/G7Q4b8+QcLfLsNals/RW6XEkr62kFJtbc/cun177mGGcfkgC7RpPzJnVmG+Tst31xzz0ycpSoA5nRkwUXmOeEw77V36UPm27UL10wscSV1+2CqtfA4JSGDUfkcCavpiZiQKOzFoRKyp9R+kXV2oS5lXTTsWPuU2qtZdCdCAK8Foi5u0ALt+eAfhp6q4aR4v/rkc1qyHfQ7wvMRnizIQGTJ18ql8WE3ENDBAgTVQz8oXawEtklC0miK4wppJm/dsVhAaLMZYj5igkh9ne8rDUhYqYd6R9d60P6Y1NOHMf5g/6mBCDiEos2/gJUA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector5401; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=/nJcLDQ/b46o3mwx33bKs+mONG1TLRlby0uBUtSHpo0=; b=Nwk6rsOgbMLywuYjBCxWqHf/7jg3/e877OswC/BmxPPirroiah9ZfxFgEeExO3uehE7hysXuD7yuZmR/AVyj2RuXq8iuLDx1BYUKXmcr/Xj+WUFGRFXwObnAsq/7qBsOJlVr3ehLsrUC/p76dH7RUFXrq4rJZGuTv5pq8ChlKcqxGGtmQgF2mPeR/xHwQsUPKGjldnVVInVDBiaCz7nuz8MBp6+0VeYUGOeszfNaHkCYxm8zkljYymv7pWI5OUAH2CK1bKNGDwnSS0hJkJptItm7et4Mdwnr8Mt+eEVX/u8FpO2EQI+tjHUi8vg4f7vlBy+b1vuLleoHppuxyALo7w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cert.org; dmarc=pass action=none header.from=cert.org; dkim=pass header.d=cert.org; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=seicmu.onmicrosoft.com; s=selector1-seicmu-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=/nJcLDQ/b46o3mwx33bKs+mONG1TLRlby0uBUtSHpo0=; b=SyQMtXds2N/A+jZSbRrdOWqLch8QUt81A3BtG8xCkw/M1hdv5VbHZK7d+bgAD+yXhkR+GNGsCdOfXtWNNzlitMfyj1F8HonMzAoFKNgPuyqOYCx3dIlMhBv73iDUcz9iVAc+Skvi9ImUCtzRMbO1z+S0Jjh5h6spJn0bdwdyuhA= Received: from DM3P110MB0538.NAMP110.PROD.OUTLOOK.COM (2001:489a:200:414::9) by DM3P110MB0364.NAMP110.PROD.OUTLOOK.COM (2001:489a:200:411::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4242.19; Mon, 21 Jun 2021 20:34:36 +0000 Received: from DM3P110MB0538.NAMP110.PROD.OUTLOOK.COM ([fe80::8156:6fdb:538a:7d36]) by DM3P110MB0538.NAMP110.PROD.OUTLOOK.COM ([fe80::8156:6fdb:538a:7d36%5]) with mapi id 15.20.4242.023; Mon, 21 Jun 2021 20:34:36 +0000 From: Roman Danyliw To: Michael Richardson , "danish@ietf.org" Thread-Topic: [Danish] Proposed WG Charter Thread-Index: AQHXX580E03gRPDEhECZYF1aM+AbNqsSr+yAgAAY3ACAABmfAIAMEwLw Date: Mon, 21 Jun 2021 20:34:36 +0000 Message-ID: References: <18269.1623628404@localhost> In-Reply-To: <18269.1623628404@localhost> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: sandelman.ca; dkim=none (message not signed) header.d=none;sandelman.ca; dmarc=none action=none header.from=cert.org; x-originating-ip: [71.112.171.248] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 5427575f-012f-4819-ea2f-08d934f3fc24 x-ms-traffictypediagnostic: DM3P110MB0364: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Qu9XdKcZFrodhpKKcHgziw7QqI3QNnWVjLe9YmxX2C+AArTHhUVQ+FYqpUQGj6E/FzxjJGZRSYlXGo6Snm7uxkqsShKycXkw2Cdtne27dqKyWZiMXZQffBeBTHjDFB8CHmRD/Ql9hGCVIjCIcSwhScBdqyxoWx+2VZUfht7AMCY9vOHJT6W6q+zzI7QeNVHUDR1yPggLMhlivEdSiNhf1+iLDiy2f2qR5e2F1M3KR6Mv9cXEVuTTlBhkB2XiqTVOXawhekccELmqzkpdFAlfJjL4M7ZpN1CWJYMi3AofsbfcdPbUSaipPxVEwhkepm7WPxRp+kNGwBICE+dZL0chsbh/GLHMkrC3HH5CJYdpMaBdSYAOnDyp1XdAACuDNNuyWpo7kOcGAvrcS8w4gtyVNP82QLhG3TShTb7BtdKFGgc8bSinsuj2pG7Lg/moQI7Lbpnx6tLqQ8dXNZhVdcDv/14PudQHov6xxgm3yTv8n2iQ8WiM4oI3OBw8x9mBwbSSOpPPtbWHVlzl1ygwPM/Zu7osgoSq8RZRrd191ThCusmj7oXfytIrhB4kFh+4bWiO9LVFCVetOcSma0bVzQT6xiL3VwAOjFHMyj9rFkK/kqwMMjxHCbaCARieozwMwoayNTELXLmB1FE31ThHT7WAeJVk68LgFhIxCcO841d2fLbYmCtN/8a/F1aFLd/NZUdw x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM3P110MB0538.NAMP110.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(346002)(366004)(396003)(376002)(136003)(39850400004)(38100700002)(83380400001)(8936002)(26005)(122000001)(53546011)(6506007)(71200400001)(66574015)(55016002)(8676002)(186003)(2906002)(33656002)(110136005)(9686003)(66556008)(64756008)(966005)(66476007)(66446008)(66946007)(478600001)(5660300002)(52536014)(316002)(76116006)(7696005)(86362001)(21314003); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: c1JwaeNMcXWX1DE8hIKSKw0ZCEyKD2KQHhdoKmmB5HfhMj9OkidEEVXfA4TxEPhWpGBnrwBF79t7PHiZQ47zH5ghFHNwCftKJxTg9JoAWuegf4VbtbiDe7LtTN0EgXM5GhTwqpXUpaVBCD1HZ5XezK1DlC2FbMN61ovzwK17C6Ug478UVHOWUvt9gQ8UObBhzVMxm9fiJFIwC4OT0T11lA4FiBHT1VabFyiBOfNMsuIj2s4GrGYksbHgHbSqGuXHvXSOJMiCbhoPh+Pifo5o3cKnHLRIN1zrmO++oynCsvaX+xScH/Es+Q8Ae1By0VrvkocJlCWadVCDAK788eHbsssAwpA+gxDccJs67Q7dn9hgdJ5EL6m43AhNLaADBnMFeewvq8d0T4S033NCpHNgf5mcQw28pMp2MnK9qTbjn2sX5aTPziKh6Z3TxCJPIT61uSbIYJWjfTlZ7lKRTIWhzSkX1yRq/yhGXHMYm0BDiOSq19ibEP3rgrUh0vM+7vJd2vzt86jO8Sn4pYTRZW5wXMAg0FDzvi3ELoYu8c5wzO69VeCdIgn1vzGnpS+R4AYCPOf0VyXOFCAjsumj/+zHShK1xrfMigJTUXFjea8/dQxfFXw7GylzuiNKGhL/jFo3NtZY0Xs5FuwS4FvD9fhr58oq1qblifzojaDXTKc7Nv1r73/iMW3LrCw64tkGeA2DnQfziv0yPdnZdiZhzVotUH+LbBOVXos8p02MbQbY2z0= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: cert.org X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM3P110MB0538.NAMP110.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: 5427575f-012f-4819-ea2f-08d934f3fc24 X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Jun 2021 20:34:36.0641 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 95a9dce2-04f2-4043-995d-1ec3861911c6 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM3P110MB0364 Archived-At: Subject: Re: [Danish] Proposed WG Charter X-BeenThere: danish@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DANE AutheNtication for Iot Service Hardening List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jun 2021 20:34:43 -0000 SGkgTWljaGFlbCENCg0KVGhhbmtzIGZvciB0aGlzIHRleHQuDQoNCkp1bXBpbmcgaW4gb24gdGhp cyBlYXJseSBtZXNzYWdlIGluIHRoZSB0aHJlYWQgdG8gY29tbWVudCBvbiB0aGlzIHNsaW1tZWQg ZG93biB2ZXJzaW9uIG9mIGh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9tc2cvZGFu aXNoLzAzdFlTVHJuTFZvZUR5N0tFZF9IU1V2VmdQQS8NCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KPiBGcm9tOiBEYW5pc2ggPGRhbmlzaC1ib3VuY2VzQGlldGYub3JnPiBPbiBCZWhh bGYgT2YgTWljaGFlbCBSaWNoYXJkc29uDQo+IFNlbnQ6IFN1bmRheSwgSnVuZSAxMywgMjAyMSA3 OjUzIFBNDQo+IFRvOiBkYW5pc2hAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFtEYW5pc2hdIFBy b3Bvc2VkIFdHIENoYXJ0ZXINCj4gDQo+IA0KPiBJIHRoaW5rIHRoYXQgdGhlIGNoYXJ0ZXIgaGFz IHRvbyBtYW55IHdvcmRzIGFuZCB0b28gbWFueSBnb2Fscy4NCj4gSSBzdWdnZXN0IGxlYXZpbmcg dGhlIEROU1NFQy1sZXNzIHN0dWZmIHRvIGEgcmVjaGFydGVyLg0KPiBXaGVyZSB3YXMgdGhhdCBn aXRodWIgZm9yIHRoaXMuLi4uDQo+IA0KPiA9PT09IEkgc3VnZ2VzdCB0aGUgZm9sbG93aW5nIHNo b3J0ZXIgY2hhcnRlcg0KPiANCj4gLU9iamVjdGl2ZQ0KPiANCj4gVGhlIERBTkUgQXV0aGVOdGlj YXRpb24gZm9yIElvdCBTZXJ2aWNlIEhhcmRlbmluZyAoREFOSVNIKSBXRyBzZWVrcyB0bw0KPiBl eHRlbmQgREFORSB0byBlbmNvbXBhc3MgVExTIGNsaWVudCBhdXRoZW50aWNhdGlvbiB1c2luZyBj ZXJ0aWZpY2F0ZXMuDQo+IA0KPiBUaGUgV0cgd2lsbCBhbHNvIHVzZSBEQU5FIHRvIGVzdGFibGlz aCBpZGVudGl0aWVzIGZvciBzdG9yZSBhbmQgZm9yd2FyZCBvZg0KPiBtZXNzYWdlcyB1c2luZyBz ZW5kZXIgaWRlbnRpdGllcy4gICAgICBbYmV0dGVyIHdvcmRpbmcgc291Z2h0XQ0KDQpDb25jdXIg d2l0aCBodHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvbXNnL2RhbmlzaC94dGhoNFFY NGNmcG9kazFmdHEzS25PbVdoR0kvIHRvIHVzZSDigJxvYmplY3Qgc2VjdXJpdHnigJ0gbGFuZ3Vh Z2UgKGluc3RlYWQgb2YgbWVzc2FnZSBzZWN1cml0eSkuICBBbHNvIHJlY29tbWVuZCBtYWtpbmcg aXQgY2xlYXIgdGhhdCB0aGlzIGlzIGdlbmVyaWMgYXBwcm9hY2ggbm90IHRpZWQgdG8gYSBzcGVj aWZpYyBwcm90b2NvbCAoYW5kIGlmIHRoZXJlIGFyZSBhbnkgbGltaXRlZCBkZXBlbmRlbmNlcyBv biBtZXNzYWdlIHNlbWFudGljcyBzdWNoIGFzICJtZXNzYWdlIGNvbnRhaW5zIHRoZSBzZW5kZXIn cyBETlMgbmFtZSIgcGVyIHNsaWRlICM1MiBvZiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3Jn L21lZXRpbmcvMTEwL21hdGVyaWFscy9zbGlkZXMtMTEwLWRhbmlzaC1kYW5pc2gtYm9mLXNsaWRl cy0wMiwgY29uc2lkZXIgZW51bWVyYXRpbmcgdGhlbSB0byByZWR1Y2Ugc2NvcGUgYW5kIGltcHJv dmUgc3BlY2lmaWNpdHkgaWYgdGhpcyBsaXN0IGlzIHNob3J0KS4NCg0KSXMg4oCcaWRlbnRpdGll c+KAnSBpbiB0aGlzIGNvbnRleHQgbW9yZSB0aGFuIGEga2V5IG9yIGNlcnRpZmljYXRlPyAgSXQg d291bGQgYmUgdXNlZnVsIHRvIGRvd24tc2NvcGUvZGVmaW5lIGlkZW50aXRpZXMgc29tZXdoZXJl Lg0KDQo+IC1Qcm9ibGVtIHN0YXRlbWVudA0KDQpFZGl0b3JpYWxseSwgaXQgd291bGQgYmUgaGVs cGZ1bCB0byBoYXZlIHN5bW1ldHJ5IGJldHdlZW4gdGhlIG9iamVjdGl2ZSBhbmQgdGhlIHByb2Js ZW0gc3RhdGVtZW50OyBhbmQgY2xlYXIgZGVsaW5lYXRpb24gYmV0d2VlbiB0aGUgdHdvIGlkZW50 aWZpZWQgcHJvYmxlbXMgKHRoaXMgbWlnaHQgYWxzbyBiZSB0aGUgdGVlIG9mIGZvciBuYW1pbmcg dGhlIHR3byB1c2UgY2FzZXMpLg0KDQo+IFRoZSBwcm9jZXNzIG9mIGVzdGFibGlzaGluZyB0cnVz dCBpbiBwdWJsaWMta2V5LWF1dGhlbnRpY2F0ZWQgaWRlbnRpdHkgdHlwaWNhbGx5DQo+IGludm9s dmVzIHRoZSB1c2Ugb2YgYSBQdWJsaWMgS2V5IEluZnJhc3RydWN0dXJlIChQS0kpLCBhbmQgYSBz aGFyZWQgUEtJIHJvb3Qgb2YNCj4gdHJ1c3QgYmV0d2VlbiB0aGUgcGFydGllcyBleGNoYW5naW5n IHB1YmxpYyBrZXlzLiBBIENlcnRpZmljYXRpb24gQXV0aG9yaXR5IChDQSkNCj4gaXMgb25lIGV4 YW1wbGUgb2YgYSBQS0kgd2hpY2ggY2FuIGJlIHVzZWQgZm9yIGVzdGFibGlzaGluZyB0cnVzdCBp biBwdWJsaWMga2V5cy4NCj4gDQo+IFRoZSBETlMgbmFtZXNwYWNlLCB0b2dldGhlciB3aXRoIERO U1NFQywgZm9ybXMgdGhlIG1vc3Qgd2lkZWx5LXJlY29nbml6ZWQNCj4gbmFtZXNwYWNlIGFuZCBh dXRoZW50aWNhdGVkIGRpc2NvdmVyeSBtZWNoYW5pc20gb24gdGhlIEludGVybmV0Lg0KPiBEQU5F IGJ1aWxkcyBvbiB0aGlzIGF1dGhlbnRpY2F0ZWQgZGlzY292ZXJ5IG1lY2hhbmlzbSB0byBlbmFi bGUgcHVibGljIGtleS0NCj4gYmFzZWQgVExTIGF1dGhlbnRpY2F0aW9uIHdoaWNoIGlzIHJlc2ls aWVudCB0byBpbXBlcnNvbmF0aW9uLCBidXQgb25seSBmb3IgVExTDQo+IHNlcnZlciBpZGVudGl0 aWVzLg0KPiANCj4gSW4gcmVzcG9uc2UgdG8gdGhlIGNoYWxsZW5nZXMgcmVsYXRlZCB0byBhbWJp Z3VpdHkgYmV0d2VlbiBpZGVudGl0aWVzIGlzc3VlZCBieQ0KPiBkaWZmZXJlbnQgQ0FzLCBhcHBs aWNhdGlvbiBvd25lcnMgZnJlcXVlbnRseSBjaG9vc2UgdG8gb25ib2FyZCBJb1QgZGV2aWNlcyB0 byBhDQo+IHNpbmdsZSBwcml2YXRlIENBIHNwZWNpZmljIHRvIHRoYXQgdmVydGljYWwuDQo+IFRo aXMgY3JlYXRlcyBhIHNpbG8gZWZmZWN0IHdoZXJlIGRpZmZlcmVudCBwYXJ0cyBvZiBsYXJnZSBk ZXBsb3ltZW50IGNhbiBub3QNCj4gY29tbXVuaWNhdGUuICBGb3IgaW5zdGFuY2UgdGhlIGhlYXRp bmcgY29vbGluZyBzeXN0ZW0gb2YgYSBidWlsZGluZyBjYW4gbm90DQo+IGF1dGhlbnRpY2F0ZSB0 aGUgbGlnaHRpbmcgY29udHJvbCBzeXN0ZW0uDQo+IA0KPiBNYW55IElvVCBkZXBsb3ltZW50cyB1 c2Ugc29tZSBraW5kIG9mIG1lc3NhZ2UgYnVzIChmb3IgaW5zdGFuY2UgTVFUVCkgdG8NCj4gZXhj aGFuZ2UgZGF0YSwgYW5kIHRoZXJlIGlzIGEgc3Ryb25nIGRlc2lyZSB0byBhZGQgbWVzc2FnZS1s ZXZlbCBzZWN1cml0eQ0KPiAoTUxTKSB0byB0aGUgb2JqZWN0cyB3aGljaCBhcmUgZXhjaGFuZ2Vk LiAgV2hpbGUgdGhlcmUgaXMgVExTIGZvciBjb25uZWN0aW9uDQo+IHNlY3VyaXR5LCBpdCBkb2Vz IG5vdCBleHRlbmQgdG8gd2hhdCBpcyBjb21tdW5pY2F0ZWQgYW5kIHNvIGRvZXMgbm90IGNvbnZl eQ0KPiBhdXRob3JpdHkgdG8gbWFrZSBhIGNsYWltLCB3aGlsZSBhIE1MUyB3b3VsZCBwcm92aWRl IHRoYXQNCg0KLS0gSSBkb24ndCBrbm93IGlmIEkgZm9sbG93IGFsbCBvZiB0aGUgdXNlIGNhc2Vz IHNvIEkgd29uZGVyaW5nIGlmIGl0IHNob3VsZCBpdCBiZSBhc3N1bWVkIHRoYXQgdGhlcmUgaXMg YWx3YXlzIFRMUyBmb3IgY29tbXVuaWNhdGlvbiBzZWN1cml0eSAoaS5lLiwg4oCcd2hpbGUgdGhl cmUgbWlnaHQgYmUgVExTIGluIHVzZSBmb3IgY29ubmVjdGlvbiBzZWN1cml0eSAuLi7igJ0pDQoN Ci0tIFdoYXQgaXMgbWVhbnQgYnkg4oCcaXQgZG9lc27igJl0IGV4dGVuZCB0byB3aGF0IGlzIGNv bW11bmljYXRlZOKAnT8gIElzIGl0IHRoYXQgdGhlcmUgYXJlbuKAmXQgZW5kLXRvLWVuZCBwcm9w ZXJ0aWVzIGR1ZSB0aGUgbWlkZGxld2FyZS9tZXNzYWdlIGJ1cz8gIFJlY29tbWVuZCBzcGVsbGlu ZyB0aGlzIG91dC4NCg0KLS0gKEVkaXRvcmlhbCkgUmVjb21tZW5kIGF2b2lkIHRoZSB0ZXJtIOKA nGNsYWlt4oCdIGFzIGl0IG1pZ2h0IGJlIHBlcmNlaXZlZCBhcyBvdmVybGFwcGluZyB3aXRoIOKA nGNsYWltc+KAnSBmcm9tIHRoaW5ncyBsaWtlIE9BdXRoLg0KDQotLSAoRWRpdG9yaWFsKSBSZWNv bW1lbmQgYXZvaWRpbmcgdXNpbmcgdGhlIHRlcm0g4oCcTUxT4oCdIChwZXIgYWJvdmUsIG9iamVj dCBzZWN1cml0eSBtYWtlcyBtb3JlIHNlbnNlKSwgYnV0IGFsc28gYmVjYXVzZSBvZiBwb3NzaWJs ZSBjb25mdXNpb24gd2l0aCB0aGUgTUxTIFdHLg0KDQo+IA0KPiBBIEROUyBuYW1lIGlzIGEgdXNl ZnVsIHVuaXF1ZSBpZGVudGlmaWVyIHRvIHdoaWNoIGh1bWFucyBpbnRlcmFjdCB3aXRoIHdlbGws DQo+IGFuZCB3aGljaCBjYW4gYmUgdXNlZCAodGhhbmtzIHRvIEROU1NFQyBhbmQgREFORSkgdG8g YXR0YWNoIGEga2V5IGJ5IHdoaWNoDQo+IHRvIGF1dGhlbnRpY2F0ZSB0aGUgbWVzc2FnZSBzZW5k ZXIgaWRlbnRpdHkuDQoNClRoaXMgaXMgdHJ1ZSwgYnV0IGRvZXNu4oCZdCBzZWVtIHJlbGV2YW50 IHRvIHRoZSBwcm9ibGVtIHN0YXRlbWVudC4NCg0KPiAtU2NvcGUgb2Ygd29yaw0KDQpJJ20gbm90 IHJlY29tbWVuZGluZyBhZGRpbmcgaXQgaW4gYXMgaXQncyBhZGRpdGlvbmFsIHNjb3BlLCBidXQg RUFQLVRMUyB3YXMgbWVudGlvbmVkOg0KDQpodHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2Fy Y2gvbXNnL2RhbmlzaC8xSzZIdDZDMkt5cndSVGo0SWkzclFFN2VqQ2MvDQoNCmFuZA0KDQpodHRw czovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvbXNnL2RhbmlzaC9NVUtRSFhLWElBRUVzbkxS bklVSm45NWZabDAvDQoNCmFuZCBhbHNvIGluIHRoZSBCb0Ygc2xpZGVzLg0KDQpUaGF0IGNhbiBi ZSBmdXR1cmUgd29yayAodGhhdCBjYW4gYmUgZGlzY3Vzc2VkIGluIGEgZnV0dXJlIHJlY2hhcnRl ciBvZiBhIFdHKQ0KDQo+IERBTklTSCB3aWxsIHNwZWNpZnkgdGhlIFRMUyBzZXNzaW9uIGFuZCBt ZXNzYWdlIHNlY3VyaXR5IHVzZSBjYXNlcyBhbmQgYW4NCj4gYXJjaGl0ZWN0dXJlIGRlc2NyaWJp bmcgdGhlIHByaW1hcnkgY29tcG9uZW50cyBhbmQgaW50ZXJhY3Rpb24gcGF0dGVybnMuDQoNCk5p dC4gIElzIGEg4oCcVExTIHNlc3Npb27igJ0gdXNlIGNhc2UgdGhlIHNhbWUgYXMgREFORS1iYXNl ZCBUTFMgY2xpZW50IGF1dGhlbnRpY2F0aW9uPyAgUmVjb21tZW5kIGNvbnNpc3RlbnQgdXNlIGNh c2UgbGFuZ3VhZ2UuDQoNCj4gREFOSVNIIHdpbGwgZXN0YWJsaXNoIHVzYWdlIGNvbnZlbnRpb25z IGZvciBEQU5FIEROUyByZWNvcmRzIHRvIHJlcHJlc2VudA0KPiBjbGllbnQgaWRlbnRpdHkgZm9y IFRMUyBjb25uZWN0aW9ucyBhbmQgaG93IHRvIHBlcmZvcm0gcHVibGljIGtleSBkaXNjb3Zlcnkg Zm9yDQo+IG1lc3NhZ2Ugc2VjdXJpdHkgdXNlIGNhc2VzLCBsaWtlIHRoZSBlc3RhYmxpc2htZW50 IG9mIG1lc3NhZ2Ugc2VuZGVyIGlkZW50aXR5Lg0KDQotLSBJ4oCZbSB0cmlwcGluZyBvdmVyIHRo ZSBlZGl0b3JpYWwgY29uc3RydWN0IGhlcmUuICBJIHRoaW5rIHRoZSBzZW50ZW5jZSBzaG91bGQg c2F5IHRoYXQgdGhlIGNsaWVudCBpZGVudGl0eSDigJx1c2FnZSBjb252ZW50aW9uc+KAnSBhcHBs eSB0byBib3RoIFRMUyBjbGllbnQgYXV0aCBhbmQgb2JqZWN0IHNlY3VyaXR5LiAgVGhlIGRpc2Nv dmVyeSBtZWNoYW5pc20gYXBwbGllcyBvbmx5IHRvIHRoZSBvYmplY3Qgc2VjdXJpdHkgdXNlIGNh c2UuDQoNCi0tIElzIHRoZSBzY29wZSBtb3JlIHRoYW4gdXNhZ2UgY29udmVudGlvbnM/ICBJdCBz ZWVtcyBsaWtlIGl0IG1pZ2h0IGluY2x1ZGUgbm90IG9ubHkgdGhlIHNwZWNpZmljYXRpb24gb2Yg Y2xpZW50IHNpZGUgY3JlZGVudGlhbHMgYnV0IGFsc28gKD8pIHRoZSBvcGVyYXRpb25hbCBwcmFj dGljZXMgZm9yIHVzaW5nIHRoZW0/DQoNCj4gREFOSVNIIHdpbGwgY29vcmRpbmF0ZSB3aXRoIHRo ZSBUTFMgd29ya2luZyBncm91cCB0byBkZWZpbmUgYW55IHJlcXVpcmVkIFRMUw0KPiB2MS4zIHBy b3RvY29sIHVwZGF0ZXMgcmVxdWlyZWQgdG8gc3VwcG9ydCBjbGllbnQgYXV0aGVudGljYXRpb24g dXNpbmcgREFORS4NCj4gDQo+IHtYWFggY3Jvc3MgdGhpcyBvdXQ/DQo+IERBTklTSCB3aWxsIHN0 YW5kYXJkaXplIGEgcHJvdG9jb2wgYW5kIHNwZWNpZnkgb3BlcmF0aW9uYWwgcmVjb21tZW5kYXRp b25zDQo+IGZvciB0aGUgdXNlIG9mIFdlYiBQS0kgdG8gYXV0aGVudGljYXRlIHRoZSBkaXNjb3Zl cnkgb2YgcHJpdmF0ZSBQS0kgY2VydGlmaWNhdGVzDQo+IGFuZCB0cnVzdCBjaGFpbnMgdmlhIERB TkUgRE5TIHJlY29yZCB0eXBlcywgaW4gdGhlIGFic2VuY2Ugb2YgRE5TU0VDLCBpbg0KPiBzdXBw b3J0IG9mIHRoZSBtZXNzYWdlIHNlY3VyaXR5IHVzZSBjYXNlLiB9DQo+DQo+IFdoaWxlIG1vZGlm aWNhdGlvbnMgdG8gdGhlIGZvbGxvd2luZyBzdGFuZGFyZHMgYXJlIG5vdCB3aXRoaW4gdGhlIHNj b3BlIG9mIHRoZQ0KPiBEQU5JU0ggY2hhcnRlciwgdGhlIERBTklTSCB3b3JraW5nIGdyb3VwIHdp bGwgdGFrZSBjYXJlIHRvIGVuc3VyZSBhIHBvdGVudGlhbA0KPiBwYXRoIGZvciBpbnRlcm9wZXJh YmlsaXR5IHdpdGggdGhlIGZvbGxvd2luZyBzdGFuZGFyZHMsIGVuYWJsaW5nIHBvdGVudGlhbCBm dXR1cmUNCj4gd29yazpTTUlNRUEgKFJGQyA4MTYyKSwgUHJveHkgaGVhZGVycyAoUkZDIDcyMzkp LCBJQU5BIGVtYWlsDQo+IGF1dGhlbnRpY2F0aW9uIGhlYWRlcnMsIGFuZCBUQ1AgcHJveHkgVExW cyBzdGFuZGFyZGl6ZWQgYnkgaGFwcm94eS4NCg0KQWdyZWUgd2l0aCB0aGUgaGVscGZ1bCBmb2N1 c2VkIHByb3ZpZGVkIGJ5IHJlbW92aW5nIG9mIGFib3ZlIHBhcmFncmFwaHMuDQoNCj4gLURlbGl2 ZXJhYmxlczoNCj4gREFOSVNIIGFyY2hpdGVjdHVyZSBkb2N1bWVudA0KPiA5IG1vbnRocw0KDQpX aGVyZSBhcmUgdGhlIHVzZSBjYXNlcyBnb2luZyB0byBiZSBkb2N1bWVudGVkPyAgSXMgdGhpcyBh IOKAnERBTklTSCB1c2UgY2FzZSBhbmQgYXJjaGl0ZWN0dXJl4oCdIGRvYyBvciBkbyB3ZSBuZWVk IHR3byBkZWxpdmVyYWJsZXMgaGVyZSAodXNlIGNhc2UgYW5kIGFyY2hpdGVjdHVyZSkuICBObyBm ZWVsaW5ncyBlaXRoZXIgd2hhdCBvbiB3aGV0aGVyIG9uZSBpcyBiZXR0ZXIgdGhhbiB0d28uDQoN Cj4gREFORSBmb3IgY2xpZW50IGNlcnRpZmljYXRlcyAoY3VycmVudCBkcmFmdCkNCj4gNiBtb250 aHMNCg0K4oCcREFORSBmb3IgY2xpZW50IGNlcnRpZmljYXRlc+KAnSBhcyBhIGRlc2lnbmF0b3Ig ZG9lc27igJl0IGZvbGxvdyBmb3IgbWUgZnJvbSB0aGUgYWJvdmUgdGV4dCAoYWx0aG91Z2ggSSBy ZWFsaXplIHRoYXQgaXQgY29tZXMgZnJvbSBpbmRpdmlkdWFsIGRyYWZ0IHRleHQpLiAgIElzIHRo aXMgdGhlIGRlbGl2ZXJhYmxlIHRoYXQgYWxzbyBjb3ZlcnMgZ2V0dGluZyB0aGUga2V5cyBmb3Ig dGhlIG9iamVjdCB1c2UgY2FzZT8gIE1vc3Qgb2YgdGhlIHRleHQgYWJvdmUgZ2VuZXJpY2FsbHkg dGFsa3MgYWJvdXQgY2xpZW50IGlkZW50aXR5IGJ1dCBoZXJlIGl0J3MgZXhwbGljaXRseSBjbGll bnQgY2VydGlmaWNhdGVzIChJ4oCZZCBzdWdnZXN0IGNsYXJpdHkgYW5kIGNvbnNpc3RlbmN5KQ0K DQo+IERBTkUgZm9yIFRMUyBjbGllbnQgYXV0aGVudGljYXRpb24gKGN1cnJlbnQgZHJhZnQpDQo+ ICAgNiBtb250aHMNCg0KRmluYWxseSwgc2luY2UgdGhlcmUgYXJlIGV4aXN0aW5nIGRyYWZ0cyBo dHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1odXF1ZS10bHMtZGFuZS1jbGll bnRpZC8gYW5kIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWh1cXVlLWRh bmUtY2xpZW50LWNlcnQvLCBpcyB0aGVyZSBzdWZmaWNpZW50IGludGVyZXN0IGluIGNhbGxpbmcg dGhlbSBvdXQgYXMgc3RhcnRpbmcgcG9pbnRzIG9mIHRoZSB3b3JrPw0KDQpSZWdhcmRzLA0KUm9t YW4NCg== From nobody Mon Jun 21 14:08:43 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 18C4B3A19BC for ; Mon, 21 Jun 2021 14:08:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[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 EfwlVXtb5qkW for ; Mon, 21 Jun 2021 14:08:37 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F8D23A19AB for ; Mon, 21 Jun 2021 14:08:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id E54E338ABB; Mon, 21 Jun 2021 17:10:08 -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 H_vkM8hvBrB0; Mon, 21 Jun 2021 17:10:04 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 0E23A38A77; Mon, 21 Jun 2021 17:10:04 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 6A8E65D3; Mon, 21 Jun 2021 17:08:30 -0400 (EDT) From: Michael Richardson To: Roman Danyliw , "danish\@ietf.org" In-Reply-To: References: <18269.1623628404@localhost> 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: Re: [Danish] Proposed WG Charter X-BeenThere: danish@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DANE AutheNtication for Iot Service Hardening List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jun 2021 21:08:42 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I will put the first iteration into: https://github.com/mcr/danish-bof and then my proposed changes, and then editorial around that. I don't feel that I/we have consensus around my rewrite yet, but I'll post about that, and maybe we can agree. Roman Danyliw wrote: >> -Problem statement > Editorially, it would be helpful to have symmetry between the objecti= ve > and the problem statement; and clear delineation between the two > identified problems (this might also be the tee of for naming the two > use cases). I'm not sure I understand what you mean here. Are you saying that the text: } The WG will also use DANE to establish identities for store and forwar= d of } messages using sender identities. [better wording sought] needs to align better? >> The process of establishing trust in public-key-authenticated identi= ty typically >> involves the use of a Public Key Infrastructure (PKI), and a shared = PKI root of >> trust between the parties exchanging public keys. A Certification Au= thority (CA) >> is one example of a PKI which can be used for establishing trust in = public keys. >> >> The DNS namespace, together with DNSSEC, forms the most widely-recog= nized >> namespace and authenticated discovery mechanism on the Internet. >> DANE builds on this authenticated discovery mechanism to enable publ= ic key- >> based TLS authentication which is resilient to impersonation, but on= ly for TLS >> server identities. >> >> In response to the challenges related to ambiguity between identitie= s issued by >> different CAs, application owners frequently choose to onboard IoT d= evices to a >> single private CA specific to that vertical. >> This creates a silo effect where different parts of large deployment= can not >> communicate. For instance the heating cooling system of a building = can not >> authenticate the lighting control system. >> >> Many IoT deployments use some kind of message bus (for instance MQTT= ) to >> exchange data, and there is a strong desire to add message-level sec= urity >> (MLS) to the objects which are exchanged. While there is TLS for co= nnection >> security, it does not extend to what is communicated and so does not= convey >> authority to make a claim, while a MLS would provide that > -- I don't know if I follow all of the use cases so I wondering if it > should it be assumed that there is always TLS for communication > security (i.e., =E2=80=9Cwhile there might be TLS in use for connecti= on > security ...=E2=80=9D) Yes, that's a reasonable qualification. MQTT doesn't always require TLS. (It's shocking to me) ACE is doing a profile for it. > -- What is meant by =E2=80=9Cit doesn=E2=80=99t extend to what is com= municated=E2=80=9D? Is it > that there aren=E2=80=99t end-to-end properties due the middleware/me= ssage bus? > Recommend spelling this out. Nothing specific to MQTT: most buses have this property. > -- (Editorial) Recommend avoid the term =E2=80=9Cclaim=E2=80=9D as it= might be > perceived as overlapping with =E2=80=9Cclaims=E2=80=9D from things li= ke OAuth. The attack is that node X says that the temperature is 37C, and X is not a temperature sensor. And here I was worried you'd complain that "claim" conflicted with RATS :-) What term should we use here? They all seem conflcited to me. > -- (Editorial) Recommend avoiding using the term =E2=80=9CMLS=E2=80= =9D (per above, > object security makes more sense), but also because of possible > confusion with the MLS WG. If we are in agreement that it will all become "object security", then good. >> A DNS name is a useful unique identifier to which humans interact wi= th well, >> and which can be used (thanks to DNSSEC and DANE) to attach a key by= which >> to authenticate the message sender identity. > This is true, but doesn=E2=80=99t seem relevant to the problem statem= ent. Hmm! This is surprising. I thought that was 90% of the point of the work! >> DANISH will specify the TLS session and message security use cases a= nd an >> architecture describing the primary components and interaction patte= rns. > Nit. Is a =E2=80=9CTLS session=E2=80=9D use case the same as DANE-ba= sed TLS client > authentication? Recommend consistent use case language. okay. >> DANISH will establish usage conventions for DANE DNS records to repr= esent >> client identity for TLS connections and how to perform public key di= scovery for >> message security use cases, like the establishment of message sender= identity. > -- I=E2=80=99m tripping over the editorial construct here. I think t= he > sentence should say that the client identity =E2=80=9Cusage conventio= ns=E2=80=9D apply > to both TLS client auth and object security. The discovery mechanism > applies only to the object security use case. agreed. > -- Is the scope more than usage conventions? It seems like it might > include not only the specification of client side credentials but also > (?) the operational practices for using them? I think that the answer is yes, but can you give me an example of an operational practice that we'd be specifying? >> DANISH will coordinate with the TLS working group to define any requ= ired TLS >> v1.3 protocol updates required to support client authentication usin= g DANE. >> >> {XXX cross this out? >> DANISH will standardize a protocol and specify operational recommend= ations >> for the use of Web PKI to authenticate the discovery of private PKI = certificates >> and trust chains via DANE DNS record types, in the absence of DNSSEC= , in >> support of the message security use case. } >> >> While modifications to the following standards are not within the sc= ope of the >> DANISH charter, the DANISH working group will take care to ensure a = potential >> path for interoperability with the following standards, enabling pot= ential future >> work:SMIMEA (RFC 8162), Proxy headers (RFC 7239), IANA email >> authentication headers, and TCP proxy TLVs standardized by haproxy. > Agree with the helpful focused provided by removing of above paragrap= hs. Thank you, that's very useful. >> -Deliverables: >> DANISH architecture document >> 9 months > Where are the use cases going to be documented? Is this a =E2=80=9CD= ANISH use > case and architecture=E2=80=9D doc or do we need two deliverables her= e (use > case and architecture). No feelings either what on whether one is > better than two. I think you know how it went in RATS, and I think that it's a pattern we should repeat. I can reply to this comment afterwards to explain, as I bet 90% of people stopped reading :-) >> DANE for client certificates (current draft) >> 6 months > =E2=80=9CDANE for client certificates=E2=80=9D as a designator doesn= =E2=80=99t follow for me > from the above text (although I realize that it comes from individual > draft text). Is this the deliverable that also covers getting the > keys for the object use case? Most of the text above generically tal= ks > about client identity but here it's explicitly client certificates (I= =E2=80=99d > suggest clarity and consistency) The 1986s ITU-T police are gonna get you for even thinking that identity is other than a certificate :-) :-) :-) Expect them to show up in red Duran Duran jackets. Yes, I think that it includes the object security use case. I guess it should say, "DANE for device certificates" maybe? >> DANE for TLS client authentication (current draft) >> 6 months > Finally, since there are existing drafts > https://datatracker.ietf.org/doc/draft-huque-tls-dane-clientid/ and > https://datatracker.ietf.org/doc/draft-huque-dane-client-cert/, is > there sufficient interest in calling them out as starting points of t= he > work? I guess that's a consensus question, right? {off to run} =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+93Q3WUFAmDQ/84ACgkQgItw+93Q 3WWRzwf+PY2syoM461Nrwsm0++oPJQvpCXzadaFRKpmzD/UpuF6bqzO3lGp8GNok xL+yI4ykaC+ToSDXUFo5R8sGKv0OaE40C95Bzo2RB5/h89rJwYrfDnTH1Xw4mxfK DDDuX5pG4i7cIMqInDgRz6xs6HkTwBRPuIKxmSYX0rt9270nyBjYxh1P21GfoBTx +Dp5OCqDbQmG/iBEM5MLvivVl3KJuRUX9NsoD240maz3Ap5rLV422pof1xZp3QDE 1bFUSAH0izcdoUVo1hNfk/Vw2CFxf6d5dVUw8Xyjrxre6PzBhDFubgKO0SWhwT8Y NeKnfCPpBx3RVcyvJslyZw1LIFGoOw== =KQAk -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Jun 21 19:00:30 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 5730C3A0A62 for ; Mon, 21 Jun 2021 19:00:28 -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 BNszdmnKLOHQ for ; Mon, 21 Jun 2021 19:00:24 -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 E3AE13A0A5F for ; Mon, 21 Jun 2021 19:00:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 678C538B0D; Mon, 21 Jun 2021 22:01:55 -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 tTqntJAEI3Cc; Mon, 21 Jun 2021 22:01:53 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 7A8DA38B06; Mon, 21 Jun 2021 22:01:53 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id B39785D3; Mon, 21 Jun 2021 22:00:18 -0400 (EDT) From: Michael Richardson To: Roman Danyliw , "danish\@ietf.org" In-Reply-To: References: <18269.1623628404@localhost> 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: Re: [Danish] Proposed WG Charter X-BeenThere: danish@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DANE AutheNtication for Iot Service Hardening List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2021 02:00:28 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable So, the initial charter from June 12 is now at: https://github.com/mcr/danish-bof/commit/6c9a50804d086679c06172f085915b9d= ad7970db My proposed revised charter is at: https://github.com/mcr/danish-bof/pull/1/files?short_path=3Dd22b3d6#diff-= d22b3d6550c34594a6e2d6b2148ed17907c5d598b10f407b6fbecf07bf25ea97 In all it's github annotated Markdown glory! These are my edits this evening based upon Roman's comments earlier today. https://github.com/mcr/danish-bof/pull/2/files?short_path=3Dd22b3d6#diff-= d22b3d6550c34594a6e2d6b2148ed17907c5d598b10f407b6fbecf07bf25ea97 I would appreciate github level comments on the comments, particularly from Roman. =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+93Q3WUFAmDRRDIACgkQgItw+93Q 3WXTJAf7B+Sv0r2q7LHxITuBR0qXX7Z6pEuCHB/hyscGw05jVsT9sTU3oP/R0LAo 8PPQgn4EveS9s2/5DaASbQ95viQRoh4h2KyFt1x/HpMoEzA+qjWUQx+kcJcvzIaF McNVZzMFz90CjRBVqk14a5OSyzvhL5EEDD00v8kzMgEvubAUF1HoC2X+/GRyt1My s3xKWbNSfXPfCDXh5afSFOaDmG1RatC+stN2u3dhLjZ/Nz1FtWtQjk7M44IfnT5N wBiKU6ySjYpeIS0/o9L77oTHO9qwKK3sll40uMjeOWgcLHZY9NQtqO+K+DwbggMm nnd9ycmnWAopXiM6FDlTxToMyFSuGw== =Uubz -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Jun 22 07:40:43 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 8E38C3A277B for ; Tue, 22 Jun 2021 07:40:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 g0wVJGYaxbBd for ; Tue, 22 Jun 2021 07:40:37 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03DE33A277A for ; Tue, 22 Jun 2021 07:40:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 9D2EC38BC5 for ; Tue, 22 Jun 2021 10:42:10 -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 dtISkfToYv9D for ; Tue, 22 Jun 2021 10:42:08 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 19FF538BC3 for ; Tue, 22 Jun 2021 10:42:08 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id C247A1C6 for ; Tue, 22 Jun 2021 10:40:31 -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] revised charter text from Tuesday morning X-BeenThere: danish@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DANE AutheNtication for Iot Service Hardening List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2021 14:40:42 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi, Wes, Roman and I got together for 30 minutes to go through the changes using github. Here is the history of our work: https://github.com/mcr/danish-bof/commits/main/charter.md Read it in markdown: https://github.com/mcr/danish-bof/blob/main/charter= .md Please review this in the next week and a half and propose text either on github, or on the ML. After changing "message" security to object security, we then moved all of the object security stuff into a recharter, i.e. deleted it from the initia= l charter. {Note that we speak about device identity at the end, because one pattern is one device (a client) speaking to another device (a server).} Here is the final text: # Charter proposal for an DANISH WG =2D Name: DANE AutheNtication for Iot Service Hardening =2D Revision: 1.2.0 ## Objective The DANE AutheNtication for Iot Service Hardening (DANISH) WG seeks to extend DANE to encompass TLS client authentication using certificates or Ra= w Public Keys (RPK). ## Problem Statement The process of establishing trust in public-key-authenticated identity typically involves the use of a Public Key Infrastructure (PKI), and a shared PKI root of trust between the parties exchanging public keys. A Certification Authority (CA) is one example of a PKI which can be used for establishing trust in public keys. The DNS namespace, together with DNSSEC, forms the most widely-recognized namespace and authenticated discovery mechanism on the Internet. DANE builds on this authenticated discovery mechanism to enable public key-= based TLS authentication which is resilient to impersonation, but only for TLS server identities. What DANE did not define is how services can authenticate connecting client= s. In response to the challenges related to ambiguity between client identitie= s issued by different CAs, application owners frequently choose to onboard IoT devic= es to a single private CA specific to that vertical. This creates a silo effect where different parts of large deployment can not communicate. For instance the heating/cooling system of a building wishing to turn lights off to reduce room temperatures can not authenticate to the lighting control system. ## Scope of work DANISH will specify the TLS client authentication use case and an architecture describing the primary components and interaction patterns. DANISH will establish usage conventions for DANE DNS records to represent client identity for TLS connections. DANISH will work with the TLS working group to define any required TLS v1.3 protocol updates required to support client authentication using DANE. Future work may include using client identifiers for other tasks including = object security, or authenticating to other protocol services. The DANISH working group will take care to ensure a potential path for interoperability, enabling these potential future direct= ions. ## Deliverables: * DANISH architecture document (9 months) * DANE for device certificates (current draft) (6 months) * DANE for TLS client authentication (current draft) (6 months) =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+93Q3WUFAmDR9l8ACgkQgItw+93Q 3WVCwAf/SsEYRMrz5oNn9wLWNkon6+UiTZPvfTMsyyo+PrJTToSurMLp3Mbs9qFf HWJy4IIZ0dGdx5MGoHAIrjhsq9tfx836s20qJNwIiaNnoEfLZ5vO9l6WKev+nJKD 79UuC8ND+RX0FgJsEbAvbAPoLj4fwSziURlVNdXgTmvFXnalcWahSdUVG+DF6hxG ou5CidGv1lYNbENnAvBxwtFyWgTTaaMCDXwzd+wg0J4ppOWh8dn+QMSwjhPXQO1z 3koC3aweDp/pRq943cNVetj6WUcgr5w/buNf12jMbsLb/ixv8V6cfuAL9ftJ80d1 aWpLO0RT0RcgbvQprKkpqmMUEQSXig== =MuHf -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Jun 22 07:49:01 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 904863A27A5 for ; Tue, 22 Jun 2021 07:49:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 3TKibH9Q_kBS for ; Tue, 22 Jun 2021 07:48:56 -0700 (PDT) Received: from mail.hardakers.net (mail.hardakers.net [168.150.192.181]) (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 160843A27A3 for ; Tue, 22 Jun 2021 07:48:56 -0700 (PDT) Received: from localhost (unknown [10.0.0.3]) by mail.hardakers.net (Postfix) with ESMTPA id 83FDE246D3; Tue, 22 Jun 2021 07:48:52 -0700 (PDT) From: Wes Hardaker To: Michael Richardson Cc: danish@ietf.org References: <17670.1624372831@localhost> Date: Tue, 22 Jun 2021 07:48:52 -0700 In-Reply-To: <17670.1624372831@localhost> (Michael Richardson's message of "Tue, 22 Jun 2021 10:40:31 -0400") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [Danish] revised charter text from Tuesday morning X-BeenThere: danish@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DANE AutheNtication for Iot Service Hardening List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2021 14:49:01 -0000 Michael Richardson writes: > Please review this in the next week and a half and propose text either on > github, or on the ML. And specifically: 1. Does anyone object to this proposed path. We believe there is likely consensus on this narrowed scope and that it's unlikely a wider scope at this will achieve consensus (but the charter notes at the bottom that other future items may be possible). 2. Who is willing to: - contribute in mailing list discussions - edit drafts - review drafts Please do respond to these messages to indicate your willingness to help if DANISH is approved as a WG. -- Wes Hardaker USC/ISI From nobody Tue Jun 22 17:38:36 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 920673A2147 for ; Tue, 22 Jun 2021 17:38:35 -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 VkC826MKMRfa for ; Tue, 22 Jun 2021 17:38:30 -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 AA1523A2117 for ; Tue, 22 Jun 2021 17:38:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id C23D738CC2; Tue, 22 Jun 2021 20:40:05 -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 iF-HCCSQW-pg; Tue, 22 Jun 2021 20:40:03 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 27C8338CC1; Tue, 22 Jun 2021 20:40:03 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 4A9E4E32; Tue, 22 Jun 2021 20:38:25 -0400 (EDT) From: Michael Richardson To: Hannes Tschofenig , "danish\@ietf.org" In-Reply-To: References: <23295.1624134481@localhost> <5631.1624225291@localhost> <11057.1624286439@localhost> 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: Re: [Danish] Charter Text and the Problem Statement X-BeenThere: danish@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DANE AutheNtication for Iot Service Hardening List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jun 2021 00:38:36 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hannes Tschofenig wrote: > I was not necessarily thinking about IEEE 802.1AR and the way BRSKI > uses it. BRSKI is kind of special in the way it is designed. It's not that special, actually :-) DeviceAuthority has a similar design in their proprietary protocol. (I don't know many details, just presentations, they have NDAs) The Intel-SDO, now FIDO IoT, is also very similiar. It looks like CHIP/MATTER also arranges for an LDevID equivalent, but witho= ut a voucher. > In general, in security there is the idea to use different keys for > different purposes. If that has changed then I completed missed it. It's clearly better to do that if you can. But, _better sometimes is often the enemy of good enough_ is a proverb I've heard attributed to many cultures. Better the keypair you overuse than the factory default password you can never change, right? My hope that the TLS subcerts mechanism will allow us to operationally use different keys, while from an identity and authorization point of view, it's all one virtual key. But, first that has to get deployed ubiquitously. > Regarding the management of access with wearables and smart home > deployments using standardized protocols I thought that this is why we > did all the work in ACE. Yes, that's true. We did that all that stuff in ACE to allow the protocols and the authorizations, but the specification and onboarding of identities was specifically out of scope for ACE. You might recall that I insisted on that. I wanted to do that, because I didn't want ACE to attempt to boil the same ocean that ANIMA and others were also boiling. Here in DANISH, we can now look forward to the situation where we can use what is essentially the well-protected (in some TEEP) factory provisioned key, with the DANE based identity in the authorization list. *OR* we could have the private PKI of one operator vertical to export to DANE for interoperation with another vectical. Or some hybrid mix. What's the bottom line Hannes should take home: _billions and billions of new mbedTLS users_ :-) =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+93Q3WUFAmDSgoEACgkQgItw+93Q 3WUI/QgAjpXBE8PEYHPXB9jqGkiS5w1elwx/ni1c5gANER7lEHfzaw9jyqZLbuCz sJTet931VEE/l4W6VNG4BloTtgvO2/YBlo3avYd+3qc+ojCNFXS2OCZZjZF/uJfC LLNFIBl9uR8Ep8zC0Sqe5jMHpD98+8pm+pHElGhyXnM6lgTcgcKNqTs49AXq+eMD kbvW1AtWOnmtMaHNA/qwn2qQ1VjS2+lRaqXt2w79yaR87rW4bCU7lMXZh4MM3GQk wHoSOrYEXPrb2Mw+lGTzWD0HJs8sHIEUYOwxFDZJ+lVE4O3E7S6qE0djBScVYgId EOuElClYsQEoUh6uuMumOY7d2EZD7g== =ku2O -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Jun 24 13:07: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 E81223A2996 for ; Thu, 24 Jun 2021 13:07:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.188 X-Spam-Level: X-Spam-Status: No, score=-4.188 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, UNPARSEABLE_RELAY=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 Gh-zoxHl_JHn for ; Thu, 24 Jun 2021 13:07:46 -0700 (PDT) Received: from nestor.zerospam.ca (nestor.zerospam.ca [209.172.38.88]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18CDF3A2994 for ; Thu, 24 Jun 2021 13:07:45 -0700 (PDT) X-ZEROSPAM_FILTERED: true Received: from nestor.zerospam.ca (localhost [127.0.0.1]) by nestor.zerospam.ca (Postfix) with ESMTP id 4G9rlh0Lchz8sWY; Thu, 24 Jun 2021 16:07:44 -0400 (EDT) Authentication-Results: nestor.zerospam.ca (ip=192.228.22.11); spf=none smtp.helo=mx1.cira.ca; spf=pass smtp.mailfrom=Jacques.Latour@cira.ca; dkim=none; dmarc=none (action=none) reason="No DMARC policy found" header.from=cira.ca Received: from 127.0.0.1 (127.0.0.1:12000) (original ip: 192.228.22.11) by nestor.zerospam.ca (Themis) with ESMTP id skuqLMuo2PevpK1yCBp; Thu, 24 Jun 2021 16:07:41 -0400 Received: from mx1.cira.ca (nat.crp.cira.ca [192.228.22.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by nestor.zerospam.ca (Postfix) with ESMTPS id 4G9rld46F4z8sWm; Thu, 24 Jun 2021 16:07:41 -0400 (EDT) Received: from CRP-EX16-02.CORP.CIRA.CA (10.2.36.121) by CRP-EX16-01.CORP.CIRA.CA (10.2.36.120) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.2242.10; Thu, 24 Jun 2021 16:07:40 -0400 Received: from CRP-EX16-02.CORP.CIRA.CA ([fe80::c50f:56f4:1f3c:b748]) by CRP-EX16-02.CORP.CIRA.CA ([fe80::c50f:56f4:1f3c:b748%14]) with mapi id 15.01.2242.010; Thu, 24 Jun 2021 16:07:40 -0400 From: Jacques Latour To: Michael Richardson , Roman Danyliw , "danish@ietf.org" Thread-Topic: [Danish] Proposed WG Charter Thread-Index: AQHXZwpimiTIhpz3QUe5h0WPSBMEFKsjlnrw Date: Thu, 24 Jun 2021 20:07:40 +0000 Message-ID: <8236b61aa6d64f3db5e23b5345730dbf@cira.ca> References: <18269.1623628404@localhost> <18462.1624327218@localhost> In-Reply-To: <18462.1624327218@localhost> Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_ee0e450f-d653-41c9-9b6c-2295bb19e3b2_Enabled=true; MSIP_Label_ee0e450f-d653-41c9-9b6c-2295bb19e3b2_SetDate=2021-06-24T20:07:39Z; MSIP_Label_ee0e450f-d653-41c9-9b6c-2295bb19e3b2_Method=Standard; MSIP_Label_ee0e450f-d653-41c9-9b6c-2295bb19e3b2_Name=Confidential; MSIP_Label_ee0e450f-d653-41c9-9b6c-2295bb19e3b2_SiteId=f349b30c-7550-4f17-88da-269417631f54; MSIP_Label_ee0e450f-d653-41c9-9b6c-2295bb19e3b2_ActionId=dc02ece4-feb6-4cd1-b5ed-80c25830ae4e; MSIP_Label_ee0e450f-d653-41c9-9b6c-2295bb19e3b2_ContentBits=2 x-originating-ip: [10.2.36.1] Content-Type: multipart/alternative; boundary="_000_8236b61aa6d64f3db5e23b5345730dbfciraca_" MIME-Version: 1.0 Archived-At: Subject: Re: [Danish] Proposed WG Charter X-BeenThere: danish@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DANE AutheNtication for Iot Service Hardening List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jun 2021 20:07:51 -0000 --_000_8236b61aa6d64f3db5e23b5345730dbfciraca_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCg0KDQoiSW4gcmVzcG9uc2UgdG8gdGhlIGNoYWxsZW5nZXMgcmVsYXRlZCB0byBhbWJp Z3VpdHkgYmV0d2VlbiBjbGllbnQgaWRlbnRpdGllcyBpc3N1ZWQgYnkgZGlmZmVyZW50IENBcywg YXBwbGljYXRpb24gb3duZXJzIGZyZXF1ZW50bHkgY2hvb3NlIHRvIG9uYm9hcmQgSW9UIGRldmlj ZXMgdG8gYSBzaW5nbGUgcHJpdmF0ZSBDQSBzcGVjaWZpYyB0byB0aGF0IHZlcnRpY2FsLiBUaGlz IGNyZWF0ZXMgYSBzaWxvIGVmZmVjdCB3aGVyZSBkaWZmZXJlbnQgcGFydHMgb2YgbGFyZ2UgZGVw bG95bWVudCBjYW4gbm90IGNvbW11bmljYXRlLiBGb3IgaW5zdGFuY2UgdGhlIGhlYXRpbmcvY29v bGluZyBzeXN0ZW0gb2YgYSBidWlsZGluZyB3aXNoaW5nIHRvIHR1cm4gbGlnaHRzIG9mZiB0byBy ZWR1Y2Ugcm9vbSB0ZW1wZXJhdHVyZXMgY2FuIG5vdCBhdXRoZW50aWNhdGUgdG8gdGhlIGxpZ2h0 aW5nIGNvbnRyb2wgc3lzdGVtLg0KDQoNCg0KVGhpcyBkb2VzIG5vdCByZXNvbmF0ZSB3aXRoIG1l IHlldCAiIFRoaXMgY3JlYXRlcyBhIHNpbG8gZWZmZWN0IHdoZXJlIGRpZmZlcmVudCBwYXJ0cyBv ZiBsYXJnZSBkZXBsb3ltZW50IGNhbiBub3QgY29tbXVuaWNhdGUuICIgSSB0aGluayB0aGUgcHJv YmxlbSBpcyB0aGF0IGVhY2ggc2lsbyBjYW5ub3QgYXV0aGVudGljYXRlIGVhY2ggb3RoZXIgaW4g dHJ1c3RlZCBtYW5uZXIsICBpZiBJb1QgZGV2aWNlIGNvbXBhbnkgQSBrbm93cyBpdCdzIGFsbG93 IHR1cm4gdGhlIGxpZ2h0IHN3aXRjaCBvbiBJb1QgZGV2aWNlIGNvbXBhbnkgQiB3aGVuIHRoZSBz dW4gc2V0cywgdGhlbiB0aGVyZSdzIG5vIG1lY2hhbmlzbSB0b2RheSB0byBhdXRoZW50aWNhdGUg dGhlbXNlbHZlcyB3aXRoIGEgdW5pcXVlIGlkZW50aXR5Py4uLiAgIGFuZCB0aGVyZSBuZWVkcyB0 byBiZSBhIGNvbnRyb2wgc3lzdGVtIHNvbWV3aGVyZSB0aGF0IHNheXMgSW9UIGRldmljZSBBIGNh biBjb250cm9sIElvVCBkZXZpY2UgQiwgdGhhdCBjb250cm9scyBzeXN0ZW0gdG9kYXkgYWxzbyBu ZWVkIHRvIGF1dGhlbnRpY2F0ZSB0aGUgSW9UIGRldmljZXMuLi4uDQoNCg0KDQpJdCdzIGNsZWFy ZXIgaW4gbXkgaGVhZCB0aGFuIG9uIHRoZSBlbWFpbC4uLiDimLkNCg0KDQoNCkphY2sNCg0KDQoN Cg0KDQoNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KDQo+IEZyb206IERhbmlzaCA8 ZGFuaXNoLWJvdW5jZXNAaWV0Zi5vcmc+IE9uIEJlaGFsZiBPZiBNaWNoYWVsIFJpY2hhcmRzb24N Cg0KPiBTZW50OiBKdW5lIDIxLCAyMDIxIDEwOjAwIFBNDQoNCj4gVG86IFJvbWFuIERhbnlsaXcg PHJkZEBjZXJ0Lm9yZz47IGRhbmlzaEBpZXRmLm9yZw0KDQo+IFN1YmplY3Q6IFJlOiBbRGFuaXNo XSBQcm9wb3NlZCBXRyBDaGFydGVyDQoNCj4NCg0KPg0KDQo+IFNvLCB0aGUgaW5pdGlhbCBjaGFy dGVyIGZyb20gSnVuZSAxMiBpcyBub3cgYXQ6DQoNCj4NCg0KPiAgIGh0dHBzOi8vZ2l0aHViLmNv bS9tY3IvZGFuaXNoLTxodHRwczovL2dpdGh1Yi5jb20vbWNyL2RhbmlzaC1ib2YvY29tbWl0LzZj OWE1MDgwNGQwODY2NzljMDYxNzJmMDg1OTE1YjlkYWQ3OTcwZGI+DQoNCj4gYm9mL2NvbW1pdC82 YzlhNTA4MDRkMDg2Njc5YzA2MTcyZjA4NTkxNWI5ZGFkNzk3MGRiPGh0dHBzOi8vZ2l0aHViLmNv bS9tY3IvZGFuaXNoLWJvZi9jb21taXQvNmM5YTUwODA0ZDA4NjY3OWMwNjE3MmYwODU5MTViOWRh ZDc5NzBkYj4NCg0KPg0KDQo+IE15IHByb3Bvc2VkIHJldmlzZWQgY2hhcnRlciBpcyBhdDoNCg0K PiAgIGh0dHBzOi8vZ2l0aHViLmNvbS9tY3IvZGFuaXNoLWJvZi9wdWxsLzEvZmlsZXM/c2hvcnRf cGF0aD1kMjJiM2Q2I2RpZmYtPGh0dHBzOi8vZ2l0aHViLmNvbS9tY3IvZGFuaXNoLWJvZi9wdWxs LzEvZmlsZXM/c2hvcnRfcGF0aD1kMjJiM2Q2I2RpZmYtZDIyYjNkNjU1MGMzNDU5NGE2ZTJkNmIy MTQ4ZWQxNzkwN2M1ZDU5OGIxMGY0MDdiNmZiZWNmMDdiZjI1ZWE5Nz4NCg0KPiBkMjJiM2Q2NTUw YzM0NTk0YTZlMmQ2YjIxNDhlZDE3OTA3YzVkNTk4YjEwZjQwN2I2ZmJlY2YwN2JmMjVlYTk3PGh0 dHBzOi8vZ2l0aHViLmNvbS9tY3IvZGFuaXNoLWJvZi9wdWxsLzEvZmlsZXM/c2hvcnRfcGF0aD1k MjJiM2Q2I2RpZmYtZDIyYjNkNjU1MGMzNDU5NGE2ZTJkNmIyMTQ4ZWQxNzkwN2M1ZDU5OGIxMGY0 MDdiNmZiZWNmMDdiZjI1ZWE5Nz4NCg0KPg0KDQo+IEluIGFsbCBpdCdzIGdpdGh1YiBhbm5vdGF0 ZWQgTWFya2Rvd24gZ2xvcnkhDQoNCj4NCg0KPiBUaGVzZSBhcmUgbXkgZWRpdHMgdGhpcyBldmVu aW5nIGJhc2VkIHVwb24gUm9tYW4ncyBjb21tZW50cyBlYXJsaWVyIHRvZGF5Lg0KDQo+DQoNCj4g ICBodHRwczovL2dpdGh1Yi5jb20vbWNyL2RhbmlzaC1ib2YvcHVsbC8yL2ZpbGVzP3Nob3J0X3Bh dGg9ZDIyYjNkNiNkaWZmLTxodHRwczovL2dpdGh1Yi5jb20vbWNyL2RhbmlzaC1ib2YvcHVsbC8y L2ZpbGVzP3Nob3J0X3BhdGg9ZDIyYjNkNiNkaWZmLWQyMmIzZDY1NTBjMzQ1OTRhNmUyZDZiMjE0 OGVkMTc5MDdjNWQ1OThiMTBmNDA3YjZmYmVjZjA3YmYyNWVhOTc+DQoNCj4gZDIyYjNkNjU1MGMz NDU5NGE2ZTJkNmIyMTQ4ZWQxNzkwN2M1ZDU5OGIxMGY0MDdiNmZiZWNmMDdiZjI1ZWE5NzxodHRw czovL2dpdGh1Yi5jb20vbWNyL2RhbmlzaC1ib2YvcHVsbC8yL2ZpbGVzP3Nob3J0X3BhdGg9ZDIy YjNkNiNkaWZmLWQyMmIzZDY1NTBjMzQ1OTRhNmUyZDZiMjE0OGVkMTc5MDdjNWQ1OThiMTBmNDA3 YjZmYmVjZjA3YmYyNWVhOTc+DQoNCj4NCg0KPiBJIHdvdWxkIGFwcHJlY2lhdGUgZ2l0aHViIGxl dmVsIGNvbW1lbnRzIG9uIHRoZSBjb21tZW50cywgcGFydGljdWxhcmx5IGZyb20NCg0KPiBSb21h bi4NCg0KPg0KDQo+IC0tDQoNCj4gTWljaGFlbCBSaWNoYXJkc29uIDxtY3IrSUVURkBzYW5kZWxt YW4uY2E8bWFpbHRvOm1jcitJRVRGQHNhbmRlbG1hbi5jYT4+ICAgLiBvIE8gKCBJUHY2IEnDuFQg Y29uc3VsdGluZyApDQoNCj4gICAgICAgICAgICBTYW5kZWxtYW4gU29mdHdhcmUgV29ya3MgSW5j LCBPdHRhd2EgYW5kIFdvcmxkd2lkZQ0KDQo+DQoNCj4NCg0KPg0KDQoNCg0KDQpDTEFTU0lGSUNB VElPTjpDT05GSURFTlRJQUwNCg== --_000_8236b61aa6d64f3db5e23b5345730dbfciraca_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiU2Vnb2UgVUkgRW1vamkiOw0KCXBhbm9z ZS0xOjIgMTEgNSAyIDQgMiA0IDIgMiAzO30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1z b05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJZm9u dC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxp bmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjoj MDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29QbGFpblRleHQsIGxp Lk1zb1BsYWluVGV4dCwgZGl2Lk1zb1BsYWluVGV4dA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJbXNvLXN0eWxlLWxpbms6IlBsYWluIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBjbTsNCglmb250 LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4u UGxhaW5UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiUGxhaW4gVGV4dCBDaGFyIjsNCgltc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlBsYWluIFRleHQiOw0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnAubXNpcGZvb3RlcjU3MzAzNmI1LCBsaS5t c2lwZm9vdGVyNTczMDM2YjUsIGRpdi5tc2lwZm9vdGVyNTczMDM2YjUNCgl7bXNvLXN0eWxlLW5h bWU6bXNpcGZvb3RlcjU3MzAzNmI1Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdp bi1yaWdodDowY207DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6 MGNtOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2Vy aWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjENCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtY29tcG9z ZTt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250 LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBw dDsNCgltYXJnaW46NzIuMHB0IDEyOS43NXB0IDcyLjBwdCAxMjkuN3B0O30NCmRpdi5Xb3JkU2Vj dGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28g OV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+ DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5 b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9v OnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4t VVMiIGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0RjcyIiBzdHlsZT0id29yZC13cmFwOmJyZWFr LXdvcmQiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPkhpLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFu Zz0iRU4tQ0EiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPjxzcGFuIGxhbmc9IkVOLUNBIj4mcXVvdDs8L3NwYW4+SW4gcmVzcG9uc2UgdG8gdGhl IGNoYWxsZW5nZXMgcmVsYXRlZCB0byBhbWJpZ3VpdHkgYmV0d2VlbiBjbGllbnQgaWRlbnRpdGll cyBpc3N1ZWQgYnkgZGlmZmVyZW50IENBcywgYXBwbGljYXRpb24gb3duZXJzIGZyZXF1ZW50bHkg Y2hvb3NlIHRvIG9uYm9hcmQgSW9UIGRldmljZXMgdG8gYSBzaW5nbGUgcHJpdmF0ZSBDQSBzcGVj aWZpYyB0byB0aGF0IHZlcnRpY2FsLg0KIFRoaXMgY3JlYXRlcyBhIHNpbG8gZWZmZWN0IHdoZXJl IGRpZmZlcmVudCBwYXJ0cyBvZiBsYXJnZSBkZXBsb3ltZW50IGNhbiBub3QgY29tbXVuaWNhdGUu IEZvciBpbnN0YW5jZSB0aGUgaGVhdGluZy9jb29saW5nIHN5c3RlbSBvZiBhIGJ1aWxkaW5nIHdp c2hpbmcgdG8gdHVybiBsaWdodHMgb2ZmIHRvIHJlZHVjZSByb29tIHRlbXBlcmF0dXJlcyBjYW4g bm90IGF1dGhlbnRpY2F0ZSB0byB0aGUgbGlnaHRpbmcgY29udHJvbCBzeXN0ZW0uPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPlRoaXMgZG9lcyBub3QgcmVzb25hdGUgd2l0aCBtZSB5ZXQg JnF1b3Q7IFRoaXMgY3JlYXRlcyBhIHNpbG8gZWZmZWN0IHdoZXJlIGRpZmZlcmVudCBwYXJ0cyBv ZiBsYXJnZSBkZXBsb3ltZW50IGNhbiBub3QgY29tbXVuaWNhdGUuICZxdW90OyBJIHRoaW5rIHRo ZSBwcm9ibGVtIGlzIHRoYXQgZWFjaCBzaWxvIGNhbm5vdCBhdXRoZW50aWNhdGUgZWFjaCBvdGhl ciBpbiB0cnVzdGVkIG1hbm5lciwmbmJzcDsgaWYgSW9UIGRldmljZSBjb21wYW55DQogQSBrbm93 cyBpdCdzIGFsbG93IHR1cm4gdGhlIGxpZ2h0IHN3aXRjaCBvbiBJb1QgZGV2aWNlIGNvbXBhbnkg QiB3aGVuIHRoZSBzdW4gc2V0cywgdGhlbiB0aGVyZSdzIG5vIG1lY2hhbmlzbSB0b2RheSB0byBh dXRoZW50aWNhdGUgdGhlbXNlbHZlcyB3aXRoIGEgdW5pcXVlIGlkZW50aXR5Py4uLiAmbmJzcDsm bmJzcDthbmQgdGhlcmUgbmVlZHMgdG8gYmUgYSBjb250cm9sIHN5c3RlbSBzb21ld2hlcmUgdGhh dCBzYXlzIElvVCBkZXZpY2UgQSBjYW4gY29udHJvbA0KIElvVCBkZXZpY2UgQiwgdGhhdCBjb250 cm9scyBzeXN0ZW0gdG9kYXkgYWxzbyBuZWVkIHRvIGF1dGhlbnRpY2F0ZSB0aGUgSW9UIGRldmlj ZXMuLi4uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkl0J3MgY2xlYXJlciBpbiBteSBo ZWFkIHRoYW4gb24gdGhlIGVtYWlsLi4uIDxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtT ZWdvZSBVSSBFbW9qaSZxdW90OyxzYW5zLXNlcmlmIj4NCuKYuTwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+SmFjazxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAtLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBGcm9t OiBEYW5pc2ggJmx0O2RhbmlzaC1ib3VuY2VzQGlldGYub3JnJmd0OyBPbiBCZWhhbGYgT2YgTWlj aGFlbCBSaWNoYXJkc29uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4m Z3Q7IFNlbnQ6IEp1bmUgMjEsIDIwMjEgMTA6MDAgUE08bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPiZndDsgVG86IFJvbWFuIERhbnlsaXcgJmx0O3JkZEBjZXJ0Lm9yZyZn dDs7IGRhbmlzaEBpZXRmLm9yZzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+Jmd0OyBTdWJqZWN0OiBSZTogW0RhbmlzaF0gUHJvcG9zZWQgV0cgQ2hhcnRlcjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyA8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij4mZ3Q7IFNvLCB0aGUgaW5pdGlhbCBjaGFydGVyIGZyb20gSnVuZSAxMiBpcyBu b3cgYXQ6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IDxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmbmJzcDsmbmJzcDs8YSBo cmVmPSJodHRwczovL2dpdGh1Yi5jb20vbWNyL2RhbmlzaC1ib2YvY29tbWl0LzZjOWE1MDgwNGQw ODY2NzljMDYxNzJmMDg1OTE1YjlkYWQ3OTcwZGIiPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0 ZXh0O3RleHQtZGVjb3JhdGlvbjpub25lIj5odHRwczovL2dpdGh1Yi5jb20vbWNyL2RhbmlzaC08 L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PGEgaHJl Zj0iaHR0cHM6Ly9naXRodWIuY29tL21jci9kYW5pc2gtYm9mL2NvbW1pdC82YzlhNTA4MDRkMDg2 Njc5YzA2MTcyZjA4NTkxNWI5ZGFkNzk3MGRiIj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4 dDt0ZXh0LWRlY29yYXRpb246bm9uZSI+Jmd0OyBib2YvY29tbWl0LzZjOWE1MDgwNGQwODY2Nzlj MDYxNzJmMDg1OTE1YjlkYWQ3OTcwZGI8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPiZndDsgTXkgcHJvcG9zZWQgcmV2aXNlZCBjaGFydGVyIGlzIGF0OjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmbmJzcDsmbmJzcDs8YSBocmVmPSJo dHRwczovL2dpdGh1Yi5jb20vbWNyL2RhbmlzaC1ib2YvcHVsbC8xL2ZpbGVzP3Nob3J0X3BhdGg9 ZDIyYjNkNiNkaWZmLWQyMmIzZDY1NTBjMzQ1OTRhNmUyZDZiMjE0OGVkMTc5MDdjNWQ1OThiMTBm NDA3YjZmYmVjZjA3YmYyNWVhOTciPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O3RleHQt ZGVjb3JhdGlvbjpub25lIj5odHRwczovL2dpdGh1Yi5jb20vbWNyL2RhbmlzaC1ib2YvcHVsbC8x L2ZpbGVzP3Nob3J0X3BhdGg9ZDIyYjNkNiNkaWZmLTwvc3Bhbj48L2E+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48YSBocmVmPSJodHRwczovL2dpdGh1Yi5jb20vbWNy L2RhbmlzaC1ib2YvcHVsbC8xL2ZpbGVzP3Nob3J0X3BhdGg9ZDIyYjNkNiNkaWZmLWQyMmIzZDY1 NTBjMzQ1OTRhNmUyZDZiMjE0OGVkMTc5MDdjNWQ1OThiMTBmNDA3YjZmYmVjZjA3YmYyNWVhOTci PjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25lIj4mZ3Q7 IGQyMmIzZDY1NTBjMzQ1OTRhNmUyZDZiMjE0OGVkMTc5MDdjNWQ1OThiMTBmNDA3YjZmYmVjZjA3 YmYyNWVhOTc8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+Jmd0OyA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgSW4g YWxsIGl0J3MgZ2l0aHViIGFubm90YXRlZCBNYXJrZG93biBnbG9yeSE8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij4mZ3Q7IFRoZXNlIGFyZSBteSBlZGl0cyB0aGlzIGV2ZW5pbmcgYmFzZWQg dXBvbiBSb21hbidzIGNvbW1lbnRzIGVhcmxpZXIgdG9kYXkuPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+Jmd0OyAmbmJzcDsmbmJzcDs8YSBocmVmPSJodHRwczovL2dpdGh1Yi5jb20vbWNy L2RhbmlzaC1ib2YvcHVsbC8yL2ZpbGVzP3Nob3J0X3BhdGg9ZDIyYjNkNiNkaWZmLWQyMmIzZDY1 NTBjMzQ1OTRhNmUyZDZiMjE0OGVkMTc5MDdjNWQ1OThiMTBmNDA3YjZmYmVjZjA3YmYyNWVhOTci PjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25lIj5odHRw czovL2dpdGh1Yi5jb20vbWNyL2RhbmlzaC1ib2YvcHVsbC8yL2ZpbGVzP3Nob3J0X3BhdGg9ZDIy YjNkNiNkaWZmLTwvc3Bhbj48L2E+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij48YSBocmVmPSJodHRwczovL2dpdGh1Yi5jb20vbWNyL2RhbmlzaC1ib2YvcHVsbC8yL2Zp bGVzP3Nob3J0X3BhdGg9ZDIyYjNkNiNkaWZmLWQyMmIzZDY1NTBjMzQ1OTRhNmUyZDZiMjE0OGVk MTc5MDdjNWQ1OThiMTBmNDA3YjZmYmVjZjA3YmYyNWVhOTciPjxzcGFuIHN0eWxlPSJjb2xvcjp3 aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25lIj4mZ3Q7IGQyMmIzZDY1NTBjMzQ1OTRhNmUy ZDZiMjE0OGVkMTc5MDdjNWQ1OThiMTBmNDA3YjZmYmVjZjA3YmYyNWVhOTc8L3NwYW4+PC9hPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyA8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgSSB3b3VsZCBhcHByZWNpYXRlIGdpdGh1 YiBsZXZlbCBjb21tZW50cyBvbiB0aGUgY29tbWVudHMsIHBhcnRpY3VsYXJseSBmcm9tPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IFJvbWFuLjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyA8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPiZndDsgLS08bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPiZndDsgTWljaGFlbCBSaWNoYXJkc29uICZsdDs8YSBocmVmPSJtYWlsdG86bWNy JiM0MztJRVRGQHNhbmRlbG1hbi5jYSI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7dGV4 dC1kZWNvcmF0aW9uOm5vbmUiPm1jciYjNDM7SUVURkBzYW5kZWxtYW4uY2E8L3NwYW4+PC9hPiZn dDsmbmJzcDsmbmJzcDsgLiBvIE8gKCBJUHY2IEnDuFQgY29uc3VsdGluZyApPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO1NhbmRlbG1hbiBTb2Z0 d2FyZSBXb3JrcyBJbmMsIE90dGF3YSBhbmQgV29ybGR3aWRlPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+Jmd0OyA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZn dDsgPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Im1zaXBmb290ZXI1NzMwMzZiNSIgc3R5bGU9Im1hcmdpbjowY20iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5DTEFTU0lGSUNBVElPTjpDT05GSURFTlRJ QUw8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_8236b61aa6d64f3db5e23b5345730dbfciraca_-- From nobody Fri Jun 25 10:11:48 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 354563A0BF3 for ; Fri, 25 Jun 2021 10:11:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, 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 GIGDynzaQcD5 for ; Fri, 25 Jun 2021 10:11:41 -0700 (PDT) Received: from mail-qv1-xf29.google.com (mail-qv1-xf29.google.com [IPv6:2607:f8b0:4864:20::f29]) (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 EFAB53A0BF0 for ; Fri, 25 Jun 2021 10:11:40 -0700 (PDT) Received: by mail-qv1-xf29.google.com with SMTP id j6so4949162qvp.3 for ; Fri, 25 Jun 2021 10:11:40 -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=dXus7JrfdBKendtAGIKma7PozyUKwm2/YVYZrcTYXUs=; b=HBq6jeKlmd/wcMmPC647LzcbElaxp6EZoHl+NXeUT071EtYL6eGWiph89XlvhXODUQ XIHz0EayNuLLM+zj1eG3nNwkSwnfB9I1ZhxpljZQitTjyK2FDU2ohl4IEfIFhjN1WnlU x2KYczzDdefF567EHaBCyrI9j0MEssPEKTO2hktaKDO8W76mdV6Hr4KuESTVPD1WE9Oq 9Er13zPrr++FbEydVZxOR9vpRyqwyQpvjulK1aKpsCGwO7Xm1Y3D1z2QEbZVsMMJPw7c orPeuhWyFEoCgjQKSH/Am6mfPoq0YXQB8z3mwpESHv1paL6K5cqqV2bEAJtZ0B0cwt5g tLxw== 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=dXus7JrfdBKendtAGIKma7PozyUKwm2/YVYZrcTYXUs=; b=I7G8w2iTOWGGuny8NaXcnUDR+jPcDsEXDuq4llp+ghDKunHg2v6pqHs9M5Gkx4ilf2 cNFWk5BpW3ASj45N8E0ZOj/gGefYHLa8+3T9RkPJchXOe3C3+r5CFSCF+xvM9BFxKEG3 7MHye7mDPrwvrdcep9FeHMbup3iCZsr4oLeGe2HGqrpWQycRYwTnhWd1o+DcYA1VOSBB afhHadvsoBY3rh9y9KFXEvmu6eF9LXtCgHi+P6RmksTCiHZNSBN7IAYUzZ3w/u+Y/s8I 5bmzCVZfg5evobre9+fLjPI58lWWjQU1Yt5GXkYSPw4dmkzjaVjHgEtL7aReGsosndn1 jrUg== X-Gm-Message-State: AOAM532044RjpOgd6cXPd9CtT8e6E8aRQgAqPvqr/SRCUHj0VeJP3gSi Q9FJ4WyRUBjNjenDhHdb2CtXf/zEYBd213XLOeZP/lvJx0A= X-Google-Smtp-Source: ABdhPJzNfwRbN9eOLhsVrNDVoPiXpZjL2P7cr3VVppi10Q3/IS9qSKrszPgHeG7ixbqz/ng4GVnaEmeS0IaKd73ldn8= X-Received: by 2002:a0c:e0d0:: with SMTP id x16mr12298854qvk.7.1624641099409; Fri, 25 Jun 2021 10:11:39 -0700 (PDT) MIME-Version: 1.0 References: <17670.1624372831@localhost> In-Reply-To: From: Ash Wilson Date: Fri, 25 Jun 2021 10:11:28 -0700 Message-ID: To: Wes Hardaker Cc: Michael Richardson , danish@ietf.org Content-Type: multipart/alternative; boundary="0000000000009e428d05c59a3b90" Archived-At: Subject: Re: [Danish] revised charter text from Tuesday morning X-BeenThere: danish@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DANE AutheNtication for Iot Service Hardening List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jun 2021 17:11:46 -0000 --0000000000009e428d05c59a3b90 Content-Type: text/plain; charset="UTF-8" Hi Team, I have no objection to the charter. I commit to contributing in the following ways: - Mailing list participation - Draft development, editing, review - Technical validation On Tue, Jun 22, 2021 at 7:49 AM Wes Hardaker wrote: > Michael Richardson writes: > > > Please review this in the next week and a half and propose text either on > > github, or on the ML. > > And specifically: > > 1. Does anyone object to this proposed path. We believe there is likely > consensus on this narrowed scope and that it's unlikely a wider scope > at this will achieve consensus (but the charter notes at the bottom > that other future items may be possible). > > 2. Who is willing to: > > - contribute in mailing list discussions > - edit drafts > - review drafts > > Please do respond to these messages to indicate your willingness to > help if DANISH is approved as a WG. > > -- > Wes Hardaker > USC/ISI > > -- > Danish mailing list > Danish@ietf.org > https://www.ietf.org/mailman/listinfo/danish > -- *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. --0000000000009e428d05c59a3b90 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Team,

I have no objection to t= he charter.

I commit to contributing in the following ways:
- Mailing list participation
- Draft development, editing= , review
- Technical validation

On Tue, Jun 22, 2021= at 7:49 AM Wes Hardaker <wjhns1= @hardakers.net> wrote:
Michael Richardson <mcr+ietf@sandelman.ca> writes:

> Please review this in the next week and a half and propose text either= on
> github, or on the ML.

And specifically:

1. Does anyone object to this proposed path.=C2=A0 We believe there is like= ly
=C2=A0 =C2=A0consensus on this narrowed scope and that it's unlikely a = wider scope
=C2=A0 =C2=A0at this will achieve consensus (but the charter notes at the b= ottom
=C2=A0 =C2=A0that other future items may be possible).

2. Who is willing to:

=C2=A0 =C2=A0- contribute in mailing list discussions
=C2=A0 =C2=A0- edit drafts
=C2=A0 =C2=A0- review drafts

=C2=A0 =C2=A0Please do respond to these messages to indicate your willingne= ss to
=C2=A0 =C2=A0help if DANISH is approved as a WG.

--
Wes Hardaker
USC/ISI

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


--

Ash Wilson | Technical Dire= ctor

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

--0000000000009e428d05c59a3b90-- From nobody Fri Jun 25 14:11:40 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 D42B73A084C; Fri, 25 Jun 2021 14:11:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 ndwwzVDufDDP; Fri, 25 Jun 2021 14:11:29 -0700 (PDT) Received: from gabriel-2.zfn.uni-bremen.de (gabriel-2.zfn.uni-bremen.de [134.102.50.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CCA73A0853; Fri, 25 Jun 2021 14:11:29 -0700 (PDT) Received: from [192.168.217.118] (p548dcc89.dip0.t-ipconnect.de [84.141.204.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4GBV6l4vLVz2xGb; Fri, 25 Jun 2021 23:11:27 +0200 (CEST) From: Carsten Bormann Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Mao-Original-Outgoing-Id: 646348287.003497-fb3724daac80c692205596cd4ebc9499 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) Message-Id: Date: Fri, 25 Jun 2021 23:11:27 +0200 To: asdf@ietf.org, coin@irtf.org, iotops@ietf.org, danish@ietf.org X-Mailer: Apple Mail (2.3608.120.23.2.7) Archived-At: Subject: [Danish] Constrained Node/Network Cluster @ IETF111: DRAFT AGENDA X-BeenThere: danish@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DANE AutheNtication for Iot Service Hardening List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jun 2021 21:11:34 -0000 Here is my usual eclectic condensed agenda based on the DRAFT AGENDA for IETF111. Remember that there is still quite some potential for changes. The IoT-relevant conflicts that most meet the eye this time are LAKE/RATS, IOTOPS/RATS (and there is likely to be an IoT-relevant discussion at tsvwg, which overlaps the third RATS). All times *on my agenda* are in UTC (the default page is UTC-0700). Please forgive the 2500, I'm way too lazy to write code to turn this into 0100. (And it is advisable to ignore the fictional end time of the Wednesday plenary anyway.) https://datatracker.ietf.org/meeting/agenda-utc might be handy. Gr=C3=BC=C3=9Fe, Carsten 1900-2100 Hackathon Kickoff Rm 1 GEN hackathon Hackathon FRIDAY, July 23, 2021 1900-2100 Hackathon Closing Rm 1 GEN hackathon Hackathon MONDAY, July 26, 2021 1900-2100 Session I Rm 1 ART dispatch Dispatch WG - Joint with ARTAREA Rm 2 IRTF anrw ACM/IRTF Applied Networking Research = Workshop - New Internet Protocols & Practical Congestion Control Rm 3 IRTF pearg Privacy Enhancements and Assessments = Research Group Rm 7 SEC gnap Grant Negotiation and Authorization = Protocol WG 2130-2230 Session II Rm 1 ART wpack Web Packaging WG Rm 2 IRTF irtfopen IRTF Open Meeting Rm 3 OPS anima Autonomic Networking Integrated Model = and Approach WG Rm 4 RTG babel Babel routing protocol WG Rm 7 SEC *** rats Remote ATtestation ProcedureS WG Rm 8 TSV (!) tsvwg Transport Area Working Group WG 2300-2500 Session III Rm 2 ART jsonpath JSON Path WG Rm 3 IRTF coinrg Computing in the Network Research Group Rm 7 SEC secdispatch Security Dispatch WG Rm 8 TSV masque Multiplexed Application Substrate over = QUIC Encryption WG TUESDAY, July 27, 2021 1900-2100 Session I Rm 1 ART sedate Serialising Extended Data About Times = and Events WG Rm 2 INT 6man IPv6 Maintenance WG Rm 3 IRTF anrw ACM/IRTF Applied Networking Research = Workshop - Interconnection and Routing & Monitoring Internet Traffic Rm 5 RTG bier Bit Indexed Explicit Replication WG Rm 6 RTG raw Reliable and Available Wireless WG Rm 7 SEC *** danish DANE AutheNtication for Iot Service = Hardening BOF Rm 8 TSV quic QUIC WG 2130-2230 Session II Rm 3 INT dnssd Extensions for Scalable DNS Service = Discovery WG Rm 6 SEC saag Security Area Open Meeting Rm 7 TSV taps Transport Services WG 2300-2500 Session III Rm 7 SEC ohttp Oblivious HTTP BOF WEDNESDAY, July 28, 2021 1900-2100 Session I Rm 1 ART *** core Constrained RESTful Environments WG Rm 3 INT madinas MAC Address Device Identification for = Network and Application Services BOF Rm 4 IRTF anrw ACM/IRTF Applied Networking Research = Workshop - Privacy & Applications Rm 7 SEC tls Transport Layer Security WG 2130-2230 Session II Rm 2 ART uta Using TLS in Applications WG Rm 4 INT *** 6lo IPv6 over Networks of = Resource-constrained Nodes WG Rm 5 INT *** drip Drone Remote ID Protocol WG Rm 8 RTG rift Routing In Fat Trees WG Rm 9 SEC *** cose CBOR Object Signing and Encryption WG 2300-2440 IETF Plenary - Plenary THURSDAY, July 29, 2021 1900-2000 Session I Rm 3 OPS anima Autonomic Networking Integrated Model = and Approach WG Rm 4 OPS v6ops IPv6 Operations WG Rm 7 SEC *** lake Lightweight Authenticated Key Exchange = WG Rm 8 SEC *** rats Remote ATtestation ProcedureS WG Rm 9 TSV tsvarea Transport Area Open Meeting 2030-2130 Session II Rm 5 IRTF qirg Quantum Internet Research Group Rm 6 OPS *** iotops IOT Operations WG Rm 7 RTG rtgarea Routing Area Open Meeting Rm 9 SEC mls Messaging Layer Security WG Rm 8 SEC *** rats Remote ATtestation ProcedureS WG 2200-2300 Session III Rm 5 SEC *** ace Authentication and Authorization for = Constrained Environments WG 2330-2430 Session IV Rm 4 IRTF panrg Path Aware Networking RG Rm 8 SEC emu EAP Method Update WG Rm 9 SEC *** teep Trusted Execution Environment = Provisioning WG FRIDAY, July 30, 2021 1900-2100 Session I Rm 1 ART webtrans WebTransport WG Rm 2 INT add Adaptive DNS Discovery WG Rm 5 RTG apn Application-aware Networking BOF Rm 7 SEC *** suit Software Updates for Internet of Things = WG 2130-2230 Session II Rm 1 ART *** cbor Concise Binary Object Representation = Maintenance and Extensions WG Rm 2 IRTF maprg Measurement and Analysis for Protocols Rm 5 RTG detnet Deterministic Networking WG Rm 6 SEC acme Automated Certificate Management = Environment WG Rm 7 SEC privacypass Privacy Pass WG 2300-2500 Session III Rm 1 ART httpapi Building Blocks for HTTP APIs WG Rm 2 INT intarea Internet Area Working Group WG Rm 3 IRTF cfrg Crypto Forum Rm 4 IRTF*** dinrg Decentralized Internet Infrastructure Rm 8 SEC *** teep Trusted Execution Environment = Provisioning WG Rm 9 TSV tsvwg Transport Area Working Group WG _______________________________________________ Lwip mailing list Lwip@ietf.org https://www.ietf.org/mailman/listinfo/lwip From nobody Fri Jun 25 18:50:31 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 3A3863A16E9 for ; Fri, 25 Jun 2021 18:50:30 -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, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 4_kFZMq_G5AL for ; Fri, 25 Jun 2021 18:50:25 -0700 (PDT) Received: from mail-ej1-x635.google.com (mail-ej1-x635.google.com [IPv6:2a00:1450:4864:20::635]) (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 919143A16E7 for ; Fri, 25 Jun 2021 18:50:25 -0700 (PDT) Received: by mail-ej1-x635.google.com with SMTP id ot9so17039404ejb.8 for ; Fri, 25 Jun 2021 18:50:25 -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=6YJU52rOSk8UB+ni0mP+PG2Vp2wI8oXl0rqhYSN+qkQ=; b=T6Z//WxZKX0kSNGSJ1Xdsy6VhK0usPXTgS5Ra6YOJozv6YejZEdPFqOgvEdxip9Dx+ HLk0cRdyi5E4lwT0nkWdbgJhNpkLl05T/qSg+NZTHk+MMXV9twandjTd04twM2dZ02TX 5uht997xRzttHJ7zlmRF84yV7J0rhNRa5Br1mQqgtdPR5io64gx4prRtD6SWLHO6hEay IqM/lue1fMVAj6v7I0koaLoM3W8MSBwt17L4U8bB7zEEBghIYFunjJgrGUGa0DbIqK8q 54Md5EHmJ+HzLdFGFfsmjoh3Mcl5XycB9sUCaG3QibXq07oiY93gKgg9R5eCuCIpvq6l U9Pg== 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=6YJU52rOSk8UB+ni0mP+PG2Vp2wI8oXl0rqhYSN+qkQ=; b=qBXg+aPllAIzK2VMYKbXQ/yVeWcSNBfyEg3xIzqxj5JnBe94MDRWyKtzG8yk3HHz5p rWTWud8SYP9gE9Bgrtb1FfRiRXZ6NJZMOq1zFqRsvMPjeEWdQ08FjTlsOauOOtlA1Jfd xNIwhdVzZ2CCS8zlPGEuaS9ToA26kcZ6TpTl41dQOCaA/9ccVhnzKlZ0GP+2b66wdRJ1 PsFTCROUWgbajp/p3S3Gv78Hl7JnTh6C495iFGPdhOMb8fPRBWXObStiBxbKcqFhWiop PR2uesJtY+KL85ZRsvBAEPkRJahflWkQaP1h1UUkRBVKGHid1E6bYLIiVzwfahY4neui BZwA== X-Gm-Message-State: AOAM53345u6JP34q9yS1p0Gcfjs3SW4gGmZVRZThh7PRW444m7n4GGsW 2YmRNdB4wiblHQrPBw/Z3gPAw3CyJOe6g0tj+YE= X-Google-Smtp-Source: ABdhPJzVEYVFr8SdQv+pIgu3F3G7ILDkr2naiMCKSCLj951mvEU4MwGnt94qJYqYG+O7+TojQaFmYLxqxPeRYKTIldE= X-Received: by 2002:a17:907:94cf:: with SMTP id dn15mr13622598ejc.476.1624672222455; Fri, 25 Jun 2021 18:50:22 -0700 (PDT) MIME-Version: 1.0 References: <17670.1624372831@localhost> In-Reply-To: From: Shumon Huque Date: Fri, 25 Jun 2021 21:50:11 -0400 Message-ID: To: Wes Hardaker Cc: Michael Richardson , danish@ietf.org Content-Type: multipart/alternative; boundary="000000000000b22ce405c5a17a57" Archived-At: Subject: Re: [Danish] revised charter text from Tuesday morning X-BeenThere: danish@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DANE AutheNtication for Iot Service Hardening List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jun 2021 01:50:30 -0000 --000000000000b22ce405c5a17a57 Content-Type: text/plain; charset="UTF-8" Charter looks okay to me. I'm willing to contribute, review, and edit drafts. Shumon. On Tue, Jun 22, 2021 at 10:49 AM Wes Hardaker wrote: > Michael Richardson writes: > > > Please review this in the next week and a half and propose text either on > > github, or on the ML. > > And specifically: > > 1. Does anyone object to this proposed path. We believe there is likely > consensus on this narrowed scope and that it's unlikely a wider scope > at this will achieve consensus (but the charter notes at the bottom > that other future items may be possible). > > 2. Who is willing to: > > - contribute in mailing list discussions > - edit drafts > - review drafts > > Please do respond to these messages to indicate your willingness to > help if DANISH is approved as a WG. > > -- > Wes Hardaker > USC/ISI > > -- > Danish mailing list > Danish@ietf.org > https://www.ietf.org/mailman/listinfo/danish > --000000000000b22ce405c5a17a57 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Charter looks okay to me.

I&= #39;m willing to contribute, review, and edit drafts.

<= div>Shumon.

On Tue, Jun 22, 2021 at 10:49 AM Wes Hardaker <wjhns1@hardakers.net> wrote:
Michael Richardson <= ;mcr+ietf@sand= elman.ca> writes:

> Please review this in the next week and a half and propose text either= on
> github, or on the ML.

And specifically:

1. Does anyone object to this proposed path.=C2=A0 We believe there is like= ly
=C2=A0 =C2=A0consensus on this narrowed scope and that it's unlikely a = wider scope
=C2=A0 =C2=A0at this will achieve consensus (but the charter notes at the b= ottom
=C2=A0 =C2=A0that other future items may be possible).

2. Who is willing to:

=C2=A0 =C2=A0- contribute in mailing list discussions
=C2=A0 =C2=A0- edit drafts
=C2=A0 =C2=A0- review drafts

=C2=A0 =C2=A0Please do respond to these messages to indicate your willingne= ss to
=C2=A0 =C2=A0help if DANISH is approved as a WG.

--
Wes Hardaker
USC/ISI

--
Danish mailing list
Danish@ietf.org https://www.ietf.org/mailman/listinfo/danish
--000000000000b22ce405c5a17a57-- From nobody Sat Jun 26 12:08:27 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 3D7AA3A005D for ; Sat, 26 Jun 2021 12:08:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 q_9Olz7EP204 for ; Sat, 26 Jun 2021 12:08:20 -0700 (PDT) Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (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 A2ED63A005C for ; Sat, 26 Jun 2021 12:08:20 -0700 (PDT) Received: from smtpclient.apple (unknown [192.168.1.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by straasha.imrryr.org (Postfix) with ESMTPSA id 9EDA8CD560 for ; Sat, 26 Jun 2021 15:08:19 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) From: Viktor Dukhovni In-Reply-To: <17670.1624372831@localhost> Date: Sat, 26 Jun 2021 15:08:19 -0400 Content-Transfer-Encoding: quoted-printable Reply-To: danish@ietf.org Message-Id: <2F9979ED-0400-4E71-A7D1-F49919004C6F@dukhovni.org> References: <17670.1624372831@localhost> To: danish@ietf.org X-Mailer: Apple Mail (2.3654.100.0.2.22) Archived-At: Subject: Re: [Danish] revised charter text from Tuesday morning X-BeenThere: danish@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DANE AutheNtication for Iot Service Hardening List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jun 2021 19:08:25 -0000 > On 22 Jun 2021, at 10:40 am, Michael Richardson = wrote: >=20 > The process of establishing trust in public-key-authenticated identity > typically involves the use of a Public Key Infrastructure (PKI), and a > shared PKI root of trust between the parties exchanging public keys. A > Certification Authority (CA) is one example of a PKI which can be used = for > establishing trust in public keys. I don't think it is correct to conflate a CA with a PKI. A PKI is an = ecosystem, that consists of some mixture of: * Relying parties * Key holders * Certification authorities * Registration Authorities * CRL distribution services * OCSP services * CT logs? * ... A CA's public key (or the associated certificate) can be a trust-anchor = in a PKI, but is not in itself a PKI. > The DNS namespace, together with DNSSEC, forms the most = widely-recognized > namespace and authenticated discovery mechanism on the Internet. This rather lacks context and looks poorly framed to me. Why are we = suddenly talking about "discovery". DNS is a distributed directly (lookup) = service, it is not a "discovery" mechanism, even if some "discovery" mechanisms = happen to leverage DNS at some point. DNS is the largest (only) Internet-wide federated namespace. DNSSEC = provides end-to-end integrity for DNS, obviating the need to trust intermediate = caches. DNSSEC also makes it possible to securely publish the public keys or certificates of (DNS) named entities. > DANE builds on this authenticated discovery mechanism to enable public = key-based > TLS authentication which is resilient to impersonation, but only for = TLS > server identities. DNS is not a discovery mechanism. DANE makes it possible to securely = look up the public key or certificate (in full or a digest) associated with a = (DNS) named entity. In the case of TLS, DANE presently only defines naming = for server endpoints. > What DANE did not define is how services can authenticate connecting = clients. There is presently no standard definition of client identity names, nor = how a client would communicate its DNS name to a server in a given protocol. > In response to the challenges related to ambiguity between client = identities issued > by different CAs, application owners frequently choose to onboard IoT = devices > to a single private CA specific to that vertical. All mention of "ambiguity" needs to go. It is misleading and not the = real issue at hand. The problem is not "ambiguity". The relevant concerns are: * Need for global names. If the relying party is not also the = owner/operator of a private PKI, but rather relies on a global PKI, then of course = the names being authenticated need to be global (e.g. DNS names). * Need to scope trust. In many applications it is not acceptable to = trust client identities issued by all the various CAs of the WebPKI. Ambiguity is not relevant, and fails to capture the key issues. --=20 Viktor. From nobody Sun Jun 27 08:47:11 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 067273A0407 for ; Sun, 27 Jun 2021 08:47:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 ZctzwXxuv3nT for ; Sun, 27 Jun 2021 08:47:04 -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 2FFE33A040A for ; Sun, 27 Jun 2021 08:47:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 0E2D338A0F for ; Sun, 27 Jun 2021 11:48:58 -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 waCZRLSCaB3A for ; Sun, 27 Jun 2021 11:48:55 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id B518F38A01 for ; Sun, 27 Jun 2021 11:48:55 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 8914C904 for ; Sun, 27 Jun 2021 11:47:00 -0400 (EDT) From: Michael Richardson To: danish@ietf.org In-Reply-To: <2F9979ED-0400-4E71-A7D1-F49919004C6F@dukhovni.org> References: <17670.1624372831@localhost> <2F9979ED-0400-4E71-A7D1-F49919004C6F@dukhovni.org> 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: Re: [Danish] revised charter text from Tuesday morning X-BeenThere: danish@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DANE AutheNtication for Iot Service Hardening List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Jun 2021 15:47:09 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Viktor Dukhovni wrote: >> On 22 Jun 2021, at 10:40 am, Michael Richardson >> wrote: >> >> The process of establishing trust in public-key-authenticated identi= ty >> typically involves the use of a Public Key Infrastructure (PKI), and= a >> shared PKI root of trust between the parties exchanging public keys.= A >> Certification Authority (CA) is one example of a PKI which can be us= ed >> for establishing trust in public keys. > I don't think it is correct to conflate a CA with a PKI. A PKI is an > ecosystem, that consists of some mixture of: I don't think that my text conflates anything, but let me ask you: > A CA's public key (or the associated certificate) can be a trust-anch= or > in a PKI, but is not in itself a PKI. *can* implies that there is an alternative. What is that alternative? What in practice, does not conflating mean? > DNS is the largest (only) Internet-wide federated namespace. DNSSEC > provides end-to-end integrity for DNS, obviating the need to trust > intermediate caches. DNSSEC also makes it possible to securely publi= sh > the public keys or certificates of (DNS) named entities. If you are suggesting changes to the text, please just make them? I'm not in disagreement with you, and I'm lost as to what your point is. >> DANE builds on this authenticated discovery mechanism to enable publ= ic >> key-based TLS authentication which is resilient to impersonation, but >> only for TLS server identities. > DNS is not a discovery mechanism. DANE makes it possible to securely Given a name, I can discovery a key. > Ambiguity is not relevant, and fails to capture the key issues. please send suggested changes they would be most welcome =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+93Q3WUFAmDYnXQACgkQgItw+93Q 3WUoYAgAqxrIo5TehRpoO7pd43U0Mb/QWcDHikXyzjamfZ5uiJDawY0blo09Jgbr b7JSNTHUUND28QQU3FXoniFhkjFviYmGyJF/uJHV47f80xd+nSuRWhzQaEbAJiEp jABIrpxVvK5BzucxFl6/Djrlq/3F5SU0ZO0fF1szpfT/C0vfLm+VilgrmbXRen2L 16vemxsVunuiw841cIP8q86pmz7a6mtQKGLF4DHsRehfHzJmMFpvHgf2FNI+MFa3 2tKFDPR6MiiCAcQOoJ5l1sVTuwcwcEQjQS23cUJw0iPogz+7RtpOsWKFU0iBTII5 +VNdzmrv+BALdfaqadrTxhlnFnVpnw== =2/Jv -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun Jun 27 11:05:25 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 DAE463A10A2 for ; Sun, 27 Jun 2021 11:05:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-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 vFcZi7rDL2TE for ; Sun, 27 Jun 2021 11:05:21 -0700 (PDT) Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (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 122373A10A0 for ; Sun, 27 Jun 2021 11:05:20 -0700 (PDT) Received: by straasha.imrryr.org (Postfix, from userid 1001) id AD910CDF07; Sun, 27 Jun 2021 14:05:19 -0400 (EDT) Date: Sun, 27 Jun 2021 14:05:19 -0400 From: Viktor Dukhovni To: danish@ietf.org Message-ID: Reply-To: danish@ietf.org References: <17670.1624372831@localhost> <2F9979ED-0400-4E71-A7D1-F49919004C6F@dukhovni.org> <12180.1624808820@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <12180.1624808820@localhost> Archived-At: Subject: Re: [Danish] revised charter text from Tuesday morning X-BeenThere: danish@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DANE AutheNtication for Iot Service Hardening List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Jun 2021 18:05:23 -0000 On Sun, Jun 27, 2021 at 11:47:00AM -0400, Michael Richardson wrote: > I don't think that my text conflates anything, but let me ask you: > > > A CA's public key (or the associated certificate) can be a trust-anchor > > in a PKI, but is not in itself a PKI. > > *can* implies that there is an alternative. What is that alternative? A CA's public key can be just a CA key without being a trust-anchor. And my larger point was that even a trust-anchor is not a PKI, it is just a (trusted by some) public key. > What in practice, does not conflating mean? Conflating means that you're calling a CA certificate a PKI, but it is just a public key container. > > DNS is the largest (only) Internet-wide federated namespace. DNSSEC > > provides end-to-end integrity for DNS, obviating the need to trust > > intermediate caches. DNSSEC also makes it possible to securely publish > > the public keys or certificates of (DNS) named entities. > > If you are suggesting changes to the text, please just make them? > I'm not in disagreement with you, and I'm lost as to what your point is. My point is that the present text is misuses terminology to the point of confusion and failure to make the intended point. > > DNS is not a discovery mechanism. DANE makes it possible to securely > > Given a name, I can discover a key. No, discovery is something else, it is a one-time activity. You discover something, and then it is known (indefinitely). DNS is not discovery, it is lookup, and the data in DNS is used for a short time (minutes to hours) and then discarded. There are discovery mechnisms that do use data from DNS, the main one I see is publishing the MSA/IMAP server names for a domain, which the MUA caches indefinitely (and ideally asks the user to initially confirm), but DNS on the whole *not* a discovery system. In the rare cases where the DNS is (ab)used for "discovery" (use of data long past its TTL) there needs to be a very good reason as to why that's a reasonable thing to do. [ One time autoconfiguration of an MUAs from the user's email address is one of the few reasonable exceptions to the general rule that one should not use DNS data past its use-by date. ] > > Ambiguity is not relevant, and fails to capture the key issues. > > please send suggested changes they would be most welcome I thought I did. The discussion needs to be about the need for global names and trusting the authoritative source of data or their rightful agent. The WebPKI is entirely unsuitable for client identity, since the CA/B forum CAs cannot notarise what they cannot observe (can't connect to clients to perform ACME challenges). It is also not reasonable to accept attestations about clients used in granting access to sensitive resources from any CA on the planet. Once the discussion shifts away from "ambiguity", to global naming and trust, one can finally begin to ask meaningful questions about the long-term stability of names, the durability of trust, whether in fact one wants to do "discovery" and then issue local names and keys to the discovered entity, or whether the interaction is short-term and with many similar peers, making vendor-managed naming attractive. The hope was that the posted critique would be a basis for improving the text in a way that also satisfies goals I may have missed, or mistakes I may have made. IoT is not a space I've thought much about. -- Viktor