From nobody Thu Jun 4 23:08:27 2020 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF4E93A12CF; Thu, 4 Jun 2020 23:08:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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 yYpBtEiTzC4E; Thu, 4 Jun 2020 23:08:22 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 A03D13A12CD; Thu, 4 Jun 2020 23:08:22 -0700 (PDT) Received: from lhreml727-chm.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id DC4C21D4BE44CA01939E; Fri, 5 Jun 2020 07:08:19 +0100 (IST) Received: from nkgeml705-chm.china.huawei.com (10.98.57.154) by lhreml727-chm.china.huawei.com (10.201.108.78) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Fri, 5 Jun 2020 07:08:19 +0100 Received: from nkgeml708-chm.china.huawei.com (10.98.57.160) by nkgeml705-chm.china.huawei.com (10.98.57.154) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Fri, 5 Jun 2020 14:08:16 +0800 Received: from nkgeml708-chm.china.huawei.com ([10.98.57.160]) by nkgeml708-chm.china.huawei.com ([10.98.57.160]) with mapi id 15.01.1913.007; Fri, 5 Jun 2020 14:08:16 +0800 From: Sheng Jiang To: Anima WG CC: "anima-chairs@ietf.org" , Toerless Eckert Thread-Topic: WGLC on draft-ietf-anima-grasp-api-05 - Respond by May 25th, 2020 Thread-Index: AdYnQijPczX2zRgrQ6m8xK5szErmRwTvTdUQ Date: Fri, 5 Jun 2020 06:08:16 +0000 Message-ID: References: <997d642cfa754d11b8c680fbb042b168@huawei.com> In-Reply-To: <997d642cfa754d11b8c680fbb042b168@huawei.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.108.222.155] Content-Type: multipart/alternative; boundary="_000_f21481211385404fb742e0084382c609huaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Anima] WGLC on draft-ietf-anima-grasp-api-05 - Respond by May 25th, 2020 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2020 06:08:25 -0000 --_000_f21481211385404fb742e0084382c609huaweicom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, all, We received no negative response to the WGLC on draft-ietf-anima-grasp-api-= 05 during the two-week WGLC and we did receive good reviews through the WG = document stage, through the shepherd review process and WGLC period. Consid= ering the past history of this work, I, with my ANIMA chair cap on, feel it= has passed the WGLC and should advance. This conclusion is made with the c= ondition that the authors would solve the received comments during the WGLC= and these modifications were not substantial changes from -05 version. If = there are big changes, a shorter second WGLC may be needed. Up to now, there is no IPR disclosure to this document. Once the update is published and it meets the above condition, for which th= e second WGLC is not needed, as the document shepherd, I will finalize the = shepherd document and send the document on. Best regards, Sheng (Document Shepherd) From: Sheng Jiang Sent: Monday, May 11, 2020 11:16 AM To: Anima WG Cc: anima-chairs@ietf.org; Toerless Eckert Subject: WGLC on draft-ietf-anima-grasp-api-05 - Respond by May 25th, 2020 Hi all, This message starts the two-week ANIMA Working Group Last Call to advance d= raft-ietf-anima-grasp-api-05, Generic Autonomic Signaling Protocol Applicat= ion Program Interface (GRASP API). This document's intended status is Infor= mational. At present, there is no IPR file against this document. This docu= ment has been ANIMA WG document since Dec, 2017 and have received a few goo= d review. The authors have addressed all known comments and think the docum= ent is ready for WGLC. Please send your comments by May 25th, 2020. If you do not feel this docume= nt should advance, please state your reasons why. Sheng JIANG is the assigned document shepherd. Regards, Sheng --_000_f21481211385404fb742e0084382c609huaweicom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi, all,

 

We received no negative response = to the WGLC on draft-ietf-anima-grasp-api-05 during the two-week WGLC and w= e did receive good reviews through the WG document stage, through the shepherd review process and WGLC period. Co= nsidering the past history of this work, I, with my ANIMA chair cap on, fee= l it has passed the WGLC and should advance. This conclusion is made with t= he condition that the authors would solve the received comments during the WGLC and these modifications were n= ot substantial changes from -05 version. If there are big changes, a shorte= r second WGLC may be needed.

 

Up to now, there is no IPR disclo= sure to this document.

 

Once the update is published and = it meets the above condition, for which the second WGLC is not needed, as t= he document shepherd, I will finalize the shepherd document and send the document on.

 

Best regards,

 

Sheng (Document Shepherd)

 

From: Sheng Jiang
Sent: Monday, May 11, 2020 11:16 AM
To: Anima WG <anima@ietf.org>
Cc: anima-chairs@ietf.org; Toerless Eckert <tte@cs.fau.de>
Subject: WGLC on draft-ietf-anima-grasp-api-05 - Respond by May 25th= , 2020

 

Hi all,

 

This message starts the two-week = ANIMA Working Group Last Call to advance draft-ietf-anima-grasp-api-05, Generic = Autonomic Signaling Protocol Application Program Interface (GRASP API). Thi= s document's intended status is Informational. At present, there is no IPR = file against this document. This document has been ANIMA WG document since Dec, 2017 and have received a few good re= view. The authors have addressed all known comments and think the document = is ready for WGLC.

 

Please send your comments by May = 25th, 2020. If you do not feel this document should advance, please state y= our reasons why.

 

Sheng JIANG is the assigned docum= ent shepherd.

 

Regards,

 

Sheng

 

--_000_f21481211385404fb742e0084382c609huaweicom_-- From nobody Thu Jun 4 23:37:37 2020 Return-Path: X-Original-To: anima@ietf.org Delivered-To: anima@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D1B113A12F8; Thu, 4 Jun 2020 23:37:35 -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: rwilton@cisco.com, jiangsheng@huawei.com, anima@ietf.org, anima-chairs@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.1.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <159133905527.14318.16517327908541013754@ietfa.amsl.com> Date: Thu, 04 Jun 2020 23:37:35 -0700 Archived-At: Subject: [Anima] anima - New Meeting Session Request for IETF 108 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2020 06:37:36 -0000 A new meeting session request has just been submitted by Sheng Jiang, a Chair of the anima working group. --------------------------------------------------------- Working Group Name: Autonomic Networking Integrated Model and Approach Area Name: Operations and Management Area Session Requester: Sheng Jiang Number of Sessions: 1 Length of Session(s): 100 Minutes Number of Attendees: 60 Conflicts to Avoid: Chair Conflict: bier pim mboned 6man 6lo 6tisch ace Technology Overlap: emu netconf homenet roll Key Participant Conflict: nmrg panrg dinrg opsarea intarea saag cfrg detnet People who must be present: Toerless T. Eckert Sheng Jiang Robert Wilton Resources Requested: Special Requests: --------------------------------------------------------- From nobody Fri Jun 5 01:56:15 2020 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 436C43A13FC; Fri, 5 Jun 2020 01:56:13 -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 RyJQuLSsKg63; Fri, 5 Jun 2020 01:56:11 -0700 (PDT) Received: from mail-ed1-x535.google.com (mail-ed1-x535.google.com [IPv6:2a00:1450:4864:20::535]) (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 5A6313A13FB; Fri, 5 Jun 2020 01:56:11 -0700 (PDT) Received: by mail-ed1-x535.google.com with SMTP id p18so6838539eds.7; Fri, 05 Jun 2020 01:56:11 -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=zW3T6eVO3sNFmZNApnlEeMvo6vrge93Cw7CZRLrUHew=; b=dJ4s2Zjy94AXBQ4JCMccY40LpWzXLJaCMnC7iRN1qQu1C/aFEs6wNfMr8Siv/4xz64 IKJGyqSlMY+2aODYpdUb3VYRGrsG9qHcnvKkz/bx21UL8sXJIbV955UgT8qq6GEG1lX4 mUygfhbQdP+yJ43TuHVWfkrB4Je8C3RPKRAwsuuMcThTX0xQ5YBPJfFRLtYCD+ZbOJnG UTZU0gkOftgZCyiJv4tNghdEsWcJfTHWyQuY9WSomAMfQDFh/EjhspCzc5qRW1fCeCjg AnOMW8Tby+bpmjwmDIHEKxVJdGFZ96oM8aSRKyTLjUYJ4i9lnAotMKEtCQp0QBPhXLWG jiyA== 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=zW3T6eVO3sNFmZNApnlEeMvo6vrge93Cw7CZRLrUHew=; b=etWpGbt2NOS0m63dUTFkoaHWApyVuhUIUk57/qzP56WOLjkTy2YMGlgTafShSVCJkW b8hZaFwguTNY2kCEtHEF9xcxn07//ro3fmFCNfJlrpR7QkNtY2aCOPWW9vQabNCeie1c tU+KN9xNewKH5zPmad1+Kl9WGgvWZmj2HFhtAew/fKseaHo4P00aPc+y8/+7zhj1iHl8 TlxPK6STr6mmmAOWUEHr/SBZIWCUOmDNiDTK2FO95QD66tWmH3LQcCShvPfjTzDIcRpW i+cTGihCKKkVXyxAZW2XoelyvwW4GHmDQ0arIOP6I1lQcaIhnqW/Ie2HGr2wI4d+M8DL u9jw== X-Gm-Message-State: AOAM531XbZwQ/0Mg5x1H8EhzOii+k6puP/uYrkL7xh+JBv4VuS4Zbdm3 7ECiMrs/dsnl0NShgYq1E5IZtAKWo6H5AciMFLC3B+6O X-Google-Smtp-Source: ABdhPJwGcw6XUGoSjb0x6nOMCsdQ41XecipLEJ+X22Pp8RTZ+NRrtw8v8b0A+JTkBj166xbgDN3jmK0XgyYbESOMEZk= X-Received: by 2002:a05:6402:1558:: with SMTP id p24mr8049847edx.193.1591347368283; Fri, 05 Jun 2020 01:56:08 -0700 (PDT) MIME-Version: 1.0 References: <997d642cfa754d11b8c680fbb042b168@huawei.com> In-Reply-To: From: Brian Carpenter Date: Fri, 5 Jun 2020 20:55:55 +1200 Message-ID: To: Sheng Jiang Cc: Anima WG , anima-chairs@ietf.org, Toerless Eckert Content-Type: multipart/alternative; boundary="00000000000099d37505a7526eec" Archived-At: Subject: Re: [Anima] WGLC on draft-ietf-anima-grasp-api-05 - Respond by May 25th, 2020 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2020 08:56:13 -0000 --00000000000099d37505a7526eec Content-Type: text/plain; charset="UTF-8" Thanks, we'll make a new version shortly with comments included. At the moment I think there will be no technical changes. Regards Brian (via tiny screen & keyboard) On Fri, 5 Jun 2020, 18:08 Sheng Jiang, wrote: > Hi, all, > > > > We received no negative response to the WGLC on > draft-ietf-anima-grasp-api-05 during the two-week WGLC and we did receive > good reviews through the WG document stage, through the shepherd review > process and WGLC period. Considering the past history of this work, I, with > my ANIMA chair cap on, feel it has passed the WGLC and should advance. This > conclusion is made with the condition that the authors would solve the > received comments during the WGLC and these modifications were not > substantial changes from -05 version. If there are big changes, a shorter > second WGLC may be needed. > > > > Up to now, there is no IPR disclosure to this document. > > > > Once the update is published and it meets the above condition, for which > the second WGLC is not needed, as the document shepherd, I will finalize > the shepherd document and send the document on. > > > > Best regards, > > > > Sheng (Document Shepherd) > > > > *From:* Sheng Jiang > *Sent:* Monday, May 11, 2020 11:16 AM > *To:* Anima WG > *Cc:* anima-chairs@ietf.org; Toerless Eckert > *Subject:* WGLC on draft-ietf-anima-grasp-api-05 - Respond by May 25th, > 2020 > > > > Hi all, > > > > This message starts the two-week ANIMA Working Group Last Call to advance > draft-ietf-anima-grasp-api-05, Generic Autonomic Signaling Protocol > Application Program Interface (GRASP API). This document's intended status > is Informational. At present, there is no IPR file against this document. > This document has been ANIMA WG document since Dec, 2017 and have received > a few good review. The authors have addressed all known comments and think > the document is ready for WGLC. > > > > Please send your comments by May 25th, 2020. If you do not feel this > document should advance, please state your reasons why. > > > > Sheng JIANG is the assigned document shepherd. > > > > Regards, > > > > Sheng > > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima > --00000000000099d37505a7526eec Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks, we'll make a new version shortly with comment= s included. At the moment I think there will be no technical changes.
Regards
=C2=A0=C2=A0=C2=A0 Bri= an
=C2=A0=C2=A0=C2=A0 (via tiny screen & keyboard)

On Fri, 5 Ju= n 2020, 18:08 Sheng Jiang, <jia= ngsheng@huawei.com> wrote:

Hi, all,

=C2=A0

We received no negative response = to the WGLC on draft-ietf-anima-grasp-api-05 during the two-week WGLC and w= e did receive good reviews through the WG document stage, through the shepherd review process and WGLC period. Co= nsidering the past history of this work, I, with my ANIMA chair cap on, fee= l it has passed the WGLC and should advance. This conclusion is made with t= he condition that the authors would solve the received comments during the WGLC and these modifications were n= ot substantial changes from -05 version. If there are big changes, a shorte= r second WGLC may be needed.

=C2=A0

Up to now, there is no IPR disclo= sure to this document.

=C2=A0

Once the update is published and = it meets the above condition, for which the second WGLC is not needed, as t= he document shepherd, I will finalize the shepherd document and send the document on.

=C2=A0

Best regards,

=C2=A0

Sheng (Document Shepherd)<= u>

=C2=A0

From: Sheng Jiang
Sent: Monday, May 11, 2020 11:16 AM
To: Anima WG <anima@ietf.org>
Cc: anima-chairs@ietf.org; Toerless Eckert <tte@cs.fau.de= >
Subject: WGLC on draft-ietf-anima-grasp-api-05 - Respond by May 25th= , 2020

=C2=A0

Hi all,

=C2=A0

This message starts the two-week = ANIMA Working Group Last Call to advance draft-ietf-anima-grasp-api-05, Generic = Autonomic Signaling Protocol Application Program Interface (GRASP API). Thi= s document's intended status is Informational. At present, there is no = IPR file against this document. This document has been ANIMA WG document since Dec, 2017 and have received a few good re= view. The authors have addressed all known comments and think the document = is ready for WGLC.

=C2=A0

Please send your comments by May = 25th, 2020. If you do not feel this document should advance, please state y= our reasons why.

=C2=A0

Sheng JIANG is the assigned docum= ent shepherd.

=C2=A0

Regards,

=C2=A0

Sheng

=C2=A0

_______________________________________________
Anima mailing list
Anim= a@ietf.org
https://www.ietf.org/mailman/listinfo/anima
--00000000000099d37505a7526eec-- From nobody Sat Jun 6 01:43:26 2020 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 885633A0F9A; Sat, 6 Jun 2020 01:43:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.601 X-Spam-Level: X-Spam-Status: No, score=-9.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 mCEMZ1HdOitu; Sat, 6 Jun 2020 01:43:23 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 974B63A0F9B; Sat, 6 Jun 2020 01:43:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=273; q=dns/txt; s=iport; t=1591433002; x=1592642602; h=from:content-transfer-encoding:mime-version:subject: message-id:date:cc:to; bh=arto/WJ4otcr1GDZNt76pUFjDlIZin4sg7c1blfQ4NY=; b=NwM0x4i9oW27qFMftkQXyEAUiI3lAaVYATRgSrXtd61jElWmYcBAZEub eKKuzc8+59bK/YCkeP388mQiRwxbUHlCARrCgeq5A1htLGO9s0B2+YU/3 hxuu67XTOhuDQSCc1nKkLR+ELrABop89LARJgL1DGByA7iVWKXCyyHgKM Q=; X-IronPort-AV: E=Sophos;i="5.73,479,1583193600"; d="scan'208";a="26879104" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 06 Jun 2020 08:43:20 +0000 Received: from [10.61.199.107] ([10.61.199.107]) by aer-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id 0568hJBu032690 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 6 Jun 2020 08:43:20 GMT From: Eliot Lear Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Message-Id: Date: Sat, 6 Jun 2020 10:43:19 +0200 Cc: anima@ietf.org, "Rob Wilton (rwilton)" To: anima-chairs@ietf.org X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Outbound-SMTP-Client: 10.61.199.107, [10.61.199.107] X-Outbound-Node: aer-core-2.cisco.com Archived-At: Subject: [Anima] BRSKI-AE X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jun 2020 08:43:25 -0000 Chairs: The authors of draft-fries-anima-brski-async-enroll-03 have been = patiently awaiting follow-up from the previous meeting of this working = group in which we came away assuming that there would be a call for = adoption. When might we expect that? Eliot= From nobody Tue Jun 9 21:33:54 2020 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B44ED3A0E95 for ; Tue, 9 Jun 2020 21:33:53 -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 mRmXQxAXGVmR for ; Tue, 9 Jun 2020 21:33:49 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95F683A0E90 for ; Tue, 9 Jun 2020 21:33:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id BDBA838A24 for ; Wed, 10 Jun 2020 00:31:18 -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 MUQfDmA8mieX for ; Wed, 10 Jun 2020 00:31:14 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 9B9D938A23 for ; Wed, 10 Jun 2020 00:31:14 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 4C1A4486 for ; Wed, 10 Jun 2020 00:33:43 -0400 (EDT) From: Michael Richardson To: anima@ietf.org In-Reply-To: <159176190855.9169.7350787463977998504@ietfa.amsl.com> References: <159176190855.9169.7350787463977998504@ietfa.amsl.com> 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: [Anima] splitting up richardson-anima-masa-considerations into two pieces X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2020 04:33:54 -0000 --=-=-= Content-Type: text/plain We have split up richardson-anima-masa-considerations into two pieces: 1) the MASA operational considerations. This is the BRSKI specific part which was part two of the original document. It deals with generating vouchers, and how to create and manage the trust anchors that need to be built-into the firmware. internet-drafts@ietf.org wrote: > A new version of I-D, draft-richardson-anima-masa-considerations-04.txt > has been successfully submitted by Michael Richardson and posted to the > IETF repository. > URL: > https://www.ietf.org/internet-drafts/draft-richardson-anima-masa-considerations-04.txt I would welcome more discussion in ANIMA on this part. 2) draft-richardson-secdispatch-idevid-considerations which deals with how do build and operate the IDevID needed to make BRSKI operate. This document is not intended to be BRSKI specific, but deal with any use for IDevID certificates. Clearly other uses may have other needs, but it should be possible to build a superset system that makes everyone happy. https://datatracker.ietf.org/doc/draft-richardson-secdispatch-idevid-considerations/ Abstract: This document provides a number of operational modes that a manufacturer of devices that include IEEE 802.1AR IDevID certificates may choose from. Different ways of generating and signing the needed keypairs are detailed, and the security tradeoffs of each method are considered. This document provides a nomenclature for each mode. IDevID certificates are used in ANIMA's BRSKI Manufacturer Authorized Signing Authority (MASA) process. I will be asking secdispatch to consider what to do with this document. I say that there is a nomenclature, but I don't yet have a clue how to name the three (at least) ways of doing key generation. Part of the reason to split this document up is to make it easier to get this part reviewed widely. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl7gYqcACgkQgItw+93Q 3WXogwf9FAgnIkM1HL2SQpQNIbkGGw9dymui/egHnjXxK2Y4Yr9DQk4yKkXoCCYe vf2h7AnSP23Wlq3x756lioeot2CFSnwk4XApoX+/oci6gi2J2A/XFfnHA6W357bf aO4OczXSySYYDZJ/yAzP5AtU31mYRXl4AKuG76Ot8p3sMlVOjZTKuczTTNj/bzf9 wS2qtcmXYENyxonazosRBzXwI9lyK37N7DlMyiyjv1KjhibPazavAmk9T3O2T9tT 0ESahNrnCpmz/Hab0Tt5ifaxLTF5XV2PxIsA1YaC8lLfSeDqvY2UMIiTDy4oT/fs Fwy0ozK+bMcUW5wBwBZSQR4pPos/Rg== =2ZV3 -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Jun 10 08:52:01 2020 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 935703A094E; Wed, 10 Jun 2020 08:51:53 -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 CrMIVIkr-y00; Wed, 10 Jun 2020 08:51:51 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E01E73A093A; Wed, 10 Jun 2020 08:51:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 30CB138A39; Wed, 10 Jun 2020 11:49:19 -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 a6Dmv5aAHGJi; Wed, 10 Jun 2020 11:49:17 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 5069A38A37; Wed, 10 Jun 2020 11:49:17 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 5CF51534; Wed, 10 Jun 2020 11:51:46 -0400 (EDT) From: Michael Richardson to: secdispatch@ietf.org Reply-to: secdispatch@ietf.org CC: anima@ietf.org, spasm@ietf.org, lwip@ietf.org, acme@ietf.org In-Reply-To: <10463.1591763623@localhost> References: <159176190855.9169.7350787463977998504@ietfa.amsl.com> <10463.1591763623@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: [Anima] IDevID considerations document to secdispatch X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2020 15:52:00 -0000 --=-=-= Content-Type: text/plain Dear Secdispatch chairs and WG, (and various people in the BCC who are encouraged to forward) EXEC SUM: https://datatracker.ietf.org/doc/draft-richardson-secdispatch-idevid-considerations/ While working on ANIMA's BRSKI enrollment system, and the associated mechanisms that create the ACP, it became clear that there was possibly a wealth of useful advice on operating the Manufacturer and Owner components (the MASA and Registrar). As these thoughts grew, it became clear that there were many non-normative, non-wire-protocol level design considerations. Two documents were originally created: a) draft-richardson-anima-masa-considerations b) draft-richardson-anima-registrar-considerations Both situations involve operation of a certificate authority. On the manufacturer side, this involves the Manufacturer Installed Certificate, the IDevID. There are multiple users of the IDevID and there are many entities building a variety of trust models based upon having that trust model. For instance, the Kumari/Doyle Secure Device Install/draft-ietf-opsawg-sdi-12 leverages built-in certificates as much as BRSKI does. Much of the RATS work requires some kind of known signing key to be built-in, secured deep into a hardware or firmware TPM/enclave. If you want to (asymmetrically) encrypt firmware for SUIT, you may need keys built in too. Many other protocols also depend upon keys to be deployed, but can deal with having them deployed as part of configuration, but as we all experienced, actually getting them deployed can be difficult. As discussed at the RATS/SUIT/TEEP Hackathon, and later in a few WGs, there seems to be three ways to deploy matching private-key/certificates. a) generate key onboard, sign with EST/SCEP/CMP/magic<%>, b) generate keypair in CA, deploy with EST/SCEP/JTAG/magic, c) simultaneously/deterministically generate keypair from shared secret, deploy certificate via magic. I don't have good names for these three methods, nor sufficient proof that there isn't a reasonable fourth method. One reason (among many) to have names for these three methods is so that it is possible in Supply Chain Security discussions to be able to easily state the inherent security vested in the device, and to thus #include the risk/threat landscape of devices (particularly MCUs) that are included in designs. I believe that EST (RFC7030), SCEP (draft-gutmann-scep) and some lightweight profile of CMP (such as is in LAMPS) are reasonable protocols for factory time onboarding, but require very strict profiling to get right. This makes it IETF business. I would want to have a champion for (a)/(b)/(c) X {EST,SCEP,CMP}., ideally said champion would be describing active experience from a real factory. As publically anchored enterprise (intermediate) CAs seem to be a thing of the past, many have discussed how appropriate it might be for manufacturers to use ACME to provision IDevIDs directly. {In fact, I have running code} There are however many aspects of this effort which might reasonably be considered outside of the IETF perview. Fundamentally, these are PKIX objects that are being provisioned, and it is at the IETF that potential successors to PKIX (CoID, JWTs, etc.) are being developed. One of the major difficulties I have experienced in trying to assemble this document is that current methods are often buried in a Silicon vendor/OEM-board vendor interaction fearing many NDAs. This is particularly acute for method (c). This makes it difficult to ascertain what level of care has been taken with the sensitive symmetric keys, which results in a difficulty to compare audit results across the industry. In order to get better and wider review, as well as detailing the required magic, I've split the MASA considerations document into two pieces. One is BRSKI MASA RFC8366 voucher generation specific, which I intend to leave in the ANIMA WG (should the chairs agree), and the other part which is IDevID generation specific, which I am looking for advice from secdispatch to determine what to do with it. The second document is: https://datatracker.ietf.org/doc/draft-richardson-secdispatch-idevid-considerations/ and it is still rather drafty. I will note that draft-richardson-anima-registrar-considerations also discusses an Operator/Enterprise/Home-router having/operating a CA, (among many other things), and I am undecided whether or not to extract that advice and merge it into idevid-considerations. At this point, I think that it is not of general interest and it is better kept isolated. <%> leveraging Clarke's third law, but possibly also 1st and 2nd law as well. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl7hAZIACgkQgItw+93Q 3WUUzAgAkr2uWhXQXc69iIGeKa5xyIYJhwB6k62QcYcoPnWImogUfphZDopQa3n7 DUeU5C64E93u4dP3BfW12tOrjv/cGrWV3nVF81BqKAsT3qHm7sf7kC86yeI2IEMB D2OSq/pe0mfBIFNCT6jgWSNVFvns4GJLxKiWiPuqCJYKIbN2xX0txcOY+EMMrgu0 Wa/sq9DApfP53ZgHm0UK9gXSjuvoWIH6nq40A3T5AZf/JHhAO+gYfQqGQra0M4nH M6ex82L5ucsipq0RgTVFeEBcjcMQ1E7L1QPl7KRAKkW6ogAEt5BgwvWtDjjMSKKd mL0CuAkXOfqSzh3WgNAq14rjr/OQVA== =fgBt -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Jun 10 18:44:54 2020 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11A553A161A; Wed, 10 Jun 2020 18:44: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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-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 0yLJ_2GQ4FWA; Wed, 10 Jun 2020 18:44:47 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 09F053A03FF; Wed, 10 Jun 2020 18:44:47 -0700 (PDT) Received: from lhreml713-chm.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id A7BB27A5C26E3DBCEAE1; Thu, 11 Jun 2020 02:44:44 +0100 (IST) Received: from nkgeml706-chm.china.huawei.com (10.98.57.153) by lhreml713-chm.china.huawei.com (10.201.108.64) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Thu, 11 Jun 2020 02:44:44 +0100 Received: from nkgeml708-chm.china.huawei.com (10.98.57.160) by nkgeml706-chm.china.huawei.com (10.98.57.153) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Thu, 11 Jun 2020 09:44:41 +0800 Received: from nkgeml708-chm.china.huawei.com ([10.98.57.160]) by nkgeml708-chm.china.huawei.com ([10.98.57.160]) with mapi id 15.01.1913.007; Thu, 11 Jun 2020 09:44:41 +0800 From: Sheng Jiang To: Anima WG CC: "anima-chairs@ietf.org" , Warren Kumari , "Rob Wilton (rwilton)" Thread-Topic: Nomcom 2020-2021 Second Call For Volunteers Thread-Index: AdY/kddPJUY2V3jWTvCqwlkCBCJTGQ== Date: Thu, 11 Jun 2020 01:44:41 +0000 Message-ID: Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.108.222.155] Content-Type: multipart/alternative; boundary="_000_a0ea32904f8f40719bb62be8d6b7d83ehuaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [Anima] Nomcom 2020-2021 Second Call For Volunteers X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2020 01:44:53 -0000 --_000_a0ea32904f8f40719bb62be8d6b7d83ehuaweicom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, all, This is the second sending of the call for volunteers for the 2020-2021 Nom= Com. I wanted to mention a few updates from the previous email (sent 2 weeks ago= ): - I've fixed the URL at the bottom of the email to point to https://urldefe= nse.proofpoint.com/v2/url?u=3Dhttps-3A__datatracker.ietf.org_nomcom_2020_&d= =3DDwIDaQ&c=3DLFYZ-o9_HUMeMTSQicvjIg&r=3DLoGzhC-8sc8SY8Tq4vrfog&m=3DZsNIRqC= xjDeOYYDNalOSHcuwQG23wBJtxzmEnsbPBtI&s=3DNgIu-7Ij0nEdsFcbJOLcl2M56RxyREhLAt= caHLatD34&e=3D instead of /2019/. This was a test to see if anyone was paying attention. A= pparently, some people were. ;) - The IETF 108 registration form includes a checkbox that will let you volu= nteer. You can use this instead of emailing me, when you register for IETF = 108. - I currently have 39 volunteers. Last year had 149. I need more volunteers= ! ---------------------------------------------------------------------------= ------ The IETF NomCom appoints people to fill the open slots on the LLC, IETF Tru= st, the IAB, and the IESG. Ten voting members for the NomCom are selected in a verifiably random way f= rom a pool of volunteers. The more volunteers, the better chance we have of= choosing a random yet representative cross section of the IETF population. The details of the operation of the NomCom can be found in BCP 10 (RFC 8713= ). RFC 3797 details the selection algorithm. Special for this year (and only this year), we also have RFC 8788 (one-off = update to RFC 8713 / BCP 10) to tell us who is eligible to volunteer: Members of the IETF community must have attended at least three of the last five in-person IETF meetings in order to volunteer. The five meetings are the five most recent in-person meetings that ended prior to the date on which the solicitation for NomCom volunteers was submitted for distribution to the IETF community. Because no IETF 107 in-person meeting was held, for the 2020-2021 Nominating Committee those five meetings are IETFs 102 [Montreal, Canada; July 2018], 103 [Bangkok, Thailand; November 2018], 104 [Prague, Czech Republic; March 2019], 105 [Montreal, Canada; July 2019], and 106 [Singapore; November 2019]. Keep in mind that eligibility is based on in-person attendance at the five = listed meetings. You can check your eligibility at: https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_registr= ation_nomcom.py&d=3DDwIDaQ&c=3DLFYZ-o9_HUMeMTSQicvjIg&r=3DLoGzhC-8sc8SY8Tq4= vrfog&m=3DZsNIRqCxjDeOYYDNalOSHcuwQG23wBJtxzmEnsbPBtI&s=3D7_9x9PPoUIajJs2An= UFYg0KnEg8gkD3Jnwf1v079EQo&e Sheng + Toerless --_000_a0ea32904f8f40719bb62be8d6b7d83ehuaweicom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi, all,

 

This is the second sending of the call for volunt= eers for the 2020-2021 NomCom.

 

I wanted to mention a few updates from the previo= us email (sent 2 weeks ago):

- I've fixed the URL at the bottom of the email t= o point to https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__datatracker.ietf.org= _nomcom_2020_&d=3DDwIDaQ&c=3DLFYZ-o9_HUMeMTSQicvjIg&r=3DLoGzhC-= 8sc8SY8Tq4vrfog&m=3DZsNIRqCxjDeOYYDNalOSHcuwQG23wBJtxzmEnsbPBtI&s= =3DNgIu-7Ij0nEdsFcbJOLcl2M56RxyREhLAtcaHLatD34&e=3D

instead of /2019/. This was a test to see if anyo= ne was paying attention. Apparently, some people were. ;)

- The IETF 108 registration form includes a check= box that will let you volunteer. You can use this instead of emailing me, w= hen you register for IETF 108.

- I currently have 39 volunteers. Last year had 1= 49. I need more volunteers!

-------------------------------------------------= --------------------------------

The IETF NomCom appoints people to fill the open = slots on the LLC, IETF Trust, the IAB, and the IESG.

 

Ten voting members for the NomCom are selected in= a verifiably random way from a pool of volunteers. The more volunteers, th= e better chance we have of choosing a random yet representative cross secti= on of the IETF population.

 

The details of the operation of the NomCom can be= found in BCP 10 (RFC 8713). RFC 3797 details the selection algorithm.=

 

Special for this year (and only this year), we al= so have RFC 8788 (one-off update to RFC 8713 / BCP 10) to tell us who is el= igible to

volunteer:

 

     Members of the IETF comm= unity must have attended at least three of

     the last five in-person = IETF meetings in order to volunteer.

 

     The five meetings are th= e five most recent in-person meetings that

     ended prior to the date = on which the solicitation for NomCom

     volunteers was submitted= for distribution to the IETF community.

     Because no IETF 107 in-p= erson meeting was held, for the 2020-2021

     Nominating Committee tho= se five meetings are IETFs

       102 [Montrea= l, Canada; July 2018],

       103 [Bangkok= , Thailand; November 2018],

       104 [Prague,= Czech Republic; March 2019],

       105 [Montrea= l, Canada; July 2019], and

       106 [Singapo= re; November 2019].

 

Keep in mind that eligibility is based on in-pers= on attendance at the five listed meetings. You can check your eligibility a= t:

https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.iet= f.org_registration_nomcom.py&d=3DDwIDaQ&c=3DLFYZ-o9_HUMeMTSQicvjIg&= amp;r=3DLoGzhC-8sc8SY8Tq4vrfog&m=3DZsNIRqCxjDeOYYDNalOSHcuwQG23wBJtxzmE= nsbPBtI&s=3D7_9x9PPoUIajJs2AnUFYg0KnEg8gkD3Jnwf1v079EQo&e<= /o:p>

 

Sheng + Toerless

--_000_a0ea32904f8f40719bb62be8d6b7d83ehuaweicom_-- From nobody Fri Jun 12 13:04:12 2020 Return-Path: X-Original-To: anima@ietf.org Delivered-To: anima@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 07BC63A0E50; Fri, 12 Jun 2020 13:04:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: anima@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.3.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: anima@ietf.org Message-ID: <159199223998.7149.644853760215907868@ietfa.amsl.com> Date: Fri, 12 Jun 2020 13:04:00 -0700 Archived-At: Subject: [Anima] I-D Action: draft-ietf-anima-grasp-api-06.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2020 20:04:09 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Autonomic Networking Integrated Model and Approach WG of the IETF. Title : Generic Autonomic Signaling Protocol Application Program Interface (GRASP API) Authors : Brian Carpenter Bing Liu Wendong Wang Xiangyang Gong Filename : draft-ietf-anima-grasp-api-06.txt Pages : 30 Date : 2020-06-12 Abstract: This document is a conceptual outline of an application programming interface (API) for the Generic Autonomic Signaling Protocol (GRASP). Such an API is needed for Autonomic Service Agents (ASA) calling the GRASP protocol module to exchange autonomic network messages with other ASAs. Since GRASP is designed to support asynchronous operations, the API will need to be adapted to the support for asynchronicity in various languages and operating systems. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-anima-grasp-api/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-anima-grasp-api-06 https://datatracker.ietf.org/doc/html/draft-ietf-anima-grasp-api-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-anima-grasp-api-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jun 12 13:21:37 2020 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A8A93A0E74 for ; Fri, 12 Jun 2020 13:21:35 -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, FREEMAIL_FROM=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 Us3kbXcv8HVf for ; Fri, 12 Jun 2020 13:21:33 -0700 (PDT) Received: from mail-pj1-x1032.google.com (mail-pj1-x1032.google.com [IPv6:2607:f8b0:4864:20::1032]) (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 65E0B3A00AE for ; Fri, 12 Jun 2020 13:21:33 -0700 (PDT) Received: by mail-pj1-x1032.google.com with SMTP id jz3so4099554pjb.0 for ; Fri, 12 Jun 2020 13:21:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=tIC0EdCa6yAL2IFnk2ny+T6XjsATzagG/yAbztunUxk=; b=f5ckL5QMYUx3sJ2y25B9BHxKzveDZn9iPW9nxNLgpZm5gTGcHLTmjEnt1Xu44KAzjJ SGpSuMj4RleeViCMXv6eDKgwQN1Q7Fl69sEEw76K5lyGkaYJ72DM8MTylxCyOHevHxW2 sNMiWWKbDdKgrOn0RSKSZxZplmE1zfAWOXn2AVFCykZ4cxfaRt+NZSJmdYgfPUB6xQ18 UCrBiD2EpvN9u45UDbLcP6soFrgX18SG1OZqEM9xiQpUsIUA7Mqr9M//7iREzm427BG7 v/Jqu7+f4Cd/6BuUttFhqeu5rJSh1qWPjfOTh5mFQ3yNaorLXkPTi19pZ/vfhPzQYWT6 CPBQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=tIC0EdCa6yAL2IFnk2ny+T6XjsATzagG/yAbztunUxk=; b=RlOY6ICfwiUOD3ky0YKa2ihRVng5TxbPDqV25YdZDOrw2L7+dnlkUcE2pide40DPVM Rq0Tpgke4Sk3yUJaZI4hq9xBA/ryCpVQlektFXzXOovW9h7rauEBI1nhTgZ8WSpR9cQJ 3d5rI9WMnhZafox0TpzUQJBEOkLb8Ld5qTeNN+r+KNf7hPNCFn23rfuPHYdBcoH5bsCO YTJOOMLqfFbJy7EAtBLZkiSHe+3qX88tK/fLijgKAzsE+dnkJ2OuJGTiYMl3Gir1CHLm JsYjiQWc0XE6LrwLqiGghZLH0eEScqI/Fbg5kR46t8p+GHbcRe6LMzYtBYiFCeUVYm+L OSPg== X-Gm-Message-State: AOAM531Oao855MxDDKk+RwMBOtIr4g/ZP07UCFSnqvc2D1MqMoKvSwkK 7gR0+LtyGp5kKlOMh2y/QQ/QWYTk X-Google-Smtp-Source: ABdhPJz9Naybw2CDdIBOloTxrr38p/yiJsC67zftbj3zAi2kWDNbQ0KcxIK7U+fyOYs/dxStWcwlew== X-Received: by 2002:a17:90b:ecb:: with SMTP id gz11mr575462pjb.207.1591993291936; Fri, 12 Jun 2020 13:21:31 -0700 (PDT) Received: from [192.168.178.30] (72.252.69.111.dynamic.snap.net.nz. [111.69.252.72]) by smtp.gmail.com with ESMTPSA id o2sm5979558pjp.53.2020.06.12.13.21.30 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 12 Jun 2020 13:21:31 -0700 (PDT) To: anima@ietf.org References: <159199223998.7149.644853760215907868@ietfa.amsl.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <88a06d4f-9043-4fb1-3d88-91562592537f@gmail.com> Date: Sat, 13 Jun 2020 08:21:27 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <159199223998.7149.644853760215907868@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] I-D Action: draft-ietf-anima-grasp-api-06.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2020 20:21:35 -0000 Hi, This version was updated following the WG Last Call, mainly to handle the comments in Laurent's careful review. In my opinion the changes are all of an editorial nature, including useful clarifications; there is no change whatever to the technical details of the API. I will just mention a few points of interest: (1) Laurent suggested adding definitions for "idempotent", "atomic access", and "operating system locks". We expanded the text slightly for the first two, and removed the reference to locks. (2) "multi-threading, an event loop structure using polling, and an event loop structure using callback functions." Laurent suggested adding a reference for this, but we didn't find a good reference such as a standard textbook or a review article. Suggestions welcome. (3) Laurent said "Wherever a "timeout" parameter appears, it is an integer expressed in milliseconds. - why specify the unit in an informational document?)". We think it's necessary to specify the unit, since portable apps need portable units. (4) Laurent said "What is the reasoning for the default support of discovery for objectives? there may be situation where the exposure of the objectives should be controlled." Our response is that GRASP has no authorization model; we trust an ASA because it has access to the ACP. This aspect would change if we added an authorization model to GRASP, so it's not an API problem today. (It is a topic for future work in ANIMA!) Regards Brian Carpenter + co-authors On 13-Jun-20 08:04, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Autonomic Networking Integrated Model and Approach WG of the IETF. > > Title : Generic Autonomic Signaling Protocol Application Program Interface (GRASP API) > Authors : Brian Carpenter > Bing Liu > Wendong Wang > Xiangyang Gong > Filename : draft-ietf-anima-grasp-api-06.txt > Pages : 30 > Date : 2020-06-12 > > Abstract: > This document is a conceptual outline of an application programming > interface (API) for the Generic Autonomic Signaling Protocol (GRASP). > Such an API is needed for Autonomic Service Agents (ASA) calling the > GRASP protocol module to exchange autonomic network messages with > other ASAs. Since GRASP is designed to support asynchronous > operations, the API will need to be adapted to the support for > asynchronicity in various languages and operating systems. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-anima-grasp-api/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-anima-grasp-api-06 > https://datatracker.ietf.org/doc/html/draft-ietf-anima-grasp-api-06 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-anima-grasp-api-06 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima > From nobody Mon Jun 15 17:20:41 2020 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63DE43A0F13 for ; Mon, 15 Jun 2020 17:20:40 -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 Fx6UZT2YL6z1 for ; Mon, 15 Jun 2020 17:20:37 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32D613A0F12 for ; Mon, 15 Jun 2020 17:20:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id B550038A20; Mon, 15 Jun 2020 20:18:00 -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 bIWh4PZ3G5HW; Mon, 15 Jun 2020 20:17:59 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id A4E7638A1B; Mon, 15 Jun 2020 20:17:59 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 58A2435C; Mon, 15 Jun 2020 20:20:33 -0400 (EDT) From: Michael Richardson To: anima@ietf.org cc: Russ Housley , kaduk@mit.edu 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: [Anima] rfc822Name "abuse" in Autonomic Control Plane document X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2020 00:20:40 -0000 --=-=-= Content-Type: text/plain Hi, I have had a few conversations with Toerless who is trying to deal with the feedback on the ACP document. An item that has come up is the use, or claimed abuse of the rfc822Name SAN. We already had this debate. Some time ago. The WG decided. Three or four years ago, I think. I sure wish that we could use something else. But, CAs and CA software make that very difficult. Given that the era of publically anchored Enterprise CAs is dead, there are only two ways an (Enterprise) ACP Registrar is going to occur. 1) by running a private CA. Sure anything is possible if you are writing your own code, but most will not be doing that. (I've supported otherName in my code for other purposes, and it's not that difficult, but it's not trivial either) My experience with COTS CA systems it that it's really hard to get them to do it. Please prove me wrong. The most popular Enterprise CA software is the Microsoft CA. 2) by using ACME to speak to a hosted CA. Maybe WebPKI, maybe not. Either way, getting otherName supported is even harder, because nobody else uses it. If we can't depend upon otherName being filled in, then we have to look for two things. That means more code paths (two more) to test, more test vectors, and what exactly does an end point do when both are present, BUT THEY DO NOT MATCH? So three more pages of text there. Remember, that just rejecting the certificate means that we have to send out a truck, which is what ACP aims to avoid, so that won't be popular. And of course, there could also be bugs (maybe even CVEs) in the code that tries to deal with the tie. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl7oEFEACgkQgItw+93Q 3WU4kAgAv9gmEwDRJonl6p0gcG2VhM2fvCsoS+XbCrwNA+vYvPifKDOm8xwGHl/8 nyTuJ0YsAzM+2T7jhMFzb3chckkH5a91F1KbKuv5d14gBojxNWBgZV+Ixdbq6tIu QVDhVQ27gqCpkosOx3j2ua4m6A95PYoyYIUUmSd/Lp4QjVNIio7LB0oJJpekc1Vy VMfHFSfPT3f1wvqAb0ARQsCBGjaeR09J9lUTaUMsKGi4VtNyBc6EYQ7wW4JS+4AU I7TH162Zm1cyuLJaDL9NRqPBuVa8GPJf7Y8KQPmGgN7zgP3a97XFyxE/qv4rOgGI +BGzLKA+yEMGdQzd2cDvvhCmxpavTA== =R0HI -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Jun 15 19:14:35 2020 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42BC53A0F93 for ; Mon, 15 Jun 2020 19:14:33 -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, FREEMAIL_FROM=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 xn7fjTPUJt6x for ; Mon, 15 Jun 2020 19:14:31 -0700 (PDT) Received: from mail-pf1-x430.google.com (mail-pf1-x430.google.com [IPv6:2607:f8b0:4864:20::430]) (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 A589E3A0F6F for ; Mon, 15 Jun 2020 19:14:31 -0700 (PDT) Received: by mail-pf1-x430.google.com with SMTP id h185so8764048pfg.2 for ; Mon, 15 Jun 2020 19:14:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=rfxxhA6kvhZ7EcdodqyDsyraX19HpBhuoVtchfOXHao=; b=fFx9wjZrlZ+hOL5n76mJfYeFBEq8ye5GPmItlleBsutfKq68ZeFaRSQ6H4mGYvpVkb ccKwMHXucBS29OCl6iZ649zKH7vjdRDYRgAGHQGKKtvRZirIfO/6UXhkMS7dG2HErBQc VX0yfBr0HiVc+v7QmX+lRjmzmDO8c2zIohPEp9xjolizWSreoIgbqPnP8fy9ZL4YMWLr kSRBxU1IXbsKOxUze+bvinJXCW+nvRwmdb0NZBQpKOXlDt9NyxI0NEDzKrnLK7VJ8kAB i2798uxWEGRatHtmruvu0UaqH9vv9doGOwcu8gGNTXBa/gL3gsDLOJDyIbZ+d7lNXy8T wG1g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=rfxxhA6kvhZ7EcdodqyDsyraX19HpBhuoVtchfOXHao=; b=JmV6Zs9EwdN468AnBCiWTAs5NINxtV5DYx9k/lP0JOIEEbzGHAFPl7HNFAsy/BT7PY 0e3t8CgcQhFGoU9+0grScpzzj5t35WFVwcdMBb536uz6sGYC+h4+TIYYbbke4GNTYkWs 9VHzPUMFjixdaxZkH6pvmGu+FNVF2oyhQbUDYTyL2IPPbo1XPn/xPlaeHQY2aXtNvmMc fHJ0XQto+OSc6pbZuIWJNou2NNAB5uem98U4gU5GemqJ+j39fqoHuIZHcyZRrKd7aFkJ RZxS9lM1NTp6b1FA+1bXwptMFHWwGhpgsFBb6Vt7WpEVtOLrr6wVyVgAkeb5pfkpvse6 L5aA== X-Gm-Message-State: AOAM5319U00etk7Ln44sBRyB3zzYuax8FeqIWWQYAJpHqsn23HZkCCB+ BfovRapzUyTuipTjc2RkKs4= X-Google-Smtp-Source: ABdhPJz+E95SBzU16JVBbPRJcW/3F21VA9vmS287wAEdBWwG7KpL4WYclBoKuLPrXs5hSfwU6oRNRA== X-Received: by 2002:aa7:9052:: with SMTP id n18mr48039pfo.319.1592273670980; Mon, 15 Jun 2020 19:14:30 -0700 (PDT) Received: from [192.168.178.25] ([165.84.13.9]) by smtp.gmail.com with ESMTPSA id hv15sm682017pjb.17.2020.06.15.19.14.28 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 15 Jun 2020 19:14:30 -0700 (PDT) To: Michael Richardson , anima@ietf.org Cc: Russ Housley , kaduk@mit.edu References: <11428.1592266833@localhost> From: Brian E Carpenter Message-ID: Date: Tue, 16 Jun 2020 14:14:24 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <11428.1592266833@localhost> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] rfc822Name "abuse" in Autonomic Control Plane document X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2020 02:14:33 -0000 On 16-Jun-20 12:20, Michael Richardson wrote: > > Hi, I have had a few conversations with Toerless who is trying to deal with > the feedback on the ACP document. > > An item that has come up is the use, or claimed abuse of the rfc822Name SAN. > > We already had this debate. > Some time ago. The WG decided. > Three or four years ago, I think. Yes, this is relitigating an issue that was resolved a long time ago in discussing Ben's DISCUSS: https://mailarchive.ietf.org/arch/msg/anima/lnZ-ykqas487qih86sYNVsUGbsc The explanation is at https://tools.ietf.org/html/draft-ietf-anima-autonomic-control-plane-24#page-26 I believe it is incorrect IETF process to rediscuss this point yet again. Brian > > I sure wish that we could use something else. > But, CAs and CA software make that very difficult. > > Given that the era of publically anchored Enterprise CAs is dead, there are > only two ways an (Enterprise) ACP Registrar is going to occur. > > 1) by running a private CA. > Sure anything is possible if you are writing your own code, but > most will not be doing that. (I've supported otherName in my code for > other purposes, and it's not that difficult, but it's not trivial either) > My experience with COTS CA systems it that it's really hard to > get them to do it. Please prove me wrong. > The most popular Enterprise CA software is the Microsoft CA. > > 2) by using ACME to speak to a hosted CA. Maybe WebPKI, maybe not. > Either way, getting otherName supported is even harder, because > nobody else uses it. > > If we can't depend upon otherName being filled in, then we have to look for > two things. That means more code paths (two more) to test, more test > vectors, and what exactly does an end point do when both are present, BUT > THEY DO NOT MATCH? So three more pages of text there. > Remember, that just rejecting the certificate means that we have to send out > a truck, which is what ACP aims to avoid, so that won't be popular. > And of course, there could also be bugs (maybe even CVEs) in the code that > tries to deal with the tie. > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima > From nobody Tue Jun 16 19:44:23 2020 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F3ED3A0DD5 for ; Tue, 16 Jun 2020 19:44:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=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 VR0SXCL7W9bZ for ; Tue, 16 Jun 2020 19:44:20 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 B29C03A0DD3 for ; Tue, 16 Jun 2020 19:44:19 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 05H2iDCT023380 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 16 Jun 2020 22:44:15 -0400 Date: Tue, 16 Jun 2020 19:44:12 -0700 From: Benjamin Kaduk To: Brian E Carpenter Cc: Michael Richardson , anima@ietf.org, Russ Housley , sean+ietf@sn3rd.com Message-ID: <20200617024412.GA11992@kduck.mit.edu> References: <11428.1592266833@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [Anima] rfc822Name use in Autonomic Control Plane document X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2020 02:44:22 -0000 Hi Brian, Michael, On Tue, Jun 16, 2020 at 02:14:24PM +1200, Brian E Carpenter wrote: > On 16-Jun-20 12:20, Michael Richardson wrote: > > > > Hi, I have had a few conversations with Toerless who is trying to deal with > > the feedback on the ACP document. > > > > An item that has come up is the use, or claimed abuse of the rfc822Name SAN. > > > > We already had this debate. > > Some time ago. The WG decided. With all due respect, this is not the sole decision of the ANIMA WG to make. If WGs had such authority then why bother with cross-area review? > > Three or four years ago, I think. > > Yes, this is relitigating an issue that was resolved a long time ago in discussing Ben's DISCUSS: I'm not sure I understand why you use the word "resolved" here: > https://mailarchive.ietf.org/arch/msg/anima/lnZ-ykqas487qih86sYNVsUGbsc In this message, I say that "I still feel like this is not the best architectural choice" and that I will provide a sketch of an alternative in my (then-)forthcoming ballot position; that ballot position retains the Discuss-level concern about rfc822Name usage along with the promised alternative. > The explanation is at https://tools.ietf.org/html/draft-ietf-anima-autonomic-control-plane-24#page-26 I appreciate that the attempted justification is clearly written; however, I do not find it compelling. Russ did not, either, and I just heard back from Sean Turner a few days ago to confirm that he supports Russ's comments. (There should be a few other editorial-ish comments that came out of that review that are still pending.) > I believe it is incorrect IETF process to rediscuss this point yet again. (I'm not sure if the "yet again" refers to "after the WG decided" or "after the (alleged) resolution of my first Discuss point".) If you believe the technical answer is clear and that I am in error to continue to hold my Discuss point for it, are there not also clear IETF processes to follow? E.g., asking for the "Single Discuss" ballot procedure described at https://www.ietf.org/standards/process/iesg-ballots/? I believe I have mentioned this option to Toerless previously; my apologies if that is not the case. While I'm willing to continue discussing the topic and pull in additional PKIX experts to weigh in, there is perhaps some consideration to matters of expediency. > > > > I sure wish that we could use something else. > > But, CAs and CA software make that very difficult. > > > > Given that the era of publically anchored Enterprise CAs is dead, there are > > only two ways an (Enterprise) ACP Registrar is going to occur. > > > > 1) by running a private CA. > > Sure anything is possible if you are writing your own code, but > > most will not be doing that. (I've supported otherName in my code for > > other purposes, and it's not that difficult, but it's not trivial either) > > My experience with COTS CA systems it that it's really hard to > > get them to do it. Please prove me wrong. (Sadly, I have zero experience with COTS CA systems; I know too much about openssl at this point and would presumably be writing my own, in this position.) > > The most popular Enterprise CA software is the Microsoft CA. > > > > 2) by using ACME to speak to a hosted CA. Maybe WebPKI, maybe not. > > Either way, getting otherName supported is even harder, because > > nobody else uses it. Is the concern the ACME protocol support or just getting the hosted CA to cope with it? The former seems like something that we could make happen in the IETF, and the latter seems to have high overlap with point (1). > > If we can't depend upon otherName being filled in, then we have to look for > > two things. That means more code paths (two more) to test, more test > > vectors, and what exactly does an end point do when both are present, BUT > > THEY DO NOT MATCH? So three more pages of text there. > > Remember, that just rejecting the certificate means that we have to send out > > a truck, which is what ACP aims to avoid, so that won't be popular. > > And of course, there could also be bugs (maybe even CVEs) in the code that > > tries to deal with the tie. To be honest, this argument feels like a stronger one to me than the bits in the -24. I'm still not willing to accept into the RFC Series a document that violates the rules set down by the specification for the technology it's making use of, but the refocus on the "running code" aspect is appreciated. -Ben From nobody Tue Jun 16 22:31:40 2020 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AD483A0EBC; Tue, 16 Jun 2020 22:31:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.601 X-Spam-Level: X-Spam-Status: No, score=-9.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 JWTWWZq7Gvmp; Tue, 16 Jun 2020 22:31:22 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 906E73A0EBA; Tue, 16 Jun 2020 22:31:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5823; q=dns/txt; s=iport; t=1592371882; x=1593581482; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=Owsz3tmevHdZpRSxeDnh6JjvfyI/VGmta6z3StUOjZg=; b=GTMbVtuB976RC14i5Hfp7bCP4NJoZacJkqR76pEy4Ku8DTKN2mQOGDrf Q1c51iu23KCyMOlyUoX3DTZ3XVpQ5LSZ7YAI7JdKwVJ8SRlZ2+465ZXml RpiAVi8lb4oNbBs7nfoTx+7HRQddfCXwczkaXi0Wg96eWQziJidG8hyEW s=; X-Files: signature.asc : 488 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DBCwDvqele/xbLJq1mHAEBAQEBAQc?= =?us-ascii?q?BARIBAQQEAQFAgUoCgxdQBAEgEiyNJYgKm3wEBwEBAQkDAQEfEAQBAYFQgnU?= =?us-ascii?q?CgholOBMCAwEBCwEBBQEBAQIBBgRthVsMQgEQAYUeAQEBAQIBeQULCxgjC1c?= =?us-ascii?q?GE4MmAYJcILVxdIE0hVGFIxCBOAGBUolFgV2CAIERJxyCTT6BfoYGgi0Ejm6?= =?us-ascii?q?EQYZfmjSCZIMBgSaUeAMdnmisAoNOAgQGBQIVgWoiKYEtMxoIGxVlAYI+CTU?= =?us-ascii?q?SGQ2OKhcUgmaLLD8DMDcCBggBAQMJhiqIAi2CFwEB?= X-IronPort-AV: E=Sophos;i="5.73,521,1583193600"; d="asc'?scan'208";a="27191345" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 17 Jun 2020 05:31:17 +0000 Received: from ams3-vpn-dhcp4163.cisco.com (ams3-vpn-dhcp4163.cisco.com [10.61.80.66]) by aer-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id 05H5VGut002248 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 17 Jun 2020 05:31:17 GMT From: Eliot Lear Message-Id: <9B1718CC-EA1F-44E9-B175-B489B5BE7418@cisco.com> Content-Type: multipart/signed; boundary="Apple-Mail=_03704023-2E77-4104-AC4B-52BD2C02B42C"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Wed, 17 Jun 2020 07:31:16 +0200 In-Reply-To: <32493.1572639262@localhost> Cc: Benjamin Kaduk , draft-ietf-anima-bootstrapping-keyinfra@ietf.org, tte+ietf@cs.fau.de, anima-chairs@ietf.org, The IESG , anima@ietf.org To: Michael Richardson References: <157132132983.10248.1050846253932775557.idtracker@ietfa.amsl.com> <20191018012352.GB43312@kduck.mit.edu> <22000.1572299410@localhost> <20191029031843.GO69013@kduck.mit.edu> <32493.1572639262@localhost> X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Outbound-SMTP-Client: 10.61.80.66, ams3-vpn-dhcp4163.cisco.com X-Outbound-Node: aer-core-2.cisco.com Archived-At: Subject: Re: [Anima] Benjamin Kaduk's Discuss on draft-ietf-anima-bootstrapping-keyinfra-28: (with DISCUSS and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2020 05:31:25 -0000 --Apple-Mail=_03704023-2E77-4104-AC4B-52BD2C02B42C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, Could we recap a bit on this? I have commented on the use of the = rfc822Name myself, and was a bit concerned about misuse and = misinterpretation prior to rfcSELF being present. Now that it is it represents a new convention. The question at hand is = whether the information found on the LHS could be subject to = misinterpretation by non-participants. I wonder if we could add an EKU = as a SHOULD to break the logjam. Eliot > On 1 Nov 2019, at 21:14, Michael Richardson = wrote: >=20 > Signed PGP part >=20 > Benjamin Kaduk wrote: > doc> although it results in additional network traffic. The = relying MASA > doc> implementation MAY leverage internal state to associate this = request > doc> with the original, and by now already validated, = voucher-request so > doc> as to avoid an extra crypto validation. >>>=20 >>>> It seems that doing so would turn the voucher-request into a bearer >>>> token for retrieving audit-log information (if the MASA accepts >>>> unauthenticated clients). >>>=20 >>> That's what's intended. >=20 >> I can see why that functionality is needed, but it seems likely to >> introduce some privacy and/or security considerations to document. = It's a >> bit too late in the day for me to reason through them, though. >=20 > To be clear: any registrar which has ever formed a valid = voucher-request MAY > retrieve the audit-log at regular intervals to verify the status of = the > device. The words, "now already validated" means that the MASA agreed = with > the voucher-request. Most implementations are going to log the > voucher-request as part of the internal audit log, so a memcmp() on = that is enough. >=20 > This would reveal new owners. Whether the new owner is legitimate or = not is > not something we can answer: it might be that the device has been = stolen, or > maybe it's legitimately lent, rented, sold, etc. >=20 >>>> Section 11 >>>=20 >>>> I am somewhat embarassed that I did not previously note that the >>>> mechanism used to generate the domainID needs to be >>>> second-preimage-resistant or an attacker can claim to be a = registrar for >>>> a domain that already exists. >>>=20 >>> Right now, that's in: >>>=20 >>> 5.8.2. Calculation of domainID >>>=20 >>> The domainID is a binary value (a BIT STRING) that uniquely >>> identifies a Registrar by the "pinned-domain-cert" >>>=20 >>> If the "pinned-domain-cert" certificate includes the >>> SubjectKeyIdentifier (Section 4.2.1.2 [RFC5280]), then it is to be >>> used as the domainID. If not, the SPKI Fingerprint as described in >>> [RFC7469] section 2.4 is to be used. This value needs to be >>> calculated by both MASA (to populate the audit-log), and by the >>> Registrar (to recognize itself). >>>=20 >>> We tried hard and found a way not to say SHA-1 directly, allowing = SHA256 to >>> replace it appropriately. >=20 >> That's all good and admirable; I'm suggesting that we add a note in = the >> security considerations of this document noting that we rely on the >> domainID (however determined) to be second-preimage-resistant. >=20 > I've added this to the security considerations as 11.2. >=20 > doc> Although the nonce used by the Pledge in the voucher-request = does not > doc> require a strong cryptographic randomness, the use of TLS in = all of > doc> the protocols in this document does. >>>=20 >>>> We discuss the need for strong randomness in the nonce in Section = 11.3, >>>> so it's not clear this is actually true. >>>=20 >>> We don't think that the voucher nonce has to be of the same quality = as something that >>> goes into a KDF. It is at the level of TCP Sequeunce number, not = seed for >>> generating a private key... >=20 >> I mean, we literally say "Reducing the possibility of this is why the >> pledge is mandated to generate a strong random or pseudo-random = number >> nonce." So to also say "the nonce [...] does not require a strong >> cryptographic randomness" seems to be in conflict with the former >> statement. >> Are you saying that "strong random" and "strong cryptographic random" = mean >> different things, or am I misreading the document in some other way? >=20 > I take your point, and I guess we were splitting hairs. > I'll just rephrase it to remove the Although statement. >=20 > -- > ] 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 [ >=20 >=20 >=20 > -- > Michael Richardson , Sandelman Software Works > -=3D IPv6 IoT consulting =3D- >=20 >=20 >=20 >=20 >=20 --Apple-Mail=_03704023-2E77-4104-AC4B-52BD2C02B42C Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAl7pqqQACgkQh7ZrRtnS ejNtDggAgQ+YJ5l3L6kUqHTVwwrFwqUt6kXIlXNoZsYRCQYzMZ017bH3d9ph18Z8 Cl5ApO5Bm9HscVclE7Myarv/PxPnqEaX8BY7S8IwAyGuCSHprJTWLoFK13ahanav xIJOgUVOVe6s/SuwGyj1cCczERI+Oc4lOGVPhgyvjypbmLG6lYlFPhC650VITMTE 4JRfejNhMRWMbFL1VtnlJ0dtAC7R1nzJIvB+Y+C+H6NOZBKEacc7taCFAZGyp4F0 sYaI7TMFpS4JzbjIn/M9q2nRhlOyQuyb2FfPkEPQfgI6t5lHWLjQ6W/q/bXK0Kn4 Q4WnvrLY/mVwVbpvKt7iHOSWAGU6qg== =SXei -----END PGP SIGNATURE----- --Apple-Mail=_03704023-2E77-4104-AC4B-52BD2C02B42C-- From nobody Wed Jun 17 09:10:15 2020 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 034213A093C; Wed, 17 Jun 2020 09:10:14 -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 GQmHtd0hhGuc; Wed, 17 Jun 2020 09:10:12 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37F123A0948; Wed, 17 Jun 2020 09:10:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 8C78338A08; Wed, 17 Jun 2020 12:07:34 -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 DLFzGBnHtwIV; Wed, 17 Jun 2020 12:07:30 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 27BB1389EF; Wed, 17 Jun 2020 12:07:30 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 41CF4FAC; Wed, 17 Jun 2020 12:10:05 -0400 (EDT) From: Michael Richardson To: Eliot Lear cc: Benjamin Kaduk , draft-ietf-anima-bootstrapping-keyinfra@ietf.org, tte+ietf@cs.fau.de, anima-chairs@ietf.org, The IESG , anima@ietf.org In-Reply-To: <9B1718CC-EA1F-44E9-B175-B489B5BE7418@cisco.com> References: <157132132983.10248.1050846253932775557.idtracker@ietfa.amsl.com> <20191018012352.GB43312@kduck.mit.edu> <22000.1572299410@localhost> <20191029031843.GO69013@kduck.mit.edu> <32493.1572639262@localhost> <9B1718CC-EA1F-44E9-B175-B489B5BE7418@cisco.com> 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: [Anima] Benjamin Kaduk's Discuss on draft-ietf-anima-bootstrapping-keyinfra-28: (with DISCUSS and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2020 16:10:14 -0000 --=-=-= Content-Type: text/plain Eliot Lear wrote: > Could we recap a bit on this? I have commented on the use of the > rfc822Name myself, and was a bit concerned about misuse and > misinterpretation prior to rfcSELF being present. The rational for rfc822Name (which I fought against 4 years ago), is that: a) it gets through existing CA infrastructure without changes b) the human presentation format is *the* format If ACP needs to wait for upgrades to the Enterprise CA that nobody wants to touch, because it's voodoo, then ACP is dead. This is hard enough to get deployed as it is. > Now that it is it represents a new convention. The question at hand is > whether the information found on the LHS could be subject to > misinterpretation by non-participants. I wonder if we could add an EKU > as a SHOULD to break the logjam. Because EKUs are so much easier to get into CAs than otherName is? Seriously, how does that help at all? -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl7qQFwACgkQgItw+93Q 3WV5ewf/WrSM7ofUDef50lrojVn+eQfpbkxdSakYPLHX/Mwqwi20RSoIOj17bvUD bEqe0YhcH5MfJW/qECXZCWACVS6g+bC/67TA3t803p8JTwbYs1vBjKpVIXm/t+2P Mlzf93pJyqKO5lAp+pBgpjWzmhaz4Gwl8TljZ9PR0HBj3DkWQZ9ATZqSzbT2Dv84 ap13vQNxVJ+E9mAakH3++ljxB1MSsqVgyBtKBtpf2jh+9lizpR4Y/Ky3fpbkm3+/ VUL4cufgssLO9/JzwqHwE4wNlc2pcLF6DZXn2lpWJVbTS4lDxCcAqV6n/QI3ZiRB 6mDR72U4CyiJX3YU9vP+wZIct9r1Qw== =EAC+ -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Jun 17 09:49:10 2020 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74DDD3A0A85; Wed, 17 Jun 2020 09:49:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.6 X-Spam-Level: X-Spam-Status: No, score=-9.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 imk6GqWev5lH; Wed, 17 Jun 2020 09:49:03 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7468F3A0A78; Wed, 17 Jun 2020 09:49:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5337; q=dns/txt; s=iport; t=1592412543; x=1593622143; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=Kn4emAN1ijHVc1NN00MvJ5rhSEbw0405gW850qOdFkM=; b=h1lW4aezy4Jqnr8jLeBDrjvCLigi6pgG4ff+lfS+srvWCbvgyIIPgR6C 1R+0eiVIwgQPMFqhNS/lo7xfUjiKbnl+B4dMtogbutMiNZG/rCw/cNEXn QZQ36Dtz/y3bD0YwB80h8/gKkQKHI1lIGoNy9soW3tn+3cjxs633yRWfy 4=; X-Files: signature.asc : 488 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DjAQDBSOpe/xbLJq1mGwEBAQEBAQE?= =?us-ascii?q?BBQEBARIBAQEDAwEBAYIKAoEhgkoBIBIshCSJAYdkJYdVjBWIEgQHAQEBCQM?= =?us-ascii?q?BAS8EAQGERAKCGyU4EwIDAQELAQEFAQEBAgEGBG2FZ0IBEAGFHgEBAQECASN?= =?us-ascii?q?WBQsLGCMHAgJXBhODJgGCXCC2P3aBMoVRhRsQgTgBgVKLJoIAgREnDBCCTT6?= =?us-ascii?q?HUTOCLQSaE5o2gmSDAYEmlHoDHZ5urA6DTgIEBgUCFYFqIoFWMxoIGxVlAYI?= =?us-ascii?q?+PhIZDY5VjhI/AzA3AgYBBwEBAwmGL4peAQE?= X-IronPort-AV: E=Sophos;i="5.73,523,1583193600"; d="asc'?scan'208,217";a="27224561" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 17 Jun 2020 16:48:58 +0000 Received: from ams3-vpn-dhcp4079.cisco.com (ams3-vpn-dhcp4079.cisco.com [10.61.79.239]) by aer-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id 05HGmvMQ030580 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 17 Jun 2020 16:48:57 GMT From: Eliot Lear Message-Id: <64D4A29B-AECC-47B7-9042-30BC1C36EF0F@cisco.com> Content-Type: multipart/signed; boundary="Apple-Mail=_AD7175D3-2F91-4D9C-952B-9C38A0B7CA75"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Wed, 17 Jun 2020 18:48:56 +0200 In-Reply-To: <4603.1592410205@localhost> Cc: draft-ietf-anima-bootstrapping-keyinfra@ietf.org, anima-chairs@ietf.org, Benjamin Kaduk , tte+ietf@cs.fau.de, anima@ietf.org, The IESG To: Michael Richardson References: <157132132983.10248.1050846253932775557.idtracker@ietfa.amsl.com> <20191018012352.GB43312@kduck.mit.edu> <22000.1572299410@localhost> <20191029031843.GO69013@kduck.mit.edu> <32493.1572639262@localhost> <9B1718CC-EA1F-44E9-B175-B489B5BE7418@cisco.com> <4603.1592410205@localhost> X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Outbound-SMTP-Client: 10.61.79.239, ams3-vpn-dhcp4079.cisco.com X-Outbound-Node: aer-core-4.cisco.com Archived-At: Subject: Re: [Anima] Benjamin Kaduk's Discuss on draft-ietf-anima-bootstrapping-keyinfra-28: (with DISCUSS and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2020 16:49:05 -0000 --Apple-Mail=_AD7175D3-2F91-4D9C-952B-9C38A0B7CA75 Content-Type: multipart/alternative; boundary="Apple-Mail=_43E6A472-DA24-4ABF-8BA3-1B7FB43DF4C4" --Apple-Mail=_43E6A472-DA24-4ABF-8BA3-1B7FB43DF4C4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 17 Jun 2020, at 18:10, Michael Richardson = wrote: >=20 >>=20 >> Now that it is it represents a new convention. The question at hand = is >> whether the information found on the LHS could be subject to >> misinterpretation by non-participants. I wonder if we could add an = EKU >> as a SHOULD to break the logjam. >=20 > Because EKUs are so much easier to get into CAs than otherName is? > Seriously, how does that help at all? I have definitely seen at least some CAs allow EKUs, such as XMPP, for = instance, and was thinking of SHOULD rather than MUST. But I do have to = say that XMPP didn=E2=80=99t have a great experience with them, to be = fair. Eliot --Apple-Mail=_43E6A472-DA24-4ABF-8BA3-1B7FB43DF4C4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 17 Jun 2020, at 18:10, Michael Richardson <mcr+ietf@sandelman.ca> wrote:


Now that it is it represents a new = convention.  The question at hand is
whether the = information found on the LHS could be subject to
misinterpretation by non-participants.  I wonder if we = could add an EKU
as a SHOULD to break the logjam.

Because EKUs are so much easier to get into CAs than = otherName is?
Seriously, = how does that help at all?

I have definitely seen at least some CAs = allow EKUs, such as XMPP, for instance, and was thinking of SHOULD = rather than MUST.  But I do have to say that XMPP didn=E2=80=99t = have a great experience with them, to be fair.

Eliot
= --Apple-Mail=_43E6A472-DA24-4ABF-8BA3-1B7FB43DF4C4-- --Apple-Mail=_AD7175D3-2F91-4D9C-952B-9C38A0B7CA75 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAl7qSXgACgkQh7ZrRtnS ejPEvQgAmSf2s52+fOFN317vYBf8mX8Yl6Ga20lQerQfEfMaUOT1yr6VxDxR2I24 wbb4shl7v4Pw2oIt8DbF4uJfOQjaKRfjXbdYkCY4hgQNsl+mO1N9/7GWrXu1l1s5 FEH3Bmtp6OtorGJTlRW/k0qvWBdNIy8+PzD932i8v1eZCpIEPgcAhH8jsn0/kCg1 ugYJvQwrRSzdmi78I2msihca3ads3ooMyFWLWUWs79egwtPFYX1bVi6NlZuGKNW/ pbXqZbcD/GqV3n/yTv7uYY6QqmRTPOSMZzqIV9lxHtvM5jb+s/A6uGfYytrwX8es QtUL6iLN8v9GMKJtA8A8px4bru3GeA== =0gVA -----END PGP SIGNATURE----- --Apple-Mail=_AD7175D3-2F91-4D9C-952B-9C38A0B7CA75-- From nobody Wed Jun 17 13:08:42 2020 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7B6F3A00D6 for ; Wed, 17 Jun 2020 13:08: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 GSX3Doetxni8 for ; Wed, 17 Jun 2020 13:08:39 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2578B3A00C4 for ; Wed, 17 Jun 2020 13:08:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 2A88D38A12; Wed, 17 Jun 2020 16:06:01 -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 5ww5VHkqBh-3; Wed, 17 Jun 2020 16:06:00 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 5744B38A05; Wed, 17 Jun 2020 16:06:00 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 966DA209; Wed, 17 Jun 2020 16:08:35 -0400 (EDT) From: Michael Richardson To: Benjamin Kaduk , Brian E Carpenter , anima@ietf.org, Russ Housley , sean+ietf@sn3rd.com In-Reply-To: <20200617024412.GA11992@kduck.mit.edu> References: <11428.1592266833@localhost> <20200617024412.GA11992@kduck.mit.edu> 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: [Anima] rfc822Name use in Autonomic Control Plane document X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2020 20:08:42 -0000 --=-=-= Content-Type: text/plain Ben, this is getting very very tiresome. PLEASE go read RFC7282. "Rough consensus is achieved when all issues are addressed, but not necessarily accommodated" Also: A diligent chair who's been carefully listening to the discussion might think, "I have heard person X make this objection, and I've heard responses from many other folks that really address the issue. I think we have rough consensus. I will note that *I* objected to rfc822Name. (And that I changed my mind. I can live with it) But, you have been effectively weidling a veto on quite a number of drafts, and that is not in the spirit of rough consensus. It's just not your job. If it were your job, then we would not have WGs, Adopton calls, we would not do WGLC reviews, nor WG charters, etc. We'd just submit our documents to you. But, this is not only your fault: had the rest of the IESG actually voted rather than Abstained or No Comment, then we'd have actual rough consensus, and the IESG seems to have abandonned that. Benjamin Kaduk wrote: > On Tue, Jun 16, 2020 at 02:14:24PM +1200, Brian E Carpenter wrote: >> On 16-Jun-20 12:20, Michael Richardson wrote: >> > >> > Hi, I have had a few conversations with Toerless who is trying to deal with >> > the feedback on the ACP document. >> > >> > An item that has come up is the use, or claimed abuse of the rfc822Name SAN. >> > >> > We already had this debate. >> > Some time ago. The WG decided. > With all due respect, this is not the sole decision of the ANIMA WG to > make. If WGs had such authority then why bother with cross-area > review? https://datatracker.ietf.org/doc/draft-ietf-anima-autonomic-control-plane/ says: Reviews RTGDIR Last Call Review: Not Ready IOTDIR Early Review (of -18): Ready SECDIR Telechat Review (of -16): Has Issues GENART Telechat Review (of -16): Ready with Nits RTGDIR Telechat Review (of -13): Ready SECDIR Early Review (of -13): Has Issues GENART Last Call Review (of -13): Not Ready (Unfortunate that many reviewers do not update their opinion when we act on their advice. So, for instance, the SECDIR review says in her text that it is ready) I guess you feel that it hasn't been cross-area reviewed unless you have blessed it? I think you should probably disband the SECDIR, because they are clearly not helping you or anybody. In fact, those reviews are just wasting everyone's time. So, our process is that the *WG* takes these views into account, and then makes a decision. That includes sponsoring AD reviews and IESG comments. The WG took the objections to rfc822Name into account already. You do not have the right to override the WG decision. -- ] 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 [ -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl7qeEMACgkQgItw+93Q 3WXG9gf/QDJvjKi0w00tk19AlfiXfm4l2SboUZOGglwWcu6VUabNf9uEnQ7wC8xV ncyB3Cs+ulwnsElniOF/NLNvvPr/O99C3QiU0LRigutFFDC18ASO6mRKTAdvb7Ka DBwoT2FMZjc6IqQRTeKGcBzABLmy8wM/hQXP9xY6unG44qWV4X4fxbJd0H1Nvz4/ 9/CbEQ5C9p5kHDwmrUvydp6D1aliINoBTng+qOwd3bozkB6UP9AgR5ouY1OgwmpJ 81qkPUzAYnyVitQ3T3hi99NW61X7YVWxM07TMk9whqmPb3lH5T85dloMRCnPn1YB 4kElzfx3QeoFondEu+3yRGU97Aa4Tw== =Xi2s -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Jun 18 02:27:42 2020 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A13483A1163; Thu, 18 Jun 2020 02:27:40 -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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-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 jR_EqMRlRuEG; Thu, 18 Jun 2020 02:27:39 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 D4DFD3A1161; Thu, 18 Jun 2020 02:27:38 -0700 (PDT) Received: from lhreml718-chm.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 91D71D15E748C71222A0; Thu, 18 Jun 2020 10:27:37 +0100 (IST) Received: from nkgeml707-chm.china.huawei.com (10.98.57.157) by lhreml718-chm.china.huawei.com (10.201.108.69) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Thu, 18 Jun 2020 10:27:36 +0100 Received: from nkgeml708-chm.china.huawei.com (10.98.57.160) by nkgeml707-chm.china.huawei.com (10.98.57.157) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Thu, 18 Jun 2020 17:27:34 +0800 Received: from nkgeml708-chm.china.huawei.com ([10.98.57.160]) by nkgeml708-chm.china.huawei.com ([10.98.57.160]) with mapi id 15.01.1913.007; Thu, 18 Jun 2020 17:27:34 +0800 From: Sheng Jiang To: Anima WG CC: "anima-chairs@ietf.org" , "Rob Wilton (rwilton)" Thread-Topic: Adoption call for draft-fries-anima-brski-async-enroll-03, ends July 1st 2020 Thread-Index: AdZFUcOGlfvPowoQSbyiu0kg7sJTWQ== Date: Thu, 18 Jun 2020 09:27:33 +0000 Message-ID: Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.108.222.155] Content-Type: multipart/alternative; boundary="_000_f8c2df730dad489d88303c6d8682caeehuaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [Anima] Adoption call for draft-fries-anima-brski-async-enroll-03, ends July 1st 2020 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2020 09:27:41 -0000 --_000_f8c2df730dad489d88303c6d8682caeehuaweicom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, ANIMAer, This message starts a two-week adoption call, it ends on July 1st, 2020. draft-fries-anima-brski-async-enroll-03 has been presented to the WG for a = long while and the WG showed good interest and had discussions. The draft i= s now clearly in scope of ANIMA charter 2 that was adopted around IETF106. = The authors asked for adoption of the document. Giving the dependent BRSKI = has passed the IESG evaluation, the chairs feel that it may be the right ti= me to call the adoption. We therefore are asking the ANIMA working group for adoption of the followi= ng work: Title: Support of asynchronous Enrollment in BRSKI Name: draft-fries-anima-brski-async-enroll-03 Authors: S. Fries, H. Brockhaus and E. Lear URL: https://datatracker.ietf.org/doc/draft-fries-anima-brski-async-en= roll/ This document is intended to become a standards track ANIMA WG document. Please express your support or rejection. If you think this document should= _not_ be adopted, please also explicitly indicate the reasons. Regards, Sheng --_000_f8c2df730dad489d88303c6d8682caeehuaweicom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi, ANIMAer,

 

This message starts a two-week adoption call, it en=
ds on July 1st, 2020.
 
draft-fries-anima-brski-async-enroll-03 has been pr=
esented to the WG for a long while and the WG showed good interest and had =
discussions. The draft is now clearly in scope of ANIMA charter 2 that was =
adopted around IETF106. The authors asked for adoption of the document. Giv=
ing the dependent BRSKI has passed the IESG evaluation, the chairs feel tha=
t it may be the right time to call the adoption.
 
We therefore are asking the ANIMA working group for=
 adoption of the following work:
 
Title:    Support of asynchronous En=
rollment in BRSKI
Name:     draft-fries-anima-brs=
ki-async-enroll-03
Authors:  S. Fries, H. Brockhaus and E. Lear
URL:      https://datatracker.ietf.org/doc/draft-fries-anima-brski-async-enroll/=

 
This document is intended to become a standards tra=
ck ANIMA WG document.
 
Please express your support or rejection. If you th=
ink this document should _not_ be adopted, please also explicitly indicate =
the reasons.
 
Regards,
 
Sheng

 

--_000_f8c2df730dad489d88303c6d8682caeehuaweicom_-- From nobody Thu Jun 18 09:37:32 2020 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 156483A0940 for ; Thu, 18 Jun 2020 09:37:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.6 X-Spam-Level: X-Spam-Status: No, score=-9.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 FTHw3LBUb4Dg for ; Thu, 18 Jun 2020 09:37:27 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 045153A0941 for ; Thu, 18 Jun 2020 09:37:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=43582; q=dns/txt; s=iport; t=1592498247; x=1593707847; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=A+mq7NSJ2Uu5ylRQJQSQqxFQ6UUqXUtdY+KmCnkVutk=; b=Yx5NZomA7ks0UDbMo36M4fyLSX6/W/93q5Ut/zpdI36eqsrHFd/nxnoS TqzYm3S3Gytt+V1Cn4aN/XxwzwoVWTuQ7BMjzIHU93QYCs1iN6iMvdAM4 qPvtMD29e5/4xSskIxlxbCRMy77Mj43iCNyd4AU00SgPutKvPyYj/PA2g g=; X-IPAS-Result: =?us-ascii?q?A0BeAABVl+te/xbLJq1mDgsBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QESAQEBAQEBAQEBAQEBggoCgSEBgXVUASASLIQkiQGICIMQmGgFCwEBAQwBA?= =?us-ascii?q?RgBDAoEAQGBUIJ0AoInJTgTAgMBAQEDAgMBAQEBBQEBAQIBBgRthVsMQgEQA?= =?us-ascii?q?YUeAQEBAQMBASFIAwsQCxcBIAEJAgInKAgGExuDCwGCfA+3MXaBMoQ6AQMCg?= =?us-ascii?q?RGFN4E4AYtAgTiCAIERJxyBfSIuPoIjOQEBAgGBMxGDLDOCCyIEjnKCdocam?= =?us-ascii?q?0mCZIMChUCQZQMdgnCBF4gIkmSZZYFSkFuDTgIEBgUCFYFAKiKBVjMaCBsVO?= =?us-ascii?q?yoBggoBMwk1EhkNjioXg06FFIUEQD8DMAILKgIGAQcBAQMJhg2IHgImB4IXA?= =?us-ascii?q?QE?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos; i="5.75,251,1589241600"; d="scan'208,217"; a="24824969" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 18 Jun 2020 16:37:22 +0000 Received: from ams3-vpn-dhcp4671.cisco.com (ams3-vpn-dhcp4671.cisco.com [10.61.82.62]) by aer-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id 05IGbLtI008515 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 18 Jun 2020 16:37:22 GMT From: Eliot Lear Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_DCC78DC6-BAF6-486B-A4E4-AA85FA11BCB4" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Thu, 18 Jun 2020 18:37:20 +0200 In-Reply-To: <20200617024412.GA11992@kduck.mit.edu> Cc: Brian E Carpenter , Michael Richardson , sean+ietf@sn3rd.com, Russ Housley , anima@ietf.org To: Benjamin Kaduk References: <11428.1592266833@localhost> <20200617024412.GA11992@kduck.mit.edu> X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Outbound-SMTP-Client: 10.61.82.62, ams3-vpn-dhcp4671.cisco.com X-Outbound-Node: aer-core-4.cisco.com Archived-At: Subject: Re: [Anima] rfc822Name use in Autonomic Control Plane document X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2020 16:37:30 -0000 --Apple-Mail=_DCC78DC6-BAF6-486B-A4E4-AA85FA11BCB4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Ok, so I just want to add that I have been able to populate otherName = with garbage and have it get signed by a public CA. My point is that at = least some public CAs are loose. If LE is important to this space, and = if it=E2=80=99s really important, then this is not a solution. Anyway, = Here was the line that I used for my jabber server (it=E2=80=99s = certainly not correct): subjectAltName =3D = DNS:www.ofcourseimright.com,DNS:upstairs.ofcourseimright.com,otherName:1.3= .6.1.5.5.7.8.7;IA5:ofcourseimright.com,otherName:1.3.6.1.5.5.7.8.7;IA5:_xm= pp-client._tcp.ofcourseimright.com,otherName:1.3.6.1.5.5.7.8.7;IA5:_xmpp-s= erver._tcp.ofcourseimright.com,otherName:1.3.6.1.5.5.7.8.7;UTF8:ofcourseim= right.com And here=E2=80=99s what I got: McNext> openssl x509 -noout -text -in jabber_ofcourseimright_com.crt=20 Certificate: Data: Version: 3 (0x2) Serial Number: 58:12:20:cd:47:fe:82:af:35:8d:75:50:75:05:a6:cb Signature Algorithm: sha256WithRSAEncryption Issuer: C=3DGB, ST=3DGreater Manchester, L=3DSalford, O=3DSectigo = Limited, CN=3DSectigo RSA Domain Validation Secure Server CA Validity Not Before: Jun 18 00:00:00 2020 GMT Not After : Jul 18 23:59:59 2020 GMT Subject: CN=3Djabber.ofcourseimright.com Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (2048 bit) Modulus: 00:9e:c8:c0:61:b6:5c:d1:fc:bf:2d:d2:13:6b:db: 97:09:45:e8:22:bf:89:24:7e:09:01:fe:91:37:85: ee:25:77:54:92:68:05:07:d2:70:f5:6f:5c:fc:b4: c6:7f:2d:e6:3e:11:68:4b:55:74:10:39:bc:1c:19: 3c:82:76:c1:76:ad:9b:6a:be:c3:be:35:dc:e5:5a: 48:95:2c:c9:9f:d7:68:c6:6f:83:b4:8d:c8:8a:0a: b8:73:2e:10:c9:0e:a1:70:cb:a4:29:a0:b3:32:34: 72:69:9a:7d:20:35:9c:58:f1:a3:17:3f:fd:6f:22: 23:e5:58:24:65:56:38:51:6f:10:46:4b:77:fb:2d: c9:5b:ca:db:8e:74:77:20:8b:b4:04:0a:63:75:03: 4c:be:19:9f:1f:9a:63:cd:9b:12:3e:b3:09:10:de: d0:a1:d3:8b:bc:83:66:6a:4e:28:3c:5f:f7:ab:23: a7:b6:da:46:59:21:eb:d7:ef:57:53:d8:72:be:55: 07:a5:95:c9:61:97:f7:39:c0:78:82:c0:1e:bd:53: fc:ae:2c:6c:7a:c2:69:a0:c4:80:44:ac:b3:6b:f8: 01:fc:8f:ab:7e:8b:b8:24:0e:cd:7b:0e:74:94:77: 1c:4d:11:a2:d8:36:53:08:1a:d8:1b:fc:23:86:4c: b3:f1 Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Authority Key Identifier:=20 = keyid:8D:8C:5E:C4:54:AD:8A:E1:77:E9:9B:F9:9B:05:E1:B8:01:8D:61:E1 X509v3 Subject Key Identifier:=20 = 65:8C:F2:D4:46:7C:FB:D1:5E:62:BC:8C:70:B6:99:D0:95:4B:EB:98 X509v3 Key Usage: critical Digital Signature, Key Encipherment X509v3 Basic Constraints: critical CA:FALSE X509v3 Extended Key Usage:=20 TLS Web Server Authentication, TLS Web Client = Authentication X509v3 Certificate Policies:=20 Policy: 1.3.6.1.4.1.6449.1.2.2.7 CPS: https://sectigo.com/CPS Policy: 2.23.140.1.2.1 Authority Information Access:=20 CA Issuers - = URI:http://crt.sectigo.com/SectigoRSADomainValidationSecureServerCA.crt OCSP - URI:http://ocsp.sectigo.com X509v3 Subject Alternative Name:=20 DNS:jabber.ofcourseimright.com, = DNS:www.jabber.ofcourseimright.com 1.3.6.1.4.1.11129.2.4.2:=20 = ......v...\..}h.....#....W|W..j..a:.i......r.e.......G0E.!...f...R...r.S..= .w.E%.}.J.i.M..... = )................!.0...L.e.fs.Z..w.....7~.b....a...{7.V..&[...K.ATn...r.e.= :.....H0F.!....~...V.....5F.h.\C.....e.'57.{.!.. = 8.I...8...U.Y........f._.6..bb Signature Algorithm: sha256WithRSAEncryption 1c:0d:7b:38:be:c5:b5:58:8e:0e:d9:7d:c8:90:9d:ea:29:94: de:a7:a1:11:db:1e:b7:9c:f8:25:48:da:2d:87:2f:76:0b:f8: ba:2d:72:49:87:50:3e:e2:9b:2f:a4:ab:61:24:8c:6c:65:c1: 91:16:c2:7e:50:27:50:93:a8:36:38:ad:66:c4:e4:66:ae:2f: 21:40:8f:41:f7:53:51:61:80:59:a8:2a:56:9b:9b:e5:85:a4: 8b:6e:31:0b:b8:ca:4d:82:af:2c:34:83:25:2b:fc:94:05:28: f6:04:f8:96:61:3c:21:9b:11:13:48:1d:c0:77:c0:df:d3:47: ff:6e:d3:6a:66:eb:16:40:d7:45:67:a0:25:1d:9f:fa:7f:85: 20:34:08:70:b2:3b:d5:b4:15:77:9b:d5:c0:4e:08:99:ce:24: fb:6e:c3:4d:a9:fc:ff:25:d9:09:d0:cd:e1:8b:69:c1:bb:f0: 40:0a:ad:1b:36:4f:ba:a0:aa:e9:f1:af:cd:73:5a:2a:0f:8a: 0d:04:ca:52:85:10:eb:d9:fe:85:6c:a6:ae:a3:de:04:a7:9a: e0:8c:5d:40:b6:1f:f6:f2:b1:d9:dc:f2:f4:fd:a8:f5:b4:25: 80:c0:ec:84:1f:bf:02:e6:3d:0c:ca:41:d5:61:d9:a3:a2:c8: a0:f2:46:3c Eliot > On 17 Jun 2020, at 04:44, Benjamin Kaduk wrote: >=20 > Hi Brian, Michael, >=20 > On Tue, Jun 16, 2020 at 02:14:24PM +1200, Brian E Carpenter wrote: >> On 16-Jun-20 12:20, Michael Richardson wrote: >>>=20 >>> Hi, I have had a few conversations with Toerless who is trying to = deal with >>> the feedback on the ACP document. >>>=20 >>> An item that has come up is the use, or claimed abuse of the = rfc822Name SAN. >>>=20 >>> We already had this debate. >>> Some time ago. The WG decided. >=20 > With all due respect, this is not the sole decision of the ANIMA WG to > make. If WGs had such authority then why bother with cross-area = review? >=20 >>> Three or four years ago, I think. >>=20 >> Yes, this is relitigating an issue that was resolved a long time ago = in discussing Ben's DISCUSS: >=20 > I'm not sure I understand why you use the word "resolved" here: >=20 >> = https://mailarchive.ietf.org/arch/msg/anima/lnZ-ykqas487qih86sYNVsUGbsc >=20 > In this message, I say that "I still feel like this is not the best > architectural choice" and that I will provide a sketch of an = alternative in > my (then-)forthcoming ballot position; that ballot position retains = the > Discuss-level concern about rfc822Name usage along with the promised > alternative. >=20 >> The explanation is at = https://tools.ietf.org/html/draft-ietf-anima-autonomic-control-plane-24#pa= ge-26 >=20 > I appreciate that the attempted justification is clearly written; = however, > I do not find it compelling. Russ did not, either, and I just heard = back > from Sean Turner a few days ago to confirm that he supports Russ's > comments. (There should be a few other editorial-ish comments that = came > out of that review that are still pending.) >=20 >> I believe it is incorrect IETF process to rediscuss this point yet = again. >=20 > (I'm not sure if the "yet again" refers to "after the WG decided" or = "after > the (alleged) resolution of my first Discuss point".) >=20 > If you believe the technical answer is clear and that I am in error to > continue to hold my Discuss point for it, are there not also clear = IETF > processes to follow? E.g., asking for the "Single Discuss" ballot = procedure > described at https://www.ietf.org/standards/process/iesg-ballots/? I > believe I have mentioned this option to Toerless previously; my = apologies > if that is not the case. While I'm willing to continue discussing the > topic and pull in additional PKIX experts to weigh in, there is = perhaps > some consideration to matters of expediency. >=20 >>>=20 >>> I sure wish that we could use something else. >>> But, CAs and CA software make that very difficult. >>>=20 >>> Given that the era of publically anchored Enterprise CAs is dead, = there are >>> only two ways an (Enterprise) ACP Registrar is going to occur. >>>=20 >>> 1) by running a private CA. >>> Sure anything is possible if you are writing your own code, but >>> most will not be doing that. (I've supported otherName in my code = for >>> other purposes, and it's not that difficult, but it's not trivial = either) >>> My experience with COTS CA systems it that it's really hard to >>> get them to do it. Please prove me wrong. >=20 > (Sadly, I have zero experience with COTS CA systems; I know too much = about > openssl at this point and would presumably be writing my own, in this > position.) >=20 >>> The most popular Enterprise CA software is the Microsoft CA. >>>=20 >>> 2) by using ACME to speak to a hosted CA. Maybe WebPKI, maybe not. >>> Either way, getting otherName supported is even harder, because >>> nobody else uses it. >=20 > Is the concern the ACME protocol support or just getting the hosted CA = to > cope with it? The former seems like something that we could make = happen in > the IETF, and the latter seems to have high overlap with point (1). >=20 >>> If we can't depend upon otherName being filled in, then we have to = look for >>> two things. That means more code paths (two more) to test, more = test >>> vectors, and what exactly does an end point do when both are = present, BUT >>> THEY DO NOT MATCH? So three more pages of text there. >>> Remember, that just rejecting the certificate means that we have to = send out >>> a truck, which is what ACP aims to avoid, so that won't be popular. >>> And of course, there could also be bugs (maybe even CVEs) in the = code that >>> tries to deal with the tie. >=20 > To be honest, this argument feels like a stronger one to me than the = bits > in the -24. I'm still not willing to accept into the RFC Series a = document > that violates the rules set down by the specification for the = technology > it's making use of, but the refocus on the "running code" aspect is > appreciated. >=20 > -Ben >=20 > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima --Apple-Mail=_DCC78DC6-BAF6-486B-A4E4-AA85FA11BCB4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Ok, = so I just want to add that I have been able to populate otherName with = garbage and have it get signed by a public CA.  My point is that at = least some public CAs are loose.  If LE is important to this space, = and if it=E2=80=99s really important, then this is not a solution. =  Anyway, Here was the line that I used for my jabber server (it=E2=80= =99s certainly not correct):

subjectAltName = =3D DNS:www.ofcourseimright.com,DNS:upstairs.ofcourseimright.com,otherName:1.3.6.1.5.5.7.8.7;IA= 5:ofcourseimright.com,otherName:1.3.6.1.5.5.7.8.7;IA5:_xmpp-c= lient._tcp.ofcourseimright.com,otherName:1.3.6.1.5.5.7.8.7;IA5:_xm= pp-server._tcp.ofcourseimright.com,otherName:1.3.6.1.5.5.7.8.7;UTF8:ofcourseimright.com

And here=E2=80=99= s what I got:

McNext> openssl x509 -noout -text -in = jabber_ofcourseimright_com.crt 
Certificate:
  =   Data:
        Version: 3 (0x2)
  =       Serial Number:
          =   58:12:20:cd:47:fe:82:af:35:8d:75:50:75:05:a6:cb
  =   Signature Algorithm: sha256WithRSAEncryption
  =       Issuer: C=3DGB, ST=3DGreater Manchester, L=3DSalford,= O=3DSectigo Limited, CN=3DSectigo RSA Domain Validation Secure Server = CA
        Validity
  =           Not Before: Jun 18 00:00:00 2020 = GMT
            Not After : Jul 18 = 23:59:59 2020 GMT
        Subject: CN=3Djabber.ofcourseimright.com
  =       Subject Public Key Info:
  =           Public Key Algorithm: = rsaEncryption
                = Public-Key: (2048 bit)
          =       Modulus:
          =           = 00:9e:c8:c0:61:b6:5c:d1:fc:bf:2d:d2:13:6b:db:
  =                   = 97:09:45:e8:22:bf:89:24:7e:09:01:fe:91:37:85:
  =                   = ee:25:77:54:92:68:05:07:d2:70:f5:6f:5c:fc:b4:
  =                   = c6:7f:2d:e6:3e:11:68:4b:55:74:10:39:bc:1c:19:
  =                   = 3c:82:76:c1:76:ad:9b:6a:be:c3:be:35:dc:e5:5a:
  =                   = 48:95:2c:c9:9f:d7:68:c6:6f:83:b4:8d:c8:8a:0a:
  =                   = b8:73:2e:10:c9:0e:a1:70:cb:a4:29:a0:b3:32:34:
  =                   = 72:69:9a:7d:20:35:9c:58:f1:a3:17:3f:fd:6f:22:
  =                   = 23:e5:58:24:65:56:38:51:6f:10:46:4b:77:fb:2d:
  =                   = c9:5b:ca:db:8e:74:77:20:8b:b4:04:0a:63:75:03:
  =                   = 4c:be:19:9f:1f:9a:63:cd:9b:12:3e:b3:09:10:de:
  =                   = d0:a1:d3:8b:bc:83:66:6a:4e:28:3c:5f:f7:ab:23:
  =                   = a7:b6:da:46:59:21:eb:d7:ef:57:53:d8:72:be:55:
  =                   = 07:a5:95:c9:61:97:f7:39:c0:78:82:c0:1e:bd:53:
  =                   = fc:ae:2c:6c:7a:c2:69:a0:c4:80:44:ac:b3:6b:f8:
  =                   = 01:fc:8f:ab:7e:8b:b8:24:0e:cd:7b:0e:74:94:77:
  =                   = 1c:4d:11:a2:d8:36:53:08:1a:d8:1b:fc:23:86:4c:
  =                   = b3:f1
                = Exponent: 65537 (0x10001)
        X509v3 = extensions:
            X509v3 Authority = Key Identifier: 
          =       = keyid:8D:8C:5E:C4:54:AD:8A:E1:77:E9:9B:F9:9B:05:E1:B8:01:8D:61:E1

          =   X509v3 Subject Key Identifier: 
  =               = 65:8C:F2:D4:46:7C:FB:D1:5E:62:BC:8C:70:B6:99:D0:95:4B:EB:98
  =           X509v3 Key Usage: = critical
                = Digital Signature, Key Encipherment
          =   X509v3 Basic Constraints: critical
  =               = CA:FALSE
            X509v3 Extended Key = Usage: 
                TLS = Web Server Authentication, TLS Web Client = Authentication
            X509v3 Certificate = Policies: 
                = Policy: 1.3.6.1.4.1.6449.1.2.2.7
          =         CPS: https://sectigo.com/CPS
          =       Policy: 2.23.140.1.2.1

          =   Authority Information Access: 
  =               CA Issuers - URI:http://crt.sectigo.com/SectigoRSADomainValidationSecureServerCA= .crt
                OCSP = - URI:http://ocsp.sectigo.com

          =   X509v3 Subject Alternative Name: 
  =               DNS:jabber.ofcourseimright.com, DNS:www.jabber.ofcourseimright.com
  =           = 1.3.6.1.4.1.11129.2.4.2: 
          =       = ......v...\..}h.....#....W|W..j..a:.i......r.e.......G0E.!...f...R...r.S..= .w.E%.}.J.i.M..... = )................!.0...L.e.fs.Z..w.....7~.b....a...{7.V..&[...K.ATn...= r.e.:.....H0F.!....~...V.....5F.h.\C.....e.'57.{.!.. = 8.I...8...U.Y........f._.6..bb
    Signature Algorithm: = sha256WithRSAEncryption
         = 1c:0d:7b:38:be:c5:b5:58:8e:0e:d9:7d:c8:90:9d:ea:29:94:
         = de:a7:a1:11:db:1e:b7:9c:f8:25:48:da:2d:87:2f:76:0b:f8:
         = ba:2d:72:49:87:50:3e:e2:9b:2f:a4:ab:61:24:8c:6c:65:c1:
         = 91:16:c2:7e:50:27:50:93:a8:36:38:ad:66:c4:e4:66:ae:2f:
         = 21:40:8f:41:f7:53:51:61:80:59:a8:2a:56:9b:9b:e5:85:a4:
         = 8b:6e:31:0b:b8:ca:4d:82:af:2c:34:83:25:2b:fc:94:05:28:
         = f6:04:f8:96:61:3c:21:9b:11:13:48:1d:c0:77:c0:df:d3:47:
         = ff:6e:d3:6a:66:eb:16:40:d7:45:67:a0:25:1d:9f:fa:7f:85:
         = 20:34:08:70:b2:3b:d5:b4:15:77:9b:d5:c0:4e:08:99:ce:24:
         = fb:6e:c3:4d:a9:fc:ff:25:d9:09:d0:cd:e1:8b:69:c1:bb:f0:
         = 40:0a:ad:1b:36:4f:ba:a0:aa:e9:f1:af:cd:73:5a:2a:0f:8a:
         = 0d:04:ca:52:85:10:eb:d9:fe:85:6c:a6:ae:a3:de:04:a7:9a:
         = e0:8c:5d:40:b6:1f:f6:f2:b1:d9:dc:f2:f4:fd:a8:f5:b4:25:
         = 80:c0:ec:84:1f:bf:02:e6:3d:0c:ca:41:d5:61:d9:a3:a2:c8:
         = a0:f2:46:3c


Eliot
On 17 = Jun 2020, at 04:44, Benjamin Kaduk <kaduk@mit.edu> wrote:

Hi = Brian, Michael,

On Tue, Jun 16, 2020 at = 02:14:24PM +1200, Brian E Carpenter wrote:
On 16-Jun-20 12:20, Michael Richardson = wrote:

Hi, I have had a few conversations with Toerless who is = trying to deal with
the feedback on the ACP document.

An item that has come up is the use, or = claimed abuse of the rfc822Name SAN.

We = already had this debate.
Some time ago.  The WG = decided.

With all = due respect, this is not the sole decision of the ANIMA WG to
make.  If WGs had such authority then why bother with = cross-area review?

Three or four years ago, = I think.

Yes, this is = relitigating an issue that was resolved a long time ago in discussing = Ben's DISCUSS:

I'm not sure I = understand why you use the word "resolved" here:

https://mailarchive.ietf.org/arch/msg/anima/lnZ-ykqas487qih86sY= NVsUGbsc

In this message, = I say that "I still feel like this is not the best
architectural choice" and that I will provide a sketch of an = alternative in
my (then-)forthcoming ballot position; that = ballot position retains the
Discuss-level concern about = rfc822Name usage along with the promised
alternative.

The = explanation is at https://tools.ietf.org/html/draft-ietf-anima-autonomic-control-= plane-24#page-26

I = appreciate that the attempted justification is clearly written; = however,
I do not find it compelling.  Russ did not, = either, and I just heard back
from Sean Turner a few days = ago to confirm that he supports Russ's
comments. =  (There should be a few other editorial-ish comments that came
out of that review that are still pending.)

I believe it is = incorrect IETF process to rediscuss this point yet again.

(I'm not sure if the "yet again" = refers to "after the WG decided" or "after
the (alleged) = resolution of my first Discuss point".)

If = you believe the technical answer is clear and that I am in error to
continue to hold my Discuss point for it, are there not also = clear IETF
processes to follow?  E.g., asking for the = "Single Discuss" ballot procedure
described at https://www.ietf.org/standards/process/iesg-ballots/? =  I
believe I have mentioned this option to Toerless = previously; my apologies
if that is not the case. =  While I'm willing to continue discussing the
topic = and pull in additional PKIX experts to weigh in, there is perhaps
some consideration to matters of expediency.


I sure wish that we could use something = else.
But, CAs and CA software make that very = difficult.

Given that the era of publically = anchored Enterprise CAs is dead, there are
only two ways = an (Enterprise) ACP Registrar is going to occur.

1) by running a private CA.
  Sure = anything is possible if you are writing your own code, but
=   most will not be doing that. (I've supported otherName in my = code for
  other purposes, and it's not that = difficult, but it's not trivial either)
  My = experience with COTS CA systems it that it's really hard to
=   get them to do it.    Please prove me = wrong.

(Sadly, I = have zero experience with COTS CA systems; I know too much about
openssl at this point and would presumably be writing my own, = in this
position.)

=   The most popular Enterprise CA software is the Microsoft = CA.

2) by using ACME to speak to a hosted = CA.  Maybe WebPKI, maybe not.
  Either = way, getting otherName supported is even harder, because
=   nobody else uses it.

Is the concern the = ACME protocol support or just getting the hosted CA to
cope = with it?  The former seems like something that we could make happen = in
the IETF, and the latter seems to have high overlap = with point (1).

If we can't depend upon = otherName being filled in, then we have to look for
two = things.  That means more code paths (two more) to test, more = test
vectors, and what exactly does an end point do when = both are present, BUT
THEY DO NOT MATCH?  So three = more pages of text there.
Remember, that just rejecting = the certificate means that we have to send out
a truck, = which is what ACP aims to avoid, so that won't be popular.
And of course, there could also be bugs (maybe even CVEs) in = the code that
tries to deal with the tie.

To be honest, this = argument feels like a stronger one to me than the bits
in = the -24.  I'm still not willing to accept into the RFC Series a = document
that violates the rules set down by the = specification for the technology
it's making use of, but = the refocus on the "running code" aspect is
appreciated.

-Ben

_______________________________________________
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

= --Apple-Mail=_DCC78DC6-BAF6-486B-A4E4-AA85FA11BCB4-- From nobody Thu Jun 18 22:11:38 2020 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC5493A0E14 for ; Thu, 18 Jun 2020 22:11:36 -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, FREEMAIL_FROM=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 VB1b-XQQ6lL6 for ; Thu, 18 Jun 2020 22:11:35 -0700 (PDT) Received: from mail-pj1-x1041.google.com (mail-pj1-x1041.google.com [IPv6:2607:f8b0:4864:20::1041]) (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 470593A0E10 for ; Thu, 18 Jun 2020 22:11:35 -0700 (PDT) Received: by mail-pj1-x1041.google.com with SMTP id k2so3595986pjs.2 for ; Thu, 18 Jun 2020 22:11:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=HGbiWU8PvtfEoReYCxJ5e+VJccq97/l9NMKIaN7gug0=; b=Zn6hPZOILg0rKDF5XILrBYtSAYQp/Wqh5tB/7ibP3e8+rzzcxz7lKfg2hxxReM9Csk kVQUGQgokkh8ViXj8scR6PfF0yda1q2ifTjUVubWjqyULUApPLiW2i2YFWoD5YdmpMq7 UJSFRejZB0BMn7t/eeUfak9MYYRjZSGzbUwxCwZwhcFrQaxnkGNBYodApxTWF+1B8bSz lVb54wwsrzMST9d9jO1GX4KfU57VDhivyGcUnq5PVxugMm+Mz5/X6TDmsWuCJu4SQ8Bz +rlNgCELaA+iHAKK5Uj1lPmwaiSmN3GBLZstxTRWOaYT/udnxgiFhdIpDR0SLqiiR8dR l6Cw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=HGbiWU8PvtfEoReYCxJ5e+VJccq97/l9NMKIaN7gug0=; b=dFarpJ8N1KtVKRSuWGZFB3CXIHLbfDH4Jp8fsjThgAvb3cCZCPHrs6XFkmXN9zbxgF iDMvEz/BZWN1SqYqy90JY91ldQU4PElttbO3zOVBAibfHSnJUJWL/TSxRuRrtzbgT3Dp TsFMK8jRMWqqlCJGo7d80kmAYzkSaU+u7jibvLhMRtz9z1ey1RDNxKjEWJuEjwz+1/Wm v4GX9m4/d+e3ZamKYoJqCh9vPms8+3HtN6JL2HXLoHeA/T8p91iJa760+KmZjHI/Fxuy +78TOrHWoGDm7OyIyXXnt9itao6GM19EhcKY47MyXlPfLze+yfdQ6UlEpWGh1cHhjvA+ loMA== X-Gm-Message-State: AOAM533C7vWjry7XS3JCr3/vOGrGMK9FzoiTxkIoQQaK+Y9jqiJORzeg 461CqR+MNOKTY5rgV3RixYY= X-Google-Smtp-Source: ABdhPJwV9IIdtd7tdlPCdvUiJzy8L6pg9e1UumcmNF9ltizVk7C2ScHwShzp58SWJKl4YwfMSwPmug== X-Received: by 2002:a17:90a:7c07:: with SMTP id v7mr1773844pjf.38.1592543494437; Thu, 18 Jun 2020 22:11:34 -0700 (PDT) Received: from [192.168.178.30] (144.91.69.111.dynamic.snap.net.nz. [111.69.91.144]) by smtp.gmail.com with ESMTPSA id a63sm3075424pfd.111.2020.06.18.22.11.30 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 18 Jun 2020 22:11:33 -0700 (PDT) To: Benjamin Kaduk Cc: Michael Richardson , anima@ietf.org, Russ Housley , sean+ietf@sn3rd.com References: <11428.1592266833@localhost> <20200617024412.GA11992@kduck.mit.edu> From: Brian E Carpenter Message-ID: <9584c5cd-c68d-ddc3-0704-da672842e359@gmail.com> Date: Fri, 19 Jun 2020 17:11:30 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <20200617024412.GA11992@kduck.mit.edu> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] rfc822Name use in Autonomic Control Plane document X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jun 2020 05:11:37 -0000 Hi Ben, (Back on line after a couple of days spent moving apartments.) On 17-Jun-20 14:44, Benjamin Kaduk wrote: > Hi Brian, Michael, > > On Tue, Jun 16, 2020 at 02:14:24PM +1200, Brian E Carpenter wrote: >> On 16-Jun-20 12:20, Michael Richardson wrote: >>> >>> Hi, I have had a few conversations with Toerless who is trying to deal with >>> the feedback on the ACP document. >>> >>> An item that has come up is the use, or claimed abuse of the rfc822Name SAN. >>> >>> We already had this debate. >>> Some time ago. The WG decided. > > With all due respect, this is not the sole decision of the ANIMA WG to > make. If WGs had such authority then why bother with cross-area review? Yes, but that was exactly the reason we had the discussion a year ago. >>> Three or four years ago, I think. >> >> Yes, this is relitigating an issue that was resolved a long time ago in discussing Ben's DISCUSS: > > I'm not sure I understand why you use the word "resolved" here: > >> https://mailarchive.ietf.org/arch/msg/anima/lnZ-ykqas487qih86sYNVsUGbsc > > In this message, I say that "I still feel like this is not the best > architectural choice" and that I will provide a sketch of an alternative in > my (then-)forthcoming ballot position; that ballot position retains the > Discuss-level concern about rfc822Name usage along with the promised > alternative. "Not the best choice" is not a DISCUSS criterion according to the IESG's own rules at https://www.ietf.org/about/groups/iesg/statements/iesg-discuss-criteria/#stand-undisc It was exactly this sort of endless debate over "best choice" disagreements that caused the IESG to adopt the DISCUSS criteria rules in the first place. If you are saying that one of the criteria in https://www.ietf.org/about/groups/iesg/statements/iesg-discuss-criteria/#stand-disc applies, that's a different matter, of course. But really, no AD should hold a DISCUSS over "not the best choice". Not to mention that this is only a Proposed Standard discussion; perfection not required. I don't consider myself enough of a subject matter expert to comment on the technical issue itself. Regards Brian > >> The explanation is at https://tools.ietf.org/html/draft-ietf-anima-autonomic-control-plane-24#page-26 > > I appreciate that the attempted justification is clearly written; however, > I do not find it compelling. Russ did not, either, and I just heard back > from Sean Turner a few days ago to confirm that he supports Russ's > comments. (There should be a few other editorial-ish comments that came > out of that review that are still pending.) > >> I believe it is incorrect IETF process to rediscuss this point yet again. > > (I'm not sure if the "yet again" refers to "after the WG decided" or "after > the (alleged) resolution of my first Discuss point".) > > If you believe the technical answer is clear and that I am in error to > continue to hold my Discuss point for it, are there not also clear IETF > processes to follow? E.g., asking for the "Single Discuss" ballot procedure > described at https://www.ietf.org/standards/process/iesg-ballots/? I > believe I have mentioned this option to Toerless previously; my apologies > if that is not the case. While I'm willing to continue discussing the > topic and pull in additional PKIX experts to weigh in, there is perhaps > some consideration to matters of expediency. > >>> >>> I sure wish that we could use something else. >>> But, CAs and CA software make that very difficult. >>> >>> Given that the era of publically anchored Enterprise CAs is dead, there are >>> only two ways an (Enterprise) ACP Registrar is going to occur. >>> >>> 1) by running a private CA. >>> Sure anything is possible if you are writing your own code, but >>> most will not be doing that. (I've supported otherName in my code for >>> other purposes, and it's not that difficult, but it's not trivial either) >>> My experience with COTS CA systems it that it's really hard to >>> get them to do it. Please prove me wrong. > > (Sadly, I have zero experience with COTS CA systems; I know too much about > openssl at this point and would presumably be writing my own, in this > position.) > >>> The most popular Enterprise CA software is the Microsoft CA. >>> >>> 2) by using ACME to speak to a hosted CA. Maybe WebPKI, maybe not. >>> Either way, getting otherName supported is even harder, because >>> nobody else uses it. > > Is the concern the ACME protocol support or just getting the hosted CA to > cope with it? The former seems like something that we could make happen in > the IETF, and the latter seems to have high overlap with point (1). > >>> If we can't depend upon otherName being filled in, then we have to look for >>> two things. That means more code paths (two more) to test, more test >>> vectors, and what exactly does an end point do when both are present, BUT >>> THEY DO NOT MATCH? So three more pages of text there. >>> Remember, that just rejecting the certificate means that we have to send out >>> a truck, which is what ACP aims to avoid, so that won't be popular. >>> And of course, there could also be bugs (maybe even CVEs) in the code that >>> tries to deal with the tie. > > To be honest, this argument feels like a stronger one to me than the bits > in the -24. I'm still not willing to accept into the RFC Series a document > that violates the rules set down by the specification for the technology > it's making use of, but the refocus on the "running code" aspect is > appreciated. > > -Ben > From nobody Fri Jun 19 09:33:04 2020 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE9413A0B69 for ; Fri, 19 Jun 2020 09:33:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=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 uB5qr4RKZaBB for ; Fri, 19 Jun 2020 09:32:59 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A68903A0B68 for ; Fri, 19 Jun 2020 09:32:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 4A290300B44 for ; Fri, 19 Jun 2020 12:32:57 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id ecDjiUT9z01s for ; Fri, 19 Jun 2020 12:32:54 -0400 (EDT) Received: from a860b60074bd.fios-router.home (pool-72-66-113-56.washdc.fios.verizon.net [72.66.113.56]) by mail.smeinc.net (Postfix) with ESMTPSA id AB42D300464; Fri, 19 Jun 2020 12:32:54 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.14\)) From: Russ Housley In-Reply-To: <9584c5cd-c68d-ddc3-0704-da672842e359@gmail.com> Date: Fri, 19 Jun 2020 12:32:56 -0400 Cc: Ben Kaduk , anima@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <11428.1592266833@localhost> <20200617024412.GA11992@kduck.mit.edu> <9584c5cd-c68d-ddc3-0704-da672842e359@gmail.com> To: Brian Carpenter X-Mailer: Apple Mail (2.3445.104.14) Archived-At: Subject: Re: [Anima] rfc822Name use in Autonomic Control Plane document X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jun 2020 16:33:02 -0000 Brian: I disagree with your characterization of the situation. RFC 5280 talks = about Subject Alternative Names, and the rfc822Name is used for an email = address. This specification puts something other than an email address = in that field, and I raised a concern when I reviewed the document. = Other name forms are explicitly accommodated by otherName, and in my = review, I suggested using otherName instead of rfc822Name. I observe that jabber IDs have the same syntax as an email address, but = they are not carried in rfc822name because the semantics are different. One cannot send email to the character string in this specification, so = it should not be carried in the rfc822name. Russ > On Jun 19, 2020, at 1:11 AM, Brian E Carpenter = wrote: >=20 > Hi Ben, >=20 > (Back on line after a couple of days spent moving apartments.) >=20 > On 17-Jun-20 14:44, Benjamin Kaduk wrote: >> Hi Brian, Michael, >>=20 >> On Tue, Jun 16, 2020 at 02:14:24PM +1200, Brian E Carpenter wrote: >>> On 16-Jun-20 12:20, Michael Richardson wrote: >>>>=20 >>>> Hi, I have had a few conversations with Toerless who is trying to = deal with >>>> the feedback on the ACP document. >>>>=20 >>>> An item that has come up is the use, or claimed abuse of the = rfc822Name SAN. >>>>=20 >>>> We already had this debate. >>>> Some time ago. The WG decided. >>=20 >> With all due respect, this is not the sole decision of the ANIMA WG = to >> make. If WGs had such authority then why bother with cross-area = review? >=20 > Yes, but that was exactly the reason we had the discussion a year ago. >=20 >>>> Three or four years ago, I think. >>>=20 >>> Yes, this is relitigating an issue that was resolved a long time ago = in discussing Ben's DISCUSS: >>=20 >> I'm not sure I understand why you use the word "resolved" here: >>=20 >>> = https://mailarchive.ietf.org/arch/msg/anima/lnZ-ykqas487qih86sYNVsUGbsc >>=20 >> In this message, I say that "I still feel like this is not the best >> architectural choice" and that I will provide a sketch of an = alternative in >> my (then-)forthcoming ballot position; that ballot position retains = the >> Discuss-level concern about rfc822Name usage along with the promised >> alternative. > "Not the best choice" is not a DISCUSS criterion according to the = IESG's own rules at = https://www.ietf.org/about/groups/iesg/statements/iesg-discuss-criteria/#s= tand-undisc >=20 > It was exactly this sort of endless debate over "best choice" = disagreements that caused the IESG to adopt the DISCUSS criteria rules = in the first place. >=20 > If you are saying that one of the criteria in = https://www.ietf.org/about/groups/iesg/statements/iesg-discuss-criteria/#s= tand-disc applies, that's a different matter, of course. But really, no = AD should hold a DISCUSS over "not the best choice". >=20 > Not to mention that this is only a Proposed Standard discussion; = perfection not required. >=20 > I don't consider myself enough of a subject matter expert to comment = on the technical issue itself. >=20 > Regards > Brian >=20 >>=20 >>> The explanation is at = https://tools.ietf.org/html/draft-ietf-anima-autonomic-control-plane-24#pa= ge-26 >>=20 >> I appreciate that the attempted justification is clearly written; = however, >> I do not find it compelling. Russ did not, either, and I just heard = back >> from Sean Turner a few days ago to confirm that he supports Russ's >> comments. (There should be a few other editorial-ish comments that = came >> out of that review that are still pending.) >>=20 >>> I believe it is incorrect IETF process to rediscuss this point yet = again. >>=20 >> (I'm not sure if the "yet again" refers to "after the WG decided" or = "after >> the (alleged) resolution of my first Discuss point".) >>=20 >> If you believe the technical answer is clear and that I am in error = to >> continue to hold my Discuss point for it, are there not also clear = IETF >> processes to follow? E.g., asking for the "Single Discuss" ballot = procedure >> described at https://www.ietf.org/standards/process/iesg-ballots/? I >> believe I have mentioned this option to Toerless previously; my = apologies >> if that is not the case. While I'm willing to continue discussing = the >> topic and pull in additional PKIX experts to weigh in, there is = perhaps >> some consideration to matters of expediency. >>=20 >>>>=20 >>>> I sure wish that we could use something else. >>>> But, CAs and CA software make that very difficult. >>>>=20 >>>> Given that the era of publically anchored Enterprise CAs is dead, = there are >>>> only two ways an (Enterprise) ACP Registrar is going to occur. >>>>=20 >>>> 1) by running a private CA. >>>> Sure anything is possible if you are writing your own code, but >>>> most will not be doing that. (I've supported otherName in my code = for >>>> other purposes, and it's not that difficult, but it's not trivial = either) >>>> My experience with COTS CA systems it that it's really hard to >>>> get them to do it. Please prove me wrong. >>=20 >> (Sadly, I have zero experience with COTS CA systems; I know too much = about >> openssl at this point and would presumably be writing my own, in this >> position.) >>=20 >>>> The most popular Enterprise CA software is the Microsoft CA. >>>>=20 >>>> 2) by using ACME to speak to a hosted CA. Maybe WebPKI, maybe not. >>>> Either way, getting otherName supported is even harder, because >>>> nobody else uses it. >>=20 >> Is the concern the ACME protocol support or just getting the hosted = CA to >> cope with it? The former seems like something that we could make = happen in >> the IETF, and the latter seems to have high overlap with point (1). >>=20 >>>> If we can't depend upon otherName being filled in, then we have to = look for >>>> two things. That means more code paths (two more) to test, more = test >>>> vectors, and what exactly does an end point do when both are = present, BUT >>>> THEY DO NOT MATCH? So three more pages of text there. >>>> Remember, that just rejecting the certificate means that we have to = send out >>>> a truck, which is what ACP aims to avoid, so that won't be popular. >>>> And of course, there could also be bugs (maybe even CVEs) in the = code that >>>> tries to deal with the tie. >>=20 >> To be honest, this argument feels like a stronger one to me than the = bits >> in the -24. I'm still not willing to accept into the RFC Series a = document >> that violates the rules set down by the specification for the = technology >> it's making use of, but the refocus on the "running code" aspect is >> appreciated. >>=20 >> -Ben >>=20 From nobody Fri Jun 19 13:22:55 2020 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C94283A0E1A for ; Fri, 19 Jun 2020 13:22:53 -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, FREEMAIL_FROM=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 VURwrb4DlnNn for ; Fri, 19 Jun 2020 13:22:52 -0700 (PDT) Received: from mail-pj1-x1044.google.com (mail-pj1-x1044.google.com [IPv6:2607:f8b0:4864:20::1044]) (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 ED4B03A0DAA for ; Fri, 19 Jun 2020 13:22:51 -0700 (PDT) Received: by mail-pj1-x1044.google.com with SMTP id s88so4736762pjb.5 for ; Fri, 19 Jun 2020 13:22:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=iWo7EcUpe2hP88Cu4EQrLIyrJ5D/ORCFeJWtjKx8YtE=; b=s2wkqM1SKA5zIMEVP2rx796VqHQp/0er9BMEEphDvh6CXH40iW19gBV3xB7mT9jhEC bHs6dFx/zCrcE7WSLAzhSj5mC8h1NCpbdHz349C2Sa5zKbt08sdtxT/oz8EZx9GhGtvg 2Nnshid3Lm8yFchAOq6xBS1rsvDwAl1ymGX9dERLrbCxrPzx+qRsps4xzlxK2tNmc/6w YpXDVm9yN2cM9/8AYutirb0gouiG1mm8VPvIQFHYUXjWjpq0lvmcrMxm+bRGUgCcJPC6 7ILub47jCg5CFwKQZ6X0YQwnnu74Oge83IT6wF9k2oR/UpaY2o8KgWZocSkR6eyyPM3K e/Rw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=iWo7EcUpe2hP88Cu4EQrLIyrJ5D/ORCFeJWtjKx8YtE=; b=LGTNjf/zpctybP6MakCr0h1A+QWr2pP1qvA6PObHT8xU4PtLd2Z8d8XsbfCruHeruj +K43uiKcL+OAYB7jn2Q1e1WwKiScQUbFtb3X5phrbjGnktbKDeyFXPzmOlsDnfOJgtQz FhIhD09y7WbuLllQaVQ766rj8RVPmMgqNKDgvB5/6FswTdcoCtTgaefYtkUTp98SgCpJ LMHZTRw77jec5PeC4NIv0xxSkixVg8EdYpexC08939r1Pg7kjhs11LPem46SZD7UjlJp iuzRvHwyDCzyWzHA8ti1xjq1mHuoc6NFXFfLz38Ata5EAdKrCN55HAiR6HFVS8KUTpMG EUqA== X-Gm-Message-State: AOAM531Vs3Y94nbX/3bh9qYBqsv1c1BZE5xK88iiUt30bRTn2ALj8pUv fW0WmA+aAcDq+ZWD2emALy0lU69+0So= X-Google-Smtp-Source: ABdhPJyRqdn3TBnsBt4+GztUr4h1n1TtgfdqBtrjGNerJf+erlWbyYlfsm5+BAYDr2s3i+LkJS4sXg== X-Received: by 2002:a17:90a:7403:: with SMTP id a3mr4978343pjg.222.1592598171156; Fri, 19 Jun 2020 13:22:51 -0700 (PDT) Received: from [192.168.178.30] (93.91.69.111.dynamic.snap.net.nz. [111.69.91.93]) by smtp.gmail.com with ESMTPSA id d25sm5683384pgn.2.2020.06.19.13.22.47 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 19 Jun 2020 13:22:50 -0700 (PDT) To: Russ Housley Cc: Ben Kaduk , anima@ietf.org References: <11428.1592266833@localhost> <20200617024412.GA11992@kduck.mit.edu> <9584c5cd-c68d-ddc3-0704-da672842e359@gmail.com> From: Brian E Carpenter Message-ID: <40facb30-fde3-ae1c-b15c-d186da5c51c1@gmail.com> Date: Sat, 20 Jun 2020 08:22:43 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] rfc822Name use in Autonomic Control Plane document X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jun 2020 20:22:54 -0000 Hi Russ, I think everyone agrees that it's bending the purpose of a protocol element, for pragmatic reasons, and it isn't something I particularly like either. But it was a pragmatic choice made after discussing the alternatives. Regards Brian On 20-Jun-20 04:32, Russ Housley wrote: > Brian: > > I disagree with your characterization of the situation. RFC 5280 talks about Subject Alternative Names, and the rfc822Name is used for an email address. This specification puts something other than an email address in that field, and I raised a concern when I reviewed the document. Other name forms are explicitly accommodated by otherName, and in my review, I suggested using otherName instead of rfc822Name. > > I observe that jabber IDs have the same syntax as an email address, but they are not carried in rfc822name because the semantics are different. > > One cannot send email to the character string in this specification, so it should not be carried in the rfc822name. > > Russ > > >> On Jun 19, 2020, at 1:11 AM, Brian E Carpenter wrote: >> >> Hi Ben, >> >> (Back on line after a couple of days spent moving apartments.) >> >> On 17-Jun-20 14:44, Benjamin Kaduk wrote: >>> Hi Brian, Michael, >>> >>> On Tue, Jun 16, 2020 at 02:14:24PM +1200, Brian E Carpenter wrote: >>>> On 16-Jun-20 12:20, Michael Richardson wrote: >>>>> >>>>> Hi, I have had a few conversations with Toerless who is trying to deal with >>>>> the feedback on the ACP document. >>>>> >>>>> An item that has come up is the use, or claimed abuse of the rfc822Name SAN. >>>>> >>>>> We already had this debate. >>>>> Some time ago. The WG decided. >>> >>> With all due respect, this is not the sole decision of the ANIMA WG to >>> make. If WGs had such authority then why bother with cross-area review? >> >> Yes, but that was exactly the reason we had the discussion a year ago. >> >>>>> Three or four years ago, I think. >>>> >>>> Yes, this is relitigating an issue that was resolved a long time ago in discussing Ben's DISCUSS: >>> >>> I'm not sure I understand why you use the word "resolved" here: >>> >>>> https://mailarchive.ietf.org/arch/msg/anima/lnZ-ykqas487qih86sYNVsUGbsc >>> >>> In this message, I say that "I still feel like this is not the best >>> architectural choice" and that I will provide a sketch of an alternative in >>> my (then-)forthcoming ballot position; that ballot position retains the >>> Discuss-level concern about rfc822Name usage along with the promised >>> alternative. >> "Not the best choice" is not a DISCUSS criterion according to the IESG's own rules at https://www.ietf.org/about/groups/iesg/statements/iesg-discuss-criteria/#stand-undisc >> >> It was exactly this sort of endless debate over "best choice" disagreements that caused the IESG to adopt the DISCUSS criteria rules in the first place. >> >> If you are saying that one of the criteria in https://www.ietf.org/about/groups/iesg/statements/iesg-discuss-criteria/#stand-disc applies, that's a different matter, of course. But really, no AD should hold a DISCUSS over "not the best choice". >> >> Not to mention that this is only a Proposed Standard discussion; perfection not required. >> >> I don't consider myself enough of a subject matter expert to comment on the technical issue itself. >> >> Regards >> Brian >> >>> >>>> The explanation is at https://tools.ietf.org/html/draft-ietf-anima-autonomic-control-plane-24#page-26 >>> >>> I appreciate that the attempted justification is clearly written; however, >>> I do not find it compelling. Russ did not, either, and I just heard back >>> from Sean Turner a few days ago to confirm that he supports Russ's >>> comments. (There should be a few other editorial-ish comments that came >>> out of that review that are still pending.) >>> >>>> I believe it is incorrect IETF process to rediscuss this point yet again. >>> >>> (I'm not sure if the "yet again" refers to "after the WG decided" or "after >>> the (alleged) resolution of my first Discuss point".) >>> >>> If you believe the technical answer is clear and that I am in error to >>> continue to hold my Discuss point for it, are there not also clear IETF >>> processes to follow? E.g., asking for the "Single Discuss" ballot procedure >>> described at https://www.ietf.org/standards/process/iesg-ballots/? I >>> believe I have mentioned this option to Toerless previously; my apologies >>> if that is not the case. While I'm willing to continue discussing the >>> topic and pull in additional PKIX experts to weigh in, there is perhaps >>> some consideration to matters of expediency. >>> >>>>> >>>>> I sure wish that we could use something else. >>>>> But, CAs and CA software make that very difficult. >>>>> >>>>> Given that the era of publically anchored Enterprise CAs is dead, there are >>>>> only two ways an (Enterprise) ACP Registrar is going to occur. >>>>> >>>>> 1) by running a private CA. >>>>> Sure anything is possible if you are writing your own code, but >>>>> most will not be doing that. (I've supported otherName in my code for >>>>> other purposes, and it's not that difficult, but it's not trivial either) >>>>> My experience with COTS CA systems it that it's really hard to >>>>> get them to do it. Please prove me wrong. >>> >>> (Sadly, I have zero experience with COTS CA systems; I know too much about >>> openssl at this point and would presumably be writing my own, in this >>> position.) >>> >>>>> The most popular Enterprise CA software is the Microsoft CA. >>>>> >>>>> 2) by using ACME to speak to a hosted CA. Maybe WebPKI, maybe not. >>>>> Either way, getting otherName supported is even harder, because >>>>> nobody else uses it. >>> >>> Is the concern the ACME protocol support or just getting the hosted CA to >>> cope with it? The former seems like something that we could make happen in >>> the IETF, and the latter seems to have high overlap with point (1). >>> >>>>> If we can't depend upon otherName being filled in, then we have to look for >>>>> two things. That means more code paths (two more) to test, more test >>>>> vectors, and what exactly does an end point do when both are present, BUT >>>>> THEY DO NOT MATCH? So three more pages of text there. >>>>> Remember, that just rejecting the certificate means that we have to send out >>>>> a truck, which is what ACP aims to avoid, so that won't be popular. >>>>> And of course, there could also be bugs (maybe even CVEs) in the code that >>>>> tries to deal with the tie. >>> >>> To be honest, this argument feels like a stronger one to me than the bits >>> in the -24. I'm still not willing to accept into the RFC Series a document >>> that violates the rules set down by the specification for the technology >>> it's making use of, but the refocus on the "running code" aspect is >>> appreciated. >>> >>> -Ben >>> > > From nobody Fri Jun 19 20:34:28 2020 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D0163A1015 for ; Fri, 19 Jun 2020 20:34:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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_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=sn3rd.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 v4R7iGQAIHcY for ; Fri, 19 Jun 2020 20:34:23 -0700 (PDT) Received: from mail-qt1-x842.google.com (mail-qt1-x842.google.com [IPv6:2607:f8b0:4864:20::842]) (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 4E92A3A1011 for ; Fri, 19 Jun 2020 20:34:23 -0700 (PDT) Received: by mail-qt1-x842.google.com with SMTP id i16so8777613qtr.7 for ; Fri, 19 Jun 2020 20:34:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Aszs29qA0BGt/ypkNk+XPxJeuNoW576a5/TKWNWImRU=; b=Ps59ZmXOVCz2s5ymeU0BBHvOvzz8nmx/Racn+X9fWFPPx4XBI85NluYwTgeJWscNvi u+GRxN5zegamtrdB759cpiIOkOm8i5OdfT/CrdjITxODFKtEOwhZJOE35+mLXXQSNouj 5m40Iyqi70Y/sbb61MPy6a+XR8MAFYwmQKexs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Aszs29qA0BGt/ypkNk+XPxJeuNoW576a5/TKWNWImRU=; b=uidQCKCdmio2zgZDvK/lwO5DY4Ovm+olW3Lladl8k+4hjXCzJrhEGBva8DyeH3rr3v 6rC21YuLKC6RFO79mWyooNmtyq67V4Y0Vt/VKiQjOTsJCozAd03eISqX3g6JblhjR5en XZRb2/wlK9DmENbKR7P4j1jDq0/hoTAcKq8/RkWvudxTxZRB3mfJWXAkm+89g90QEDth SZApUKJtJPSHsBjdq0O4Tx9b8NQeDzgsCfKsYZtnOtUwV0OSgaE4XhbXZsL99tnIkn9U ocFGtHg4SKy/IYgzmTPNgliOPuG8bXNgUABBQeG79TWS6lyqn/6EOUGnVWRdvUOGjTIH rTng== X-Gm-Message-State: AOAM5332OYXhQpJshyyhW3PEAX3P2egs7uZXdQhf31prBO6ScHfH+C3z pq0PZY7u7SLz0/NZgjpqDMk9fg== X-Google-Smtp-Source: ABdhPJxSAS1s8YnbhFQMGXTXAm0UaylAXyhR71iRvZPMbWfsTJztHnHayES092We57ztreLMYyxIdQ== X-Received: by 2002:ac8:6b53:: with SMTP id x19mr6588104qts.106.1592624062027; Fri, 19 Jun 2020 20:34:22 -0700 (PDT) Received: from sn3rd.lan ([75.102.131.34]) by smtp.gmail.com with ESMTPSA id p7sm3022639qki.61.2020.06.19.20.34.20 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 19 Jun 2020 20:34:21 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Sean Turner In-Reply-To: <20200617024412.GA11992@kduck.mit.edu> Date: Fri, 19 Jun 2020 23:34:19 -0400 Cc: Russ Housley Content-Transfer-Encoding: quoted-printable Message-Id: References: <11428.1592266833@localhost> <20200617024412.GA11992@kduck.mit.edu> To: Benjamin Kaduk , anima@ietf.org, Brian E Carpenter , Michael Richardson X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Anima] rfc822Name use in Autonomic Control Plane document X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Jun 2020 03:34:26 -0000 I am coming at this way late, and I apologize for that. After reviewing draft-ietf-anima-autonomic-control-plane, I think that = putting ACP Domain Information in rfc822Name is a bad idea. After = reviewing the mailing list for rfc822Name-related messages, I think I = may have graduated to thinking that putting ACP Domain Information in = rfc822Name is a very risky deployment strategy, and I may have even = graduated to thinking it is harmful to others in the Internet ecosystem. rfc822Name is meant to convey =E2=80=9Can Internet mail address=E2=80=9D = [RFC5280]. ACP Domain Information is not that so it seems, at least to = me, like rfc822Name is not the right place to put ACP Domain = Information. My next thought was that others have defined values for otherName, which = is the extension point in X.509 to support name forms not envisioned in = 2002, so what is special about anima that they should to =E2=80=9Csquat" = on an existing name form? The rationale, which seems oddly out of place = in a normative section, did not really make sense to me, especially in = the context of IDevID and LDevID. For example, the =E2=80=9CRfc822 = addresses have become standard identifiers of entities in many systems, = including the majority of user identification in web or mobile = applications, ...=E2=80=9D might well be true for humans, but it is not = true for devices. Humans can only remember few identifiers (e.g., an = email addresses) and type them correctly over and over. The situation = here is vey different; a device is identified (and authenticated) by the = IDevID and LDevID. The sense I got from the rationale boils down to: we = need some certs and we think we can get them if we put our =E2=80=9Cname" = in a commonly supported field. Regardless of whether public CAs or enterprise CAs issue the certs, what = seems to be getting lost here is that running a CA is more than just = running a server and signing a bag of bits. If you are going to run a CA = that is trusted beyond your organization, a lot of policies and = procedures are followed to make it trustworthy. You need to write a CP = (Certificate Policy) and CPS (Certification Practice Statement) = [RFC3647], get lawyers to review it and probably write section 9 (Other = Business and Other legal Matters), and you are going to need to get = regular audits from a reputable firm. To limit your liability, you are = also likely going to need to have Subscriber and/or Relying Party = agreements. As far as private CAs goes, I am not trying to say what is hard and what = is not, but both Microsoft CA and OpenSSL support arbitrary data being = placed in a subjectAltName.otherName: - MS: = https://docs.microsoft.com/en-us/windows/win32/api/certenroll/nn-certenrol= l-ix509extensionalternativenames - OpenSSL: https://www.openssl.org/docs/man1.0.2/ If you are relying on a public CA, I think this is a very risky = deployment strategy because this I-D is saying that it is okay to = request a name that that has different semantics than the name that you = are asking to be certified. Consider whether: - a CA could reject the request outright? - a CA would revoke an already issued certificate after determining that = the request did not comply with the CP, CPS and/or Subscriber agreement? - an RP could later claim damages because the Subscriber did not request = the certificate in good faith? I also think that there is some potential for negative impacts on others = in the Internet ecosystem based on this I-D, at least in the light of = the above. For example, maybe just maybe somebody manages to get 100K = IDevID certificates from a public CA. That public CA decides that those = certificates were mis-issued and revokes them as their CP/RP agreement = allows (or even requires). An entity that has to download and then slog = through the bigger-than-normal CRL (Certificate Revocation List) is = adversely affected. Maybe that CA only supports OCSP (Online Certificate = Status Protocol), but the OCSP Responder is fed by a CRL, the CA still = needs to store and process the bigger-than-normal CRL to pump out the = OCSP responses so the CA is also adversely impacted. I know I am not providing an alternative solution here, but maybe we can = do that in another thread. spt > On Jun 16, 2020, at 22:44, Benjamin Kaduk wrote: >=20 > Hi Brian, Michael, >=20 > On Tue, Jun 16, 2020 at 02:14:24PM +1200, Brian E Carpenter wrote: >> On 16-Jun-20 12:20, Michael Richardson wrote: >>>=20 >>> Hi, I have had a few conversations with Toerless who is trying to = deal with >>> the feedback on the ACP document. >>>=20 >>> An item that has come up is the use, or claimed abuse of the = rfc822Name SAN. >>>=20 >>> We already had this debate. >>> Some time ago. The WG decided. >=20 > With all due respect, this is not the sole decision of the ANIMA WG to > make. If WGs had such authority then why bother with cross-area = review? >=20 >>> Three or four years ago, I think. >>=20 >> Yes, this is relitigating an issue that was resolved a long time ago = in discussing Ben's DISCUSS: >=20 > I'm not sure I understand why you use the word "resolved" here: >=20 >> = https://mailarchive.ietf.org/arch/msg/anima/lnZ-ykqas487qih86sYNVsUGbsc >=20 > In this message, I say that "I still feel like this is not the best > architectural choice" and that I will provide a sketch of an = alternative in > my (then-)forthcoming ballot position; that ballot position retains = the > Discuss-level concern about rfc822Name usage along with the promised > alternative. >=20 >> The explanation is at = https://tools.ietf.org/html/draft-ietf-anima-autonomic-control-plane-24#pa= ge-26 >=20 > I appreciate that the attempted justification is clearly written; = however, > I do not find it compelling. Russ did not, either, and I just heard = back > from Sean Turner a few days ago to confirm that he supports Russ's > comments. (There should be a few other editorial-ish comments that = came > out of that review that are still pending.) >=20 >> I believe it is incorrect IETF process to rediscuss this point yet = again. >=20 > (I'm not sure if the "yet again" refers to "after the WG decided" or = "after > the (alleged) resolution of my first Discuss point".) >=20 > If you believe the technical answer is clear and that I am in error to > continue to hold my Discuss point for it, are there not also clear = IETF > processes to follow? E.g., asking for the "Single Discuss" ballot = procedure > described at https://www.ietf.org/standards/process/iesg-ballots/? I > believe I have mentioned this option to Toerless previously; my = apologies > if that is not the case. While I'm willing to continue discussing the > topic and pull in additional PKIX experts to weigh in, there is = perhaps > some consideration to matters of expediency. >=20 >>>=20 >>> I sure wish that we could use something else. >>> But, CAs and CA software make that very difficult. >>>=20 >>> Given that the era of publically anchored Enterprise CAs is dead, = there are >>> only two ways an (Enterprise) ACP Registrar is going to occur. >>>=20 >>> 1) by running a private CA. >>> Sure anything is possible if you are writing your own code, but >>> most will not be doing that. (I've supported otherName in my code = for >>> other purposes, and it's not that difficult, but it's not trivial = either) >>> My experience with COTS CA systems it that it's really hard to >>> get them to do it. Please prove me wrong. >=20 > (Sadly, I have zero experience with COTS CA systems; I know too much = about > openssl at this point and would presumably be writing my own, in this > position.) >=20 >>> The most popular Enterprise CA software is the Microsoft CA. >>>=20 >>> 2) by using ACME to speak to a hosted CA. Maybe WebPKI, maybe not. >>> Either way, getting otherName supported is even harder, because >>> nobody else uses it. >=20 > Is the concern the ACME protocol support or just getting the hosted CA = to > cope with it? The former seems like something that we could make = happen in > the IETF, and the latter seems to have high overlap with point (1). >=20 >>> If we can't depend upon otherName being filled in, then we have to = look for >>> two things. That means more code paths (two more) to test, more = test >>> vectors, and what exactly does an end point do when both are = present, BUT >>> THEY DO NOT MATCH? So three more pages of text there. >>> Remember, that just rejecting the certificate means that we have to = send out >>> a truck, which is what ACP aims to avoid, so that won't be popular. >>> And of course, there could also be bugs (maybe even CVEs) in the = code that >>> tries to deal with the tie. >=20 > To be honest, this argument feels like a stronger one to me than the = bits > in the -24. I'm still not willing to accept into the RFC Series a = document > that violates the rules set down by the specification for the = technology > it's making use of, but the refocus on the "running code" aspect is > appreciated. >=20 > -Ben From nobody Sat Jun 20 16:48:26 2020 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1594F3A07A7 for ; Sat, 20 Jun 2020 16:48:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=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 vW7MsBZM1I4B for ; Sat, 20 Jun 2020 16:48:22 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 458263A07A6 for ; Sat, 20 Jun 2020 16:48:22 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 05KNmFu3001581 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 20 Jun 2020 19:48:17 -0400 Date: Sat, 20 Jun 2020 16:48:14 -0700 From: Benjamin Kaduk To: Brian E Carpenter Cc: Michael Richardson , anima@ietf.org, Russ Housley , sean+ietf@sn3rd.com Message-ID: <20200620234814.GC11992@kduck.mit.edu> References: <11428.1592266833@localhost> <20200617024412.GA11992@kduck.mit.edu> <9584c5cd-c68d-ddc3-0704-da672842e359@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9584c5cd-c68d-ddc3-0704-da672842e359@gmail.com> User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [Anima] rfc822Name use in Autonomic Control Plane document X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Jun 2020 23:48:24 -0000 Hi Brian, On Fri, Jun 19, 2020 at 05:11:30PM +1200, Brian E Carpenter wrote: > Hi Ben, > > (Back on line after a couple of days spent moving apartments.) (and me after getting slowed down by being sick) > On 17-Jun-20 14:44, Benjamin Kaduk wrote: > > Hi Brian, Michael, > > > > On Tue, Jun 16, 2020 at 02:14:24PM +1200, Brian E Carpenter wrote: > >> On 16-Jun-20 12:20, Michael Richardson wrote: > >>> > >>> Hi, I have had a few conversations with Toerless who is trying to deal with > >>> the feedback on the ACP document. > >>> > >>> An item that has come up is the use, or claimed abuse of the rfc822Name SAN. > >>> > >>> We already had this debate. > >>> Some time ago. The WG decided. > > > > With all due respect, this is not the sole decision of the ANIMA WG to > > make. If WGs had such authority then why bother with cross-area review? > > Yes, but that was exactly the reason we had the discussion a year ago. I think the expansion of the "we" is important, here -- who did you have in mind? > >>> Three or four years ago, I think. > >> > >> Yes, this is relitigating an issue that was resolved a long time ago in discussing Ben's DISCUSS: > > > > I'm not sure I understand why you use the word "resolved" here: > > > >> https://mailarchive.ietf.org/arch/msg/anima/lnZ-ykqas487qih86sYNVsUGbsc > > > > In this message, I say that "I still feel like this is not the best > > architectural choice" and that I will provide a sketch of an alternative in > > my (then-)forthcoming ballot position; that ballot position retains the > > Discuss-level concern about rfc822Name usage along with the promised > > alternative. > "Not the best choice" is not a DISCUSS criterion according to the IESG's own rules at https://www.ietf.org/about/groups/iesg/statements/iesg-discuss-criteria/#stand-undisc > > It was exactly this sort of endless debate over "best choice" disagreements that caused the IESG to adopt the DISCUSS criteria rules in the first place. > > If you are saying that one of the criteria in https://www.ietf.org/about/groups/iesg/statements/iesg-discuss-criteria/#stand-disc applies, that's a different matter, of course. But really, no AD should hold a DISCUSS over "not the best choice". Sorry, that was the second round of Discuss and my politness filter may have been overactive. Allow me to rephrase: I think that the use of rfc822Name in this document is inconsistent with the specification for that field given in RFC 5280. I do not believe that there is IETF consensus (specifically, including the IETF PKIX community, e.g., the LAMPS WG) for this deviation from the RFC 5280 behavior, and it is not documented (and consensus obtained for it) as such a deviation from RFC 5280. I believe there are several ways in which the necessary functionality for this specification can be obtained that remain consistent with RFC 5280; specifying the use of any of them would suffice to resolve the Discuss point. The "smallest diff to the text" option would be to define an otherName OID to carry the same contents currently specified for rfc822Name, but other options involving splitting the semantic components into EKU/iPAddress SAN/extension/etc. are possible. I could probably even accept a non-normative note saying that some legacy deployments used the rfc822Name field, though given Sean's review there would probably need to be a pretty strong disclaimer of the risks of doing so. [one more note at the end] > Not to mention that this is only a Proposed Standard discussion; perfection not required. > > I don't consider myself enough of a subject matter expert to comment on the technical issue itself. > > Regards > Brian > > > > >> The explanation is at https://tools.ietf.org/html/draft-ietf-anima-autonomic-control-plane-24#page-26 > > > > I appreciate that the attempted justification is clearly written; however, > > I do not find it compelling. Russ did not, either, and I just heard back > > from Sean Turner a few days ago to confirm that he supports Russ's > > comments. (There should be a few other editorial-ish comments that came > > out of that review that are still pending.) > > > >> I believe it is incorrect IETF process to rediscuss this point yet again. > > > > (I'm not sure if the "yet again" refers to "after the WG decided" or "after > > the (alleged) resolution of my first Discuss point".) > > > > If you believe the technical answer is clear and that I am in error to > > continue to hold my Discuss point for it, are there not also clear IETF > > processes to follow? E.g., asking for the "Single Discuss" ballot procedure > > described at https://www.ietf.org/standards/process/iesg-ballots/? I > > believe I have mentioned this option to Toerless previously; my apologies > > if that is not the case. While I'm willing to continue discussing the > > topic and pull in additional PKIX experts to weigh in, there is perhaps > > some consideration to matters of expediency. > > > >>> > >>> I sure wish that we could use something else. > >>> But, CAs and CA software make that very difficult. > >>> > >>> Given that the era of publically anchored Enterprise CAs is dead, there are > >>> only two ways an (Enterprise) ACP Registrar is going to occur. > >>> > >>> 1) by running a private CA. > >>> Sure anything is possible if you are writing your own code, but > >>> most will not be doing that. (I've supported otherName in my code for > >>> other purposes, and it's not that difficult, but it's not trivial either) > >>> My experience with COTS CA systems it that it's really hard to > >>> get them to do it. Please prove me wrong. > > > > (Sadly, I have zero experience with COTS CA systems; I know too much about > > openssl at this point and would presumably be writing my own, in this > > position.) > > > >>> The most popular Enterprise CA software is the Microsoft CA. > >>> > >>> 2) by using ACME to speak to a hosted CA. Maybe WebPKI, maybe not. > >>> Either way, getting otherName supported is even harder, because > >>> nobody else uses it. > > > > Is the concern the ACME protocol support or just getting the hosted CA to > > cope with it? The former seems like something that we could make happen in > > the IETF, and the latter seems to have high overlap with point (1). > > > >>> If we can't depend upon otherName being filled in, then we have to look for > >>> two things. That means more code paths (two more) to test, more test > >>> vectors, and what exactly does an end point do when both are present, BUT > >>> THEY DO NOT MATCH? So three more pages of text there. > >>> Remember, that just rejecting the certificate means that we have to send out > >>> a truck, which is what ACP aims to avoid, so that won't be popular. > >>> And of course, there could also be bugs (maybe even CVEs) in the code that > >>> tries to deal with the tie. > > > > To be honest, this argument feels like a stronger one to me than the bits > > in the -24. I'm still not willing to accept into the RFC Series a document > > that violates the rules set down by the specification for the technology > > it's making use of, but the refocus on the "running code" aspect is > > appreciated. > > Thinking about this a bit more, it seems like it would be doable (and, more importantly, testable) to require that if the otherName (or whatever) is present, there MUST NOT be an rfc822Name present. Which doesn't necessarily help with the "need to implement" bit for sites that use rfc822Name, of course, but should avoid the worst of the risks for when two sources of data don't match. -Ben From nobody Sat Jun 20 17:03:42 2020 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9C7D3A07BA for ; Sat, 20 Jun 2020 17:03:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 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_MSPIKE_H2=-0.001, 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=verizon.net 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 KHVipwO_myf8 for ; Sat, 20 Jun 2020 17:03:39 -0700 (PDT) Received: from sonic316-12.consmr.mail.bf2.yahoo.com (sonic316-12.consmr.mail.bf2.yahoo.com [74.6.130.122]) (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 C11763A07B6 for ; Sat, 20 Jun 2020 17:03:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verizon.net; s=a2048; t=1592697818; bh=bqpO0GHSSrNP4sD6SW1OmvTh/FrglViMPVO3cgyvr4I=; h=To:From:Subject:Date:References:From:Subject; b=ZeTSnfP7lVHNze/3zuVedjkZCXRwtIiZSoVBhwpPrs+oS9UclNcfvHxaZkBdcobLuiUShcT8TMDW+EIBC+nDf81SfA3Odt3FE/QNYENF+VS/XTp+TrCKdulSmq2wgADSUbcdo8nkh7QqfOvx8ffhLRTI4z9a6YS+sVe5OHbZD8m5g0/gkFHQhl6XPEMpxRnCblwFy9IgO1Mblo/iniRZ9mXom7g2BsJWA+JuOW+QYY86hNXOpmxm++jc/Ae++KQkLTVbyzi3XhIY68NbhTu4hPmoZTyVJAEj4jczMe6x12WfAdn7I4k5Y+xZBM60GqNN4isCFiJcLXyUJf2VxBrtRQ== X-YMail-OSG: F1E.nG4VM1kMugB_s4doWs0dOl1ba3d5p787HPHYj3naUBNrBxZ6SiH5ZVZ3diJ 4jr0onhphE.klGAv5Ng0HuXEE9fDpOyJzpUZcVs1GiyL9QRhmxVTjrp0j3TGhZexeQVgOhqglL1t PZwvXq.bANMcu2ULRrqSA.IsdSubx8VXa76vzetukltDAlblMEU019bv5otG2Uarxmdd6eUSu3Xf Y1iX67auRAuE.qJUIc3RMHBTyZOUlJd9E5R1nQ30nCC8QeuNv6LYb5RAIq4tJikx5syLAPm1ptDM WC9Is61TCwKKVh7.22HRZoOfmpmnqCSdSdn4_4sxicimAn4l2CkuoB8lMBeioV8IlSJOCJ4HwbaM q5tQkCs7M9q4Ty0X3KYplZia_3taEWePtSvZhFGsQIWxD0Ae70aN53jqAl56c92sVmdhF19lgv83 D6yPMOXq5wzhFgucOXLeojnjKAjaZfkgvoD2IqC8Hz6X8y_b_eddDDFfMdsffKWJuNIA2PIXEEeV 8DkEulnG_yLnXAZO5n04pevZCHVqvW0VrctPWNwMxRgQtMUZU.UQoI8Ftl1aOlzuySq.a7LaE_z2 oqgNuYjk5vx9iifdwFh5KPfy0Nka_fbxrT3ggJX5EqNPCv9eohebC1grYe3aCpnIvB8RIra5ubtG bFaf7Gy15M06plNeM5DGFeIs3ggalqxXXFA.vArprf24En5P6AiPFtJ5bH.8WqkBiZVVYFu.o7D9 9NGqqTuT1CKDMpVaUhKoxr9FBxF8jGyTcF6fbdGSN7pCFvADpDCf.STuGIH8Le0oZjpn9ogM3.Ie 4tFLXK7fGJmYX7sTEh.ZSNTXLk0kwc7ggPFGL8OSMGn6hSjvJAkeA9BLEzvQ9UQ5d6sUJXGw1efK 7XEoUsaOa7CLGwZcCC2i8pZEhN4bklCxrXVN2qlu8RyJEQ_Xmr9ytoyeuVqVp7lYfL74InLS1G6T gtsVUUbel Received: from sonic.gate.mail.ne1.yahoo.com by sonic316.consmr.mail.bf2.yahoo.com with HTTP; Sun, 21 Jun 2020 00:03:38 +0000 Received: by smtp410.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID a8b8f6c603d8b276ff61976a245114f5; Sun, 21 Jun 2020 00:03:33 +0000 (UTC) To: anima@ietf.org From: Stephen Kent Message-ID: Date: Sat, 20 Jun 2020 20:03:31 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------4E984BB7D5F4FD56BDFC3D17" Content-Language: en-US References: X-Mailer: WebService/1.1.16138 hermes_aol Apache-HttpAsyncClient/4.1.4 (Java/11.0.7) Archived-At: Subject: [Anima] representing ACP info in X.509 certs X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Jun 2020 00:03:41 -0000 This is a multi-part message in MIME format. --------------4E984BB7D5F4FD56BDFC3D17 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Folks, My perspective matches what Russ & Ben have suggested, i.e., use of rfc822Name is inappropriate for this context. RFC 5280 is very clear about the intended use of the rfc822Name field in a cert and the proposed use in the anima context is inconsistent with 5280 text. A reasonable, appropriate way forward is to define a new otherName type for the anima context. Steve --------------4E984BB7D5F4FD56BDFC3D17 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit

Folks,

My perspective matches what Russ & Ben have suggested, i.e., use of rfc822Name is inappropriate for this context. RFC 5280 is very clear about the intended use of the rfc822Name field in a cert and the proposed use in the anima context is inconsistent with 5280 text. A reasonable, appropriate way forward is to define a new otherName type for the anima context.

Steve

--------------4E984BB7D5F4FD56BDFC3D17-- From nobody Sat Jun 20 18:26:18 2020 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F11EF3A0803 for ; Sat, 20 Jun 2020 18:26:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, 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 (2048-bit key) header.d=rtfm-com.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 WzzlwrmWQMk4 for ; Sat, 20 Jun 2020 18:26:15 -0700 (PDT) Received: from mail-lj1-x231.google.com (mail-lj1-x231.google.com [IPv6:2a00:1450:4864:20::231]) (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 3225A3A07F9 for ; Sat, 20 Jun 2020 18:26:15 -0700 (PDT) Received: by mail-lj1-x231.google.com with SMTP id i27so15505332ljb.12 for ; Sat, 20 Jun 2020 18:26:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=wVqySJiflhlDzsr2RTgT1KNfM17eKj0vlRFVOx0KJuU=; b=yP8/gxJSHV2u37t/v5CxRn+cji53ySogSUGk4elIZNIPEfbMw1EHiEBZN7Pd81ckI+ jkJONZ+28vfwQhVg3tbY5EifISyqdLJ183AcDzTNp3i+dfSxw4lHWU+ekF3IbBbxO/GA Ipmnu8OG1+pep+CKzOzwd+2Om+KrU4jsYG+yAw6vIhlzSpPMBgByhYl/bOA5Q3nxaFS6 +CdoFwPfpxfSXvpzJoROLZIQtXOeRsGKa1qB3Qc7MszzIjjSLeGnR2aEKHjHjr7fejks tFVwFhq7vXpSUo2RMEL792JGmRD/J6Ml/Y4dKZ0QatLnd9hqMIi3j6HKt1T2exKPcxZk WOfg== 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=wVqySJiflhlDzsr2RTgT1KNfM17eKj0vlRFVOx0KJuU=; b=IFT2R9Gfs4+l/17OrEQXH2NzNjHYQsUM8FspGitzr/PAt5JgblPEjKBRsMPk07fsQ3 WwUUEsPfRsdznQD2qB7hsUVeFDwgqtNBALcSlXKtFpbJ6zZBGoGO7En3+0aXPw4OjLKF ZlXbL0PYjtmS8jKXqk96+odBQ/2tp9yfi4VZjjJwoOAw4g2wpL4M7Rwa2aR6GBzMDE/T EeAMlKzpLONLVYJTY4DsVBUnpJJY97k5KfRhptF1WZsCGxxUzsrJh6edNu1Il/1hZvcF CjJ2EbWsa1rOqcf2Y8EoBYKnr8CZDLBVoP5KYnbf9zSzlqkKmu0Puh27dWtb9DBEFHAf 6a3A== X-Gm-Message-State: AOAM532w1cg+TzzrhR/sM8sJytg9oRm4Gu/coJ0gHSO0cbjzD/7Cp5qs dmb6o5UdiqVZRPvuGjD2t8LW0oNYOR7QtIjU0Cs+3g== X-Google-Smtp-Source: ABdhPJy5avmH/bBuDiRPlDz5lPRrukvXft52iUO2GUo6jZR5EtotftYUmzEZaMlJ/O2ZH9Kvg/8hWpsymx4h4RHW3ig= X-Received: by 2002:a2e:9d98:: with SMTP id c24mr4764830ljj.17.1592702773284; Sat, 20 Jun 2020 18:26:13 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Eric Rescorla Date: Sat, 20 Jun 2020 18:25:37 -0700 Message-ID: To: Stephen Kent Cc: Anima WG Content-Type: multipart/alternative; boundary="00000000000008e56505a88e03cb" Archived-At: Subject: Re: [Anima] representing ACP info in X.509 certs X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Jun 2020 01:26:17 -0000 --00000000000008e56505a88e03cb Content-Type: text/plain; charset="UTF-8" This matches my understanding as well. One thing that's not clear to me: is the expectation that you will be using a public CA or that you will be using an enterprise-level one? -Ekr On Sat, Jun 20, 2020 at 5:03 PM Stephen Kent wrote: > Folks, > > My perspective matches what Russ & Ben have suggested, i.e., use of > rfc822Name is inappropriate for this context. RFC 5280 is very clear > about the intended use of the rfc822Name field in a cert and the proposed > use in the anima context is inconsistent with 5280 text. A reasonable, > appropriate way forward is to define a new otherName type for the anima > context. > > Steve > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima > --00000000000008e56505a88e03cb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
This matches my understanding as well.

=
One thing that's not clear to me: is the expectation that yo= u will be using a public CA or that you will be using an enterprise-level o= ne?

-Ekr


On Sat, Jun 20, 2020= at 5:03 PM Stephen Kent <stkent=3D40verizon.net@dmarc.ietf.org> wrote:
=20 =20 =20

Folks,

My perspective matches what Russ & Ben have suggested, i.e., use of rfc822Name is inappropriate for this context. RFC 5280 is very clear about the intended use of the rfc822Name field in a cert and the proposed use in the anima context is inconsistent with 5280 text. A reasonable, appropriate way forward is to define a new otherName type for the anima context.

Steve

_______________________________________________
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima
--00000000000008e56505a88e03cb-- From nobody Sat Jun 20 19:41:54 2020 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C1063A0848 for ; Sat, 20 Jun 2020 19:41:53 -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, FREEMAIL_FROM=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 4bhgzLCT1Gwz for ; Sat, 20 Jun 2020 19:41:50 -0700 (PDT) Received: from mail-pf1-x441.google.com (mail-pf1-x441.google.com [IPv6:2607:f8b0:4864:20::441]) (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 DC3E73A0846 for ; Sat, 20 Jun 2020 19:41:50 -0700 (PDT) Received: by mail-pf1-x441.google.com with SMTP id x207so6636309pfc.5 for ; Sat, 20 Jun 2020 19:41:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=aWVGCQM1h3bymCoIUSVw8dOBgan+2JuqgIuHc2/MjHE=; b=I+G6L86Rp9X7dPFj5e044ZivrPV8SPCFJ44PMzVp+PVwLYh4dKhqvKUOEnlGL4EYWZ tK+dXOFVel3d+Za1H4Gd5ZRAlEuc/Ur1I9gc1Drd8Hu16YjNHbFlya/SjUHmjIU1tvGO 0JHWzSF7eZFjO/yeJbA5z0izwH4xy7a8igvyeubeID19OWKaK7WNsKHUnVDo8Klc7NTE Qe/QMOZypMlQsXs7zswO6/UcV/q+rqjWj4i6jpRIppwAPJptAuoqfzaddEg8wbMLcPhd a0Eb8P865h4ssIoMhz0EfVsS4HhPtNzVz9hiFZLFa6/KdKCTSU437kLnIMKPSyqL0oP2 YTUg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=aWVGCQM1h3bymCoIUSVw8dOBgan+2JuqgIuHc2/MjHE=; b=TyX46ygC7pqf9krYYlu9mI2+VVBHrh5j6kEUuD6l1HX2F5LFvI2VFJm05FPTFY5kbZ RBNI+JgyxauzCkHYLwA+MrF2/FuwmkUNHhLrtavzT/mwNk0Qa2joQ+4kJERcBByz8O2Q //WPLh8sMT9xuJJCppmpnLnxbEP2bdxU0wDH1w45RA8PlNBSQfmpiyACbCRiexd8VrEP 2UOl3ppdxtFbFC341N9u37qiMUDVuXBJD9HhQQuDbhY+eLnfmJxavnvgRFUtLB/PkmJS 4kCph+ZnTB/QXChWKhnm2tCjXiSL+0jJvJcfBrv2TjYYTXleFhm6EZCsIk9AOdNMzhGz yaKw== X-Gm-Message-State: AOAM5300/ubflGrwV0McfVsgZo8eVgBRm2YB3+mW3yv1FHaQgctgA3+B NhGj6X3128PpG0815VzZx4in/zPVF5Q= X-Google-Smtp-Source: ABdhPJzbnhjTHqXKURH/4w2lLv+7pXhgCcP4vUoEB/tkZhEDcioObA15HZtk/qfKSnIRXPrAfuFVsw== X-Received: by 2002:a63:d847:: with SMTP id k7mr8155931pgj.93.1592707310173; Sat, 20 Jun 2020 19:41:50 -0700 (PDT) Received: from [192.168.178.30] (247.90.69.111.dynamic.snap.net.nz. [111.69.90.247]) by smtp.gmail.com with ESMTPSA id w206sm10004064pfc.28.2020.06.20.19.41.46 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 20 Jun 2020 19:41:49 -0700 (PDT) To: Benjamin Kaduk Cc: Michael Richardson , anima@ietf.org, Russ Housley , sean+ietf@sn3rd.com References: <11428.1592266833@localhost> <20200617024412.GA11992@kduck.mit.edu> <9584c5cd-c68d-ddc3-0704-da672842e359@gmail.com> <20200620234814.GC11992@kduck.mit.edu> From: Brian E Carpenter Message-ID: <596df468-58d2-1a5c-f667-952d2b668191@gmail.com> Date: Sun, 21 Jun 2020 14:41:43 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <20200620234814.GC11992@kduck.mit.edu> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] rfc822Name use in Autonomic Control Plane document X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Jun 2020 02:41:53 -0000 Thanks Ben. It's important IMHO to be precise about technical objections and your statement below is precise. As a non-expert, I'll refrain from technical comment. Regards Brian On 21-Jun-20 11:48, Benjamin Kaduk wrote: > Hi Brian, > > On Fri, Jun 19, 2020 at 05:11:30PM +1200, Brian E Carpenter wrote: >> Hi Ben, >> >> (Back on line after a couple of days spent moving apartments.) > > (and me after getting slowed down by being sick) > >> On 17-Jun-20 14:44, Benjamin Kaduk wrote: >>> Hi Brian, Michael, >>> >>> On Tue, Jun 16, 2020 at 02:14:24PM +1200, Brian E Carpenter wrote: >>>> On 16-Jun-20 12:20, Michael Richardson wrote: >>>>> >>>>> Hi, I have had a few conversations with Toerless who is trying to deal with >>>>> the feedback on the ACP document. >>>>> >>>>> An item that has come up is the use, or claimed abuse of the rfc822Name SAN. >>>>> >>>>> We already had this debate. >>>>> Some time ago. The WG decided. >>> >>> With all due respect, this is not the sole decision of the ANIMA WG to >>> make. If WGs had such authority then why bother with cross-area review? >> >> Yes, but that was exactly the reason we had the discussion a year ago. > > I think the expansion of the "we" is important, here -- who did you have in > mind? Well, I guess it was between you and the WG, but prior to IETF-wide review. My understanding was that we'd reached an unhappy compromise, but apparently not. Brian > >>>>> Three or four years ago, I think. >>>> >>>> Yes, this is relitigating an issue that was resolved a long time ago in discussing Ben's DISCUSS: >>> >>> I'm not sure I understand why you use the word "resolved" here: >>> >>>> https://mailarchive.ietf.org/arch/msg/anima/lnZ-ykqas487qih86sYNVsUGbsc >>> >>> In this message, I say that "I still feel like this is not the best >>> architectural choice" and that I will provide a sketch of an alternative in >>> my (then-)forthcoming ballot position; that ballot position retains the >>> Discuss-level concern about rfc822Name usage along with the promised >>> alternative. >> "Not the best choice" is not a DISCUSS criterion according to the IESG's own rules at https://www.ietf.org/about/groups/iesg/statements/iesg-discuss-criteria/#stand-undisc >> >> It was exactly this sort of endless debate over "best choice" disagreements that caused the IESG to adopt the DISCUSS criteria rules in the first place. >> >> If you are saying that one of the criteria in https://www.ietf.org/about/groups/iesg/statements/iesg-discuss-criteria/#stand-disc applies, that's a different matter, of course. But really, no AD should hold a DISCUSS over "not the best choice". > > Sorry, that was the second round of Discuss and my politness filter may > have been overactive. Allow me to rephrase: > > I think that the use of rfc822Name in this document is inconsistent with > the specification for that field given in RFC 5280. I do not believe that there > is IETF consensus (specifically, including the IETF PKIX community, e.g., > the LAMPS WG) for this deviation from the RFC 5280 behavior, and it is not > documented (and consensus obtained for it) as such a deviation from RFC > 5280. > > I believe there are several ways in which the necessary functionality for > this specification can be obtained that remain consistent with RFC 5280; > specifying the use of any of them would suffice to resolve the Discuss > point. The "smallest diff to the text" option would be to define an > otherName OID to carry the same contents currently specified for > rfc822Name, but other options involving splitting the semantic components > into EKU/iPAddress SAN/extension/etc. are possible. I could probably even > accept a non-normative note saying that some legacy deployments used the > rfc822Name field, though given Sean's review there would probably need to > be a pretty strong disclaimer of the risks of doing so. > > [one more note at the end] > >> Not to mention that this is only a Proposed Standard discussion; perfection not required. >> >> I don't consider myself enough of a subject matter expert to comment on the technical issue itself. >> >> Regards >> Brian >> >>> >>>> The explanation is at https://tools.ietf.org/html/draft-ietf-anima-autonomic-control-plane-24#page-26 >>> >>> I appreciate that the attempted justification is clearly written; however, >>> I do not find it compelling. Russ did not, either, and I just heard back >>> from Sean Turner a few days ago to confirm that he supports Russ's >>> comments. (There should be a few other editorial-ish comments that came >>> out of that review that are still pending.) >>> >>>> I believe it is incorrect IETF process to rediscuss this point yet again. >>> >>> (I'm not sure if the "yet again" refers to "after the WG decided" or "after >>> the (alleged) resolution of my first Discuss point".) >>> >>> If you believe the technical answer is clear and that I am in error to >>> continue to hold my Discuss point for it, are there not also clear IETF >>> processes to follow? E.g., asking for the "Single Discuss" ballot procedure >>> described at https://www.ietf.org/standards/process/iesg-ballots/? I >>> believe I have mentioned this option to Toerless previously; my apologies >>> if that is not the case. While I'm willing to continue discussing the >>> topic and pull in additional PKIX experts to weigh in, there is perhaps >>> some consideration to matters of expediency. >>> >>>>> >>>>> I sure wish that we could use something else. >>>>> But, CAs and CA software make that very difficult. >>>>> >>>>> Given that the era of publically anchored Enterprise CAs is dead, there are >>>>> only two ways an (Enterprise) ACP Registrar is going to occur. >>>>> >>>>> 1) by running a private CA. >>>>> Sure anything is possible if you are writing your own code, but >>>>> most will not be doing that. (I've supported otherName in my code for >>>>> other purposes, and it's not that difficult, but it's not trivial either) >>>>> My experience with COTS CA systems it that it's really hard to >>>>> get them to do it. Please prove me wrong. >>> >>> (Sadly, I have zero experience with COTS CA systems; I know too much about >>> openssl at this point and would presumably be writing my own, in this >>> position.) >>> >>>>> The most popular Enterprise CA software is the Microsoft CA. >>>>> >>>>> 2) by using ACME to speak to a hosted CA. Maybe WebPKI, maybe not. >>>>> Either way, getting otherName supported is even harder, because >>>>> nobody else uses it. >>> >>> Is the concern the ACME protocol support or just getting the hosted CA to >>> cope with it? The former seems like something that we could make happen in >>> the IETF, and the latter seems to have high overlap with point (1). >>> >>>>> If we can't depend upon otherName being filled in, then we have to look for >>>>> two things. That means more code paths (two more) to test, more test >>>>> vectors, and what exactly does an end point do when both are present, BUT >>>>> THEY DO NOT MATCH? So three more pages of text there. >>>>> Remember, that just rejecting the certificate means that we have to send out >>>>> a truck, which is what ACP aims to avoid, so that won't be popular. >>>>> And of course, there could also be bugs (maybe even CVEs) in the code that >>>>> tries to deal with the tie. >>> >>> To be honest, this argument feels like a stronger one to me than the bits >>> in the -24. I'm still not willing to accept into the RFC Series a document >>> that violates the rules set down by the specification for the technology >>> it's making use of, but the refocus on the "running code" aspect is >>> appreciated. >>> > > Thinking about this a bit more, it seems like it would be doable (and, more > importantly, testable) to require that if the otherName (or whatever) is > present, there MUST NOT be an rfc822Name present. Which doesn't > necessarily help with the "need to implement" bit for sites that use > rfc822Name, of course, but should avoid the worst of the risks for when two > sources of data don't match. > > -Ben > From nobody Sun Jun 21 09:09:16 2020 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6470B3A0D87 for ; Sun, 21 Jun 2020 09:09: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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 8YXbyKzblkkI for ; Sun, 21 Jun 2020 09:09:13 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DFAD3A0D86 for ; Sun, 21 Jun 2020 09:09:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 7D0D3389B6; Sun, 21 Jun 2020 12:06: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 9fjafKHMr5LV; Sun, 21 Jun 2020 12:06:31 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id C1D29389B4; Sun, 21 Jun 2020 12:06:31 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 7412160; Sun, 21 Jun 2020 12:09:10 -0400 (EDT) From: Michael Richardson To: Eric Rescorla , Stephen Kent , Anima WG 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: [Anima] representing ACP info in X.509 certs X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Jun 2020 16:09:15 -0000 --=-=-= Content-Type: text/plain Eric Rescorla wrote: > One thing that's not clear to me: is the expectation that you will be > using a public CA or that you will be using an enterprise-level one? There are different many use cases, and it is precisely because we can't be prescriptive about the operation of the CA involved that the WG compromised on a solution that we know can be deployed today. I wasn't happy with the result, but I realized that I could live with the compromise result. The WG did consider all the points that you have raised. 1) a private-CA internal to the ACP Registar. 2) an enterprise private-CA external to the ACP Registrar, which is embedded in another system, such as ActiveDirectory 3) when we started this work, it was possible to have (a) and (b) with anchors toward public CAs 4) an enterprise private-CA external to the ACP Registrar, which is operated by a third party, which might use ACME or something else to enroll 5) a small (or growing) enterprise entity that uses ACME to a public CA. The is no "group" policy to deploy a private CA, and there is a strong desire that the devices that are enrolled do not train users to think security exceptions are "normal". Obviously, the DN presented to a browser is not a rfc822Name, but would have to be an dnsName. The ACP rfc822Name may not be the only SAN in the certificate, but it is one that draft-ietf-acme-email-smime-08 allow the Registrar to validate. 6) virtual corporation, where most of the systems are "hosted" systems in "the" cloud. Some of these scenarios are described by https://datatracker.ietf.org/doc/draft-friel-anima-brski-cloud/ 7) construction-site scenarios, where EE LDevID will "be left behind" for the eventual home owner, who could rekey into 1-6. see https://datatracker.ietf.org/doc/draft-fries-anima-brski-async-enroll/ -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl7vhiYACgkQgItw+93Q 3WWVYggAphtSwCLzsUqek+DKHaiwtn2u7cZz3xw/G19e+68mQ0roPB274eqszrZn ik/Z3Z/sa4vjxLpEe3wkwIBERBPM0dR2bfrLFFY+0oJJTo+hMAqolkE498q9/jGJ GfkcDTgBQRfZr1H9Z9ugaxjm9dzvPKHDzMWjg7qe3ZEcTYKn4vZVUfb2bFEdcsFV SbK9IllKP9uXNH5wjbr/F+LpnA3QmHxGYxLzl/I7289IwSnYASwDG8izUpJTtZJ7 qk6gSqrwO4sdmZL6nfh2Uo4K9nb1PS2a/W/AiUKBY9R49IN16t4FgeJ2Mh9ihO0P pD47VxsGnWoG+0cIlkWJ9Bu8SMfvRg== =m7li -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun Jun 21 09:28:31 2020 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E50043A0DC9 for ; Sun, 21 Jun 2020 09:28:28 -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 Jd5gThdVGOyF for ; Sun, 21 Jun 2020 09:28:27 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E79D33A0DC6 for ; Sun, 21 Jun 2020 09:28:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 3F888389B6; Sun, 21 Jun 2020 12:25:47 -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 nho-xZ4qYECw; Sun, 21 Jun 2020 12:25:46 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 892AB389B4; Sun, 21 Jun 2020 12:25:46 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 3F0C760; Sun, 21 Jun 2020 12:28:25 -0400 (EDT) From: Michael Richardson To: Russ Housley , Brian Carpenter , Ben Kaduk , anima@ietf.org In-Reply-To: References: <11428.1592266833@localhost> <20200617024412.GA11992@kduck.mit.edu> <9584c5cd-c68d-ddc3-0704-da672842e359@gmail.com> 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: [Anima] rfc822Name use in Autonomic Control Plane document X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Jun 2020 16:28:29 -0000 --=-=-= Content-Type: text/plain Russ Housley wrote: > One cannot send email to the character string in this specification, so > it should not be carried in the rfc822name. You can send email to that character string if you configure the MX. It was designed specifically to accomodate that. I objected at the time: I thought it was a stupid feature, that no sensible IKEv2 daemon was going to have to send/receive email. But, Toerless was paranoid that if we did anything at all out of the ordinary, that the corporate CA people, in order to protect their fiefdom, would freak out and throw some huge roadblock in the way of deploying the ACP. And, now have an ACME method past WGLC that does certificate validation by SMTP. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl7viqgACgkQgItw+93Q 3WVsxgf/XAnu2P5/hvl6A4Aq4V62GN2NUZ8HqOgsjMPQlkyZC0WgENT7DFpRpY57 bX7qW514970M6ns+fZAdw94wnnQtD/AQDopnaGr7FfCFgypECyknnK/dWR5zAzrp eYYd0HUtA5nnL9Lxj48iGMRRhdRUBO8lLiN3z40FncohQhwyIHR1RnyhdW70OYLo SBocnGDkyy36x9hPSXgJ4NKSv9xPlQWUbuI20GLuSAiclNkpZue9iJTB1xys6UKE gT74K/cfAJNk+jaIYjHgCShBDknwU4nEZrOh9RVQ6zAGFeNVl2Crl56eqIhnG4bf auwoL//c/osFcXcnuJx+bMVmIxOMyg== =AGlq -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun Jun 21 09:36:14 2020 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31F9F3A0DD9 for ; Sun, 21 Jun 2020 09:36:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=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 Ub3lYXVhjQJ4 for ; Sun, 21 Jun 2020 09:36:11 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 990963A0DD8 for ; Sun, 21 Jun 2020 09:36:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id EC05E300B1A for ; Sun, 21 Jun 2020 12:36:08 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id ZPChNyi-SnPE for ; Sun, 21 Jun 2020 12:36:07 -0400 (EDT) Received: from a860b60074bd.fios-router.home (pool-72-66-113-56.washdc.fios.verizon.net [72.66.113.56]) by mail.smeinc.net (Postfix) with ESMTPSA id DB25C300AF9; Sun, 21 Jun 2020 12:36:06 -0400 (EDT) From: Russ Housley Message-Id: <3A92516D-B980-4231-9059-EF7234BA8610@vigilsec.com> Content-Type: multipart/signed; boundary="Apple-Mail=_F9224FF7-7BDB-49AE-8F48-8D28E7616F23"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.14\)) Date: Sun, 21 Jun 2020 12:36:06 -0400 In-Reply-To: <9406.1592756905@localhost> Cc: Brian Carpenter , Ben Kaduk , anima@ietf.org To: Michael Richardson References: <11428.1592266833@localhost> <20200617024412.GA11992@kduck.mit.edu> <9584c5cd-c68d-ddc3-0704-da672842e359@gmail.com> <9406.1592756905@localhost> X-Mailer: Apple Mail (2.3445.104.14) Archived-At: Subject: Re: [Anima] rfc822Name use in Autonomic Control Plane document X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Jun 2020 16:36:13 -0000 --Apple-Mail=_F9224FF7-7BDB-49AE-8F48-8D28E7616F23 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Jun 21, 2020, at 12:28 PM, Michael Richardson = wrote: >=20 >=20 > Russ Housley wrote: >> One cannot send email to the character string in this specification, = so >> it should not be carried in the rfc822name. >=20 > You can send email to that character string if you configure the MX. > It was designed specifically to accomodate that. >=20 > I objected at the time: I thought it was a stupid feature, that no = sensible IKEv2 daemon > was going to have to send/receive email. >=20 > But, Toerless was paranoid that if we did anything at all out of the > ordinary, that the corporate CA people, in order to protect their = fiefdom, > would freak out and throw some huge roadblock in the way of deploying = the ACP. >=20 > And, now have an ACME method past WGLC that does certificate = validation by > SMTP. Looking at the email certificate enrollment work in the ACME WG = (draft-ietf-acme-email-smime-08), I have a hard time seeing how the = device that knows the private key could participate in such a protocol. = How do you see it working? Russ --Apple-Mail=_F9224FF7-7BDB-49AE-8F48-8D28E7616F23 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iF0EARECAB0WIQRJuTEKFXbtfFQz5huK5O7Q9ZwRywUCXu+MdgAKCRCK5O7Q9ZwR y06nAJ9+hhOO9ogSsJI52EOxRZP3QKZBuQCfdsH9kk3XD/X8wsqyzEaM0pc0kTM= =mXXs -----END PGP SIGNATURE----- --Apple-Mail=_F9224FF7-7BDB-49AE-8F48-8D28E7616F23-- From nobody Sun Jun 21 10:17:06 2020 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CF4F3A0769 for ; Sun, 21 Jun 2020 10:17:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=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 AJfR1QHKlt2T for ; Sun, 21 Jun 2020 10:17:03 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 4B1D73A0764 for ; Sun, 21 Jun 2020 10:17:02 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 05LHGvoF024369 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 21 Jun 2020 13:16:59 -0400 Date: Sun, 21 Jun 2020 10:16:56 -0700 From: Benjamin Kaduk To: Michael Richardson Cc: Russ Housley , Brian Carpenter , anima@ietf.org Message-ID: <20200621171656.GQ11992@kduck.mit.edu> References: <11428.1592266833@localhost> <20200617024412.GA11992@kduck.mit.edu> <9584c5cd-c68d-ddc3-0704-da672842e359@gmail.com> <9406.1592756905@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9406.1592756905@localhost> User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [Anima] rfc822Name use in Autonomic Control Plane document X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Jun 2020 17:17:05 -0000 On Sun, Jun 21, 2020 at 12:28:25PM -0400, Michael Richardson wrote: > > Russ Housley wrote: > > One cannot send email to the character string in this specification, so > > it should not be carried in the rfc822name. > > You can send email to that character string if you configure the MX. > It was designed specifically to accomodate that. > > I objected at the time: I thought it was a stupid feature, that no sensible IKEv2 daemon > was going to have to send/receive email. > > But, Toerless was paranoid that if we did anything at all out of the > ordinary, that the corporate CA people, in order to protect their fiefdom, > would freak out and throw some huge roadblock in the way of deploying the ACP. I note that the -24 discusses creating a single mailbox rfcSELF@, which receives mail for *all* ACP identities in the domain, yet we are in other parts of the document claiming that these identities are distinct and in many cases will be granted different authorizations. If these identities are supposed to be equivalent in the "RFC 822" sense, then it seems inconsistent to use the rfc822Name field (which sees them as equivalent) yet treat them as distinct entitites. -Ben From nobody Sun Jun 21 10:36:08 2020 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C015C3A0788 for ; Sun, 21 Jun 2020 10:36:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, 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 (2048-bit key) header.d=rtfm-com.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 vwDtIfCCxF_s for ; Sun, 21 Jun 2020 10:36:03 -0700 (PDT) Received: from mail-lj1-x22e.google.com (mail-lj1-x22e.google.com [IPv6:2a00:1450:4864:20::22e]) (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 3E7913A077D for ; Sun, 21 Jun 2020 10:36:03 -0700 (PDT) Received: by mail-lj1-x22e.google.com with SMTP id n23so16731195ljh.7 for ; Sun, 21 Jun 2020 10:36:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=OAH8k1WPV3b51R8f/uTHnmfk/MC1WyQF9kQeKHlWVXE=; b=E5SaV2ik1BZKw8yMmDSN3dsJygKjOiJ98dPEIDGuAz+7s3mivKA1dklXz1qDb3uilt nI0E8QQwOzbw0ZmvosIYMqvkTY9Lo9EutM3b29YxibFto+3Q8bAbBaGCuFWL+74WN7VR 00ZX3BJtW3bhy4d/Ok+S4YRfpAfSFXxDwsNKUIWw5AuBnGVmU/ilE48z/CVKDTxP78Sh Yy699iqyV4vin9Jrcx2IQbhmGU61XJaeLg2sxcMF8ZsHuPogUUJVZ5LH/onfxh1esVDF Cw51qUC7tZw80RFPESV1IQYxhtWrVXgZ1rCrRnwO6wAZHtu/sn5f9bDwJeQrsIxGbCnt kRYg== 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=OAH8k1WPV3b51R8f/uTHnmfk/MC1WyQF9kQeKHlWVXE=; b=merfTRCqDXEDmY3WA+KRlhie9hFysU786X9/VywwbNe0lgaIHlfIM2YHkrss/ZWvAM jj6Sl1W2bL2tFZ7RV1fh+7DI3RJTtbnNISQ0QZ7WKNfSQTw2S++KBQ6fckq5vWqHnq+x lAtvy7SlKhAB8TCrPk3/bG4g0cWnrhBClPkdXtjLFRz4uAIsVR7+z6MKoee9MVMrRZVP KU4KUvE2bYsC7u614WSCE7Ir3L3Gl34ZX5TBgdZXq9cOzomXdvyYfNNfIOG38Hv3MPyc 7Qz4/cYLmqoo4tl2LhvaP9cUXUBjSQ11+KFkDGkrwtgulnVvRMMJ+TbTIsal1wHC2wv8 DoQQ== X-Gm-Message-State: AOAM530MC1yCkstYdWd/dJPlTapqvvi1ojOh0DjNX1vO6TKH44SksFoQ hoZhmirRyhyh5ftX0uI2IZ+TBr/PdsdbXedcjHcrKQ== X-Google-Smtp-Source: ABdhPJzFk1L7mS+Ix+u+PRdFjslpdhyUClv1zRAKpaVLiLSvcOL8l9gYx4MklqMyPWhVMGfIQpIskhnvE8yH5HUIcAw= X-Received: by 2002:a05:651c:1044:: with SMTP id x4mr6240698ljm.409.1592760961253; Sun, 21 Jun 2020 10:36:01 -0700 (PDT) MIME-Version: 1.0 References: <4280.1592755750@localhost> In-Reply-To: <4280.1592755750@localhost> From: Eric Rescorla Date: Sun, 21 Jun 2020 10:35:25 -0700 Message-ID: To: Michael Richardson Cc: Stephen Kent , Anima WG Content-Type: multipart/alternative; boundary="0000000000004ed69705a89b8fcc" Archived-At: Subject: Re: [Anima] representing ACP info in X.509 certs X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Jun 2020 17:36:06 -0000 --0000000000004ed69705a89b8fcc Content-Type: text/plain; charset="UTF-8" > Eric Rescorla wrote: > > One thing that's not clear to me: is the expectation that you will be > > using a public CA or that you will be using an enterprise-level one? > > There are different many use cases, and it is precisely because we can't be > prescriptive about the operation of the CA involved that the WG compromised > on a solution that we know can be deployed today. > I wasn't happy with the result, but I realized that I could live with the > compromise result. The WG did consider all the points that you have raised. Well, strictly speaking, I believe it was others who raised the points; however, I do concur with them. In any cases, as Ben notes, this decision cannot be made by this WG alone. > 1) a private-CA internal to the ACP Registar. > > 2) an enterprise private-CA external to the ACP Registrar, which is embedded > in another system, such as ActiveDirectory I am not particularly expert on private CAs, though I see that Sean made some notes on what could be done with that software. > 3) when we started this work, it was possible to have (a) and (b) with > anchors toward public CAs ... > 5) a small (or growing) enterprise entity that uses ACME to a public CA. > The is no "group" policy to deploy a private CA, and there is a strong > desire that the devices that are enrolled do not train users to think > security exceptions are "normal". > Obviously, the DN presented to a browser is not a rfc822Name, > but would have to be an dnsName. The ACP rfc822Name > may not be the only SAN in the certificate, but it is one that > draft-ietf-acme-email-smime-08 allow the Registrar to validate. I'm assuming that by "public CA" we are talking about a CA which issues certificates which are acceptable to browsers or other generic clients. On that topic, I would make a few points: 1. It is not impossible to get CAs to issue certificates with custom extensions. For instance, DigiCert issues certificates with the Delegated Credentials extension: https://engineering.fb.com/security/delegated-credentials/ It's of course possible that otherName would be different. 2. I believe the Mozilla Root Store Policy [0] would require a CA to revoke certificates used as described in this specification. See Section 6.2 (S/MIME Certificates) [1]: For any certificate in a hierarchy capable of being used for S/MIME, CAs MUST revoke certificates upon the occurrence of any of the following events: ... 3. the CA obtains reasonable evidence that the certificate has been used for a purpose outside of that indicated in the certificate or in the CA's subscriber agreement; I imagine that other root programs have similar restrictions. Of course this wouldn't preclude a CA that wasn't subject to these restrictions issuing ACP certificates. -Ekr [0] https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/ [1] There are a number of other clauses which I believe would also apply, but I believe this is the most on-point. --0000000000004ed69705a89b8fcc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> Eric Rescorla <ekr@rtfm.com> wrote:
> =C2=A0 =C2=A0 > One t= hing that's not clear to me: is the expectation that you will be
>= ; =C2=A0 =C2=A0 > using a public CA or that you will be using an enterpr= ise-level one?
>
> There are different many use cases, and it = is precisely because we can't be
> prescriptive about the operati= on of the CA involved that the WG compromised
> on a solution that we= know can be deployed today.
> I wasn't happy with the result, bu= t I realized that I could live with the
> compromise result.=C2=A0 Th= e WG did consider all the points that you have raised.

Well, strictl= y speaking, I believe it was others who raised the points;
however, I do= concur with them. In any cases, as Ben notes, this decision
cannot be m= ade by this WG alone.


> 1) a private-CA internal to the ACP R= egistar.
>
> 2) an enterprise private-CA external to the ACP R= egistrar, which is embedded
> =C2=A0 =C2=A0in another system, such as= ActiveDirectory

I am not particularly expert on private CAs, though= I see that
Sean made some notes on what could be done with that softwar= e.


> 3) when we started this work, it was possible to have (a= ) and (b) with
> =C2=A0 =C2=A0anchors toward public CAs
...
> 5) a small (or growing) enterprise entity that uses ACME to a public = CA.
> =C2=A0 =C2=A0The is no "group" policy to deploy a pri= vate CA, and there is a strong
> =C2=A0 =C2=A0desire that the devices= that are enrolled do not train users to think
> =C2=A0 =C2=A0securit= y exceptions are "normal".
> =C2=A0 =C2=A0Obviously, the DN= presented to a browser is not a rfc822Name,
> =C2=A0 =C2=A0but would= have to be an dnsName.=C2=A0 The ACP rfc822Name
> =C2=A0 =C2=A0may n= ot be the only SAN in the certificate, but it is one that
> =C2=A0 = =C2=A0draft-ietf-acme-email-smime-08 allow the Registrar to validate.
I'm assuming that by "public CA" we are talking about a CA = which
issues certificates which are acceptable to browsers or other gene= ric
clients. On that topic, I would make a few points:

1. It is n= ot impossible to get CAs to issue certificates with custom
extensions. F= or instance, DigiCert issues certificates with the
Delegated Credentials= extension:

=C2=A0 =C2=A0https://engineering.fb.com/se= curity/delegated-credentials/
=C2=A0 =C2=A0
It's of course po= ssible that otherName would be different.


2. I believe the Mozil= la Root Store Policy [0] would require a CA to
revoke certificates used = as described in this specification. See
Section 6.2 (S/MIME Certificates= ) [1]:

=C2=A0 =C2=A0For any certificate in a hierarchy capable of be= ing used for
=C2=A0 =C2=A0S/MIME, CAs MUST revoke certificates upon the = occurrence of any of
=C2=A0 =C2=A0the following events:

=C2=A0 = =C2=A0...

=C2=A0 =C2=A03. the CA obtains reasonable evidence that th= e certificate has been
=C2=A0 =C2=A0used for a purpose outside of that i= ndicated in the certificate or
=C2=A0 =C2=A0in the CA's subscriber a= greement;

I imagine that other root programs have si= milar restrictions.
Of course this wouldn't preclude a CA that= wasn't subject to these
restrictions issuing ACP certificates.
<= br>-Ekr



[0] https://= www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy= /
[1] There are a number of other clauses which I believe would also= apply,
but I believe this is the most on-point.
--0000000000004ed69705a89b8fcc-- From nobody Sun Jun 21 17:59:33 2020 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E73B3A083B; Sun, 21 Jun 2020 17:59:32 -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 cVvNP8djoHPq; Sun, 21 Jun 2020 17:59:30 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E5383A0828; Sun, 21 Jun 2020 17:59:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 16F78389BC; Sun, 21 Jun 2020 20:56:49 -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 11pahaUK74xX; Sun, 21 Jun 2020 20:56:47 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id C88D2389BA; Sun, 21 Jun 2020 20:56:47 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id C94AB60; Sun, 21 Jun 2020 20:59:26 -0400 (EDT) From: Michael Richardson To: Sheng Jiang , Anima WG , "anima-chairs\@ietf.org" , "Rob Wilton \(rwilton\)" 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: [Anima] Adoption call for draft-fries-anima-brski-async-enroll-03, ends July 1st 2020 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jun 2020 00:59:32 -0000 --=-=-= Content-Type: text/plain I have read draft-fries-anima-brski-async-enroll-03 and I would be happy to have it as the basis for an extension. PLEASE ADOPT. --- While I think that section 4 is very well fleshed out, I think that section 5 will need revisions. While it attempts to mirror the structure of the BRSKI document, I think that probably is both unnecessary, and also too verbose. I think that use of EST is probably wrong: more choices here is not better. CMP is the right protocol, because there will not be a consistent transport to secure. I am not sure how to integrate RFC8366 vouchers into CMP. I believe that this work needs focus on the lightweight CMP profile. I don't know CMP well enough to comment on how to do this yet. Since we are dealing with signed objects, I wonder if COSE/CoID objects would not be better signed containers. That's clearly *not* bits-on-the-wire CMP, but if it's 1:1 with CMP objects, then it may be easier to integrated into existing CMP infrastructure. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl7wAm4ACgkQgItw+93Q 3WUb0gf9GgVcQpf3+RmLIHLLvUFisRxxoMbN+ixlgBYz5SR5Wlzr8r/mw0as/H/3 JzuziuVCIV570tW4qjjSyX7Cl8DkJveeWLUlHxSnwvmiR/za3mjtS0jPfR1tOjaL O6Y5BeDVs37DBEqP8SPHwcHs+l574yqXwlPvNnI9M7n0Pxjq2M/HKJcNFge7vXHT qW1St9rbLzE8yXwdyePlvOziYgxBa/+Xi+aWXW20ZUE14GSwUcc7xWmZQsBK3fWp qOEqcmeZJ6lX5rUhQnllgnOvo+ZE50WpzFvojqC0UZletsDEEgslRJ9AFpSVztVE vFMxYGWQ0kv4jjDbLWmdddSjKZS59g== =fHqA -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Jun 22 01:41:49 2020 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 392813A0BAD; Mon, 22 Jun 2020 01:41:47 -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, RCVD_IN_MSPIKE_H2=-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 bHCUYvqZRlrT; Mon, 22 Jun 2020 01:41:46 -0700 (PDT) Received: from gw-eagle1.siemens.com (gw-eagle1.siemens.com [194.138.20.72]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2AC53A0BA9; Mon, 22 Jun 2020 01:41:45 -0700 (PDT) Received: from mail1.dc4ca.siemens.de (mail1.dc4ca.siemens.de [139.25.224.78]) by gw-eagle1.siemens.com (Postfix) with ESMTPS id A14D44F003E; Mon, 22 Jun 2020 10:41:42 +0200 (CEST) Received: from DEMCHDC89YA.ad011.siemens.net (demchdc89ya.ad011.siemens.net [139.25.226.104]) by mail1.dc4ca.siemens.de (Postfix) with ESMTPS id 1092315522179; Mon, 22 Jun 2020 10:41:41 +0200 (CEST) Received: from DEMCHDC8A1A.ad011.siemens.net (139.25.226.107) by DEMCHDC89YA.ad011.siemens.net (139.25.226.104) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1979.3; Mon, 22 Jun 2020 10:41:41 +0200 Received: from DEMCHDC8A1A.ad011.siemens.net ([139.25.226.107]) by DEMCHDC8A1A.ad011.siemens.net ([139.25.226.107]) with mapi id 15.01.1979.003; Mon, 22 Jun 2020 10:41:41 +0200 From: "Fries, Steffen" To: Michael Richardson CC: Sheng Jiang , Anima WG , "anima-chairs@ietf.org" , "Rob Wilton (rwilton)" Thread-Topic: [Anima] Adoption call for draft-fries-anima-brski-async-enroll-03, ends July 1st 2020 Thread-Index: AQHWSDBtaclimbANOkiK+Y6kXbVaTajkH8nQ Date: Mon, 22 Jun 2020 08:41:41 +0000 Message-ID: <9641bc176f334dec818c0105e64d4a39@siemens.com> References: <8922.1592787566@localhost> In-Reply-To: <8922.1592787566@localhost> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [144.145.220.65] x-tm-snts-smtp: EE15CAB3470FEF24060FF60D628F3A6AE0CC542A71683FA3BBC1EC75FD070F2D2000:8 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Anima] Adoption call for draft-fries-anima-brski-async-enroll-03, ends July 1st 2020 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jun 2020 08:41:47 -0000 Hi Michael > -----Original Message----- > From: Anima On Behalf Of Michael Richardson > Sent: Montag, 22. Juni 2020 02:59>=20 > I have read draft-fries-anima-brski-async-enroll-03 and I would be happy = to > have it as the basis for an extension. PLEASE ADOPT. Thanks for the support. > --- >=20 > While I think that section 4 is very well fleshed out, I think that secti= on 5 will > need revisions. While it attempts to mirror the structure of the BRSKI > document, I think that probably is both unnecessary, and also too verbose= . I'm currently about to update that section as well as section 6 to remove a= ny duplication of BRSKI approaches already described and kept unchanged. > I think that use of EST is probably wrong: more choices here is not bette= r. > CMP is the right protocol, because there will not be a consistent transpo= rt to > secure. I am not sure how to integrate RFC8366 vouchers into CMP. We strive for a protocol agnostic approach, which allows to use existing en= rollment protocols. As EST also supports signed objects with fullcmc it can= be used as well. It would most likely require to enhance EST to specify ho= w fullcmc is supported, which may go into a similar direction as the lightw= eight CMC.=20 Also, in BRSKI we did not change the defined voucher exchange to be carried= out with other enrollment protocols. We have not seen this as integral par= t of EST. At least for CMP it would be possible to transmit the voucher as = part of a general message. But we tried to leave as much as possible from t= he original approach to keep the registrar enhancements focused on the enro= llment only.=20 > I believe that this work needs focus on the lightweight CMP profile. > I don't know CMP well enough to comment on how to do this yet. We currently have a usage mapping to lightweight CMP and EST included in se= ction 7. > Since we are dealing with signed objects, I wonder if COSE/CoID objects > would not be better signed containers. That's clearly *not* bits-on-the-= wire > CMP, but if it's 1:1 with CMP objects, then it may be easier to integrate= d into > existing CMP infrastructure. Good point. While we are currently focusing on being protocol agnostic, obj= ect agnostic came into the game as well. In the next update we also support= a discovery mechanism for supported enrollment protocols on the registrar,= which should also allow to transport the information about the different e= ncodings supported by the registrar as context type.=20 Best regards Steffen >=20 > -- > Michael Richardson , Sandelman Software Works > -=3D IPv6 IoT consulting =3D- From nobody Mon Jun 22 01:56:53 2020 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C71C53A0BB3; Mon, 22 Jun 2020 01:56:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.6 X-Spam-Level: X-Spam-Status: No, score=-9.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 kNLQbqkJzbGk; Mon, 22 Jun 2020 01:56:49 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09A773A0BB1; Mon, 22 Jun 2020 01:56:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14477; q=dns/txt; s=iport; t=1592816209; x=1594025809; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=YOEgpNxccrWB49i1/XxeuCbH/2B8l3/nP3w7HidYEPk=; b=OMdnT6nBId7odp9C01Ph8n2AEEEGY9XrKZWDzRJzNrJ8wn+9QzPNoLJG w1Qd+LABOsLPsCUWW2zPX2/JsZzvILdHVIZYMF4mZ8j8TgFI6Z/azmf64 kEJ+WqHfuqWl5PzXwmS7hmF9OThhvBY4uW5dyaj2nuvSOjjQCu+b0sqP1 U=; X-IronPort-AV: E=Sophos; i="5.75,266,1589241600"; d="scan'208,217"; a="27272372" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 22 Jun 2020 08:56:47 +0000 Received: from dhcp-10-61-111-166.cisco.com (dhcp-10-61-111-166.cisco.com [10.61.111.166]) by aer-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id 05M8ujkL007674 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 22 Jun 2020 08:56:46 GMT From: Eliot Lear Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_6789A2C3-EFFA-4DB0-9DBE-3C3747F4089C" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Mon, 22 Jun 2020 10:56:45 +0200 In-Reply-To: Cc: Anima WG , "anima-chairs@ietf.org" , "Rob Wilton (rwilton)" To: Sheng Jiang References: X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Outbound-SMTP-Client: 10.61.111.166, dhcp-10-61-111-166.cisco.com X-Outbound-Node: aer-core-2.cisco.com Archived-At: Subject: Re: [Anima] Adoption call for draft-fries-anima-brski-async-enroll-03, ends July 1st 2020 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jun 2020 08:56:52 -0000 --Apple-Mail=_6789A2C3-EFFA-4DB0-9DBE-3C3747F4089C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Sheng Thanks for initiating this call. As one of the co-authors, it should = surprise you not at all the I have read it, and indeed have modestly = contributed to it (Steffen did the heavy lifting). I support its = adoption. Eliot > On 18 Jun 2020, at 11:27, Sheng Jiang wrote: >=20 > Hi, ANIMAer, > =20 > This message starts a two-week adoption call, it ends on July 1st, = 2020. > =20 > draft-fries-anima-brski-async-enroll-03 has been presented to the WG = for a long while and the WG showed good interest and had discussions. = The draft is now clearly in scope of ANIMA charter 2 that was adopted = around IETF106. The authors asked for adoption of the document. Giving = the dependent BRSKI has passed the IESG evaluation, the chairs feel that = it may be the right time to call the adoption. > =20 > We therefore are asking the ANIMA working group for adoption of the = following work: > =20 > Title: Support of asynchronous Enrollment in BRSKI > Name: draft-fries-anima-brski-async-enroll-03 > Authors: S. Fries, H. Brockhaus and E. Lear > URL: = https://datatracker.ietf.org/doc/draft-fries-anima-brski-async-enroll/ = > =20 > This document is intended to become a standards track ANIMA WG = document. > =20 > Please express your support or rejection. If you think this document = should _not_ be adopted, please also explicitly indicate the reasons. > =20 > Regards, > =20 > Sheng > =20 > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima = --Apple-Mail=_6789A2C3-EFFA-4DB0-9DBE-3C3747F4089C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi = Sheng

Thanks for = initiating this call.  As one of the co-authors, it should surprise = you not at all the I have read it, and indeed have modestly contributed = to it (Steffen did the heavy lifting).  I support its = adoption.

Eliot

On 18 Jun 2020, at 11:27, Sheng = Jiang <jiangsheng@huawei.com> wrote:

Hi, = ANIMAer,
 
This =
message starts a two-week adoption call, it ends on July 1st, 2020.
 
draft-fries-anima-brski-async-enroll-03 has been presented to =
the WG for a long while and the WG showed good interest and had =
discussions. The draft is now clearly in scope of ANIMA charter 2 that =
was adopted around IETF106. The authors asked for adoption of the =
document. Giving the dependent BRSKI has passed the IESG evaluation, the =
chairs feel that it may be the right time to call the adoption.
 
We =
therefore are asking the ANIMA working group for adoption of the =
following work:
 
Title:    Support of asynchronous Enrollment =
in BRSKI
Name:     =
draft-fries-anima-brski-async-enroll-03
Authors:  S. Fries, =
H. Brockhaus and E. Lear
URL:      https://datatracker.ietf.org/doc/draft-fries-anima-brski-async-=
enroll/
 
This =
document is intended to become a standards track ANIMA WG document.
 
Please =
express your support or rejection. If you think this document should =
_not_ be adopted, please also explicitly indicate the reasons.
 
Regards,
 
Sheng
 
_______________________________________________
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

= --Apple-Mail=_6789A2C3-EFFA-4DB0-9DBE-3C3747F4089C-- From nobody Mon Jun 22 03:43:10 2020 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91D993A0BEF for ; Mon, 22 Jun 2020 03:43:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.597 X-Spam-Level: X-Spam-Status: No, score=-9.597 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_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=E4DIF2W3; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=EFYQXQKf 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 YSYa1T9v_GK4 for ; Mon, 22 Jun 2020 03:43:07 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3BBC3A091B for ; Mon, 22 Jun 2020 03:43:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12891; q=dns/txt; s=iport; t=1592822587; x=1594032187; h=from:to:cc:subject:date:message-id:mime-version; bh=cN6udH2cMmkFFgx4PJzpZZPONN5dyjmZRqFiDQ3t6Ko=; b=E4DIF2W3jzCuWER9tMOY52eoIUnK8jrBDNowvaNsD/Nl0NqEL+3X+PJg mmUTvYaJq95TAS+sDMc0fJskuoYVX/vbiAHI0ROmdWTxI+RXk2dRLWGiJ E2HxCLSaFkQd/epOf2S4mRadezy73fFWXarvN7EkiDPUiufVPV36O/Ya6 s=; IronPort-PHdr: =?us-ascii?q?9a23=3ApsJRFBwAJ745KoHXCy+N+z0EezQntrPoPwUc9p?= =?us-ascii?q?sgjfdUf7+++4j5ZRWFt/RgkFGPWp/UuLpIiOvT5qbnX2FIoZOMq2sLf5EEUR?= =?us-ascii?q?gZwd4XkAotDI/gawX7IffmYjZ8EJFEU1lorHC2LUYTH9zxNBXep3So5msUHR?= =?us-ascii?q?PyfQN+OuXyHNvUiMK6n+C/8pHeeUNGnj24NLhzNx6x6w7Ws5ob?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AHCAAeivBe/5pdJa1mHgEBCxIMgX8?= =?us-ascii?q?LgSMvUQdvWC8shCSDRgONH5QRhGiBLoEkA1ULAQEBDAEBLQIEAQGERxmCEgI?= =?us-ascii?q?kNgcOAgMBAQsBAQUBAQECAQYEbYVbDIV1FhEdAQE3AREBSgIEMCcEDhkOgwQ?= =?us-ascii?q?BgX5NAy4BqzcCgTmIYXaBMoMBAQEFhR8Ygg4JgTiCZ4l8GoFBP4ERJwwQilw?= =?us-ascii?q?zgi2RbAE8hjqbdAqCWgSOYYpEAx2ee69zAgQCBAUCDgEBBYFZATKBVnAVZQG?= =?us-ascii?q?CPlAXAg2OHgwXg06KVnQ3AgYBBwEBAwl8kDoBAQ?= X-IronPort-AV: E=Sophos;i="5.75,266,1589241600"; d="scan'208,217";a="500580792" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 22 Jun 2020 10:43:06 +0000 Received: from XCH-RCD-004.cisco.com (xch-rcd-004.cisco.com [173.37.102.14]) by rcdn-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id 05MAh2TS018393 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 22 Jun 2020 10:43:05 GMT Received: from xhs-rtp-002.cisco.com (64.101.210.229) by XCH-RCD-004.cisco.com (173.37.102.14) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 22 Jun 2020 05:43:02 -0500 Received: from xhs-aln-001.cisco.com (173.37.135.118) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 22 Jun 2020 06:43:01 -0400 Received: from NAM10-MW2-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Mon, 22 Jun 2020 05:43:01 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=lFMhBJJDZZFuyDct6EA2OS1mg0EGOxoe4EloRSnZFV+8rgqkrv7TQnmgjuX0plKzv/uNXtdvZFxfiqx/2/JMW/Z58L5YI7b8F7Kq/JZTUB4c5WYZIZmMMJ3INrxqeRIApLVDo9HUzOhjUnlZcrGKMP1onrCPvu8IsljkxZft+Ayn/fdr3F+MgPXNkR7nHl8XnpOP4753A5E2NvuOlD+RGTY/ULazWX63Rgz6CG1lXD93ikJ2sPXCoQREOuBnn0MbnomR3usD+tuGlJpvZp1ReJn5VuAn5gZ46bzMgfHRSDkc+EFjk0n20p6yy/mu8oJHmvXb5JPVYgB/8w4aZFRd2g== 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=cN6udH2cMmkFFgx4PJzpZZPONN5dyjmZRqFiDQ3t6Ko=; b=fWBRZjVca2zKj1ynJpoUA+Zp+34UodKhHazgzw9Q1OI0nHi9IT7iIaOZ0w4KN3RMghMwoSCR8prYC8ydRmDiJOcMsaFtofqWSD53pCRKihtrF6y+hPeW5u4d0kky5gKDyosNr+1ALn5TvCy6Jt5t0GoWcNbdK6SUqqV2okS7FnHHHzBNaNPh47U0+/FgzWXIYfQsCq30Lp1N3JiONOTRWAnT0tJuQiR02qzQP9Z60TDwJu7wcOolltSY6aGVFMR0IsGbQ0i4UliDKAgUzZUA8iWra6wKpSPdLPF386Vgjoga8I9mxP2UvvWTazOaAjwTSbWCMnvxPcq6qLVz5XjGdQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=cN6udH2cMmkFFgx4PJzpZZPONN5dyjmZRqFiDQ3t6Ko=; b=EFYQXQKfZpWRIz5BI9I7zcW9iR7o747TT24DhIuHWCBqEsP5LNLBN5lUu9imNcYusKlCkuhUHs7iVa/J59bfR5R3U7ro8N62GJ5f3g7SJFUEMkQCb7kWAC3J2d8MBSzoHw1N50c5lcDVcFEoYx+gZGNKASmdwUX5l8XHJ2TGVf8= Received: from DM5PR11MB1753.namprd11.prod.outlook.com (2603:10b6:3:10d::13) by DM5PR11MB1819.namprd11.prod.outlook.com (2603:10b6:3:10a::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3109.21; Mon, 22 Jun 2020 10:43:00 +0000 Received: from DM5PR11MB1753.namprd11.prod.outlook.com ([fe80::a14c:59b6:47b0:f630]) by DM5PR11MB1753.namprd11.prod.outlook.com ([fe80::a14c:59b6:47b0:f630%7]) with mapi id 15.20.3109.027; Mon, 22 Jun 2020 10:43:00 +0000 From: "Eric Vyncke (evyncke)" To: Anima WG CC: Stephen Kent , Benjamin Kaduk , Eric Rescorla , "tte+ietf@cs.fau.de" , "sbjarnason@arbor.net" , "Michael.H.Behringer@gmail.com" , "warren@kumari.net" , "jiangsheng@huawei.com" , "Joel M. Halpern" Thread-Topic: Moving forward with draft-ietf-anima-autonomic-control-plane Thread-Index: AQHWSIHmHX8R92wb0UK+1UkyU08n7Q== Date: Mon, 22 Jun 2020 10:43:00 +0000 Message-ID: <1C60B01B-3258-4F93-A782-2B2940CAAC49@cisco.com> Accept-Language: fr-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.38.20061401 authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=cisco.com; x-originating-ip: [2001:420:c0c1:36:143e:7544:52c6:7384] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 8a573d4f-cb5f-4ca0-c7fa-08d8169908d8 x-ms-traffictypediagnostic: DM5PR11MB1819: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0442E569BC x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 3rCkBlKveeFTklqsWgeFsNuNIQ1OnPLT0Rd0YR7tYA/PUGQDvC1+CRDPOOcl75/kYXJOco6L/SCIGR4XRVn97yPoyb541tfoF/h8H/Mnv7KeCVWh9jZ4cN3HKy1MLQWXZqeQMrFnkb3k5JY1CYZVTrJgeDJnOVHQbPrKL6wAF5Sx9355TfI7yVfSHsTZJmDN7ujhwJ+BizVWxruv6GcL8B2Pn0+lW5NfjZHwcYcx5ZR0hXvUCkAflKr09Wkg4GlxxwZRkBHEb99FiFI4lRN5QyZjFfuQf35dBjhRn6sbtnorTX2a8G9ngQZcncLB6C83yN6WHpihI/XDM/2ryxM+uQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM5PR11MB1753.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(366004)(39860400002)(396003)(346002)(376002)(136003)(66946007)(6506007)(91956017)(76116006)(5660300002)(478600001)(4326008)(71200400001)(6916009)(33656002)(2616005)(66446008)(66476007)(86362001)(64756008)(66556008)(8936002)(36756003)(8676002)(7416002)(6486002)(83380400001)(54906003)(6512007)(316002)(186003)(2906002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: 9ITc8alX5gG97o7/LvVqxkZmBgxXo1rXSpKJHQxHBu0EEcpfWeBGhm2FioJJHVo2wbAbR9TjIrl2fkCK1QnHeMOhhU1JuftkzWG4ctGs8G+X0sz0p1CcvZpyOEGoLYQTrNmrowQXiI+6q6/oZBInBEo7t/KV/U4soKCjKGcs+OmkgSWmepI4Bf+1qEcc0g/Tl0c1OzXXKo6nQAJOtTk34ezK87kfaAsfxZ+WdRPTjQ64LhYo8Dce+s17Yhu/IFPxB4co55GT8WBmAzHCx7B/mu8E+cjzkSUHTezySFXHzlNR5eTFd0lafkFr7ViE9rUB4zc+JGb2Rncp2qWWZCHIaipXjfGw1hlTAYs1bIFuy3UpDpnLYgBg7Sm90De1sV0CJMmpjcQk3NqaO9T6BeBL6+2G4cITMBnjOrGgRPJAzWWdKC0iQdVa81wUFZrpwRT614SH59ABlrQ/bgLh3rqC1ElIC+1OvRhD/mO8iA5Zyr5kZRFKy5B+kkTCcKeW7b+2uqb/ObHF4s0Z8mIq7aSNT2JomjBeukSU78DwYA3v6B4= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_1C60B01B32584F93A7822B2940CAAC49ciscocom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 8a573d4f-cb5f-4ca0-c7fa-08d8169908d8 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Jun 2020 10:43:00.5847 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: ONMdGCqlS8fpCo0zLgHy5w+wBR5vgWbGcNW5UXrOyumSK3IDtMPXf8fa7y2OCS3f9gi99c3ozBDtNNnMFv5nEA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR11MB1819 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.14, xch-rcd-004.cisco.com X-Outbound-Node: rcdn-core-3.cisco.com Archived-At: Subject: [Anima] Moving forward with draft-ietf-anima-autonomic-control-plane X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jun 2020 10:43:10 -0000 --_000_1C60B01B32584F93A7822B2940CAAC49ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QXMgdGhlIHNoZXBoZXJkaW5nIEFEIGZvciB0aGlzIGRvY3VtZW50LCBJIGFtIGhhcHB5IHRvIHNl ZSByZWNlbnQgdGVjaG5pY2FsIGRpc2N1c3Npb25zIG9uIHRoaXMgZG9jdW1lbnQuIE9UT0gsIEkg ZG8gbm90IG9ic2VydmUgYW55IGNvbnZlcmdlbmNlIHRvIHJlbW92ZSB0aGUgcGVuZGluZyBESVND VVNTLg0KDQoNCg0KVGhlIDJuZCBJRVRGIExhc3QgQ2FsbCB3YXMgY29tcGxldGVkIDIgbW9udGhz IGFnbyBpbiBBcHJpbCAyMDIwLiBKb2VsIEhhbHBlcm4gZGlkIHRoZSByZXZpZXcgZm9yIHJvdXRp bmcgZGlyZWN0b3JhdGUgYW5kIGZvdW5kIGEgY291cGxlIG9mIGlzc3VlcyAoem9uZS1JRCwgbG9v cGJhY2sgZGVmaW5pdGlvbikgYW5kIGl0IHNlZW1zIHRoYXQgdGhlcmUgaXMgbm93IGFuIGFncmVl bWVudCB3aXRoaW4gdGhlIGNvbW11bml0eSBmb3IgdXBkYXRlZCB0aGUgdGV4dC4NCg0KDQoNCklu IG9yZGVyIHRvIHByb2dyZXNzIHRoZSBkb2N1bWVudCwgYSByZXZpc2VkIEktRCBpcyBuZWVkZWQg dG8gZml4IEJlbuKAmXMgRElTQ1VTUyBwb2ludHM6DQoNCi0gVXNlIG9mIHJmYzgyMk5hbWUgcmF0 aGVyIHRoYW4gb3RoZXJOYW1lOiB0aGUg4oCYZWFzeeKAmSBmaXggaXMgaW5kZWVkIHRvIHVzZSBv dGhlck5hbWUgKGV2ZW4gd2l0aCB0aGUgc2VjdGlvbiA2LjEuMiBqdXN0aWZpY2F0aW9ucykNCg0K LSDigJxNVEkgY3J5cHRvZ3JhcGhpYyBtZWNoYW5pc21zIGFyZSB1bmRlci1zcGVjaWZpZWTigJ0g dGhhdCBzaG91bGQgbm90IGJlIGNvbnRyb3ZlcnNpYWwgYW5kIGVhc3kgdG8gZml4DQoNCi0gQ2xh cmlmaWNhdGlvbiBhYm91dCB0aGUgUlBMIHJvb3QNCg0KDQoNClVuc3VyZSB3aGV0aGVyIEVyaWMg UmVzY29sYeKAmXMgRElTQ1VTUyBhcmUgc3RpbGwgYXBwbGljYWJsZSAoYXMgdGhleSB3ZXJlIG9u IC0xNik7IGJ1dCwgdGhpcyB3b3VsZCBiZSBhIHBsdXMgdG8gZml4IHRoZXNlIHBvaW50cy4NCg0K DQoNCkkgdW5kZXJzdGFuZCB0aGF0IHRoZSBhdXRob3JzIGhhdmUgd29ya2VkIG9uIHRoaXMgZm9y IDYgeWVhcnMgYW5kIG1heSBiZSBib3JlZCBidXQgSSB3b3VsZCBsb3ZlIHRvIHNlZSB0aGlzIEkt RCBnb2luZyBmb3J3YXJkLiBBZ2FpbiwgYXMgbWFueSBvdGhlcnMgSSBmYWlsIHRvIHNlZSB0aGUg cmVhc29uIG9mIHVzaW5nIHJmYzgyMk5hbWUgYW5kIHRoZSBmaXggd291bGQgYmUgdG8gdXNlIG90 aGVyTmFtZS4NCg0KDQoNCk1heSBJIGFsc28gc3VnZ2VzdCB0byB0aGUgYXV0aG9ycyB0byBhZGQg bmV3IGNvLWF1dGhvcnMgaW4gb3JkZXIgdG8gaGF2ZSDigJhmcmVzaCBibG9vZOKAmSBhbmQgZW5l cmd5ID8NCg0KDQoNClJlZ2FyZHMNCg0KDQoNCi3DqXJpYw0KDQoNCg0KDQoNCg0K --_000_1C60B01B32584F93A7822B2940CAAC49ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <65B4D6CFE41B2A42AB65FA5C367822B8@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAg MDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0x OjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25z ICovDQpwLk1zb1BsYWluVGV4dCwgbGkuTXNvUGxhaW5UZXh0LCBkaXYuTXNvUGxhaW5UZXh0DQoJ e21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiUGxhaW4gVGV4dCBDaGFy IjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEu MHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHls ZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5QbGFpblRleHRDaGFyDQoJe21z by1zdHlsZS1uYW1lOiJQbGFpbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgltc28tc3R5bGUtbGluazoiUGxhaW4gVGV4dCI7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNh bnMtc2VyaWY7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7 fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3 Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldv cmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlz dC1pZDozNDA4MTIzNzc7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxh dGUtaWRzOjEyMjQ1MDMxNjYgMTkyNzQ2NDY2NiA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2 NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5Mzt9DQpAbGlzdCBsMDps ZXZlbDENCgl7bXNvLWxldmVsLXN0YXJ0LWF0OjA7DQoJbXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Oi07DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJ Zm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1p bHk6Q2FsaWJyaTt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJ Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw0 DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0 IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseToiQ291cmll ciBOZXciO30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZv bnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LTE4LjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZl bC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6 bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2Rpbmdz O30NCkBsaXN0IGwxDQoJe21zby1saXN0LWlkOjEyNTY1OTY4MzI7DQoJbXNvLWxpc3QtdHlwZTpo eWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjI5NDA0MDExMCAyNjUwNjI5MjggNjc2OTg2 OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEg Njc2OTg2OTM7fQ0KQGxpc3QgbDE6bGV2ZWwxDQoJe21zby1sZXZlbC1zdGFydC1hdDowOw0KCW1z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDotOw0KCW1zby1s ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0K CW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OkNhbGlicmk7fQ0KQGxpc3QgbDE6bGV2ZWwyDQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1s ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3Qg bDE6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2Rp bmdzO30NCkBsaXN0IGwxOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQt ZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7 DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMTpsZXZlbDYNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDE6bGV2 ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv grc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBs aXN0IGwxOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseToiQ291 cmllciBOZXciO30NCkBsaXN0IGwxOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0K CWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBjbTt9DQp1bA0K CXttYXJnaW4tYm90dG9tOjBjbTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0i ZW4tQkUiIGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0RjcyIj4NCjxkaXYgY2xhc3M9IldvcmRT ZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5BcyB0aGUgc2hlcGhlcmRpbmcgQUQg Zm9yIHRoaXMgZG9jdW1lbnQsIEkgYW0gaGFwcHkgdG8gc2VlIHJlY2VudCB0ZWNobmljYWwgZGlz Y3Vzc2lvbnMgb24gdGhpcyBkb2N1bWVudC4gT1RPSCwgSSBkbyBub3Qgb2JzZXJ2ZSBhbnkgY29u dmVyZ2VuY2UgdG8gcmVtb3ZlIHRoZSBwZW5kaW5nIERJU0NVU1MuPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPlRoZSAybmQgSUVURiBMYXN0IENhbGwgd2FzIGNvbXBsZXRlZCAyIG1vbnRo cyBhZ28gaW4gQXByaWwgMjAyMC4gSm9lbCBIYWxwZXJuIGRpZCB0aGUgcmV2aWV3IGZvciByb3V0 aW5nIGRpcmVjdG9yYXRlIGFuZCBmb3VuZCBhIGNvdXBsZSBvZiBpc3N1ZXMgKHpvbmUtSUQsIGxv b3BiYWNrIGRlZmluaXRpb24pIGFuZCBpdCBzZWVtcyB0aGF0IHRoZXJlIGlzIG5vdyBhbiBhZ3Jl ZW1lbnQgd2l0aGluIHRoZSBjb21tdW5pdHkNCiBmb3IgdXBkYXRlZCB0aGUgdGV4dC48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+SW4gb3JkZXIgdG8gcHJvZ3Jlc3MgdGhlIGRvY3VtZW50 LCBhIHJldmlzZWQgSS1EIGlzIG5lZWRlZCB0byBmaXggQmVu4oCZcyBESVNDVVNTIHBvaW50czo8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPi0gVXNlIG9mIHJmYzgyMk5h bWUgcmF0aGVyIHRoYW4gb3RoZXJOYW1lOiB0aGUg4oCYZWFzeeKAmSBmaXggaXMgaW5kZWVkIHRv IHVzZSBvdGhlck5hbWUNCjxzcGFuIGxhbmc9IkVOLVVTIj4oZXZlbiB3aXRoIHRoZSBzZWN0aW9u IDYuMS4yIGp1c3RpZmljYXRpb25zKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPi0g4oCcTVRJIGNyeXB0b2dyYXBoaWMgbWVjaGFuaXNtcyBhcmUgdW5kZXIt c3BlY2lmaWVk4oCdIHRoYXQgc2hvdWxkIG5vdCBiZSBjb250cm92ZXJzaWFsIGFuZCBlYXN5IHRv IGZpeDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+LSBDbGFyaWZpY2F0 aW9uIGFib3V0IHRoZSBSUEwgcm9vdDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5VbnN1 cmUgd2hldGhlciBFcmljIFJlc2NvbGHigJlzIERJU0NVU1MgYXJlIHN0aWxsIGFwcGxpY2FibGUm bmJzcDs8c3BhbiBsYW5nPSJFTi1VUyI+KGFzIHRoZXkgd2VyZSBvbiAtMTYpOyBidXQsIHRoaXMg d291bGQgYmUgYSBwbHVzIHRvIGZpeCB0aGVzZSBwb2ludHMuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVO LVVTIj5JIHVuZGVyc3RhbmQgdGhhdCB0aGUgYXV0aG9ycyBoYXZlIHdvcmtlZCBvbiB0aGlzIGZv ciA2IHllYXJzIGFuZCBtYXkgYmUgYm9yZWQgYnV0IEkgd291bGQgbG92ZSB0byBzZWUgdGhpcyBJ LUQgZ29pbmcgZm9yd2FyZC4gQWdhaW4sIGFzIG1hbnkgb3RoZXJzIEkgZmFpbCB0byBzZWUgdGhl IHJlYXNvbiBvZiB1c2luZyByZmM4MjJOYW1lIGFuZCB0aGUgZml4IHdvdWxkIGJlDQogdG8gdXNl IG90aGVyTmFtZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPk1heSBJIGFsc28gc3VnZ2VzdCB0 byB0aGUgYXV0aG9ycyB0byBhZGQgbmV3IGNvLWF1dGhvcnMgaW4gb3JkZXIgdG8gaGF2ZSDigJhm cmVzaCBibG9vZOKAmSBhbmQgZW5lcmd5ID88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPlJlZ2Fy ZHM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBs YW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPi3DqXJpYzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_1C60B01B32584F93A7822B2940CAAC49ciscocom_-- From nobody Mon Jun 22 13:29:43 2020 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A62683A083D; Mon, 22 Jun 2020 13:29:41 -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, FREEMAIL_FROM=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 RI03UHI27uwN; Mon, 22 Jun 2020 13:29:40 -0700 (PDT) Received: from mail-pj1-x1033.google.com (mail-pj1-x1033.google.com [IPv6:2607:f8b0:4864:20::1033]) (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 41AC13A115B; Mon, 22 Jun 2020 13:29:40 -0700 (PDT) Received: by mail-pj1-x1033.google.com with SMTP id h22so427712pjf.1; Mon, 22 Jun 2020 13:29:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=KMFTQqNbU6nRBtd76NpySthlV6KT2/bh0x9lxIVnMDc=; b=bQAoEmnYXHOmnxg7uUsPE+LhL0SwyxbWGhqskj0MyQ7ot953pFpfhhhvgtcAHPlssM F3aMWm/R6acP0dYdXGeglzARyaFsZAWjCOGbWcO+hSN0YTpZYPZI2PxOGt3pzMY4MhcU ITc4wqo6mw3kQjv2NqDn5lrx4K/4VUZqbvdWNNFWUHqn+3Y6Mud3497Btfxuh7nk+SqO XG35ZnfaTEhydHx6z2ytwTAGqi1jB6hPBI6yV+RSU7hnp9p1uySAnZHanXRfBTooFjpN dXN8J889YQ3qhZixKHESXUcdCB3ipTxPSIT+s/wnLbt8N6XvybPtbMu+p+32nXGsRTaW lpNQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=KMFTQqNbU6nRBtd76NpySthlV6KT2/bh0x9lxIVnMDc=; b=Ue2ub3BhXM6kWLhK6pMWIUBpFb9LgQjwOD6/M37IZPAdyNBt23MZQLV5h564ujGxFQ fjjJi84/USmVSyi8yYw1Hr3TpjTUMCA8sDZ5OIJoJa1+kPBTWFJ5vS53Y1Lelfmivbjv gct0iJBM1QcTpfa6NbqSREmxZHPgI2dB83PCbZfae8qg4HLgyXUlSur01tDKHTF1AReE PAjLIPvurU0HEM71K29TJmsHyJab6Tx0HKVI4+QSjqdC5QnjfM6xTHlUv/8LWkHbW01G BFfYe6NkKNGNXfaLX1wLquD7YcaTuMwuhbagLgUvAQWw3s/UjQPcsyJ8MN9BY02N1U2d USzQ== X-Gm-Message-State: AOAM533hrbaGlSV1qMmiiW7ollI3i8dPA68vCQTbaios2jSNrQuEblBw 7JKMfV9MT5biY67d+cUQ5FbKO1irxIs= X-Google-Smtp-Source: ABdhPJyupMTHrGyNxn3ZMWms0eyjIvKErzyjkNmK3R5swaqBOSOp0ldE2r8T+QECyJ4JGzMTgA0YUg== X-Received: by 2002:a17:902:c192:: with SMTP id d18mr21483631pld.260.1592857779456; Mon, 22 Jun 2020 13:29:39 -0700 (PDT) Received: from [192.168.178.30] (100.91.69.111.dynamic.snap.net.nz. [111.69.91.100]) by smtp.gmail.com with ESMTPSA id z8sm322921pjr.41.2020.06.22.13.29.35 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 22 Jun 2020 13:29:38 -0700 (PDT) To: Sheng Jiang Cc: "anima-chairs@ietf.org" , "Rob Wilton (rwilton)" , Anima WG References: From: Brian E Carpenter Message-ID: Date: Tue, 23 Jun 2020 08:29:32 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Anima] Adoption call for draft-fries-anima-brski-async-enroll-03, ends July 1st 2020 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jun 2020 20:29:42 -0000 Hi, I believe this work fills an important gap in BRSKI scenarios so it shoul= d be adopted. A couple of nits while I'm here:=20 1) I think the section "History of changes" should be an Appendix, since = it is distracting to the reader at present. Also it should be marked "[RF= C Editor: please delete]". 2) The Abstract is too long. I think everything from "In the context of .= =2E." belongs in the Introduction. Regards Brian Carpenter >> On 18 Jun 2020, at 11:27, Sheng Jiang > wrote: >> >> Hi, ANIMAer, >> =C2=A0 >> This message starts a two-week adoption call, it ends on July 1st, 202= 0. >> =C2=A0 >> draft-fries-anima-brski-async-enroll-03 has been presented to the WG f= or a long while and the WG showed good interest and had discussions. The = draft is now clearly in scope of ANIMA charter 2 that was adopted around = IETF106. The authors asked for adoption of the document. Giving the depen= dent BRSKI has passed the IESG evaluation, the chairs feel that it may be= the right time to call the adoption. >> =C2=A0 >> We therefore are asking the ANIMA working group for adoption of the fo= llowing work: >> =C2=A0 >> Title:=C2=A0=C2=A0=C2=A0 Support of asynchronous Enrollment in BRSKI >> Name:=C2=A0=C2=A0=C2=A0=C2=A0 draft-fries-anima-brski-async-enroll-03 >> Authors:=C2=A0 S. Fries, H. Brockhaus and E. Lear >> URL:=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0https://datatracker.ietf.org/doc/dr= aft-fries-anima-brski-async-enroll/ >> =C2=A0 >> This document is intended to become a standards track ANIMA WG documen= t. >> =C2=A0 >> Please express your support or rejection. If you think this document s= hould _not_ be adopted, please also explicitly indicate the reasons. >> =C2=A0 >> Regards, >> =C2=A0 >> Sheng >> =C2=A0 >> _______________________________________________ >> Anima mailing list >> Anima@ietf.org >> https://www.ietf.org/mailman/listinfo/anima >=20 >=20 > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima >=20 From nobody Mon Jun 22 20:31:44 2020 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 313BC3A171E for ; Mon, 22 Jun 2020 20:31:43 -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_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable 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 PXw-585OtgJn for ; Mon, 22 Jun 2020 20:31:42 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 ECB813A171D for ; Mon, 22 Jun 2020 20:31:41 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 05N3VGpL002570 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 22 Jun 2020 23:31:18 -0400 Date: Mon, 22 Jun 2020 20:31:16 -0700 From: Benjamin Kaduk To: "Eric Vyncke (evyncke)" Cc: Anima WG , Stephen Kent , Eric Rescorla , "tte+ietf@cs.fau.de" , "sbjarnason@arbor.net" , "Michael.H.Behringer@gmail.com" , "warren@kumari.net" , "jiangsheng@huawei.com" , "Joel M. Halpern" Message-ID: <20200623033116.GG58278@kduck.mit.edu> References: <1C60B01B-3258-4F93-A782-2B2940CAAC49@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1C60B01B-3258-4F93-A782-2B2940CAAC49@cisco.com> User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [Anima] Moving forward with draft-ietf-anima-autonomic-control-plane X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jun 2020 03:31:43 -0000 Hi Éric, On Mon, Jun 22, 2020 at 10:43:00AM +0000, Eric Vyncke (evyncke) wrote: > As the shepherding AD for this document, I am happy to see recent technical discussions on this document. OTOH, I do not observe any convergence to remove the pending DISCUSS. > > > > The 2nd IETF Last Call was completed 2 months ago in April 2020. Joel Halpern did the review for routing directorate and found a couple of issues (zone-ID, loopback definition) and it seems that there is now an agreement within the community for updated the text. > > > > In order to progress the document, a revised I-D is needed to fix Ben’s DISCUSS points: > > - Use of rfc822Name rather than otherName: the ‘easy’ fix is indeed to use otherName (even with the section 6.1.2 justifications) Russ has been helping reach out to more of the PKIX community; one suggestion that came up so far is to consider defining a dedicated URI scheme and using a uniformResourceIdentifier SAN -- did the WG consider that in the initial discussions? > - “MTI cryptographic mechanisms are under-specified†that should not be controversial and easy to fix Toerless has been doing an incredible job reaching out to the IPsec community and getting this text nailed down. There are still a couple points still under discussion but I'm confident that we will have something good here (and IIRC the TLS stuff has already been polished). > - Clarification about the RPL root I'm pretty sure this is already done -- note that my latest ballot position is only for the -19, so I think I just didn't update it yet. > > > Unsure whether Eric Rescola’s DISCUSS are still applicable (as they were on -16); but, this would be a plus to fix these points. Indeed. I expect the current SEC ADs to review those when the document comes up on a telechat again. > > > I understand that the authors have worked on this for 6 years and may be bored but I would love to see this I-D going forward. Again, as many others I fail to see the reason of using rfc822Name and the fix would be to use otherName. I do not want to put words in anyone's mouth, but my understanding is that the "obvious alternatives" to otherName are believed to suffer from strong deployment difficulties, whether one attempts to use an existing (commercial, or so-called "public" CA) or COTS CA software to run one's own CA. (There is some question as to whether the "public CA" route is advisable at all, given the legal agreements and policy documents surrounding such CAs and whether issuing certificates intended for ACP use is compatible with those policy documents. Sean's review alluded to some of these topics, and if you manage to catch Ryan Sleevi when he has time, he can talk about them at length.) -Ben > > > May I also suggest to the authors to add new co-authors in order to have ‘fresh blood’ and energy ? > > > > Regards > > > > -éric > > > > > > From nobody Mon Jun 22 20:31:55 2020 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D0573A1720 for ; Mon, 22 Jun 2020 20:31:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.597 X-Spam-Level: X-Spam-Status: No, score=-9.597 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_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=j2E9gHo0; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=LyZCq1fX 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 jj7kQasjwolr for ; Mon, 22 Jun 2020 20:31:49 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 584E43A172D for ; Mon, 22 Jun 2020 20:31:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9688; q=dns/txt; s=iport; t=1592883109; x=1594092709; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=HKlqCbJFVFN9ZXMXU7x93TKU+Rf8fEnEGQ138qoxjh4=; b=j2E9gHo0jcqVjFHnc1QeYByGENUr0pOifEa1/fr8ZXJu9rkoge/xP/sG Z+TVEm0q0tmVixvm0Jb6cQXW9Q4+KaaQK/m6QlOouoT32SOXs5hGYR8RS ztCw1e8IeD/8P2zgR/xcK+KlC8/oPZjxbOL+APQ3Mg0DYLasbNf88FPnY w=; IronPort-PHdr: =?us-ascii?q?9a23=3Aw04NThREYoI4HiqOk/dir1BNG9psv++ubAcI9p?= =?us-ascii?q?oqja5Pea2//pPkeVbS/uhpkESQBN+J8e5KjqzdtKWzEWAD4JPUtncEfdQMUh?= =?us-ascii?q?IekswZkkQmB9LNEkz0KvPmLklYVMRPXVNo5Te3ZE5SHsutfUHcpzu56jtBUh?= =?us-ascii?q?n6PBB+c+LyHIOahs+r1ue0rpvUZQgAhDe0bb5oahusqgCEvcgNiowkIaE0mR?= =?us-ascii?q?Y=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DdAQCodvFe/5RdJa1mGwEBAQEBAQE?= =?us-ascii?q?BBQEBARIBAQEDAwEBAYIKgSMvUQdvWC8sCoQag0YDjUOTbIRogUKBEANVCwE?= =?us-ascii?q?BAQwBARgBCgoCBAEBhEcCF4IUAiQ4EwIDAQELAQEFAQEBAgEGBG2FLgcmDIV?= =?us-ascii?q?yAQEBAQMBARARChMBASwLAQ8CAQgOAwQBASgDAgICJQsUCQgCBAENBQgagwW?= =?us-ascii?q?Bfk0DLgEOq2UCgTmIYXaBMoMBAQEFhRsYgg4DBoE4gmeJfBqBQT+BVIIfLj6?= =?us-ascii?q?CXAEBAoEoARIBIysJgl4zgi2SKYY6m3QKglqZSZ57kSueSAIEAgQFAg4BAQW?= =?us-ascii?q?BaiJmcHAVO4JpUBcCDYQDihuDcYUUhUJ0AjUCBgEHAQEDCXyOawGBEAEB?= X-IronPort-AV: E=Sophos;i="5.75,269,1589241600"; d="scan'208,217";a="501078277" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 23 Jun 2020 03:31:48 +0000 Received: from XCH-ALN-003.cisco.com (xch-aln-003.cisco.com [173.36.7.13]) by rcdn-core-12.cisco.com (8.15.2/8.15.2) with ESMTPS id 05N3VmDD023063 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 23 Jun 2020 03:31:48 GMT Received: from xhs-aln-001.cisco.com (173.37.135.118) by XCH-ALN-003.cisco.com (173.36.7.13) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 22 Jun 2020 22:31:48 -0500 Received: from xhs-aln-002.cisco.com (173.37.135.119) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 22 Jun 2020 22:31:47 -0500 Received: from NAM04-CO1-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Mon, 22 Jun 2020 22:31:47 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=QDnEZ29qNoQCuEjpRYkLUv0wITNZzrwJi4cOl+vQkHY81bE/pJNWwfQVV2H7iR/rc1kO8DIRtflOEAVpBezgzIj/7GPjB5hew79pntGf0rpNV3/tn2Tqnwdt8ASDl+QrO2xd7NVE8hfZxWh6l3MiSrGt9t6/yRW31CiWcUNhe/Av7jSgCYCxwU4/GZ6azjYM+jc8C2K5ch3D4zQgugrfTPoWWX0Uyh642Aozy/m78kkJaOVaQTz35datzyWOhMo8axFtTnq+RSyxG831clsy4CWRyvoPHLfGKoso2XyEaqQvgHg3MutlWHqoWSrsgsvwdKsQdk99KKZs640ugTxPzQ== 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=HKlqCbJFVFN9ZXMXU7x93TKU+Rf8fEnEGQ138qoxjh4=; b=IeR6beS03FzZMoWIAGrMjRgfpWnSbLQ0AORthDTo9wfk3ZbwXwsJh+NXdbj7cylPyH2u1Ikiw2HKXLLI9Q6koPG50HrNN64rIkMuUgKv+PCySaxmQ9mU26UdfH1KWTRISoskI4EJqUbfAGSg3XoMBiT/brFVq27v91YvFYLxB0BV+cR79kwfYP5U1QswiPMkJX2Hcuf5ulc/Stn1q1I3coFrd/EqvQ/zU0cMowoAB47lB9Ub/SqG600DmXlN6OYyC3PdvDK4Bm2sFCI4FNNmx5ynKZDMIBknzGG5NfMM2Tmzi8VoCJNu41zEeodGHd6aKtvE/o/Io7QEMuBpn7JIXw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=HKlqCbJFVFN9ZXMXU7x93TKU+Rf8fEnEGQ138qoxjh4=; b=LyZCq1fXe0tBsobdi6obahwrgK3Ucahtuf4aP2jTXLLgj1CbW+qWru/4dpNPx4lnJaMLPrVNt5sISpYt2Kc6YJYF74fBKZ55Iu93C91uWE8miZgaiywaHEcbGSkBKECBUF8Gc5gJoIk3Tc9C/46elOGwAUKuwAZvYKwRBU8uXb4= Received: from MN2PR11MB3901.namprd11.prod.outlook.com (2603:10b6:208:138::12) by MN2PR11MB3856.namprd11.prod.outlook.com (2603:10b6:208:ef::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3109.21; Tue, 23 Jun 2020 03:31:46 +0000 Received: from MN2PR11MB3901.namprd11.prod.outlook.com ([fe80::8492:8c63:dd5f:39c7]) by MN2PR11MB3901.namprd11.prod.outlook.com ([fe80::8492:8c63:dd5f:39c7%5]) with mapi id 15.20.3109.027; Tue, 23 Jun 2020 03:31:46 +0000 From: "Owen Friel (ofriel)" To: Eric Rescorla , Stephen Kent CC: Anima WG Thread-Topic: [Anima] representing ACP info in X.509 certs Thread-Index: AQHWR1+JNyfRR8kzFEir9HF7n/5jvajiRvyAgANGAmA= Date: Tue, 23 Jun 2020 03:31:45 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: rtfm.com; dkim=none (message not signed) header.d=none;rtfm.com; dmarc=none action=none header.from=cisco.com; x-originating-ip: [161.142.179.234] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 5a177984-975e-4248-f73f-08d81725f4d0 x-ms-traffictypediagnostic: MN2PR11MB3856: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 04433051BF x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: pFJh4hWZAX00UCivpppUrZ+R/ZnnheqZ99xaEQr52q18zms1cW+bTuh1DtHzpCgbQzaDuYZWlqGoxdklSHgrWKEdoCI3ze7dsQvXmL6AXKMYci+nsnQ8JD3E1lujYjDlEJDR+/1ch1DSwGdeH+SGVnrLmoUNm2AZOwpm30yc1CC0H8HIhBby5asOuQ0NoeeFiOcW6rPFHrJ7q2Jdoxa9D+UkrwyzvSwYtuSzvdLTr/bKQNm06CQ2iuq8YTUUNHW+ivZGLSPkVGdj/JLrpoLYHhJoG5ELMLXUs3ImJajSM5jpOz2pRVPNmp4x0E6U+ZRjNPaKZYxSoQMaHbYjHsXb4EHPl1twEpex3y7TltDopHpIUdaXpAjHlxeRaTjVVMU8lIdielmceQoeoPm6N3fPSw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR11MB3901.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(366004)(136003)(39860400002)(396003)(376002)(346002)(66476007)(7696005)(64756008)(66556008)(66946007)(8936002)(9686003)(66446008)(55016002)(316002)(166002)(8676002)(52536014)(6506007)(2906002)(53546011)(33656002)(110136005)(186003)(5660300002)(4326008)(966005)(76116006)(86362001)(71200400001)(478600001)(26005); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: 1B2jDaedaD1v87eScUUJ/EZmUeLNvWr3b+sB5TCs7gCwtS01dtGrwspJ8AgCQyY0WTfM1l/33cTTfd/iPMwaojRKdAbXrGA3IYHIdlsBnm9Ez/HUCzPFdVmWeXRHmph5yTkrGF2McVidSfLRd/9bVBuZOOHGfZ78x1ssFHJKGKoZs61I86n7qIJ9ggUBA/wemip5y1KLH8kclyHpOJtUwUWwl21y9oOMPbr+45CWUJ6eLKuDJtU5kJ+u4CKOhysOax1whUVvrd32OCXzhpPXBIy8avFmYZZawHkc+EPc6z6TR9oIbXUVMYrnt1P7rFFJc0YZq2Avdopi64UCIa5g2bU/3mNkm691jaX/m9Rh0cTr2UbOkAbYQmOlBfmHAgN5tyogKZDhLjdHFzhiLeMKF/JtjUB8U1e1Bx6vjRQRHR+kgqt0iA+AKiC4I62f9uuiYe+qhuUb53Y3/U+dX6S0KxwYZMgv/Hhb0DEUZosI266YhqchhZlUAQU5UjDbju+Q x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_MN2PR11MB3901DD5D6176FEEA43EB9D72DB940MN2PR11MB3901namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 5a177984-975e-4248-f73f-08d81725f4d0 X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Jun 2020 03:31:45.9830 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 5YIZgygBQjvnWWUftvkseAuZVgJjLtTP3yhvZ1RxWUfpnpqvMdHsVOVuR1ikA5zRI0Qo3W8O9f/uNmb8iNLcVw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB3856 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.13, xch-aln-003.cisco.com X-Outbound-Node: rcdn-core-12.cisco.com Archived-At: Subject: Re: [Anima] representing ACP info in X.509 certs X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jun 2020 03:31:55 -0000 --_000_MN2PR11MB3901DD5D6176FEEA43EB9D72DB940MN2PR11MB3901namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QmVpbmcgY29tcGxldGVseSBwZWRhbnRpYyBhYm91dCB0aGUgUkZDNTI4MCB0ZXh0LCBub3doZXJl IGluIHRoZSB0ZXh0IGRvZXMgaXQgc2F5IHRoYXQgcmZjODIybmFtZSBjYW5ub3QgYmUgdXNlZCBm b3IgYW55dGhpbmcgYnV0IGVtYWlsIGFkZHJlc3MuIEl0IGRvZXMgc3RhdGUgbXVsdGlwbGUgdGlt ZXMgdGhhdCBhbiBlbWFpbCBhZGRyZXNzIG11c3QgYmUgcmVwcmVzZW50ZWQgYXMgYW4gcmZjODIy bmFtZSwgYnV0IHBsYWNlcyBubyBleHBsaWNpdCByZXN0cmljdGlvbnMgb24gd2hhdCBhbiByZmM4 MjJuYW1lIG1heSByZXByZXNlbnQuIFRoZSB0ZXh0IGFzIGlzIGRvZXMgbm90IGV4cGxpY2l0bHkg cHJlY2x1ZGUgdXNlIG9mIHJmYzgyMm5hbWUgZm9yIEFDUC4gVGhpcyBtYXkgYmUgdGhlIHdpZGVz cHJlYWQgdW5kZXJzdGFuZGluZyBvZiB3aGF0IFJGQzUyODAgbWVhbnMsIGJ1dCBpdHMgbm90IHN0 cmljdGx5IHdoYXQgaXQgc2F5c+KApg0KDQpGcm9tOiBBbmltYSA8YW5pbWEtYm91bmNlc0BpZXRm Lm9yZz4gT24gQmVoYWxmIE9mIEVyaWMgUmVzY29ybGENClNlbnQ6IDIxIEp1bmUgMjAyMCAwOToy Ng0KVG86IFN0ZXBoZW4gS2VudCA8c3RrZW50PTQwdmVyaXpvbi5uZXRAZG1hcmMuaWV0Zi5vcmc+ DQpDYzogQW5pbWEgV0cgPGFuaW1hQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtBbmltYV0gcmVw cmVzZW50aW5nIEFDUCBpbmZvIGluIFguNTA5IGNlcnRzDQoNClRoaXMgbWF0Y2hlcyBteSB1bmRl cnN0YW5kaW5nIGFzIHdlbGwuDQoNCk9uZSB0aGluZyB0aGF0J3Mgbm90IGNsZWFyIHRvIG1lOiBp cyB0aGUgZXhwZWN0YXRpb24gdGhhdCB5b3Ugd2lsbCBiZSB1c2luZyBhIHB1YmxpYyBDQSBvciB0 aGF0IHlvdSB3aWxsIGJlIHVzaW5nIGFuIGVudGVycHJpc2UtbGV2ZWwgb25lPw0KDQotRWtyDQoN Cg0KT24gU2F0LCBKdW4gMjAsIDIwMjAgYXQgNTowMyBQTSBTdGVwaGVuIEtlbnQgPHN0a2VudD00 MHZlcml6b24ubmV0QGRtYXJjLmlldGYub3JnPG1haWx0bzo0MHZlcml6b24ubmV0QGRtYXJjLi5p ZXRmLm9yZz4+IHdyb3RlOg0KDQpGb2xrcywNCg0KTXkgcGVyc3BlY3RpdmUgbWF0Y2hlcyB3aGF0 IFJ1c3MgJiBCZW4gaGF2ZSBzdWdnZXN0ZWQsIGkuZS4sIHVzZSBvZiByZmM4MjJOYW1lIGlzIGlu YXBwcm9wcmlhdGUgZm9yIHRoaXMgY29udGV4dC4gUkZDIDUyODAgaXMgdmVyeSBjbGVhciBhYm91 dCB0aGUgaW50ZW5kZWQgdXNlIG9mIHRoZSByZmM4MjJOYW1lIGZpZWxkIGluIGEgY2VydCBhbmQg dGhlIHByb3Bvc2VkIHVzZSBpbiB0aGUgYW5pbWEgY29udGV4dCBpcyBpbmNvbnNpc3RlbnQgd2l0 aCA1MjgwIHRleHQuIEEgcmVhc29uYWJsZSwgYXBwcm9wcmlhdGUgd2F5IGZvcndhcmQgaXMgdG8g ZGVmaW5lIGEgbmV3IG90aGVyTmFtZSB0eXBlIGZvciB0aGUgYW5pbWEgY29udGV4dC4NCg0KU3Rl dmUNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpBbmlt YSBtYWlsaW5nIGxpc3QNCkFuaW1hQGlldGYub3JnPG1haWx0bzpBbmltYUBpZXRmLm9yZz4NCmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYW5pbWENCg== --_000_MN2PR11MB3901DD5D6176FEEA43EB9D72DB940MN2PR11MB3901namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpNb25hY287DQoJcGFub3NlLTE6MCAwIDAg MCAwIDAgMCAwIDAgMDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxp Lk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206 LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0 ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAubXNvbm9ybWFs MCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9y bWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowY207DQoJbXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGNtOw0KCWZvbnQtc2l6ZTox MS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0 eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNh bGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDsNCglmb250LXdlaWdodDpub3Jt YWw7DQoJZm9udC1zdHlsZTpub3JtYWw7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5 cGU6ZXhwb3J0LW9ubHk7DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVM7fQ0KQHBhZ2UgV29y ZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0 IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9 DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2 OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYg Z3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAg djpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZd LS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1HQiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBs ZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5CZWluZyBjb21wbGV0ZWx5IHBl ZGFudGljIGFib3V0IHRoZSBSRkM1MjgwIHRleHQsIG5vd2hlcmUgaW4gdGhlIHRleHQgZG9lcyBp dCBzYXkgdGhhdCByZmM4MjJuYW1lIGNhbm5vdCBiZSB1c2VkIGZvciBhbnl0aGluZyBidXQgZW1h aWwgYWRkcmVzcy4gSXQgZG9lcyBzdGF0ZSBtdWx0aXBsZSB0aW1lcyB0aGF0IGFuIGVtYWlsIGFk ZHJlc3MNCiBtdXN0IGJlIHJlcHJlc2VudGVkIGFzIGFuIHJmYzgyMm5hbWUsIGJ1dCBwbGFjZXMg bm8gZXhwbGljaXQgcmVzdHJpY3Rpb25zIG9uIHdoYXQgYW4gcmZjODIybmFtZSBtYXkgcmVwcmVz ZW50LiBUaGUgdGV4dCBhcyBpcyBkb2VzIG5vdCBleHBsaWNpdGx5IHByZWNsdWRlIHVzZSBvZiBy ZmM4MjJuYW1lIGZvciBBQ1AuIFRoaXMgbWF5IGJlIHRoZSB3aWRlc3ByZWFkIHVuZGVyc3RhbmRp bmcgb2Ygd2hhdCBSRkM1MjgwIG1lYW5zLCBidXQgaXRzIG5vdA0KIHN0cmljdGx5IHdoYXQgaXQg c2F5c+KApjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+ PGI+PHNwYW4gbGFuZz0iRU4tVVMiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyI+ IEFuaW1hICZsdDthbmltYS1ib3VuY2VzQGlldGYub3JnJmd0Ow0KPGI+T24gQmVoYWxmIE9mIDwv Yj5FcmljIFJlc2NvcmxhPGJyPg0KPGI+U2VudDo8L2I+IDIxIEp1bmUgMjAyMCAwOToyNjxicj4N CjxiPlRvOjwvYj4gU3RlcGhlbiBLZW50ICZsdDtzdGtlbnQ9NDB2ZXJpem9uLm5ldEBkbWFyYy5p ZXRmLm9yZyZndDs8YnI+DQo8Yj5DYzo8L2I+IEFuaW1hIFdHICZsdDthbmltYUBpZXRmLm9yZyZn dDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtBbmltYV0gcmVwcmVzZW50aW5nIEFDUCBpbmZv IGluIFguNTA5IGNlcnRzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQi PlRoaXMgbWF0Y2hlcyBteSB1bmRlcnN0YW5kaW5nIGFzIHdlbGwuPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYu MHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPk9uZSB0aGluZyB0aGF0J3Mgbm90IGNs ZWFyIHRvIG1lOiBpcyB0aGUgZXhwZWN0YXRpb24gdGhhdCB5b3Ugd2lsbCBiZSB1c2luZyBhIHB1 YmxpYyBDQSBvciB0aGF0IHlvdSB3aWxsIGJlIHVzaW5nIGFuIGVudGVycHJpc2UtbGV2ZWwgb25l PzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4tRWty PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+T24gU2F0LCBKdW4gMjAsIDIwMjAgYXQgNTowMyBQTSBT dGVwaGVuIEtlbnQgJmx0O3N0a2VudD08YSBocmVmPSJtYWlsdG86NDB2ZXJpem9uLm5ldEBkbWFy Yy4uaWV0Zi5vcmciPjQwdmVyaXpvbi5uZXRAZG1hcmMuaWV0Zi5vcmc8L2E+Jmd0OyB3cm90ZTo8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDtt YXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxkaXY+DQo8cCBzdHlsZT0ibWFy Z2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7TW9uYWNvJnF1 b3Q7LHNlcmlmIj5Gb2xrcyw8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2lu LWxlZnQ6MzYuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7TW9uYWNvJnF1b3Q7 LHNlcmlmIj5NeSBwZXJzcGVjdGl2ZSBtYXRjaGVzIHdoYXQgUnVzcyAmYW1wOyBCZW4gaGF2ZSBz dWdnZXN0ZWQsIGkuZS4sIHVzZSBvZiByZmM4MjJOYW1lIGlzIGluYXBwcm9wcmlhdGUgZm9yIHRo aXMgY29udGV4dC48L3NwYW4+IFJGQyA1MjgwIGlzIHZlcnkgY2xlYXIgYWJvdXQgdGhlIGludGVu ZGVkIHVzZSBvZiB0aGUgcmZjODIyTmFtZSBmaWVsZA0KIGluIGEgY2VydCBhbmQgdGhlIHByb3Bv c2VkIHVzZSBpbiB0aGUgYW5pbWEgY29udGV4dCBpcyBpbmNvbnNpc3RlbnQgd2l0aCA1MjgwIHRl eHQuIEEgcmVhc29uYWJsZSwgYXBwcm9wcmlhdGUgd2F5IGZvcndhcmQgaXMgdG8gZGVmaW5lIGEg bmV3IG90aGVyTmFtZSB0eXBlIGZvciB0aGUgYW5pbWEgY29udGV4dC4NCjxvOnA+PC9vOnA+PC9w Pg0KPHAgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+U3RldmU8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+X19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpBbmltYSBt YWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86QW5pbWFAaWV0Zi5vcmciIHRhcmdldD0i X2JsYW5rIj5BbmltYUBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2FuaW1hIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hbmltYTwvYT48bzpwPjwvbzpwPjwvcD4NCjwvYmxv Y2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_MN2PR11MB3901DD5D6176FEEA43EB9D72DB940MN2PR11MB3901namp_-- From nobody Mon Jun 22 23:51:27 2020 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A273A3A17BA for ; Mon, 22 Jun 2020 23:51:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.6 X-Spam-Level: X-Spam-Status: No, score=-9.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 Qn7rIIuAunid for ; Mon, 22 Jun 2020 23:51:23 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D95E3A17BB for ; Mon, 22 Jun 2020 23:51:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6062; q=dns/txt; s=iport; t=1592895083; x=1594104683; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=TmQwtCsgFiOUoW7UvwXxcZaEsbgYADP9bQTwZqJTqAo=; b=HmKRB2Bq4PHpbd/2wtLbnpPfyrbwdC6G24PPi2Da9IMpvYWHB/UnPqwo 35HjpdeSQfmavQecBlBgoxVWCRw9CFre1ayEEhniVf6yQpifqUH5zaC1p 4DjVNrH09Cth8cDC+3pqGo78NTRDix16AKY0TTFwpeHltejCXq/vxY7US 8=; X-IronPort-AV: E=Sophos; i="5.75,270,1589241600"; d="scan'208,217"; a="27300361" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 23 Jun 2020 06:51:21 +0000 Received: from [10.61.204.134] ([10.61.204.134]) by aer-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id 05N6pKnK021216 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 23 Jun 2020 06:51:21 GMT From: Eliot Lear Message-Id: <6EA0BD6D-2B81-4428-A45A-24A0A21B73D0@cisco.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_149AD8D2-18F1-423A-9F94-A7DEA30EF5F5" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Tue, 23 Jun 2020 08:51:20 +0200 In-Reply-To: <20200623033116.GG58278@kduck.mit.edu> Cc: Eric Vyncke , Eric Rescorla , Stephen Kent , Anima WG , "Michael.H.Behringer@gmail.com" , "tte+ietf@cs.fau.de" , "Joel M. Halpern" , "warren@kumari.net" , "sbjarnason@arbor.net" , "jiangsheng@huawei.com" To: Benjamin Kaduk References: <1C60B01B-3258-4F93-A782-2B2940CAAC49@cisco.com> <20200623033116.GG58278@kduck.mit.edu> X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Outbound-SMTP-Client: 10.61.204.134, [10.61.204.134] X-Outbound-Node: aer-core-4.cisco.com Archived-At: Subject: Re: [Anima] Moving forward with draft-ietf-anima-autonomic-control-plane X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jun 2020 06:51:27 -0000 --Apple-Mail=_149AD8D2-18F1-423A-9F94-A7DEA30EF5F5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Ben > On 23 Jun 2020, at 05:31, Benjamin Kaduk wrote: >=20 > Russ has been helping reach out to more of the PKIX community; one > suggestion that came up so far is to consider defining a dedicated URI > scheme and using a uniformResourceIdentifier SAN -- did the WG = consider > that in the initial discussions? I don=E2=80=99t know if the group looked at this, but I can say that = from a public CA standpoint, it=E2=80=99s not much different from = otherName because there is a requirement to validate the name. A new = URI scheme would require a new resolution mechanism. Perhaps that is = needed as part of ACP anyway. The one value of URI is that it is easier = to configure in some of the tooling like OpenSSL. What disturbs me about all of this is that public CAs will accept = otherNames and produce garbage out. That=E2=80=99s just asking for a = boot to the head* from a vulnerability perspective. Eliot *https://www.youtube.com/watch?v=3D-V1Mn5-xF0w = ** (And one for Jenny and the whimp) --Apple-Mail=_149AD8D2-18F1-423A-9F94-A7DEA30EF5F5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Ben

On 23 Jun 2020, at 05:31, Benjamin Kaduk = <kaduk@mit.edu> = wrote:

Russ has been helping reach out = to more of the PKIX community; one
suggestion that came up so far is to consider defining a = dedicated URI
scheme and = using a uniformResourceIdentifier SAN -- did the WG consider
that in the initial = discussions?


I don=E2=80=99t know if = the group looked at this, but I can say that from a public CA = standpoint, it=E2=80=99s not much different from otherName because there = is a requirement to validate the name.  A new URI scheme would = require a new resolution mechanism.  Perhaps that is needed as part = of ACP anyway.  The one value of URI is that it = is easier to configure in some of the tooling like OpenSSL.

What disturbs me about = all of this is that public CAs will accept otherNames and produce = garbage out.  That=E2=80=99s just asking for a boot to the head* = from a vulnerability perspective.

Eliot

*https://www.youtube.com/watch?v=3D-V1Mn5-xF0w
** (And one for Jenny and the whimp)

= --Apple-Mail=_149AD8D2-18F1-423A-9F94-A7DEA30EF5F5-- From nobody Tue Jun 23 05:02:29 2020 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D95643A1886 for ; Tue, 23 Jun 2020 05:02:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, 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 (2048-bit key) header.d=rtfm-com.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 p3EUQnaZscwK for ; Tue, 23 Jun 2020 05:02:26 -0700 (PDT) Received: from mail-lj1-x229.google.com (mail-lj1-x229.google.com [IPv6:2a00:1450:4864:20::229]) (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 3FF063A0C23 for ; Tue, 23 Jun 2020 05:02:26 -0700 (PDT) Received: by mail-lj1-x229.google.com with SMTP id y11so23119079ljm.9 for ; Tue, 23 Jun 2020 05:02:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=07fdbtFmRVT3e5fSOV4Lz4QcTh4OMKMjE30NlmCbdhg=; b=FDNnVfhORmjRPiASSQJaiZieg975sdZQ+Y7KQoWQFXn8w2HsOuAHr4/Fi5A9yNXUHh yScD/Q73nHwjCC09f3n4v4U2KBb11MggtEFa40yLDQ4omhFM4zYsqEvBgLp0e6rIbG59 KwDfJN1yKNa79JbBjLP0dKhjqjE9pwOcE0sxtPdpg9eSe+czGB59MRtSlqoPJ1bJSQ2z BgeTNX6tZ/DjXmryZ9pF6CZ2zoXGWic/ial08WRzmblRPphEN1kbDj3V8RXU0P0tv/c3 JAtyQ8W/jIv+AiCEj+dgtXN8o9/LZPihjlco/J3N7pzD5DCaqE2Q3CU2EcgEWV7jhgXd fgFQ== 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=07fdbtFmRVT3e5fSOV4Lz4QcTh4OMKMjE30NlmCbdhg=; b=tpVL3DhzqsmeuU9+5r10gXajFki+y/esZMutdydboJOnG3ZlhfHJYRCsUvrZtdIbf4 p4f3J2EsAOeCjE5z1FGZUvb5Kmm0FCo/IGVex8LSou8iCQCyuNzz/CtFlkoFJxLuFDNq DciZxTbTXJBu2MJUIzBP2iwCsahs6+GiR2o1QMgyLWsbD4KSc3XZVt398a2kPS4SdxpT E/BJcT2N9CbGqnifVsY9yqpofAcFaSpKTtc/cZZv+1uAjcjIzMkRLhbJVPbiGLT+sLWa d7oK4lVF4w9Uukv2pt7sQn9NXoBgPq0lLZMlACmUmslwgDMBFPPxUecSPegZHTbzDu+x JNMw== X-Gm-Message-State: AOAM530YajuRXuWaMPnEE9kASbK/3aVkJUhZba/Ax/p+NRVL4PwImfMt vocc1ka3SZIeyWNBpQyesD95bd8x6jvYbIzcS4XPTw== X-Google-Smtp-Source: ABdhPJxvwyHSla4vLY4ca2Sb0zFjbZ4/ftVCQcxaILdaeQLPe/9Nds/eaf0A00r6n0WJx17YINcdi1rkfxN8y6bBwlM= X-Received: by 2002:a2e:81d4:: with SMTP id s20mr10991562ljg.184.1592913744420; Tue, 23 Jun 2020 05:02:24 -0700 (PDT) MIME-Version: 1.0 References: <1C60B01B-3258-4F93-A782-2B2940CAAC49@cisco.com> <20200623033116.GG58278@kduck.mit.edu> <6EA0BD6D-2B81-4428-A45A-24A0A21B73D0@cisco.com> In-Reply-To: <6EA0BD6D-2B81-4428-A45A-24A0A21B73D0@cisco.com> From: Eric Rescorla Date: Tue, 23 Jun 2020 05:01:48 -0700 Message-ID: To: Eliot Lear Cc: Benjamin Kaduk , Eric Vyncke , Stephen Kent , Anima WG , "Michael.H.Behringer@gmail.com" , "tte+ietf@cs.fau.de" , "Joel M. Halpern" , "warren@kumari.net" , "sbjarnason@arbor.net" , "jiangsheng@huawei.com" Content-Type: multipart/alternative; boundary="000000000000e4f66405a8bf21c4" Archived-At: Subject: Re: [Anima] Moving forward with draft-ietf-anima-autonomic-control-plane X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jun 2020 12:02:28 -0000 --000000000000e4f66405a8bf21c4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Jun 22, 2020 at 11:51 PM Eliot Lear wrote: > Hi Ben > > On 23 Jun 2020, at 05:31, Benjamin Kaduk wrote: > > Russ has been helping reach out to more of the PKIX community; one > suggestion that came up so far is to consider defining a dedicated URI > scheme and using a uniformResourceIdentifier SAN -- did the WG consider > that in the initial discussions? > > > > I don=E2=80=99t know if the group looked at this, but I can say that from= a public > CA standpoint, it=E2=80=99s not much different from otherName because the= re is a > requirement to validate the name. A new URI scheme would require a new > resolution mechanism. Perhaps that is needed as part of ACP *anyway*. > The one value of URI is that it is easier to configure in some of the > tooling like OpenSSL. > > What disturbs me about all of this is that public CAs will accept > otherNames and produce garbage out. That=E2=80=99s just asking for a boo= t to the > head* from a vulnerability perspective. > This would at present appear to violate the BRs. S 7.1.4.2.1 says: Contents: This extension MUST contain at least one entry. Each entry MUST be either a dNSName containing the Fully-Qualified Domain Name or an iPAddress containing the IP address of a server. The CA MUST confirm that the Applicant controls the Fully-Qualified Domain Name or IP address or has been granted the right to use it by the Domain Name Registrant or IP address assignee, as appropriate. -Ekr --000000000000e4f66405a8bf21c4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Jun 22, 2020 at 11:51 PM Elio= t Lear <lear@cisco.com> wrote:<= br>
Hi Ben

On 23 Jun 2020, at 05:31, Benjamin Kaduk <kaduk@mit.edu> wrote:

Russ has been helping reach out to mo= re of the PKIX community; one
suggestion that came up so far is to consider = defining a dedicated URI
scheme and using a uniformResourceIdentifier SAN --= did the WG consider
that in the initial discussions?


I don=E2=80=99t know if the group looked a= t this, but I can say that from a public CA standpoint, it=E2=80=99s not mu= ch different from otherName because there is a requirement to validate the = name.=C2=A0 A new URI scheme would require a new resolution mechanism.=C2= =A0 Perhaps that is needed as part of ACP anyway.=C2=A0 The one valu= e of URI is that it is easier to configure in some of the tooling like Open= SSL.

What disturbs me about all of this is that pu= blic CAs will accept otherNames and produce garbage out.=C2=A0 That=E2=80= =99s just asking for a boot to the head* from a vulnerability perspective.<= /div>

This would at present appear to= violate the BRs. S 7.1.4.2.1 says: =09 =09

Contents: This extension MUS= T contain at least one entry. Each entry MUST be either a dNSName containin= g the Fully-Qualified Domain Name or an iPAddress containing the IP address o= f a server. The CA MUST confirm that the Applicant controls the Fully-Qualified Domain Name or IP a= ddress or has been granted the right to use it by the Domain Name Registrant or IP address assignee, as ap= propriate.

-Ekr


--000000000000e4f66405a8bf21c4-- From nobody Tue Jun 23 05:49:38 2020 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DF1C3A0C5F for ; Tue, 23 Jun 2020 05:49:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.6 X-Spam-Level: X-Spam-Status: No, score=-9.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 VvQyP_-3Kr_U for ; Tue, 23 Jun 2020 05:49:33 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 660D83A0C47 for ; Tue, 23 Jun 2020 05:49:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4722; q=dns/txt; s=iport; t=1592916573; x=1594126173; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=pBZw4Xyg2jdHGhckJR44voQqBv3ht556AhoMTeByBvc=; b=TqSODXITAhDV+bJ6mhuBRtnl1xZJQyx9Nt5Ta/3CiQ+uFHZsi+v0giVi 4BQS3+d6HmBJrYnuYxNpvTq91E0XiImQQcJQukMchT2psb05bj70HH98u 3gRJ9teudx2bua+6R40p+P4TJjmdRbamp6s0DG08BKlFyGBxzOimw5tvl I=; X-IronPort-AV: E=Sophos; i="5.75,271,1589241600"; d="scan'208,217"; a="27310002" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 23 Jun 2020 12:49:31 +0000 Received: from [10.61.204.134] ([10.61.204.134]) by aer-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id 05NCnUkq004894 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 23 Jun 2020 12:49:31 GMT From: Eliot Lear Message-Id: <8C94BD38-B6D1-4473-8A92-A6DD11C7A7EC@cisco.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_1F45DA0D-9EEC-4068-AB40-188F4C76D868" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Tue, 23 Jun 2020 14:49:30 +0200 In-Reply-To: Cc: Benjamin Kaduk , Eric Vyncke , Stephen Kent , Anima WG , "Michael.H.Behringer@gmail.com" , "tte+ietf@cs.fau.de" , "Joel M. Halpern" , "warren@kumari.net" , "sbjarnason@arbor.net" , "jiangsheng@huawei.com" To: Eric Rescorla References: <1C60B01B-3258-4F93-A782-2B2940CAAC49@cisco.com> <20200623033116.GG58278@kduck.mit.edu> <6EA0BD6D-2B81-4428-A45A-24A0A21B73D0@cisco.com> X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Outbound-SMTP-Client: 10.61.204.134, [10.61.204.134] X-Outbound-Node: aer-core-4.cisco.com Archived-At: Subject: Re: [Anima] Moving forward with draft-ietf-anima-autonomic-control-plane X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jun 2020 12:49:36 -0000 --Apple-Mail=_1F45DA0D-9EEC-4068-AB40-188F4C76D868 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 23 Jun 2020, at 14:01, Eric Rescorla wrote: >=20 > I don=E2=80=99t know if the group looked at this, but I can say that = from a public CA standpoint, it=E2=80=99s not much different from = otherName because there is a requirement to validate the name. A new = URI scheme would require a new resolution mechanism. Perhaps that is = needed as part of ACP anyway. The one value of URI is that it is easier = to configure in some of the tooling like OpenSSL. >=20 > What disturbs me about all of this is that public CAs will accept = otherNames and produce garbage out. That=E2=80=99s just asking for a = boot to the head* from a vulnerability perspective. >=20 > This would at present appear to violate the BRs. S 7.1.4.2.1 says: > Contents: This extension MUST contain at least one entry. Each entry = MUST be either a dNSName containing the Fully-Qualified Domain Name or = an iPAddress containing the IP address of a server. The CA MUST confirm = that the Applicant controls the Fully-Qualified Domain Name or IP = address or has been granted the right to use it by the Domain Name = Registrant or IP address assignee, as appropriate.=20 >=20 > -Ekr >=20 Oh it does the DV. It just adds garbage into the cert :-(= --Apple-Mail=_1F45DA0D-9EEC-4068-AB40-188F4C76D868 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 23 Jun 2020, at 14:01, Eric Rescorla <ekr@rtfm.com> = wrote:

I don=E2=80=99t know if the group looked at this, but I can = say that from a public CA standpoint, it=E2=80=99s not much different = from otherName because there is a requirement to validate the = name.  A new URI scheme would require a new resolution = mechanism.  Perhaps that is needed as part of ACP anyway.  The one value of URI is that it is easier = to configure in some of the tooling like OpenSSL.
What disturbs me about all of this is = that public CAs will accept otherNames and produce garbage out.  = That=E2=80=99s just asking for a boot to the head* from a vulnerability = perspective.

This would at present appear to violate = the BRs. S 7.1.4.2.1 says:

Contents: This extension MUST contain at = least one entry. Each entry MUST be either a dNSName containing the = Fully-Qualified Domain Name or an iPAddress containing the IP address of = a server. The CA MUST confirm that the Applicant controls the = Fully-Qualified Domain Name or IP address or has been granted the right = to use it by the Domain Name Registrant or IP address assignee, as = appropriate. 

-Ekr


Oh it does the DV. It just = adds garbage into the cert :-(
= --Apple-Mail=_1F45DA0D-9EEC-4068-AB40-188F4C76D868-- From nobody Tue Jun 23 08:29:27 2020 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC5CB3A0E43 for ; Tue, 23 Jun 2020 08:29:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 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_BLOCKED=0.001, 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 (2048-bit key) header.d=rtfm-com.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 RmBm3eUKouRc for ; Tue, 23 Jun 2020 08:29:24 -0700 (PDT) Received: from mail-lj1-x230.google.com (mail-lj1-x230.google.com [IPv6:2a00:1450:4864:20::230]) (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 1B4773A0E52 for ; Tue, 23 Jun 2020 08:29:24 -0700 (PDT) Received: by mail-lj1-x230.google.com with SMTP id 9so23951222ljc.8 for ; Tue, 23 Jun 2020 08:29:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=y54hvqdvnEhGS27o7q7WtbIo+z8tZInBvNpaJSSD2Xs=; b=hjI9AVJQGFz8jk/LY4PsXbl4dUKpNtmdwpJruM0yodjUWkAVpgoJgUyG/l/IeHVmo6 szdcGrmbC1NqqSSK1FKBBgsS+v6/MO0u6vORsbIPgktUojPcxdCdutUdcD8S99PlVHLL x+bGG8mkZaVJf/J/7yMLjXXZsPNHM5soRUVcrdHVCiqLi3CsEgXKU+cBE8AcPliqpzf4 iMGwhBpw2Q5F7JqQ+Opb5pO8aceJ9RkoJhUZP6iSSwBPyB8j6vpKqtMrle33/Eku8F7P PVR+pHDIbd+hHJBQ/qLumYhydeJ7iS6qot+aqDgjDON7lYzsWcNpiF9BKVsj4PkJw+zW ZsIA== 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=y54hvqdvnEhGS27o7q7WtbIo+z8tZInBvNpaJSSD2Xs=; b=LbEVZwrYlyfBaRKBcDQl9Dwdh1v6c+FRQaVYDoC3E5P8L+oBWJmWP8qt8NZGQgFHyQ ngeqXF17jF/MhdZj7VQghu3mVNxZOHx91TIatlsVqkxuH2TguK09PIEV+dlPFW+BU+V7 5LFT/7RzldVdN8yAb60DMRQXbjBYPP/JyEVq8u46QDt7Job9XG1984LFQkupGXEqunZQ uRaWJmVESrNXegeN9279wUIXCDLOYsSLqqF2gpxc13nHmPBLqMsnKMmQ7SF+aFbJk6pI ubocjgBdYaNWYeo3jsx3jJihLRDXGWIpSgw2K538g+zMBManIalobW3AEDSgND9g3muG swJg== X-Gm-Message-State: AOAM531PkLY3tCFA2d6/rt9kVjjoax+TuyBXIA2bDwK/t2n0HYy05qHj mEaAKoDbcU8Pz4haCeDD05ot1UFo30blaFhdkXkUBg== X-Google-Smtp-Source: ABdhPJzrV+rCQDuA2uPsFfXGSbzpxJbO41H0EfQ52NYpAZTKf5TD133kxWIlYXPtx7/UpetlAjfl/t/0Yb73hWYdVH4= X-Received: by 2002:a2e:9cd4:: with SMTP id g20mr11388499ljj.371.1592926162238; Tue, 23 Jun 2020 08:29:22 -0700 (PDT) MIME-Version: 1.0 References: <1C60B01B-3258-4F93-A782-2B2940CAAC49@cisco.com> <20200623033116.GG58278@kduck.mit.edu> <6EA0BD6D-2B81-4428-A45A-24A0A21B73D0@cisco.com> <8C94BD38-B6D1-4473-8A92-A6DD11C7A7EC@cisco.com> In-Reply-To: <8C94BD38-B6D1-4473-8A92-A6DD11C7A7EC@cisco.com> From: Eric Rescorla Date: Tue, 23 Jun 2020 08:28:46 -0700 Message-ID: To: Eliot Lear Cc: Benjamin Kaduk , Eric Vyncke , Stephen Kent , Anima WG , "Michael.H.Behringer@gmail.com" , "tte+ietf@cs.fau.de" , "Joel M. Halpern" , "warren@kumari.net" , "sbjarnason@arbor.net" , "jiangsheng@huawei.com" Content-Type: multipart/alternative; boundary="0000000000000dd12f05a8c206a4" Archived-At: Subject: Re: [Anima] Moving forward with draft-ietf-anima-autonomic-control-plane X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jun 2020 15:29:26 -0000 --0000000000000dd12f05a8c206a4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Jun 23, 2020 at 5:49 AM Eliot Lear wrote: > > > On 23 Jun 2020, at 14:01, Eric Rescorla wrote: > >> >> I don=E2=80=99t know if the group looked at this, but I can say that fro= m a >> public CA standpoint, it=E2=80=99s not much different from otherName bec= ause there >> is a requirement to validate the name. A new URI scheme would require a >> new resolution mechanism. Perhaps that is needed as part of ACP *anyway= *. >> The one value of URI is that it is easier to configure in some of the >> tooling like OpenSSL. >> >> What disturbs me about all of this is that public CAs will accept >> otherNames and produce garbage out. That=E2=80=99s just asking for a bo= ot to the >> head* from a vulnerability perspective. >> > > This would at present appear to violate the BRs. S 7.1.4.2.1 says: > > Contents: This extension MUST contain at least one entry. Each entry MUST > be either a dNSName containing the Fully-Qualified Domain Name or an > iPAddress containing the IP address of a server. The CA MUST confirm that > the Applicant controls the Fully-Qualified Domain Name or IP address or h= as > been granted the right to use it by the Domain Name Registrant or IP > address assignee, as appropriate. > > -Ekr > > > Oh it does the DV. It just adds garbage into the cert :-( > I'm talking about the second sentence, which requires that the SAN contain only dNSName or IPAddress. -Ekr --0000000000000dd12f05a8c206a4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Jun 23, 2020 at 5:49 AM Eliot= Lear <lear@cisco.com> wrote:


On 23 = Jun 2020, at 14:01, Eric Rescorla <ekr@rtfm.com> wrote:
<= div>
I don=E2=80=99t know if the group looked at this, but I = can say that from a public CA standpoint, it=E2=80=99s not much different f= rom otherName because there is a requirement to validate the name.=C2=A0 A = new URI scheme would require a new resolution mechanism.=C2=A0 Perhaps that= is needed as part of ACP=C2=A0anyway.=C2=A0 The one va= lue of URI is that it is easier to configure in some of the tooling like Op= enSSL.

What disturbs me about all of this is that = public CAs will accept otherNames and produce garbage out.=C2=A0 That=E2=80= =99s just asking for a boot to the head* from a vulnerability perspective.<= /div>

This would at present appear to= violate the BRs. S 7.1.4.2.1 says:

Con= tents: This extension MUST contain at= least one entry. Each entry MUST be either a dNSName containing the Fully-= Qualified Domain Name or an iPAddress containing the IP address of a server= . The CA MUST confirm that the Applicant controls the Fully-Qualified Domai= n Name or IP address or has been granted the right to use it by the Domain = Name Registrant or IP address assignee, as appropriate.=C2=A0<= br>

-Ekr


Oh it does the DV. It just adds garbage= into the cert :-(

I'm talk= ing about the second sentence, which requires that the SAN contain only dNS= Name or IPAddress.

-Ekr

=
--0000000000000dd12f05a8c206a4-- From nobody Tue Jun 23 08:35:51 2020 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 025103A0EA3 for ; Tue, 23 Jun 2020 08:35:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.6 X-Spam-Level: X-Spam-Status: No, score=-9.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 hkwMtH5bPXS0 for ; Tue, 23 Jun 2020 08:35:48 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98B153A0F2A for ; Tue, 23 Jun 2020 08:35:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2052; q=dns/txt; s=iport; t=1592926547; x=1594136147; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=eUrjUY5JE5Nxukzngvhzfe5K5BQ/N56k4QHEQAc6hKM=; b=Ifo9rNTnvm7Z/AN8Izz2wZoLg0bQWYwChBF+YC3nBlFWJqwWs+FU/n/g jZ+cgjpz7RqjC/AAqb8RGEu6Ck2dO7xEzxXaMyszp+UwoN+qd0NisIDS3 cZaldA8gocUvkKwEp5rII28YE31ooU8swlqb0+lGEpRGehweZGiens7SC c=; X-IronPort-AV: E=Sophos; i="5.75,271,1589241600"; d="scan'208,217"; a="27314309" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 23 Jun 2020 15:35:45 +0000 Received: from [10.61.204.134] ([10.61.204.134]) by aer-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id 05NFZiVm010356 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 23 Jun 2020 15:35:45 GMT From: Eliot Lear Message-Id: <60658F80-7DB8-4A8A-AE0E-D2C1E3201DDA@cisco.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_8D4E6B45-A728-463E-9A15-263C75FF6BE8" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Tue, 23 Jun 2020 17:35:44 +0200 In-Reply-To: Cc: Benjamin Kaduk , Eric Vyncke , Stephen Kent , Anima WG , "Michael.H.Behringer@gmail.com" , "tte+ietf@cs.fau.de" , "Joel M. Halpern" , "warren@kumari.net" , "sbjarnason@arbor.net" , "jiangsheng@huawei.com" To: Eric Rescorla References: <1C60B01B-3258-4F93-A782-2B2940CAAC49@cisco.com> <20200623033116.GG58278@kduck.mit.edu> <6EA0BD6D-2B81-4428-A45A-24A0A21B73D0@cisco.com> <8C94BD38-B6D1-4473-8A92-A6DD11C7A7EC@cisco.com> X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Outbound-SMTP-Client: 10.61.204.134, [10.61.204.134] X-Outbound-Node: aer-core-3.cisco.com Archived-At: Subject: Re: [Anima] Moving forward with draft-ietf-anima-autonomic-control-plane X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jun 2020 15:35:49 -0000 --Apple-Mail=_8D4E6B45-A728-463E-9A15-263C75FF6BE8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 23 Jun 2020, at 17:28, Eric Rescorla wrote: >=20 >=20 >=20 > Oh it does the DV. It just adds garbage into the cert :-( >=20 > I'm talking about the second sentence, which requires that the SAN = contain only dNSName or IPAddress. Regardless, the garbage that is left in was the point of my note. Eliot --Apple-Mail=_8D4E6B45-A728-463E-9A15-263C75FF6BE8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

On 23 Jun 2020, at 17:28, Eric Rescorla <ekr@rtfm.com> = wrote:



Oh = it does the DV. It just adds garbage into the cert = :-(

I'm talking about the second sentence, which requires that = the SAN contain only dNSName or = IPAddress.


Regardless, the garbage = that is left in was the point of my note.

Eliot

= --Apple-Mail=_8D4E6B45-A728-463E-9A15-263C75FF6BE8-- From nobody Tue Jun 23 08:46:35 2020 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7FEC3A101C for ; Tue, 23 Jun 2020 08:46:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 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_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=verizon.net 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 ylkf9YTgSNQ4 for ; Tue, 23 Jun 2020 08:46:21 -0700 (PDT) Received: from sonic315-13.consmr.mail.bf2.yahoo.com (sonic315-13.consmr.mail.bf2.yahoo.com [74.6.134.123]) (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 C73963A0FF6 for ; Tue, 23 Jun 2020 08:46:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verizon.net; s=a2048; t=1592927179; bh=AordG0q1pHo3X6Hu7iXf4Sf2916UPPskM9yBYYbkPio=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From:Subject; b=osY8sFZYK0TtwwWQ4RjZ8cNRvMbw2XpGF1+d2x5OjNDA44+PUXlRtM06OAYEdNVdfTMBGXu//fx0WFh1DYPZAji5uTfX9nPH5pt58wXJji5RP48T4D3m3ROIIKdx0hS9aMssBtqQaIARUdA+ZTH5JkX4+1IvkveAgNnMaNGfcp9KOO8mt8SPNIyEyOfFjGF+HWkdunOR0K1Ds3KlIeUoX+P4zbUTgTM75vQmJ41G+N+Fp6GiqfBmC9HB5Cgjmug7YGaigdScMpwVI1SNb7vUG4mDvSJcTLcNkwALHHRPyniwWrz+pkCtLjFgyypmNErOCUc0lkOgYTP4XkQm2Lb2mw== X-YMail-OSG: Cg5G2loVM1m53pCTEiX8QvChTyRbNorjD6VVg9Jx5dLGHoncIQ96qlL1dRJYCAO oW7cN7mV.3iD_MmbsRlPNKOWhxWAmdh407pxAd4cVfwtZ6473_r1p.oZ7SUS1TdGQSxT0.u3ayEc gyVQpUatZn85s26.sVUQmVDhtmlxhdaflVQKwaZmOzFLzaKN4PmAgfGZ_IsrYCPxPH6Ofmu_82lq YMXKpqvwYaEZBDXAtS5JgZTrfh4Uk2UjevEU.CN5_LZmHtOe3.lthFSxEdhxumU2YnxqAXKb7Z6u KAgZUcxwkZzTkJbaSeq0rMuATimOAOUc.yE3q_HBHTa15.FyvekAjtj3KWIOJ92Iy1WGULfmSOSS uoAjxVZeTZCHeDo1vCljYjRNPyaLcLrM.lqb7ucz8lBR9DCg_xnNWZPyf3wGsgGyJPoq8_tYFVpv MAlZpwTIppZHdzixz2f1XugF8dzCtB7nHiDZQaxo5rLh5.TouOPDbZwIkqT5oUhmLqcrzRjV8sp4 k6lq8IFgCY6u1wXH8iWutGo8vKX2CDI_bwlJjM1._wS1e0XLThs5ZV5pPzBf_omQdpcuPRVlfkfr 1YkkQ7vobppfXLy7xvoQfY7.jrmOAUu25JjBEpFP6WdTxz4PD75KkBnEzdWTr.CdSQwiEQAnyCYa GmcvwobXNfWZv2UcAi5y5CKZYfP2NYuViduku1ULXT6Ncnipe9cxR3bg.8q0fQdsm2uA8ouGit5i E9iG9xZt.g7GwerpHLbkIESQNXwsfvP1rWX65bZElwk2WjnVsbPRpAt1QScO4ypW9uhyasB3aMu0 LjrjQHqaVGOoE1gFYAFZuZ_8fYPYSvL_WiiAOJ9mXyF33hzC0AXc1J6pypnJc5m.wqZI2xvra6pw 53mP7h.lF2OOdKBOV80Eo4u9vanLWfB4v_ICXI2SbIKeKSf2Wt_Fg7lD9JkhFpuQNJEaRxAFy88j hLA6ZtwI5msqBNaYHJKpoZq8ooKRYDqKCIjkqJt3sJATHbXtrcFr9O56d2l4dHQDcDyNwnl14uYa kgiA8zRcKl5izSbByHhiL5T_4X8OCXS11y5V75Gd_hEFM.hBwFpZIJ8rWjTjjs1lt.TkQfhBarLL _3BIqdC5KRZt69EeV1MvVi4GXmRThiIsYS4AsFNAi81dlg0CTWTuix9m126OsLZHA3AcpyAJwYcQ D4UgzPgwnjIAQhPk2Z2ngU1D.KJxRSwmV5Zueq1e7QtYm9lU6HWT6_4OIWjdfhquk.c3vxBvf5gL 9qsnKqnajpjgFqU82rsGtBKvK5FjeD4crqg40E7L7mddxhU_P5lRocTBZGT3Q10G3VajkluQRKGu iDU0BNkuvm6XcRFzT5QbHsGWT.HOlsUjqK2Ll3l8Ol3SLhzRQtyNW8KJUIBGaFlJYsv90UVUtZvs ThjGP0P_7r5EvfDEA6hcg4crLSHjcRGkLM0FyYa2JdMODydR8zkFPd6L8VbQvLrxT5_PbzolJrBc nDMoo Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.bf2.yahoo.com with HTTP; Tue, 23 Jun 2020 15:46:19 +0000 Received: by smtp420.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 7e644a492fef1793d5d9f7a232f7568a; Tue, 23 Jun 2020 15:46:18 +0000 (UTC) To: "Owen Friel (ofriel)" , Eric Rescorla Cc: Anima WG References: From: Stephen Kent Message-ID: <6981a76f-76f1-e9b2-319d-473c7a4bc847@verizon.net> Date: Tue, 23 Jun 2020 11:46:16 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------F4446BF5597D945CBEA2A756" Content-Language: en-US X-Mailer: WebService/1.1.16138 hermes_aol Apache-HttpAsyncClient/4.1.4 (Java/11.0.7) Archived-At: Subject: Re: [Anima] representing ACP info in X.509 certs X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jun 2020 15:46:34 -0000 This is a multi-part message in MIME format. --------------F4446BF5597D945CBEA2A756 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Owen, > > Being completely pedantic about the RFC5280 text, nowhere in the text > does it say that rfc822name cannot be used for anything but email > address. It does state multiple times that an email address must be > represented as an rfc822name, but places no explicit restrictions on > what an rfc822name may represent. The text as is does not explicitly > preclude use of rfc822name for ACP. This may be the widespread > understanding of what RFC5280 means, but its not strictly what it says… > Common sense argues against putting something other than an e-mail address in the rfc822namem attribute. I expect ADs to use common sense, as well as careful reading of prior RFCs, when making decisions. Steve --------------F4446BF5597D945CBEA2A756 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Owen,

Being completely pedantic about the RFC5280 text, nowhere in the text does it say that rfc822name cannot be used for anything but email address. It does state multiple times that an email address must be represented as an rfc822name, but places no explicit restrictions on what an rfc822name may represent. The text as is does not explicitly preclude use of rfc822name for ACP. This may be the widespread understanding of what RFC5280 means, but its not strictly what it says…

Common sense argues against putting something other than an e-mail address in the rfc822namem attribute.

I expect ADs to use common sense, as well as careful reading of prior RFCs, when making decisions.

Steve

--------------F4446BF5597D945CBEA2A756-- From nobody Tue Jun 23 13:34:48 2020 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CAFD3A0A1D for ; Tue, 23 Jun 2020 13:34: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, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 i2uIW9JgKYl2 for ; Tue, 23 Jun 2020 13:34:45 -0700 (PDT) Received: from mail-pg1-x52e.google.com (mail-pg1-x52e.google.com [IPv6:2607:f8b0:4864:20::52e]) (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 5546A3A0A07 for ; Tue, 23 Jun 2020 13:34:45 -0700 (PDT) Received: by mail-pg1-x52e.google.com with SMTP id s10so119265pgm.0 for ; Tue, 23 Jun 2020 13:34:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=uLh+qmvNOTct6cVDYJKdzoAAIRsbY718OAgRR1d6qFM=; b=FBh2pKy8j/aHj6Ti1bU6fkBpqcqxBRprwqejcLgFReXvYR+kNidI8ALH+bUz01MbhF aJglfWynqL55NFNtdUC7oBPWEgPXp3N26M8/Uk2yc5BermgXdLsNfdfFtRg5IxAoO1bu cMhBwS/weEsZvErbMhOBStz6IVw++Xsjls70gsK+gkXXWeaPNBLi/ZlOqydEjb4QaYza WX9xxA78k/SQNodmiN/KDTFvZ0KgLSPTaF6hEcfVNSlF5kcq2u9KAjX+cMU/3K+/vLbF wAccW64hYdCDHIw9cTFyenKPRdg6GCiiD9oBbfvUcczKHc47+g4izj73Qgb3maVuzk8E PAzg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=uLh+qmvNOTct6cVDYJKdzoAAIRsbY718OAgRR1d6qFM=; b=b3pEBuprOC7+o1hO/utdXn36BylhlmO8J0RJV28awcFL9HmF3KXaTHAZ/70DdEL5Bj KLdiPRV1Oz/fNfKK+crkt5HUzYCYg7/McumJ35HqOersFhhFqM99+yXpLNyAEKfgo2ME fc+Uyl16tTnT5RbaDAaWaClg1zw69k62UOCmMrzZEFunNmCURtFsB0sHWVgMA8XM/h5Z t6R5Ik03cEt3c5fdFdRhW87odAUd4rv6jt5UpL5uFninyLDNMPyDAiTkjpEdK6htffBO Dk5jvP/QDgPaQPiv1X9lcIcZ19C8W9nDaKK1+7/8E6N76tgrmt8jEtZQkgnptqxGiPMp fgAw== X-Gm-Message-State: AOAM530khZwAxEyEk7CbypTtv13QRkiJ22dkK0HYKfLEfm4IB308R7O4 nAtT+BhBrhhr1t9NeKExveM= X-Google-Smtp-Source: ABdhPJy/K+lHLBDdZsGFZTy2EzVdKHz8hkp167UHLD62335lSWvfu3kxf2vAZFqKcxRACbuPETut4w== X-Received: by 2002:a05:6a00:7c6:: with SMTP id n6mr24825616pfu.120.1592944484818; Tue, 23 Jun 2020 13:34:44 -0700 (PDT) Received: from [192.168.178.30] ([118.149.66.243]) by smtp.gmail.com with ESMTPSA id k7sm17981423pfp.84.2020.06.23.13.34.40 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 23 Jun 2020 13:34:44 -0700 (PDT) To: Stephen Kent , "Owen Friel (ofriel)" , Eric Rescorla Cc: Anima WG , rfcSELF+fd89b714F3db00000200000064000000+area51.research@acp.example.com References: <6981a76f-76f1-e9b2-319d-473c7a4bc847@verizon.net> From: Brian E Carpenter Message-ID: <6c4e402f-cce6-daff-aa16-6159340f0802@gmail.com> Date: Wed, 24 Jun 2020 08:34:38 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <6981a76f-76f1-e9b2-319d-473c7a4bc847@verizon.net> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Anima] representing ACP info in X.509 certs X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jun 2020 20:34:47 -0000 Regards Brian Carpenter On 24-Jun-20 03:46, Stephen Kent wrote: > Owen, >> >> Being completely pedantic about the RFC5280 text, nowhere in the text = does it say that rfc822name cannot be used for anything but email address= =2E It does state multiple times that an email address must be represente= d as an rfc822name, but places no explicit restrictions on what an rfc822= name may represent. The text as is does not explicitly preclude use of rf= c822name for ACP. This may be the widespread understanding of what RFC528= 0 means, but its not strictly what it says=E2=80=A6 >> > Common sense argues against putting something other than an e-mail addr= ess in the rfc822namem attribute. >=20 > I expect ADs to use common sense, as well as careful reading of prior R= FCs, when making decisions. Indeed, but that cuts both ways, since running code is our goal. No parse= r is in a position to say that rfcSELF+fd89b714F3db00000200000064000000+a= rea51.research@acp.example.com isn't an email address. Brian >=20 > Steve >=20 >=20 > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima >=20 From nobody Tue Jun 23 16:52:33 2020 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F12A93A0C80 for ; Tue, 23 Jun 2020 16:52:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, 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=verizon.net 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 8yFz-L89gFLE for ; Tue, 23 Jun 2020 16:52:30 -0700 (PDT) Received: from sonic316-12.consmr.mail.bf2.yahoo.com (sonic316-12.consmr.mail.bf2.yahoo.com [74.6.130.122]) (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 E00213A0C7F for ; Tue, 23 Jun 2020 16:52:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verizon.net; s=a2048; t=1592956348; bh=trDafBFF0Xbq25Xru9mh+qQEwOUMw3suOSD3GLYTmfQ=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From:Subject; b=nMG5P8vII3DwqB6g8P7yVXYX6jPupZoNmaOiGMBKeVU4FeneNoIVe5lZWgpCtellHPRYzD2dtlCCmovGgIbXjxHD6m5n90rPMfvr33Ly1/UEtCMjsQgasX+q+WoBEqZzVX+IaYxUOmnbUmaXAwRIs5h5zGO9bQjF01gebgTSalx591Py8Hx5557mVJGtl/bNUSQqZ2s5WXeslgXlhMrk4bH4tnMbyECHkZmpo+GIicLR0bP99pMph3tUupDwynrQDYRoe/D16E50F+HejTcal6mN72O0/wTeVw6uVUeFkv03wNNlFJ32yEAtVrDaFXbPOHO2y6OneSCS2nw0w3aMIA== X-YMail-OSG: PoYbMVIVM1ntwPhsyDEdqYOEpO9G4xNJtKqCmi.U9ubS18on5KIlYlUPJ5QVBOT u0JyOPd1hG.0mIK6hg2NtNL655ncEQYMI9W87id.ORSuWTO0LzmoK1VnOg6mhcZeMbW_ztCcG0Hf 3YJanzR367Gu2JYnopaXTrhL_S4T8DGDVFqTQxVDqlhubRKAxsj73NYCKIaJsEax4CR6GBxq5el3 R4I52XD05OptJqrL.1pDaFfeAbF7vC3kFtNoLYUf96hjjt2T5JocR2KNHL2hHmSuk5rcSJbWkO0x j1EMB5sBUYX9u6JQL9_TJIzaPvfbdzGEaxuM.0nv2ppu97E5fs2wjAc59f4Yw0rDLB.HVk8R_58r i17GO0qD6KQrvt574jWOtyJUMudia3EU5YRvYN0b0RqWDKEjPi7GMzb3bZaVmnKfyTMnGyLvwBGP DYHalZOk7KahlMoO93CYKScqJqUKro_L0_7aFTWC9sbwE.88rxRgrz9A8YyqKmdX7HM4dNV9E0Ww qbh0jgeBT_9qtC1rs.rQbK8zULb2MJwMEXowZYbrHFxqJT.kwQJKkfKmXwJyxU81reI10RCAGoVf Xh5xuAlZUaAX4dWKQtlFEGXBlSiXWk_vDqfDXaHFNpKvoPz4YqG803Rlm8.SgNJ3RxI6j7iTlwzT RqaQkColPcAJn.knT9Y_SnO3dYzQJvZdOUleX0Cc6BgyhRZM4CiGmL55GIoTuC4p5YDpF8iZ8.z. ZRctqovBbjSe530Jojge3SRL1GRVernwKFM_dVaGEbl20OpsWemFT2wZcVM8YqPYO16ZiSjvtaao OKtgdPbrzferdYSmFxUtwZxzGFi9O1p8bEPvmwurBGH_ZYTW9qsPlJ5aVkpZFHWH.Luat.qvx3rW t6IIfr3cmtCKo72Hrvv.fQDFLBC1pS5r_7L0Rrbc3I493dlVuyrwOnEfYKnxQFTZWJnJYhpdAH6k bgNNjvDkBefD6lJaLXrNNf0AuGlYBJkOTvqvWSx2NAob_IDyBfJ4BmN_UnKhmb40gLClx5kMztiO .nIradXcfzOrN4Z0Gka9ICTVIdNlgZ4Pba_L52X_t_9ISF9sm.dzTsdUzcVCZq7ylk779YRECEdO EBMMz8kqYot12H4cYpSzw19j0obr0g3mTYV2xJn9YviIX.eDCXA9uuLJ.H8PIcrLSLa7dEvLbqke 82_jlnoJPOdXMeaAKFAL8Nr51aE.f8f0rSnXAeV0FHb2FZtJjKVcaDSSUWwKXuvNCtkaohZNkhqf J_uSh7isPyMHTffFiengzvYbxY5Xz9pQgwM7PGw.o2svI8mGmxdjHdP.AkMOdDBrEGA.IkiaDuR2 f.MtsKlZaEuE9i3qSUsvzSjEtpeBOhghQ8ns9EG6b9IwXm0nPustdYgZBxxUCUzNmDwDg.ka7vFo IIJPqx5mYA0cYY5XaadyFdT.AR4.I82lFxITJnVDptNqWdW.IyFjcdGsW_2Oo60jMQ3UN7_JAyRo 8KFhGx7NQ.yKrNFhpT4c3re90nezgWyzRYnNspw-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic316.consmr.mail.bf2.yahoo.com with HTTP; Tue, 23 Jun 2020 23:52:28 +0000 Received: by smtp413.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID a3a54140683b6475eb93bd20ef472d43; Tue, 23 Jun 2020 23:52:27 +0000 (UTC) To: Brian E Carpenter , "Owen Friel (ofriel)" , Eric Rescorla Cc: Anima WG , rfcSELF+fd89b714F3db00000200000064000000+area51.research@acp.example.com References: <6981a76f-76f1-e9b2-319d-473c7a4bc847@verizon.net> <6c4e402f-cce6-daff-aa16-6159340f0802@gmail.com> From: Stephen Kent Message-ID: <9c09debe-3463-a574-46cf-cee86a2c68af@verizon.net> Date: Tue, 23 Jun 2020 19:52:25 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <6c4e402f-cce6-daff-aa16-6159340f0802@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Mailer: WebService/1.1.16138 hermes_aol Apache-HttpAsyncClient/4.1.4 (Java/11.0.7) Archived-At: Subject: Re: [Anima] representing ACP info in X.509 certs X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jun 2020 23:52:31 -0000 Brian, > Common sense argues against putting something other than an e-mail address in the rfc822namem attribute. > > I expect ADs to use common sense, as well as careful reading of prior RFCs, when making decisions. > Indeed, but that cuts both ways, since running code is our goal. No parser is in a position to say that rfcSELF+fd89b714F3db00000200000064000000+area51.research@acp.example.com isn't an email address. If we were only AIs that would be a suitable reply ;-). But, we're not- we all know that the proposed IDs are NOT rfc822 addresses, so let's not play games. The simple answer is that when, in the past, developers have chosen to abuse the semantics of subject name fields in certs, the result shave been VERY long lasting, and embarrassing. Long ago, Netscape chose to shove a DNS name into the DN common name filed because it was an easy fix for their problem. As a result, we still have browsers and CAs that misuse that field. At least that egregious behavior was not the result of an IETF WG. Let's not screw this up in the name of expediency! Steve From nobody Tue Jun 23 17:55:47 2020 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CB733A0B7E for ; Tue, 23 Jun 2020 17:55: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, 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 KxZwISVNcITq for ; Tue, 23 Jun 2020 17:55: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 AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38F8F3A0CF7 for ; Tue, 23 Jun 2020 17:55:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id E9E40389AE for ; Tue, 23 Jun 2020 20:52:59 -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 WaWl9bm33w6n for ; Tue, 23 Jun 2020 20:52:59 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 48FDA389AC for ; Tue, 23 Jun 2020 20:52:59 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 1ECE7400 for ; Tue, 23 Jun 2020 20:55:40 -0400 (EDT) From: Michael Richardson To: Anima WG In-Reply-To: <9c09debe-3463-a574-46cf-cee86a2c68af@verizon.net> References: <6981a76f-76f1-e9b2-319d-473c7a4bc847@verizon.net> <6c4e402f-cce6-daff-aa16-6159340f0802@gmail.com> <9c09debe-3463-a574-46cf-cee86a2c68af@verizon.net> 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: [Anima] representing ACP info in X.509 certs X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jun 2020 00:55:46 -0000 --==-=-= Content-Type: multipart/mixed; boundary="=-=-=" --=-=-= Content-Type: text/plain Stephen Kent wrote: > The simple answer is that when, in the past, developers have chosen to abuse > the semantics of subject name fields in certs, the result shave been VERY > long lasting, and embarrassing. Long ago, Netscape chose to shove a DNS name > into the DN common name filed because it was an easy fix for their > problem. As a result, we still have browsers and CAs that misuse that > field. At least that egregious behavior was not the result of an IETF > WG. Let's not screw this up in the name of expediency! Yes, I remember that. Why do you think Netscape did that? What should they have done instead? --=-=-= Content-Type: text/plain Content-Disposition: inline Content-Description: Signature -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-=-- --==-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl7ypIsACgkQgItw+93Q 3WWPowgAlTEv4L8QxCsX1mQc91P5JZ73AFeNIKhG6eXgaycj+9mlxgW2v1QzhG1K vu9F/c1EWvzUW1Xm3cvQbfC0IZEEiK+Wz0Waw+WJ2XU1LOVIFRUG5XWZEzRGqQtU HxsVZdyCsVEpu1cXBcf5yRhr+bIbLZIM2Syi/dll+9Fao4py37UYe/OtLKkp54Of mOg8X6Yrv8v63TWw4dGANSXvqKfU1N9zpU3KG/EAU6pGosB4uKStzti2nN+yKVtY RPA9PjhHcqh9IB/Uil4Npa+qNx7jBV//LNqjux8GGq1ZjETfNW7bN7uoZEHBWFIl naDNiML9QVoPn+H5iqUlLMP5YroUAQ== =BOa8 -----END PGP SIGNATURE----- --==-=-=-- From nobody Tue Jun 23 19:31:13 2020 Return-Path: X-Original-To: anima@ietf.org Delivered-To: anima@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 629543A00B0; Tue, 23 Jun 2020 19:31:08 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: anima@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.4.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: anima@ietf.org Message-ID: <159296586835.337.577109779817720457@ietfa.amsl.com> Date: Tue, 23 Jun 2020 19:31:08 -0700 Archived-At: Subject: [Anima] I-D Action: draft-ietf-anima-autonomic-control-plane-25.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jun 2020 02:31:09 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Autonomic Networking Integrated Model and Approach WG of the IETF. Title : An Autonomic Control Plane (ACP) Authors : Toerless Eckert Michael H. Behringer Steinthor Bjarnason Filename : draft-ietf-anima-autonomic-control-plane-25.txt Pages : 160 Date : 2020-06-23 Abstract: Autonomic functions need a control plane to communicate, which depends on some addressing and routing. This Autonomic Control Plane should ideally be self-managing, and as independent as possible of configuration. This document defines such a plane and calls it the "Autonomic Control Plane", with the primary use as a control plane for autonomic functions. It also serves as a "virtual out-of-band channel" for Operations, Administration and Management (OAM) communications over a network that provides automatically configured hop-by-hop authenticated and encrypted communications via automatically configured IPv6 even when the network is not configured, or misconfigured. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-anima-autonomic-control-plane/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-anima-autonomic-control-plane-25 https://datatracker.ietf.org/doc/html/draft-ietf-anima-autonomic-control-plane-25 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-anima-autonomic-control-plane-25 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jun 23 19:34:21 2020 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CB723A00B3; Tue, 23 Jun 2020 19:34:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.87 X-Spam-Level: X-Spam-Status: No, score=-0.87 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=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 WFRH0QFG19zW; Tue, 23 Jun 2020 19:34:16 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42EEB3A00B0; Tue, 23 Jun 2020 19:34:12 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [131.188.34.52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 2B44B548068; Wed, 24 Jun 2020 04:34:07 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 20360440043; Wed, 24 Jun 2020 04:34:07 +0200 (CEST) Date: Wed, 24 Jun 2020 04:34:07 +0200 From: Toerless Eckert To: housley@vigilsec.com Cc: draft-ietf-anima-autonomic-control-plane.ad@ietf.org, anima@ietf.org, Benjamin Kaduk , evyncke@cisco.com, rwilton@cisco.com Message-ID: <20200624023407.GA41244@faui48f.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: [Anima] Russ/Ben: Re: Russ Housley's review of draft-ietf-autonomic-control-plane-24 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jun 2020 02:34:19 -0000 Hi Russ/Ben, * I had a writeup of this reply several weeks back, and then it got lost in some stupid crash, so i had to recreate it alltogether, and that conflicted with other priorities. And then i made the wrong choice trying to finish the IPsec and Joel halperns review before pushing out -25, so further delay to get this reply out. Oh well.. Diff here http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=https://raw.githubusercontent.com/anima-wg/autonomic-control-plane/6f3151058bcbea7369cfe402203c22a920b54db4/draft-ietf-anima-autonomic-control-plane/draft-ietf-anima-autonomic-control-plane.txt&url2=https://raw.githubusercontent.com/anima-wg/autonomic-control-plane/0caa400fd1c554ece49fddc7dabe8140195aa5bf/draft-ietf-anima-autonomic-control-plane/draft-ietf-anima-autonomic-control-plane.txt You are also free to compare the final -25 against -24, but that has additional changes in response to bove mentioned input to -24, Joel and IPsec stuff. For the numbered list of arguments for use of rfc822name, please use latest -25 version, it adds argument 3.5 about CA issues signing certs with non-standrd attributes. I will discuss the additional arguments/discussions re. rfc822name on the according threads on the mailing list. I find the discussion about rfc822name to be somewhat of an outliar. All the rest of the SEC IESG review was really good and to the actual point of security. Sure, it caused me a lot of pain/work getting up to speed on a lot of security protocol details, but IMHO hopefully good improvement for the doc. This rfc822name, if you excuse me saying so is an outliar: - The decision for rfc822name was a long-time compromise by practical experience and repeated discussions in the WG. - No contest beyond yours was maintained after reviewing the points explaining the choice in 6.1.2. This list was improved several times to address questions and resolved them. I have not seen any comment from you how the arguments made in that list create a good framework to justify the choice. - We also had what i felt to be a good discussion with Ben in person at IETF106 @ANIMA-WG, that i thought would have explained/persuaded him of our choice, but the only followup i saw afterwards was only repeating the "this looks like not the right thing" statement. - I don't think such an assessment is a good technical argument during WG time or IETF review compared to the arguments in the document in the list in 6.1.2, and even less so during IESG SEC review: - I have not heard any actual security issue raised against this choice. I was under the impression that IESG SEC reviews primary role is to exactly support that. - We have for all the years we revisited the decision a security advisor in ANIMA and she too never raised a security issue about this. Specific replies to all the points inline below. And thanks a lot for the excellent_review - rfc822name ;-) Cheers Toerless On Mon, Mar 23, 2020 at 08:56:14PM -0700, Benjamin Kaduk wrote: > Hi all, > > I had asked Russ to take a look at the rfc822Name usage. I guess I did not > do a good enough job of setting the background information for how the > certificate containing it would be used, so he had to read some other bits > of the document as well. > > FWIW I agree with his sentiment that "assigning another name type seems > preferable, even if it has the same syntax" (and that something more > efficient could be used if we had desire to do so). > > -Ben > On Fri, Mar 20, 2020 at 05:12:52PM -0400, Russ Housley wrote: > > The document defines Enrollment: > > Enrollment: The process where a node presents identification (for > example through keying material such as the private key of an > IDevID) to a network and acquires a network specific identity such > as an LDevID and trust anchors such as Certificate Authority (CA) > certificates. > > First, an annoyance. CA = Certification Authority (not Certificate Authority). This applies to an earlier definition and many other places as well. [fun excourse] In my defense, i grew up in a town with a dialect: google: site:cisco.com "certificate authority" -> 59,700 google: site:cisco.com "certification authority" -> 8,580 Also: https://en.wikipedia.org/wiki/Certificate_authority grep -il "ertification authorit" rfc*.txt | wc -> 272 (#RFCs) grep -il "ertificate authorit" rfc*.txt | wc -> 136 (#RFCs) grep -il "ertification authorit" rfc8???.txt | wc -> 38 (#RFCs) grep -il "ertificate authorit" rfc8???.txt | wc -> 13 (#RFCs) ratio is getting better for your side... a bit. Does RFC editor have a negative list of wrong words ? RFC editor abbreviation lists only the correct term. [/fun excourse] Fixed. > IDevID and LDevID are certificates. In this context, enrollment should be using an IDevID for authentication in order to get a LDevID. That was the intention of the text. Pls. check fixed text for CA, Enrollment, root CA, and TA, i hope they are better now. > The document defines Trust Anchor in a way that is not fully compatible with RFC 5280. It ought to use the definition from RFC 5280. I apologize, but this is a bit of a riddle to me because i could not find text that looks like a definition of "trust anchor" in rfc5280 and your concern above also does not explain exactly how the ACP text does not comply with such an "definition". Are you taking offense in conflating trust anchor and trust anchor information ? That seems to be a common issue in other documents, eg. in 5280: "When the trust anchor is provided in the form of a self-signed certificate" "When trust anchor information" ? In any case, in lack of a better pointe to an RFC, the ACP text now uses the X.509 text to define trust anchor and i tried to go through the text and distinguish between TA and TA information as good as i could. If there are still concern about this point, i would appreciate if you could be more specific as to what exactly is still wrong and provide suggested text fixes. > Section 6.1: > > - The text uses the word "trust" in a vague way. It should say what they are trusted to do, and what they are trusted to not do. > > - The test says: > > An ACP node MUST > have a Local Device IDentity certificate (LDevID) and a Trust Anchor > (TA) consisting of a certificate (chain) used to sign the LDevID of > all ACP domain members. > > This does not seem accurate to me in several ways. Most importantly, a TA is not c certifications path or chain. Fixed to: To trust another ACP member node with access to the ACP Domain, each ACP member requires keying material: An ACP node MUST have a Local Device IDentity certificate (LDevID), henceforth called the ACP Domain Certificate and information about one or more Trust Anchor (TA) as required for the ACP domain membership check () { Please suggest better text if this is still not good enough}. > Section 6.1.1: > > - s/X.509/X.509v3/ fixed. > - What does "All elements are [RFC5280] compliant??? mean? removed. It was just meant to be unnecessary duplicaction of initial sentence from same section: "ACP domain certificates MUST be [RFC5280] compliant X.509v3 certificates" > - MUST do both RSA and ECC? I think this is too simplistic. I do not expect devices to have both kinds of private key, but they need to handle both kinds of public key. This seems to be where the transition paragraph is going, but it is not very clear. Changed: "ACP nodes MUST support RSA and Elliptic Curve (ECC) public keys in ACP certificates" to "ACP nodes MUST support handling ACP certificates with RSA public keys and ACP certificates with Elliptic Curve (ECC) public keys" Hope i was guessing right what you are aluding to, if now, then explicit text suggestions are always welcome. > - I do not understand the wording about ECC curves that MUST be supported. Normally I see a single curve that MUST be supported for interoperability and and others that SHOULD be supported. The "or better" wording is really unclear. Also, each of the curves has a specific key length associated with it. In the ACP we have any-to-any connectivity and hence any-any mutual cert authentication, so i felt it to be prudent to support some good range of cert key sizes to ensure interoperability across a wide range of equipment within a single ACP - but also exclude key sizes that we feel are unnecessarily weak, such as RSA with less than 2048 bits. I changed the two paragraphs now to the following three: --- ACP nodes MUST support handling ACP certificates, TA certificates and certificate chain certificates (henceforth just called certificates in this section) with RSA public keys and certificates with Elliptic Curve (ECC) public keys. Certificates with ECC keys MUST indicate to be Elliptic Curve Diffie-Hellman capable (ECDH) if X.509 v3 keyUsage and extendedKeyUsage are included in the certificate. ACP nodes MUST NOT support certificates with RSA public keys of less than 2048 bits. They MUST support certificates with RSA public keys with 2048 bits and SHOULD support longer RSA keys. ACP nodes MUST support certificates with ECC public keys using NIST P-256, P-384 and P-521 curves. ACP nodes MUST support SHA-256, SHA-384, SHA-512 signatures for certificates with RSA key and the same RSA signatures plus ECDSA signatures for certificates with ECC key. --- I don't understand whether your note about the key length of the curves is an indication of missing text. When i first reviewed with Ben, i had to enter the curves because thats as specific as necessary AFAIK, but given how the key length is implied, i wouldn't understand why i would need to write those down. I don't remember that i have seen that being done either in other RFCs i read through. In any case, specific text suggestions always welcome in case this text is not sufficient. > - I would really like to see some clarity about digital signature vs. key establishment. The two are jumbled together is a way that is difficult to figure out. One way to read it is that digital signature is required, but key establishment is optional. I am not sure that is the intent. I may not understand what you mean with "key establishment". The first two paragraphs talk about the requirements to handle public key in the certificate including permitted minimum key-length for RSA. Is that what you call "key establishment" ? The third paragraph talks about requirements against the signatures in the certificates. The idea is to have the necessary and sufficient text for all ACP nodes to be able to authenticte each other wrt. to their certificate. > - The TLS reference should point to TLS 1.3 (not TLS 1.2). The MTI for the ACP is TLS 1.2, TLS 1.3 is SHOULD because of the need for lowest common denominator in more embedded device space moving very slowly from TLS 1.2 to TLS 1.3. See e.g.: 6.8.2. Also note that TLS profile for ACP is quite close to TLS 1.3 wrt. crypto requirements. > Section 6.1.2: > > - Using rfc822name seems wrong to me. Assigning another name type seems preferable, even if it has the same syntax. The semantics are different. This is the approach used in RFC 4556 for the Kerberos Principal Name. Can you point me to any specifc RFC text that actually prohibits what we want to do ? I was reading through the RFCs (forgot number now) that i think defined the encodings, and i could not find anything that would prohibit to use the existing rfc822name for a name that is a valid rfc822name. It would also be good if you review and address the bullet points 2.1 ... 2.6 and 3.1 ... 3.5 in section 6.1.2. These points explain and justify the choice of rfc822name. For example, points 2.1 , 2.4 and 2.5 would be closest in addressing your semantic concern. > - The document claims that "subjectAlName / otherName" will not be able to be supported because it uses a field that is not mandatory. I do not think that this is a very big deal. The otherName definition is: > > OtherName ::= SEQUENCE { > type-id OBJECT IDENTIFIER, > value [0] EXPLICIT ANY DEFINED BY type-id } > So, the "extra" processing is parse past the type and length for the SEQUENCE, perform an exact match to the constant value of the object identifier, parse past the type and length of the value. For example, when using the python ASN.1 library for the certificate processing, the additional code is tiny. After this, the parsing of the string is exactly the same. In fact, it might be possible to define a format that is even easier to parse if it did not have to look like an email address. Since this "extra" is so small, I think we should not use rfc822name in this context. This is addressed in for example point 3.2 in 6.1.2. The ASN.1 libraries available in embedded systems do not necessarily provide the ability to be extended. They may often come from embedded system OS vendors or third parties. Also see points 2.2 and 2.3 of 6.1.2: There is a whole backend and diagnostic infrastructure that needs to be extended when introducing new types to decode the new field. This is highly undesirable for easy operationalization. > Section 6.1.3: > > - validity period checking (in step 1) is part of path validation (in step 3). Sigh... hope i fixed all the references to the rule numbers in the document after eliminating this step 1 and mentioning how it is included in what is now step 2. > - In step 4, revocation checking allowed to be initially skipped, but the wording is concerning since the check is in a MUST statement. Then, the checking takes place when communications are established. I assume some cache is used, otherwise the connection works for a short while, then shuts down, over and over and over. Hopefully fixed. Pls. check the reworded text. I conditioned the MUST with a "when availalable" and changed the secondary MUST to lower case as they just explain the mechanism. Wrt to the up/down issue you mention: It seems cleat that one must periodically re-try a connection to another peer because it could have received a new certificate. If the connection is torn down at any point in time because of newly learned CRL/OCSP information, it also seems clear the connection needs to be torn down. I do not understand all possible connection setup protocols, but from what i understand, a negative CRL or OCSP information will not change back to positive in the future, so a connection torn down once because of a particular certificate would need to be retried later up to the point that the signaling gets to the same certificate, at which point in time it would fail. Aka: with caching of OCSP/CRL results, the connection would still be probed periodically, but would not be brought up again until there is a new cert. Is there anything of these explanations you would like to see written down ? Or that are wrong ? > Section 6.1.4: > > - Please use the terms from RFC 5280. That is, use "trust anchor" not "root-CA". a) While trying to do this, it seemed to me as if the word "trust point" that was also used in the text was also redundant. So i hopefully correctly eliminated it and replaced it with TA. b) Given how rfc7030 in 4.1.3 also refers to Root CA, and equaly the BRSKI draft in several places, and also rfc8572, aka: all the documents that this ACP relates to, i wonder what the rule of thumb is when it is appropriate to use root CA as a term and when not... I don't want to be the first RFC of all the ones that the ACP builds on or relates to that is NOT using the term... without understanding why ACP should be the only one not using it... There are similarily few occurrances of "root CA" as in those other documents... Just wondering. Thanks a lot for the review, and apoligies for my delay. Cheers Toerless > > Russ From nobody Tue Jun 23 19:35:46 2020 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BF893A0795; Tue, 23 Jun 2020 19:35:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.616 X-Spam-Level: X-Spam-Status: No, score=0.616 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FAKE_REPLY_C=1.486, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=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 gsB-x2A8r_Lr; Tue, 23 Jun 2020 19:35:29 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66C573A0775; Tue, 23 Jun 2020 19:35:27 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 8FFCF548441; Wed, 24 Jun 2020 04:35:21 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 8D9A7440043; Wed, 24 Jun 2020 04:35:21 +0200 (CEST) Date: Wed, 24 Jun 2020 04:35:21 +0200 From: Toerless Eckert To: Joel Halpern Cc: rtg-dir@ietf.org, last-call@ietf.org, draft-ietf-anima-autonomic-control-plane.all@ietf.org, anima@ietf.org, evyncke@cisco.com, rwilton@cisco.com Message-ID: <20200624023521.GB41244@faui48f.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <158648497631.26678.9121665060210659827@ietfa.amsl.com> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [Anima] Rtgdir last call review of draft-ietf-anima-autonomic-control-plane-24 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jun 2020 02:35:40 -0000 Thanks a lot, Joel Personal diff with just the fixes for you, otherwise feel free to compare -25 against -25, it has more fixes for Russ Housley and IPsec proto detail enhancements/fixes. http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=https://raw.githubusercontent.com/anima-wg/autonomic-control-plane/0caa400fd1c554ece49fddc7dabe8140195aa5bf/draft-ietf-anima-autonomic-control-plane/draft-ietf-anima-autonomic-control-plane.txt&url2=https://raw.githubusercontent.com/anima-wg/autonomic-control-plane/ae9e6cd856ab2706e8b38cc2552f2e77f6b676a5/draft-ietf-anima-autonomic-control-plane/draft-ietf-anima-autonomic-control-plane.txt Cheers toerless On Thu, Apr 09, 2020 at 07:16:16PM -0700, Joel Halpern via Datatracker wrote: > Reviewer: Joel Halpern > Review result: Not Ready > > Hello, > > I have been selected as the Routing Directorate reviewer for this draft. The > Routing Directorate seeks to review all routing or routing-related drafts as > they pass through IETF last call and IESG review, and sometimes on special > request. The purpose of the review is to provide assistance to the Routing ADs. > For more information about the Routing Directorate, please see > ???http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir > > Although these comments are primarily for the use of the Routing ADs, it would > be helpful if you could consider them along with any other IETF Last Call > comments that you receive, and strive to resolve them through discussion or by > updating the draft. > > Document: draft-ietf-anima-autonomic-control-plane-24.txt > Reviewer: Joel Halpern > Review Date: 9-April-2020 > IETF LC End Date: N/A > Intended Status: Proposed Standard > > Summary: > I have two major concern about this document that I think should be > resolved before publication. The are also a number of minor items that > warrant attention. > > Comments: > > While quite long, the draft is significantly improved from earlier versions. > It does provide significant explanation of its design choices, which is helpful > and appreciated. Sometimes this seems to end up more as marketing or promotion > instead of explanation, but this is mostly harmless. Any pointers to specific text that sounds to be too marketing wise always welcome. Happy to review that. I thought i had eliminated all the ones... i did see myself. > In particular, I would like to thank the authors and editors for the addition > of section 9.3 and its careful discussion of the many issues there. Thank you. > Major Issues: > > Section 6.10.3.1 on the use of Zone-IDs seems, from the material in A.10.1, > to be dependent upon either configuration (which ACP is supposed to avoid) > or completely unspecified magic. Having an addressing and routing scheme > standardized that is impossible to use seems at variance with appropriate > practice. It would be fine to say that provision is made for non-zero > Zone-IDs in the hope that future work can find ways to scale further using > this. But pretending it is well-defined, but not actually defining it, > seems unacceptable. You brought up this issue in your -13 review and we had a longer thread about it which ended in i think this statement of yours: | <8d2d0b06-0982-53a3-0ce0-38a465f58bed@joelhalpern.com> | My perspective is that I would have preferred to see the system designed such | that when Zones are needed, they can be added in a way that does not assume | system-wide knowledge of the layout choices. | | I think you could have achieved that. I understand that the working group | didn't do that. And beause it is the WG decision, I can live with it. I wish | it were better. No protection against double jeopardy in IETF ? Maybe its a good thing except for expediency of completion of the draft, because i had to rethink the issue again, and while it took a while i hope the result is especially good to help with initial ACP adoption challenges: The included text in the discussion up to -24 is now also in my opinion not very useful, it also had technical issues. The core issue that was combination of your ask for complete removal of the ACP zone address scheme and the (bad) solution of attempting to guess at a future way how to provide the final full benefits for the zone address scheme in 6.10.3.1. And that guesswork in 6.10.3.1 was not good, which is why 6.10.3.1 is now gone in -25. [Side note: I think i have the zone solution for a future RFC kinda worked out: we would have some manual or autonomic zone edges, grasp announcements within each zone announcing the Zone-ID and then nodes with ACP-Zone addresses that attach into a zone would update the Zone-ID of their ACP address accordingly. E-voila: zone-mobility by updating the zone-id field] However, the main disconnect was that this longer term goal alone is not good reason to keep Zone-ID. Instead the main reason to keep it was and is the ability to support better partial and incremental adoption of ACP, and for that one we do actually have good pre-standard implementation experience. But i didn't want this in the normative part of the spec, and i either didn't get the idea that it could go into the operational part (section 9), or i felt such text would be too difficult or too much subject to additional review attacks. But given how i think it is really an important option for initial deployments of ACP in large networks, i finally wrote that, it is now a new section 9.4. Pls check it out. > Section 6.12.5.1 on loopback interface is factually wrong. > It conflates one particular form of loopback interface with > the definition of loopback interfaces. > > This also leads to the error in the definition section (see > minor comment below). Let me move this here so we can have a cohesive discussion about that section. > 6.12.5.1 refers to the ACP addresses as node addresses. Technically, the > IPv6 architecture requires that all addresses are associated with > interfaces rather than nodes. I would prefer that this draft not > needlessly claim to violate that. In practice the term node address is often used, maybe less in RFC, but more in practice. And its often done interchangably with loopback addresses because without changing the actual IPv6 functionality, loopback interfaces are the main way to achieve the function operators typically associate with a node address. Be that as it may, i have tried to end the rewrite of the section with a paragraph that is trying to bring the use of the word "Node" in-line with the way RFC8402 does it. > (Loopback Interfaces were used long before RFC 4291, Yepp, was just bad english to connect something that was meant to be read in he context of IPv4 with an example about IPv6. > and on routers were often used for external communication. This was itself > a repurposing of the original loopback interface, 127.0.0.1, which was > indeed for internal use.) Yepp. So, i ended up rewriting the whole section also because EricV asked in his review earlier this year if it would not be better to use a new term instead of loopback. Whe i reviewed existing normaive references it became clear to me that loopback is actually a very good logical name for the function we need for addresses we want to behave as what non-dogmatic people would call a node address. So i hope the explanation in the new text for loopback to well justify the naming choice. I have also added a bullet list for justifying the loopback address use. Really nothing new, but common operational practice, alas, i wasn't able to find a list like this in other docs and this is an ongoing reason for questions from readers of ACP that do not have a background in running IP router networks. So hopefully, while this point too took me a lot of time to rewrite, it is all for the better. > Minor Issues: > > It seems distinctly unfortunate that the definition for Data Plane in > section 2 explicitly states that this definition is different from that used > in other work, including other routing work. This seems a recipe for both > confusion and mis-communication among technologists. Actually, IMHO the term data-plane has always been badly defined in the face of the inline-signaling model of IP networks. Are IGP/BGP signaling packets data-plane or control-plane ? How about routers connecting via L2 unbeknownst to them and their STP packets ? Even if you have an opininon, do you have a normative RFC to support your definition ? What is the difference between data and forwarding plane ? Don't answer... rethoric questions... I have replaced two existing paragraphs in the intro with the following text that explains the terminology better and shows how in the vision of autonomic networks the term is very logical, and that it is just existing non-autonomous networks in which there is more to the data-plane than what you might expect, but i think that is perfectly fine, especially when considering the layering example from above, where one layers (L2, ethernet) control and forwarding plane are just considered to be part of a higher layers data-plane. New text: In a fully autonomic network node without legacy control or management functions/protocols, the Data-Plane would be for example just a forwarding plane for "Data" IPv6 packets, aka: packets that are not forwarded by the ACP itself because they are control or management plane packets. In such networks/nodes, there would be no non-autonomous control or non-autonomous management plane. Routing protocols for example would be built inside the ACP as so-called autonomous functions via autonomous service agents, leveraging the ACPs functions instead of implementing them seperately for each protocol: discovery, automaticically established authenticated and encrypted local and distant peer connectivity for control and managemenet traffic and common control/management protocol session and presentation functions. When the ACP is added to henceforth so-called non-autonomous nodes that have non-autonomous management plane and/or control plane functions, the ACP instead is best abstracted as a special Virtual Routing and Forwarding (VRF) instance (or virtual router) and the complete pre-existing non-autonomous management and/or control plane is considered to be part of the Data-Plane to avoid introduction of more complex, new terminology only for this case. Like the forwarding plane for "Data" packets, the non-autonomous control and management plane functions can then be managed/used via the ACP. This terminology is consistent with pre-existing documents such as "/>. In both instances (autonomous and non-autonomous nodes), the ACP is built such that it is operating in the absene of the Data-Plane, and in the case of existing non-autonomous (management, control) components in the Data-Plane also in th e presence of any (mis-)configuration thereof. /New text > In the definition of in-band management in section 2, please remove the > commentary text on putative fragility. (I actually agree it has some > fragility. The discussion does not belong here. This is a definition.) > The promotional material may be warranted, if jarring, in other parts of the > documents. Not in the definitions please. Ok, i stripped down explanatory text for out-of-band network in terminology and instead pimped what you would call "marketing" about it in the introduction section. Easy to find in diff. Always happy to get explicit suggestions for how to reduce what you think is "jarring". The ability of ACP to even avoid a single case of sending out a tech person to a remote site due to misconfigurations is IMHO the bigest single use-case benefit in talks with customers, so i think it deserves good factual representation and i can not see where the text goes beyond that. I am happy if any positive pitching is called "marketing", but i definitely do not want anything to be "jarring". > The definition of a loopback interface in section 2 is wrong. It claims > that loopbacks transmit no external traffic. They send and receive lots > of external traffic. They merely do so by forwarding the traffic > internally to other interfaces. The traffic is external. The particular > step of the transmission, if implemented naively, is internal. Fixed. > If we are going to define ACP as a virtual out of band network, I would > suggest separating the terms into two definitions. One for true out of > band networks (distinct physical links, switches, and ports), and then a > definition for virtual out of band network which describes the ACP > approximation which creates independence from configuration, but not > independence from the physical links. Done. [ Note: I am btw. not worried about the link-sharing as a career limiting move for ACP, as soon as there is sufficient link redundancy (2 links eliminate 99% of issues). The actual HW design of the nodes to maximize ACP value is more interesting. I had slides about that in a research conference workshop some years back, e.g.: applying concepts such as BMC so that you can use the common HW diag functions you typically expect from OOB support. ] > Section 5, bullet 2, talks about a policy as to which peers ACP > communication should be established. It would be helpful if this gave a > reference or indication as to where such policies would come from. Given > the emphasis on zero touch, I presume they are not configured on the node? > (This issues was in my review of -13.) Original -13 thread here: | >> It is unclear how the flexible policy defined in section 5 bullet 2 (about | >> which nodes are ACP peer candidates) is consistent with autonomic | >> operation. It seems that the flexibility is important, so there should be | >> some explanation here about how this is consonant with the stated goals. I | >> understand that the bootstrap comes from BRSKI, but I do not think that is | >> where the policy comes from? | > | > Would rather not like to add more suggestive text, and thats at best what | > i could add. The default policy is the best "autonomic" behavior we know how | > to make work: aka: try to connect ACP to all neighbors you can discover. And | > we have only defined with DULL GRASP how to find subnet adjacent neighbors. | > | > The main reason to mention policy is so that there is some leeway to do | > more or even (sigh) less than all direct neighbors. Double jeopardy ? I actually did not bother to fix up the intro section since taking the editor pen from Michael. I had kept the "policy" in there as a reminder of Intent to be done in the future, but given how we deprioritized intent in charter, i felt more happy now than during 13 to fix this. Alas, it turns out i also found other points in the overview lacking clarity and consistency with the normative sections, so the changes here got larger, but hopefully all for the better. Please check. > Bullet 4 of section 6.1.3 on checking certificates against the CRL / OCSP > would seem to be better reworded. I believe the intended requirements i > that IF there is ACP connectivity to the CRL / OCSP source, then it should > be verified. But that absence of such connectivity should not prevent > association formation. (As, if I have read it wright, otherwise we could > deadlock the startup process.) Pls. check the full diff vs. -24 for this, because that fix is in the commit i did for Russ Housley before i worked on your review. If you don't like that text either, pls suggest better wording, its a bit of a tricky language problem i think, which a native speaker might master easier. > In the example in section 6.5 on Channel selection, in steps 7:C1 and > 11:C2, Node 1 concludes that it is Bob. However, in steps 12 and 13, the > text refers to Node1 (Alice). This seems inconsistent. Yikes. How could that have slipped me. Thanks a lot. > > Section 6.7.1 makes an assertion about the lack of need for MTI of security > mechanisms. The earlier explanation was well done and seems sound. This > shorter one seems wrong, since without MTI there is no good way to know > what ones neighbors may implement. I suggest simply removing this text and > replacing it with a backwards reference to the earlier description. (The > rest of the section is useful and clear.) Done. > In 6.10.3, ACP Zone Addressing Sub-Scheme, the text claims that when zone > IDs of 0 are used, the addresses are identifiers, and when non-zero IDs > aere used, they are locators. Since in either case the addresses are used > for packet forwarding, and the addressing information is propagated in the > routing protocol (RPL), this seems to be a misuse of the locator / > identifier distinction. And a misuse for no purpose as the distinction is > not relevant to the document. (This odd use of "identifier continues in > section 6.10.3.1. Identifier is not a synonym of "flat". Just say "flat".) Hey, i didn't come up with all this confusing an probably wrong understanding of locator or identifier, i just fell into the trap of trying to use these terms ;-)) This is removed now. Hope i found all places. Only locartors left should be about GRASP. Is there even any agreed upon distinction ? To me, identifier/locator are just two roles an address can have based on who is using it for what purpose. They're not exclusive to each other IMHO. > The assertion about looping packets in the later portion of 6.11.1.1 is > over-stated. There are other routing protocols that avoid looping-till-ttl > without changing the data plane header. > I suggest removing the gratuitous comparison with other routing protocols. Well... it was IMHO not gratuitous, it was just bad text. The intent was not to make the solution sound better than other routing protocols, but rather to explain how it is not far worse than other routing protocols given the absence of the RPI (RPL Packet Information). The text was not good because it only indirectly addressed what it intended to describe by just talking about TTL looping. I have replaced this paragraph by two paragraphs that hopefully better capture the intent: [snip] In RPL profiles where RPL Packet Information (RPI, see ) is present, it is also used to trigger reconvergence when misrouted, for example looping, packets are recognized because of their RPI data. This helps to minimize RPL signaling traffic especially in networks without stable topology and slow links. The ACP RPL profile instead relies on quick reconverging the DODAG by recognizing link state change (down/up) and triggering reconvergence signaling as described in . Since links in the ACP are assumed to be mostly reliable (or have link layer protection against loss) and because there is no stretch according to , loops caused by loss of RPL routing protocol signaling packets should be exceedingly rare. [/snip] Hope this is an adequate answer to close this point. I now have no text about TTL expiry because that is a difficult qualitative comparison for which there is IMHO not enough data on evidence: The reconvergence with RPL in the ACP profile may be somewhat slower than the most common sub-50 msec LFA in SP networks or subsecond SPF-IGP fast convergence common in most other networks in scope of ACP ("well manageg, aka: private enterprise etc. networks), but the total amount of traffic across the ACP will likely be orders of magnitude less than that on the Data Plane where the SPF-IGP runs. I think convergence with the profile should be 50 msec (link change discovery plus O(max-pathlength) * per-node RPL processing latency, but i think this is too much analysis for a spec, so no text. > Section 7.2 (L2 DULL GRASP) seems to be doing something quite useful. I > think I see how it would work. The need for some configuration on some > switches seems inevitable and acceptable. Hmm.. there is no intent to require configuration. What specifically do you think of ? The goal is really to support ACP in complete L2-only networks, except that the ACP itself is of course L3. One core part of the text is explaining how ACP can be supported on the most limited L2 hardware where it can work. Aka: withough changing the actual L2 HW forwarding, but just by punting GRASP packets so they are not flooded by L2. > I think there is one corner > case that should be avoided, as it seems likely to create significant > complexity for little or no benefit. It seems to me that a switch that is > capable of participating in the ACP should either participate in the ACP on > all its physical ports, or should not participate in the ACP at all. I > would not be surprised if that was the WG intent. But I could not find the > text that says this. (Apologies if it is there and I missed it.) Not sure why you specifically think this is an issue for devices operating at L2. I have seen all type of weird problems. For example: How do you enable autodiscovery of ACP neighbors across the 10Gbps backbone interfaces of a router/switch for broadband if those interfaces are initially disabled by software because the user is expected to first enter an additional license key to use those interfaces.... Sorry, randomn example. Maybe rephrase your point with an example why you think it deserve additional text ? Suggest additional text ? > > Section 9 starts by saying it is informational. But the first paragraph > says that some of the content is "necessary" for correct operation. Thus, > it seems that some of the content is normative? (I am not sure, but I > think the "necessary" material relates to what is needed to be a registrar?) The first paragraph does not say "correct operation", and i think to remember that i word smithed that paragraph quite a bit to walk the thin line: you can not build an ACP without understanding this section and follow its advice to the extend you deem appropriate or feasible, but we can also not normatively standardize what is in this section. Some things will hopefully gt standardized via future yang model RFC. That stuff is just not standardized beause it does not meet the formal bar. Most of the stuff is talking about variety of options deemed to be necessary or beneficial in various situations. Doing even the Yang stuff for the subset people will agree to is a lot of work. protecting the ACP from operator misconfiguration is IMHO necessary. I wouldn't even dare to begin guessing what details could get standardized for that. Yang models for new interface states would certainly be another 5++ year discusion in IETF. better to start these things with vendor proprietary Yang models and learn. I know from personal experience that you can not successfully deploy without humunguous amount of diagnostic as long as you have buggy implementations, especially when fitting into exising router OS, incurring a lot of unforeseen limitations. Very difficult to standardize because its all about interaction with the non-autonomic stuff unless you can severely isolate ACP in your platform design. If you do not understand the discussions about registrars, you will have a hard time getting a working support backend system for the registars. Aka: necessary does not mean standardizable. > Nits: > The second and third paragraphs of section 6.11.1.1 on RPL start with > duplicated text, and then go on to say different (complementary) things. > There is no need for the repetition. Right. I reworked the overview to remove duplicates, also structured into two subsections to highlight the two key themes of the profile (single instance and convergence). > The rank factor in 6.11.1.6 of 100 megabits as the boundary seems a fairly > arbitrary choice. It may be that an arbitrary choice was needed. Could > something be said? In particular, if someone looks at this 5 years from > now, it may seem quite confusing. In german, rule of thumb is called "pi times thumb", obviously much more accurate than just thumb ;-) I added the following paragraph: This is a simple rank differentiation between typical "low speed" or "IoT" links that commonly max out at 100 Mbps and typical infrastructure links with speeds of 1 Gbps or higher. Given how the path selection for the ACP focusses only on reachability but not on path cost optimization, no attempts at finer grained path optimization are made. Heard a nice summary about the new ieee work about the future of 10 Mbps ethernet over twisted pair, so i think the cut point at 100 Mbps may actually be quite a good one. aka: with just two values i don't know how we could do better. Aain, thanks a lot for the review. Toerless From nobody Tue Jun 23 19:48:14 2020 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D9B53A011B; Tue, 23 Jun 2020 19:48:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, 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=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 d2Dospu6oKiJ; Tue, 23 Jun 2020 19:48:10 -0700 (PDT) Received: from mail-pf1-x433.google.com (mail-pf1-x433.google.com [IPv6:2607:f8b0:4864:20::433]) (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 86FED3A0112; Tue, 23 Jun 2020 19:48:10 -0700 (PDT) Received: by mail-pf1-x433.google.com with SMTP id q17so428624pfu.8; Tue, 23 Jun 2020 19:48:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=/1gRbkIt0Nziy57Qimckr+aSOGK6hgGwiqeReq5ca4A=; b=HhhLBZHEbCOqqJo3nlqcnbzs9Iy6WhP8wM4WsF0OZG1dBf+WIwVVdZlpzB7FOUQpid xdVCwGyVpM/r7/Aw4A7tD5FRZMW2r9rB6O8NqFRR5uMI4gFEmAdwOtgAeaIXH66BShNO 5v7EG8Wd5u5lb6yYLn7Ita1yU3nL33aPoBnCHW/NNmuda82zOd9g/7t5DfhLWYrG1cTG oZ0ri01De7HE1TtoN9dPWgLSIPAWShFnlhfD7Z8D6KPdFPyVaged+BjI0+gAYR3xD0s0 UicSLrvcP4T4xQqwXSAWoZ4UxQ74dZakH1EfdG2Z3i6bK5FUMWRQLlkalZl9vd55cNww 6PPQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=/1gRbkIt0Nziy57Qimckr+aSOGK6hgGwiqeReq5ca4A=; b=Nl/D+ji801xAD5ZCNmWntntdlEDTGibbw8378YCBf49IKKtYpiHdLMG7uy6gMuzHxV nXObpG3fvsGYpopg58c9ETwJs2m4PjHzB5KMxz2ztbRkQ8D36xfsrI0UOfof+RLk8XTi mBqwfKZgoe5IsiPiZ5mfC1D/4p52mBuzJiDl4EncYmHuegni1WZAsZsAm3cDqO1XVgsL h9mU78vM+9vecz84WzP2mvUa2WUfC7ERgQfwUz/+4knW52/obcAV8TfbJnIY/a597HVK gaKTNAvcf0PjznAQWfgrXWtl66FKZ6d0xLFyS+1lmmmSPkMLP8Z9pvOOqd5x74U0BRGh JrSA== X-Gm-Message-State: AOAM5337mRbb2wRK/PHXKqasBkMF8qC7EsdXtpGemZ7TnsyhAGv1NXoi iOtxVXrh73fB228M0KFRyI635tQ+ X-Google-Smtp-Source: ABdhPJw0AlMrzi7mbcIecY9Pz0raCvTDk7Q+zaToLCrS1Irja+KZHN3Gw2Qlrs54XvWxmxtPyX99eA== X-Received: by 2002:a62:8096:: with SMTP id j144mr4974937pfd.78.1592966889820; Tue, 23 Jun 2020 19:48:09 -0700 (PDT) Received: from [192.168.178.30] ([118.149.66.243]) by smtp.gmail.com with ESMTPSA id z1sm17850907pfn.178.2020.06.23.19.48.06 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 23 Jun 2020 19:48:09 -0700 (PDT) To: Anima WG , draft-ietf-anima-autonomic-control-plane.all@ietf.org References: <83115a40-b8fe-bc4a-cce4-43c6291ef0ed@gmail.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Wed, 24 Jun 2020 14:48:03 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <83115a40-b8fe-bc4a-cce4-43c6291ef0ed@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] Significant nits in draft-ietf-anima-autonomic-control-plane-24 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jun 2020 02:48:13 -0000 Certified: both these examples are now correct in the -25 draft. Thanks Brian On 28-Apr-20 13:44, Brian E Carpenter wrote: > Hi, > > Thanks to Michael Richardson, we have found some important nits in the GRASP examples in the ACP draft. The CDDL syntax is correct, but the examples need to be corrected as below. The errors are in nesting levels within the flood message, and the naming > of constants. > > The draft is already in "Revised I-D Needed" so this can easily be fixed in the next draft. > > In Figure 3: > > OLD: > > [M_FLOOD, 12340815, h'fd89b714f3db0000200000064000001', 210000, > ["SRV.est", 4, 255 ], > [O_IPv6_LOCATOR, > h'fd89b714f3db0000200000064000001', TCP, 443] > ] > > NEW: > > [M_FLOOD, 12340815, h'fd89b714f3db0000200000064000001', 210000, > [["SRV.est", 4, 255 ], > [O_IPv6_LOCATOR, > h'fd89b714f3db0000200000064000001', IPPROTO_TCP, 443]] > ] > > > In Figure 5: > > OLD: > > [M_FLOOD, 12340815, h'fe80000000000000c0011001feef0000', 210000, > ["AN_ACP", 4, 1, "IKEv2" ], > [O_IPv6_LOCATOR, > h'fe80000000000000c0011001feef0000', UDP, 15000] > ["AN_ACP", 4, 1, "DTLS" ], > [O_IPv6_LOCATOR, > h'fe80000000000000c0011001feef0000', UDP, 17000] > ] > > NEW: > > [M_FLOOD, 12340815, h'fe80000000000000c0011001feef0000', 210000, > [["AN_ACP", 4, 1, "IKEv2" ], > [O_IPv6_LOCATOR, > h'fe80000000000000c0011001feef0000', IPPROTO_UDP, 15000]], > [["AN_ACP", 4, 1, "DTLS" ], > [O_IPv6_LOCATOR, > h'fe80000000000000c0011001feef0000', IPPROTO_UDP, 17000]] > ] > > Regards > Brian > From nobody Tue Jun 23 20:08:27 2020 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58DEB3A03ED for ; Tue, 23 Jun 2020 20:08:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.65 X-Spam-Level: X-Spam-Status: No, score=-1.65 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 E93oh3NnXl0s for ; Tue, 23 Jun 2020 20:08:23 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB4063A02C1 for ; Tue, 23 Jun 2020 20:08:22 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [131.188.34.52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 79735548068; Wed, 24 Jun 2020 05:08:17 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 6D53F440043; Wed, 24 Jun 2020 05:08:17 +0200 (CEST) Date: Wed, 24 Jun 2020 05:08:17 +0200 From: Toerless Eckert To: Benjamin Kaduk Cc: Brian E Carpenter , Michael Richardson , sean+ietf@sn3rd.com, Russ Housley , anima@ietf.org Message-ID: <20200624030817.GA47499@faui48f.informatik.uni-erlangen.de> References: <11428.1592266833@localhost> <20200617024412.GA11992@kduck.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200617024412.GA11992@kduck.mit.edu> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [Anima] rfc822Name use in Autonomic Control Plane document X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jun 2020 03:08:25 -0000 On Tue, Jun 16, 2020 at 07:44:12PM -0700, Benjamin Kaduk wrote: > > > We already had this debate. > > > Some time ago. The WG decided. > > With all due respect, this is not the sole decision of the ANIMA WG to > make. If WGs had such authority then why bother with cross-area review? I probably still don't understand process well enough for a WG chair, but given how i am just here as an author ;-): Cross-WG review during IETF review time is fine but it looks to me as if this point in Russ' review does not raise to the level of SEC AD review consideration. Aka: Russ can perfectly have an opinion about encoding preferences, and so can have other WG groups, but we need to use real technical arguments to make our choices. There are 15 bullet points justifying and explaining the choice but the feedback reveived does not take any of them into account. > > > Three or four years ago, I think. > > > > Yes, this is relitigating an issue that was resolved a long time ago in discussing Ben's DISCUSS: > > I'm not sure I understand why you use the word "resolved" here: > > > https://mailarchive.ietf.org/arch/msg/anima/lnZ-ykqas487qih86sYNVsUGbsc > > In this message, I say that "I still feel like this is not the best > architectural choice" and that I will provide a sketch of an alternative in > my (then-)forthcoming ballot position; that ballot position retains the > Discuss-level concern about rfc822Name usage along with the promised > alternative. Yes. I felt bad for you investing that much amount of work into an alternate proposal without having a discussion about this point. I do not remember if the crucial points why binary enoding was a inferior and ecossytem overhead choice was in the drafts you read or if i added/improved them in reply to your suggestion. Its now in sectin 6.1.2 explanation points 2.2, 2.3, 2.4, 2.5, 3.2, 3.3, 3.5. > > The explanation is at https://tools.ietf.org/html/draft-ietf-anima-autonomic-control-plane-24#page-26 > > I appreciate that the attempted justification is clearly written; however, > I do not find it compelling. Russ did not, either, and I just heard back > from Sean Turner a few days ago to confirm that he supports Russ's > comments. (There should be a few other editorial-ish comments that came > out of that review that are still pending.) It is still not a technical discussion to simply reply to a list of 8 points "this is not compelling". As i asked in the reply to Russ: Show me RFC text that would prohibit what we do. Show me security issues. SHow me any technical issues. Show me how this concern is anything more than an opinion that should not raise to the level of SEC AD DISCUSS block. > > I believe it is incorrect IETF process to rediscuss this point yet again. > > (I'm not sure if the "yet again" refers to "after the WG decided" or "after > the (alleged) resolution of my first Discuss point".) > > If you believe the technical answer is clear and that I am in error to > continue to hold my Discuss point for it, are there not also clear IETF > processes to follow? E.g., asking for the "Single Discuss" ballot procedure > described at https://www.ietf.org/standards/process/iesg-ballots/? I > believe I have mentioned this option to Toerless previously; my apologies > if that is not the case. While I'm willing to continue discussing the > topic and pull in additional PKIX experts to weigh in, there is perhaps > some consideration to matters of expediency. My understand is that i have have not seen a technical argument for the DISCUSS, but just a suggestion for encoding preference. > > > I sure wish that we could use something else. > > > But, CAs and CA software make that very difficult. > > > > > > Given that the era of publically anchored Enterprise CAs is dead, there are > > > only two ways an (Enterprise) ACP Registrar is going to occur. > > > > > > 1) by running a private CA. > > > Sure anything is possible if you are writing your own code, but > > > most will not be doing that. (I've supported otherName in my code for > > > other purposes, and it's not that difficult, but it's not trivial either) > > > My experience with COTS CA systems it that it's really hard to > > > get them to do it. Please prove me wrong. > > (Sadly, I have zero experience with COTS CA systems; I know too much about > openssl at this point and would presumably be writing my own, in this > position.) And ossification in the wide range of vendor specific software that ACP ha to deal with is one reason to not use an encoding choice that maximizes the amount of ecossytem changes. > > > The most popular Enterprise CA software is the Microsoft CA. > > > > > > 2) by using ACME to speak to a hosted CA. Maybe WebPKI, maybe not. > > > Either way, getting otherName supported is even harder, because > > > nobody else uses it. > > Is the concern the ACME protocol support or just getting the hosted CA to > cope with it? The former seems like something that we could make happen in > the IETF, and the latter seems to have high overlap with point (1). So far, there is no defined integration ACME and ANIMA. We did discuss this in a side meeting last year, but didn't continue, and i would not want to bring this discussion into the fold now because the whole premise of ACP was to be standalone private networks where the only reason to look into any type of public PKI is to help outsourcing TA work overhead, and that does not need to be a typical PKI anyhow. Not saying that i wouldn't like to see ANIMA to integrate with ACME, but thats not a concern for this document but at best for followup work. > > > If we can't depend upon otherName being filled in, then we have to look for > > > two things. That means more code paths (two more) to test, more test > > > vectors, and what exactly does an end point do when both are present, BUT > > > THEY DO NOT MATCH? So three more pages of text there. > > > Remember, that just rejecting the certificate means that we have to send out > > > a truck, which is what ACP aims to avoid, so that won't be popular. > > > And of course, there could also be bugs (maybe even CVEs) in the code that > > > tries to deal with the tie. > > To be honest, this argument feels like a stronger one to me than the bits > in the -24. I'm still not willing to accept into the RFC Series a document > that violates the rules set down by the specification for the technology > it's making use of, but the refocus on the "running code" aspect is > appreciated. "violates the rules set down by the specification for the technology" ?? I have not seen any supporting evidence for that. the rfc822name is a perfect rfc822name formatted string. Cheers Toerless From nobody Tue Jun 23 20:38:10 2020 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07F7D3A0769 for ; Tue, 23 Jun 2020 20:38:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.005 X-Spam-Level: X-Spam-Status: No, score=-1.005 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_IMAGE_ONLY_16=1.092, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 b0BgKEnIer-M for ; Tue, 23 Jun 2020 20:38:06 -0700 (PDT) Received: from mail-pf1-x442.google.com (mail-pf1-x442.google.com [IPv6:2607:f8b0:4864:20::442]) (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 412503A0766 for ; Tue, 23 Jun 2020 20:38:06 -0700 (PDT) Received: by mail-pf1-x442.google.com with SMTP id p11so478224pff.11 for ; Tue, 23 Jun 2020 20:38:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=W7cz/XrbKb+JDssUQxTXD7nKHZA3HAg5VLDuipbYSkg=; b=rsh+AJw5XadQ8goE1vgbRlwnD+wyU6JRVynz9AnpkDn1hAHbzDOTeV5GmpiWa0peo0 86HgsYs76H+bnLXEQVs16ZfyUist035THwHIDd0CJQT9wBouiWg1vAJBKBWKejPnDqbM Wyhf6AFK43F1ZvipaLkxL2I++QCThD6CsiiUuUT+DXH7TdCLkgJf5Dv28H5fzBKRLUQr CaVwEtHIFroSpiQuo9xFaXYxTit+4Y7flL1Krhbf/kgJyPk5PONB93/hI4PCncw3fm6a /zIRAVxKe70b+aw6OSPsZmRDUx3qSFP0UgSwtgWZGx1OIfHOx4jPKH5NvxCz967nQeWv BqNw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=W7cz/XrbKb+JDssUQxTXD7nKHZA3HAg5VLDuipbYSkg=; b=ULEaJUm/rKuBfGvXk/UbN+ePSScUnZ7Wnqiu49fgSP/nzA3pp4IBlTtL1eb52fQ8SQ 6VrO5+HounQeQ5C+rgBNBFk5RbrTDerSlc6Swlj8d55i12DVrvjXmEdp2uKLvNIULtLH joDiRMDB/nYyMjbRhxSej8HLmk4mahwB4bLX2+kbML+dgPRUfbnrB1zMkgapeKeKdZ3X f1/QIhBUcBYr8LenunFl3oJniQghDyRpCMtkpcz4F29aWQce4kbSCqeIpw4Vyrgtw7/X zFF0bVIlbyKzJv8h2lOlR+T1Y0C4mUtz2i/bZnPN1hLAKcqtjj/edIQlfHUihOBV2m+2 dIhg== X-Gm-Message-State: AOAM531c1i4x91gn+3Zse/XP5foIrNlhWAbYI/lf/4b5t17uE/LXBu89 QCrqxOyRblfs9XMKYssSj66q2E1j X-Google-Smtp-Source: ABdhPJx64t1FuEyRhLYmPMbkzFbRidJjvQrRAxB7zZw2QVxrDvJXMbrUb72vvRTicyGSWCmcaa1+nQ== X-Received: by 2002:a63:360c:: with SMTP id d12mr12062145pga.414.1592969885674; Tue, 23 Jun 2020 20:38:05 -0700 (PDT) Received: from [192.168.178.30] ([118.149.66.243]) by smtp.gmail.com with ESMTPSA id s194sm15363022pgs.24.2020.06.23.20.38.01 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 23 Jun 2020 20:38:04 -0700 (PDT) To: Toerless Eckert , Benjamin Kaduk Cc: Michael Richardson , sean+ietf@sn3rd.com, Russ Housley , anima@ietf.org, rfcSELF+fd89b714F3db00000200000064000000+area51.research@acp.example.com References: <11428.1592266833@localhost> <20200617024412.GA11992@kduck.mit.edu> <20200624030817.GA47499@faui48f.informatik.uni-erlangen.de> From: Brian E Carpenter Message-ID: <4af6d6e0-6d1c-c06d-a5a2-85a870b76085@gmail.com> Date: Wed, 24 Jun 2020 15:37:58 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <20200624030817.GA47499@faui48f.informatik.uni-erlangen.de> Content-Type: multipart/mixed; boundary="------------600AE1684B4F1F31AD8178E3" Content-Language: en-US Archived-At: Subject: Re: [Anima] rfc822Name use in Autonomic Control Plane document X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jun 2020 03:38:08 -0000 This is a multi-part message in MIME format. --------------600AE1684B4F1F31AD8178E3 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit On 24-Jun-20 15:08, Toerless Eckert wrote: > On Tue, Jun 16, 2020 at 07:44:12PM -0700, Benjamin Kaduk wrote: >>>> We already had this debate. .... > > "violates the rules set down by the specification for the technology" > > ?? > > I have not seen any supporting evidence for that. the rfc822name is > a perfect rfc822name formatted string. Well, more than that. It's a perfectly valid email address, accepted by conformant SMTP servers. Yes, it does lead to a delivery failure, but it doesn't just *look like* an email address, it *is* an email address. Why is it misuse of rfc822name to express a valid email address that has no mailbox behind it? Is this in any way a security vulnerability? What does it break? I still don't see how this qualifies as a DISCUSS issue. I do see that it is unaesthetic. I do see how it meets several of the DISCUSS non-criteria at https://www.ietf.org/about/groups/iesg/statements/iesg-discuss-criteria/#stand-undisc Brian --------------600AE1684B4F1F31AD8178E3 Content-Type: message/rfc822; name="Delivery Status Notification (Failure).eml" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Delivery Status Notification (Failure).eml" X-Account-Key: account7 X-Mozilla-Keys: Delivered-To: brian.e.carpenter@gmail.com Received: by 2002:aa7:d74b:0:0:0:0:0 with SMTP id a11csp4320950eds; Tue, 23 Jun 2020 13:34:45 -0700 (PDT) X-Received: by 2002:a17:902:bd46:: with SMTP id b6mr4063234plx.287.1592944485633; Tue, 23 Jun 2020 13:34:45 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1592944485; cv=none; d=google.com; s=arc-20160816; b=AOYfaWNAm+kkPIp8ZDtvw4UhSBLKBTKznMoeYhGBF/sHf/rIFVRm9HHF6pwVo+FGRq AEfz5R27D+drCMTyPmhQ86zUqpw6H0YgbJZkS0EVuaBIl10Zui8O1XuyQCS+SRJ0K1r+ OS/cmGmunfWFxlWIl4ZUEGvHlJKmpIM+Ges81311Jxa0aYwC9ShMze+HQByQ0HVDQ+zp noi+915A7HQ/CL3BrqKcI8vxh8u7vYHOddfIYwXitOOatKF3IHTXFsPbLIruIBqCgQkP WZa9JciqpT2BV27G3FpQ/ofC5Id3iz971yKanL6L7Ntc+DQAEjI2aY2/k//+IV4pdtZe 25mQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=in-reply-to:references:subject:from:date:message-id:auto-submitted :to:dkim-signature; bh=JYz2kSju82otwyoDwa3u/RsXwB+9Hekd/XLzkptAmrU=; b=xzjN9Bq58YjiznuowYZPgfVP6ZC6H6iG6NfzfZNcpMO27CQB4TqKvjsNm0Dj+FXkCn W05ZShvj2XZDOkSKcElaR6lun3jFTuxZkm9VhFHrhWeWjBrXmhy6wCC7nJTDxZzjG5lD UeoDtsqHDwyyZfpZvhuOboPRBQMzeE9jo37vN/SnHur5LGw6colmwuTJnOD8eYb1OS7e AczSNIL4GkgYkoyX6sL16sGVuACrM/v9tQg9rvhhVt3dzeNuRIKOee6ORKuvIcMwEPVL GunuwH4+xjqzZL0vU1KI2ddBTd8GFewJQc1ItopIAushYtIClsntSD/0WuqFUmOrptVc GxPA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@googlemail.com header.s=20161025 header.b=HtfEQ6Qt; spf=pass (google.com: best guess record for domain of postmaster@mail-sor-f69.google.com designates 209.85.220.69 as permitted sender) smtp.helo=mail-sor-f69.google.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=googlemail.com Return-Path: <> Received: from mail-sor-f69.google.com (mail-sor-f69.google.com. [209.85.220.69]) by mx.google.com with SMTPS id k22sor22833842pfg.28.2020.06.23.13.34.45 for (Google Transport Security); Tue, 23 Jun 2020 13:34:45 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of postmaster@mail-sor-f69.google.com designates 209.85.220.69 as permitted sender) client-ip=209.85.220.69; Authentication-Results: mx.google.com; dkim=pass header.i=@googlemail.com header.s=20161025 header.b=HtfEQ6Qt; spf=pass (google.com: best guess record for domain of postmaster@mail-sor-f69.google.com designates 209.85.220.69 as permitted sender) smtp.helo=mail-sor-f69.google.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=googlemail.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20161025; h=to:auto-submitted:message-id:date:from:subject:references :in-reply-to; bh=JYz2kSju82otwyoDwa3u/RsXwB+9Hekd/XLzkptAmrU=; b=HtfEQ6QtPxS2EYZtZfrGpI6UE7kvFz3p8wgmozQzR1AUu8utJg7+u00SNIkxpljYU0 dfYHg1CcrKySfYRx5G5yrw414+PwDDp8+99PqSf1/+hg5yoHk+kTGcYKbluaev2690Bh jXu/5tMOJfdoxJ0e88D6x6+Q2oIJguyxNJ4biqzmLxuQAPCfYCAojtxWs2osoKw1s4Pw 9qQlONdL/2/jQFxIZuqA5NfAFMDP6+G+sf5uCJAwUjnfXga3FYWq3g0wibOBaGOPk6bi ZLrj9QaKiFYlNtlydDh/ezMmHbM31nyMwJ2pgUMJ6TviQO5yRzjGc+2PeBpSRQ4NJIU+ Dk0Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:auto-submitted:message-id:date:from:subject :references:in-reply-to; bh=JYz2kSju82otwyoDwa3u/RsXwB+9Hekd/XLzkptAmrU=; b=aDP8xKKoWYP2gQC+x9UQAgWAhVQjv7pezzGHt58oRHE7Pw1yJ8sLTOyDmG4FZWxHKZ 8IiETZbQtoT3lU6Q87CEa/3d67BYOlIRbI/417tYjqKkFiydKjsIHG47ne9NuVeGsRmV CFhcS4Q2ou6EhvchP5Z+ehatf9wDVBvHs0AR5iMygZajYKK9ES1yrDWdmz4iNuO2/Dlh I3oraPpIq+zvxdcmFt+LeuasnzJwafBv8/LxVxVxnzAyzlu1XUkPM9dIXgLkuH/c7oQv PLJcnwpGKgY753P2BvKnQAfBChepbDDVLVjNz/USTsicyPbf0KArSO5l8GTCUlDsfL9H JIVA== X-Gm-Message-State: AOAM530jkeBDxrzzE0hsMmnn5QjHCNr+/K9M/HEH3J+liGHQMogdoQUK sM3kNbOWvdbuKp+EJhdJrOb2QBRLU39uu49DF8gTfg== X-Google-Smtp-Source: ABdhPJw79ZCQZctEwibuoFfjdV4qG7D6fkuasX1Ap+0tSd4xT/8IonAPD/EErdfj+6SMZMWgmktPJIeNe7/Fy9PR3PsKT9QJj1U6xFY= X-Received: by 2002:a05:6a00:7c6:: with SMTP id n6mr24825642pfu.120.1592944485357; Tue, 23 Jun 2020 13:34:45 -0700 (PDT) Content-Type: multipart/report; boundary="000000000000324a1305a8c64abf"; report-type=delivery-status To: brian.e.carpenter@gmail.com Received: by 2002:a05:6a00:7c6:: with SMTP id n6mr22898911pfu.120; Tue, 23 Jun 2020 13:34:45 -0700 (PDT) Return-Path: <> Auto-Submitted: auto-replied Message-ID: <5ef26765.1c69fb81.7905c.9089.GMR@mx.google.com> Date: Tue, 23 Jun 2020 13:34:45 -0700 (PDT) From: Mail Delivery Subsystem Subject: Delivery Status Notification (Failure) References: <6981a76f-76f1-e9b2-319d-473c7a4bc847@verizon.net> <6c4e402f-cce6-daff-aa16-6159340f0802@gmail.com> In-Reply-To: <6c4e402f-cce6-daff-aa16-6159340f0802@gmail.com> X-Failed-Recipients: rfcSELF+fd89b714F3db00000200000064000000+area51.research@acp.example.com --000000000000324a1305a8c64abf Content-Type: multipart/related; boundary="0000000000003255b705a8c64acf" --0000000000003255b705a8c64acf Content-Type: multipart/alternative; boundary="0000000000003255c205a8c64ad0" --0000000000003255c205a8c64ad0 Content-Type: text/plain; charset="UTF-8" ** Address not found ** Your message wasn't delivered to rfcSELF+fd89b714F3db00000200000064000000+area51.research@acp.example.com because the domain acp.example.com couldn't be found. Check for typos or unnecessary spaces and try again. The response was: DNS Error: 111832 DNS type 'mx' lookup of acp.example.com responded with code NXDOMAIN Domain name not found: acp.example.com --0000000000003255c205a8c64ad0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
=3D"Error

Address not found

Your message wasn't delivered to rfcSELF+fd89b714F3db00000200000064000000+area51.research@acp.examp= le.com because the domain acp.example.com couldn't be found. Check = for typos or unnecessary spaces and try again.
The response was:

DNS Error: 111832 DNS type 'mx' lookup of acp.example.com responded= with code NXDOMAIN Domain name not found: acp.example.com

--0000000000003255c205a8c64ad0-- --0000000000003255b705a8c64acf Content-Type: image/png; name="icon.png" Content-Disposition: attachment; filename="icon.png" Content-Transfer-Encoding: base64 Content-ID: iVBORw0KGgoAAAANSUhEUgAAAJAAAACQCAYAAADnRuK4AAAACXBIWXMAABYlAAAWJQFJUiTwAAAA GXRFWHRTb2Z0d2FyZQBBZG9iZSBJbWFnZVJlYWR5ccllPAAABTdJREFUeNrsnD9sFEcUh5+PRMqZ yA0SPhAUQAQFUkyTgiBASARo6QApqVIkfdxGFJFSgGhJAUIiBaQB0ZIOKVCkwUgURjIg2fxL4kS+ YDvkbC/388bi8N16Z4/d7J/5PsniuD3fyePP772ZeTsDQRAYQL/UGAJAIEAgQCBAIAAEAgQCBAIE AkAgyJT3Mv+Eq7vYK8mTE+MDRCAghQECAeRQA5V2ZOpmg5vDx3NPzRbmGRMEcmTrEbNNB8zWfRD+ f/Efs2e3zCZvMjaksBg27TfbcuSNPEKP9ZyuAQKtHX2O9ncNgWC57umMPKvRNb0GEKgnLoUyxTQC rcns0/6uIRAs8/hGf9cQCJZpTpjdO2f25/03z+mxntM1eLtsZAgiUtX4JcaBCAQIBAgECARQ8CJa G5jab4J4pm4WZmO3OALVh802fIwcLkyPkcKAGggAgQCBAIEAgQCBABAIEAjKA/1AnahhbO5FdOOY VsrrDbPBYcYKgf5D2wLaV3p+22xh1u17tO3S+DTcvxvagUDeivPgx/a/95J/73w7Sj26Hn4pKo2M ehuV/KyBJM6d0f7k6RKx/R63vvL2tmf/ItDdM2ZTP6f7nkp9Y2fDx1v9akmpIU+KSCLVUghUQfSL zVKeTklbLxGoctw/nzC5rw8L5KRNbkpnKq6pgSqEClzNnFzY+XnYWrt6VpVk1vbwWvg+RKCKMOUw Q1LEOXA+/MX3mpJvGDHb265xtnzmFoUK1HaKQGlMtePYM+q2KKjXuaS1NJYIEKgI8jhEgqHt4cqy Ky53j3hyHz2bqSLp2o2LbJ7MxKovkGqXteoWpaOk96O9/yF/dF7NwlS36AuIQIBA5celQK4PIxBE 4LLzrtoLgaALdSy6CJRkWQCBPGLsTHznomZ9nszUECgJ2ml3WWHe+QVFNPSQx6UdZNtxr9pbEShN eTTz8mQXHoHSlke7+Z+c9m6VGoHSkEfs/trLW3wQKApN1V3lGfnGu2Z6BFoLtYCs3GWBPAiUCLVh /HoaeRCoT9R873KLM/IgUBfapnCpe5AHgXry4pf412ihEHkQqCdxd5VqrcezhUIESsJMTJ+Pdthp Z0WgyNlXXPHc2Mc4IVAELl2Gnh8mhUDvCkfbIVAkcbf/aOoO3fMKhqAD3frTa4quwpn0hUDOkQhI YYBAgECAQAAU0QlYObl+5Ug8NcprZkZxjUCxRPVA6zmtEXHCBykskrhjgHXN09PoEcgFl4M4H11j nBAoApcj6ZoPGScEAgTKApcDoTw5sgWB+sGlz1n90IBAPdE6j1o21PfcC11jLagL1oFWRyGlKU3p OxcSJQ7NZAjkhHp/uG2HFAYIBAgECASAQIBAgECAQAAIBOkxEARBtp9wdVfAMOfIifEBIhCQwgCB ABAI0oV2jhxZ+nfBatuPZfgBCy0Eqqo8c01b+uu51XZvzOgDWoHNTGR+pCwpLEd5svuAZXlO2uEr PyEQ8hRWHgRCHmqg0sjTnLalv6crJQ8C/U8stqNO0I4+VZOHFIY8COS1PGL2ybd5yUMKK7s8zYmL dujyd3n+nESgcsvzZd4/KwIhDwIhT35QA6UyE1qyxZnfvJMHgdKS549JC1qvvJOHFIY8CFR5eV5O XimqPAhUdHnmfx+zgxdOFXkoqIGKKs/cswnb/8Oeog8HEai48nxUhiFBIORBIOShBioskkbySCLk IQIhDwIhj28p7FApR6b1qlEbHGpkO/rr6215vi/zH1r2x7tApSGFAQIBAgECAQIBIBAgECAQIBBA LK8FGADCTxYrr+EVJgAAAABJRU5ErkJggg== --0000000000003255b705a8c64acf-- --000000000000324a1305a8c64abf Content-Type: message/delivery-status Reporting-MTA: dns; googlemail.com Received-From-MTA: dns; brian.e.carpenter@gmail.com Arrival-Date: Tue, 23 Jun 2020 13:34:44 -0700 (PDT) X-Original-Message-ID: <6c4e402f-cce6-daff-aa16-6159340f0802@gmail.com> Final-Recipient: rfc822; rfcSELF+fd89b714F3db00000200000064000000+area51.research@acp.example.com Action: failed Status: 4.0.0 Diagnostic-Code: smtp; DNS Error: 111832 DNS type 'mx' lookup of acp.example.com responded with code NXDOMAIN Domain name not found: acp.example.com Last-Attempt-Date: Tue, 23 Jun 2020 13:34:45 -0700 (PDT) --000000000000324a1305a8c64abf Content-Type: message/rfc822 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=uLh+qmvNOTct6cVDYJKdzoAAIRsbY718OAgRR1d6qFM=; b=FBh2pKy8j/aHj6Ti1bU6fkBpqcqxBRprwqejcLgFReXvYR+kNidI8ALH+bUz01MbhF aJglfWynqL55NFNtdUC7oBPWEgPXp3N26M8/Uk2yc5BermgXdLsNfdfFtRg5IxAoO1bu cMhBwS/weEsZvErbMhOBStz6IVw++Xsjls70gsK+gkXXWeaPNBLi/ZlOqydEjb4QaYza WX9xxA78k/SQNodmiN/KDTFvZ0KgLSPTaF6hEcfVNSlF5kcq2u9KAjX+cMU/3K+/vLbF wAccW64hYdCDHIw9cTFyenKPRdg6GCiiD9oBbfvUcczKHc47+g4izj73Qgb3maVuzk8E PAzg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=uLh+qmvNOTct6cVDYJKdzoAAIRsbY718OAgRR1d6qFM=; b=gAYKcIS0ml5WBr9Sjluj4PGZ4D7wana3MW1bsa3/VET1rg9bOZXuNUc2LZsuMEePfk VwIgEkmKnhEivIte/CdWhOQlchFa3QfLOqr962yvwwUoni5h6jguRfQJWYkdXEvQe9r3 Cf2GDso3iqCLp5XNYejlICoJo3FoQMGkDWGP+8udLci47u3RqZu0ZpoyHqo/OFl//VfH 5do/NZ07iunEX9Dh51TGevjvaiM1nJx3XOMDba/9rcToBjp3NYi6CQN/z5Lzt9AXPlFA EWPlE2uygPIPAixa2yNbz/1RRPpyxseltG4SxIYbZLdy0pvyy2dENvLcPDubwUUcUiOL yy/g== X-Gm-Message-State: AOAM532KhZDKgId73GhIkVoBp0SbBvpxU+gTRvMA9gsn/SwiPIDKToZ0 eEIMqDYpmpX5lJ7a+ASiAh+PEPFw X-Google-Smtp-Source: ABdhPJy/K+lHLBDdZsGFZTy2EzVdKHz8hkp167UHLD62335lSWvfu3kxf2vAZFqKcxRACbuPETut4w== X-Received: by 2002:a05:6a00:7c6:: with SMTP id n6mr24825616pfu.120.1592944484818; Tue, 23 Jun 2020 13:34:44 -0700 (PDT) Return-Path: Received: from [192.168.178.30] ([118.149.66.243]) by smtp.gmail.com with ESMTPSA id k7sm17981423pfp.84.2020.06.23.13.34.40 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 23 Jun 2020 13:34:44 -0700 (PDT) Subject: Re: [Anima] representing ACP info in X.509 certs To: Stephen Kent , "Owen Friel (ofriel)" , Eric Rescorla Cc: Anima WG , rfcSELF+fd89b714F3db00000200000064000000+area51.research@acp.example.com References: <6981a76f-76f1-e9b2-319d-473c7a4bc847@verizon.net> From: Brian E Carpenter Message-ID: <6c4e402f-cce6-daff-aa16-6159340f0802@gmail.com> Date: Wed, 24 Jun 2020 08:34:38 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <6981a76f-76f1-e9b2-319d-473c7a4bc847@verizon.net> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Regards Brian Carpenter On 24-Jun-20 03:46, Stephen Kent wrote: > Owen, >> >> Being completely pedantic about the RFC5280 text, nowhere in the text = does it say that rfc822name cannot be used for anything but email address= =2E It does state multiple times that an email address must be represente= d as an rfc822name, but places no explicit restrictions on what an rfc822= name may represent. The text as is does not explicitly preclude use of rf= c822name for ACP. This may be the widespread understanding of what RFC528= 0 means, but its not strictly what it says=E2=80=A6 >> > Common sense argues against putting something other than an e-mail addr= ess in the rfc822namem attribute. >=20 > I expect ADs to use common sense, as well as careful reading of prior R= FCs, when making decisions. Indeed, but that cuts both ways, since running code is our goal. No parse= r is in a position to say that rfcSELF+fd89b714F3db00000200000064000000+a= rea51.research@acp.example.com isn't an email address. Brian >=20 > Steve >=20 >=20 > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima >=20 --000000000000324a1305a8c64abf-- --------------600AE1684B4F1F31AD8178E3-- From nobody Wed Jun 24 00:05:29 2020 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B44E3A0C1F for ; Wed, 24 Jun 2020 00:05:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.6 X-Spam-Level: X-Spam-Status: No, score=-9.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 GtpGVwrk0SuY for ; Wed, 24 Jun 2020 00:05:18 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 063F73A0CE5 for ; Wed, 24 Jun 2020 00:05:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9416; q=dns/txt; s=iport; t=1592982306; x=1594191906; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=59iBREKEQHRLxX1+R8mfCLNUDzwBziuyOMCub4hHD7o=; b=NcD2cpejb9zGPAxnPJvJjpMUhM0Zu8zhhatsK6M/Kk7vEThSHkLq3OYT x3idqSEbqt/Sctj9Sft6XidkhyfdA5CJbV1F0kWPpvR1lRFpA6aF63xwR g4yeFDGfOR/UquSb9QURLEVtZM+J90uf8nSxWj+JxDpJx0jRRZsHNUxOK U=; X-Files: signature.asc : 488 X-IPAS-Result: =?us-ascii?q?A0B6AAA8+vJe/xbLJq1mGgEBAQEBAQEBAQEDAQEBARIBA?= =?us-ascii?q?QEBAgIBAQEBggoCg2sBIBIshCSJAYgRk22GLIFoBAcBAQEJAwEBLwQBAYRHA?= =?us-ascii?q?oIUJTgTAgMBAQEDAgMBAQEBBQEBAQIBBgRthWdCARABhR4BAQEBAgEjVgULC?= =?us-ascii?q?xgnAwICRhEGEx+DBwGCXCC2R3aBMoVRhQUQgTgBgVKIRYJlggCBOByCHy4+g?= =?us-ascii?q?lwEgSgBEQIBVoJeM4ItBI9KiUSBEZpFgmSDA4EmlQUDHZENjXSsM4NPAgQGB?= =?us-ascii?q?QIVgWoiZnAzGggbFWUBgj4+EhkNjioXjiY/AzACNQIGAQcBAQMJhiKKfQEB?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.75,274,1589241600"; d="asc'?scan'208,217";a="24959434" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 24 Jun 2020 07:05:01 +0000 Received: from [10.61.241.223] ([10.61.241.223]) by aer-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id 05O750VR029763 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 24 Jun 2020 07:05:01 GMT From: Eliot Lear Message-Id: <9AF4DB48-EAB5-4BFB-8FF1-E55EF0F59140@cisco.com> Content-Type: multipart/signed; boundary="Apple-Mail=_12948B6D-8173-4928-94E2-7073EB0FC089"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Wed, 24 Jun 2020 09:04:59 +0200 In-Reply-To: <15951.1592960140@localhost> Cc: Anima WG , Eric Rescorla , Stephen Kent To: Michael Richardson References: <6981a76f-76f1-e9b2-319d-473c7a4bc847@verizon.net> <6c4e402f-cce6-daff-aa16-6159340f0802@gmail.com> <9c09debe-3463-a574-46cf-cee86a2c68af@verizon.net> <15951.1592960140@localhost> X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Outbound-SMTP-Client: 10.61.241.223, [10.61.241.223] X-Outbound-Node: aer-core-2.cisco.com Archived-At: Subject: Re: [Anima] representing ACP info in X.509 certs X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jun 2020 07:05:27 -0000 --Apple-Mail=_12948B6D-8173-4928-94E2-7073EB0FC089 Content-Type: multipart/alternative; boundary="Apple-Mail=_EC36AE89-45E1-473E-A04A-A761AD059EFB" --Apple-Mail=_EC36AE89-45E1-473E-A04A-A761AD059EFB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi there, > On 24 Jun 2020, at 02:55, Michael Richardson = wrote: >=20 > Signed PGP part >=20 > Stephen Kent wrote: >> The simple answer is that when, in the past, developers have chosen = to abuse >> the semantics of subject name fields in certs, the result shave been = VERY >> long lasting, and embarrassing. Long ago, Netscape chose to shove a = DNS name >> into the DN common name filed because it was an easy fix for their >> problem. As a result, we still have browsers and CAs that misuse that >> field. At least that egregious behavior was not the result of an IETF >> WG. Let's not screw this up in the name of expediency! >=20 > Yes, I remember that. > Why do you think Netscape did that? > What should they have done instead? >=20 Going further, sometimes expedients are appropriate. With the benefit of hindsight of nearly 30 years of experience, = there=E2=80=99s a lot that Netscape did in its first years that we = wouldn=E2=80=99t do today, but had they not done those things, field = delivery could have been delayed by years, probably the worst example = being the User-Agent header. We can say, =E2=80=9Cthey never should = have done that=E2=80=9D, but it was what people deemed necessary and = expedient for a number of reasons, not least of which was product = differentiation and market maturity. Here we have a situation where the public CA offerings have been made = quite brittle. The ability to add either an otherName or a URI requires = CAs to modify their code and create alternative roots. We all know = that won=E2=80=99t happen, and so that leads to whether an expedient is = appropriate. Worse, as I have demonstrated, submitting otherName to = public CAs produces garbage in certs (very bad, but there it is). They = not only aren=E2=80=99t ready, but they may have potential exploits = lingering. Is an expedient appropriate? With ACP it=E2=80=99s clear they are overloading semantics of an = rfc822name, and from an application standpoint we don=E2=80=99t like = that because it is possible that different subsystems may have different = uncoordinated allocation methods. That is- someone may be able to nab = an email address via the mail subsystem a la = rfcSELF+fd89b714F3db00000200000064000000+area51.research@acp.example.com = , get a cert for that address, and masquerade as an AN or an AN = could start sending email as a user that has such an address. Let=E2=80=99= s agree that the latter is so minimal a risk as to not warrant further = discussion. It=E2=80=99s only the former that=E2=80=99s really of = concern. That can be mitigated through operational guidance, a=E2=80=99la= =E2=80=9Cdon=E2=80=99t allow email addresses in your domain that begin = with rfcSELF+=E2=80=9D. It=E2=80=99s not perfect. That=E2=80=99s the nature of an expedient. = But it=E2=80=99s probably Good Enough for now. For the eventuality that = another name could be used over time, it=E2=80=99s probably worth = getting an OID and using otherName where possible, but we shouldn=E2=80=99= t hold this work up over a highly theoretical attack. Eliot --Apple-Mail=_EC36AE89-45E1-473E-A04A-A761AD059EFB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = there,

On 24 Jun 2020, at 02:55, Michael Richardson = <mcr+ietf@sandelman.ca> wrote:

Signed PGP part

Stephen Kent <stkent=3D40verizon.net@dmarc.ietf.org> wrote:
The simple answer is = that when, in the past, developers have chosen to abuse
the = semantics of subject name fields in certs, the result shave been VERY
long lasting, and embarrassing. Long ago, Netscape chose to = shove a DNS name
into the DN common name filed because it = was an easy fix for their
problem. As a result, we still = have browsers and CAs that misuse that
field. At least = that egregious behavior was not the result of an IETF
WG. = Let's not screw this up in the name of expediency!

Yes, I remember that.
Why do you think Netscape did that?
What should = they have done instead?


Going further, sometimes expedients are appropriate.

With the benefit of hindsight of nearly 30 years = of experience, there=E2=80=99s a lot that Netscape did in its first = years that we wouldn=E2=80=99t do today, but had they not done those = things, field delivery could have been delayed by years, probably the = worst example being the User-Agent header.  We can say, =E2=80=9Cthey= never should have done that=E2=80=9D, but it was what people deemed = necessary and expedient for a number of reasons, not least of which was = product differentiation and market maturity.

Here we have a situation where the public CA = offerings have been made quite brittle. The ability to add either an = otherName or a URI requires CAs to modify their code and create = alternative roots.    We all know that won=E2=80=99t happen, = and so that leads to whether an expedient is appropriate.  Worse, = as I have demonstrated, submitting otherName to public CAs produces = garbage in certs (very bad, but there it is).  They not only = aren=E2=80=99t ready, but they may have potential exploits = lingering.

Is an expedient = appropriate?

With ACP it=E2=80=99s = clear they are overloading semantics of an rfc822name, and from an = application standpoint we don=E2=80=99t like that because it is possible = that different subsystems may have different uncoordinated allocation = methods.  That is- someone may be able to nab an email address via = the mail subsystem a la rfcSELF+fd89b714F3db00000200000064000000+area51.research@acp.ex= ample.com, get a cert for that address, and masquerade as an AN = or an AN could start sending email as a user that has such an address. =  Let=E2=80=99s agree that the latter is so minimal a risk as to not = warrant further discussion.  It=E2=80=99s only the former that=E2=80=99= s really of concern.  That can be mitigated through operational = guidance, a=E2=80=99la =E2=80=9Cdon=E2=80=99t allow email addresses = in your domain that begin with rfcSELF+=E2=80=9D.

It=E2=80=99s not perfect. =  That=E2=80=99s the nature of an expedient.  But it=E2=80=99s = probably Good Enough for now.  For the eventuality that another = name could be used over time, it=E2=80=99s probably worth getting an OID = and using otherName where possible, but we shouldn=E2=80=99t hold this = work up over a highly theoretical attack.

Eliot
= --Apple-Mail=_EC36AE89-45E1-473E-A04A-A761AD059EFB-- --Apple-Mail=_12948B6D-8173-4928-94E2-7073EB0FC089 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAl7y+xsACgkQh7ZrRtnS ejPuOwf9FhfbSeKW4Q70cAmZENDKyr5Tc1HL/O3YAR657XAdb4Ug4Kq4bMcWucgl 7aZgTck0HgvyK4mALYyx1aNHu0s3HURjzgbo3fb+vOO0962+TyfFOPzQtJ/c3m6O CJjLXQzv2fYE42MPY1l4+dzoyQaFt9R/FABrXLG1Vu2KLvnL+yAWTM+kOzT258tD 80UW6+DT/iXKVjjm8ejmV1ajy7uocYQUy/Mho4uH62nIJkR8eEVHt/tNLuRjc6x5 RusqrDiJSz8kcaPkeOCBCLOhGZrn5NJ/pyymCdO4oCl1IH+r5ki1aiwGfKcNSgMz 9nNGhX0mKxdDO+i4GtchN54RwHCFow== =ZQIa -----END PGP SIGNATURE----- --Apple-Mail=_12948B6D-8173-4928-94E2-7073EB0FC089-- From nobody Wed Jun 24 00:29:57 2020 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E7EE3A0C09; Wed, 24 Jun 2020 00:29:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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 2YbrVH0QJOzU; Wed, 24 Jun 2020 00:29:54 -0700 (PDT) Received: from gw-eagle2.siemens.com (gw-eagle2.siemens.com [194.138.20.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75F6E3A0C05; Wed, 24 Jun 2020 00:29:54 -0700 (PDT) Received: from mail2.dc4ca.siemens.de (mail2.dc4ca.siemens.de [139.25.224.94]) by gw-eagle2.siemens.com (Postfix) with ESMTPS id A8A58468164; Wed, 24 Jun 2020 09:29:52 +0200 (CEST) Received: from DEMCHDC89XA.ad011.siemens.net (demchdc89xa.ad011.siemens.net [139.25.226.103]) by mail2.dc4ca.siemens.de (Postfix) with ESMTPS id 399AB14A011C4; Wed, 24 Jun 2020 09:29:52 +0200 (CEST) Received: from DEMCHDC8A1A.ad011.siemens.net (139.25.226.107) by DEMCHDC89XA.ad011.siemens.net (139.25.226.103) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1979.3; Wed, 24 Jun 2020 09:29:52 +0200 Received: from DEMCHDC8A1A.ad011.siemens.net ([139.25.226.107]) by DEMCHDC8A1A.ad011.siemens.net ([139.25.226.107]) with mapi id 15.01.1979.003; Wed, 24 Jun 2020 09:29:52 +0200 From: "Fries, Steffen" To: Brian E Carpenter , Sheng Jiang CC: "anima-chairs@ietf.org" , "Rob Wilton (rwilton)" , Anima WG Thread-Topic: [Anima] Adoption call for draft-fries-anima-brski-async-enroll-03, ends July 1st 2020 Thread-Index: AQHWSNPjGviRiuVBQ0KLZrhAPdEOpKjl8LEw Date: Wed, 24 Jun 2020 07:29:51 +0000 Message-ID: <9514670387474a47b6fe6cc9c4ce38f7@siemens.com> References: In-Reply-To: Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [139.21.146.184] x-tm-snts-smtp: 7FF8C326293CBF193854D0B9C3866045E020F30916A7E425DC3FB595BC78DF142000:8 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Anima] Adoption call for draft-fries-anima-brski-async-enroll-03, ends July 1st 2020 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jun 2020 07:29:56 -0000 SGkgQnJpYW4sDQoNClRoYW5rIHlvdSBmb3IgdGhlIHN1cHBvcnQuIFBvaW50cyB0YWtlbi4gSSB3 aWxsIGNvbnNpZGVyIHRoZW0gaW4gdGhlIG5leHQgdXBkYXRlLg0KDQpCZXN0IHJlZ2FyZHMNClN0 ZWZmZW4NCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBBbmltYSA8YW5p bWEtYm91bmNlc0BpZXRmLm9yZz4gT24gQmVoYWxmIE9mIEJyaWFuIEUgQ2FycGVudGVyDQo+IFNl bnQ6IE1vbnRhZywgMjIuIEp1bmkgMjAyMCAyMjozMA0KPiBUbzogU2hlbmcgSmlhbmcgPGppYW5n c2hlbmdAaHVhd2VpLmNvbT4NCj4gQ2M6IGFuaW1hLWNoYWlyc0BpZXRmLm9yZzsgUm9iIFdpbHRv biAocndpbHRvbikgPHJ3aWx0b25AY2lzY28uY29tPjsgQW5pbWENCj4gV0cgPGFuaW1hQGlldGYu b3JnPg0KPiBTdWJqZWN0OiBSZTogW0FuaW1hXSBBZG9wdGlvbiBjYWxsIGZvciBkcmFmdC1mcmll cy1hbmltYS1icnNraS1hc3luYy1lbnJvbGwtDQo+IDAzLCBlbmRzIEp1bHkgMXN0IDIwMjANCj4g DQo+IEhpLA0KPiANCj4gSSBiZWxpZXZlIHRoaXMgd29yayBmaWxscyBhbiBpbXBvcnRhbnQgZ2Fw IGluIEJSU0tJIHNjZW5hcmlvcyBzbyBpdCBzaG91bGQgYmUNCj4gYWRvcHRlZC4NCj4gDQo+IEEg Y291cGxlIG9mIG5pdHMgd2hpbGUgSSdtIGhlcmU6DQo+IA0KPiAxKSBJIHRoaW5rIHRoZSBzZWN0 aW9uICJIaXN0b3J5IG9mIGNoYW5nZXMiIHNob3VsZCBiZSBhbiBBcHBlbmRpeCwgc2luY2UgaXQg aXMNCj4gZGlzdHJhY3RpbmcgdG8gdGhlIHJlYWRlciBhdCBwcmVzZW50LiBBbHNvIGl0IHNob3Vs ZCBiZSBtYXJrZWQgIltSRkMgRWRpdG9yOg0KPiBwbGVhc2UgZGVsZXRlXSIuDQo+IA0KPiAyKSBU aGUgQWJzdHJhY3QgaXMgdG9vIGxvbmcuIEkgdGhpbmsgZXZlcnl0aGluZyBmcm9tICJJbiB0aGUg Y29udGV4dCBvZiAuLi4iDQo+IGJlbG9uZ3MgaW4gdGhlIEludHJvZHVjdGlvbi4NCj4gDQo+IFJl Z2FyZHMNCj4gICAgQnJpYW4gQ2FycGVudGVyDQo+IA0KPiA+PiBPbiAxOCBKdW4gMjAyMCwgYXQg MTE6MjcsIFNoZW5nIEppYW5nIDxqaWFuZ3NoZW5nQGh1YXdlaS5jb20NCj4gPG1haWx0bzpqaWFu Z3NoZW5nQGh1YXdlaS5jb20+PiB3cm90ZToNCj4gPj4NCj4gPj4gSGksIEFOSU1BZXIsDQo+ID4+ DQo+ID4+IFRoaXMgbWVzc2FnZSBzdGFydHMgYSB0d28td2VlayBhZG9wdGlvbiBjYWxsLCBpdCBl bmRzIG9uIEp1bHkgMXN0LCAyMDIwLg0KPiA+Pg0KPiA+PiBkcmFmdC1mcmllcy1hbmltYS1icnNr aS1hc3luYy1lbnJvbGwtMDMgaGFzIGJlZW4gcHJlc2VudGVkIHRvIHRoZSBXRyBmb3INCj4gYSBs b25nIHdoaWxlIGFuZCB0aGUgV0cgc2hvd2VkIGdvb2QgaW50ZXJlc3QgYW5kIGhhZCBkaXNjdXNz aW9ucy4gVGhlDQo+IGRyYWZ0IGlzIG5vdyBjbGVhcmx5IGluIHNjb3BlIG9mIEFOSU1BIGNoYXJ0 ZXIgMiB0aGF0IHdhcyBhZG9wdGVkIGFyb3VuZA0KPiBJRVRGMTA2LiBUaGUgYXV0aG9ycyBhc2tl ZCBmb3IgYWRvcHRpb24gb2YgdGhlIGRvY3VtZW50LiBHaXZpbmcgdGhlDQo+IGRlcGVuZGVudCBC UlNLSSBoYXMgcGFzc2VkIHRoZSBJRVNHIGV2YWx1YXRpb24sIHRoZSBjaGFpcnMgZmVlbCB0aGF0 IGl0IG1heQ0KPiBiZSB0aGUgcmlnaHQgdGltZSB0byBjYWxsIHRoZSBhZG9wdGlvbi4NCj4gPj4N Cj4gPj4gV2UgdGhlcmVmb3JlIGFyZSBhc2tpbmcgdGhlIEFOSU1BIHdvcmtpbmcgZ3JvdXAgZm9y IGFkb3B0aW9uIG9mIHRoZQ0KPiBmb2xsb3dpbmcgd29yazoNCj4gPj4NCj4gPj4gVGl0bGU6wqDC oMKgIFN1cHBvcnQgb2YgYXN5bmNocm9ub3VzIEVucm9sbG1lbnQgaW4gQlJTS0kNCj4gPj4gTmFt ZTrCoMKgwqDCoCBkcmFmdC1mcmllcy1hbmltYS1icnNraS1hc3luYy1lbnJvbGwtMDMNCj4gPj4g QXV0aG9yczrCoCBTLiBGcmllcywgSC4gQnJvY2toYXVzIGFuZCBFLiBMZWFyDQo+ID4+IFVSTDoN Cj4gPj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtZnJpZXMtYW5pbWEt YnJza2ktYXN5bmMtZW5yb2xsDQo+ID4+IC8NCj4gPj4NCj4gPj4gVGhpcyBkb2N1bWVudCBpcyBp bnRlbmRlZCB0byBiZWNvbWUgYSBzdGFuZGFyZHMgdHJhY2sgQU5JTUEgV0cNCj4gZG9jdW1lbnQu DQo+ID4+DQo+ID4+IFBsZWFzZSBleHByZXNzIHlvdXIgc3VwcG9ydCBvciByZWplY3Rpb24uIElm IHlvdSB0aGluayB0aGlzIGRvY3VtZW50DQo+IHNob3VsZCBfbm90XyBiZSBhZG9wdGVkLCBwbGVh c2UgYWxzbyBleHBsaWNpdGx5IGluZGljYXRlIHRoZSByZWFzb25zLg0KPiA+Pg0KPiA+PiBSZWdh cmRzLA0KPiA+Pg0KPiA+PiBTaGVuZw0KPiA+Pg0KPiA+PiBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+PiBBbmltYSBtYWlsaW5nIGxpc3QNCj4gPj4g QW5pbWFAaWV0Zi5vcmcgPG1haWx0bzpBbmltYUBpZXRmLm9yZz4NCj4gPj4gaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hbmltYQ0KPiA+DQo+ID4NCj4gPiBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+IEFuaW1hIG1haWxpbmcg bGlzdA0KPiA+IEFuaW1hQGlldGYub3JnDQo+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9hbmltYQ0KPiA+DQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KPiBBbmltYSBtYWlsaW5nIGxpc3QNCj4gQW5pbWFAaWV0Zi5v cmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hbmltYQ0K From nobody Wed Jun 24 02:39:42 2020 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 355EB3A0CEF for ; Wed, 24 Jun 2020 02:39:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.87 X-Spam-Level: X-Spam-Status: No, score=-0.87 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=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 feyyvGaVpzsY for ; Wed, 24 Jun 2020 02:39:38 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA5963A0CED for ; Wed, 24 Jun 2020 02:39:38 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 62DF854843F; Wed, 24 Jun 2020 11:39:33 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 5BFA5440043; Wed, 24 Jun 2020 11:39:33 +0200 (CEST) Date: Wed, 24 Jun 2020 11:39:33 +0200 From: Toerless Eckert To: Eliot Lear Cc: Michael Richardson , Eric Rescorla , Stephen Kent , Anima WG Message-ID: <20200624093933.GC47499@faui48f.informatik.uni-erlangen.de> References: <6981a76f-76f1-e9b2-319d-473c7a4bc847@verizon.net> <6c4e402f-cce6-daff-aa16-6159340f0802@gmail.com> <9c09debe-3463-a574-46cf-cee86a2c68af@verizon.net> <15951.1592960140@localhost> <9AF4DB48-EAB5-4BFB-8FF1-E55EF0F59140@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9AF4DB48-EAB5-4BFB-8FF1-E55EF0F59140@cisco.com> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [Anima] representing ACP info in X.509 certs X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jun 2020 09:39:41 -0000 Thanks, Eliot, inline On Wed, Jun 24, 2020 at 09:04:59AM +0200, Eliot Lear wrote: > With ACP it???s clear they are overloading semantics of an rfc822name, What is your definition of "overloading" ? There are all type of entities addressed with rfc822name, not only people, but also functions and devices have been given rfc822names as well forever. Ok, so the name part is somewhat strange because it's numeric. How about companies giving users email addresses that are serial numbers. Quite ccommon actuall i think. Prof.Dr.Acme.Example@domain.com - also roles can be found in rfc822names. We're just doing what everybody and their dog has done with rfc822 names forever. > and from an application standpoint we don???t like that because it is possible that different subsystems may have different uncoordinated allocation methods. I don't think this is true > That is- someone may be able to nab an email address via the mail subsystem a la rfcSELF+fd89b714F3db00000200000064000000+area51.research@acp.example.com , The example explicitly used acp.example.com instead of example.com to ensure that allocation of email addresses in such a specific subdomain was not simply possible for arbitrary users who might allocate email addrs under example.com. Its common practivce in enterprises to have all type of subdomains for specific functions not accessible to the standard mail system setup. Arguing you can get an email address is like arguing you can fake a domain name in such a controlled environment. And see the following: it wouldn't even be good enough. > get a cert for that address Not from the necessary TA. > , and masquerade as an AN or an AN could start sending email as a user that has such an address. No. See section 6.1.4 | Certificates for an ACP MUST only be given to nodes that are allowed | to be members of that ACP. Because the signing CA relies on an ACP | Registrar, the CA MUST only sign certificates with ACP domain | information through trusted ACP Registrars. Any existing CA, unaware | of the new ACP domain information field, can be used as long as it | only allows signing requests from trusted ACP Registrars and from | nodes or registrars trusted not to include ACP domain information in | their certificates. | These requirements can be achieved by using TA private to the owner | of the ACP domain or potentially through appropriate contractual | agreements between the involved parties. Public CA without such | obligations and guarantees can not be used as TA for ACP domains, but | they can be used to obtain certificates for TAs of ACP domain. Aka: The ACP trust model is built on controlled access TA and specific functionality registrar, it does not matter at all which field the information is encoded into for the trust model described. > Let???s agree that the latter is so minimal a risk as to not warrant further discussion. Lets agree this would only happen by explicit violation of mandatory document requirements by a real misguided operator. And under those circumstances most RFCs would not be safe. > It???s only the former that???s really of concern. That can be mitigated through operational guidance, a???la ???don???t allow email addresses in your domain that begin with rfcSELF+???. Actually right now my personal recommendation would be to allocate that email address (prefix) rfcSELF{+...}@.. to the ACP admin to see if there was ever some unintended side effect such as email to that address that was generated by other software. Btw: ANIMA and ACME folks had a side meeting last year (i think you where there ?!), and of course one of the ideas is to be able to use ACME mail signed certs in the future, but this is outside the scope of the document. But the recommendation in the doc to use an ACP domain name part that you own already prepares for that, so i think it should be fairly easy to use in the future ACME web PKI as TA just from the perspective of using the ACP rfc822name as the validation email mechanism. There may be other ACME issues to resolve though. > It???s not perfect. Thats how i started to think of initially as well coming from just the problem of how to overcome ossification of the ecosystem we have to deal with. But in the meantime i think the format of rfc822name is near perfect for both human consumption as well as for managing it - has domain-name to tie into something you can have authoritatively. > That???s the nature of an expedient. But it???s probably Good Enough for now. For the eventuality that another name could be used over time, it???s probably worth getting an OID and using otherName where possible, but we shouldn???t hold this work up over a highly theoretical attack. I think the reason for solutions that like to reuse the rfc822name format of local@domain but choose new encoding points is so that they can reuse existing local@domain user identifiers but indicate a specific app. Much like a uri scheme of newapp:local@domain In the case of ACP this is not necessary, because we simply distinguish on the local part and/or the domain name. No need to support overloading of the same rfc822names for different uses. That is something more relevant to humans who like to have a single local@domain ID for themselves across all apps. ACP IDs are more functional IDs. Cheers Toerless > Eliot > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima -- --- tte@cs.fau.de From nobody Wed Jun 24 03:41:17 2020 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 046903A0D36 for ; Wed, 24 Jun 2020 03:41:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.6 X-Spam-Level: X-Spam-Status: No, score=-9.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 2ZEnznp91QHR for ; Wed, 24 Jun 2020 03:41:13 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E1A83A0CFA for ; Wed, 24 Jun 2020 03:41:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=18689; q=dns/txt; s=iport; t=1592995273; x=1594204873; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=YKGZpPXmXNvTmBceHW117zMWzgECVkWDEL3ypCPlBig=; b=ditFgruWN2iS5ndaDWsbch5pZ5ZM7ZwrP0lQBeZMMnu3rEe9ffVsSAvz wug8tM5p5b3F7KdCWVqRQ6j4npyVm2xspJWCQFw+H0aQPgkwsNRtu6kq9 AjjkLb9rMw58Jd3Us+j9XnLkulZtiw6wYS3q0gRH/T0m8tFCGXefrgYx1 k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AwAQBtLfNe/xbLJq1mGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQEBAQEBARIBAQEBAQEBAQEBAQGCCgKBc4EkVAEgEiyBf4IliQGICpN?= =?us-ascii?q?thiyBaAsBAQEMAQEYAQoMBAEBgVOCdAKCFSU4EwIDAQELAQEFAQEBAgEGBG2?= =?us-ascii?q?FLgYnDEIBDAGFIgEBAQECAQEBIUsLBQsLDgonAwICJx8RBhMbgwsBglwgD7Y?= =?us-ascii?q?1doEyhVGFCYE4AYoXgmWCAIERJxyCHy4+giM5AQGBKgERAgFWgl4zgi0EmRC?= =?us-ascii?q?LCZBOgmSDA4VBkGsDHYQJjQSNdpoJkiyDTwIEBgUCFYFAKiJmcDMaCBsVOyo?= =?us-ascii?q?Bgj4JNRIZDYE0jHYXg06FFIVEPwMwAgE0AgYBBwEBAwmGJohuLYIXAQE?= X-IronPort-AV: E=Sophos; i="5.75,275,1589241600"; d="scan'208,217"; a="27403167" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 24 Jun 2020 10:40:51 +0000 Received: from [10.61.241.223] ([10.61.241.223]) by aer-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id 05OAenXE028763 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 24 Jun 2020 10:40:50 GMT From: Eliot Lear Message-Id: <16FC5860-93AC-46DC-942F-9E3898CAFD73@cisco.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_E1CAF0AD-803D-4F7E-88AA-C3AA1C57DA9A" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Wed, 24 Jun 2020 12:40:48 +0200 In-Reply-To: <20200624093933.GC47499@faui48f.informatik.uni-erlangen.de> Cc: Michael Richardson , Eric Rescorla , Stephen Kent , Anima WG To: Toerless Eckert References: <6981a76f-76f1-e9b2-319d-473c7a4bc847@verizon.net> <6c4e402f-cce6-daff-aa16-6159340f0802@gmail.com> <9c09debe-3463-a574-46cf-cee86a2c68af@verizon.net> <15951.1592960140@localhost> <9AF4DB48-EAB5-4BFB-8FF1-E55EF0F59140@cisco.com> <20200624093933.GC47499@faui48f.informatik.uni-erlangen.de> X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Outbound-SMTP-Client: 10.61.241.223, [10.61.241.223] X-Outbound-Node: aer-core-4.cisco.com Archived-At: Subject: Re: [Anima] representing ACP info in X.509 certs X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jun 2020 10:41:16 -0000 --Apple-Mail=_E1CAF0AD-803D-4F7E-88AA-C3AA1C57DA9A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 24 Jun 2020, at 11:39, Toerless Eckert wrote: >=20 > Thanks, Eliot, >=20 > inline >=20 > On Wed, Jun 24, 2020 at 09:04:59AM +0200, Eliot Lear wrote: >> With ACP it???s clear they are overloading semantics of an = rfc822name, >=20 > What is your definition of "overloading" ? >=20 > There are all type of entities addressed with rfc822name, not only > people, but also functions and devices have been given rfc822names as = well forever. > Ok, so the name part is somewhat strange because it's numeric. > How about companies giving users email addresses that are serial = numbers. > Quite ccommon actuall i think. Prof.Dr.Acme.Example@domain.com - also = roles can be found in > rfc822names. We're just doing what everybody and their dog has done > with rfc822 names forever. >=20 >> and from an application standpoint we don???t like that because it is = possible that different subsystems may have different uncoordinated = allocation methods. >=20 > I don't think this is true If the ACP subsystem allocates a name and the user management system = allocates a name, then you have the potential of a conflict. Again, the = odds of an actual conflict are very low. >=20 >> That is- someone may be able to nab an email address via the mail = subsystem a la = rfcSELF+fd89b714F3db00000200000064000000+area51.research@acp.example.com = , >=20 > The example explicitly used acp.example.com instead of example.com > to ensure that allocation of email addresses in such a specific > subdomain was not simply possible for arbitrary users who might > allocate email addrs under example.com. Its common practivce > in enterprises to have all type of subdomains for specific > functions not accessible to the standard mail system setup. > Arguing you can get an email address is like arguing you can > fake a domain name in such a controlled environment. And see=20 > the following: it wouldn't even be good enough. You can make an operational recommendation of course. However, some = enterprises simply do not do subdomains (I email from one such = enterprise now). >=20 >> get a cert for that address >=20 > Not from the necessary TA. >=20 >> , and masquerade as an AN or an AN could start sending email as a = user that has such an address. >=20 > No. >=20 > See section 6.1.4 >=20 > | Certificates for an ACP MUST only be given to nodes that are = allowed > | to be members of that ACP. Because the signing CA relies on an ACP > | Registrar, the CA MUST only sign certificates with ACP domain > | information through trusted ACP Registrars. Any existing CA, = unaware > | of the new ACP domain information field, can be used as long as it > | only allows signing requests from trusted ACP Registrars and from > | nodes or registrars trusted not to include ACP domain information = in > | their certificates. >=20 Ok, but... > | These requirements can be achieved by using TA private to the owner > | of the ACP domain or potentially through appropriate contractual > | agreements between the involved parties. Public CA without such > | obligations and guarantees can not be used as TA for ACP domains, = but > | they can be used to obtain certificates for TAs of ACP domain. >=20 > Aka: The ACP trust model is built on controlled access TA and=20 > specific functionality registrar, it does not matter at all which > field the information is encoded into for the trust model described. If the TA is itself signed by a public CA, then the CA can sign other = names or for that matter issue other signing certs , and (at least by = normal use of PKI) the name will validate without the TA ever having = been used. Assuming that=E2=80=99s not what you mean, how does the = client know which TA is authorized? >=20 >> Let???s agree that the latter is so minimal a risk as to not warrant = further discussion. >=20 > Lets agree this would only happen by explicit violation of > mandatory document requirements by a real misguided operator. And > under those circumstances most RFCs would not be safe. >=20 >> It???s only the former that???s really of concern. That can be = mitigated through operational guidance, a???la ???don???t allow email = addresses in your domain that begin with rfcSELF+???. >=20 > Actually right now my personal recommendation would be to allocate = that > email address (prefix) rfcSELF{+...}@.. to the ACP admin to see if = there was ever > some unintended side effect such as email to that address > that was generated by other software. I like that idea. >=20 > Btw: ANIMA and ACME folks had a side meeting last year (i think you > where there ?!), and of course one of the ideas is to be able > to use ACME mail signed certs in the future, but this is outside > the scope of the document. But the recommendation > in the doc to use an ACP domain name part that you own already > prepares for that, so i think it should be fairly easy to use > in the future ACME web PKI as TA just from the perspective of > using the ACP rfc822name as the validation email mechanism. There > may be other ACME issues to resolve though. >=20 >> It???s not perfect. >=20 > Thats how i started to think of initially as well coming from > just the problem of how to overcome ossification of the ecosystem > we have to deal with. But in the meantime i think the format > of rfc822name is near perfect for both human consumption as well > as for managing it - has domain-name to tie into something you > can have authoritatively.=20 >=20 >> That???s the nature of an expedient. But it???s probably Good Enough = for now. For the eventuality that another name could be used over time, = it???s probably worth getting an OID and using otherName where possible, = but we shouldn???t hold this work up over a highly theoretical attack. >=20 > I think the reason for solutions that like to reuse the > rfc822name format of local@domain but choose new encoding > points is so that they can reuse existing local@domain > user identifiers but indicate a specific app. Much > like a uri scheme of newapp:local@domain This requires a broader discussion that need not hold up this draft. Eliot >=20 > In the case of ACP this is not necessary, because we > simply distinguish on the local part and/or the domain > name. No need to support overloading of the same rfc822names > for different uses. That is something more relevant to > humans who like to have a single local@domain ID for=20 > themselves across all apps. ACP IDs are more functional IDs. >=20 > Cheers > Toerless >=20 >> Eliot >=20 >=20 >=20 >> _______________________________________________ >> Anima mailing list >> Anima@ietf.org >> https://www.ietf.org/mailman/listinfo/anima >=20 >=20 > --=20 > --- > tte@cs.fau.de --Apple-Mail=_E1CAF0AD-803D-4F7E-88AA-C3AA1C57DA9A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 24 Jun 2020, at 11:39, Toerless Eckert <tte@cs.fau.de> = wrote:

Thanks, Eliot,

inline

On Wed, Jun 24, 2020 at 09:04:59AM +0200, = Eliot Lear wrote:
With = ACP it???s clear they are overloading semantics of an rfc822name,

What is your definition of = "overloading" ?

There are all type of = entities addressed with rfc822name, not only
people, but = also functions and devices have been given rfc822names as well = forever.
Ok, so the name part is somewhat strange because = it's numeric.
How about companies giving users email = addresses that are serial numbers.
Quite ccommon actuall i = think. Prof.Dr.Acme.Example@domain.com - also roles can be found = in
rfc822names. We're just doing what everybody and their = dog has done
with rfc822 names forever.

and from an application = standpoint we don???t like that because it is possible that different = subsystems may have different uncoordinated allocation methods.

I don't think this is true

If the ACP = subsystem allocates a name and the user management system allocates a = name, then you have the potential of a conflict.  Again, the odds = of an actual conflict are very low.


That is- someone may be = able to nab an email address via the mail subsystem a la rfcSELF+fd89b714F3db00000200000064000000+area51.research@acp.ex= ample.com <mailto:rfcSELF+fd89b714F3db00000200000064000000+area51.research= @acp.example.com>,

The = example explicitly used acp.example.com instead of example.com
to ensure that allocation of = email addresses in such a specific
subdomain was not = simply possible for arbitrary users who might
allocate = email addrs under example.com. Its common practivce
in = enterprises to have all type of subdomains for specific
functions not accessible to the standard mail system = setup.
Arguing you can get an email address is like = arguing you can
fake a domain name in such a controlled = environment. And see
the following: it wouldn't even be = good enough.

You can make an operational recommendation of course. =  However, some enterprises simply do not do subdomains (I email = from one such enterprise now).


get a cert for that = address

Not from the necessary = TA.

, = and masquerade as an AN or an AN could start sending email as a user = that has such an address.

No.
See section 6.1.4

|  Certificates for an ACP MUST only be given to nodes = that are allowed
|  to be members of that ACP. =  Because the signing CA relies on an ACP
| =  Registrar, the CA MUST only sign certificates with ACP domain
|  information through trusted ACP Registrars.  Any = existing CA, unaware
|  of the new ACP domain = information field, can be used as long as it
|  only = allows signing requests from trusted ACP Registrars and from
|  nodes or registrars trusted not to include ACP domain = information in
|  their certificates.

Ok, = but...


|  These requirements can be achieved by using TA = private to the owner
|  of the ACP domain or = potentially through appropriate contractual
| =  agreements between the involved parties.  Public CA without = such
|  obligations and guarantees can not be used as = TA for ACP domains, but
|  they can be used to obtain = certificates for TAs of ACP domain.

Aka: = The ACP trust model is built on controlled access TA and
specific functionality registrar, it does not matter at all = which
field the information is encoded into for the trust = model described.

If the TA is itself signed by a public CA, then = the CA can sign other names or for that matter issue other signing certs = , and (at least by normal use of PKI) the name will validate without the = TA ever having been used.  Assuming that=E2=80=99s not what you = mean, how does the client know which TA is authorized?



Let???s agree that the latter is so minimal a risk as to not = warrant further discussion.

Lets= agree this would only happen by explicit violation of
mandatory document requirements by a real misguided operator. = And
under those circumstances most RFCs would not be = safe.

= It???s only the former that???s really of concern.  That can be = mitigated through operational guidance, a???la ???don???t allow email = addresses in your domain that begin with rfcSELF+???.

Actually right now my personal = recommendation would be to allocate that
email address = (prefix) rfcSELF{+...}@.. to the ACP admin to see if there was ever
some unintended side effect such as email to that address
that was generated by other software.

I like = that idea.



Btw: ANIMA and ACME folks had a side meeting last year (i = think you
where there ?!), and of course one of the ideas = is to be able
to use ACME mail signed certs in the future, = but this is outside
the scope of the document. But the = recommendation
in the doc to use an ACP domain name part = that you own already
prepares for that, so i think it = should be fairly easy to use
in the future ACME web PKI as = TA just from the perspective of
using the ACP rfc822name = as the validation email mechanism. There
may be other ACME = issues to resolve though.

It???s not perfect.

Thats how i started to think of = initially as well coming from
just the problem of how to = overcome ossification of the ecosystem
we have to deal = with. But in the meantime i think the format
of rfc822name = is near perfect for both human consumption as well
as for = managing it - has domain-name to tie into something you
can = have authoritatively.

That???s the nature of an expedient.  But = it???s probably Good Enough for now.  For the eventuality that = another name could be used over time, it???s probably worth getting an = OID and using otherName where possible, but we shouldn???t hold this = work up over a highly theoretical attack.

I think the reason for solutions that like to reuse the
rfc822name format of local@domain but choose new encoding
points is so that they can reuse existing local@domain
user identifiers but indicate a specific app. Much
like a uri scheme of newapp:local@domain

This = requires a broader discussion that need not hold up this = draft.

Eliot

In the case of ACP this is not necessary, because we
simply distinguish on the local part and/or the domain
name. No need to support overloading of the same = rfc822names
for different uses. That is something more = relevant to
humans who like to have a single local@domain = ID for
themselves across all apps. ACP IDs are more = functional IDs.

Cheers
=    Toerless

Eliot



_______________________________________________
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima


--
---
tte@cs.fau.de

= --Apple-Mail=_E1CAF0AD-803D-4F7E-88AA-C3AA1C57DA9A-- From nobody Wed Jun 24 11:17:26 2020 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9D643A1123 for ; Wed, 24 Jun 2020 11:17:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 STexwcav4DzP for ; Wed, 24 Jun 2020 11:17:20 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE1FD3A08A7 for ; Wed, 24 Jun 2020 11:17:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 4C069300B04 for ; Wed, 24 Jun 2020 14:17:17 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 2fnTCDv9ZuqB for ; Wed, 24 Jun 2020 14:17:08 -0400 (EDT) Received: from a860b60074bd.fios-router.home (pool-72-66-113-56.washdc.fios.verizon.net [72.66.113.56]) by mail.smeinc.net (Postfix) with ESMTPSA id 04878300B7C; Wed, 24 Jun 2020 14:17:07 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.14\)) From: Russ Housley In-Reply-To: <20200624023407.GA41244@faui48f.informatik.uni-erlangen.de> Date: Wed, 24 Jun 2020 14:17:08 -0400 Cc: draft-ietf-anima-autonomic-control-plane.ad@ietf.org, anima@ietf.org, Ben Kaduk , Eric Vyncke , rwilton@cisco.com Content-Transfer-Encoding: quoted-printable Message-Id: References: <20200624023407.GA41244@faui48f.informatik.uni-erlangen.de> To: Toerless Eckert X-Mailer: Apple Mail (2.3445.104.14) Archived-At: Subject: Re: [Anima] Russ/Ben: Re: Russ Housley's review of draft-ietf-autonomic-control-plane-24 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jun 2020 18:17:24 -0000 Toerless: > On Fri, Mar 20, 2020 at 05:12:52PM -0400, Russ Housley wrote: >>=20 >> The document defines Enrollment: >>=20 >> Enrollment: The process where a node presents identification (for >> example through keying material such as the private key of an >> IDevID) to a network and acquires a network specific identity = such >> as an LDevID and trust anchors such as Certificate Authority = (CA) >> certificates. >>=20 >> First, an annoyance. CA =3D Certification Authority (not Certificate = Authority). This applies to an earlier definition and many other places = as well. >=20 > [fun excourse] >=20 > In my defense, i grew up in a town with a dialect: >=20 > google: site:cisco.com "certificate authority" -> 59,700 > google: site:cisco.com "certification authority" -> 8,580 >=20 > Also:=20 >=20 > https://en.wikipedia.org/wiki/Certificate_authority >=20 > grep -il "ertification authorit" rfc*.txt | wc -> 272 (#RFCs) > grep -il "ertificate authorit" rfc*.txt | wc -> 136 (#RFCs) >=20 > grep -il "ertification authorit" rfc8???.txt | wc -> 38 (#RFCs) > grep -il "ertificate authorit" rfc8???.txt | wc -> 13 (#RFCs) >=20 > ratio is getting better for your side... a bit. >=20 > Does RFC editor have a negative list of wrong words ? > RFC editor abbreviation lists only the correct term. >=20 > [/fun excourse] >=20 > Fixed. Thank you. Many people get it wrong, but X.509 and RFC 5280 (as well as = the earlier versions in RFC 2459 and RFC 3280) all use "certification = authority". >=20 >> IDevID and LDevID are certificates. In this context, enrollment = should be using an IDevID for authentication in order to get a LDevID. >=20 > That was the intention of the text. >=20 > Pls. check fixed text for CA, Enrollment, root CA, and TA, i hope they = are better now. CA: It says "A CA uses its own certificate to sign the certificates it = issues." This is not correct. The CA signs with the private key, and the relying = party used the public key in the CA certificate to check the signature. Enrollment: I think it would help the reader to say "IDevID certificate" = and "LDevID certificate" Root CA: I do not understand the purpose of "()" in the old text or the = new text. TA: Please point to RFC 5280, Section 6.1.1, item (d). It says: """ (d) trust anchor information, describing a CA that serves as a trust anchor for the certification path. The trust anchor information includes: (1) the trusted issuer name, (2) the trusted public key algorithm, (3) the trusted public key, and (4) optionally, the trusted public key parameters associated with the public key. The trust anchor information may be provided to the path processing procedure in the form of a self-signed certificate. When the trust anchor information is provided in the form of a certificate, the name in the subject field is used as the trusted issuer name and the contents of the subjectPublicKeyInfo field is used as the source of the trusted public key algorithm and the trusted public key. The trust anchor information is trusted because it was delivered to the path processing procedure by some trustworthy out-of-band procedure. If the trusted public key algorithm requires parameters, then the parameters are provided along with the trusted public key. """ >=20 >> The document defines Trust Anchor in a way that is not fully = compatible with RFC 5280. It ought to use the definition from RFC 5280. >=20 > I apologize, but this is a bit of a riddle to me because i could not = find text that looks like a definition of "trust anchor" in rfc5280 and = your concern above also does not explain exactly how the ACP text does = not comply with such an "definition". >=20 > Are you taking offense in conflating trust anchor and trust anchor = information ? > That seems to be a common issue in other documents, eg. in 5280: >=20 > "When the trust anchor is provided in the form of a self-signed = certificate" >=20 > "When trust anchor information" ? >=20 > In any case, in lack of a better pointe to an RFC, the ACP text now = uses the X.509 text to define trust anchor and i tried to go through the = text and distinguish between TA and TA information as good as i could. >=20 > If there are still concern about this point, i would appreciate if you = could be more specific as to what exactly is still wrong and provide = suggested text fixes. I made a suggestion above. Certification path validation depends on the = TA name, public key algorithm, and public key, and it may also depend on = parameters associated with the algorithm. >=20 >> Section 6.1: >>=20 >> - The text uses the word "trust" in a vague way. It should say what = they are trusted to do, and what they are trusted to not do. >>=20 >> - The test says: >>=20 >> An ACP node MUST >> have a Local Device IDentity certificate (LDevID) and a Trust = Anchor >> (TA) consisting of a certificate (chain) used to sign the LDevID of >> all ACP domain members. >>=20 >> This does not seem accurate to me in several ways. Most importantly, = a TA is not c certifications path or chain. >=20 > Fixed to: To trust another ACP member node with access to the ACP = Domain, each ACP member requires > keying material: An ACP node MUST have a Local Device IDentity = certificate (LDevID), > henceforth called the ACP Domain Certificate and information about one = or more Trust Anchor (TA) > as required for the ACP domain membership check () >=20 > { Please suggest better text if this is still not good enough}. Why not point to Section 6 of RFC 5280 for validation of the LDevID to = the configured trust anchor? >=20 >> Section 6.1.1: >>=20 >> - s/X.509/X.509v3/ >=20 > fixed. Thank you. >=20 >> - What does "All elements are [RFC5280] compliant??? mean? >=20 > removed. >=20 > It was just meant to be unnecessary duplicaction of initial sentence = from same section: > "ACP domain certificates MUST be [RFC5280] compliant X.509v3 = certificates" Okay. >=20 >> - MUST do both RSA and ECC? I think this is too simplistic. I do not = expect devices to have both kinds of private key, but they need to = handle both kinds of public key. This seems to be where the transition = paragraph is going, but it is not very clear. >=20 > Changed: >=20 > "ACP nodes MUST support RSA and Elliptic Curve (ECC) public keys in = ACP certificates" >=20 > to >=20 > "ACP nodes MUST support handling ACP certificates with RSA public keys = and ACP certificates with Elliptic Curve (ECC) public keys" >=20 > Hope i was guessing right what you are aluding to, if now, then = explicit text suggestions are always welcome. Section 6.1.1 looks okay to me. >=20 >> - I do not understand the wording about ECC curves that MUST be = supported. Normally I see a single curve that MUST be supported for = interoperability and and others that SHOULD be supported. The "or = better" wording is really unclear. Also, each of the curves has a = specific key length associated with it. >=20 > In the ACP we have any-to-any connectivity and hence any-any mutual = cert authentication, so i felt it to be prudent to support some good = range of cert key sizes to ensure interoperability across a wide range = of equipment within a single ACP - but also exclude key sizes that we = feel are unnecessarily weak, such as RSA with less than 2048 bits. >=20 > I changed the two paragraphs now to the following three: >=20 > --- > ACP nodes MUST support handling ACP certificates, TA certificates = and certificate chain certificates (henceforth just called certificates = in this section) with RSA public keys and certificates with Elliptic = Curve (ECC) public keys. Certificates with ECC keys MUST indicate to be = Elliptic Curve Diffie-Hellman capable (ECDH) if X.509 v3 keyUsage and = extendedKeyUsage are included in the certificate. >=20 > ACP nodes MUST NOT support certificates with RSA public keys of = less than 2048 bits. They MUST support certificates with RSA public keys = with 2048 bits and SHOULD support longer RSA keys. ACP nodes MUST = support certificates with ECC public keys using NIST P-256, P-384 and = P-521 curves. >=20 > ACP nodes MUST support SHA-256, SHA-384, SHA-512 signatures for = certificates with RSA key and the same RSA signatures plus ECDSA = signatures for certificates with ECC key. > --- >=20 > I don't understand whether your note about the key length of the = curves is an indication of missing text. When i first reviewed with Ben, = i had to enter the curves because thats as specific as necessary AFAIK, = but given how the key length is implied, i wouldn't understand why i = would need to write those down. I don't remember that i have seen that = being done either in other RFCs i read through. >=20 > In any case, specific text suggestions always welcome in case this = text is not sufficient. I was expecting you to make one of the curves MUST and the others = SHOULD. Making all three curves MUST is okay with me, but it will = increase implementation size. Likewise, I was expecting you to make one of the hash functions MUST and = the others SHOULD. >=20 >> - I would really like to see some clarity about digital signature vs. = key establishment. The two are jumbled together is a way that is = difficult to figure out. One way to read it is that digital signature = is required, but key establishment is optional. I am not sure that is = the intent. >=20 > I may not understand what you mean with "key establishment". ECDH is used for key establishment, not digital signature. RSA can be used for both key establishment and digital signature if the = key usage bits allow. >=20 > The first two paragraphs talk about the requirements to handle public = key in the certificate > including permitted minimum key-length for RSA. Is that what you call = "key establishment" ? >=20 > The third paragraph talks about requirements against the signatures in = the certificates. >=20 > The idea is to have the necessary and sufficient text for all ACP = nodes to be > able to authenticte each other wrt. to their certificate. My comment was about the ECDH sentence. >=20 >> - The TLS reference should point to TLS 1.3 (not TLS 1.2). >=20 > The MTI for the ACP is TLS 1.2, TLS 1.3 is SHOULD because of the need = for > lowest common denominator in more embedded device space moving very = slowly > from TLS 1.2 to TLS 1.3. See e.g.: 6.8.2. Also note that TLS profile > for ACP is quite close to TLS 1.3 wrt. crypto requirements. The please be specific: ... TLS 1.2 [RFC5246]. >=20 >> Section 6.1.2: >>=20 >> - Using rfc822name seems wrong to me. Assigning another name type = seems preferable, even if it has the same syntax. The semantics are = different. This is the approach used in RFC 4556 for the Kerberos = Principal Name. >=20 > Can you point me to any specifc RFC text that actually prohibits what = we want to do ? >=20 > I was reading through the RFCs (forgot number now) that i think = defined the > encodings, and i could not find anything that would prohibit to use = the existing > rfc822name for a name that is a valid rfc822name. >=20 > It would also be good if you review and address the bullet points 2.1 = ... 2.6 and > 3.1 ... 3.5 in section 6.1.2. These points explain and justify the = choice > of rfc822name. >=20 > For example, points 2.1 , 2.4 and 2.5 would be closest in addressing = your semantic concern. I firmly believe that this use of rfc822name is harmful. Please do not = do it. >=20 >> - The document claims that "subjectAlName / otherName" will not be = able to be supported because it uses a field that is not mandatory. I = do not think that this is a very big deal. The otherName definition is: >>=20 >> OtherName ::=3D SEQUENCE { >> type-id OBJECT IDENTIFIER, >> value [0] EXPLICIT ANY DEFINED BY type-id } >=20 >> So, the "extra" processing is parse past the type and length for the = SEQUENCE, perform an exact match to the constant value of the object = identifier, parse past the type and length of the value. For example, = when using the python ASN.1 library for the certificate processing, the = additional code is tiny. After this, the parsing of the string is = exactly the same. In fact, it might be possible to define a format that = is even easier to parse if it did not have to look like an email = address. Since this "extra" is so small, I think we should not use = rfc822name in this context. >=20 > This is addressed in for example point 3.2 in 6.1.2. The ASN.1 = libraries available in=20 > embedded systems do not necessarily provide the ability to be = extended. They may > often come from embedded system OS vendors or third parties. >=20 > Also see points 2.2 and 2.3 of 6.1.2: There is a whole backend and = diagnostic infrastructure that needs to be extended when introducing new = types to decode the new field. This is highly undesirable for easy = operationalization. I believe that otherName would be better here. You have made the syntax = align with rfc822name, but the semantics are aligned. >=20 >> Section 6.1.3: >>=20 >> - validity period checking (in step 1) is part of path validation (in = step 3). >=20 > Sigh... hope i fixed all the references to the rule numbers in the = document > after eliminating this step 1 and mentioning how it is included in = what is > now step 2. Within Item 3: s/CDP/CRLDP/ or /CRL Distribution Point (CRLDP)/ s/communicate CRL or OCSP check/communicate a CRL or perform an OCSP = check/ >=20 >> - In step 4, revocation checking allowed to be initially skipped, but = the wording is concerning since the check is in a MUST statement. Then, = the checking takes place when communications are established. I assume = some cache is used, otherwise the connection works for a short while, = then shuts down, over and over and over. >=20 > Hopefully fixed. >=20 > Pls. check the reworded text. I conditioned the MUST > with a "when availalable" and changed the secondary MUST to lower case = as they > just explain the mechanism. >=20 > Wrt to the up/down issue you mention: It seems cleat that one must = periodically > re-try a connection to another peer because it could have received a = new > certificate. >=20 > If the connection is torn down at any point in time because of newly = learned > CRL/OCSP information, it also seems clear the connection needs to be = torn down. >=20 > I do not understand all possible connection setup protocols, but from > what i understand, a negative CRL or OCSP information will not change = back > to positive in the future, so a connection torn down once because of > a particular certificate would need to be retried later up to the > point that the signaling gets to the same certificate, at which point = in > time it would fail.=20 >=20 > Aka: with caching of OCSP/CRL results, the connection would still be = probed > periodically, but would not be brought up again until there is a new = cert. >=20 > Is there anything of these explanations you would like to see written > down ? Or that are wrong ? The previous step allows the CRL check and OCSP check to be skipped if = communication is not available. When the communication is established, = is a CRL check or OCSP check performed? What happens if the check = fails? Of course, I strongly disagree with the use of rfc822name here, but that = was not really the point of this comment. >=20 >> Section 6.1.4: >>=20 >> - Please use the terms from RFC 5280. That is, use "trust anchor" = not "root-CA". >=20 > a) While trying to do this, it seemed to me as if the word "trust = point" that > was also used in the text was also redundant. So i hopefully correctly > eliminated it and replaced it with TA. >=20 > b) Given how rfc7030 in 4.1.3 also refers to Root CA, and equaly > the BRSKI draft in several places, and also rfc8572, aka: all the > documents that this ACP relates to, i wonder what the rule of thumb is = when > it is appropriate to use root CA as a term and when not... I don't = want > to be the first RFC of all the ones that the ACP builds on or relates > to that is NOT using the term... without understanding why ACP should = be > the only one not using it... >=20 > There are similarily few occurrances of "root CA" as in those other = documents... I think your definitions now make it clear that a Root CA is a trust = anchor. That is essentially the approach taken in RFC 7030 as well. Russ >=20 > Just wondering. >=20 > Thanks a lot for the review, and apoligies for my delay. >=20 > Cheers > Toerless >>=20 >> Russ From nobody Wed Jun 24 13:06:17 2020 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36BD53A1154 for ; Wed, 24 Jun 2020 13:06:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.65 X-Spam-Level: X-Spam-Status: No, score=-1.65 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 u_slyYMngkKj for ; Wed, 24 Jun 2020 13:06:14 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F18273A0951 for ; Wed, 24 Jun 2020 13:06:13 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 780D6548045; Wed, 24 Jun 2020 22:06:07 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 713A4440043; Wed, 24 Jun 2020 22:06:07 +0200 (CEST) Date: Wed, 24 Jun 2020 22:06:07 +0200 From: Toerless Eckert To: Eliot Lear Cc: Michael Richardson , Eric Rescorla , Stephen Kent , Anima WG Message-ID: <20200624200607.GA31510@faui48f.informatik.uni-erlangen.de> References: <6981a76f-76f1-e9b2-319d-473c7a4bc847@verizon.net> <6c4e402f-cce6-daff-aa16-6159340f0802@gmail.com> <9c09debe-3463-a574-46cf-cee86a2c68af@verizon.net> <15951.1592960140@localhost> <9AF4DB48-EAB5-4BFB-8FF1-E55EF0F59140@cisco.com> <20200624093933.GC47499@faui48f.informatik.uni-erlangen.de> <16FC5860-93AC-46DC-942F-9E3898CAFD73@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <16FC5860-93AC-46DC-942F-9E3898CAFD73@cisco.com> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [Anima] representing ACP info in X.509 certs X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jun 2020 20:06:16 -0000 Thanks, Eliott, inline Btw: Just seeing that the folks holding the DISCUSS are not explicitly included in this thread... not sure if they follow the anima WG mailing list overall... Cc them ? On Wed, Jun 24, 2020 at 12:40:48PM +0200, Eliot Lear wrote: > > I don't think this is true > > If the ACP subsystem allocates a name and the user management system allocates a name, then you have the potential of a conflict. Again, the odds of an actual conflict are very low. Whether or not there is ACP, we are talking about about an app that has access to certificates on routers that could have rfc822name and the app would send emails to those rfc822name addresses and something good would happen. I am quite sure that such an app does not exist, but it could be nice, so lets call it the unicorn app. The ACP rfc822name structure certainly allows for unicorns. If you want to deploy ACP and you don't care about unicorns, you ignore the issue. The conflict you are talking about would only hurt the unicorn but not the ACP. When you do care for unicorns you have several options: a) You can make sure that the local part name space is well managed so local part names for ACP can not be incorrectly assigned to other purposes. Likely works by default because common solutions that let users assign local names or aliases have length limits < ~ 30 characters and ACP local part is 40 + X (X being extensions). Upper limit in rfc822name is btw 64 for local name part. b) You use a different name or subdomain (see) to separate name spaces between users and the names you use inside network operations / ACP. Most common solution IMHO. c) You train the unicorn to forward the names based on where they are found to another domain. typical setup in email ssytem when there are logical names but distributed MTA. > You can make an operational recommendation of course. However, some enterprises simply do not do subdomains (I email from one such enterprise now). Different (Sub)domains are the standard tool to separate local-part namespaces in rfc822. It is widely used in enterprises Do not confuse what you as the user see with whats under the hood in RFC822. As soon as you have multi-vendor distributed MT setups you will use different subdomains under the hood with forwarding and name aliasing/hiding. The vendor you work for even sells comms products with MTA in them that would do that last i checked (couple years back). I am sure if you could look at the whole domain space of your employer, you would find a lot of subdomains, including for other MTAs. But then again, whatever is visible to the outside, both domains and local name parts is subject to corporate comms policies, so indeed it is likely that subdomains would only be available to what that department likes. Many network operations orgs in SP/enterprise therefore just buy their own domain name that has nothing to do wih their enterprises "brand" domain name and use that other domain to freely asign names for routers, network exquipment and network ops related MTA, web servers etc. And then make sure none of these domain names are on public accessible DNS servers/zones. So, if example.com was a typical brand-marketing lead enterprise, the network ops teams would ask to get acp.example.com and even though they may actually run the example.com DNS and MTAs, they wouldn't be the one permitted to decide whats on it, so after four months of discussion, the network ops team would go buy example.org and use acp.example.org. > > | Certificates for an ACP MUST only be given to nodes that are allowed > > | to be members of that ACP. Because the signing CA relies on an ACP > > | Registrar, the CA MUST only sign certificates with ACP domain > > | information through trusted ACP Registrars. Any existing CA, unaware > > | of the new ACP domain information field, can be used as long as it > > | only allows signing requests from trusted ACP Registrars and from > > | nodes or registrars trusted not to include ACP domain information in > > | their certificates. > > Ok, but... > > > | These requirements can be achieved by using TA private to the owner > > | of the ACP domain or potentially through appropriate contractual > > | agreements between the involved parties. Public CA without such > > | obligations and guarantees can not be used as TA for ACP domains, but > > | they can be used to obtain certificates for TAs of ACP domain. > > > > Aka: The ACP trust model is built on controlled access TA and > > specific functionality registrar, it does not matter at all which > > field the information is encoded into for the trust model described. > > If the TA is itself signed by a public CA, then the CA can sign other names or for that matter issue other signing certs , and (at least by normal use of PKI) the name will validate without the TA ever having been used. Assuming that???s not what you mean, how does the client know which TA is authorized? ACP nodes are initialized before ACP can run by a registrar with a cert and the appropriate TA. Cert and TA are renewed via EST automatically before they expire. So TA are fully controlled by the registrar(s). The public CA would never be a feasible TA. Only the private root cert would be an appropriate TA. Whether that private root cert is self-signed or signed by a public CA is irrelevant, that would not change the result of an ACP cert chain validation: The cert chain validation MUST terminate in a TA. The attackers cert you mention would only be signed by the public CA, which is not a TA for the ACP. I don't think there is any benefit of letting private root CA certs as required by ACP to be signed by public CA today. Thats also not done with any of the private root CA certs i know from enterprises, so nothing new here with ACP. With ACME mail we would get new options, but one has to see how more beneficial they are from just having an enterprise run its own private CA solution. You can easily buy private CA solutions as a cloud service from the usual suspectsa. I think the ACME stuff is primarily when you do want to use the certs for external authentication, which ACP wouldn't need unless we go into maybe future ACP for federations. > > Actually right now my personal recommendation would be to allocate that > > email address (prefix) rfcSELF{+...}@.. to the ACP admin to see if there was ever > > some unintended side effect such as email to that address > > that was generated by other software. > > I like that idea. Cheers Toerless > > Btw: ANIMA and ACME folks had a side meeting last year (i think you > > where there ?!), and of course one of the ideas is to be able > > to use ACME mail signed certs in the future, but this is outside > > the scope of the document. But the recommendation > > in the doc to use an ACP domain name part that you own already > > prepares for that, so i think it should be fairly easy to use > > in the future ACME web PKI as TA just from the perspective of > > using the ACP rfc822name as the validation email mechanism. There > > may be other ACME issues to resolve though. > > > >> It???s not perfect. > > > > Thats how i started to think of initially as well coming from > > just the problem of how to overcome ossification of the ecosystem > > we have to deal with. But in the meantime i think the format > > of rfc822name is near perfect for both human consumption as well > > as for managing it - has domain-name to tie into something you > > can have authoritatively. > > > >> That???s the nature of an expedient. But it???s probably Good Enough for now. For the eventuality that another name could be used over time, it???s probably worth getting an OID and using otherName where possible, but we shouldn???t hold this work up over a highly theoretical attack. > > > > I think the reason for solutions that like to reuse the > > rfc822name format of local@domain but choose new encoding > > points is so that they can reuse existing local@domain > > user identifiers but indicate a specific app. Much > > like a uri scheme of newapp:local@domain > > This requires a broader discussion that need not hold up this draft. > > Eliot > > > > In the case of ACP this is not necessary, because we > > simply distinguish on the local part and/or the domain > > name. No need to support overloading of the same rfc822names > > for different uses. That is something more relevant to > > humans who like to have a single local@domain ID for > > themselves across all apps. ACP IDs are more functional IDs. > > > > Cheers > > Toerless > > > >> Eliot > > > > > > > >> _______________________________________________ > >> Anima mailing list > >> Anima@ietf.org > >> https://www.ietf.org/mailman/listinfo/anima > > > > > > -- > > --- > > tte@cs.fau.de > -- --- tte@cs.fau.de From nobody Wed Jun 24 14:11:51 2020 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B52373A1191 for ; Wed, 24 Jun 2020 14:11:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, 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 (2048-bit key) header.d=rtfm-com.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 Lvs2bYJhJbDu for ; Wed, 24 Jun 2020 14:11:47 -0700 (PDT) Received: from mail-lf1-x12f.google.com (mail-lf1-x12f.google.com [IPv6:2a00:1450:4864:20::12f]) (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 857BE3A1190 for ; Wed, 24 Jun 2020 14:11:46 -0700 (PDT) Received: by mail-lf1-x12f.google.com with SMTP id u25so2060476lfm.1 for ; Wed, 24 Jun 2020 14:11:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=k9m8T8AHqUovr2y+LhB65d8NgYX+lamw5bHZtN57xWg=; b=L5fHCyP38G1Mz5UWehA+Q/yVuwWbKEpTMJtSQV6n/PZp0+NWEr/cV/W0mnXGeK6Wkb 6c+hnSpxbQBG/paglbi5dlxc0mSif99hcvdPEmT5RCh+TeT5K4mIOiXNLI8tMG25YbMW Dm8JzszV9RpeeqnF5xkrLcOv9JJfwoDy9IUBh1cB+/Y7ru2c/ZrLjdbjiU7GJGDsbq5w hT5ED7LLVO4kMJbLlcBEpTbwV/t4xqwPKSy97gIbaF5AzWadxHBHkeD1/PTPJXJ9kZJl j2kzTdz+8Qm3pl/RbTkR8MKZfqZcvdszBXAdpdrO1mMWcVx2fqe78qcb05stZnx6gUke tImw== 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=k9m8T8AHqUovr2y+LhB65d8NgYX+lamw5bHZtN57xWg=; b=G8tV8WU8dJa8E8BD1l9GTZMZ4Hb9DngnjiJUQORh/3mnZK+lEhAwaNU0+jgSyby8+O VmFD5xsS2TcTigGOBYLzLj4JI8wAZrweuVlyAp42uNG9gxae/gXkKIyUId+LpTjYfyjK V67j0o5XqBM8VBtbXSDhU/I1Qy7dKYJgUjcArKrppq3V6N/ystWTzZA6PrfHuxtdbrgT BVcef3dJofTz75omCyr/IEl0Sz25hzkIea7Qw2bNerqqfZesXKb4zfVgOnJapcp6FVqj Q9/5rJD6DHjJbZVqhPuD5a0OFnLq4Ah/kyv/m+GVfywo9OvmnC+AgJdkR44jFkyysOaK LdJg== X-Gm-Message-State: AOAM530iX2yuS/A9DRmFmm+xwCSmiu3pB0M6FSGjUGiLTbLmJZ/I1ubE gQKN4yl+DtO8tDvLAM5ObLjpj6P580fFc/JuOL6GFA== X-Google-Smtp-Source: ABdhPJxYwmxZ92ZclcDMydbJcB7l8C58eu7sHgF/mr0w4p7Z/fxFJuE3RbVN38qIam2fmLGXe6DWYfa6qa70sxXjo0E= X-Received: by 2002:ac2:5f0b:: with SMTP id 11mr16413184lfq.201.1593033104598; Wed, 24 Jun 2020 14:11:44 -0700 (PDT) MIME-Version: 1.0 References: <6981a76f-76f1-e9b2-319d-473c7a4bc847@verizon.net> <6c4e402f-cce6-daff-aa16-6159340f0802@gmail.com> <9c09debe-3463-a574-46cf-cee86a2c68af@verizon.net> <15951.1592960140@localhost> <9AF4DB48-EAB5-4BFB-8FF1-E55EF0F59140@cisco.com> <20200624093933.GC47499@faui48f.informatik.uni-erlangen.de> <16FC5860-93AC-46DC-942F-9E3898CAFD73@cisco.com> <20200624200607.GA31510@faui48f.informatik.uni-erlangen.de> In-Reply-To: <20200624200607.GA31510@faui48f.informatik.uni-erlangen.de> From: Eric Rescorla Date: Wed, 24 Jun 2020 14:11:08 -0700 Message-ID: To: Toerless Eckert Cc: Eliot Lear , Michael Richardson , Stephen Kent , Anima WG Content-Type: multipart/alternative; boundary="0000000000005170a605a8daec9d" Archived-At: Subject: Re: [Anima] representing ACP info in X.509 certs X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jun 2020 21:11:50 -0000 --0000000000005170a605a8daec9d Content-Type: text/plain; charset="UTF-8" On Wed, Jun 24, 2020 at 1:06 PM Toerless Eckert wrote: > Thanks, Eliott, inline > > Btw: Just seeing that the folks holding the DISCUSS are not > explicitly included in this thread... not sure if they > follow the anima WG mailing list overall... Cc them ? > I should clarify that I am not holding a DISCUSS as I am no longer on the IESG. That's what the parentheses around my position in datatracker mean, which is to say that I dropped off the IESG while my DISCUSS was pending. To the best of my knowledge it doesn't have any special status and is just kept around as a historical reference. I certainly have opinions here, but I'm weighing in as a community member, as are Stephen, Russ, and Sean. -Ekr > On Wed, Jun 24, 2020 at 12:40:48PM +0200, Eliot Lear wrote: > > > I don't think this is true > > > > If the ACP subsystem allocates a name and the user management system > allocates a name, then you have the potential of a conflict. Again, the > odds of an actual conflict are very low. > > Whether or not there is ACP, we are talking about about an app > that has access to certificates on routers that could have rfc822name > and the app would send emails to those rfc822name addresses > and something good would happen. > > I am quite sure that such an app does not exist, but it could > be nice, so lets call it the unicorn app. The ACP rfc822name > structure certainly allows for unicorns. > > If you want to deploy ACP and you don't care about unicorns, > you ignore the issue. The conflict you are talking about would > only hurt the unicorn but not the ACP. > > When you do care for unicorns you have several options: > > a) You can make sure that the local part name space is well managed > so local part names for ACP can not be incorrectly assigned > to other purposes. Likely works by default because common > solutions that let users assign local names or aliases have > length limits < ~ 30 characters and ACP local part is 40 + X > (X being extensions). Upper limit in rfc822name is btw 64 > for local name part. > > b) You use a different name or subdomain (see) to separate > name spaces between users and the names you use inside > network operations / ACP. Most common solution IMHO. > > c) You train the unicorn to forward the names based on where > they are found to another domain. typical setup in email > ssytem when there are logical names but distributed MTA. > > > You can make an operational recommendation of course. However, some > enterprises simply do not do subdomains (I email from one such enterprise > now). > > Different (Sub)domains are the standard tool to separate > local-part namespaces in rfc822. It is widely used in > enterprises > > Do not confuse what you as the user see with whats under > the hood in RFC822. As soon as you have multi-vendor > distributed MT setups you will use different subdomains > under the hood with forwarding and name aliasing/hiding. > The vendor you work for even sells comms products with MTA > in them that would do that last i checked (couple years back). > I am sure if you could look at the whole domain space of > your employer, you would find a lot of subdomains, including > for other MTAs. > > But then again, whatever is visible to the outside, both > domains and local name parts is subject to corporate comms > policies, so indeed it is likely that subdomains would only > be available to what that department likes. Many > network operations orgs in SP/enterprise therefore just > buy their own domain name that has nothing to do wih > their enterprises "brand" domain name and use that other > domain to freely asign names for routers, network exquipment > and network ops related MTA, web servers etc. And then make > sure none of these domain names are on public accessible > DNS servers/zones. > > So, if example.com was a typical brand-marketing lead enterprise, > the network ops teams would ask to get acp.example.com and > even though they may actually run the example.com DNS and MTAs, > they wouldn't be the one permitted to decide whats on it, > so after four months of discussion, the network ops team > would go buy example.org and use acp.example.org. > > > > | Certificates for an ACP MUST only be given to nodes that are allowed > > > | to be members of that ACP. Because the signing CA relies on an ACP > > > | Registrar, the CA MUST only sign certificates with ACP domain > > > | information through trusted ACP Registrars. Any existing CA, > unaware > > > | of the new ACP domain information field, can be used as long as it > > > | only allows signing requests from trusted ACP Registrars and from > > > | nodes or registrars trusted not to include ACP domain information in > > > | their certificates. > > > > Ok, but... > > > > > | These requirements can be achieved by using TA private to the owner > > > | of the ACP domain or potentially through appropriate contractual > > > | agreements between the involved parties. Public CA without such > > > | obligations and guarantees can not be used as TA for ACP domains, > but > > > | they can be used to obtain certificates for TAs of ACP domain. > > > > > > Aka: The ACP trust model is built on controlled access TA and > > > specific functionality registrar, it does not matter at all which > > > field the information is encoded into for the trust model described. > > > > If the TA is itself signed by a public CA, then the CA can sign other > names or for that matter issue other signing certs , and (at least by > normal use of PKI) the name will validate without the TA ever having been > used. Assuming that???s not what you mean, how does the client know which > TA is authorized? > > ACP nodes are initialized before ACP can run by a registrar > with a cert and the appropriate TA. Cert and TA are renewed > via EST automatically before they expire. So TA are fully > controlled by the registrar(s). > > The public CA would never be a feasible TA. Only the private root cert > would be an appropriate TA. Whether that private root cert is > self-signed or signed by a public CA is irrelevant, that would > not change the result of an ACP cert chain validation: The > cert chain validation MUST terminate in a TA. The attackers > cert you mention would only be signed by the public CA, which is > not a TA for the ACP. > > I don't think there is any benefit of letting private root CA certs > as required by ACP to be signed by public CA today. Thats also > not done with any of the private root CA certs i know from > enterprises, so nothing new here with ACP. > > With ACME mail we would get new options, but one has to see how > more beneficial they are from just having an enterprise run its > own private CA solution. You can easily buy private CA solutions > as a cloud service from the usual suspectsa. I think the ACME > stuff is primarily when you do want to use the certs for > external authentication, which ACP wouldn't need unless we > go into maybe future ACP for federations. > > > > Actually right now my personal recommendation would be to allocate that > > > email address (prefix) rfcSELF{+...}@.. to the ACP admin to see if > there was ever > > > some unintended side effect such as email to that address > > > that was generated by other software. > > > > I like that idea. > > Cheers > Toerless > > > > Btw: ANIMA and ACME folks had a side meeting last year (i think you > > > where there ?!), and of course one of the ideas is to be able > > > to use ACME mail signed certs in the future, but this is outside > > > the scope of the document. But the recommendation > > > in the doc to use an ACP domain name part that you own already > > > prepares for that, so i think it should be fairly easy to use > > > in the future ACME web PKI as TA just from the perspective of > > > using the ACP rfc822name as the validation email mechanism. There > > > may be other ACME issues to resolve though. > > > > > >> It???s not perfect. > > > > > > Thats how i started to think of initially as well coming from > > > just the problem of how to overcome ossification of the ecosystem > > > we have to deal with. But in the meantime i think the format > > > of rfc822name is near perfect for both human consumption as well > > > as for managing it - has domain-name to tie into something you > > > can have authoritatively. > > > > > >> That???s the nature of an expedient. But it???s probably Good Enough > for now. For the eventuality that another name could be used over time, > it???s probably worth getting an OID and using otherName where possible, > but we shouldn???t hold this work up over a highly theoretical attack. > > > > > > I think the reason for solutions that like to reuse the > > > rfc822name format of local@domain but choose new encoding > > > points is so that they can reuse existing local@domain > > > user identifiers but indicate a specific app. Much > > > like a uri scheme of newapp:local@domain > > > > This requires a broader discussion that need not hold up this draft. > > > > Eliot > > > > > > In the case of ACP this is not necessary, because we > > > simply distinguish on the local part and/or the domain > > > name. No need to support overloading of the same rfc822names > > > for different uses. That is something more relevant to > > > humans who like to have a single local@domain ID for > > > themselves across all apps. ACP IDs are more functional IDs. > > > > > > Cheers > > > Toerless > > > > > >> Eliot > > > > > > > > > > > >> _______________________________________________ > > >> Anima mailing list > > >> Anima@ietf.org > > >> https://www.ietf.org/mailman/listinfo/anima > > > > > > > > > -- > > > --- > > > tte@cs.fau.de > > > > -- > --- > tte@cs.fau.de > --0000000000005170a605a8daec9d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Jun 24, 2020 at 1:06 PM Toerl= ess Eckert <tte@cs.fau.de> wrote= :
Thanks, Eliott= , inline

Btw: Just seeing that the folks holding the DISCUSS are not
explicitly included in this thread... not sure if they
follow the anima WG mailing list overall... Cc them ?
=
I should clarify that I am not holding a DISCUSS as I am no = longer on the IESG. That's what the parentheses around my position in d= atatracker mean, which is to say that I dropped off the IESG while my DISCU= SS was pending. To the best of my knowledge it doesn't have any special= status and is just kept around as a historical reference.
I certainly have opinions here, but I'm weighing in as a = community member, as are Stephen, Russ, and Sean.

<= div>-Ekr



On Wed, Jun 24, 2020 at 12:40:48PM +0200, Eliot Lear wrote:
> > I don't think this is true
>
> If the ACP subsystem allocates a name and the user management system a= llocates a name, then you have the potential of a conflict.=C2=A0 Again, th= e odds of an actual conflict are very low.

Whether or not there is ACP, we are talking about about an app
that has access to certificates on routers that could have rfc822name
and the app would send emails to those rfc822name addresses
and something good would happen.

I am quite sure that such an app does not exist, but it could
be nice, so lets call it the unicorn app. The ACP rfc822name
structure certainly allows for unicorns.

If you want to deploy ACP and you don't care about unicorns,
you ignore the issue. The conflict you are talking about would
only hurt the unicorn but not the ACP.

When you do care for unicorns you have several options:

a) You can make sure that the local part name space is well managed
so local part names for ACP can not be incorrectly assigned
to other purposes. Likely works by default because common
solutions that let users assign local names or aliases have
length limits < ~ 30 characters and ACP local part is 40 + X
(X being extensions). Upper limit in rfc822name is btw 64
for local name part.

b) You use a different name or subdomain (see) to separate
name spaces between users and the names you use inside
network operations / ACP. Most common solution IMHO.

c) You train the unicorn to forward the names based on where
they are found to another domain. typical setup in email
ssytem when there are logical names but distributed MTA.

> You can make an operational recommendation of course.=C2=A0 However, s= ome enterprises simply do not do subdomains (I email from one such enterpri= se now).

Different (Sub)domains are the standard tool to separate
local-part namespaces in rfc822. It is widely used in
enterprises

Do not confuse what you as the user see with whats under
the hood in RFC822. As soon as you have multi-vendor
distributed MT setups you will use different subdomains
under the hood with forwarding and name aliasing/hiding.
The vendor you work for even sells comms products with MTA
in them that would do that last i checked (couple years back).
I am sure if you could look at the whole domain space of
your employer, you would find a lot of subdomains, including
for other MTAs.

But then again, whatever is visible to the outside, both
domains and local name parts is subject to corporate comms
policies, so indeed it is likely that subdomains would only
be available to what that department likes. Many
network operations orgs in SP/enterprise therefore just
buy their own domain name that has nothing to do wih
their enterprises "brand" domain name and use that other
domain to freely asign names for routers, network exquipment
and network ops related MTA, web servers etc. And then make
sure none of these domain names are on public accessible
DNS servers/zones.

So, if = example.com was a typical brand-marketing lead enterprise,
the network ops teams would ask to get acp.example.com and
even though they may actually run the example.com DNS and MTAs,
they wouldn't be the one permitted to decide whats on it,
so after four months of discussion, the network ops team
would go buy example.org and use acp.example.org.

> > |=C2=A0 Certificates for an ACP MUST only be given to nodes that = are allowed
> > |=C2=A0 to be members of that ACP.=C2=A0 Because the signing CA r= elies on an ACP
> > |=C2=A0 Registrar, the CA MUST only sign certificates with ACP do= main
> > |=C2=A0 information through trusted ACP Registrars.=C2=A0 Any exi= sting CA, unaware
> > |=C2=A0 of the new ACP domain information field, can be used as l= ong as it
> > |=C2=A0 only allows signing requests from trusted ACP Registrars = and from
> > |=C2=A0 nodes or registrars trusted not to include ACP domain inf= ormation in
> > |=C2=A0 their certificates.
>
> Ok, but...
>
> > |=C2=A0 These requirements can be achieved by using TA private to= the owner
> > |=C2=A0 of the ACP domain or potentially through appropriate cont= ractual
> > |=C2=A0 agreements between the involved parties.=C2=A0 Public CA = without such
> > |=C2=A0 obligations and guarantees can not be used as TA for ACP = domains, but
> > |=C2=A0 they can be used to obtain certificates for TAs of ACP do= main.
> >
> > Aka: The ACP trust model is built on controlled access TA and > > specific functionality registrar, it does not matter at all which=
> > field the information is encoded into for the trust model describ= ed.
>
> If the TA is itself signed by a public CA, then the CA can sign other = names or for that matter issue other signing certs , and (at least by norma= l use of PKI) the name will validate without the TA ever having been used.= =C2=A0 Assuming that???s not what you mean, how does the client know which = TA is authorized?

ACP nodes are initialized before ACP can run by a registrar
with a cert and the appropriate TA.=C2=A0 Cert and TA are renewed
via EST automatically before they expire. So TA are fully
controlled by the registrar(s).

The public CA would never be a feasible TA. Only the private root cert
would be an appropriate TA. Whether that private root cert is
self-signed or signed by a public CA is irrelevant, that would
not change the result of an ACP cert chain validation: The
cert chain validation MUST terminate in a TA. The attackers
cert you mention would only be signed by the public CA, which is
not a TA for the ACP.

I don't think there is any benefit of letting private root CA certs
as required by ACP to be signed by public CA today. Thats also
not done with any of the private root CA certs i know from
enterprises, so nothing new here with ACP.

With ACME mail we would get new options, but one has to see how
more beneficial they are from just having an enterprise run its
own private CA solution. You can easily buy private CA solutions
as a cloud service from the usual suspectsa. I think the ACME
stuff is primarily when you do want to use the certs for
external authentication, which ACP wouldn't need unless we
go into maybe future ACP for federations.

> > Actually right now my personal recommendation would be to allocat= e that
> > email address (prefix) rfcSELF{+...}@.. to the ACP admin to see i= f there was ever
> > some unintended side effect such as email to that address
> > that was generated by other software.
>
> I like that idea.

Cheers
=C2=A0 =C2=A0 Toerless

> > Btw: ANIMA and ACME folks had a side meeting last year (i think y= ou
> > where there ?!), and of course one of the ideas is to be able
> > to use ACME mail signed certs in the future, but this is outside<= br> > > the scope of the document. But the recommendation
> > in the doc to use an ACP domain name part that you own already > > prepares for that, so i think it should be fairly easy to use
> > in the future ACME web PKI as TA just from the perspective of
> > using the ACP rfc822name as the validation email mechanism. There=
> > may be other ACME issues to resolve though.
> >
> >> It???s not perfect.
> >
> > Thats how i started to think of initially as well coming from
> > just the problem of how to overcome ossification of the ecosystem=
> > we have to deal with. But in the meantime i think the format
> > of rfc822name is near perfect for both human consumption as well<= br> > > as for managing it - has domain-name to tie into something you > > can have authoritatively.
> >
> >> That???s the nature of an expedient.=C2=A0 But it???s probabl= y Good Enough for now.=C2=A0 For the eventuality that another name could be= used over time, it???s probably worth getting an OID and using otherName w= here possible, but we shouldn???t hold this work up over a highly theoretic= al attack.
> >
> > I think the reason for solutions that like to reuse the
> > rfc822name format of local@domain but choose new encoding
> > points is so that they can reuse existing local@domain
> > user identifiers but indicate a specific app. Much
> > like a uri scheme of newapp:local@domain
>
> This requires a broader discussion that need not hold up this draft. >
> Eliot
> >
> > In the case of ACP this is not necessary, because we
> > simply distinguish on the local part and/or the domain
> > name. No need to support overloading of the same rfc822names
> > for different uses. That is something more relevant to
> > humans who like to have a single local@domain ID for
> > themselves across all apps. ACP IDs are more functional IDs.
> >
> > Cheers
> >=C2=A0 =C2=A0 Toerless
> >
> >> Eliot
> >
> >
> >
> >> _______________________________________________
> >> Anima mailing list
> >> Anima@iet= f.org
> >> https://www.ietf.org/mailman/listinfo/ani= ma
> >
> >
> > --
> > ---
> > tte@cs.fau.de<= /a>
>

--
---
tte@cs.fau.de
--0000000000005170a605a8daec9d-- From nobody Fri Jun 26 14:56:53 2020 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00B303A0CDB; Fri, 26 Jun 2020 14:56: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, 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 vDesNArbJ1Mb; Fri, 26 Jun 2020 14:56:45 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 248D33A0CBE; Fri, 26 Jun 2020 14:56:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 21B5C389A1; Fri, 26 Jun 2020 17:54:00 -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 mJYdoEzqxphY; Fri, 26 Jun 2020 17:53:58 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id BDC0C389A0; Fri, 26 Jun 2020 17:53:58 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 2A838F5; Fri, 26 Jun 2020 17:56:42 -0400 (EDT) From: Michael Richardson To: spasm@ietf.org, Russ Housley , anima@ietf.org, Ben Kaduk CC: Nico Williams , Ryan Sleevi In-Reply-To: References: <20200624023407.GA41244@faui48f.informatik.uni-erlangen.de> 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: [Anima] on certification authorities. X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jun 2020 21:56:47 -0000 --=-=-= Content-Type: text/plain Russ Housley wrote: > Thank you. Many people get it wrong, but X.509 and RFC 5280 (as well > as the earlier versions in RFC 2459 and RFC 3280) all use > {CA=} "certification authority". I guess it might be worth spreading this point more widely :-) I'll all for stamping out the wrong expansions, even if it sometimes seems pendantic. I'm told that Google is about to start their Cloud *Certificate* Authority. If that happens, I believe that any chance to assert the term will be completely lost :-) On the other hand, if they go with "certification authority", then perhaps the tide of the terminology will be reversed. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl72bxkACgkQgItw+93Q 3WWVnQf+PbQH5kxqc+k5oGlEk0ziTLghz1BAboDztzOfyjEwsOZTbpORX1P7oZLU UWufR9LUfFVBTgOyP5ZYwJdhFEifdRwZJny/yFQvQEVDRSoRgFq41PNi3yzxp9ea wDuR2p1aCHdb888HrM9HZsR0sTRhwflbGxWCn0+hSoks6mpmkw+/+EvR1v3UENKt x942eJ9kidSzmmm9CXFTFROniYSgpVzGY99MCsKpmBuP5kgX7p7sVzWUprEyive9 WBJujsSFiZBG+rtgEyXu9aMglMJUa8sLD2gEbD0bzgOydRxJ8KYl1G1v07B9Wumm gGs1YNSJEVSp+UxMNMt0MbdfAVbQ1Q== =sEPI -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Jun 26 15:02:40 2020 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24EAC3A0CE3; Fri, 26 Jun 2020 15:02:39 -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 DPijPFhR4b-B; Fri, 26 Jun 2020 15:02:37 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35EAD3A0CDD; Fri, 26 Jun 2020 15:02:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 76C76389A1; Fri, 26 Jun 2020 17:59:49 -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 n3m027bpctID; Fri, 26 Jun 2020 17:59:48 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 2E7D3389A0; Fri, 26 Jun 2020 17:59:48 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 908BEF5; Fri, 26 Jun 2020 18:02:31 -0400 (EDT) From: Michael Richardson To: Russ Housley , Toerless Eckert , anima@ietf.org, Ben Kaduk , saag@ietf.org In-Reply-To: References: <20200624023407.GA41244@faui48f.informatik.uni-erlangen.de> 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: [Anima] towards using of MUST-/SHOULD+/SHOULD- in draft-ietf-autonomic-control-plane-24 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jun 2020 22:02:39 -0000 --=-=-= Content-Type: text/plain Russ Housley wrote: >> ACP nodes MUST NOT support certificates with RSA public keys of >> less than 2048 bits. They MUST support certificates with RSA public keys >> with 2048 bits and SHOULD support longer RSA keys. ACP nodes MUST >> support certificates with ECC public keys using NIST P-256, P-384 and >> P-521 curves. >> >> ACP nodes MUST support SHA-256, SHA-384, SHA-512 signatures for certificates with RSA key and the same RSA signatures plus ECDSA signatures for certificates with ECC key. >> --- >> >> I don't understand whether your note about the key length of the curves is an indication of missing text. When i first reviewed with Ben, i had to enter the curves because thats as specific as necessary AFAIK, but given how the key length is implied, i wouldn't understand why i would need to write those down. I don't remember that i have seen that being done either in other RFCs i read through. >> >> In any case, specific text suggestions always welcome in case this text is not sufficient. russ> I was expecting you to make one of the curves MUST and the others russ> SHOULD. Making all three curves MUST is okay with me, but it will russ> increase implementation size. russ> Likewise, I was expecting you to make one of the hash functions russ> MUST and the others SHOULD. I tried to convince Toerless to go with the MUST-/SHOULD+/SHOULD- terminology from IPsecME's RFC8247. It would be nice if SAAG lifted section 1.1 into a BCP14-like document, as I think that it has widespread applicability throughout documents that want to establish interoperable crypto. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl72cHcACgkQgItw+93Q 3WVgNwf/Yo3HWY/7sxuu8HVimbEV2EI5EWvwrZE6TH7Ngj40wsAyClcBjoZdVDGf +xpXiSj9l7COWxUeKbjzep1uZL4yaQ6j/ywEnSLlLPIGfAzmDIxNpReYvPtDjURq BuODyIU8tGuTmUlDNIFUohrX8ElvPr6Qti9q/uYT6NlRkjcHmE8m6iJJraDqpwM2 rsciYMWEsSlHBJRTKpFjGdyVwyVG6gcFVjn4eSJeV1HuIQaLaY8bRQVGYOAcGHp4 EAqbsSO9mvuAIB8CYcLvNHWywd0yAeUQHtsIKwUQH+abKdAH2LItt4VIXp8smaC0 lsQCczHSzszj9gnmtZGIxuY8TP5FhQ== =IrHI -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Jun 26 15:04:54 2020 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 587F23A0CE5; Fri, 26 Jun 2020 15:04:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-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=cryptonector.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 GraGu44BaHuv; Fri, 26 Jun 2020 15:04:51 -0700 (PDT) Received: from bird.elm.relay.mailchannels.net (bird.elm.relay.mailchannels.net [23.83.212.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 3FCB73A0CE4; Fri, 26 Jun 2020 15:04:49 -0700 (PDT) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 2C0391E0EA3; Fri, 26 Jun 2020 22:04:49 +0000 (UTC) Received: from pdx1-sub0-mail-a15.g.dreamhost.com (100-96-23-8.trex.outbound.svc.cluster.local [100.96.23.8]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 67A3A1E1255; Fri, 26 Jun 2020 22:04:48 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from pdx1-sub0-mail-a15.g.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.18.8); Fri, 26 Jun 2020 22:04:49 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com X-MailChannels-Auth-Id: dreamhost X-Absorbed-Bubble: 2d677f5e17533c28_1593209088910_198106182 X-MC-Loop-Signature: 1593209088910:1891334799 X-MC-Ingress-Time: 1593209088910 Received: from pdx1-sub0-mail-a15.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a15.g.dreamhost.com (Postfix) with ESMTP id 2A1C27F081; Fri, 26 Jun 2020 15:04:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=Yq23/ANPjKPXZC 12YmFWhdLtWJo=; b=g97my4gRGyzFmCc8NonREQb12uq6BfrLlbd6CiUk1lCQhC CvykyiXKDAyNBaKbs/JC4YV+thz4y08qI0fd2v30gRdH4oU0PY6d58VylWvt/hWZ pUd2EOZYDbKaq74wQbRaEtrUiYSrMTBnNAzx8/D96nI3IVHwK+sdwV/q6XB0I= Received: from localhost (unknown [24.28.108.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by pdx1-sub0-mail-a15.g.dreamhost.com (Postfix) with ESMTPSA id 064797F07F; Fri, 26 Jun 2020 15:04:45 -0700 (PDT) Date: Fri, 26 Jun 2020 17:04:42 -0500 X-DH-BACKEND: pdx1-sub0-mail-a15 From: Nico Williams To: Michael Richardson Cc: spasm@ietf.org, Russ Housley , anima@ietf.org, Ben Kaduk , Ryan Sleevi Message-ID: <20200626220441.GW3100@localhost> References: <20200624023407.GA41244@faui48f.informatik.uni-erlangen.de> <13005.1593208602@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <13005.1593208602@localhost> User-Agent: Mutt/1.9.4 (2018-02-28) X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: -100 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduhedrudelvddgtdeiucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuggftfghnshhusghstghrihgsvgdpffftgfetoffjqffuvfenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhepfffhvffukfhfgggtuggjfgesthdtredttdervdenucfhrhhomheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqeenucggtffrrghtthgvrhhnpefftdektefhueetveeigfefgeejteejvdfhhefgvddtfeeujeehleeguefhgffhgfenucfkphepvdegrddvkedruddtkedrudekfeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhhouggvpehsmhhtphdphhgvlhhopehlohgtrghlhhhoshhtpdhinhgvthepvdegrddvkedruddtkedrudekfedprhgvthhurhhnqdhprghthheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqedpmhgrihhlfhhrohhmpehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmpdhnrhgtphhtthhopehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhm Archived-At: Subject: Re: [Anima] on certification authorities. X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jun 2020 22:04:52 -0000 On Fri, Jun 26, 2020 at 05:56:42PM -0400, Michael Richardson wrote: > Russ Housley wrote: > > Thank you. Many people get it wrong, but X.509 and RFC 5280 (as well > > as the earlier versions in RFC 2459 and RFC 3280) all use > > {CA=} "certification authority". > > I guess it might be worth spreading this point more widely :-) > I'll all for stamping out the wrong expansions, even if it sometimes > seems pendantic. > > I'm told that Google is about to start their Cloud *Certificate* > Authority. If that happens, I believe that any chance to assert the > term will be completely lost :-) Then clearly they have not read the specs and have no idea what they're doing!!1! :^) Just like with IpSec. Nico -- From nobody Fri Jun 26 15:09:04 2020 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAAFD3A0D12; Fri, 26 Jun 2020 15:09:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-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=cryptonector.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 r08X1sTeHBZ4; Fri, 26 Jun 2020 15:08:58 -0700 (PDT) Received: from aye.elm.relay.mailchannels.net (aye.elm.relay.mailchannels.net [23.83.212.6]) (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 1E4953A0D07; Fri, 26 Jun 2020 15:08:57 -0700 (PDT) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 764E5481008; Fri, 26 Jun 2020 22:08:56 +0000 (UTC) Received: from pdx1-sub0-mail-a15.g.dreamhost.com (100-96-23-5.trex.outbound.svc.cluster.local [100.96.23.5]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 01078480DE4; Fri, 26 Jun 2020 22:08:55 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from pdx1-sub0-mail-a15.g.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.18.8); Fri, 26 Jun 2020 22:08:56 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com X-MailChannels-Auth-Id: dreamhost X-Blushing-Bitter: 7c55c7e929ac9496_1593209336265_1978622880 X-MC-Loop-Signature: 1593209336265:1496277518 X-MC-Ingress-Time: 1593209336265 Received: from pdx1-sub0-mail-a15.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a15.g.dreamhost.com (Postfix) with ESMTP id B63967F05D; Fri, 26 Jun 2020 15:08:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=MAtL7mc1RQlelr tiZ7Dbcty2CPM=; b=Qw3Nenffps3vu5lMBbHNALvon+WfynDAa3hopV8a6J/x8Y 37AKqK2ytu+rd50N9vfUdTizLd9WmyKEtfNB1LLygbuRjJAGTpaaVrIlAQ8mOE5a jlhAhcp0EQNHhOvaMEi1R38YCM0HEo0TG0vL5fQjveUdfd6fFZIprtinIUf8E= Received: from localhost (unknown [24.28.108.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by pdx1-sub0-mail-a15.g.dreamhost.com (Postfix) with ESMTPSA id 7A90B7F073; Fri, 26 Jun 2020 15:08:52 -0700 (PDT) Date: Fri, 26 Jun 2020 17:08:49 -0500 X-DH-BACKEND: pdx1-sub0-mail-a15 From: Nico Williams To: Michael Richardson Cc: Russ Housley , Toerless Eckert , anima@ietf.org, Ben Kaduk , saag@ietf.org Message-ID: <20200626220847.GX3100@localhost> References: <20200624023407.GA41244@faui48f.informatik.uni-erlangen.de> <14352.1593208951@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <14352.1593208951@localhost> User-Agent: Mutt/1.9.4 (2018-02-28) X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: -100 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduhedrudelvddgtdejucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuggftfghnshhusghstghrihgsvgdpffftgfetoffjqffuvfenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhepfffhvffukfhfgggtuggjfgesthdtredttdervdenucfhrhhomheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqeenucggtffrrghtthgvrhhnpefftdektefhueetveeigfefgeejteejvdfhhefgvddtfeeujeehleeguefhgffhgfenucfkphepvdegrddvkedruddtkedrudekfeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhhouggvpehsmhhtphdphhgvlhhopehlohgtrghlhhhoshhtpdhinhgvthepvdegrddvkedruddtkedrudekfedprhgvthhurhhnqdhprghthheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqedpmhgrihhlfhhrohhmpehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmpdhnrhgtphhtthhopehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhm Archived-At: Subject: Re: [Anima] [saag] towards using of MUST-/SHOULD+/SHOULD- in draft-ietf-autonomic-control-plane-24 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jun 2020 22:09:02 -0000 On Fri, Jun 26, 2020 at 06:02:31PM -0400, Michael Richardson wrote: > I tried to convince Toerless to go with the MUST-/SHOULD+/SHOULD- > terminology from IPsecME's RFC8247. > > It would be nice if SAAG lifted section 1.1 into a BCP14-like > document, as I think that it has widespread applicability throughout > documents that want to establish interoperable crypto. Is there are reason that RFC8247's {MUST,SHOULD}[-+] wouldn't be generally applicable beyond crypto? The -/+ thing is about pithily indicating likelihood of future downgrade/upgrade of the requirement/ recommendation -- seems generally applicable to me. So.. just update RFC2119. Nico -- From nobody Fri Jun 26 16:58:32 2020 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2D6F3A0D29 for ; Fri, 26 Jun 2020 16:58:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=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 sfiL2b2M8Dqa for ; Fri, 26 Jun 2020 16:58:29 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26A563A0D27 for ; Fri, 26 Jun 2020 16:58:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id A63E1300B33 for ; Fri, 26 Jun 2020 19:58:26 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id Xl2sUrF-VEud for ; Fri, 26 Jun 2020 19:58:24 -0400 (EDT) Received: from a860b60074bd.fios-router.home (pool-72-66-113-56.washdc.fios.verizon.net [72.66.113.56]) by mail.smeinc.net (Postfix) with ESMTPSA id F1CC6300A93; Fri, 26 Jun 2020 19:58:23 -0400 (EDT) From: Russ Housley Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_02CA01BA-1A25-4870-BBE0-2E93295B82B6"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.14\)) Date: Fri, 26 Jun 2020 19:58:24 -0400 In-Reply-To: <14352.1593208951@localhost> Cc: Toerless Eckert , anima@ietf.org, Ben Kaduk , IETF SAAG To: Michael Richardson References: <20200624023407.GA41244@faui48f.informatik.uni-erlangen.de> <14352.1593208951@localhost> X-Mailer: Apple Mail (2.3445.104.14) Archived-At: Subject: Re: [Anima] towards using of MUST-/SHOULD+/SHOULD- in draft-ietf-autonomic-control-plane-24 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jun 2020 23:58:31 -0000 --Apple-Mail=_02CA01BA-1A25-4870-BBE0-2E93295B82B6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Jun 26, 2020, at 6:02 PM, Michael Richardson = wrote: >=20 >=20 > Russ Housley wrote: >>> ACP nodes MUST NOT support certificates with RSA public keys of >>> less than 2048 bits. They MUST support certificates with RSA public = keys >>> with 2048 bits and SHOULD support longer RSA keys. ACP nodes MUST >>> support certificates with ECC public keys using NIST P-256, P-384 = and >>> P-521 curves. >>>=20 >>> ACP nodes MUST support SHA-256, SHA-384, SHA-512 signatures for = certificates with RSA key and the same RSA signatures plus ECDSA = signatures for certificates with ECC key. >>> --- >>>=20 >>> I don't understand whether your note about the key length of the = curves is an indication of missing text. When i first reviewed with Ben, = i had to enter the curves because thats as specific as necessary AFAIK, = but given how the key length is implied, i wouldn't understand why i = would need to write those down. I don't remember that i have seen that = being done either in other RFCs i read through. >>>=20 >>> In any case, specific text suggestions always welcome in case this = text is not sufficient. >=20 > russ> I was expecting you to make one of the curves MUST and the = others > russ> SHOULD. Making all three curves MUST is okay with me, but it = will > russ> increase implementation size. >=20 > russ> Likewise, I was expecting you to make one of the hash = functions > russ> MUST and the others SHOULD. >=20 > I tried to convince Toerless to go with the MUST-/SHOULD+/SHOULD- = terminology from > IPsecME's RFC8247. >=20 > It would be nice if SAAG lifted section 1.1 into a BCP14-like = document, as I > think that it has widespread applicability throughout documents that = want to > establish interoperable crypto. IPsec ad S/MIME have been using MUST-/SHOULD+/SHOULD- terminology for a = long time. I'd be willing to help with a BCP14-like document for them. Russ --Apple-Mail=_02CA01BA-1A25-4870-BBE0-2E93295B82B6 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iF0EARECAB0WIQRJuTEKFXbtfFQz5huK5O7Q9ZwRywUCXvaLoAAKCRCK5O7Q9ZwR y2BmAJwNvF8oJw08D7VO4EynZHSzAzHJHQCeOFqoyE+Hn68YPzvZYfsSyfZTOmA= =jiQt -----END PGP SIGNATURE----- --Apple-Mail=_02CA01BA-1A25-4870-BBE0-2E93295B82B6-- From nobody Fri Jun 26 18:15:28 2020 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B7E53A081B; Fri, 26 Jun 2020 18:15:26 -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 Om0Q-aw544Ye; Fri, 26 Jun 2020 18:15:23 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B09003A07C0; Fri, 26 Jun 2020 18:15:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id E21E838995; Fri, 26 Jun 2020 21:12:36 -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 B53N7CRMATJJ; Fri, 26 Jun 2020 21:12:35 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 99FD538991; Fri, 26 Jun 2020 21:12:35 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 24DDE8D; Fri, 26 Jun 2020 21:15:19 -0400 (EDT) From: Michael Richardson To: Nico Williams , Russ Housley , Toerless Eckert , anima@ietf.org, Ben Kaduk , saag@ietf.org In-Reply-To: <20200626220847.GX3100@localhost> References: <20200624023407.GA41244@faui48f.informatik.uni-erlangen.de> <14352.1593208951@localhost> <20200626220847.GX3100@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: [Anima] [saag] towards using of MUST-/SHOULD+/SHOULD- in draft-ietf-autonomic-control-plane-24 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jun 2020 01:15:26 -0000 --=-=-= Content-Type: text/plain Nico Williams wrote: > On Fri, Jun 26, 2020 at 06:02:31PM -0400, Michael Richardson wrote: >> I tried to convince Toerless to go with the MUST-/SHOULD+/SHOULD- >> terminology from IPsecME's RFC8247. >> >> It would be nice if SAAG lifted section 1.1 into a BCP14-like >> document, as I think that it has widespread applicability throughout >> documents that want to establish interoperable crypto. > Is there are reason that RFC8247's {MUST,SHOULD}[-+] wouldn't be > generally applicable beyond crypto? The -/+ thing is about pithily > indicating likelihood of future downgrade/upgrade of the requirement/ > recommendation -- seems generally applicable to me. > So.. just update RFC2119. 1) So, BCPs can point to multiple documents. BCP14 actually is RFC2119 and RFC8174 now, so we can add a third document if desired. That is, it's cheaper to not spin 2119. 2) I'm not claiming others won't use it, I just don't know if they will. Crypto progresses... what other things do that in the same way? -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl72naYACgkQgItw+93Q 3WXsoQf+L9M3Ebcm6GI5Ma6zqE4hjTE+Rfv0yvvOjwFCIdQlTdV+1WeyPOxxgZ5a baa0+AEABL579bkC4lgCOPgbOTOFXZ1LcJTHgPAbYRwaQE+BtOkl6uwCJNdy6kfz Dd3CZMt1W9tjtwLPKol4ITlPMAs1FiG9UXWI8qa5TEOxGGZ6Qxmd1iSCggVVa+vc vtogptRIfGQVsZyR19qSFP0b33c0uP+szU11UEDytABCLaCjkYMR8W3xrIqJ4/9o 9/gdJDWS9NpgIam9D0ZKlKC3qtoY5OSaelSsm8w5MB5jLG8g3xyJAhGlvWiF/DSL aclVlf22Xe6LWWYZh0gtgT4eWzBqZA== =7i90 -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Jun 26 20:06:42 2020 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B87CB3A098C; Fri, 26 Jun 2020 20:06:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-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=cryptonector.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 kmK04TAA918v; Fri, 26 Jun 2020 20:06:39 -0700 (PDT) Received: from black.elm.relay.mailchannels.net (black.elm.relay.mailchannels.net [23.83.212.19]) (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 A7CDE3A097F; Fri, 26 Jun 2020 20:06:38 -0700 (PDT) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 7E5867E14A2; Sat, 27 Jun 2020 03:06:37 +0000 (UTC) Received: from pdx1-sub0-mail-a37.g.dreamhost.com (100-96-19-6.trex.outbound.svc.cluster.local [100.96.19.6]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id E9EB47E10FA; Sat, 27 Jun 2020 03:06:36 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from pdx1-sub0-mail-a37.g.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.18.8); Sat, 27 Jun 2020 03:06:37 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com X-MailChannels-Auth-Id: dreamhost X-Robust-Cooing: 3b4d6dea220e19b7_1593227197341_2479348239 X-MC-Loop-Signature: 1593227197341:3968239992 X-MC-Ingress-Time: 1593227197341 Received: from pdx1-sub0-mail-a37.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a37.g.dreamhost.com (Postfix) with ESMTP id A5610B2B2E; Fri, 26 Jun 2020 20:06:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=TeAOYnjQ+LfNgP 0rg6wD32hlTeM=; b=JILNocdWuDCvUVd4E0OaEdFVzJSJpurs69E/Pr8PH9m/8p ZkHs40RHqFCenOF2RyyzhAynEiPcU2SRDCXqA3k47gOb3T7HoGEZSRFhcVgIROaf A2HXFw1DnPB7peYuipo8ZNn9YWqcngdBbGIazg6Y+nyYlXVA2gjcN6oFlkoOY= Received: from localhost (unknown [24.28.108.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by pdx1-sub0-mail-a37.g.dreamhost.com (Postfix) with ESMTPSA id A8F66B2B34; Fri, 26 Jun 2020 20:06:30 -0700 (PDT) Date: Fri, 26 Jun 2020 22:06:24 -0500 X-DH-BACKEND: pdx1-sub0-mail-a37 From: Nico Williams To: Michael Richardson Cc: Russ Housley , Toerless Eckert , anima@ietf.org, Ben Kaduk , saag@ietf.org Message-ID: <20200627030622.GZ3100@localhost> References: <20200624023407.GA41244@faui48f.informatik.uni-erlangen.de> <14352.1593208951@localhost> <20200626220847.GX3100@localhost> <30682.1593220519@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <30682.1593220519@localhost> User-Agent: Mutt/1.9.4 (2018-02-28) X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: -100 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduhedrudelvddgieekucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuggftfghnshhusghstghrihgsvgdpffftgfetoffjqffuvfenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhepfffhvffukfhfgggtuggjfgesthdtredttdervdenucfhrhhomheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqeenucggtffrrghtthgvrhhnpefftdektefhueetveeigfefgeejteejvdfhhefgvddtfeeujeehleeguefhgffhgfenucfkphepvdegrddvkedruddtkedrudekfeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhhouggvpehsmhhtphdphhgvlhhopehlohgtrghlhhhoshhtpdhinhgvthepvdegrddvkedruddtkedrudekfedprhgvthhurhhnqdhprghthheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqedpmhgrihhlfhhrohhmpehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmpdhnrhgtphhtthhopehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhm Archived-At: Subject: Re: [Anima] [saag] towards using of MUST-/SHOULD+/SHOULD- in draft-ietf-autonomic-control-plane-24 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jun 2020 03:06:41 -0000 On Fri, Jun 26, 2020 at 09:15:19PM -0400, Michael Richardson wrote: > 1) So, BCPs can point to multiple documents. > BCP14 actually is RFC2119 and RFC8174 now, so we can add a third document if > desired. That is, it's cheaper to not spin 2119. Sure. Plus, RFC2119 is iconic, and used far and wide outside the IETF. > 2) I'm not claiming others won't use it, I just don't know if they will. > Crypto progresses... what other things do that in the same way? Any time we have a migration from one [sub]protocol to a newer one and need to retain support for the old one for a while, we will need something like SHOULD-. I agree this comes up most often in the context of cryptographic algorithms. Nico -- From nobody Fri Jun 26 21:05:51 2020 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE5603A0B85; Fri, 26 Jun 2020 21:05:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, 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=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 Qc9DdkuM4s4S; Fri, 26 Jun 2020 21:05:48 -0700 (PDT) Received: from mail-pj1-x1033.google.com (mail-pj1-x1033.google.com [IPv6:2607:f8b0:4864:20::1033]) (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 352783A0953; Fri, 26 Jun 2020 21:05:48 -0700 (PDT) Received: by mail-pj1-x1033.google.com with SMTP id u8so5503910pje.4; Fri, 26 Jun 2020 21:05:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=tIv/z/6v49g8/FPZgdYr94yCU4plDr13jrNrcDntvaM=; b=YnJe3/vzxFoZgPQhhTn45EIQeYdAHB+5wQdmO1gn0gccyA6fElGnh37PK8aJUCDi8v aVGM4wsSLChYKVadyu5gfZXHK45kulT+Jx8tQKcl9QHYsXtKm28YPQifyq1DFsDwOs5f o3Xe1sNWiU3/nQZIAv7IprBa5/5vRb99JBgz3dX/OCHkMV+V67Aq5f/+RkJLEzqEhJeB EDmCZXiYRff5b5UI95Gz5tDJrFIVY5M2c+UI4iW8KE6K1WK+BFSToMC7kAT472W1LYpc wwZuSxKuoH1p7aB4rPtb3/x/Pt6SWd0jhzYYBI2xar9fGtgx4WiKvzY0nUBvycUFo2SH 6IjA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=tIv/z/6v49g8/FPZgdYr94yCU4plDr13jrNrcDntvaM=; b=qZVRmDXBLdF9/zKIc/no7ncNRbAx4bG/un+gSdDJFzumxXqoK81mFgBhEf4XYbT7l7 ujmknPgWY37YZYVWwqnHdM565Ls33wllEY3u+sfCpSOj9pWDxXTBMLogf6kwBHHXUYHh dnRXBLJuev1ITiz8rqEY/uDjlyvGrD9e89yGse/NRmsBfvZRjRzYrQC7dz3haBD4Utuc GBlGA4RpdiCgajz0tLQDWXwdezWGhgtKitgcMJbZBxtBjZNfAm9EJGhyhhiGzt/pRyUS xz5OYU4T/rqmDuJJKXvjslJXJ97opr6n5IhByL/Kn337eXuu+nKvdaRpQq83OMKmO4aA 64lA== X-Gm-Message-State: AOAM5311XlRoWLehHhfvZpZHqAoqwpMd3KjUWYPHjK/w78C+1V2qWLGV xMZmo4k5ictM+3i7dONt8sx7D+K1B6Q= X-Google-Smtp-Source: ABdhPJzks4sPVyuC8FxmrQznUw7h1XB9lW4OJNfUztLc8I6UEm+5Fa5kI2/Rnjcihox3JH8Cjw/Fiw== X-Received: by 2002:a17:902:8f83:: with SMTP id z3mr5016064plo.203.1593230747453; Fri, 26 Jun 2020 21:05:47 -0700 (PDT) Received: from [192.168.178.20] (203.90.69.111.dynamic.snap.net.nz. [111.69.90.203]) by smtp.gmail.com with ESMTPSA id c187sm3465174pfc.146.2020.06.26.21.05.43 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 26 Jun 2020 21:05:46 -0700 (PDT) To: Nico Williams , Michael Richardson Cc: Toerless Eckert , Russ Housley , Ben Kaduk , anima@ietf.org, saag@ietf.org References: <20200624023407.GA41244@faui48f.informatik.uni-erlangen.de> <14352.1593208951@localhost> <20200626220847.GX3100@localhost> <30682.1593220519@localhost> <20200627030622.GZ3100@localhost> From: Brian E Carpenter Message-ID: Date: Sat, 27 Jun 2020 16:05:41 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <20200627030622.GZ3100@localhost> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] [saag] towards using of MUST-/SHOULD+/SHOULD- in draft-ietf-autonomic-control-plane-24 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jun 2020 04:05:50 -0000 On 27-Jun-20 15:06, Nico Williams wrote: > On Fri, Jun 26, 2020 at 09:15:19PM -0400, Michael Richardson wrote: >> 1) So, BCPs can point to multiple documents. >> BCP14 actually is RFC2119 and RFC8174 now, so we can add a third document if >> desired. That is, it's cheaper to not spin 2119. > > Sure. Plus, RFC2119 is iconic, and used far and wide outside the IETF. > >> 2) I'm not claiming others won't use it, I just don't know if they will. >> Crypto progresses... what other things do that in the same way? > > Any time we have a migration from one [sub]protocol to a newer one and > need to retain support for the old one for a while, we will need > something like SHOULD-. I agree this comes up most often in the context > of cryptographic algorithms. Interesting discussion but I want to see the ACP in the RFC Editor queue, can we just do what is required for that and nothing else? I am about a millimetre away from proposing to recall the GRASP spec from the RFC Editor so that we can amputate its normative dependency on the ACP. I really wish I'd done that a year ago. Grumpy Brian From nobody Fri Jun 26 22:01:53 2020 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 031863A0CBB; Fri, 26 Jun 2020 22:01:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-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=cryptonector.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 mFynQbu-asz7; Fri, 26 Jun 2020 22:01:49 -0700 (PDT) Received: from beige.elm.relay.mailchannels.net (beige.elm.relay.mailchannels.net [23.83.212.16]) (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 C61F23A0CB9; Fri, 26 Jun 2020 22:01:48 -0700 (PDT) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id BF9E148107B; Sat, 27 Jun 2020 05:01:47 +0000 (UTC) Received: from pdx1-sub0-mail-a18.g.dreamhost.com (100-96-23-5.trex.outbound.svc.cluster.local [100.96.23.5]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 37AE8480BDB; Sat, 27 Jun 2020 05:01:47 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from pdx1-sub0-mail-a18.g.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.18.8); Sat, 27 Jun 2020 05:01:47 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com X-MailChannels-Auth-Id: dreamhost X-Keen-Descriptive: 454fd1da55862d3c_1593234107584_3040401124 X-MC-Loop-Signature: 1593234107584:2566361195 X-MC-Ingress-Time: 1593234107584 Received: from pdx1-sub0-mail-a18.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a18.g.dreamhost.com (Postfix) with ESMTP id C68C880022; Fri, 26 Jun 2020 22:01:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=2UG8g3ilcgqCNP rrniikSOxzUvA=; b=W2twSAMvdP0HHpl1/B2bMq9Y5/8zemOkW3/93buzYrjL1e siUOXviMbOukrKAMsxFY7NIXKBU3Uomj1sM2APXscm36w27JQmO1zYgqJbfOVlO+ tHcYt8WUgMonQqTdQnJ4nUH08gYmTpVqbbmF2+qEkB2XItCSxZL3JfSSIllnA= Received: from localhost (unknown [24.28.108.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by pdx1-sub0-mail-a18.g.dreamhost.com (Postfix) with ESMTPSA id 228BA80024; Fri, 26 Jun 2020 22:01:43 -0700 (PDT) Date: Sat, 27 Jun 2020 00:01:38 -0500 X-DH-BACKEND: pdx1-sub0-mail-a18 From: Nico Williams To: Brian E Carpenter Cc: Michael Richardson , Toerless Eckert , Russ Housley , Ben Kaduk , anima@ietf.org, saag@ietf.org Message-ID: <20200627050137.GA3100@localhost> References: <20200624023407.GA41244@faui48f.informatik.uni-erlangen.de> <14352.1593208951@localhost> <20200626220847.GX3100@localhost> <30682.1593220519@localhost> <20200627030622.GZ3100@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: -100 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduhedrudelvddgledvucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuggftfghnshhusghstghrihgsvgdpffftgfetoffjqffuvfenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhepfffhvffukfhfgggtuggjfgesthdtredttdervdenucfhrhhomheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqeenucggtffrrghtthgvrhhnpefftdektefhueetveeigfefgeejteejvdfhhefgvddtfeeujeehleeguefhgffhgfenucfkphepvdegrddvkedruddtkedrudekfeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhhouggvpehsmhhtphdphhgvlhhopehlohgtrghlhhhoshhtpdhinhgvthepvdegrddvkedruddtkedrudekfedprhgvthhurhhnqdhprghthheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqedpmhgrihhlfhhrohhmpehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmpdhnrhgtphhtthhopehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhm Archived-At: Subject: Re: [Anima] [saag] towards using of MUST-/SHOULD+/SHOULD- in draft-ietf-autonomic-control-plane-24 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jun 2020 05:01:51 -0000 On Sat, Jun 27, 2020 at 04:05:41PM +1200, Brian E Carpenter wrote: > Interesting discussion but I want to see the ACP in the RFC Editor > queue, can we just do what is required for that and nothing else? > > I am about a millimetre away from proposing to recall the GRASP spec > from the RFC Editor so that we can amputate its normative dependency > on the ACP. I really wish I'd done that a year ago. I don't follow GRASP, or ACP, so I've no idea what you're talking about, but I don't see how this discussion could keep ACP from progressing. In particular, no one is proposing to update BCP14 and make that a prereq for ACP progressing. Nico -- From nobody Fri Jun 26 22:06:08 2020 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 213EC3A0CBB; Fri, 26 Jun 2020 22:06:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, 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=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 2vW2izCFK4S5; Fri, 26 Jun 2020 22:05:59 -0700 (PDT) Received: from mail-pl1-x62b.google.com (mail-pl1-x62b.google.com [IPv6:2607:f8b0:4864:20::62b]) (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 688723A0CB9; Fri, 26 Jun 2020 22:05:59 -0700 (PDT) Received: by mail-pl1-x62b.google.com with SMTP id 35so5067478ple.0; Fri, 26 Jun 2020 22:05:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=b3ZGYOfnjzPdp8Fwn/7oQlPe8rw3F2LdzpYL7PkXSDI=; b=Ccqg9hmqvDH0kPmxzKLVVRQ6+zYDOiZ/qF0Kj4bZDCkdOxIEdyxO0bONe3e2mpRLP+ ghvfNWljl/eq923cT4jLNlayq+0BVNMgZx/HhN6m/QiWEAJ/gFQODXR7K+VB9E5lyWAz nw+Ric4FkfLoSVBZ3RRHLoHvg00TjXQwMwU7pvZdida5uj6+QNuGthFYLrFbVeGyU5ZK xyqnMsyYKm/xbF8xKBn0gEg4nwQZcu+vBHFQMdjMmdYwHbbcewr215LDqE1PtLMDugiy oX+raHnr1dCJHLu8IXoqbBknyFjRlfx6aCdV5S3IwtUP8Q05fmv/HxvTMx4jUfhcN46C +rGg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=b3ZGYOfnjzPdp8Fwn/7oQlPe8rw3F2LdzpYL7PkXSDI=; b=D0qOlWu31YC5//KwCHHYpQKePB78mozpnceumlVuFHaVvSEear1o11rpOOEoPIJw5g +T1G019v9rIn8riDtqktAHqcgB8UyJEfmHBzGtRnCKPS16n/nHDnR3iimPukt1H0pP4g 7LMcrnRUjuNWkJqwpRgpzYPyukFpELL1/tQTCeTUqy5Scfosa70+8ROEG0UX1Br1jsYV akGR3j8lPv4LtYMDT/vdmtB0GupTWET1OAATt4ZELD7tKKDZidiofSQnr/2Kpg5Fqa8C 5TBhE14Z6KQ8E5RJrbFltf1R6kIEavJQruakT652ccd3kQUHzbTDBc+PHLM0CtwZcfXZ 8Y8A== X-Gm-Message-State: AOAM533q94P2gIfW/D038Mb8TPy20DKajyIT7XRYlrPt4tnnIFiiN7i1 OZz6H/WHdeEjwzcgBW6uwe84O8mCbeg= X-Google-Smtp-Source: ABdhPJxt7AFvc+Ylq05Sh5lDaFN0wluwDnIuF20jA66Wu7IZSEcWXylEvLuotyqOD6Z7r5uFddCN+w== X-Received: by 2002:a17:90a:ac0f:: with SMTP id o15mr6878088pjq.105.1593234358781; Fri, 26 Jun 2020 22:05:58 -0700 (PDT) Received: from [192.168.178.20] (203.90.69.111.dynamic.snap.net.nz. [111.69.90.203]) by smtp.gmail.com with ESMTPSA id gm11sm12864741pjb.9.2020.06.26.22.05.55 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 26 Jun 2020 22:05:58 -0700 (PDT) To: Nico Williams Cc: Michael Richardson , Toerless Eckert , Russ Housley , Ben Kaduk , anima@ietf.org, saag@ietf.org References: <20200624023407.GA41244@faui48f.informatik.uni-erlangen.de> <14352.1593208951@localhost> <20200626220847.GX3100@localhost> <30682.1593220519@localhost> <20200627030622.GZ3100@localhost> <20200627050137.GA3100@localhost> From: Brian E Carpenter Message-ID: <41d2ee93-7a2a-ba3c-f527-06a1748444b3@gmail.com> Date: Sat, 27 Jun 2020 17:05:53 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <20200627050137.GA3100@localhost> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] [saag] towards using of MUST-/SHOULD+/SHOULD- in draft-ietf-autonomic-control-plane-24 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jun 2020 05:06:01 -0000 On 27-Jun-20 17:01, Nico Williams wrote: > On Sat, Jun 27, 2020 at 04:05:41PM +1200, Brian E Carpenter wrote: >> Interesting discussion but I want to see the ACP in the RFC Editor >> queue, can we just do what is required for that and nothing else? >> >> I am about a millimetre away from proposing to recall the GRASP spec >> from the RFC Editor so that we can amputate its normative dependency >> on the ACP. I really wish I'd done that a year ago. > > I don't follow GRASP, or ACP, so I've no idea what you're talking about, > but I don't see how this discussion could keep ACP from progressing. In > particular, no one is proposing to update BCP14 and make that a prereq > for ACP progressing. Sorry about my tone, but this seems like a discussion for gendispatch, not anima. Brian From nobody Fri Jun 26 22:12:48 2020 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA9993A0D29; Fri, 26 Jun 2020 22:12:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-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=cryptonector.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 7CbS-8D7RPU8; Fri, 26 Jun 2020 22:12:45 -0700 (PDT) Received: from guinea.birch.relay.mailchannels.net (guinea.birch.relay.mailchannels.net [23.83.209.79]) (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 9D8FF3A0D25; Fri, 26 Jun 2020 22:12:43 -0700 (PDT) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 8E338181110; Sat, 27 Jun 2020 05:12:42 +0000 (UTC) Received: from pdx1-sub0-mail-a18.g.dreamhost.com (100-96-23-8.trex.outbound.svc.cluster.local [100.96.23.8]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id EDD3E1813A2; Sat, 27 Jun 2020 05:12:37 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from pdx1-sub0-mail-a18.g.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.18.8); Sat, 27 Jun 2020 05:12:42 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com X-MailChannels-Auth-Id: dreamhost X-Troubled-Lonely: 7e1c574b164d39c9_1593234762284_1659966079 X-MC-Loop-Signature: 1593234762284:1693100779 X-MC-Ingress-Time: 1593234762284 Received: from pdx1-sub0-mail-a18.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a18.g.dreamhost.com (Postfix) with ESMTP id A4DED80028; Fri, 26 Jun 2020 22:12:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:reply-to:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=a82ZsXbUVfAcuE q4Ocqgmw64nWA=; b=sPIz4wyq94d06RQTb90qqHnnv6Mwa+yS5993g5UJMW3845 qHU+SD0OCIj5Imhh8jh4r/Pawu96fHP+ISZsJsThSjf+uYR//DUKlF951K2Zrvj/ bWyb+r36JZqPmk9wRLU0ZRIjpwxR1xYAS2PhEF31gFo7iachRrQtvK1SADQH8= Received: from localhost (unknown [24.28.108.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by pdx1-sub0-mail-a18.g.dreamhost.com (Postfix) with ESMTPSA id 0D04580026; Fri, 26 Jun 2020 22:12:33 -0700 (PDT) Date: Sat, 27 Jun 2020 00:12:30 -0500 X-DH-BACKEND: pdx1-sub0-mail-a18 From: Nico Williams To: Brian E Carpenter Cc: Michael Richardson , Toerless Eckert , Russ Housley , Ben Kaduk , anima@ietf.org, saag@ietf.org Message-ID: <20200627051229.GB3100@localhost> Reply-To: saag@ietf.org References: <20200624023407.GA41244@faui48f.informatik.uni-erlangen.de> <14352.1593208951@localhost> <20200626220847.GX3100@localhost> <30682.1593220519@localhost> <20200627030622.GZ3100@localhost> <20200627050137.GA3100@localhost> <41d2ee93-7a2a-ba3c-f527-06a1748444b3@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <41d2ee93-7a2a-ba3c-f527-06a1748444b3@gmail.com> User-Agent: Mutt/1.9.4 (2018-02-28) X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: -100 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduhedrudelvddgleegucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuggftfghnshhusghstghrihgsvgdpffftgfetoffjqffuvfenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhepfffhvffukfhrfhggtggujggfsehttdertddtredvnecuhfhrohhmpefpihgtohcuhghilhhlihgrmhhsuceonhhitghosegtrhihphhtohhnvggtthhorhdrtghomheqnecuggftrfgrthhtvghrnhephedvhfevleefffevheetgeekjeeihefhueeugffhfeevhfettddtiedugfeghefgnecukfhppedvgedrvdekrddutdekrddukeefnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmohguvgepshhmthhppdhhvghloheplhhotggrlhhhohhsthdpihhnvghtpedvgedrvdekrddutdekrddukeefpdhrvghtuhhrnhdqphgrthhhpefpihgtohcuhghilhhlihgrmhhsuceonhhitghosegtrhihphhtohhnvggtthhorhdrtghomheqpdhmrghilhhfrhhomhepnhhitghosegtrhihphhtohhnvggtthhorhdrtghomhdpnhhrtghpthhtohepnhhitghosegtrhihphhtohhnvggtthhorhdrtghomh Archived-At: Subject: Re: [Anima] [saag] towards using of MUST-/SHOULD+/SHOULD- in draft-ietf-autonomic-control-plane-24 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jun 2020 05:12:47 -0000 On Sat, Jun 27, 2020 at 05:05:53PM +1200, Brian E Carpenter wrote: > Sorry about my tone, but this seems like a discussion for gendispatch, > not anima. Well, look at the distribution list: Michael clearly meant for SAAG to see this, and for anima to see his post in case anyone there cares. I agree that some other list might be better still, and setting Reply-To: would have helped keep noise down on anima. I'm setting Reply-To: now. From nobody Fri Jun 26 22:41:06 2020 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D6333A0D46 for ; Fri, 26 Jun 2020 22:41:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.87 X-Spam-Level: X-Spam-Status: No, score=-0.87 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=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 R7iSw0IFZZZY for ; Fri, 26 Jun 2020 22:41:03 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDCED3A0D45 for ; Fri, 26 Jun 2020 22:41:02 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [131.188.34.52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 1C0A9548440; Sat, 27 Jun 2020 07:40:56 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 11F25440043; Sat, 27 Jun 2020 07:40:56 +0200 (CEST) Date: Sat, 27 Jun 2020 07:40:56 +0200 From: Toerless Eckert To: Russ Housley Cc: Michael Richardson , anima@ietf.org, Ben Kaduk Message-ID: <20200627054056.GA35664@faui48f.informatik.uni-erlangen.de> References: <11428.1592266833@localhost> <20200617024412.GA11992@kduck.mit.edu> <9584c5cd-c68d-ddc3-0704-da672842e359@gmail.com> <9406.1592756905@localhost> <3A92516D-B980-4231-9059-EF7234BA8610@vigilsec.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3A92516D-B980-4231-9059-EF7234BA8610@vigilsec.com> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: [Anima] Russ: Re: rfc822Name use in Autonomic Control Plane document X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jun 2020 05:41:05 -0000 Russ, Top posting re. your ACP vs. ACME question. ACP rfc822name are meant to be under control of the ACP network operations. aka: the ACP registrars could be controlling rfcSELF*@example.com mailboxes using ACME S/MIME to get rfcSELF*@example.com certificates or IMHO easier control the acp.example.com MTA. Just no need/benefit to do this now IMHO: An ACP is a private network which is ideally isolated from other ACP networks by use of private TA. Using the ACME rfc822name scheme would IMHO create a lot of attack components (all the MTA in the mail path and domain names) if used acros the Internet - without benefits for ACP. Of course, if it was all a private ACME setup within an enterprise, and using mailboxes and ACME is a popular choice - sure, why not. But for private CA setups there are existing IMO easier options (private CA VMs using EST or the like). IMHO public ACME CAwith S/MIME authenitcation could make sense in the future to enable authentication across different ACP domains. Any network has links into other domains and today they are usually unauthenticated, that could be solved IMHO fairly easily. "private" CA of ACP domain , lets call it acpCA signs all ACP certs. Its own cert is not self-signed, but signed by ACME CA via S/MIME, maybe email is rfcSELF@example.com (no ACP IPv6 address in it) Now the ACP nodes actually use acpCA PLUS ACMA CA's as TA. After IKEv2 authenticates neigbor the followup ACP domain membership step checks if the TA of the peer is acpCA. If yes, then peer becomes ACP member, otherwise we have an authenticated signalling channel to an interdomain / different CA peer. And that of course would enable better/secure auto-configuration of such interdomain links. This gives me good mix of security: Its still only relying on well controlled private TA to get into ACP, but also doubles at less secure but best available "Internet/Interdomain" authentication. Cheers Toerless On Sun, Jun 21, 2020 at 12:36:06PM -0400, Russ Housley wrote: > > On Jun 21, 2020, at 12:28 PM, Michael Richardson wrote: > > > > > > Russ Housley wrote: > >> One cannot send email to the character string in this specification, so > >> it should not be carried in the rfc822name. > > > > You can send email to that character string if you configure the MX. > > It was designed specifically to accomodate that. > > > > I objected at the time: I thought it was a stupid feature, that no sensible IKEv2 daemon > > was going to have to send/receive email. > > > > But, Toerless was paranoid that if we did anything at all out of the > > ordinary, that the corporate CA people, in order to protect their fiefdom, > > would freak out and throw some huge roadblock in the way of deploying the ACP. > > > > And, now have an ACME method past WGLC that does certificate validation by > > SMTP. > > Looking at the email certificate enrollment work in the ACME WG (draft-ietf-acme-email-smime-08), I have a hard time seeing how the device that knows the private key could participate in such a protocol. How do you see it working? > > Russ > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima -- --- tte@cs.fau.de From nobody Sat Jun 27 00:57:33 2020 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E4B03A0542; Sat, 27 Jun 2020 00:57:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.695 X-Spam-Level: X-Spam-Status: No, score=-1.695 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=x500.eu 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 Ls1SC2zxKAbO; Sat, 27 Jun 2020 00:57:29 -0700 (PDT) Received: from outscan1.mf.dandomain.dk (outscan1.mf.dandomain.dk [212.237.249.58]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D1C63A043D; Sat, 27 Jun 2020 00:57:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by outscan1.mf.dandomain.dk (Postfix) with ESMTP id 026754069108; Sat, 27 Jun 2020 09:57:27 +0200 (CEST) Received: from outscan1.mf.dandomain.dk ([127.0.0.1]) by localhost (outscan1.mf.dandomain.dk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id biJ1pJk1QMuv; Sat, 27 Jun 2020 09:57:26 +0200 (CEST) Received: from mail-proxy.dandomain.dk (dilvs03.dandomain.net [194.150.112.64]) by outscan1.mf.dandomain.dk (Postfix) with ESMTPA id 204594069100; Sat, 27 Jun 2020 09:57:18 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=x500.eu; s=dandomain; t=1593244646; bh=St7PSINpTDoO7XbXbeu19G7mALHtr+KVerIBvmZTLbA=; h=From:To:Cc:References:In-Reply-To:Subject:Date:From; b=LI4bDBk2VvF7ALm74PQliD9+6gwwjwZqlhHTxNfw78HitSuJU18mwglOuzOG2EFyZ Sf3Bhherfy3a4kkW1VksUhpsg0Pe7CwoHcUde/zk6s0FA0wY4J0YlPIVUfc4ePfguf XQkjTfanwDwHPCscQqrv4O/wK/BJ4lJ+v3hPs7NdvyjYRuWzwqr6tw0gCyx6j6dwb4 KFx6aiuKXVhZNteOQaT6DCwm0sg4XsgZHyun4cKo1glSjPlZNNyLmAde7Vr01g1jlE z5saF8s4bEXYAqeSFvvCYLOFIShPypFQqI1zc6MwHWUb8aqI5XYkJuBkvkXwaMqx2J XuYpT8GYvr0fw== From: "Erik Andersen" To: "'Michael Richardson'" , , "'Russ Housley'" , , "'Ben Kaduk'" Cc: "'Ryan Sleevi'" , "'Nico Williams'" References: <20200624023407.GA41244@faui48f.informatik.uni-erlangen.de> <13005.1593208602@localhost> In-Reply-To: <13005.1593208602@localhost> Date: Sat, 27 Jun 2020 09:57:16 +0200 Message-ID: <001001d64c58$98890d40$c99b27c0$@x500.eu> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQEwj93EDQf+67rRWWSqilgJXpnKwAJ6Ny4/AP3sFROqG81lYA== Content-Language: en-gb Archived-At: Subject: Re: [Anima] [lamps] on certification authorities. X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jun 2020 07:57:31 -0000 There certainly is a big difference between the term certification (an act) and the term certificate (a data value). Certification implies that the CA does some validation before issuing a certificate. When a read an article and hit the term certificate authority, I stop reading thinking the guy cannot even get the term right. He/She does not know what a CA is. Erik -----Original Message----- From: Spasm On Behalf Of Michael Richardson Sent: 26 June 2020 23:57 To: spasm@ietf.org; Russ Housley ; anima@ietf.org; Ben Kaduk Cc: Ryan Sleevi ; Nico Williams Subject: [lamps] on certification authorities. Russ Housley wrote: > Thank you. Many people get it wrong, but X.509 and RFC 5280 (as well > as the earlier versions in RFC 2459 and RFC 3280) all use > {CA=} "certification authority". I guess it might be worth spreading this point more widely :-) I'll all for stamping out the wrong expansions, even if it sometimes seems pendantic. I'm told that Google is about to start their Cloud *Certificate* Authority. If that happens, I believe that any chance to assert the term will be completely lost :-) On the other hand, if they go with "certification authority", then perhaps the tide of the terminology will be reversed. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- From nobody Sat Jun 27 07:19:21 2020 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FA003A093C for ; Sat, 27 Jun 2020 07:19:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.36 X-Spam-Level: X-Spam-Status: No, score=-0.36 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_ABOUTYOU=0.5, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, T_FILL_THIS_FORM_SHORT=0.01, URIBL_BLOCKED=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 jwTtbnu_PBwt for ; Sat, 27 Jun 2020 07:19:18 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D230E3A093D for ; Sat, 27 Jun 2020 07:19:17 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [131.188.34.52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 6E731548011; Sat, 27 Jun 2020 16:19:11 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 64E2E440043; Sat, 27 Jun 2020 16:19:11 +0200 (CEST) Date: Sat, 27 Jun 2020 16:19:11 +0200 From: Toerless Eckert To: Stephen Kent Cc: Brian E Carpenter , "Owen Friel (ofriel)" , Eric Rescorla , rfcSELF+fd89b714F3db00000200000064000000+area51.research@acp.example.com, Anima WG Message-ID: <20200627141911.GA49753@faui48f.informatik.uni-erlangen.de> References: <6981a76f-76f1-e9b2-319d-473c7a4bc847@verizon.net> <6c4e402f-cce6-daff-aa16-6159340f0802@gmail.com> <9c09debe-3463-a574-46cf-cee86a2c68af@verizon.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9c09debe-3463-a574-46cf-cee86a2c68af@verizon.net> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [Anima] representing ACP info in X.509 certs X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jun 2020 14:19:20 -0000 Dear Stephen, Thank you very much for your thoughts, but i do not think we can move the discussion ahead when it stops with non-technical opinion dropping statements like "lets not play games" (you) or "i do not think this is the right thing to do" (Ben/Russ). Could you please explain your assertion with technical arguments ? More inline On Tue, Jun 23, 2020 at 07:52:25PM -0400, Stephen Kent wrote: > Brian, > > Common sense argues against putting something other than an e-mail address in the rfc822namem attribute. > > > > I expect ADs to use common sense, as well as careful reading of prior RFCs, when making decisions. > > Indeed, but that cuts both ways, since running code is our goal. No parser is in a position to say that rfcSELF+fd89b714F3db00000200000064000000+area51.research@acp.example.com isn't an email address. > > If we were only AIs that would be a suitable reply ;-). I can only guess what this mean. You don't like the look of it as a human ? I for once have been confused a lot by solutions where some data only have a well-defined binary representation for "AI" ? to handle but none for humans. In result, those solutions all are IMHO hard to troubleshoot, because every CLI/GUI software came up with its own representation. For information which naturally represents the domain, name and role attributes of an entity, there is IMHO no better human recognizable standardized representation in a single string than using the local-part@domain format. ACP nodes in the acp.example.com domain only have one name, which is their registrar assigned IPv6 address, therefore fd89b714F3db00000200000064000000@acp.example.com really is the most human readible representation of that identification i can think of. rfcSELF+fd89b714F3db00000200000064000000@acp.example.com The rfcSELF is just a prefix to allow isolation of namespaces in the local part. Think of staff.john.smith@example.com vs. contractor.john.smith@example.com Likewise the +area51.research is just like a department name, john.smith.research.area51@example.com A lot more legible than what poor network operators would normally see IMHO. > But, we're not- we all know that the proposed IDs are NOT rfc822 addresses, > so let's not play games. This is not meant to be playing games. These are syntactically perfect rfc822Names/ email-addresses and semantically they can be perfect electronic mail boxes. Remember that as the draft explains also in section 6.1.2, there is good amount of prior examples where local-part@domain is used as just identifiers without using any email boxes in the process. For example inter-domain access authentication, eduroam or the like. [ Then again, IMHO IETF is also supposed to develop new technologies, so i am not even sure why i always end up having to argue that solutions are better because they don't do something fundamentally new.] > The simple answer is that when, in the past, developers have chosen to abuse > the semantics of subject name fields in certs, the result shave been VERY > long lasting, and embarrassing. Long ago, Netscape chose to shove a DNS name > into the DN common name filed because it was an easy fix for their problem. > As a result, we still have browsers and CAs that misuse that field. At least > that egregious behavior was not the result of an IETF WG. Let's not screw > this up in the name of expediency! I have also not seen a reply from you to Michael Richardsons question about that statement. I am not aware of the history, so i can not comment, but i am curious about your reply. Nevertheless, i do not think your example has any relevance here, because we are not choosing a potentially wrong encoding for an existing piece of information, but we are arguing that our strgins are are perrfectly syntactic and semantic correct electronic email addresses and therefore deserve to use the standard encoding for electronic email addresses. Cheers Toerless > > Steve > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima -- --- tte@cs.fau.de From nobody Sat Jun 27 08:02:27 2020 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FEC73A07D7 for ; Sat, 27 Jun 2020 08:02:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.86 X-Spam-Level: X-Spam-Status: No, score=-0.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, T_FILL_THIS_FORM_SHORT=0.01, URIBL_BLOCKED=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 m7nmNS8OtNcn for ; Sat, 27 Jun 2020 08:02:11 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0E853A07D4 for ; Sat, 27 Jun 2020 08:02:11 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 6217C548068; Sat, 27 Jun 2020 17:02:06 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 5B938440043; Sat, 27 Jun 2020 17:02:06 +0200 (CEST) Date: Sat, 27 Jun 2020 17:02:06 +0200 From: Toerless Eckert To: Russ Housley Cc: Brian Carpenter , Ben Kaduk , anima@ietf.org Message-ID: <20200627150206.GB49753@faui48f.informatik.uni-erlangen.de> References: <11428.1592266833@localhost> <20200617024412.GA11992@kduck.mit.edu> <9584c5cd-c68d-ddc3-0704-da672842e359@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [Anima] rfc822Name use in Autonomic Control Plane document X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jun 2020 15:02:26 -0000 Russ, ...getting to backlog... inline. On Fri, Jun 19, 2020 at 12:32:56PM -0400, Russ Housley wrote: > Brian: > > I disagree with your characterization of the situation. RFC 5280 talks about Subject Alternative Names, and the rfc822Name is used for an email address. This specification puts something other than an email address in that field, and I raised a concern when I reviewed the document. Other name forms are explicitly accommodated by otherName, and in my review, I suggested using otherName instead of rfc822Name. I think i stated often enough now that the ACP domain information is meant to be a both syntactically and semantically correct electronic mail address. Maybe you can provide technical reasons why you think it is not. Is there some degree of uglyness ? Indeed, all the uglyness comes from seeing how typical electronic mailbox handling could be supported: rfcSELF is a prefix to de-conflict the mail box local-parts from other classes of entities when they share the same domain part. Think temp.john.doe@example.com for contractors (temp workers) to keep the nice john.doe@example.com free. Likewise area51.research as a suffix is quite comparable in syntax and semantic to department names you can see in local parts. > I observe that jabber IDs have the same syntax as an email address, but they are not carried in rfc822name because the semantics are different. Sure, but thats because in that solution you want to be able to imply different application scopes for potentially the same entity, aka: reuse the same entity name (local-part@domain) for email and jabber. In our case we are coming up with email address names for new entities that would fit well into existing email address name spaces already existing. > One cannot send email to the character string in this specification, so it should not be carried in the rfc822name. First of all, you can if you want to, and secondly, i contest that it is a requirement to be able to do that if the recipient doesn't need to support it. Think about noreply@bad-corporation.com. You do want to make sure though that you are in control of the electronic mail address though, and that is given for ACP addresses. Example: in WiFi access with roaming you also use local-part@domain as entity identifiers, and some seem to be using certificates with rfc822Name. And to the best of my understanding, nothing on those solutions depends on the actual use of mail boxes. Maybe in those places where like in ACME you can enroll by some challenge of ownership of the mailbox, but that could equally be just web based if it exists at all in a particular instance. Cheers Toeress > >>>> Sure anything is possible if you are writing your own code, but > >>>> most will not be doing that. (I've supported otherName in my code for > >>>> other purposes, and it's not that difficult, but it's not trivial either) > >>>> My experience with COTS CA systems it that it's really hard to > >>>> get them to do it. Please prove me wrong. > >> > >> (Sadly, I have zero experience with COTS CA systems; I know too much about > >> openssl at this point and would presumably be writing my own, in this > >> position.) > >> > >>>> The most popular Enterprise CA software is the Microsoft CA. > >>>> > >>>> 2) by using ACME to speak to a hosted CA. Maybe WebPKI, maybe not. > >>>> Either way, getting otherName supported is even harder, because > >>>> nobody else uses it. > >> > >> Is the concern the ACME protocol support or just getting the hosted CA to > >> cope with it? The former seems like something that we could make happen in > >> the IETF, and the latter seems to have high overlap with point (1). > >> > >>>> If we can't depend upon otherName being filled in, then we have to look for > >>>> two things. That means more code paths (two more) to test, more test > >>>> vectors, and what exactly does an end point do when both are present, BUT > >>>> THEY DO NOT MATCH? So three more pages of text there. > >>>> Remember, that just rejecting the certificate means that we have to send out > >>>> a truck, which is what ACP aims to avoid, so that won't be popular. > >>>> And of course, there could also be bugs (maybe even CVEs) in the code that > >>>> tries to deal with the tie. > >> > >> To be honest, this argument feels like a stronger one to me than the bits > >> in the -24. I'm still not willing to accept into the RFC Series a document > >> that violates the rules set down by the specification for the technology > >> it's making use of, but the refocus on the "running code" aspect is > >> appreciated. > >> > >> -Ben > >> > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima -- --- tte@cs.fau.de From nobody Sat Jun 27 08:52:28 2020 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B278C3A07B9 for ; Sat, 27 Jun 2020 08:52:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=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 6cpw7HsZeb7v for ; Sat, 27 Jun 2020 08:52:24 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81DCF3A07B6 for ; Sat, 27 Jun 2020 08:52:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id E59A6300B22 for ; Sat, 27 Jun 2020 11:52:21 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 4wDlc_sa_Qt6 for ; Sat, 27 Jun 2020 11:52:19 -0400 (EDT) Received: from a860b60074bd.fios-router.home (pool-72-66-113-56.washdc.fios.verizon.net [72.66.113.56]) by mail.smeinc.net (Postfix) with ESMTPSA id 5F374300A93; Sat, 27 Jun 2020 11:52:19 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.14\)) From: Russ Housley In-Reply-To: <20200627054056.GA35664@faui48f.informatik.uni-erlangen.de> Date: Sat, 27 Jun 2020 11:52:20 -0400 Cc: Michael Richardson , anima@ietf.org, Ben Kaduk Content-Transfer-Encoding: quoted-printable Message-Id: References: <11428.1592266833@localhost> <20200617024412.GA11992@kduck.mit.edu> <9584c5cd-c68d-ddc3-0704-da672842e359@gmail.com> <9406.1592756905@localhost> <3A92516D-B980-4231-9059-EF7234BA8610@vigilsec.com> <20200627054056.GA35664@faui48f.informatik.uni-erlangen.de> To: Toerless Eckert X-Mailer: Apple Mail (2.3445.104.14) Archived-At: Subject: Re: [Anima] Russ: Re: rfc822Name use in Autonomic Control Plane document X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jun 2020 15:52:27 -0000 Toerless: I think Brian actually made my point. While the filed contains an email = address, using it as such would result in a delivery failure. The = private key holder cannot be reached by this address. Russ > On Jun 27, 2020, at 1:40 AM, Toerless Eckert wrote: >=20 > Russ, >=20 > Top posting re. your ACP vs. ACME question. >=20 > ACP rfc822name are meant to be under control of the ACP network = operations. > aka: the ACP registrars could be controlling rfcSELF*@example.com = mailboxes using > ACME S/MIME to get rfcSELF*@example.com certificates or IMHO easier = control > the acp.example.com MTA. Just no need/benefit to do this now IMHO: >=20 > An ACP is a private network which is ideally isolated from other > ACP networks by use of private TA. Using the ACME rfc822name scheme = would > IMHO create a lot of attack components (all the MTA in the mail path > and domain names) if used acros the Internet - without benefits for > ACP. Of course, if it was all a private ACME setup within an = enterprise, > and using mailboxes and ACME is a popular choice - sure, why not. > But for private CA setups there are existing IMO easier options > (private CA VMs using EST or the like). >=20 > IMHO public ACME CAwith S/MIME authenitcation could make sense=20 > in the future to enable authentication across different ACP domains. >=20 > Any network has links into other domains and today they are usually > unauthenticated, that could be solved IMHO fairly easily. >=20 > "private" CA of ACP domain , lets call it acpCA signs all ACP certs. > Its own cert is not self-signed, but signed by ACME CA via S/MIME, > maybe email is rfcSELF@example.com (no ACP IPv6 address in it) >=20 > Now the ACP nodes actually use acpCA PLUS ACMA CA's as TA. > After IKEv2 authenticates neigbor the followup ACP domain membership > step checks if the TA of the peer is acpCA. If yes, then peer > becomes ACP member, otherwise we have an authenticated signalling > channel to an interdomain / different CA peer. And that of course > would enable better/secure auto-configuration of such interdomain > links. >=20 > This gives me good mix of security: Its still only relying on > well controlled private TA to get into ACP, but also doubles > at less secure but best available "Internet/Interdomain" > authentication. >=20 > Cheers > Toerless >=20 > On Sun, Jun 21, 2020 at 12:36:06PM -0400, Russ Housley wrote: >>> On Jun 21, 2020, at 12:28 PM, Michael Richardson = wrote: >>>=20 >>>=20 >>> Russ Housley wrote: >>>> One cannot send email to the character string in this = specification, so >>>> it should not be carried in the rfc822name. >>>=20 >>> You can send email to that character string if you configure the MX. >>> It was designed specifically to accomodate that. >>>=20 >>> I objected at the time: I thought it was a stupid feature, that no = sensible IKEv2 daemon >>> was going to have to send/receive email. >>>=20 >>> But, Toerless was paranoid that if we did anything at all out of the >>> ordinary, that the corporate CA people, in order to protect their = fiefdom, >>> would freak out and throw some huge roadblock in the way of = deploying the ACP. >>>=20 >>> And, now have an ACME method past WGLC that does certificate = validation by >>> SMTP. >>=20 >> Looking at the email certificate enrollment work in the ACME WG = (draft-ietf-acme-email-smime-08), I have a hard time seeing how the = device that knows the private key could participate in such a protocol. = How do you see it working? >>=20 >> Russ >>=20 >=20 >=20 >=20 >> _______________________________________________ >> Anima mailing list >> Anima@ietf.org >> https://www.ietf.org/mailman/listinfo/anima >=20 >=20 > --=20 > --- > tte@cs.fau.de From nobody Sat Jun 27 08:57:00 2020 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A58743A07C7 for ; Sat, 27 Jun 2020 08:56:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.886 X-Spam-Level: X-Spam-Status: No, score=-1.886 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_FILL_THIS_FORM_SHORT=0.01, 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 X36cN_yMKh0v for ; Sat, 27 Jun 2020 08:56:55 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CDD2B3A07C6 for ; Sat, 27 Jun 2020 08:56:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 5519F300B25 for ; Sat, 27 Jun 2020 11:56:53 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id v0hNGTttNwrV for ; Sat, 27 Jun 2020 11:56:47 -0400 (EDT) Received: from a860b60074bd.fios-router.home (pool-72-66-113-56.washdc.fios.verizon.net [72.66.113.56]) by mail.smeinc.net (Postfix) with ESMTPSA id C1192300B54; Sat, 27 Jun 2020 11:56:46 -0400 (EDT) From: Russ Housley Message-Id: <695B5071-F53F-407D-A4D4-23CE4C56A0DA@vigilsec.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_B7E85837-71A6-4668-8434-F88DC84C16A3" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.14\)) Date: Sat, 27 Jun 2020 11:56:43 -0400 In-Reply-To: <20200627150206.GB49753@faui48f.informatik.uni-erlangen.de> Cc: Brian Carpenter , Ben Kaduk , anima@ietf.org To: Toerless Eckert References: <11428.1592266833@localhost> <20200617024412.GA11992@kduck.mit.edu> <9584c5cd-c68d-ddc3-0704-da672842e359@gmail.com> <20200627150206.GB49753@faui48f.informatik.uni-erlangen.de> X-Mailer: Apple Mail (2.3445.104.14) Archived-At: Subject: Re: [Anima] rfc822Name use in Autonomic Control Plane document X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jun 2020 15:56:58 -0000 --Apple-Mail=_B7E85837-71A6-4668-8434-F88DC84C16A3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Toerless: Your example is making my point: noreply@bad-corporation.com = . Such an email address should not = appear in a certificate. It does not name the private key holder. Russ > On Jun 27, 2020, at 11:02 AM, Toerless Eckert wrote: >=20 > Russ, >=20 > ...getting to backlog... >=20 > inline. >=20 > On Fri, Jun 19, 2020 at 12:32:56PM -0400, Russ Housley wrote: >> Brian: >>=20 >> I disagree with your characterization of the situation. RFC 5280 = talks about Subject Alternative Names, and the rfc822Name is used for an = email address. This specification puts something other than an email = address in that field, and I raised a concern when I reviewed the = document. Other name forms are explicitly accommodated by otherName, = and in my review, I suggested using otherName instead of rfc822Name. >=20 > I think i stated often enough now that the ACP domain information is > meant to be a both syntactically and semantically correct electronic > mail address. Maybe you can provide technical reasons why you think it = is not. >=20 > Is there some degree of uglyness ? Indeed, all the uglyness comes > from seeing how typical electronic mailbox handling could be > supported: >=20 > rfcSELF is a prefix to de-conflict the mail box local-parts > from other classes of entities when they share the same domain part. >=20 > Think temp.john.doe@example.com for contractors (temp workers) to > keep the nice john.doe@example.com free. >=20 > Likewise area51.research as a suffix is quite comparable in syntax > and semantic to department names you can see in local parts. >=20 >> I observe that jabber IDs have the same syntax as an email address, = but they are not carried in rfc822name because the semantics are = different. >=20 > Sure, but thats because in that solution you want to be able to imply > different application scopes for potentially the same entity, aka: = reuse the > same entity name (local-part@domain) for email and jabber. >=20 > In our case we are coming up with email address names for new entities > that would fit well into existing email address name spaces already = existing. >=20 >> One cannot send email to the character string in this specification, = so it should not be carried in the rfc822name. >=20 > First of all, you can if you want to, and secondly, i contest that > it is a requirement to be able to do that if the recipient doesn't > need to support it. Think about noreply@bad-corporation.com. > You do want to make sure though that you are in control of > the electronic mail address though, and that is given for ACP > addresses. >=20 > Example: in WiFi access with roaming you also use > local-part@domain as entity identifiers, and some seem to > be using certificates with rfc822Name. And to the best of > my understanding, nothing on those solutions depends on > the actual use of mail boxes. Maybe in those places where like > in ACME you can enroll by some challenge of ownership of > the mailbox, but that could equally be just web based if it > exists at all in a particular instance. >=20 > Cheers > Toeress >=20 >>>>>> Sure anything is possible if you are writing your own code, but >>>>>> most will not be doing that. (I've supported otherName in my = code for >>>>>> other purposes, and it's not that difficult, but it's not = trivial either) >>>>>> My experience with COTS CA systems it that it's really hard to >>>>>> get them to do it. Please prove me wrong. >>>>=20 >>>> (Sadly, I have zero experience with COTS CA systems; I know too = much about >>>> openssl at this point and would presumably be writing my own, in = this >>>> position.) >>>>=20 >>>>>> The most popular Enterprise CA software is the Microsoft CA. >>>>>>=20 >>>>>> 2) by using ACME to speak to a hosted CA. Maybe WebPKI, maybe = not. >>>>>> Either way, getting otherName supported is even harder, because >>>>>> nobody else uses it. >>>>=20 >>>> Is the concern the ACME protocol support or just getting the hosted = CA to >>>> cope with it? The former seems like something that we could make = happen in >>>> the IETF, and the latter seems to have high overlap with point (1). >>>>=20 >>>>>> If we can't depend upon otherName being filled in, then we have = to look for >>>>>> two things. That means more code paths (two more) to test, more = test >>>>>> vectors, and what exactly does an end point do when both are = present, BUT >>>>>> THEY DO NOT MATCH? So three more pages of text there. >>>>>> Remember, that just rejecting the certificate means that we have = to send out >>>>>> a truck, which is what ACP aims to avoid, so that won't be = popular. >>>>>> And of course, there could also be bugs (maybe even CVEs) in the = code that >>>>>> tries to deal with the tie. >>>>=20 >>>> To be honest, this argument feels like a stronger one to me than = the bits >>>> in the -24. I'm still not willing to accept into the RFC Series a = document >>>> that violates the rules set down by the specification for the = technology >>>> it's making use of, but the refocus on the "running code" aspect is >>>> appreciated. >>>>=20 >>>> -Ben >>>>=20 >>=20 >> _______________________________________________ >> Anima mailing list >> Anima@ietf.org >> https://www.ietf.org/mailman/listinfo/anima >=20 > --=20 > --- > tte@cs.fau.de --Apple-Mail=_B7E85837-71A6-4668-8434-F88DC84C16A3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Toerless:

Your example is making my point: noreply@bad-corporation.com.  Such an email address = should not appear in a certificate.  It does not name the private = key holder.

Russ


On Jun = 27, 2020, at 11:02 AM, Toerless Eckert <tte@cs.fau.de> = wrote:

Russ,

...getting to = backlog...

inline.

On Fri, Jun 19, 2020 at 12:32:56PM -0400, Russ Housley = wrote:
Brian:

I disagree with your characterization of the = situation.  RFC 5280 talks about Subject Alternative Names, and the = rfc822Name is used for an email address.  This specification puts = something other than an email address in that field, and I raised a = concern when I reviewed the document.  Other name forms are = explicitly accommodated by otherName, and in my review, I suggested = using otherName instead of rfc822Name.

I think i stated often enough now that the ACP domain = information is
meant to be a both syntactically and = semantically correct electronic
mail address. Maybe you = can provide technical reasons why you think it is not.

Is there some degree of uglyness ? Indeed, all the uglyness = comes
from seeing how typical electronic mailbox handling = could be
supported:

rfcSELF = is a prefix to de-conflict the mail box local-parts
from = other classes of entities when they share the same domain part.

Think temp.john.doe@example.com for contractors (temp workers) = to
keep the nice john.doe@example.com free.

Likewise area51.research as a suffix is quite comparable in = syntax
and semantic to department names you can see in = local parts.

I observe that jabber IDs have the same syntax as an email = address, but they are not carried in rfc822name because the semantics = are different.

Sure, but thats = because in that solution you want to be able to imply
different application scopes for potentially the same entity, = aka: reuse the
same entity name (local-part@domain) for = email and jabber.

In our case we are coming = up with email address names for new entities
that would = fit well into existing email address name spaces already existing.

One = cannot send email to the character string in this specification, so it = should not be carried in the rfc822name.

First of all, you can if you want to, and secondly, i contest = that
it is a requirement to be able to do that if the = recipient doesn't
need to support it. Think about noreply@bad-corporation.com.
You do want to = make sure though that you are in control of
the electronic = mail address though, and that is given for ACP
addresses.
Example: in WiFi access with roaming you also = use
local-part@domain as entity identifiers, and some seem = to
be using certificates with rfc822Name. And to the best = of
my understanding, nothing on those solutions depends = on
the actual use of mail boxes. Maybe in those places = where like
in ACME you can enroll by some challenge of = ownership of
the mailbox, but that could equally be just = web based if it
exists at all in a particular instance.

Cheers
=    Toeress

 Sure anything is possible if you are = writing your own code, but
 most will not be doing = that. (I've supported otherName in my code for
=  other purposes, and it's not that difficult, but it's not trivial = either)
 My experience with COTS CA systems it that = it's really hard to
 get them to do it. =    Please prove me wrong.

(Sadly, I have zero = experience with COTS CA systems; I know too much about
openssl at this point and would presumably be writing my own, = in this
position.)

 The = most popular Enterprise CA software is the Microsoft CA.
2) by using ACME to speak to a hosted CA.  Maybe = WebPKI, maybe not.
 Either way, getting otherName = supported is even harder, because
 nobody else uses = it.

Is the = concern the ACME protocol support or just getting the hosted CA to
cope with it?  The former seems like something that we = could make happen in
the IETF, and the latter seems to = have high overlap with point (1).

If we = can't depend upon otherName being filled in, then we have to look for
two things.  That means more code paths (two more) to = test, more test
vectors, and what exactly does an end = point do when both are present, BUT
THEY DO NOT MATCH? =  So three more pages of text there.
Remember, that = just rejecting the certificate means that we have to send out
a truck, which is what ACP aims to avoid, so that won't be = popular.
And of course, there could also be bugs (maybe = even CVEs) in the code that
tries to deal with the tie.

To be honest, this = argument feels like a stronger one to me than the bits
in = the -24.  I'm still not willing to accept into the RFC Series a = document
that violates the rules set down by the = specification for the technology
it's making use of, but = the refocus on the "running code" aspect is
appreciated.

-Ben


_______________________________________________
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

--
---
tte@cs.fau.de

= --Apple-Mail=_B7E85837-71A6-4668-8434-F88DC84C16A3-- From nobody Sat Jun 27 09:35:43 2020 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64F7B3A082C for ; Sat, 27 Jun 2020 09:35:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, 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=verizon.net 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 yXgJx10K24KV for ; Sat, 27 Jun 2020 09:35:40 -0700 (PDT) Received: from sonic303-2.consmr.mail.bf2.yahoo.com (sonic303-2.consmr.mail.bf2.yahoo.com [74.6.131.41]) (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 341D13A0810 for ; Sat, 27 Jun 2020 09:35:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verizon.net; s=a2048; t=1593275739; bh=3KVYJY39+YiJ1/aCBX31yAcNLo6x6JdRcb0/cywQVMc=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From:Subject; b=G03qbXcs8Iv15bZRa49Sz5E3vKgKAJv2AuiHlsn/C7v+RPwzWqfB/RxAWL3C0Hut10cmI9dXJlmHARjbj/zUnJjUs3AXoSHpnlRWtauY84VHSz3Fz/QWc+Ar6kWOZZwv+23bNzGwQcwvb5234qAL9yDqYuOicgaMewt1PPFIq1aSgKfyZtpBXjcinKz4K8N+UsqhQlCWZBdywR3nRjxJQ1mpEuz2Z9ICP4Hpegqx9lrkIT1H6fid00PkHgdFDjsm53mXDWlSGIMT8Fde0R1eNqxHTLn08AYbm38XO+mdcN9rFqib70HG9+y/9z7ulw3Tze0k6Gdxbp4PyzjoRbcfAQ== X-YMail-OSG: 7h_bsg0VM1lHFiPrA81YGj43xU99haCmFa.dOgqmlRS5e7Q7nzy1cQy2XID3I5. ._2YHV.ZB.nD2geiLa3bv8c5MdSLjtt72Gjq_3t64fRlIAOdV8zWRc95SS0QxrtY9lAgKokBr65t R2B4WObb54yAckZLK2KXcESDQXP17Lcg5MBjL3oVbcny33SaACMt39_ySMnlUW73PDPak4Vl8vyw nz03exIYuynrsSb3DcKC4z9_04TWVifjnmH6jaderVyABg3rOFbuAT3OkmSt1dtw7r7HmLBca67S sMcvWDsEdfFCwnOeqAPOd1BAqi4WTnytG9wlnwlzzk6DaKko2_VJCA1gYwJUF688rn.2bEbn2Ot4 67wTnGvqdrZx03I_r23ipdX8H9jca5w26QkHQaFCklUrQ5dLaqSiKljOwu4HTg2UWpcYX4Gyu43o cPpnMOeG9GMGwG4eTP0GJvZdYfyPK6bwWxW2jsiDEchnOAGEPjAMZUsjScX_4dFkb9a9v_bxNPed WFQEioSl8sBtMeTtOy0M2iVkeXhtVO9tw1sBLwUBciMZ5fEOWQ_9grOfYKr38rnvc_2monOADHaz gaRDvI46Tn7DP.OX9b3a71r2qgb5CM32JMh.RJM6PR9vi7hwaURlhLePK0cfjdKzRu2ZymmeSOeK gNVxHz5m8CWokm.DR54v3O84uYWtemnwcxHg3x.41ooL1BqwAHaWnbNBbW7ZJ.on_enkjJ48X9jJ 4CleEAbT9tll4CNE_HPlbCq6hZsA..KTclJrhZJQT6NpdlHMUjymrrUzWq3C64JuGVDwkpwzliSJ QrGEMCQWpn.jXXd4SX_.KS55Jxw8pB7087bGpNdo0yMSuwni8yTcyLddOauS0FZMapNhYXfrzDBf iq4Wgw9xqybrWMdsOskADppkq5Ew7UgsgN35P1Zns0FvB.2mSyZdbVFTB.rCxjgVJnXFkSfCiz27 4.5xsgxagaSg1.hsSD6WBjVOJLacE2mLKUtWeU1GsVesaxZJ56GjhuwIUHQZsHW6ZzsT2H4V8mJN ThM1jBW9FYbbUSs6i3hKFMcWbBktUA7VUeHF_Mqvr0AP4XcPv4xad6WmOWiFki4oprHeuh5QTtgR YEbF4y71b5AOohbxqnLy7orJr0OSGG6kv.NgNlCuFa7fGSLugKPx3_iRCBeIv7aMkIisi380pKHl 7dR3b.FOe2gXjxIKll2gPMdssrHyN6UxS4DmdLd7Qf3SF3GWoN9Ta5o8k5QC9rZnDrvutX_.hWBV CoRYrFuhb3ym.MK2IbPLqh3SfiXgd1HhWzib0EC.OvFSn.7QSV2zOpeFmQdvTQnOP96c.KForpx_ jT9qykEZs9ts38fS8TPHkoqEPA0jWjmGO3eOxFTRumSHQJP4oQMr_H5q8hiF6LlHXZp7jnvUayHG hepgwPtWj0Svd5.byTyBrMBM8ZR8447kK Received: from sonic.gate.mail.ne1.yahoo.com by sonic303.consmr.mail.bf2.yahoo.com with HTTP; Sat, 27 Jun 2020 16:35:39 +0000 Received: by smtp428.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 552f1781b1a3f480221e2376e59b1bfb; Sat, 27 Jun 2020 16:35:36 +0000 (UTC) To: Toerless Eckert Cc: Brian E Carpenter , "Owen Friel (ofriel)" , Eric Rescorla , rfcSELF+fd89b714F3db00000200000064000000+area51.research@acp.example.com, Anima WG References: <6981a76f-76f1-e9b2-319d-473c7a4bc847@verizon.net> <6c4e402f-cce6-daff-aa16-6159340f0802@gmail.com> <9c09debe-3463-a574-46cf-cee86a2c68af@verizon.net> <20200627141911.GA49753@faui48f.informatik.uni-erlangen.de> From: Stephen Kent Message-ID: Date: Sat, 27 Jun 2020 12:35:35 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <20200627141911.GA49753@faui48f.informatik.uni-erlangen.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Mailer: WebService/1.1.16138 hermes_aol Apache-HttpAsyncClient/4.1.4 (Java/11.0.7) Archived-At: Subject: Re: [Anima] representing ACP info in X.509 certs X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jun 2020 16:35:42 -0000 Toerless, > Dear Stephen, > > Thank you very much for your thoughts, but i do not think we can move > the discussion ahead when it stops with non-technical opinion dropping > statements like "lets not play games" (you) or "i do not think this > is the right thing to do" (Ben/Russ). > > Could you please explain your assertion with technical arguments ? The ID goes to great lengths to justify the use of the rfc822Name field for this context, rather than defining a new data type.  If this was the obvious "right" thing to do, there would not need to be so much text justifying the choice ("The lady doth protest too much, methinks"). I am not an AD;  I don't have a vote on this. If PKIX were still an active WG, and if someone came to me and asked about the choice of identifier in the ACP context, I would say that it was a questionable choice, given 25+ years of experience with PKI standards and technologies. As I noted in a prior message, when Netscape elected to shove a DNS name into the common name field, it was a questionable choice, and we have had to live with the result for 20+ years. Elliot Lear's messages  suggest that this choice was motivated , at least in part, by expediency, but he believes that sometimes expediency is an OK justification in these matters. Personally, I don't, but, ... Steve From nobody Sat Jun 27 13:03:54 2020 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B5033A00AD for ; Sat, 27 Jun 2020 13:03:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=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 YPtnHbtAgZgI for ; Sat, 27 Jun 2020 13:03:50 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D04F73A0062 for ; Sat, 27 Jun 2020 13:03:49 -0700 (PDT) Received: from [192.168.217.116] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 49vPpC0GDhzyZD; Sat, 27 Jun 2020 22:03:46 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Carsten Bormann In-Reply-To: <001001d64c58$98890d40$c99b27c0$@x500.eu> Date: Sat, 27 Jun 2020 22:03:46 +0200 Cc: anima@ietf.org X-Mao-Original-Outgoing-Id: 614981026.328643-24cdf8bb248348331fa667ec76c53425 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20200624023407.GA41244@faui48f.informatik.uni-erlangen.de> <13005.1593208602@localhost> <001001d64c58$98890d40$c99b27c0$@x500.eu> To: Erik Andersen X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Anima] [lamps] on certification authorities. X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jun 2020 20:03:53 -0000 On 2020-06-27, at 09:57, Erik Andersen wrote: >=20 > There certainly is a big difference between the term certification (an = act) > and the term certificate (a data value). Certification implies that = the CA > does some validation before issuing a certificate.=20 Well, I maybe have a different perception because I=E2=80=99m German: = the German word for the place that certifies that you are allowed to = drive a car is =E2=80=9CF=C3=BChrerscheinstelle=E2=80=9D (*), =E2=80=9CDri= ving License Office=E2=80=9D. Not =E2=80=9CDriving Licensing Office=E2=80= =9D. Because the result is what the customer cares about, not the = process. Then, of course, RFC 5280 gets to define the term for X.509v3, so = =E2=80=9Ccertification authority=E2=80=9D it is. (But, like with URIs and URLs, and TLS and SSL, and many other things, a = different term is then used by the unwashed masses. And, infuriatingly, = by the people that cater to those masses instead of preferring the = ground truth they know.) Gr=C3=BC=C3=9Fe, Carsten (*) That office might be part of the Fahrerlaubnisbeh=C3=B6rde, but I = digress. Same thing. From nobody Sat Jun 27 13:18:43 2020 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F6C53A00C9 for ; Sat, 27 Jun 2020 13:18:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=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 f3xcibQmeBe3 for ; Sat, 27 Jun 2020 13:18:38 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47C3E3A00C4 for ; Sat, 27 Jun 2020 13:18:37 -0700 (PDT) Received: from [192.168.217.116] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 49vQ7H3yMYzybM; Sat, 27 Jun 2020 22:18:35 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Carsten Bormann In-Reply-To: <001001d64c58$98890d40$c99b27c0$@x500.eu> Date: Sat, 27 Jun 2020 22:18:34 +0200 Cc: anima@ietf.org X-Mao-Original-Outgoing-Id: 614981914.4838409-966d771d340f23f91727b8be2d355c53 Content-Transfer-Encoding: quoted-printable Message-Id: <45FA4A1E-FC9B-4194-933A-A2DA1E8C14B9@tzi.org> References: <20200624023407.GA41244@faui48f.informatik.uni-erlangen.de> <13005.1593208602@localhost> <001001d64c58$98890d40$c99b27c0$@x500.eu> To: Erik Andersen X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Anima] [lamps] on certification authorities. X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jun 2020 20:18:42 -0000 On 2020-06-27, at 09:57, Erik Andersen wrote: >=20 > certificate authority 4 matches in 1id-abstracts.txt. 7292 files on my laptop happen to match. Enjoy how RFC 4523 dances right into the fire here: ( 2.5.6.16 NAME 'certificationAuthority' DESC 'X.509 certificate authority' SUP top AUXILIARY MUST ( authorityRevocationList $ certificateRevocationList $ cACertificate ) MAY crossCertificatePair ) RFCs with =E2=80=9Ccertificate authority=E2=80=9D released before RFC = 5280: rfc1305.txt rfc2246.txt rfc2408.txt rfc2633.txt rfc2634.txt rfc2752.txt rfc2828.txt rfc2847.txt rfc2904.txt rfc3108.txt rfc3182.txt rfc3193.txt rfc3520.txt rfc3552.txt rfc3588.txt rfc3720.txt rfc3723.txt rfc3760.txt rfc3851.txt rfc3854.txt rfc3911.txt rfc3920.txt rfc3923.txt rfc4171.txt rfc4230.txt rfc4255.txt rfc4261.txt rfc4346.txt rfc4474.txt rfc4523.txt rfc4534.txt rfc4582.txt rfc4795.txt rfc4870.txt rfc4949.txt rfc4953.txt rfc5040.txt rfc5197.txt rfc5246.txt RFCs with =E2=80=9Ccertificate authority=E2=80=9D released after RFC = 5280: rfc5479.txt rfc5763.txt rfc5765.txt rfc5981.txt rfc6101.txt rfc6187.txt rfc6189.txt rfc6376.txt rfc6406.txt rfc6810.txt rfc6818.txt rfc6837.txt rfc6940.txt rfc6950.txt rfc6962.txt rfc7143.txt rfc7146.txt rfc7211.txt rfc7340.txt rfc7378.txt rfc7427.txt rfc7533.txt rfc7576.txt rfc7671.txt rfc7826.txt rfc7858.txt rfc7859.txt rfc7958.txt rfc8023.txt rfc8071.txt rfc8446.txt rfc8572.txt rfc8705.txt (Not all of these are about X.509 certificates, of course. And I=E2=80=99m probably missing a few because line breaking obscures = the combination.) Yes, you saw TLS 1.0, 1.1, 1.2, and 1.3 there. Now starting to write the errata reports :-) Gr=C3=BC=C3=9Fe, Carsten From nobody Sat Jun 27 13:47:55 2020 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 156E83A0796 for ; Sat, 27 Jun 2020 13:47:54 -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, FREEMAIL_FROM=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 OkngUwIm21J7 for ; Sat, 27 Jun 2020 13:47:52 -0700 (PDT) Received: from mail-pf1-x432.google.com (mail-pf1-x432.google.com [IPv6:2607:f8b0:4864:20::432]) (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 465073A077A for ; Sat, 27 Jun 2020 13:47:52 -0700 (PDT) Received: by mail-pf1-x432.google.com with SMTP id u5so6185274pfn.7 for ; Sat, 27 Jun 2020 13:47:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=gOHzTXBObxEUejNLxFcLAaBE3l3VjdTyDIs1psxe1t0=; b=splLLne/39dOOIZqCIjalQKKjoU8ae1l3k7ZBNkCMG2/U8qM/pUx9THDwuze9Vv4EJ rxsSTaEGFEJsp1REmNmvUSKt612G+2knM4o4shFVXX5wdFUiYaRpbn3BuJOycpLQ3Uh/ DX7bU3rSBY634xQhiL9jnnPZdLDhP/SoZOEsXrJykiSz6hAvDbBvkfySWU9GlYB5IcXJ oOPownarztS1+jycC1cgZpTZBGg1bePhL1M2R1htqCPWRc275bpWb044nrKR3daGiNDN iofVIePFEuikJWoSGL/n2Hb9AYBxw+TmQ+Tc7N8KpP1CCzrvhkkjCVP4XufGs6YRxas9 XEFg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=gOHzTXBObxEUejNLxFcLAaBE3l3VjdTyDIs1psxe1t0=; b=SyTS6Q+63Vl4LBZCaDz5l9YdMYMdLZPwCnyflbpePRfQg5ybfAi0Di0F1+KbbTQ+na 98Oy3Xb94D4d5vYwDkr9hE17Z1+GePQ8gB6otQqo6mLyOw8mgXKvIGYM8y5EdsuDmeP5 hJ5OPL+taHBngEUp99xUaWjT3c5sZo0c+1hWNgNNJSzFERr9i5SlRQ3YX3/jG+n75UEG 9L7kllWV159vVd5NTucOM8AmZ+yjvOwlh/tELRwY8kKUyDB/bw4ADDmHaPWGx2K3C5YM H2N3tu0Ch5x1QZF5ayByUMUSth7i5zwIpDdRGV9x+vxS7HFwkY815aeKQqxUlQNrQR+H 1/7Q== X-Gm-Message-State: AOAM531qjAds0MW2MVAap1Q22mXdgTJ1pshXe9IOUurMYdUtbupJcfPY yDQtNnDv6Frd8zRubg4YFHAYx55o9p8= X-Google-Smtp-Source: ABdhPJyrfi9Iau9XNgzw5arZXyarsY2Sb3fTk5RYU98xpBGSfZZa5L9v0DVCn6cNTfAM+Ael02GDBA== X-Received: by 2002:a63:dd42:: with SMTP id g2mr4774672pgj.442.1593290871341; Sat, 27 Jun 2020 13:47:51 -0700 (PDT) Received: from [192.168.178.20] (203.90.69.111.dynamic.snap.net.nz. [111.69.90.203]) by smtp.gmail.com with ESMTPSA id u13sm7396551pjy.40.2020.06.27.13.47.48 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 27 Jun 2020 13:47:50 -0700 (PDT) To: Russ Housley , Toerless Eckert Cc: Michael Richardson , Ben Kaduk , anima@ietf.org References: <11428.1592266833@localhost> <20200617024412.GA11992@kduck.mit.edu> <9584c5cd-c68d-ddc3-0704-da672842e359@gmail.com> <9406.1592756905@localhost> <3A92516D-B980-4231-9059-EF7234BA8610@vigilsec.com> <20200627054056.GA35664@faui48f.informatik.uni-erlangen.de> From: Brian E Carpenter Organization: University of Auckland Message-ID: <0bec7478-2661-71fe-2263-d0f5d3e75ba9@gmail.com> Date: Sun, 28 Jun 2020 08:47:46 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] Russ: Re: rfc822Name use in Autonomic Control Plane document X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jun 2020 20:47:54 -0000 On 28-Jun-20 03:52, Russ Housley wrote: > Toerless: > > I think Brian actually made my point. While the filed contains an email address, using it as such would result in a delivery failure. The private key holder cannot be reached by this address. I don't see a requirement in RFC5280 that the email address in an rfc822name must be reachable, or that it must belong to the private key holder. Brian > > Russ > > >> On Jun 27, 2020, at 1:40 AM, Toerless Eckert wrote: >> >> Russ, >> >> Top posting re. your ACP vs. ACME question. >> >> ACP rfc822name are meant to be under control of the ACP network operations. >> aka: the ACP registrars could be controlling rfcSELF*@example.com mailboxes using >> ACME S/MIME to get rfcSELF*@example.com certificates or IMHO easier control >> the acp.example.com MTA. Just no need/benefit to do this now IMHO: >> >> An ACP is a private network which is ideally isolated from other >> ACP networks by use of private TA. Using the ACME rfc822name scheme would >> IMHO create a lot of attack components (all the MTA in the mail path >> and domain names) if used acros the Internet - without benefits for >> ACP. Of course, if it was all a private ACME setup within an enterprise, >> and using mailboxes and ACME is a popular choice - sure, why not. >> But for private CA setups there are existing IMO easier options >> (private CA VMs using EST or the like). >> >> IMHO public ACME CAwith S/MIME authenitcation could make sense >> in the future to enable authentication across different ACP domains. >> >> Any network has links into other domains and today they are usually >> unauthenticated, that could be solved IMHO fairly easily. >> >> "private" CA of ACP domain , lets call it acpCA signs all ACP certs. >> Its own cert is not self-signed, but signed by ACME CA via S/MIME, >> maybe email is rfcSELF@example.com (no ACP IPv6 address in it) >> >> Now the ACP nodes actually use acpCA PLUS ACMA CA's as TA. >> After IKEv2 authenticates neigbor the followup ACP domain membership >> step checks if the TA of the peer is acpCA. If yes, then peer >> becomes ACP member, otherwise we have an authenticated signalling >> channel to an interdomain / different CA peer. And that of course >> would enable better/secure auto-configuration of such interdomain >> links. >> >> This gives me good mix of security: Its still only relying on >> well controlled private TA to get into ACP, but also doubles >> at less secure but best available "Internet/Interdomain" >> authentication. >> >> Cheers >> Toerless >> >> On Sun, Jun 21, 2020 at 12:36:06PM -0400, Russ Housley wrote: >>>> On Jun 21, 2020, at 12:28 PM, Michael Richardson wrote: >>>> >>>> >>>> Russ Housley wrote: >>>>> One cannot send email to the character string in this specification, so >>>>> it should not be carried in the rfc822name. >>>> >>>> You can send email to that character string if you configure the MX. >>>> It was designed specifically to accomodate that. >>>> >>>> I objected at the time: I thought it was a stupid feature, that no sensible IKEv2 daemon >>>> was going to have to send/receive email. >>>> >>>> But, Toerless was paranoid that if we did anything at all out of the >>>> ordinary, that the corporate CA people, in order to protect their fiefdom, >>>> would freak out and throw some huge roadblock in the way of deploying the ACP. >>>> >>>> And, now have an ACME method past WGLC that does certificate validation by >>>> SMTP. >>> >>> Looking at the email certificate enrollment work in the ACME WG (draft-ietf-acme-email-smime-08), I have a hard time seeing how the device that knows the private key could participate in such a protocol. How do you see it working? >>> >>> Russ >>> >> >> >> >>> _______________________________________________ >>> Anima mailing list >>> Anima@ietf.org >>> https://www.ietf.org/mailman/listinfo/anima >> >> >> -- >> --- >> tte@cs.fau.de > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima > From nobody Sat Jun 27 14:27:54 2020 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 348EF3A0805 for ; Sat, 27 Jun 2020 14:27:52 -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, SPF_HELO_NONE=0.001, SPF_NONE=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 80QxcIr3qF67 for ; Sat, 27 Jun 2020 14:27:50 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7AA93A0801 for ; Sat, 27 Jun 2020 14:27:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 59329300B40 for ; Sat, 27 Jun 2020 17:27:48 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 5TGrIQXMwpE1 for ; Sat, 27 Jun 2020 17:27:46 -0400 (EDT) Received: from a860b60074bd.fios-router.home (pool-72-66-113-56.washdc.fios.verizon.net [72.66.113.56]) by mail.smeinc.net (Postfix) with ESMTPSA id 00226300A55; Sat, 27 Jun 2020 17:27:45 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.14\)) From: Russ Housley In-Reply-To: <0bec7478-2661-71fe-2263-d0f5d3e75ba9@gmail.com> Date: Sat, 27 Jun 2020 17:27:46 -0400 Cc: Toerless Eckert , Michael Richardson , Ben Kaduk , anima@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <020EE6AB-26B3-419B-8D5D-F573891E7293@vigilsec.com> References: <11428.1592266833@localhost> <20200617024412.GA11992@kduck.mit.edu> <9584c5cd-c68d-ddc3-0704-da672842e359@gmail.com> <9406.1592756905@localhost> <3A92516D-B980-4231-9059-EF7234BA8610@vigilsec.com> <20200627054056.GA35664@faui48f.informatik.uni-erlangen.de> <0bec7478-2661-71fe-2263-d0f5d3e75ba9@gmail.com> To: Brian Carpenter X-Mailer: Apple Mail (2.3445.104.14) Archived-At: Subject: Re: [Anima] Russ: Re: rfc822Name use in Autonomic Control Plane document X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jun 2020 21:27:52 -0000 Brian: >> I think Brian actually made my point. While the filed contains an = email address, using it as such would result in a delivery failure. The = private key holder cannot be reached by this address. >=20 > I don't see a requirement in RFC5280 that the email address in an = rfc822name must be reachable, or that it must belong to the private key = holder. We seem to be interpreting RFC 5280, Sections 4.1.2.6 and 4.2.16 = differently. 4.1.2.6. Subject The subject field identifies the entity associated with the public key stored in the subject public key field. The subject name MAY be carried in the subject field and/or the subjectAltName extension. = ... 4.2.1.6. Subject Alternative Name ... When the subjectAltName extension contains an Internet mail address, the address MUST be stored in the rfc822Name. The format of an rfc822Name is a "Mailbox" as defined in Section 4.1.2 of [RFC2821]. A Mailbox has the form "Local-part@Domain". Note that a Mailbox has no phrase (such as a common name) before it, has no comment (text surrounded in parentheses) after it, and is not surrounded by "<" and ">". Rules for encoding Internet mail addresses that include internationalized domain names are specified in Section 7.5. Section 4.1.2 of RFC 2821 provides the ABNF for the Mailbox. RFC 2821 says: As used in this specification, an "address" is a character string that identifies a user to whom mail will be sent or a location into which mail will be deposited. The term "mailbox" refers to that depository. ... So, the mailbox is the place that email gets sent to. Russ From nobody Sat Jun 27 15:46:50 2020 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6B843A00B0 for ; Sat, 27 Jun 2020 15:46:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.87 X-Spam-Level: X-Spam-Status: No, score=-0.87 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=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 e3nN-5OBAhS6 for ; Sat, 27 Jun 2020 15:46:46 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DAF1E3A00B2 for ; Sat, 27 Jun 2020 15:46:45 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 6120D54843F; Sun, 28 Jun 2020 00:46:40 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 53A5B440043; Sun, 28 Jun 2020 00:46:40 +0200 (CEST) Date: Sun, 28 Jun 2020 00:46:40 +0200 From: Toerless Eckert To: Russ Housley Cc: Michael Richardson , anima@ietf.org, Ben Kaduk Message-ID: <20200627224640.GA41058@faui48f.informatik.uni-erlangen.de> References: <11428.1592266833@localhost> <20200617024412.GA11992@kduck.mit.edu> <9584c5cd-c68d-ddc3-0704-da672842e359@gmail.com> <9406.1592756905@localhost> <3A92516D-B980-4231-9059-EF7234BA8610@vigilsec.com> <20200627054056.GA35664@faui48f.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [Anima] Russ: Re: rfc822Name use in Autonomic Control Plane document X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jun 2020 22:46:49 -0000 On Sat, Jun 27, 2020 at 11:52:20AM -0400, Russ Housley wrote: > Toerless: > > I think Brian actually made my point. While the filed contains an email address, using it as such would result in a delivery failure. The private key holder cannot be reached by this address. Russ, i said: > First of all, you can if you want to, ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Aka: Yes, if an ACP admin thinks ACME style challenge/reply email authentication mechanism is useful, then he can of course set up those email addresses accordingly. I did reply to that point exhaustively in my reply about the ACME email mechanism. Why do you ignore that answer ? > and secondly, i contest that it is a requirement to be able > to do that if the recipient doesn't need to support it. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > Think about noreply@bad-corporation.com. > You do want to make sure though that you are in control of > the electronic mail address though, and that is given for ACP > addresses. Where in rfc5280 or any other generic RFC about certificates does it say you MUST have a mailbox that is reachable ? Where does it say that all certificiates with rfc822Name must be email boxes that support ACME email style challenge-reply about the email address ? I think this is a non-existing requirement against email addresses. Of course, noreply@bad-corporation.com can have a certificate with that rfc822Name. It just can't use the ACME mechanism to be generated. But the signed mails sent from that address can be authenticated. Or there are never emails, because the email address just serves as identifier of an entity such as in wifi roaming identification and authentication. In that case you are not authenticating e.g.: password ownership for the email address via actual emails but via AAA protocols against a DNS domain known AAA server for the domain part of the email address. If you want to write a standards track RFC that all email addresses used in any X.509v3 certificate MUST support an ACME style challenge/reply email, then please do that, and seee if you get thast through. If would invalidate a lot of solutions like those wifi roaming ones. It WOULD NOT invalidate the ACP solution, because as said (no several times) the ACP solution can perfectly be set up to support this. It just does not need to. Cheers Toerless > Russ > > > > On Jun 27, 2020, at 1:40 AM, Toerless Eckert wrote: > > > > Russ, > > > > Top posting re. your ACP vs. ACME question. > > > > ACP rfc822name are meant to be under control of the ACP network operations. > > aka: the ACP registrars could be controlling rfcSELF*@example.com mailboxes using > > ACME S/MIME to get rfcSELF*@example.com certificates or IMHO easier control > > the acp.example.com MTA. Just no need/benefit to do this now IMHO: > > > > An ACP is a private network which is ideally isolated from other > > ACP networks by use of private TA. Using the ACME rfc822name scheme would > > IMHO create a lot of attack components (all the MTA in the mail path > > and domain names) if used acros the Internet - without benefits for > > ACP. Of course, if it was all a private ACME setup within an enterprise, > > and using mailboxes and ACME is a popular choice - sure, why not. > > But for private CA setups there are existing IMO easier options > > (private CA VMs using EST or the like). > > > > IMHO public ACME CAwith S/MIME authenitcation could make sense > > in the future to enable authentication across different ACP domains. > > > > Any network has links into other domains and today they are usually > > unauthenticated, that could be solved IMHO fairly easily. > > > > "private" CA of ACP domain , lets call it acpCA signs all ACP certs. > > Its own cert is not self-signed, but signed by ACME CA via S/MIME, > > maybe email is rfcSELF@example.com (no ACP IPv6 address in it) > > > > Now the ACP nodes actually use acpCA PLUS ACMA CA's as TA. > > After IKEv2 authenticates neigbor the followup ACP domain membership > > step checks if the TA of the peer is acpCA. If yes, then peer > > becomes ACP member, otherwise we have an authenticated signalling > > channel to an interdomain / different CA peer. And that of course > > would enable better/secure auto-configuration of such interdomain > > links. > > > > This gives me good mix of security: Its still only relying on > > well controlled private TA to get into ACP, but also doubles > > at less secure but best available "Internet/Interdomain" > > authentication. > > > > Cheers > > Toerless > > > > On Sun, Jun 21, 2020 at 12:36:06PM -0400, Russ Housley wrote: > >>> On Jun 21, 2020, at 12:28 PM, Michael Richardson wrote: > >>> > >>> > >>> Russ Housley wrote: > >>>> One cannot send email to the character string in this specification, so > >>>> it should not be carried in the rfc822name. > >>> > >>> You can send email to that character string if you configure the MX. > >>> It was designed specifically to accomodate that. > >>> > >>> I objected at the time: I thought it was a stupid feature, that no sensible IKEv2 daemon > >>> was going to have to send/receive email. > >>> > >>> But, Toerless was paranoid that if we did anything at all out of the > >>> ordinary, that the corporate CA people, in order to protect their fiefdom, > >>> would freak out and throw some huge roadblock in the way of deploying the ACP. > >>> > >>> And, now have an ACME method past WGLC that does certificate validation by > >>> SMTP. > >> > >> Looking at the email certificate enrollment work in the ACME WG (draft-ietf-acme-email-smime-08), I have a hard time seeing how the device that knows the private key could participate in such a protocol. How do you see it working? > >> > >> Russ > >> > > > > > > > >> _______________________________________________ > >> Anima mailing list > >> Anima@ietf.org > >> https://www.ietf.org/mailman/listinfo/anima > > > > > > -- > > --- > > tte@cs.fau.de -- --- tte@cs.fau.de From nobody Sat Jun 27 15:59:04 2020 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 267323A079D for ; Sat, 27 Jun 2020 15:59:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, 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 (2048-bit key) header.d=rtfm-com.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 p4pbVukKcSr6 for ; Sat, 27 Jun 2020 15:58:59 -0700 (PDT) Received: from mail-lf1-x133.google.com (mail-lf1-x133.google.com [IPv6:2a00:1450:4864:20::133]) (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 233683A0766 for ; Sat, 27 Jun 2020 15:58:59 -0700 (PDT) Received: by mail-lf1-x133.google.com with SMTP id d21so7003500lfb.6 for ; Sat, 27 Jun 2020 15:58:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=7/aDGa2hX4NzjXYSFCLqxNdDK0MbBwvNSwgsH95NFeU=; b=gQZG3uxwrEYE0WPr2OQKqnCWEYVJKFvkpgVKIrJVoOYT2u/0s6NUfTLUQe7QMdklFC ThoZ3FKj8NJx0W94JYKeyHS/PQqoBJVOiFAh6ctoCTz0Kg9F0UGCjJ+NYT/1szsEj5mX rGwd6aKM9EAzgDSWBSiADBL5qbJa6WPRC57es4NU3sxO4zSH0rX0L0ILC+PR049ywRx+ Li0kHaFmreaOhz0aC1ewcbkBTiNXXWDCX+2wPfNOuWuhbmiyNCbgoxdhdcCK0qns9N5T 5QVSPJE0uunRuw7h5L0WLyIANHQ12FDyDWBv5KOF28SCDGK1YaVyxxDWr1RSSQevE3QG GgNQ== 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=7/aDGa2hX4NzjXYSFCLqxNdDK0MbBwvNSwgsH95NFeU=; b=qUe6sd/3WYxlAjxUi9/uwIBgyMIfUW6P3Df+KQ+NT6y8sjue79uinKs4NgJyGZw4lF jBSItAjQyC4KLp052F1GUbeHN+OHthLJQrqKqCLL+CQqxW93Vdl3YJ3CRqFhciHuU80R EiImEHrZaLH/otqRXYto3AWVDOovn0rynpRYyuUW0oWd+d3/knpWO1EUI0m3FjH0dl+S 2c2JRrM4I4KtG8GleR7AP0/uH04Lefy5l1VpGjER9NXaQKwRFpWaIQjW0sRKoorccWJI Ja61LKHx3j+Yi5pNC3nzl5JYUpHNd4akuz0qGZ4nZ6j8dq9hjmirE+54Ue49E+/XKadv 0OfA== X-Gm-Message-State: AOAM533bkPpyrAzrrwJIh65VEPkh1yx6SMqmvjxxG92DgybYeAgzOB4W xyuXLodBichG45jiMfAVC1K4es2M4bp+pUF5xsqGHWrcEVE= X-Google-Smtp-Source: ABdhPJwc+YxX9GKT/sxI4sX4hOGby91DW45IN2W/Lcs9/jiKVDftaBxcy5hQyRbQWYgiZkqcNb/TTzcV67SUNCvUuuM= X-Received: by 2002:ac2:5f0b:: with SMTP id 11mr5506370lfq.201.1593298737161; Sat, 27 Jun 2020 15:58:57 -0700 (PDT) MIME-Version: 1.0 References: <11428.1592266833@localhost> <20200617024412.GA11992@kduck.mit.edu> <9584c5cd-c68d-ddc3-0704-da672842e359@gmail.com> <9406.1592756905@localhost> <3A92516D-B980-4231-9059-EF7234BA8610@vigilsec.com> <20200627054056.GA35664@faui48f.informatik.uni-erlangen.de> <20200627224640.GA41058@faui48f.informatik.uni-erlangen.de> In-Reply-To: <20200627224640.GA41058@faui48f.informatik.uni-erlangen.de> From: Eric Rescorla Date: Sat, 27 Jun 2020 15:58:21 -0700 Message-ID: To: Toerless Eckert Cc: Russ Housley , Michael Richardson , Ben Kaduk , Anima WG Content-Type: multipart/alternative; boundary="0000000000003ffa0b05a918c5d4" Archived-At: Subject: Re: [Anima] Russ: Re: rfc822Name use in Autonomic Control Plane document X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jun 2020 22:59:02 -0000 --0000000000003ffa0b05a918c5d4 Content-Type: text/plain; charset="UTF-8" I'm not Russ, but I don't take his point to be about ACME one way or the other. Rather, I take his point to be (as he just said in his response to Brian) that while this is *formatted* as an e-mail address, it does not in fact correspond to something to which e-mail can be delivered and therefore does not match the semantics of RFC 5280. Taking a step back from the substantive issue, it seems to me that to the extent to which their is debate about the meaning of 5280, this is a discussion which cannot be resolved entirely on this list, but instead needs to involve the LAMPS WG. -Ekr On Sat, Jun 27, 2020 at 3:46 PM Toerless Eckert wrote: > On Sat, Jun 27, 2020 at 11:52:20AM -0400, Russ Housley wrote: > > Toerless: > > > > I think Brian actually made my point. While the filed contains an email > address, using it as such would result in a delivery failure. The private > key holder cannot be reached by this address. > > Russ, i said: > > > First of all, you can if you want to, > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > Aka: Yes, if an ACP admin thinks ACME style challenge/reply > email authentication mechanism is useful, then he can of course > set up those email addresses accordingly. I did reply to that > point exhaustively in my reply about the ACME email mechanism. > > Why do you ignore that answer ? > > > and secondly, i contest that it is a requirement to be able > > to do that if the recipient doesn't need to support it. > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > > Think about noreply@bad-corporation.com. > > You do want to make sure though that you are in control of > > the electronic mail address though, and that is given for ACP > > addresses. > > Where in rfc5280 or any other generic RFC about certificates does > it say you MUST have a mailbox that is reachable ? Where does it > say that all certificiates with rfc822Name must be email boxes > that support ACME email style challenge-reply about the email address ? > I think this is a non-existing requirement against email addresses. > > Of course, noreply@bad-corporation.com can have a certificate with > that rfc822Name. It just can't use the ACME mechanism to be > generated. But the signed mails sent from that address can be > authenticated. > > Or there are never emails, because the email address just serves > as identifier of an entity such as in wifi roaming identification > and authentication. In that case you are not authenticating > e.g.: password ownership for the email address via actual emails > but via AAA protocols against a DNS domain known AAA server > for the domain part of the email address. > > If you want to write a standards track RFC that all email addresses > used in any X.509v3 certificate MUST support an ACME style > challenge/reply email, then please do that, and seee if you get > thast through. If would invalidate a lot of solutions like > those wifi roaming ones. It WOULD NOT invalidate the ACP > solution, because as said (no several times) the ACP solution > can perfectly be set up to support this. It just does not > need to. > > Cheers > Toerless > > > Russ > > > > > > > On Jun 27, 2020, at 1:40 AM, Toerless Eckert wrote: > > > > > > Russ, > > > > > > Top posting re. your ACP vs. ACME question. > > > > > > ACP rfc822name are meant to be under control of the ACP network > operations. > > > aka: the ACP registrars could be controlling rfcSELF*@example.com > mailboxes using > > > ACME S/MIME to get rfcSELF*@example.com certificates or IMHO easier > control > > > the acp.example.com MTA. Just no need/benefit to do this now IMHO: > > > > > > An ACP is a private network which is ideally isolated from other > > > ACP networks by use of private TA. Using the ACME rfc822name scheme > would > > > IMHO create a lot of attack components (all the MTA in the mail path > > > and domain names) if used acros the Internet - without benefits for > > > ACP. Of course, if it was all a private ACME setup within an > enterprise, > > > and using mailboxes and ACME is a popular choice - sure, why not. > > > But for private CA setups there are existing IMO easier options > > > (private CA VMs using EST or the like). > > > > > > IMHO public ACME CAwith S/MIME authenitcation could make sense > > > in the future to enable authentication across different ACP domains. > > > > > > Any network has links into other domains and today they are usually > > > unauthenticated, that could be solved IMHO fairly easily. > > > > > > "private" CA of ACP domain , lets call it acpCA signs all ACP certs. > > > Its own cert is not self-signed, but signed by ACME CA via S/MIME, > > > maybe email is rfcSELF@example.com (no ACP IPv6 address in it) > > > > > > Now the ACP nodes actually use acpCA PLUS ACMA CA's as TA. > > > After IKEv2 authenticates neigbor the followup ACP domain membership > > > step checks if the TA of the peer is acpCA. If yes, then peer > > > becomes ACP member, otherwise we have an authenticated signalling > > > channel to an interdomain / different CA peer. And that of course > > > would enable better/secure auto-configuration of such interdomain > > > links. > > > > > > This gives me good mix of security: Its still only relying on > > > well controlled private TA to get into ACP, but also doubles > > > at less secure but best available "Internet/Interdomain" > > > authentication. > > > > > > Cheers > > > Toerless > > > > > > On Sun, Jun 21, 2020 at 12:36:06PM -0400, Russ Housley wrote: > > >>> On Jun 21, 2020, at 12:28 PM, Michael Richardson < > mcr+ietf@sandelman.ca> wrote: > > >>> > > >>> > > >>> Russ Housley wrote: > > >>>> One cannot send email to the character string in this > specification, so > > >>>> it should not be carried in the rfc822name. > > >>> > > >>> You can send email to that character string if you configure the MX. > > >>> It was designed specifically to accomodate that. > > >>> > > >>> I objected at the time: I thought it was a stupid feature, that no > sensible IKEv2 daemon > > >>> was going to have to send/receive email. > > >>> > > >>> But, Toerless was paranoid that if we did anything at all out of the > > >>> ordinary, that the corporate CA people, in order to protect their > fiefdom, > > >>> would freak out and throw some huge roadblock in the way of > deploying the ACP. > > >>> > > >>> And, now have an ACME method past WGLC that does certificate > validation by > > >>> SMTP. > > >> > > >> Looking at the email certificate enrollment work in the ACME WG > (draft-ietf-acme-email-smime-08), I have a hard time seeing how the device > that knows the private key could participate in such a protocol. How do > you see it working? > > >> > > >> Russ > > >> > > > > > > > > > > > >> _______________________________________________ > > >> Anima mailing list > > >> Anima@ietf.org > > >> https://www.ietf.org/mailman/listinfo/anima > > > > > > > > > -- > > > --- > > > tte@cs.fau.de > > -- > --- > tte@cs.fau.de > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima > --0000000000003ffa0b05a918c5d4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'm not Russ, but I don't take his point to b= e about ACME one way or the other.

Rather, I take = his point to be (as he just said in his response to Brian) that while this = is *formatted* as an e-mail address, it does not in fact correspond to some= thing to which e-mail can be delivered and therefore does not match the sem= antics of RFC 5280.

Taking a step back from the su= bstantive issue, it seems to me that to the extent to which their is debate= about the meaning of 5280, this is a discussion which cannot be resolved e= ntirely on this list, but instead needs to involve the LAMPS WG.
<= div>
-Ekr



<= /div>
O= n Sat, Jun 27, 2020 at 3:46 PM Toerless Eckert <tte@cs.fau.de> wrote:
On Sat, Jun 27, 2020 at 11:52:20AM -0400, Russ Housle= y wrote:
> Toerless:
>
> I think Brian actually made my point.=C2=A0 While the filed contains a= n email address, using it as such would result in a delivery failure.=C2=A0= The private key holder cannot be reached by this address.

Russ, i said:

> First of all, you can if you want to,
=C2=A0 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Aka: Yes, if an ACP admin thinks ACME style challenge/reply
email authentication mechanism is useful, then he can of course
set up those email addresses accordingly. I did reply to that
point exhaustively in my reply about the ACME email mechanism.

=C2=A0Why do you ignore that answer ?

> and secondly, i contest that it is a requirement to be able
> to do that if the recipient doesn't need to support it.
=C2=A0 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

> Think about noreply@bad-corporation.com.
> You do want to make sure though that you are in control of
> the electronic mail address though, and that is given for ACP
> addresses.

Where in rfc5280 or any other generic RFC about certificates does
it say you MUST have a mailbox that is reachable ? Where does it
say that all certificiates with rfc822Name must be email boxes
that support ACME email style challenge-reply about the email address ?
I think this is a non-existing requirement against email addresses.

Of course, noreply@bad-corporation.com can have a certificate with
that rfc822Name. It just can't use the ACME mechanism to be
generated. But the signed mails sent from that address can be
authenticated.

Or there are never emails, because the email address just serves
as identifier of an entity such as in wifi roaming identification
and authentication. In that case you are not authenticating
e.g.: password ownership for the email address via actual emails
but via AAA protocols against a DNS domain known AAA server
for the domain part of the email address.

If you want to write a standards track RFC that all email addresses
used in any X.509v3 certificate MUST support an ACME style
challenge/reply email, then please do that, and seee if you get
thast through. If would invalidate a lot of solutions like
those wifi roaming ones. It WOULD NOT invalidate the ACP
solution, because as said (no several times) the ACP solution
can perfectly be set up to support this. It just does not
need to.

Cheers
=C2=A0 =C2=A0 Toerless

> Russ
>
>
> > On Jun 27, 2020, at 1:40 AM, Toerless Eckert <tte@cs.fau.de> wrote:
> >
> > Russ,
> >
> > Top posting re. your ACP vs. ACME question.
> >
> > ACP rfc822name are meant to be under control of the ACP network o= perations.
> > aka: the ACP registrars could be controlling rfcSELF*@example.com ma= ilboxes using
> > ACME S/MIME to get rfcSELF*@example.com certificates or IMHO easier = control
> > the acp.example.com MTA.=C2=A0 Just no need/benefit to do this = now IMHO:
> >
> > An ACP is a private network which is ideally isolated from other<= br> > > ACP networks by use of private TA. Using the ACME rfc822name sche= me would
> > IMHO create a lot of attack components (all the MTA in the mail p= ath
> > and domain names) if used acros the Internet - without benefits f= or
> > ACP. Of course, if it was all a private ACME setup within an ente= rprise,
> > and using mailboxes and ACME is a popular choice - sure, why not.=
> > But for private CA setups there are existing IMO easier options > > (private CA VMs using EST or the like).
> >
> > IMHO public ACME CAwith S/MIME authenitcation could=C2=A0 make se= nse
> > in the future to enable authentication across different ACP domai= ns.
> >
> > Any network has links into other domains and today they are usual= ly
> > unauthenticated, that could be solved IMHO fairly easily.
> >
> > "private" CA of ACP domain , lets call it acpCA signs a= ll ACP certs.
> > Its own cert is not self-signed, but signed by ACME CA via S/MIME= ,
> > maybe email is rfcSELF@example.com (no ACP IPv6 address in it)
> >
> > Now the ACP nodes actually use acpCA PLUS ACMA CA's as TA. > > After IKEv2 authenticates neigbor the followup ACP domain members= hip
> > step checks if the TA of the peer is acpCA. If yes, then peer
> > becomes ACP member, otherwise we have an authenticated signalling=
> > channel to an interdomain / different CA peer. And that of course=
> > would enable better/secure auto-configuration of such interdomain=
> > links.
> >
> > This gives me good mix of security: Its still only relying on
> > well controlled private TA to get into ACP, but also doubles
> > at less secure but best available "Internet/Interdomain"= ;
> > authentication.
> >
> > Cheers
> >=C2=A0 =C2=A0 Toerless
> >
> > On Sun, Jun 21, 2020 at 12:36:06PM -0400, Russ Housley wrote:
> >>> On Jun 21, 2020, at 12:28 PM, Michael Richardson <mcr+ietf@sandelman= .ca> wrote:
> >>>
> >>>
> >>> Russ Housley <housley@vigilsec.com> wrote:
> >>>> One cannot send email to the character string in this= specification, so
> >>>> it should not be carried in the rfc822name.
> >>>
> >>> You can send email to that character string if you config= ure the MX.
> >>> It was designed specifically to accomodate that.
> >>>
> >>> I objected at the time: I thought it was a stupid feature= , that no sensible IKEv2 daemon
> >>> was going to have to send/receive email.
> >>>
> >>> But, Toerless was paranoid that if we did anything at all= out of the
> >>> ordinary, that the corporate CA people, in order to prote= ct their fiefdom,
> >>> would freak out and throw some huge roadblock in the way = of deploying the ACP.
> >>>
> >>> And, now have an ACME method past WGLC that does certific= ate validation by
> >>> SMTP.
> >>
> >> Looking at the email certificate enrollment work in the ACME = WG (draft-ietf-acme-email-smime-08), I have a hard time seeing how the devi= ce that knows the private key could participate in such a protocol.=C2=A0 H= ow do you see it working?
> >>
> >> Russ
> >>
> >
> >
> >
> >> _______________________________________________
> >> Anima mailing list
> >> Anima@iet= f.org
> >> https://www.ietf.org/mailman/listinfo/ani= ma
> >
> >
> > --
> > ---
> > tte@cs.fau.de<= /a>

--
---
tte@cs.fau.de

_______________________________________________
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima
--0000000000003ffa0b05a918c5d4-- From nobody Sat Jun 27 16:10:35 2020 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD1223A0808 for ; Sat, 27 Jun 2020 16:10:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.87 X-Spam-Level: X-Spam-Status: No, score=-0.87 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=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 rWdpjLi9P6eO for ; Sat, 27 Jun 2020 16:10:31 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D1313A07B6 for ; Sat, 27 Jun 2020 16:10:31 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 5A358548068; Sun, 28 Jun 2020 01:10:26 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 449A2440043; Sun, 28 Jun 2020 01:10:26 +0200 (CEST) Date: Sun, 28 Jun 2020 01:10:26 +0200 From: Toerless Eckert To: Stephen Kent Cc: Brian E Carpenter , "Owen Friel (ofriel)" , Eric Rescorla , rfcSELF+fd89b714F3db00000200000064000000+area51.research@acp.example.com, Anima WG Message-ID: <20200627231026.GB41058@faui48f.informatik.uni-erlangen.de> References: <6981a76f-76f1-e9b2-319d-473c7a4bc847@verizon.net> <6c4e402f-cce6-daff-aa16-6159340f0802@gmail.com> <9c09debe-3463-a574-46cf-cee86a2c68af@verizon.net> <20200627141911.GA49753@faui48f.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [Anima] representing ACP info in X.509 certs X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jun 2020 23:10:34 -0000 On Sat, Jun 27, 2020 at 12:35:35PM -0400, Stephen Kent wrote: > Toerless, > > Dear Stephen, > > > > Thank you very much for your thoughts, but i do not think we can move > > the discussion ahead when it stops with non-technical opinion dropping > > statements like "lets not play games" (you) or "i do not think this > > is the right thing to do" (Ben/Russ). > > > > Could you please explain your assertion with technical arguments ? > > The ID goes to great lengths to justify the use of the rfc822Name field for > this context, rather than defining a new data type.  If this was the obvious > "right" thing to do, there would not need to be so much text justifying the > choice ("The lady doth protest too much, methinks"). Seriously ? Because some people people do not like it and the text goes to great length to technically explain the choices, your conclusion is that it must be wrong ? Do you call that a technical argument ? > I am not an AD;  I don't have a vote on this. The IETF does not vote. We supposedly have rough consensus. I thought that means that it needs to have a sufficient community to be interested work (we hae that, ANIMA WG), and it needs to pass technical challenges. It should IMHO NOT mean that people who do not have a technical arrgument should be able to just succeed by creating a flash mob rejecting the choice and arguing "The lady doth protest too much". Aka: Yes, you did miss the timeline (just about 5 years ongoing) to argue your preference how to encode in the WG before last call. You and everybody ense in this discussion should IMHO stick to providing technical challenges why the ANIMA WG choice can technically not appropriate or suggest better technical choices. But such proposed better technical choices can not simply ignore the requirements described by the solution, and those include the long list that you like to refer to in the negative without (i think) even having read them. (section 6.1.2 numbered lists). > If PKIX were still an active > WG, and if someone came to me and asked about the choice of identifier in > the ACP context, I would say that it was a questionable choice, given 25+ > years of experience with PKI standards and technologies. How about ANY technical argument. If you hae experience, you would be able to make a technical argument. > As I noted in a prior message, when Netscape elected to shove a DNS name > into the common name field, it was a questionable choice, and we have had to > live with the result for 20+ years. If your example was actually applicable to this case, you wuld be able to describe the problem without that example. I replied to your prior email stating that i think that eample is non-applicable to this case. > Elliot Lear's messages  suggest that this choice was motivated, > at least in part, by expediency, but he believes > that sometimes expediency is an OK justification in these matters. > Personally, I don't, but, ... What experience do you have with backbone/WAN router/switches and NOC software ecosystems ? If you had any idea how fragmented/duplicated/ and ossified the target deployment environment is, you too would look for appropriate solutions that avoid unnecessary forklift upgrade requirements. Thats exactly what new attribute types introduce to achieve the same degree of ecosystem support as using existing cert attributes. Of course, this means that the solution to use an existing attribute must accordingly match the requirements for such use. So now this document has a long list of explanations why this is the case, and the only rejections we are getting are opinions, but no technical arguments. > Steve > -- --- tte@cs.fau.de From nobody Sat Jun 27 16:14:12 2020 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13EAF3A0822 for ; Sat, 27 Jun 2020 16:14:11 -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_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=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 vkV3UKNWN0M3 for ; Sat, 27 Jun 2020 16:14:10 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 D57693A0821 for ; Sat, 27 Jun 2020 16:14:09 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 05RNDqES003793 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 27 Jun 2020 19:13:54 -0400 Date: Sat, 27 Jun 2020 16:13:52 -0700 From: Benjamin Kaduk To: Eric Rescorla Cc: Toerless Eckert , Russ Housley , Michael Richardson , Anima WG Message-ID: <20200627231352.GM58278@kduck.mit.edu> References: <20200617024412.GA11992@kduck.mit.edu> <9584c5cd-c68d-ddc3-0704-da672842e359@gmail.com> <9406.1592756905@localhost> <3A92516D-B980-4231-9059-EF7234BA8610@vigilsec.com> <20200627054056.GA35664@faui48f.informatik.uni-erlangen.de> <20200627224640.GA41058@faui48f.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [Anima] Russ: Re: rfc822Name use in Autonomic Control Plane document X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jun 2020 23:14:11 -0000 My apologies for commenting before having caught up on the whole thread (I've been pretty sluggish all week and don't want to get even further behind.) On Sat, Jun 27, 2020 at 03:58:21PM -0700, Eric Rescorla wrote: > > Taking a step back from the substantive issue, it seems to me that to the > extent to which their is debate about the meaning of 5280, this is a > discussion which cannot be resolved entirely on this list, but instead > needs to involve the LAMPS WG. This has been a key point that I've (apparently) been failing to make very well so far. E.g., while the ANIMA WG has presumably reached consensus on the use of rfc822Name years ago, I think we also need consensus from LAMPS before we can be confident that there is IETF consensus. Also, making even another step back, it seems that there is a key issue of the CA model in play here, namely "know what you sign". If we are asking a CA to sign an rfc822Name, which the CA treats as having email semantics, but we assign different semantics to that name, then the CA is not actually in knowledge of what it's signing. Accordingly, the CA incurs significant (e.g., legal and financial) risk by making those signatures, and defining the field in this way gives the impression that we are trying to make an end-run around CA policies. -Ben From nobody Sat Jun 27 16:44:06 2020 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8C263A084E for ; Sat, 27 Jun 2020 16:44:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.87 X-Spam-Level: X-Spam-Status: No, score=-0.87 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=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 0KyOIbbNeg_O for ; Sat, 27 Jun 2020 16:44:02 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B11E3A084D for ; Sat, 27 Jun 2020 16:44:02 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [131.188.34.52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 6CDE2548068; Sun, 28 Jun 2020 01:43:56 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 63E5F440043; Sun, 28 Jun 2020 01:43:56 +0200 (CEST) Date: Sun, 28 Jun 2020 01:43:56 +0200 From: Toerless Eckert To: Carsten Bormann Cc: Erik Andersen , anima@ietf.org Message-ID: <20200627234356.GC41058@faui48f.informatik.uni-erlangen.de> References: <20200624023407.GA41244@faui48f.informatik.uni-erlangen.de> <13005.1593208602@localhost> <001001d64c58$98890d40$c99b27c0$@x500.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [Anima] [lamps] on certification authorities. X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jun 2020 23:44:05 -0000 On Sat, Jun 27, 2020 at 10:03:46PM +0200, Carsten Bormann wrote: > On 2020-06-27, at 09:57, Erik Andersen wrote: > > > > There certainly is a big difference between the term certification (an act) > > and the term certificate (a data value). Certification implies that the CA > > does some validation before issuing a certificate. IMHO: In one case you describe the work process (certification) in the other case the work product (certificate). If we can find examples entities that perform certification but do not produce certificates, or vice versa, then it makes sense to me to be very careful which word to use. Otherwise its just a CNAME discussion. > Well, I maybe have a different perception because I???m German: the German word for the place that certifies that you are allowed to drive a car is ???Führerscheinstelle??? (*), ???Driving License Office???. Not ???Driving Licensing Office???. Because the result is what the customer cares about, not the process. Well... I have seen a lot more obsession about process: ISO9000, process oriented company, constant redefinition of processes, etc. pp. > Then, of course, RFC 5280 gets to define the term for X.509v3, so ???certification authority??? it is. AFAIK it is much older, ISO/IEC X.509 but likely predating it. > (But, like with URIs and URLs, and TLS and SSL, and many other things, a different term is then used by the unwashed masses. And, infuriatingly, by the people that cater to those masses instead of preferring the ground truth they know.) Here some fun stats i took (copied from other email thread): google: site:cisco.com "certificate authority" -> 59,700 google: site:cisco.com "certification authority" -> 8,580 https://en.wikipedia.org/wiki/Certificate_authority grep -il "ertification authorit" rfc*.txt | wc -> 272 (#RFCs) grep -il "ertificate authorit" rfc*.txt | wc -> 136 (#RFCs) grep -il "ertification authorit" rfc8???.txt | wc -> 38 (#RFCs) grep -il "ertificate authorit" rfc8???.txt | wc -> 13 (#RFCs) Cheers Toerless > Grüße, Carsten > > (*) That office might be part of the Fahrerlaubnisbehörde, but I digress. Same thing. > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima From nobody Sat Jun 27 17:07:03 2020 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E4C63A087C for ; Sat, 27 Jun 2020 17:07:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.65 X-Spam-Level: X-Spam-Status: No, score=-1.65 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 lohVoCQliKz5 for ; Sat, 27 Jun 2020 17:06:59 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACB663A087B for ; Sat, 27 Jun 2020 17:06:59 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id A39D8548441; Sun, 28 Jun 2020 02:06:54 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 9D0FA440043; Sun, 28 Jun 2020 02:06:54 +0200 (CEST) Date: Sun, 28 Jun 2020 02:06:54 +0200 From: Toerless Eckert To: Russ Housley Cc: Brian Carpenter , Michael Richardson , Ben Kaduk , anima@ietf.org Message-ID: <20200628000654.GD41058@faui48f.informatik.uni-erlangen.de> References: <20200617024412.GA11992@kduck.mit.edu> <9584c5cd-c68d-ddc3-0704-da672842e359@gmail.com> <9406.1592756905@localhost> <3A92516D-B980-4231-9059-EF7234BA8610@vigilsec.com> <20200627054056.GA35664@faui48f.informatik.uni-erlangen.de> <0bec7478-2661-71fe-2263-d0f5d3e75ba9@gmail.com> <020EE6AB-26B3-419B-8D5D-F573891E7293@vigilsec.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <020EE6AB-26B3-419B-8D5D-F573891E7293@vigilsec.com> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [Anima] Russ: Re: rfc822Name use in Autonomic Control Plane document X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jun 2020 00:07:03 -0000 Thanks, Russ, inline On Sat, Jun 27, 2020 at 05:27:46PM -0400, Russ Housley wrote: > Brian: > > >> I think Brian actually made my point. While the filed contains an email address, using it as such would result in a delivery failure. The private key holder cannot be reached by this address. > > > > I don't see a requirement in RFC5280 that the email address in an rfc822name must be reachable, or that it must belong to the private key holder. > > We seem to be interpreting RFC 5280, Sections 4.1.2.6 and 4.2.16 differently. > > 4.1.2.6. Subject > > The subject field identifies the entity associated with the public > key stored in the subject public key field. The subject name MAY be > carried in the subject field and/or the subjectAltName extension. ... Yep. For purpose of ACP, we use rfc822Name, but the entity may get from registrar/CA other names too, such as any pre-existing, however formatted SN. > 4.2.1.6. Subject Alternative Name > > ... > > When the subjectAltName extension contains an Internet mail address, > the address MUST be stored in the rfc822Name. Yes. ACP does that. > The format of an > rfc822Name is a "Mailbox" as defined in Section 4.1.2 of [RFC2821]. > A Mailbox has the form "Local-part@Domain". Yes. ACP does that. > Note that a Mailbox has > no phrase (such as a common name) before it, has no comment (text > surrounded in parentheses) after it, and is not surrounded by "<" and > ">". Rules for encoding Internet mail addresses that include > internationalized domain names are specified in Section 7.5. Yes, ACP does that. > Section 4.1.2 of RFC 2821 provides the ABNF for the Mailbox. Yes, ACP matches that. Actually, when i did the ABNF, i had to go through a couple of RFC becaue 2821 was superceeded and i think i picked as references the now normative one, but have to go back and remember details. No actual change in the syntax AFAIK since rfc2821. > RFC 2821 says: > > As used in this specification, an "address" is a character string > that identifies a user to whom mail will be sent or a location into > which mail will be deposited. The term "mailbox" refers to that > depository. ... > > So, the mailbox is the place that email gets sent to. Do you think that this sentence makes an address of noreply@example.com an invalid email address given how it does not receive email ? And please do not conflate this discussion with the use in certificates, your discussion points about rfc2821 are non-considering any certificate work, as rfc5280 does not attempt to redecine anything. Would you also like to legislate what "user" means ? E.g.: would lamps-request@ietf.org, valid email address in your reading or does a user have to be a human ? In any case: ACP email address can perfectly well have mailboxes, You also did not repy to my expamples about other systems where email addresses are primarily used for non-mailbox purposes but still encoded in rfc822Name. I have seen no outlawing of this practice through IETF documents. Cheers Toerless > Russ -- --- tte@cs.fau.de From nobody Sat Jun 27 17:09:30 2020 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 548C33A087C for ; Sat, 27 Jun 2020 17:09:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.87 X-Spam-Level: X-Spam-Status: No, score=-0.87 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=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 pWkO9IFIVKm7 for ; Sat, 27 Jun 2020 17:09:27 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D8ED3A087B for ; Sat, 27 Jun 2020 17:09:27 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [131.188.34.52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 5C0E354843F; Sun, 28 Jun 2020 02:09:22 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 549DB440043; Sun, 28 Jun 2020 02:09:22 +0200 (CEST) Date: Sun, 28 Jun 2020 02:09:22 +0200 From: Toerless Eckert To: Eric Rescorla Cc: Russ Housley , Michael Richardson , Ben Kaduk , Anima WG Message-ID: <20200628000922.GE41058@faui48f.informatik.uni-erlangen.de> References: <20200617024412.GA11992@kduck.mit.edu> <9584c5cd-c68d-ddc3-0704-da672842e359@gmail.com> <9406.1592756905@localhost> <3A92516D-B980-4231-9059-EF7234BA8610@vigilsec.com> <20200627054056.GA35664@faui48f.informatik.uni-erlangen.de> <20200627224640.GA41058@faui48f.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [Anima] Russ: Re: rfc822Name use in Autonomic Control Plane document X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jun 2020 00:09:29 -0000 Thanks, Eric, inline On Sat, Jun 27, 2020 at 03:58:21PM -0700, Eric Rescorla wrote: > I'm not Russ, but I don't take his point to be about ACME one way or the > other. > > Rather, I take his point to be (as he just said in his response to Brian) > that while this is *formatted* as an e-mail address, it does not in fact > correspond to something to which e-mail can be delivered and therefore does > not match the semantics of RFC 5280. And i did repeatedly explain how this is not true. The ACP operator can perfectly well set up mailxobxes if he desires to. The whole question circles around the use of email addresses primairily for purposes other than sending to mailboxes, and i gave other examples where this is common industry practice and also uses certificate rfc822Name. > Taking a step back from the substantive issue, it seems to me that to the > extent to which their is debate about the meaning of 5280, this is a > discussion which cannot be resolved entirely on this list, but instead > needs to involve the LAMPS WG. Let me answer this to Ben. Cheers Toerless > -Ekr > > > > > On Sat, Jun 27, 2020 at 3:46 PM Toerless Eckert wrote: > > > On Sat, Jun 27, 2020 at 11:52:20AM -0400, Russ Housley wrote: > > > Toerless: > > > > > > I think Brian actually made my point. While the filed contains an email > > address, using it as such would result in a delivery failure. The private > > key holder cannot be reached by this address. > > > > Russ, i said: > > > > > First of all, you can if you want to, > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > > > Aka: Yes, if an ACP admin thinks ACME style challenge/reply > > email authentication mechanism is useful, then he can of course > > set up those email addresses accordingly. I did reply to that > > point exhaustively in my reply about the ACME email mechanism. > > > > Why do you ignore that answer ? > > > > > and secondly, i contest that it is a requirement to be able > > > to do that if the recipient doesn't need to support it. > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > > > > Think about noreply@bad-corporation.com. > > > You do want to make sure though that you are in control of > > > the electronic mail address though, and that is given for ACP > > > addresses. > > > > Where in rfc5280 or any other generic RFC about certificates does > > it say you MUST have a mailbox that is reachable ? Where does it > > say that all certificiates with rfc822Name must be email boxes > > that support ACME email style challenge-reply about the email address ? > > I think this is a non-existing requirement against email addresses. > > > > Of course, noreply@bad-corporation.com can have a certificate with > > that rfc822Name. It just can't use the ACME mechanism to be > > generated. But the signed mails sent from that address can be > > authenticated. > > > > Or there are never emails, because the email address just serves > > as identifier of an entity such as in wifi roaming identification > > and authentication. In that case you are not authenticating > > e.g.: password ownership for the email address via actual emails > > but via AAA protocols against a DNS domain known AAA server > > for the domain part of the email address. > > > > If you want to write a standards track RFC that all email addresses > > used in any X.509v3 certificate MUST support an ACME style > > challenge/reply email, then please do that, and seee if you get > > thast through. If would invalidate a lot of solutions like > > those wifi roaming ones. It WOULD NOT invalidate the ACP > > solution, because as said (no several times) the ACP solution > > can perfectly be set up to support this. It just does not > > need to. > > > > Cheers > > Toerless > > > > > Russ > > > > > > > > > > On Jun 27, 2020, at 1:40 AM, Toerless Eckert wrote: > > > > > > > > Russ, > > > > > > > > Top posting re. your ACP vs. ACME question. > > > > > > > > ACP rfc822name are meant to be under control of the ACP network > > operations. > > > > aka: the ACP registrars could be controlling rfcSELF*@example.com > > mailboxes using > > > > ACME S/MIME to get rfcSELF*@example.com certificates or IMHO easier > > control > > > > the acp.example.com MTA. Just no need/benefit to do this now IMHO: > > > > > > > > An ACP is a private network which is ideally isolated from other > > > > ACP networks by use of private TA. Using the ACME rfc822name scheme > > would > > > > IMHO create a lot of attack components (all the MTA in the mail path > > > > and domain names) if used acros the Internet - without benefits for > > > > ACP. Of course, if it was all a private ACME setup within an > > enterprise, > > > > and using mailboxes and ACME is a popular choice - sure, why not. > > > > But for private CA setups there are existing IMO easier options > > > > (private CA VMs using EST or the like). > > > > > > > > IMHO public ACME CAwith S/MIME authenitcation could make sense > > > > in the future to enable authentication across different ACP domains. > > > > > > > > Any network has links into other domains and today they are usually > > > > unauthenticated, that could be solved IMHO fairly easily. > > > > > > > > "private" CA of ACP domain , lets call it acpCA signs all ACP certs. > > > > Its own cert is not self-signed, but signed by ACME CA via S/MIME, > > > > maybe email is rfcSELF@example.com (no ACP IPv6 address in it) > > > > > > > > Now the ACP nodes actually use acpCA PLUS ACMA CA's as TA. > > > > After IKEv2 authenticates neigbor the followup ACP domain membership > > > > step checks if the TA of the peer is acpCA. If yes, then peer > > > > becomes ACP member, otherwise we have an authenticated signalling > > > > channel to an interdomain / different CA peer. And that of course > > > > would enable better/secure auto-configuration of such interdomain > > > > links. > > > > > > > > This gives me good mix of security: Its still only relying on > > > > well controlled private TA to get into ACP, but also doubles > > > > at less secure but best available "Internet/Interdomain" > > > > authentication. > > > > > > > > Cheers > > > > Toerless > > > > > > > > On Sun, Jun 21, 2020 at 12:36:06PM -0400, Russ Housley wrote: > > > >>> On Jun 21, 2020, at 12:28 PM, Michael Richardson < > > mcr+ietf@sandelman.ca> wrote: > > > >>> > > > >>> > > > >>> Russ Housley wrote: > > > >>>> One cannot send email to the character string in this > > specification, so > > > >>>> it should not be carried in the rfc822name. > > > >>> > > > >>> You can send email to that character string if you configure the MX. > > > >>> It was designed specifically to accomodate that. > > > >>> > > > >>> I objected at the time: I thought it was a stupid feature, that no > > sensible IKEv2 daemon > > > >>> was going to have to send/receive email. > > > >>> > > > >>> But, Toerless was paranoid that if we did anything at all out of the > > > >>> ordinary, that the corporate CA people, in order to protect their > > fiefdom, > > > >>> would freak out and throw some huge roadblock in the way of > > deploying the ACP. > > > >>> > > > >>> And, now have an ACME method past WGLC that does certificate > > validation by > > > >>> SMTP. > > > >> > > > >> Looking at the email certificate enrollment work in the ACME WG > > (draft-ietf-acme-email-smime-08), I have a hard time seeing how the device > > that knows the private key could participate in such a protocol. How do > > you see it working? > > > >> > > > >> Russ > > > >> > > > > > > > > > > > > > > > >> _______________________________________________ > > > >> Anima mailing list > > > >> Anima@ietf.org > > > >> https://www.ietf.org/mailman/listinfo/anima > > > > > > > > > > > > -- > > > > --- > > > > tte@cs.fau.de > > > > -- > > --- > > tte@cs.fau.de > > > > _______________________________________________ > > Anima mailing list > > Anima@ietf.org > > https://www.ietf.org/mailman/listinfo/anima > > -- --- tte@cs.fau.de From nobody Sat Jun 27 17:19:31 2020 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B5B43A0881 for ; Sat, 27 Jun 2020 17:19:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, 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 (2048-bit key) header.d=rtfm-com.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 Fgcx1KuWyItc for ; Sat, 27 Jun 2020 17:19:25 -0700 (PDT) Received: from mail-lf1-x12e.google.com (mail-lf1-x12e.google.com [IPv6:2a00:1450:4864:20::12e]) (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 868283A087C for ; Sat, 27 Jun 2020 17:19:24 -0700 (PDT) Received: by mail-lf1-x12e.google.com with SMTP id g2so7080538lfb.0 for ; Sat, 27 Jun 2020 17:19:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=w+dwrdBrNCoIZ5QLZtqUNVI2TOGJhIaNAHR2cOhLcBc=; b=NH6T41TGt4ndPX7owV2nixUjEK2gD36KD9wjbFYjLI98Z34bYOT29t70Fd+DBZSv1Z yt95Wk3qslng080kyR9AweSMNOEZfRvt9h5IsFkq3q9tLcN2/p9UBTbyX1pocuHBoPw3 fCUqWM2ISedBsgcN5KzrCL+Gei6LQZBKlspvYLMXazfefZYuGMMwpd90OUk84l8+whox KEALgxrB5hbHsSJmv5EdExbMATUgC9DJmZSy//IeE3ZfM5r//fHURpaEu79jWW744Pxr BdBxVZKlWa/tTwGHL7f/tRSvFtdQ7jww1u8Lwmg94zXIA4QBemSCt0QoiO1LKWwT/ty+ Allg== 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=w+dwrdBrNCoIZ5QLZtqUNVI2TOGJhIaNAHR2cOhLcBc=; b=P3+GQDq2V28xmxciYuin8WE4vcZVfSIGIcab/FmH9U9eg0tDNPuTbtxmuo1KN2GILj WtefifBoOyEswYckUatxArQiw8+PnTQ5NmKfa6eYb+E3aKTe0+dKikaJLxrWjZHL7czm sS4N1wGULsga1JR9NZyW6k1XMJ76fBAaVUGQTxVUK/wjvdeHC2uo1c8wZ+MIYc0Wy4Qf wqa+0OH4lHfNu8YSmyZAKqRBrZ7o95Dl3qJXq5P16pXZhxyJxGToRr+0/gIMRTm8b7pk 4xCbaIa0lUIqUDs4NHsuoHEksxj0l6+n+Qxx5GyLA1mgOqrd7sCI/Uw+1juXVzax3Iu0 GpEA== X-Gm-Message-State: AOAM530gbPcwKXD8G4M++iL5y8Eck4ahiP1hSgFEomEtGBxBs3aCUHEB hbeDlA9fc4bxqaS/kvxVsOqdE5XA1Eh6PZVFsKAW/w== X-Google-Smtp-Source: ABdhPJyjn9rum65vYcBQ4GlWlVNRERiaxbOcNCdWQrbbJIdLNKVuD2FT8BIibqpbCXfpvXmyZQ2875mmldgmNDE5UUc= X-Received: by 2002:ac2:5f0b:: with SMTP id 11mr5618497lfq.201.1593303562798; Sat, 27 Jun 2020 17:19:22 -0700 (PDT) MIME-Version: 1.0 References: <20200617024412.GA11992@kduck.mit.edu> <9584c5cd-c68d-ddc3-0704-da672842e359@gmail.com> <9406.1592756905@localhost> <3A92516D-B980-4231-9059-EF7234BA8610@vigilsec.com> <20200627054056.GA35664@faui48f.informatik.uni-erlangen.de> <20200627224640.GA41058@faui48f.informatik.uni-erlangen.de> <20200628000922.GE41058@faui48f.informatik.uni-erlangen.de> In-Reply-To: <20200628000922.GE41058@faui48f.informatik.uni-erlangen.de> From: Eric Rescorla Date: Sat, 27 Jun 2020 17:18:46 -0700 Message-ID: To: Toerless Eckert Cc: Russ Housley , Michael Richardson , Ben Kaduk , Anima WG Content-Type: multipart/alternative; boundary="000000000000e1554c05a919e422" Archived-At: Subject: Re: [Anima] Russ: Re: rfc822Name use in Autonomic Control Plane document X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jun 2020 00:19:30 -0000 --000000000000e1554c05a919e422 Content-Type: text/plain; charset="UTF-8" On Sat, Jun 27, 2020 at 5:09 PM Toerless Eckert wrote: > > Thanks, Eric, inline > > On Sat, Jun 27, 2020 at 03:58:21PM -0700, Eric Rescorla wrote: > > I'm not Russ, but I don't take his point to be about ACME one way or the > > other. > > > > Rather, I take his point to be (as he just said in his response to Brian) > > that while this is *formatted* as an e-mail address, it does not in fact > > correspond to something to which e-mail can be delivered and therefore > does > > not match the semantics of RFC 5280. > > And i did repeatedly explain how this is not true. > Well, I understand you think you explained it, but unfortunately I don't find that argument persuasive, nor, I suspect, do others. The ACP operator can perfectly well set up mailxobxes if he desires to. > And if ACP required the operators to do so, I think that would also resolve this issue from an IETF perspective (although you still would likely not be able to get publicly verifiable certificates for this purpose, at least from any CA in the Mozilla root program, for the reasons I indicated previously). The whole question circles around the use of email addresses primairily > for purposes other than sending to mailboxes, and i gave other > examples where this is common industry practice and also uses > certificate rfc822Name. > I don't see how that makes this a practice which we should be endorsing. -Ekr > > Taking a step back from the substantive issue, it seems to me that to the > > extent to which their is debate about the meaning of 5280, this is a > > discussion which cannot be resolved entirely on this list, but instead > > needs to involve the LAMPS WG. > > Let me answer this to Ben. > > Cheers > Toerless > > > -Ekr > > > > > > > > > > On Sat, Jun 27, 2020 at 3:46 PM Toerless Eckert wrote: > > > > > On Sat, Jun 27, 2020 at 11:52:20AM -0400, Russ Housley wrote: > > > > Toerless: > > > > > > > > I think Brian actually made my point. While the filed contains an > email > > > address, using it as such would result in a delivery failure. The > private > > > key holder cannot be reached by this address. > > > > > > Russ, i said: > > > > > > > First of all, you can if you want to, > > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > > > > > Aka: Yes, if an ACP admin thinks ACME style challenge/reply > > > email authentication mechanism is useful, then he can of course > > > set up those email addresses accordingly. I did reply to that > > > point exhaustively in my reply about the ACME email mechanism. > > > > > > Why do you ignore that answer ? > > > > > > > and secondly, i contest that it is a requirement to be able > > > > to do that if the recipient doesn't need to support it. > > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > > > > > > Think about noreply@bad-corporation.com. > > > > You do want to make sure though that you are in control of > > > > the electronic mail address though, and that is given for ACP > > > > addresses. > > > > > > Where in rfc5280 or any other generic RFC about certificates does > > > it say you MUST have a mailbox that is reachable ? Where does it > > > say that all certificiates with rfc822Name must be email boxes > > > that support ACME email style challenge-reply about the email address ? > > > I think this is a non-existing requirement against email addresses. > > > > > > Of course, noreply@bad-corporation.com can have a certificate with > > > that rfc822Name. It just can't use the ACME mechanism to be > > > generated. But the signed mails sent from that address can be > > > authenticated. > > > > > > Or there are never emails, because the email address just serves > > > as identifier of an entity such as in wifi roaming identification > > > and authentication. In that case you are not authenticating > > > e.g.: password ownership for the email address via actual emails > > > but via AAA protocols against a DNS domain known AAA server > > > for the domain part of the email address. > > > > > > If you want to write a standards track RFC that all email addresses > > > used in any X.509v3 certificate MUST support an ACME style > > > challenge/reply email, then please do that, and seee if you get > > > thast through. If would invalidate a lot of solutions like > > > those wifi roaming ones. It WOULD NOT invalidate the ACP > > > solution, because as said (no several times) the ACP solution > > > can perfectly be set up to support this. It just does not > > > need to. > > > > > > Cheers > > > Toerless > > > > > > > Russ > > > > > > > > > > > > > On Jun 27, 2020, at 1:40 AM, Toerless Eckert > wrote: > > > > > > > > > > Russ, > > > > > > > > > > Top posting re. your ACP vs. ACME question. > > > > > > > > > > ACP rfc822name are meant to be under control of the ACP network > > > operations. > > > > > aka: the ACP registrars could be controlling rfcSELF*@example.com > > > mailboxes using > > > > > ACME S/MIME to get rfcSELF*@example.com certificates or IMHO > easier > > > control > > > > > the acp.example.com MTA. Just no need/benefit to do this now > IMHO: > > > > > > > > > > An ACP is a private network which is ideally isolated from other > > > > > ACP networks by use of private TA. Using the ACME rfc822name scheme > > > would > > > > > IMHO create a lot of attack components (all the MTA in the mail > path > > > > > and domain names) if used acros the Internet - without benefits for > > > > > ACP. Of course, if it was all a private ACME setup within an > > > enterprise, > > > > > and using mailboxes and ACME is a popular choice - sure, why not. > > > > > But for private CA setups there are existing IMO easier options > > > > > (private CA VMs using EST or the like). > > > > > > > > > > IMHO public ACME CAwith S/MIME authenitcation could make sense > > > > > in the future to enable authentication across different ACP > domains. > > > > > > > > > > Any network has links into other domains and today they are usually > > > > > unauthenticated, that could be solved IMHO fairly easily. > > > > > > > > > > "private" CA of ACP domain , lets call it acpCA signs all ACP > certs. > > > > > Its own cert is not self-signed, but signed by ACME CA via S/MIME, > > > > > maybe email is rfcSELF@example.com (no ACP IPv6 address in it) > > > > > > > > > > Now the ACP nodes actually use acpCA PLUS ACMA CA's as TA. > > > > > After IKEv2 authenticates neigbor the followup ACP domain > membership > > > > > step checks if the TA of the peer is acpCA. If yes, then peer > > > > > becomes ACP member, otherwise we have an authenticated signalling > > > > > channel to an interdomain / different CA peer. And that of course > > > > > would enable better/secure auto-configuration of such interdomain > > > > > links. > > > > > > > > > > This gives me good mix of security: Its still only relying on > > > > > well controlled private TA to get into ACP, but also doubles > > > > > at less secure but best available "Internet/Interdomain" > > > > > authentication. > > > > > > > > > > Cheers > > > > > Toerless > > > > > > > > > > On Sun, Jun 21, 2020 at 12:36:06PM -0400, Russ Housley wrote: > > > > >>> On Jun 21, 2020, at 12:28 PM, Michael Richardson < > > > mcr+ietf@sandelman.ca> wrote: > > > > >>> > > > > >>> > > > > >>> Russ Housley wrote: > > > > >>>> One cannot send email to the character string in this > > > specification, so > > > > >>>> it should not be carried in the rfc822name. > > > > >>> > > > > >>> You can send email to that character string if you configure the > MX. > > > > >>> It was designed specifically to accomodate that. > > > > >>> > > > > >>> I objected at the time: I thought it was a stupid feature, that > no > > > sensible IKEv2 daemon > > > > >>> was going to have to send/receive email. > > > > >>> > > > > >>> But, Toerless was paranoid that if we did anything at all out of > the > > > > >>> ordinary, that the corporate CA people, in order to protect their > > > fiefdom, > > > > >>> would freak out and throw some huge roadblock in the way of > > > deploying the ACP. > > > > >>> > > > > >>> And, now have an ACME method past WGLC that does certificate > > > validation by > > > > >>> SMTP. > > > > >> > > > > >> Looking at the email certificate enrollment work in the ACME WG > > > (draft-ietf-acme-email-smime-08), I have a hard time seeing how the > device > > > that knows the private key could participate in such a protocol. How > do > > > you see it working? > > > > >> > > > > >> Russ > > > > >> > > > > > > > > > > > > > > > > > > > >> _______________________________________________ > > > > >> Anima mailing list > > > > >> Anima@ietf.org > > > > >> https://www.ietf.org/mailman/listinfo/anima > > > > > > > > > > > > > > > -- > > > > > --- > > > > > tte@cs.fau.de > > > > > > -- > > > --- > > > tte@cs.fau.de > > > > > > _______________________________________________ > > > Anima mailing list > > > Anima@ietf.org > > > https://www.ietf.org/mailman/listinfo/anima > > > > > -- > --- > tte@cs.fau.de > --000000000000e1554c05a919e422 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sat, Jun 27, 2020 at 5:09 PM Toerl= ess Eckert <tte@cs.fa= u.de> wrote:

Thanks, Eric, inline

On Sat, Jun 27, 2020 at 03:58:21PM -0700, Eric Rescorla wrote:
> I'm not Russ, but I don't take his point to be about ACME one = way or the
> other.
>
> Rather, I take his point to be (as he just said in his response to Bri= an)
> that while this is *formatted* as an e-mail address, it does not in fa= ct
> correspond to something to which e-mail can be delivered and therefore= does
> not match the semantics of RFC 5280.

And i did repeatedly explain how this is not true.
Well, I understand you think you explained it, but unfortunate= ly I don't find that argument persuasive, nor, I suspect, do others.


The ACP operator can perfectly well set up mailxobxes if he desires to.
=

And if ACP required the operators to do so= , I think that would also resolve this issue from an IETF perspective (alth= ough you still would likely not be able to get publicly verifiable certific= ates for this purpose, at least from any CA in the Mozilla root program, fo= r the reasons I indicated previously).


The whole question circles around the use of email addresses primairily
for purposes other than sending to mailboxes, and i gave other
examples where this is common industry practice and also uses
certificate rfc822Name.

I don't see= how that makes this a practice which we should be endorsing.

-Ekr


> Taking a step back from the substantive issue, it seems to me that to = the
> extent to which their is debate about the meaning of 5280, this is a > discussion which cannot be resolved entirely on this list, but instead=
> needs to involve the LAMPS WG.

Let me answer this to Ben.

Cheers
=C2=A0 =C2=A0 Toerless

> -Ekr
>
>
>
>
> On Sat, Jun 27, 2020 at 3:46 PM Toerless Eckert <tte@cs.fau.de> wrote:
>
> > On Sat, Jun 27, 2020 at 11:52:20AM -0400, Russ Housley wrote:
> > > Toerless:
> > >
> > > I think Brian actually made my point.=C2=A0 While the filed = contains an email
> > address, using it as such would result in a delivery failure.=C2= =A0 The private
> > key holder cannot be reached by this address.
> >
> > Russ, i said:
> >
> > > First of all, you can if you want to,
> >=C2=A0 =C2=A0^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> >
> > Aka: Yes, if an ACP admin thinks ACME style challenge/reply
> > email authentication mechanism is useful, then he can of course > > set up those email addresses accordingly. I did reply to that
> > point exhaustively in my reply about the ACME email mechanism. > >
> >=C2=A0 Why do you ignore that answer ?
> >
> > > and secondly, i contest that it is a requirement to be able<= br> > > > to do that if the recipient doesn't need to support it.<= br> > >=C2=A0 =C2=A0^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^= ^^
> >
> > > Think about noreply@bad-corporation.com.
> > > You do want to make sure though that you are in control of > > > the electronic mail address though, and that is given for AC= P
> > > addresses.
> >
> > Where in rfc5280 or any other generic RFC about certificates does=
> > it say you MUST have a mailbox that is reachable ? Where does it<= br> > > say that all certificiates with rfc822Name must be email boxes > > that support ACME email style challenge-reply about the email add= ress ?
> > I think this is a non-existing requirement against email addresse= s.
> >
> > Of course, noreply@bad-corporation.com can have a certificate with
> > that rfc822Name. It just can't use the ACME mechanism to be > > generated. But the signed mails sent from that address can be
> > authenticated.
> >
> > Or there are never emails, because the email address just serves<= br> > > as identifier of an entity such as in wifi roaming identification=
> > and authentication. In that case you are not authenticating
> > e.g.: password ownership for the email address via actual emails<= br> > > but via AAA protocols against a DNS domain known AAA server
> > for the domain part of the email address.
> >
> > If you want to write a standards track RFC that all email address= es
> > used in any X.509v3 certificate MUST support an ACME style
> > challenge/reply email, then please do that, and seee if you get > > thast through. If would invalidate a lot of solutions like
> > those wifi roaming ones. It WOULD NOT invalidate the ACP
> > solution, because as said (no several times) the ACP solution
> > can perfectly be set up to support this. It just does not
> > need to.
> >
> > Cheers
> >=C2=A0 =C2=A0 =C2=A0Toerless
> >
> > > Russ
> > >
> > >
> > > > On Jun 27, 2020, at 1:40 AM, Toerless Eckert <tte@cs.fau.de> wrote: > > > >
> > > > Russ,
> > > >
> > > > Top posting re. your ACP vs. ACME question.
> > > >
> > > > ACP rfc822name are meant to be under control of the ACP= network
> > operations.
> > > > aka: the ACP registrars could be controlling rfcSELF*@<= a href=3D"http://example.com" rel=3D"noreferrer" target=3D"_blank">example.= com
> > mailboxes using
> > > > ACME S/MIME to get rfcSELF*@example.com certificates or IM= HO easier
> > control
> > > > the acp.example.com MTA.=C2=A0 Just no need/benefit to= do this now IMHO:
> > > >
> > > > An ACP is a private network which is ideally isolated f= rom other
> > > > ACP networks by use of private TA. Using the ACME rfc82= 2name scheme
> > would
> > > > IMHO create a lot of attack components (all the MTA in = the mail path
> > > > and domain names) if used acros the Internet - without = benefits for
> > > > ACP. Of course, if it was all a private ACME setup with= in an
> > enterprise,
> > > > and using mailboxes and ACME is a popular choice - sure= , why not.
> > > > But for private CA setups there are existing IMO easier= options
> > > > (private CA VMs using EST or the like).
> > > >
> > > > IMHO public ACME CAwith S/MIME authenitcation could=C2= =A0 make sense
> > > > in the future to enable authentication across different= ACP domains.
> > > >
> > > > Any network has links into other domains and today they= are usually
> > > > unauthenticated, that could be solved IMHO fairly easil= y.
> > > >
> > > > "private" CA of ACP domain , lets call it acp= CA signs all ACP certs.
> > > > Its own cert is not self-signed, but signed by ACME CA = via S/MIME,
> > > > maybe email is rfcSELF@example.com (no ACP IPv6 address in it)
> > > >
> > > > Now the ACP nodes actually use acpCA PLUS ACMA CA's= as TA.
> > > > After IKEv2 authenticates neigbor the followup ACP doma= in membership
> > > > step checks if the TA of the peer is acpCA. If yes, the= n peer
> > > > becomes ACP member, otherwise we have an authenticated = signalling
> > > > channel to an interdomain / different CA peer. And that= of course
> > > > would enable better/secure auto-configuration of such i= nterdomain
> > > > links.
> > > >
> > > > This gives me good mix of security: Its still only rely= ing on
> > > > well controlled private TA to get into ACP, but also do= ubles
> > > > at less secure but best available "Internet/Interd= omain"
> > > > authentication.
> > > >
> > > > Cheers
> > > >=C2=A0 =C2=A0 Toerless
> > > >
> > > > On Sun, Jun 21, 2020 at 12:36:06PM -0400, Russ Housley = wrote:
> > > >>> On Jun 21, 2020, at 12:28 PM, Michael Richardso= n <
> > mcr+= ietf@sandelman.ca> wrote:
> > > >>>
> > > >>>
> > > >>> Russ Housley <housley@vigilsec.com> wrote:
> > > >>>> One cannot send email to the character stri= ng in this
> > specification, so
> > > >>>> it should not be carried in the rfc822name.=
> > > >>>
> > > >>> You can send email to that character string if = you configure the MX.
> > > >>> It was designed specifically to accomodate that= .
> > > >>>
> > > >>> I objected at the time: I thought it was a stup= id feature, that no
> > sensible IKEv2 daemon
> > > >>> was going to have to send/receive email.
> > > >>>
> > > >>> But, Toerless was paranoid that if we did anyth= ing at all out of the
> > > >>> ordinary, that the corporate CA people, in orde= r to protect their
> > fiefdom,
> > > >>> would freak out and throw some huge roadblock i= n the way of
> > deploying the ACP.
> > > >>>
> > > >>> And, now have an ACME method past WGLC that doe= s certificate
> > validation by
> > > >>> SMTP.
> > > >>
> > > >> Looking at the email certificate enrollment work in= the ACME WG
> > (draft-ietf-acme-email-smime-08), I have a hard time seeing how t= he device
> > that knows the private key could participate in such a protocol.= =C2=A0 How do
> > you see it working?
> > > >>
> > > >> Russ
> > > >>
> > > >
> > > >
> > > >
> > > >> _______________________________________________
> > > >> Anima mailing list
> > > >> Anima@ietf.org
> > > >> https://www.ietf.org/mailman/list= info/anima
> > > >
> > > >
> > > > --
> > > > ---
> > > > tte@= cs.fau.de
> >
> > --
> > ---
> > tte@cs.fau.de<= /a>
> >
> > _______________________________________________
> > Anima mailing list
> > Anima@ietf.or= g
> > https://www.ietf.org/mailman/listinfo/anima=
> >

--
---
tte@cs.fau.de
--000000000000e1554c05a919e422-- From nobody Sat Jun 27 17:45:39 2020 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C6893A088C for ; Sat, 27 Jun 2020 17:45:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.65 X-Spam-Level: X-Spam-Status: No, score=-1.65 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 pZUBgXsLqDsn for ; Sat, 27 Jun 2020 17:45:36 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE3CF3A0063 for ; Sat, 27 Jun 2020 17:45:35 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [131.188.34.52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 0814754843F; Sun, 28 Jun 2020 02:45:30 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id EE65C440043; Sun, 28 Jun 2020 02:45:29 +0200 (CEST) Date: Sun, 28 Jun 2020 02:45:29 +0200 From: Toerless Eckert To: Benjamin Kaduk Cc: Eric Rescorla , Russ Housley , Michael Richardson , Anima WG , barryleiba@computer.org, evyncke@cisco.com, rwilton@cisco.com, ncamwing@cisco.com Message-ID: <20200628004529.GF41058@faui48f.informatik.uni-erlangen.de> References: <20200617024412.GA11992@kduck.mit.edu> <9584c5cd-c68d-ddc3-0704-da672842e359@gmail.com> <9406.1592756905@localhost> <3A92516D-B980-4231-9059-EF7234BA8610@vigilsec.com> <20200627054056.GA35664@faui48f.informatik.uni-erlangen.de> <20200627224640.GA41058@faui48f.informatik.uni-erlangen.de> <20200627231352.GM58278@kduck.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200627231352.GM58278@kduck.mit.edu> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [Anima] Russ: Re: rfc822Name use in Autonomic Control Plane document X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jun 2020 00:45:38 -0000 [Adding Barry and a few more folks] Ben, Russ: RFC5280 does not redefine anything about email addresses. It solely refer to RFC2821 definitions of them. Russ' last email on this thread explicitly reconfirmed that his concern is purely about use of email addresses in anima wrt. his reading of RFC2821. I think he is inventing new legislation what is and what is not a valid email address. >From that perspective i ask you to consult with Barry which the appropriate IETF WG is that has the expertise to provide input into how to interpret RFC2821, the RFCs that obsoleted it, or in general what does and what does not constitute a semantically correct email address. Maybe emailcore WG. I don't know. Barry ? There is ample explanation how what ACP uses as an email addrss is in our opinion perfectly valid syntactically and semantically, most of the argumens are in the numbered list in section 6.1.2 of the ACP draft. I have not seen any substantial technical argument invalidating what is written there. I have repeated written that ACP email addresses CAN HAVE an actual mailbox associated with them when desirable, but that like other common use-cases of email addresses such as wifi roaiming authentication, where also rfc822Name are used to certify ownership of such addresses, the main purpose of the use of these addresses is not that of sending or receiving email. I have pointed to examples like noreply@example.com which also is a typical example of a valid email address that arguably could be interpreted to have no mailbox associated with it. The ACP draft also well specifies how even in he absence of a configured physical mailbox, the email address itself is assigned such that it is under the control of the entity (ACP) it identifies. Such that no one else but his entity could own a mailbox for that email address. If LAMPS is interested to define additional constraints on email addresses required to make them legal to be put into PKIX rfc822Name attributes, i think thatss thats group perogative, but please: Such future additional constrain work can not be used to hold up progressing ACP now, especially not when it is just personal prefernces for encoding without any technical eplanation as to the harm the choice could provide. Aka: If there i anything reasonable to ask LAMPS now, then it is not to legislate what is a valid email address, but at most to come up with possible harm of putting particular email addresses into rfc822Name. Cheers Toerless On Sat, Jun 27, 2020 at 04:13:52PM -0700, Benjamin Kaduk wrote: > My apologies for commenting before having caught up on the whole thread > (I've been pretty sluggish all week and don't want to get even further > behind.) > > On Sat, Jun 27, 2020 at 03:58:21PM -0700, Eric Rescorla wrote: > > > > Taking a step back from the substantive issue, it seems to me that to the > > extent to which their is debate about the meaning of 5280, this is a > > discussion which cannot be resolved entirely on this list, but instead > > needs to involve the LAMPS WG. > > This has been a key point that I've (apparently) been failing to make very > well so far. E.g., while the ANIMA WG has presumably reached consensus on > the use of rfc822Name years ago, I think we also need consensus from LAMPS > before we can be confident that there is IETF consensus. > > Also, making even another step back, it seems that there is a key issue of > the CA model in play here, namely "know what you sign". If we are asking a > CA to sign an rfc822Name, which the CA treats as having email semantics, > but we assign different semantics to that name, then the CA is not actually > in knowledge of what it's signing. Accordingly, the CA incurs significant > (e.g., legal and financial) risk by making those signatures, and defining > the field in this way gives the impression that we are trying to make an > end-run around CA policies. > > -Ben -- --- tte@cs.fau.de From nobody Sat Jun 27 17:54:43 2020 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EFC93A08AD for ; Sat, 27 Jun 2020 17:54:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.87 X-Spam-Level: X-Spam-Status: No, score=-0.87 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=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 ysU-MNPcaWqg for ; Sat, 27 Jun 2020 17:54:39 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21DD43A08AC for ; Sat, 27 Jun 2020 17:54:38 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [131.188.34.52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id AEAC154843F; Sun, 28 Jun 2020 02:54:33 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id A647B440043; Sun, 28 Jun 2020 02:54:33 +0200 (CEST) Date: Sun, 28 Jun 2020 02:54:33 +0200 From: Toerless Eckert To: Eric Rescorla Cc: Russ Housley , Michael Richardson , Ben Kaduk , Anima WG Message-ID: <20200628005433.GG41058@faui48f.informatik.uni-erlangen.de> References: <9584c5cd-c68d-ddc3-0704-da672842e359@gmail.com> <9406.1592756905@localhost> <3A92516D-B980-4231-9059-EF7234BA8610@vigilsec.com> <20200627054056.GA35664@faui48f.informatik.uni-erlangen.de> <20200627224640.GA41058@faui48f.informatik.uni-erlangen.de> <20200628000922.GE41058@faui48f.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [Anima] Russ: Re: rfc822Name use in Autonomic Control Plane document X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jun 2020 00:54:42 -0000 On Sat, Jun 27, 2020 at 05:18:46PM -0700, Eric Rescorla wrote: > Well, I understand you think you explained it, but unfortunately I don't > find that argument persuasive, nor, I suspect, do others. > > The ACP operator can perfectly well set up mailxobxes if he desires to. > > > > And if ACP required the operators to do so, I think that would also resolve > this issue from an IETF perspective (although you still would likely not be > able to get publicly verifiable certificates for this purpose, at least > from any CA in the Mozilla root program, for the reasons I indicated > previously). FInd the email in the thread where i eplained to Russ how a public CA is useless if not dangerous for what the ACP does right now, but it could be quite useful in future extensons, such as for interdomain auhentication via ACMPE S/MIME. Please understand the use case first before thinking that apply Internet public PKI requirements is always the right think to do. This version of ACP is solely for private networks and effectively for private PKI. We went through all that review together, and you and Ben approved of that text. > The whole question circles around the use of email addresses primairily > > for purposes other than sending to mailboxes, and i gave other > > examples where this is common industry practice and also uses > > certificate rfc822Name. > > I don't see how that makes this a practice which we should be endorsing. Again, give me any technical reasoning. show me any possible harm. All i am seeing now is a choice of preference from people who where not active in the working group, and they had 5 years time. And i think anyhthing short of showing possible harm should really be the WG decision. Especially when i continuously bring technical arguments that nobody seems to bother to read, at least hey are never acknowledged. Such as the reasons for differet choice of preference between e.g.: other uses of email addresses picking a new otherName vs. our solution preference not to do tht. And even more the harm that another choice would create for the ease of adoption of the solution. We have several points how unnecessary churn in encoding creates much more of harm and pain in a highly fragmented, ossified environemnt such as that of wide area/enterprise routers & switches than in your backyard of highly agile, often vertically integrted cloud/web software. Please do not ignore the the requirements of the ecosystem when expressing preferences. Cheers Toerless > > -Ekr > > > > > Taking a step back from the substantive issue, it seems to me that to the > > > extent to which their is debate about the meaning of 5280, this is a > > > discussion which cannot be resolved entirely on this list, but instead > > > needs to involve the LAMPS WG. > > > > Let me answer this to Ben. > > > > Cheers > > Toerless > > > > > -Ekr > > > > > > > > > > > > > > > On Sat, Jun 27, 2020 at 3:46 PM Toerless Eckert wrote: > > > > > > > On Sat, Jun 27, 2020 at 11:52:20AM -0400, Russ Housley wrote: > > > > > Toerless: > > > > > > > > > > I think Brian actually made my point. While the filed contains an > > email > > > > address, using it as such would result in a delivery failure. The > > private > > > > key holder cannot be reached by this address. > > > > > > > > Russ, i said: > > > > > > > > > First of all, you can if you want to, > > > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > > > > > > > Aka: Yes, if an ACP admin thinks ACME style challenge/reply > > > > email authentication mechanism is useful, then he can of course > > > > set up those email addresses accordingly. I did reply to that > > > > point exhaustively in my reply about the ACME email mechanism. > > > > > > > > Why do you ignore that answer ? > > > > > > > > > and secondly, i contest that it is a requirement to be able > > > > > to do that if the recipient doesn't need to support it. > > > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > > > > > > > > Think about noreply@bad-corporation.com. > > > > > You do want to make sure though that you are in control of > > > > > the electronic mail address though, and that is given for ACP > > > > > addresses. > > > > > > > > Where in rfc5280 or any other generic RFC about certificates does > > > > it say you MUST have a mailbox that is reachable ? Where does it > > > > say that all certificiates with rfc822Name must be email boxes > > > > that support ACME email style challenge-reply about the email address ? > > > > I think this is a non-existing requirement against email addresses. > > > > > > > > Of course, noreply@bad-corporation.com can have a certificate with > > > > that rfc822Name. It just can't use the ACME mechanism to be > > > > generated. But the signed mails sent from that address can be > > > > authenticated. > > > > > > > > Or there are never emails, because the email address just serves > > > > as identifier of an entity such as in wifi roaming identification > > > > and authentication. In that case you are not authenticating > > > > e.g.: password ownership for the email address via actual emails > > > > but via AAA protocols against a DNS domain known AAA server > > > > for the domain part of the email address. > > > > > > > > If you want to write a standards track RFC that all email addresses > > > > used in any X.509v3 certificate MUST support an ACME style > > > > challenge/reply email, then please do that, and seee if you get > > > > thast through. If would invalidate a lot of solutions like > > > > those wifi roaming ones. It WOULD NOT invalidate the ACP > > > > solution, because as said (no several times) the ACP solution > > > > can perfectly be set up to support this. It just does not > > > > need to. > > > > > > > > Cheers > > > > Toerless > > > > > > > > > Russ > > > > > > > > > > > > > > > > On Jun 27, 2020, at 1:40 AM, Toerless Eckert > > wrote: > > > > > > > > > > > > Russ, > > > > > > > > > > > > Top posting re. your ACP vs. ACME question. > > > > > > > > > > > > ACP rfc822name are meant to be under control of the ACP network > > > > operations. > > > > > > aka: the ACP registrars could be controlling rfcSELF*@example.com > > > > mailboxes using > > > > > > ACME S/MIME to get rfcSELF*@example.com certificates or IMHO > > easier > > > > control > > > > > > the acp.example.com MTA. Just no need/benefit to do this now > > IMHO: > > > > > > > > > > > > An ACP is a private network which is ideally isolated from other > > > > > > ACP networks by use of private TA. Using the ACME rfc822name scheme > > > > would > > > > > > IMHO create a lot of attack components (all the MTA in the mail > > path > > > > > > and domain names) if used acros the Internet - without benefits for > > > > > > ACP. Of course, if it was all a private ACME setup within an > > > > enterprise, > > > > > > and using mailboxes and ACME is a popular choice - sure, why not. > > > > > > But for private CA setups there are existing IMO easier options > > > > > > (private CA VMs using EST or the like). > > > > > > > > > > > > IMHO public ACME CAwith S/MIME authenitcation could make sense > > > > > > in the future to enable authentication across different ACP > > domains. > > > > > > > > > > > > Any network has links into other domains and today they are usually > > > > > > unauthenticated, that could be solved IMHO fairly easily. > > > > > > > > > > > > "private" CA of ACP domain , lets call it acpCA signs all ACP > > certs. > > > > > > Its own cert is not self-signed, but signed by ACME CA via S/MIME, > > > > > > maybe email is rfcSELF@example.com (no ACP IPv6 address in it) > > > > > > > > > > > > Now the ACP nodes actually use acpCA PLUS ACMA CA's as TA. > > > > > > After IKEv2 authenticates neigbor the followup ACP domain > > membership > > > > > > step checks if the TA of the peer is acpCA. If yes, then peer > > > > > > becomes ACP member, otherwise we have an authenticated signalling > > > > > > channel to an interdomain / different CA peer. And that of course > > > > > > would enable better/secure auto-configuration of such interdomain > > > > > > links. > > > > > > > > > > > > This gives me good mix of security: Its still only relying on > > > > > > well controlled private TA to get into ACP, but also doubles > > > > > > at less secure but best available "Internet/Interdomain" > > > > > > authentication. > > > > > > > > > > > > Cheers > > > > > > Toerless > > > > > > > > > > > > On Sun, Jun 21, 2020 at 12:36:06PM -0400, Russ Housley wrote: > > > > > >>> On Jun 21, 2020, at 12:28 PM, Michael Richardson < > > > > mcr+ietf@sandelman.ca> wrote: > > > > > >>> > > > > > >>> > > > > > >>> Russ Housley wrote: > > > > > >>>> One cannot send email to the character string in this > > > > specification, so > > > > > >>>> it should not be carried in the rfc822name. > > > > > >>> > > > > > >>> You can send email to that character string if you configure the > > MX. > > > > > >>> It was designed specifically to accomodate that. > > > > > >>> > > > > > >>> I objected at the time: I thought it was a stupid feature, that > > no > > > > sensible IKEv2 daemon > > > > > >>> was going to have to send/receive email. > > > > > >>> > > > > > >>> But, Toerless was paranoid that if we did anything at all out of > > the > > > > > >>> ordinary, that the corporate CA people, in order to protect their > > > > fiefdom, > > > > > >>> would freak out and throw some huge roadblock in the way of > > > > deploying the ACP. > > > > > >>> > > > > > >>> And, now have an ACME method past WGLC that does certificate > > > > validation by > > > > > >>> SMTP. > > > > > >> > > > > > >> Looking at the email certificate enrollment work in the ACME WG > > > > (draft-ietf-acme-email-smime-08), I have a hard time seeing how the > > device > > > > that knows the private key could participate in such a protocol. How > > do > > > > you see it working? > > > > > >> > > > > > >> Russ > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > >> _______________________________________________ > > > > > >> Anima mailing list > > > > > >> Anima@ietf.org > > > > > >> https://www.ietf.org/mailman/listinfo/anima > > > > > > > > > > > > > > > > > > -- > > > > > > --- > > > > > > tte@cs.fau.de > > > > > > > > -- > > > > --- > > > > tte@cs.fau.de > > > > > > > > _______________________________________________ > > > > Anima mailing list > > > > Anima@ietf.org > > > > https://www.ietf.org/mailman/listinfo/anima > > > > > > > > -- > > --- > > tte@cs.fau.de > > -- --- tte@cs.fau.de From nobody Sat Jun 27 17:58:27 2020 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DCAB3A08B3 for ; Sat, 27 Jun 2020 17:58:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, 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 (2048-bit key) header.d=rtfm-com.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 oyFsfz0yFqJ3 for ; Sat, 27 Jun 2020 17:58:23 -0700 (PDT) Received: from mail-lj1-x22f.google.com (mail-lj1-x22f.google.com [IPv6:2a00:1450:4864:20::22f]) (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 8AA603A08AF for ; Sat, 27 Jun 2020 17:58:23 -0700 (PDT) Received: by mail-lj1-x22f.google.com with SMTP id h22so6958539lji.9 for ; Sat, 27 Jun 2020 17:58:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=MY7ssJNp1QNDalgZNCOjInHwhkjkNTrC6fu+GIPWzJg=; b=EVoBdKVxEfEovgucbtxUy5HmeBegtb0VjBF87m3TLSAqdgb2q/a8ILpTwh58LsR17w Wjtz2H+clnakaqzy3O1e+Qrl5cvj2LM2FGv9pxp+cLIQAdsDjcs0U1sZlaynIAgbuwwM 4JhEv9NLJrmHRU9fawnfAH2h7j2FE0hn8AhaB5qa0lFPLVE2TpXC3KGrA0cvwzWIKBBv nK0T7tMA/7MYjs76IY8Ocv0IfT+GsMpYDfiwAiiM5aVitvKTLIBGItlcdbV4T4GFagwq VNfCRh36s/xS0NRVmB1bS0uuENp8/4mnbz5JbvGGviLzOOfQZVg96j5WDtMMDWtnJYa5 o9yA== 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=MY7ssJNp1QNDalgZNCOjInHwhkjkNTrC6fu+GIPWzJg=; b=XWad1KPht8omG6A5nGCTjW9SNKGOA6ZRYyc51q1HQwfY4ak5Lxoe7IcI2yq1dBxJ6Z E1CEIbTTz+DT4jqz/R+FG6Wh+QFddZrjvxF7oH8bozZ4dXETa54GDbD/FDFTx8JSkief KiSkWcDINvO6vuX81K5t6qeuDAMeJTdKvy7WspljyWvTY8WuRm3nACfb38XThOfrZpcY LNOiJ8WZwluo3j4/gdvrB2Zr5dNnyv4BPUH+WW1pJQt1Pue4tQNBz4DvhUxZLeYN/fxE rHtyzQhW2jYcB1f8YW1Zb1grsqunQHYJjnFcSY+j+FOvo3NXVPoO2qIz9G9+RiIeZM7I rZDQ== X-Gm-Message-State: AOAM532BaSZouoWUlWK7DttCz3EX10krV6qhaMV5FsFiWxjE1V9ZTqlN wbZb3KB2LWzTMBlLZ2OKBP80WZNK3DNlczAugLRKvA== X-Google-Smtp-Source: ABdhPJya2uTfEgwr19npmAw9FPT7xFTxCoW7xnRmJYjaAIP7UoL87thQHqVxnb+V9Caivb4V1QhzrBPf1EnrEhvSc2c= X-Received: by 2002:a2e:2a42:: with SMTP id q63mr5162533ljq.265.1593305901718; Sat, 27 Jun 2020 17:58:21 -0700 (PDT) MIME-Version: 1.0 References: <9584c5cd-c68d-ddc3-0704-da672842e359@gmail.com> <9406.1592756905@localhost> <3A92516D-B980-4231-9059-EF7234BA8610@vigilsec.com> <20200627054056.GA35664@faui48f.informatik.uni-erlangen.de> <20200627224640.GA41058@faui48f.informatik.uni-erlangen.de> <20200628000922.GE41058@faui48f.informatik.uni-erlangen.de> <20200628005433.GG41058@faui48f.informatik.uni-erlangen.de> In-Reply-To: <20200628005433.GG41058@faui48f.informatik.uni-erlangen.de> From: Eric Rescorla Date: Sat, 27 Jun 2020 17:57:45 -0700 Message-ID: To: Toerless Eckert Cc: Russ Housley , Michael Richardson , Ben Kaduk , Anima WG Content-Type: multipart/alternative; boundary="0000000000004a704105a91a70a3" Archived-At: Subject: Re: [Anima] Russ: Re: rfc822Name use in Autonomic Control Plane document X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jun 2020 00:58:25 -0000 --0000000000004a704105a91a70a3 Content-Type: text/plain; charset="UTF-8" On Sat, Jun 27, 2020 at 5:54 PM Toerless Eckert wrote: > On Sat, Jun 27, 2020 at 05:18:46PM -0700, Eric Rescorla wrote: > > Well, I understand you think you explained it, but unfortunately I don't > > find that argument persuasive, nor, I suspect, do others. > > > > The ACP operator can perfectly well set up mailxobxes if he desires to. > > > > > > > And if ACP required the operators to do so, I think that would also > resolve > > this issue from an IETF perspective (although you still would likely not > be > > able to get publicly verifiable certificates for this purpose, at least > > from any CA in the Mozilla root program, for the reasons I indicated > > previously). > > FInd the email in the thread where i eplained to Russ how a public CA > is useless if not dangerous for what the ACP does right now, but it > could be quite useful in future extensons, such as for interdomain > auhentication via ACMPE S/MIME. > > Please understand the use case first before thinking that apply > Internet public PKI requirements is always the right think to do. > I didn't say any such thing. I merely observed that it would not be compatible with the requirements those CAs operate under. That's why I put it in parentheses. -Ekr --0000000000004a704105a91a70a3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sat, Jun 27, 2020 at 5:54 PM Toerl= ess Eckert <tte@cs.fa= u.de> wrote:
On Sat, Jun 27, 2020 at 05:18:46PM -0700, Eric Rescorla wrote:
> Well, I understand you think you explained it, but unfortunately I don= 't
> find that argument persuasive, nor, I suspect, do others.
>
> The ACP operator can perfectly well set up mailxobxes if he desires to= .
> >
>
> And if ACP required the operators to do so, I think that would also re= solve
> this issue from an IETF perspective (although you still would likely n= ot be
> able to get publicly verifiable certificates for this purpose, at leas= t
> from any CA in the Mozilla root program, for the reasons I indicated > previously).

FInd the email in the thread where i eplained to Russ how a public CA
is useless if not dangerous for what the ACP does right now, but it
could be quite useful in future extensons, such as for interdomain
auhentication via ACMPE S/MIME.

Please understand the use case first before thinking that apply
Internet public PKI requirements is always the right think to do.

I didn't say any such thing. I merely observ= ed that it would not be compatible
with the requirements those CA= s operate under. That's why I put it in
parentheses.

-Ekr



--0000000000004a704105a91a70a3-- From nobody Sat Jun 27 18:11:23 2020 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9213E3A08D8 for ; Sat, 27 Jun 2020 18:11:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.87 X-Spam-Level: X-Spam-Status: No, score=-0.87 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=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 Ngr3uG5U8KCE for ; Sat, 27 Jun 2020 18:11:19 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3364E3A08D7 for ; Sat, 27 Jun 2020 18:11:19 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [131.188.34.52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 8B8EA548068; Sun, 28 Jun 2020 03:11:14 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 7E70F440043; Sun, 28 Jun 2020 03:11:14 +0200 (CEST) Date: Sun, 28 Jun 2020 03:11:14 +0200 From: Toerless Eckert To: Eric Rescorla Cc: Russ Housley , Michael Richardson , Ben Kaduk , Anima WG Message-ID: <20200628011114.GH41058@faui48f.informatik.uni-erlangen.de> References: <9406.1592756905@localhost> <3A92516D-B980-4231-9059-EF7234BA8610@vigilsec.com> <20200627054056.GA35664@faui48f.informatik.uni-erlangen.de> <20200627224640.GA41058@faui48f.informatik.uni-erlangen.de> <20200628000922.GE41058@faui48f.informatik.uni-erlangen.de> <20200628005433.GG41058@faui48f.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [Anima] Russ: Re: rfc822Name use in Autonomic Control Plane document X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jun 2020 01:11:22 -0000 On Sat, Jun 27, 2020 at 05:57:45PM -0700, Eric Rescorla wrote: > On Sat, Jun 27, 2020 at 5:54 PM Toerless Eckert wrote: > > > On Sat, Jun 27, 2020 at 05:18:46PM -0700, Eric Rescorla wrote: > > > Well, I understand you think you explained it, but unfortunately I don't > > > find that argument persuasive, nor, I suspect, do others. > > > > > > The ACP operator can perfectly well set up mailxobxes if he desires to. > > > > > > > > > > And if ACP required the operators to do so, I think that would also > > resolve > > > this issue from an IETF perspective (although you still would likely not > > be > > > able to get publicly verifiable certificates for this purpose, at least > > > from any CA in the Mozilla root program, for the reasons I indicated > > > previously). > > > > FInd the email in the thread where i eplained to Russ how a public CA > > is useless if not dangerous for what the ACP does right now, but it > > could be quite useful in future extensons, such as for interdomain > > auhentication via ACMPE S/MIME. > > > > Please understand the use case first before thinking that apply > > Internet public PKI requirements is always the right think to do. > > > > I didn't say any such thing. I merely observed that it would not be > compatible with the requirements those CAs operate under. That's why I put it in > parentheses. Thanks. Cheers Toerless > -Ekr -- --- tte@cs.fau.de From nobody Sat Jun 27 20:10:01 2020 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9A5A3A0964 for ; Sat, 27 Jun 2020 20:09:59 -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, FREEMAIL_FROM=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 9RHYJ2Cvk-VU for ; Sat, 27 Jun 2020 20:09:58 -0700 (PDT) Received: from mail-pl1-x62c.google.com (mail-pl1-x62c.google.com [IPv6:2607:f8b0:4864:20::62c]) (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 E7A693A08AA for ; Sat, 27 Jun 2020 20:09:57 -0700 (PDT) Received: by mail-pl1-x62c.google.com with SMTP id s14so5752914plq.6 for ; Sat, 27 Jun 2020 20:09:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=eC2OXuB4UhcLrUb+p4ebfqzpeY08pdirhsHE9bz/+X0=; b=G6vohxmYAv5i9WcabTf59Y9/Fe54njL5nVNRMKOc+Qm+qOIefKHwRJK6tA5LqLcw/5 xlL3ifTA0TqkpJcIYdNrFJ5ShrDIHVhH1dJopXBeIorCM1ZeDDpSgC8LA4b7qNb6tkzL BvTgZfo7zNaXDdHQJKH0gFa1uEjRH8rL3aLKoemeqc5xJM6HWkolbzS2C1MKVvnb/WsG 4Kuq2Mz+YF4BM7V22HrqeGZK9m4+d/R56gXvGYeGNMq4Jw2/rwMlKcpKh4Obj7XQQkyf 1zqOFVM731wKWw9VzcgwQUBWcXzxaps9sElkHxmWtiPr1WK8XnWYawyGq4KaF0bf7/p5 BJew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=eC2OXuB4UhcLrUb+p4ebfqzpeY08pdirhsHE9bz/+X0=; b=XSKjpwqPGiSqySG5X30rnqyHdxHuZpaBOSq/yboQ1zyZ18Fkp5wrN6E66nqL0p51Rz PLnj2KGcfvtGUatleKjg/pH4RW7YvUyBCnm6l4JN54g00x220t5XWJ443bU8bgn7vRq3 43o0uLTHb2UmYLfjFzArX9C+6Fzroy0piegLDnxDLg8R2LA3YCMY+7BkOxpx4LClHR8W vtxbBm4bcFTSb8vKhhsNJ/1fyz0L+J1Fjm+q3UwikXcSrDb/h/p5+icQEkOInIRZO4MC nmklioP4/7K5Cmc6a8qRcpNg8g1t03GSMIhds8TF3TB74c/xC5qiZXFJjV5rgRKP8xUv UzEQ== X-Gm-Message-State: AOAM533lsCNd3yTfKl304/hMxAZrOuwflEnWoNzzGZJsYoN2XTnX3g91 PtF0dWfbIyl/1tp+H0W02LEfy9uWgmE= X-Google-Smtp-Source: ABdhPJyFkGoWlQAIwMwO+NeOx2hA7ZWbrLtRpZTApma2beihQMXxRpQqCGZV4dMGGxA+n4Zub2NeIg== X-Received: by 2002:a17:90a:e00a:: with SMTP id u10mr10967908pjy.17.1593313796955; Sat, 27 Jun 2020 20:09:56 -0700 (PDT) Received: from [192.168.178.20] (203.90.69.111.dynamic.snap.net.nz. [111.69.90.203]) by smtp.gmail.com with ESMTPSA id k19sm30858829pfg.153.2020.06.27.20.09.53 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 27 Jun 2020 20:09:56 -0700 (PDT) To: Eric Rescorla , Toerless Eckert Cc: Michael Richardson , Russ Housley , Ben Kaduk , Anima WG References: <11428.1592266833@localhost> <20200617024412.GA11992@kduck.mit.edu> <9584c5cd-c68d-ddc3-0704-da672842e359@gmail.com> <9406.1592756905@localhost> <3A92516D-B980-4231-9059-EF7234BA8610@vigilsec.com> <20200627054056.GA35664@faui48f.informatik.uni-erlangen.de> <20200627224640.GA41058@faui48f.informatik.uni-erlangen.de> From: Brian E Carpenter Message-ID: Date: Sun, 28 Jun 2020 15:09:52 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Anima] Russ: Re: rfc822Name use in Autonomic Control Plane document X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jun 2020 03:10:00 -0000 Hi Eric, On 28-Jun-20 10:58, Eric Rescorla wrote: > I'm not Russ, but I don't take his point to be about ACME one way or th= e other. >=20 > Rather, I take his point to be (as he just said in his response to Bria= n) that while this is *formatted* as an e-mail address, it does not in fa= ct correspond to something to which e-mail can be delivered=20 It might do, simply because it is so formatted. > and therefore does not match the semantics of RFC 5280. RFC5280 does not require such a mailbox to exist. Is there another normat= ive document, e.g. a BCP, that does require one? It's entirely possible t= hat the authors of RFC5280 assumed that such a mailbox would exist, but t= his is not written anywhere that I can see. So IMNSHO, this objection to = the ACP draft is attempting to hold it to a standard that isn't documente= d. =20 > Taking a step back from the substantive issue, it seems to me that to t= he extent to which their is debate about the meaning of 5280, this is a d= iscussion which cannot be resolved entirely on this list, but instead nee= ds to involve the LAMPS WG. That may be true, but it's not ANIMA's fault and the discussion first aro= se last year, so why hasn't LAMPS already considered it, if it's importan= t enough to continue obstructing ANIMA's progress? Brian >=20 > -Ekr >=20 >=20 >=20 >=20 > On Sat, Jun 27, 2020 at 3:46 PM Toerless Eckert > wrote: >=20 > On Sat, Jun 27, 2020 at 11:52:20AM -0400, Russ Housley wrote: > > Toerless: > > > > I think Brian actually made my point.=C2=A0 While the filed conta= ins an email address, using it as such would result in a delivery failure= =2E=C2=A0 The private key holder cannot be reached by this address. >=20 > Russ, i said: >=20 > > First of all, you can if you want to, > =C2=A0 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >=20 > Aka: Yes, if an ACP admin thinks ACME style challenge/reply > email authentication mechanism is useful, then he can of course > set up those email addresses accordingly. I did reply to that > point exhaustively in my reply about the ACME email mechanism. >=20 > =C2=A0Why do you ignore that answer ? >=20 > > and secondly, i contest that it is a requirement to be able > > to do that if the recipient doesn't need to support it. > =C2=A0 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >=20 > > Think about noreply@bad-corporation.com . > > You do want to make sure though that you are in control of > > the electronic mail address though, and that is given for ACP > > addresses. >=20 > Where in rfc5280 or any other generic RFC about certificates does > it say you MUST have a mailbox that is reachable ? Where does it > say that all certificiates with rfc822Name must be email boxes > that support ACME email style challenge-reply about the email addre= ss ? > I think this is a non-existing requirement against email addresses.= >=20 > Of course, noreply@bad-corporation.com can have a certificate with > that rfc822Name. It just can't use the ACME mechanism to be > generated. But the signed mails sent from that address can be > authenticated. >=20 > Or there are never emails, because the email address just serves > as identifier of an entity such as in wifi roaming identification > and authentication. In that case you are not authenticating > e.g.: password ownership for the email address via actual emails > but via AAA protocols against a DNS domain known AAA server > for the domain part of the email address. >=20 > If you want to write a standards track RFC that all email addresses= > used in any X.509v3 certificate MUST support an ACME style > challenge/reply email, then please do that, and seee if you get > thast through. If would invalidate a lot of solutions like > those wifi roaming ones. It WOULD NOT invalidate the ACP > solution, because as said (no several times) the ACP solution > can perfectly be set up to support this. It just does not > need to. >=20 > Cheers > =C2=A0 =C2=A0 Toerless >=20 > > Russ > > > > > > > On Jun 27, 2020, at 1:40 AM, Toerless Eckert > wrote: > > > > > > Russ, > > > > > > Top posting re. your ACP vs. ACME question. > > > > > > ACP rfc822name are meant to be under control of the ACP network= operations. > > > aka: the ACP registrars could be controlling rfcSELF*@example.c= om mailboxes using > > > ACME S/MIME to get rfcSELF*@example.com ce= rtificates or IMHO easier control > > > the acp.example.com MTA.=C2=A0 Just no= need/benefit to do this now IMHO: > > > > > > An ACP is a private network which is ideally isolated from othe= r > > > ACP networks by use of private TA. Using the ACME rfc822name sc= heme would > > > IMHO create a lot of attack components (all the MTA in the mail= path > > > and domain names) if used acros the Internet - without benefits= for > > > ACP. Of course, if it was all a private ACME setup within an en= terprise, > > > and using mailboxes and ACME is a popular choice - sure, why no= t. > > > But for private CA setups there are existing IMO easier options= > > > (private CA VMs using EST or the like). > > > > > > IMHO public ACME CAwith S/MIME authenitcation could=C2=A0 make = sense > > > in the future to enable authentication across different ACP dom= ains. > > > > > > Any network has links into other domains and today they are usu= ally > > > unauthenticated, that could be solved IMHO fairly easily. > > > > > > "private" CA of ACP domain , lets call it acpCA signs all ACP c= erts. > > > Its own cert is not self-signed, but signed by ACME CA via S/MI= ME, > > > maybe email is rfcSELF@example.com = (no ACP IPv6 address in it) > > > > > > Now the ACP nodes actually use acpCA PLUS ACMA CA's as TA. > > > After IKEv2 authenticates neigbor the followup ACP domain membe= rship > > > step checks if the TA of the peer is acpCA. If yes, then peer > > > becomes ACP member, otherwise we have an authenticated signalli= ng > > > channel to an interdomain / different CA peer. And that of cour= se > > > would enable better/secure auto-configuration of such interdoma= in > > > links. > > > > > > This gives me good mix of security: Its still only relying on > > > well controlled private TA to get into ACP, but also doubles > > > at less secure but best available "Internet/Interdomain" > > > authentication. > > > > > > Cheers > > >=C2=A0 =C2=A0 Toerless > > > > > > On Sun, Jun 21, 2020 at 12:36:06PM -0400, Russ Housley wrote: > > >>> On Jun 21, 2020, at 12:28 PM, Michael Richardson > wrote: > > >>> > > >>> > > >>> Russ Housley > wrote: > > >>>> One cannot send email to the character string in this specif= ication, so > > >>>> it should not be carried in the rfc822name. > > >>> > > >>> You can send email to that character string if you configure = the MX. > > >>> It was designed specifically to accomodate that. > > >>> > > >>> I objected at the time: I thought it was a stupid feature, th= at no sensible IKEv2 daemon > > >>> was going to have to send/receive email. > > >>> > > >>> But, Toerless was paranoid that if we did anything at all out= of the > > >>> ordinary, that the corporate CA people, in order to protect t= heir fiefdom, > > >>> would freak out and throw some huge roadblock in the way of d= eploying the ACP. > > >>> > > >>> And, now have an ACME method past WGLC that does certificate = validation by > > >>> SMTP. > > >> > > >> Looking at the email certificate enrollment work in the ACME W= G (draft-ietf-acme-email-smime-08), I have a hard time seeing how the dev= ice that knows the private key could participate in such a protocol.=C2=A0= How do you see it working? > > >> > > >> Russ > > >> > > > > > > > > > > > >> _______________________________________________ > > >> Anima mailing list > > >> Anima@ietf.org > > >> https://www.ietf.org/mailman/listinfo/anima > > > > > > > > > -- > > > --- > > > tte@cs.fau.de >=20 > --=20 > --- > tte@cs.fau.de >=20 > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima >=20 >=20 > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima >=20 From nobody Sun Jun 28 07:32:45 2020 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43B3B3A0D17 for ; Sun, 28 Jun 2020 07:32:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=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 Xo4MbDRLVdY2 for ; Sun, 28 Jun 2020 07:32:41 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC9093A0D16 for ; Sun, 28 Jun 2020 07:32:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 127EB300AAF for ; Sun, 28 Jun 2020 10:32:39 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id NtDmmyyL6kra for ; Sun, 28 Jun 2020 10:32:36 -0400 (EDT) Received: from a860b60074bd.fios-router.home (pool-72-66-113-56.washdc.fios.verizon.net [72.66.113.56]) by mail.smeinc.net (Postfix) with ESMTPSA id 8883D300A55; Sun, 28 Jun 2020 10:32:36 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.14\)) From: Russ Housley In-Reply-To: <20200627224640.GA41058@faui48f.informatik.uni-erlangen.de> Date: Sun, 28 Jun 2020 10:32:37 -0400 Cc: Michael Richardson , anima@ietf.org, Ben Kaduk Content-Transfer-Encoding: quoted-printable Message-Id: <3B3487F7-E2A7-4B95-8F8D-CC9EBB23F32C@vigilsec.com> References: <11428.1592266833@localhost> <20200617024412.GA11992@kduck.mit.edu> <9584c5cd-c68d-ddc3-0704-da672842e359@gmail.com> <9406.1592756905@localhost> <3A92516D-B980-4231-9059-EF7234BA8610@vigilsec.com> <20200627054056.GA35664@faui48f.informatik.uni-erlangen.de> <20200627224640.GA41058@faui48f.informatik.uni-erlangen.de> To: Toerless Eckert X-Mailer: Apple Mail (2.3445.104.14) Archived-At: Subject: Re: [Anima] Russ: Re: rfc822Name use in Autonomic Control Plane document X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jun 2020 14:32:43 -0000 > On Jun 27, 2020, at 6:46 PM, Toerless Eckert wrote: >=20 > On Sat, Jun 27, 2020 at 11:52:20AM -0400, Russ Housley wrote: >> Toerless: >>=20 >> I think Brian actually made my point. While the filed contains an = email address, using it as such would result in a delivery failure. The = private key holder cannot be reached by this address. >=20 > Russ, i said: >=20 >> First of all, you can if you want to, > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >=20 > Aka: Yes, if an ACP admin thinks ACME style challenge/reply > email authentication mechanism is useful, then he can of course > set up those email addresses accordingly. I did reply to that > point exhaustively in my reply about the ACME email mechanism. >=20 > Why do you ignore that answer ? You and Michael have said that MX records could be set up, but Brian = says that will lead to delivery failures. And then Ben pointed out that = a single mailbox rfcSELF@ is used for all ACP identities in the = domain. That has not been resolved. >=20 >> and secondly, i contest that it is a requirement to be able >> to do that if the recipient doesn't need to support it. > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >=20 >> Think about noreply@bad-corporation.com. >> You do want to make sure though that you are in control of >> the electronic mail address though, and that is given for ACP >> addresses. >=20 > Where in rfc5280 or any other generic RFC about certificates does > it say you MUST have a mailbox that is reachable ? Where does it > say that all certificiates with rfc822Name must be email boxes > that support ACME email style challenge-reply about the email address = ? > I think this is a non-existing requirement against email addresses. >=20 > Of course, noreply@bad-corporation.com can have a certificate with > that rfc822Name. It just can't use the ACME mechanism to be > generated. But the signed mails sent from that address can be > authenticated. >=20 > Or there are never emails, because the email address just serves > as identifier of an entity such as in wifi roaming identification > and authentication. In that case you are not authenticating > e.g.: password ownership for the email address via actual emails > but via AAA protocols against a DNS domain known AAA server > for the domain part of the email address. >=20 > If you want to write a standards track RFC that all email addresses > used in any X.509v3 certificate MUST support an ACME style=20 > challenge/reply email, then please do that, and seee if you get > thast through. If would invalidate a lot of solutions like > those wifi roaming ones. It WOULD NOT invalidate the ACP > solution, because as said (no several times) the ACP solution > can perfectly be set up to support this. It just does not > need to. I have explained reasoning in a note yesterday in response to Brian, and = it had nothing to do with ACME. Russ From nobody Sun Jun 28 07:36:41 2020 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4A4C3A0D1A for ; Sun, 28 Jun 2020 07:36:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=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 DM10ICL6V5Sq for ; Sun, 28 Jun 2020 07:36:38 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CD243A0927 for ; Sun, 28 Jun 2020 07:36:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 0AD16300B75 for ; Sun, 28 Jun 2020 10:36:36 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id drjQfo92eUzh for ; Sun, 28 Jun 2020 10:36:33 -0400 (EDT) Received: from a860b60074bd.fios-router.home (pool-72-66-113-56.washdc.fios.verizon.net [72.66.113.56]) by mail.smeinc.net (Postfix) with ESMTPSA id 0B305300A55; Sun, 28 Jun 2020 10:36:33 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.14\)) From: Russ Housley In-Reply-To: <20200628000654.GD41058@faui48f.informatik.uni-erlangen.de> Date: Sun, 28 Jun 2020 10:36:34 -0400 Cc: Brian Carpenter , Michael Richardson , Ben Kaduk , anima@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <7A22A1E0-D5E6-408F-8D15-31E09BCCF849@vigilsec.com> References: <20200617024412.GA11992@kduck.mit.edu> <9584c5cd-c68d-ddc3-0704-da672842e359@gmail.com> <9406.1592756905@localhost> <3A92516D-B980-4231-9059-EF7234BA8610@vigilsec.com> <20200627054056.GA35664@faui48f.informatik.uni-erlangen.de> <0bec7478-2661-71fe-2263-d0f5d3e75ba9@gmail.com> <020EE6AB-26B3-419B-8D5D-F573891E7293@vigilsec.com> <20200628000654.GD41058@faui48f.informatik.uni-erlangen.de> To: Toerless Eckert X-Mailer: Apple Mail (2.3445.104.14) Archived-At: Subject: Re: [Anima] Russ: Re: rfc822Name use in Autonomic Control Plane document X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jun 2020 14:36:40 -0000 > On Jun 27, 2020, at 8:06 PM, Toerless Eckert wrote: >=20 > Thanks, Russ, inline >=20 > On Sat, Jun 27, 2020 at 05:27:46PM -0400, Russ Housley wrote: >> Brian: >>=20 >>>> I think Brian actually made my point. While the filed contains an = email address, using it as such would result in a delivery failure. The = private key holder cannot be reached by this address. >>>=20 >>> I don't see a requirement in RFC5280 that the email address in an = rfc822name must be reachable, or that it must belong to the private key = holder. >>=20 >> We seem to be interpreting RFC 5280, Sections 4.1.2.6 and 4.2.16 = differently. >>=20 >> 4.1.2.6. Subject >>=20 >> The subject field identifies the entity associated with the public >> key stored in the subject public key field. The subject name MAY = be >> carried in the subject field and/or the subjectAltName extension. = ... >=20 > Yep. For purpose of ACP, we use rfc822Name, but the entity may get > from registrar/CA other names too, such as any pre-existing, however > formatted SN. >=20 >> 4.2.1.6. Subject Alternative Name >>=20 >> ... >>=20 >> When the subjectAltName extension contains an Internet mail = address, >> the address MUST be stored in the rfc822Name. >=20 > Yes. ACP does that. >=20 >> The format of an >> rfc822Name is a "Mailbox" as defined in Section 4.1.2 of [RFC2821]. >> A Mailbox has the form "Local-part@Domain". >=20 > Yes. ACP does that. >=20 >> Note that a Mailbox has >> no phrase (such as a common name) before it, has no comment (text >> surrounded in parentheses) after it, and is not surrounded by "<" = and >> ">". Rules for encoding Internet mail addresses that include >> internationalized domain names are specified in Section 7.5. >=20 > Yes, ACP does that. >=20 >> Section 4.1.2 of RFC 2821 provides the ABNF for the Mailbox. >=20 > Yes, ACP matches that. Actually, when i did the ABNF, i had to go > through a couple of RFC becaue 2821 was superceeded and i think i = picked > as references the now normative one, but have to go back and remember = details. > No actual change in the syntax AFAIK since rfc2821. >=20 >> RFC 2821 says: >>=20 >> As used in this specification, an "address" is a character string >> that identifies a user to whom mail will be sent or a location into >> which mail will be deposited. The term "mailbox" refers to that >> depository. ... >>=20 >> So, the mailbox is the place that email gets sent to. >=20 > Do you think that this sentence makes an address of = noreply@example.com > an invalid email address given how it does not receive email ? >=20 > And please do not conflate this discussion with the use in = certificates, > your discussion points about rfc2821 are non-considering any > certificate work, as rfc5280 does not attempt to redecine anything. >=20 > Would you also like to legislate what "user" means ? E.g.: would > lamps-request@ietf.org, valid email address in your reading or does > a user have to be a human ? >=20 > In any case: ACP email address can perfectly well have mailboxes, >=20 > You also did not repy to my expamples about other systems where > email addresses are primarily used for non-mailbox purposes > but still encoded in rfc822Name. I have seen no outlawing of > this practice through IETF documents. It is clear that noreply@example.com has the syntax of an email address, = but there is not corresponding mailbox. For that reason, it should not = appear in a certificate. It is the the email address of the subject of = the certificate. Russ From nobody Sun Jun 28 07:48:04 2020 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B00973A096E for ; Sun, 28 Jun 2020 07:48:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=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 oeSpe8KW2jRM for ; Sun, 28 Jun 2020 07:47:59 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8821A3A096C for ; Sun, 28 Jun 2020 07:47:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id E5E33300A98 for ; Sun, 28 Jun 2020 10:47:56 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id fYuEVT2N7X1W for ; Sun, 28 Jun 2020 10:47:50 -0400 (EDT) Received: from a860b60074bd.fios-router.home (pool-72-66-113-56.washdc.fios.verizon.net [72.66.113.56]) by mail.smeinc.net (Postfix) with ESMTPSA id 772C9300AA8; Sun, 28 Jun 2020 10:47:50 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.14\)) From: Russ Housley In-Reply-To: Date: Sun, 28 Jun 2020 10:47:51 -0400 Cc: Eric Rescorla , Toerless Eckert , Michael Richardson , Anima WG , Ben Kaduk Content-Transfer-Encoding: quoted-printable Message-Id: <3A5D70B2-B3F9-42A6-9219-F25D657A7A7F@vigilsec.com> References: <11428.1592266833@localhost> <20200617024412.GA11992@kduck.mit.edu> <9584c5cd-c68d-ddc3-0704-da672842e359@gmail.com> <9406.1592756905@localhost> <3A92516D-B980-4231-9059-EF7234BA8610@vigilsec.com> <20200627054056.GA35664@faui48f.informatik.uni-erlangen.de> <20200627224640.GA41058@faui48f.informatik.uni-erlangen.de> To: Brian Carpenter , Eric Vyncke X-Mailer: Apple Mail (2.3445.104.14) Archived-At: Subject: Re: [Anima] Russ: Re: rfc822Name use in Autonomic Control Plane document X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jun 2020 14:48:02 -0000 Brian: The point of a certificate is to bind the public key to the identity of = the private key holder. The certificate supports many different forms = of names to support many different protocols. The rfc822name is used to = bind to an email address. And, something else is going on here. That = is why I recommend otherName instead of rfc822name. I think that everyone understands that at this point. Eric: Please change the write-up for this document. It currently says: (10) Has anyone threatened an appeal or otherwise indicated extreme = discontent? If so, please summarise the areas of conflict in separate email messages = to the Responsible Area Director. (It should be in a separate email because = this questionnaire is publicly available.) No. There was unanimous support for this work and nobody raised any = objections. This is no longer the case. Russ > On Jun 27, 2020, at 11:09 PM, Brian E Carpenter = wrote: >=20 > Hi Eric, >=20 > On 28-Jun-20 10:58, Eric Rescorla wrote: >> I'm not Russ, but I don't take his point to be about ACME one way or = the other. >>=20 >> Rather, I take his point to be (as he just said in his response to = Brian) that while this is *formatted* as an e-mail address, it does not = in fact correspond to something to which e-mail can be delivered=20 >=20 > It might do, simply because it is so formatted. >=20 >> and therefore does not match the semantics of RFC 5280. >=20 > RFC5280 does not require such a mailbox to exist. Is there another = normative document, e.g. a BCP, that does require one? It's entirely = possible that the authors of RFC5280 assumed that such a mailbox would = exist, but this is not written anywhere that I can see. So IMNSHO, this = objection to the ACP draft is attempting to hold it to a standard that = isn't documented. >=20 >> Taking a step back from the substantive issue, it seems to me that to = the extent to which their is debate about the meaning of 5280, this is a = discussion which cannot be resolved entirely on this list, but instead = needs to involve the LAMPS WG. >=20 > That may be true, but it's not ANIMA's fault and the discussion first = arose last year, so why hasn't LAMPS already considered it, if it's = important enough to continue obstructing ANIMA's progress? >=20 > Brian >=20 >>=20 >> -Ekr >>=20 >>=20 >>=20 >>=20 >> On Sat, Jun 27, 2020 at 3:46 PM Toerless Eckert > wrote: >>=20 >> On Sat, Jun 27, 2020 at 11:52:20AM -0400, Russ Housley wrote: >>> Toerless: >>>=20 >>> I think Brian actually made my point. While the filed contains an = email address, using it as such would result in a delivery failure. The = private key holder cannot be reached by this address. >>=20 >> Russ, i said: >>=20 >>> First of all, you can if you want to, >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >>=20 >> Aka: Yes, if an ACP admin thinks ACME style challenge/reply >> email authentication mechanism is useful, then he can of course >> set up those email addresses accordingly. I did reply to that >> point exhaustively in my reply about the ACME email mechanism. >>=20 >> Why do you ignore that answer ? >>=20 >>> and secondly, i contest that it is a requirement to be able >>> to do that if the recipient doesn't need to support it. >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >>=20 >>> Think about noreply@bad-corporation.com = . >>> You do want to make sure though that you are in control of >>> the electronic mail address though, and that is given for ACP >>> addresses. >>=20 >> Where in rfc5280 or any other generic RFC about certificates does >> it say you MUST have a mailbox that is reachable ? Where does it >> say that all certificiates with rfc822Name must be email boxes >> that support ACME email style challenge-reply about the email = address ? >> I think this is a non-existing requirement against email = addresses. >>=20 >> Of course, noreply@bad-corporation.com = can have a certificate with >> that rfc822Name. It just can't use the ACME mechanism to be >> generated. But the signed mails sent from that address can be >> authenticated. >>=20 >> Or there are never emails, because the email address just serves >> as identifier of an entity such as in wifi roaming identification >> and authentication. In that case you are not authenticating >> e.g.: password ownership for the email address via actual emails >> but via AAA protocols against a DNS domain known AAA server >> for the domain part of the email address. >>=20 >> If you want to write a standards track RFC that all email = addresses >> used in any X.509v3 certificate MUST support an ACME style >> challenge/reply email, then please do that, and seee if you get >> thast through. If would invalidate a lot of solutions like >> those wifi roaming ones. It WOULD NOT invalidate the ACP >> solution, because as said (no several times) the ACP solution >> can perfectly be set up to support this. It just does not >> need to. >>=20 >> Cheers >> Toerless >>=20 >>> Russ >>>=20 >>>=20 >>>> On Jun 27, 2020, at 1:40 AM, Toerless Eckert > wrote: >>>>=20 >>>> Russ, >>>>=20 >>>> Top posting re. your ACP vs. ACME question. >>>>=20 >>>> ACP rfc822name are meant to be under control of the ACP network = operations. >>>> aka: the ACP registrars could be controlling rfcSELF*@example.com = mailboxes using >>>> ACME S/MIME to get rfcSELF*@example.com = certificates or IMHO easier control >>>> the acp.example.com MTA. Just no = need/benefit to do this now IMHO: >>>>=20 >>>> An ACP is a private network which is ideally isolated from other >>>> ACP networks by use of private TA. Using the ACME rfc822name scheme = would >>>> IMHO create a lot of attack components (all the MTA in the mail = path >>>> and domain names) if used acros the Internet - without benefits for >>>> ACP. Of course, if it was all a private ACME setup within an = enterprise, >>>> and using mailboxes and ACME is a popular choice - sure, why not. >>>> But for private CA setups there are existing IMO easier options >>>> (private CA VMs using EST or the like). >>>>=20 >>>> IMHO public ACME CAwith S/MIME authenitcation could make sense >>>> in the future to enable authentication across different ACP = domains. >>>>=20 >>>> Any network has links into other domains and today they are usually >>>> unauthenticated, that could be solved IMHO fairly easily. >>>>=20 >>>> "private" CA of ACP domain , lets call it acpCA signs all ACP = certs. >>>> Its own cert is not self-signed, but signed by ACME CA via S/MIME, >>>> maybe email is rfcSELF@example.com (no = ACP IPv6 address in it) >>>>=20 >>>> Now the ACP nodes actually use acpCA PLUS ACMA CA's as TA. >>>> After IKEv2 authenticates neigbor the followup ACP domain = membership >>>> step checks if the TA of the peer is acpCA. If yes, then peer >>>> becomes ACP member, otherwise we have an authenticated signalling >>>> channel to an interdomain / different CA peer. And that of course >>>> would enable better/secure auto-configuration of such interdomain >>>> links. >>>>=20 >>>> This gives me good mix of security: Its still only relying on >>>> well controlled private TA to get into ACP, but also doubles >>>> at less secure but best available "Internet/Interdomain" >>>> authentication. >>>>=20 >>>> Cheers >>>> Toerless >>>>=20 >>>> On Sun, Jun 21, 2020 at 12:36:06PM -0400, Russ Housley wrote: >>>>>> On Jun 21, 2020, at 12:28 PM, Michael Richardson = > wrote: >>>>>>=20 >>>>>>=20 >>>>>> Russ Housley > = wrote: >>>>>>> One cannot send email to the character string in this = specification, so >>>>>>> it should not be carried in the rfc822name. >>>>>>=20 >>>>>> You can send email to that character string if you configure the = MX. >>>>>> It was designed specifically to accomodate that. >>>>>>=20 >>>>>> I objected at the time: I thought it was a stupid feature, that = no sensible IKEv2 daemon >>>>>> was going to have to send/receive email. >>>>>>=20 >>>>>> But, Toerless was paranoid that if we did anything at all out of = the >>>>>> ordinary, that the corporate CA people, in order to protect their = fiefdom, >>>>>> would freak out and throw some huge roadblock in the way of = deploying the ACP. >>>>>>=20 >>>>>> And, now have an ACME method past WGLC that does certificate = validation by >>>>>> SMTP. >>>>>=20 >>>>> Looking at the email certificate enrollment work in the ACME WG = (draft-ietf-acme-email-smime-08), I have a hard time seeing how the = device that knows the private key could participate in such a protocol. = How do you see it working? >>>>>=20 >>>>> Russ >>>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>> _______________________________________________ >>>>> Anima mailing list >>>>> Anima@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/anima >>>>=20 >>>>=20 >>>> -- >>>> --- >>>> tte@cs.fau.de >>=20 >> --=20 >> --- >> tte@cs.fau.de >>=20 >> _______________________________________________ >> Anima mailing list >> Anima@ietf.org >> https://www.ietf.org/mailman/listinfo/anima >>=20 >>=20 >> _______________________________________________ >> Anima mailing list >> Anima@ietf.org >> https://www.ietf.org/mailman/listinfo/anima >>=20 >=20 From nobody Sun Jun 28 09:12:01 2020 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F7833A0D73 for ; Sun, 28 Jun 2020 09:11:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.87 X-Spam-Level: X-Spam-Status: No, score=-0.87 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=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 Wl7SUdTBZo-T for ; Sun, 28 Jun 2020 09:11:56 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 861173A0D71 for ; Sun, 28 Jun 2020 09:11:55 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [131.188.34.52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id BA3E4548011; Sun, 28 Jun 2020 18:11:49 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id B0CA1440043; Sun, 28 Jun 2020 18:11:49 +0200 (CEST) Date: Sun, 28 Jun 2020 18:11:49 +0200 From: Toerless Eckert To: Russ Housley Cc: Brian Carpenter , Eric Vyncke , Eric Rescorla , Michael Richardson , Anima WG , Ben Kaduk , barryleiba@computer.org Message-ID: <20200628161149.GA16571@faui48f.informatik.uni-erlangen.de> References: <9584c5cd-c68d-ddc3-0704-da672842e359@gmail.com> <9406.1592756905@localhost> <3A92516D-B980-4231-9059-EF7234BA8610@vigilsec.com> <20200627054056.GA35664@faui48f.informatik.uni-erlangen.de> <20200627224640.GA41058@faui48f.informatik.uni-erlangen.de> <3A5D70B2-B3F9-42A6-9219-F25D657A7A7F@vigilsec.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3A5D70B2-B3F9-42A6-9219-F25D657A7A7F@vigilsec.com> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [Anima] Russ: Re: rfc822Name use in Autonomic Control Plane document X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jun 2020 16:12:00 -0000 On Sun, Jun 28, 2020 at 10:47:51AM -0400, Russ Housley wrote: > Brian: > > The point of a certificate is to bind the public key to the identity of the private key holder. The certificate supports many different forms of names to support many different protocols. The rfc822name is used to bind to an email address. How do you think IETF should decide on what is a semantic correct email address ? RFC5280 simply inherited the non-crypto definitions of email address/mailbox. Do you think it is appropriate for you to recommend blocking progress of a document through IESG review based on your interpretation what does and what does not constitute a semantic correct email address ? Do you think that there are rfc2821 email addresses that are semantically correct if not used in a certificate, but that are not semantically correct for use in rfc5280 certificates ? If so, can you please explain how such a differentiation would be justified by existing RFC text ? If you do not think that there is a semantic correct email addresses outside and inside of certificate/rfc822Name use, how then would it be appropriate for you, Ben or LAMPS to decide on what is and what is not a semantic correct email address. > And, something else is going on here. Are you saying the addresses are (1) semantic correct email addresses AND something else is going on, or are you saying (2) they are NOT semantic correct email addresses AND something else is going on. If you are saying (1), we are back to the above discussion of the standing of how to decide what does and what does not consitute a semantic correct email address. If you are saying (2), i fully agree, but i would need an explanation of how such "something else" would invalidate the use of such email addresses in rfc822Name, because i see no further requirements against email addresses in rfc822Name other than what you showed in a prior mair on this thread. If a terminal is assigned an email address of "room17.terminal5@example.com", and the software says to the user "you are sitting in Room17 on Terminal5", because the software expected a particular formed local part of its email address and parsed it, that is something else going on. If the same email address is then use together as an identifier together with a password for the terminal to access some resources, oh, like a library database, that is also something else going on. This is pretty much what ACP does. What is IMHO is NOT going on here is that these additional aspects render room17.terminal5@example.com into a non semantic correct email address. They just do more with it. > That is why I recommend otherName instead of rfc822name. No, if you would just recommend an alternative that would be great, but you are blocking progress of a document that has a lot of in our opinion crucial explanations how that alternative would create more use-case harm than the solution choosen in the document. > I think that everyone understands that at this point. I do not understand how a recommendation like yours can raise to a blocking DISCUSS in an IESG review. > Eric: > > Please change the write-up for this document. It currently says: > > (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? > If so, please summarise the areas of conflict in separate email messages to the > Responsible Area Director. (It should be in a separate email because this > questionnaire is publicly available.) > > No. There was unanimous support for this work and nobody raised any objections. > This is no longer the case. So, it is not a recommendation you are voicing, it is instead "extreme discontent". I wonder what rules of IETF are for betting how such "extreme miscontent" has to be technically founded or just needs to be taken into account without suficient technical argument. I think you have provided no clear technical reasoning for: - How does the documents choice cause more harm than the alternative proposed for the use-cases or any other possible victims ? - How is the choice in violation of any relevant RFC ? - How are the email addresses not syntactic and semantic correct addresses according to rfc2821 ? - How are otherwise statements like "i do not think this is the right thing" and "there is something else going on here" sufficient arguments for blocking IESG progressing the document. Cheers Toerless > > Russ > > > > On Jun 27, 2020, at 11:09 PM, Brian E Carpenter wrote: > > > > Hi Eric, > > > > On 28-Jun-20 10:58, Eric Rescorla wrote: > >> I'm not Russ, but I don't take his point to be about ACME one way or the other. > >> > >> Rather, I take his point to be (as he just said in his response to Brian) that while this is *formatted* as an e-mail address, it does not in fact correspond to something to which e-mail can be delivered > > > > It might do, simply because it is so formatted. > > > >> and therefore does not match the semantics of RFC 5280. > > > > RFC5280 does not require such a mailbox to exist. Is there another normative document, e.g. a BCP, that does require one? It's entirely possible that the authors of RFC5280 assumed that such a mailbox would exist, but this is not written anywhere that I can see. So IMNSHO, this objection to the ACP draft is attempting to hold it to a standard that isn't documented. > > > >> Taking a step back from the substantive issue, it seems to me that to the extent to which their is debate about the meaning of 5280, this is a discussion which cannot be resolved entirely on this list, but instead needs to involve the LAMPS WG. > > > > That may be true, but it's not ANIMA's fault and the discussion first arose last year, so why hasn't LAMPS already considered it, if it's important enough to continue obstructing ANIMA's progress? > > > > Brian > > > >> > >> -Ekr > >> > >> > >> > >> > >> On Sat, Jun 27, 2020 at 3:46 PM Toerless Eckert > wrote: > >> > >> On Sat, Jun 27, 2020 at 11:52:20AM -0400, Russ Housley wrote: > >>> Toerless: > >>> > >>> I think Brian actually made my point. While the filed contains an email address, using it as such would result in a delivery failure. The private key holder cannot be reached by this address. > >> > >> Russ, i said: > >> > >>> First of all, you can if you want to, > >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > >> > >> Aka: Yes, if an ACP admin thinks ACME style challenge/reply > >> email authentication mechanism is useful, then he can of course > >> set up those email addresses accordingly. I did reply to that > >> point exhaustively in my reply about the ACME email mechanism. > >> > >> Why do you ignore that answer ? > >> > >>> and secondly, i contest that it is a requirement to be able > >>> to do that if the recipient doesn't need to support it. > >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > >> > >>> Think about noreply@bad-corporation.com . > >>> You do want to make sure though that you are in control of > >>> the electronic mail address though, and that is given for ACP > >>> addresses. > >> > >> Where in rfc5280 or any other generic RFC about certificates does > >> it say you MUST have a mailbox that is reachable ? Where does it > >> say that all certificiates with rfc822Name must be email boxes > >> that support ACME email style challenge-reply about the email address ? > >> I think this is a non-existing requirement against email addresses. > >> > >> Of course, noreply@bad-corporation.com can have a certificate with > >> that rfc822Name. It just can't use the ACME mechanism to be > >> generated. But the signed mails sent from that address can be > >> authenticated. > >> > >> Or there are never emails, because the email address just serves > >> as identifier of an entity such as in wifi roaming identification > >> and authentication. In that case you are not authenticating > >> e.g.: password ownership for the email address via actual emails > >> but via AAA protocols against a DNS domain known AAA server > >> for the domain part of the email address. > >> > >> If you want to write a standards track RFC that all email addresses > >> used in any X.509v3 certificate MUST support an ACME style > >> challenge/reply email, then please do that, and seee if you get > >> thast through. If would invalidate a lot of solutions like > >> those wifi roaming ones. It WOULD NOT invalidate the ACP > >> solution, because as said (no several times) the ACP solution > >> can perfectly be set up to support this. It just does not > >> need to. > >> > >> Cheers > >> Toerless > >> > >>> Russ > >>> > >>> > >>>> On Jun 27, 2020, at 1:40 AM, Toerless Eckert > wrote: > >>>> > >>>> Russ, > >>>> > >>>> Top posting re. your ACP vs. ACME question. > >>>> > >>>> ACP rfc822name are meant to be under control of the ACP network operations. > >>>> aka: the ACP registrars could be controlling rfcSELF*@example.com mailboxes using > >>>> ACME S/MIME to get rfcSELF*@example.com certificates or IMHO easier control > >>>> the acp.example.com MTA. Just no need/benefit to do this now IMHO: > >>>> > >>>> An ACP is a private network which is ideally isolated from other > >>>> ACP networks by use of private TA. Using the ACME rfc822name scheme would > >>>> IMHO create a lot of attack components (all the MTA in the mail path > >>>> and domain names) if used acros the Internet - without benefits for > >>>> ACP. Of course, if it was all a private ACME setup within an enterprise, > >>>> and using mailboxes and ACME is a popular choice - sure, why not. > >>>> But for private CA setups there are existing IMO easier options > >>>> (private CA VMs using EST or the like). > >>>> > >>>> IMHO public ACME CAwith S/MIME authenitcation could make sense > >>>> in the future to enable authentication across different ACP domains. > >>>> > >>>> Any network has links into other domains and today they are usually > >>>> unauthenticated, that could be solved IMHO fairly easily. > >>>> > >>>> "private" CA of ACP domain , lets call it acpCA signs all ACP certs. > >>>> Its own cert is not self-signed, but signed by ACME CA via S/MIME, > >>>> maybe email is rfcSELF@example.com (no ACP IPv6 address in it) > >>>> > >>>> Now the ACP nodes actually use acpCA PLUS ACMA CA's as TA. > >>>> After IKEv2 authenticates neigbor the followup ACP domain membership > >>>> step checks if the TA of the peer is acpCA. If yes, then peer > >>>> becomes ACP member, otherwise we have an authenticated signalling > >>>> channel to an interdomain / different CA peer. And that of course > >>>> would enable better/secure auto-configuration of such interdomain > >>>> links. > >>>> > >>>> This gives me good mix of security: Its still only relying on > >>>> well controlled private TA to get into ACP, but also doubles > >>>> at less secure but best available "Internet/Interdomain" > >>>> authentication. > >>>> > >>>> Cheers > >>>> Toerless > >>>> > >>>> On Sun, Jun 21, 2020 at 12:36:06PM -0400, Russ Housley wrote: > >>>>>> On Jun 21, 2020, at 12:28 PM, Michael Richardson > wrote: > >>>>>> > >>>>>> > >>>>>> Russ Housley > wrote: > >>>>>>> One cannot send email to the character string in this specification, so > >>>>>>> it should not be carried in the rfc822name. > >>>>>> > >>>>>> You can send email to that character string if you configure the MX. > >>>>>> It was designed specifically to accomodate that. > >>>>>> > >>>>>> I objected at the time: I thought it was a stupid feature, that no sensible IKEv2 daemon > >>>>>> was going to have to send/receive email. > >>>>>> > >>>>>> But, Toerless was paranoid that if we did anything at all out of the > >>>>>> ordinary, that the corporate CA people, in order to protect their fiefdom, > >>>>>> would freak out and throw some huge roadblock in the way of deploying the ACP. > >>>>>> > >>>>>> And, now have an ACME method past WGLC that does certificate validation by > >>>>>> SMTP. > >>>>> > >>>>> Looking at the email certificate enrollment work in the ACME WG (draft-ietf-acme-email-smime-08), I have a hard time seeing how the device that knows the private key could participate in such a protocol. How do you see it working? > >>>>> > >>>>> Russ > >>>>> > >>>> > >>>> > >>>> > >>>>> _______________________________________________ > >>>>> Anima mailing list > >>>>> Anima@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/anima > >>>> > >>>> > >>>> -- > >>>> --- > >>>> tte@cs.fau.de > >> > >> -- > >> --- > >> tte@cs.fau.de > >> > >> _______________________________________________ > >> Anima mailing list > >> Anima@ietf.org > >> https://www.ietf.org/mailman/listinfo/anima > >> > >> > >> _______________________________________________ > >> Anima mailing list > >> Anima@ietf.org > >> https://www.ietf.org/mailman/listinfo/anima > >> > > -- --- tte@cs.fau.de From nobody Sun Jun 28 10:01:37 2020 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 605FF3A0DD9 for ; Sun, 28 Jun 2020 10:01:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.651 X-Spam-Level: X-Spam-Status: No, score=-1.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_NONE=0.001, SPF_PASS=-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 8z6s7rKsHBSJ for ; Sun, 28 Jun 2020 10:01:34 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23CA93A0DD7 for ; Sun, 28 Jun 2020 10:01:33 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 83403548011; Sun, 28 Jun 2020 19:01:28 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 7C52D440043; Sun, 28 Jun 2020 19:01:28 +0200 (CEST) Date: Sun, 28 Jun 2020 19:01:28 +0200 From: Toerless Eckert To: Russ Housley Cc: Brian Carpenter , Michael Richardson , Ben Kaduk , anima@ietf.org, barryleiba@computer.com Message-ID: <20200628170128.GB16571@faui48f.informatik.uni-erlangen.de> References: <9584c5cd-c68d-ddc3-0704-da672842e359@gmail.com> <9406.1592756905@localhost> <3A92516D-B980-4231-9059-EF7234BA8610@vigilsec.com> <20200627054056.GA35664@faui48f.informatik.uni-erlangen.de> <0bec7478-2661-71fe-2263-d0f5d3e75ba9@gmail.com> <020EE6AB-26B3-419B-8D5D-F573891E7293@vigilsec.com> <20200628000654.GD41058@faui48f.informatik.uni-erlangen.de> <7A22A1E0-D5E6-408F-8D15-31E09BCCF849@vigilsec.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7A22A1E0-D5E6-408F-8D15-31E09BCCF849@vigilsec.com> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: [Anima] No certs for noreply (was: Re: Russ: Re: rfc822Name use in Autonomic Control Plane) document X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jun 2020 17:01:36 -0000 On Sun, Jun 28, 2020 at 10:36:34AM -0400, Russ Housley wrote: > > You also did not repy to my expamples about other systems where > > email addresses are primarily used for non-mailbox purposes > > but still encoded in rfc822Name. I have seen no outlawing of > > this practice through IETF documents. > > It is clear that noreply@example.com has the syntax of an email address, but there is not corresponding mailbox. For that reason, it should not appear in a certificate. It is the the email address of the subject of the certificate. Ok, i think this simple example allows me maybe to understand the process better. So, if i was to write a target normative RFC explaining for example certificates for "customer communications" departments of example.com that would result in creation of certs with rfc822Name noreply@example.com. This draft passes 5 years through WG and all IETF/IESG review except SEC review. What now are the criteria by which your opinion should be vetted as a blocker for IESG approval of the document ? I for once received numerous email in private that it is impossible to argue opinions of security people in IETF technically, just because of the weight that their names carry with IESG, so i shouldn't even try technical arguments. And i fear this is true, and some of the other emails here (not from you) also indicate this to me. If not, then i would like to hear what you think the process should be. If this is the process, then i should obviously stop making technical arguments, accept defeat and move on. Hopefully we will at least be allowed to document in the RFC how easier implementable and deployable solutions where unacceptable due to ... understanding of the required semantic of rfc822Name content. Otherwise we would loose the whole discussion here. I already feel that the process is injust because i seem to have to prove that what we are doing is not in violation of RFC/semantics, which to me sounds like i have to prove our draft is "innocent", whereas i was under the assumption that the burden of proof was opposite. Wrt to the technical argument: noreply@example.com is an interesting example, because i hate receiving these emails, so i would LOVE to see a normative RFC saying that these type of email addresses MUST NOT get certificates. However, technically i think that is not defensible, because obviously (to me) its perfect valid for a mailbox to not receive or not to send emails. Its to me just a controlled subject with a name/address. And customer harrasment departments are of course also interested to be protected from phishing and the like, so they will of course also use certificates for mails from noreply@example.com as soon as enough customers would understand security (*sigh*). And i am willing to take any bet with you, that there will be nothing from the IETF that normatively says this should not be done. Cheers Toerless > > Russ From nobody Sun Jun 28 15:36:25 2020 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D25A3A0F4D for ; Sun, 28 Jun 2020 15:36:24 -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, FREEMAIL_FROM=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 RleYz9PccFkQ for ; Sun, 28 Jun 2020 15:36:22 -0700 (PDT) Received: from mail-pl1-x62d.google.com (mail-pl1-x62d.google.com [IPv6:2607:f8b0:4864:20::62d]) (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 D93D23A0814 for ; Sun, 28 Jun 2020 15:36:22 -0700 (PDT) Received: by mail-pl1-x62d.google.com with SMTP id u9so2729821pls.13 for ; Sun, 28 Jun 2020 15:36:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:references:to:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=T8MFN0Ih/LLEhTiqBpiZ64oX8cNar1WhlGep/qX6Fr8=; b=VmokiZbd/c+GbJmBL4L4NhoeQA1/nSYZ3tsc0aUQLp0jPf2Y8T4peeGa9kaiCSMVRJ wTZD/eU8J1NL1Yd5T9tiAMCQdhMcOtVtA2eKtQjcdbwbv23XioU0qpf2m7RT+h8Xu5Db xJvW5edDBoDBfq6+B3B2xScFqSlEPW4RVW/klrE5SC5cv5mgPQsIAtX6d2Q+oL3OMHw1 iMIz8FpWhadCAIBMB4dxNVK7dIUEAgqWk/QIRiO3pn3lVKlrTtP/4iOveCf5bEoObd8p ASgXCSYkVk2GNvwMLe9MkVZ5WqVS58nLSvZuASPgc5989QW4nMO3EUwO/nQTy59pLUzW /aVQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:references:to:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=T8MFN0Ih/LLEhTiqBpiZ64oX8cNar1WhlGep/qX6Fr8=; b=pucjv/gg9cn0lMmNmPvnZb+l+yC8uuLj+EDrx/2I1LIa7hSaFx+HYzH7CanKbTzLgJ 0DuaOOJ6oXob5SBNw38r1yaBP0eVU4m096XLO32nT1VARsZZMOmppbHOlKPJK8vVRpJ+ bRreSgwwyszERL5/ibk+PCsZNMrRuYB3XnU1xVN57dma1FYLw31MmoIFDba2M9bAmCA5 e4AkhhYvA5pTwMEXF9I4RECXRB/+ndHz2VKgVBWPfpIyMrLRWlcy1DCwp+g14n4BKeNC SYF5BpEdeg+CcDcFoMJD/oL12JLchz2a4SeORR3IA7dt5NKmCsmnuRad13NtSm3E0vtD Yenw== X-Gm-Message-State: AOAM530ZG/pwB0aybsBpVZyglafh4z7q+soJcXTiZfEVeEs+XlxGJTmY D1QhnlQMnLQKRpcOxYUVEY/vNmpir0U= X-Google-Smtp-Source: ABdhPJxZqgD4x4snSni7ZaTh5mpe2D98U5FvmQ2AWEOsOd7Ky9MF+2OvW74+KdZB1/5bt/31cVFfvw== X-Received: by 2002:a17:902:a511:: with SMTP id s17mr11033574plq.37.1593383782101; Sun, 28 Jun 2020 15:36:22 -0700 (PDT) Received: from [192.168.178.20] (203.90.69.111.dynamic.snap.net.nz. [111.69.90.203]) by smtp.gmail.com with ESMTPSA id y10sm4542994pfn.121.2020.06.28.15.36.20 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 28 Jun 2020 15:36:21 -0700 (PDT) References: <159338339853.14735.3533502825063015940@ietfa.amsl.com> To: Anima WG From: Brian E Carpenter X-Forwarded-Message-Id: <159338339853.14735.3533502825063015940@ietfa.amsl.com> Message-ID: <7f4104b9-03f5-a0cf-c855-a1556f682a01@gmail.com> Date: Mon, 29 Jun 2020 10:36:17 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <159338339853.14735.3533502825063015940@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [Anima] Fwd: New Version Notification for draft-carpenter-anima-quads-grasp-03.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jun 2020 22:36:24 -0000 Hi, I have refreshed this draft since it expired a while ago. There is no technical change, but I have slightly reworded the title and text to clarify that this is in fact a simple but secure ACP (with running code). However, it does depend on a shared secret, which of course is not ideal. Regards Brian -------- Forwarded Message -------- Subject: New Version Notification for draft-carpenter-anima-quads-grasp-03.txt Date: Sun, 28 Jun 2020 15:29:58 -0700 From: internet-drafts@ietf.org To: Brian Carpenter A new version of I-D, draft-carpenter-anima-quads-grasp-03.txt has been successfully submitted by Brian Carpenter and posted to the IETF repository. Name: draft-carpenter-anima-quads-grasp Revision: 03 Title: Quick and Dirty Secure Autonomic Control Plane for GRASP Document date: 2020-06-29 Group: Individual Submission Pages: 10 URL: https://www.ietf.org/internet-drafts/draft-carpenter-anima-quads-grasp-03.txt Status: https://datatracker.ietf.org/doc/draft-carpenter-anima-quads-grasp/ Htmlized: https://tools.ietf.org/html/draft-carpenter-anima-quads-grasp-03 Htmlized: https://datatracker.ietf.org/doc/html/draft-carpenter-anima-quads-grasp Diff: https://www.ietf.org/rfcdiff?url2=draft-carpenter-anima-quads-grasp-03 Abstract: A secure substrate known as the Autonomic Control Plane (ACP) is required by the Generic Autonomic Signaling Protocol (GRASP) used by Autonomic Service Agents. This document describes QUADS, a QUick And Dirty Secure ACP using symmetric cryptography and preconfigured keys or passwords. It also describes a simplistic QUADS Key Infrastructure based on asymmetric cryptography used over insecure instances of GRASP to create a QUADS ACP. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From nobody Sun Jun 28 20:02:21 2020 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B72493A0645 for ; Sun, 28 Jun 2020 20:02:18 -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 O77CylcKQnem for ; Sun, 28 Jun 2020 20:02:16 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11BCB3A060A for ; Sun, 28 Jun 2020 20:02:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 5AF8538990 for ; Sun, 28 Jun 2020 22:59: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 Yc86XnZ7l6_M for ; Sun, 28 Jun 2020 22:59:28 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 123783898E for ; Sun, 28 Jun 2020 22:59:28 -0400 (EDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 72601F11 for ; Sun, 28 Jun 2020 23:02:13 -0400 (EDT) To: anima@ietf.org References: <159296586835.337.577109779817720457@ietfa.amsl.com> From: Michael Richardson Message-ID: <16876f80-5504-a622-f13c-686ce69b4733@sandelman.ca> Date: Sun, 28 Jun 2020 23:02:13 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <159296586835.337.577109779817720457@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [Anima] "virtual out-of-band" ... or some minor non-ACP-number comments on Action: draft-ietf-anima-autonomic-control-plane-25.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2020 03:02:19 -0000 On 2020-06-23 10:31 p.m., internet-drafts@ietf.org wrote: > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-anima-autonomic-control-plane-25 yes, I read the diffs :-) - This document describes a modular design for a self-forming, self- - managing and self-protecting ACP, which is a virtual in-band network - designed to be as independent as possible of configuration, + This document describes a modular design for a self-forming, self- + managing and self-protecting ACP, which is a virtual out-of-band + network designed to be as independent as possible of configuration, This change from being a virtual in-band network to a virtual out-of-band network must have been in response to some comments... It seems a big change in some ways. I guess it makes this text consistent with the abstract which has said virtual out-of-band for awhile now. But, I do have to wonder if we are creating confusion by claiming that this is an out-of-band mechanism, even though it's really an in-band mechanism. It's just virtually-out. I actually do want to start a bike-shed issue here? Are we describing ourself wrong? Maybe there is some portmanteau that would be more accurate? I think that the above sentence is essentially the elevator pitch for all of ANIMA. There is also a bunch of other text that has been added to the Introduction, which I think confuses more than it enlightens. Or at least needs a better copy-edit. A number of other new sections (9.4..) need a copy-edit to fix some missing words. I will try to help Toerless with that via github. From nobody Mon Jun 29 05:45:46 2020 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BDEA3A0CA4 for ; Mon, 29 Jun 2020 05:45:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.233 X-Spam-Level: X-Spam-Status: No, score=-1.233 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=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 XiO0D7hDCX7B for ; Mon, 29 Jun 2020 05:45:42 -0700 (PDT) Received: from oldperseverance.encs.concordia.ca (oldperseverance.encs.concordia.ca [132.205.96.92]) by ietfa.amsl.com (Postfix) with ESMTP id E95EB3A0C63 for ; Mon, 29 Jun 2020 05:45:41 -0700 (PDT) Received: from [IPv6:::1] (bill@grace.encs.concordia.ca [132.205.2.217] port 64205) by oldperseverance.encs.concordia.ca (envelope-from william.atwood@concordia.ca) (8.13.7/8.13.7) with ESMTP id 05TCjcas007255 for ; Mon, 29 Jun 2020 08:45:39 -0400 To: anima@ietf.org References: <159296586835.337.577109779817720457@ietfa.amsl.com> <16876f80-5504-a622-f13c-686ce69b4733@sandelman.ca> From: William Atwood Autocrypt: addr=william.atwood@concordia.ca; prefer-encrypt=mutual; keydata= mQGiBEmjdrMRBADawl3I6QQW9RTYKHQk0tMhjbbgi7clCKZzmgTOOHKYDil9J68+xyTdXlBT ud5crBx2kYf334Uf5fOBNBh6Z/3kUr2qkvVHXAp+yox81wao8pBwQ5wcnhPmnGhpsapCMeBA 3deiCQfvd9AVygrNZOJvW526PIHiNvob2pDT4ef0iwCgroVoHugkt+84Ly3jL9lcFFmqW38D /2exybJrzefDFGHExaQinYRwIovHhdilirh3k6BcRaS6xWUbWsra+w0OSQWCt+Ooaj6Zmeio 13U5lybjD4M0Se7TI0AW6JJsHot3x69/2Uq2OWb1cddezafZ4+vlNybC5LZ+tynTVt2RB7lE Yy34W9kTWIHsaFOLUjDaZW+ScpKoA/9yXM3FY7hUTBEgP5+CUyX4zYsnxtmeurhVi4D3Ri1e TRQhE/WxaVsxxqJuFNx/rzOPwnekWa06cb4mKYHJ6HJ/q1hjSCOvhlSUgLwQ6XiqYW/dulfL ulq6d9w01gApWPNdaimLOnZi/Of52YO7RZroSNPBwC71hOxzQCzeHZLgaLQxSm9obiBXaWxs aWFtIEF0d29vZCA8d2lsbGlhbS5hdHdvb2RAY29uY29yZGlhLmNhPohjBBMRAgAjAhsjBgsJ CAcDAgQVAggDBBYCAwECHgECF4AFAlC5EYcCGQEACgkQV5o4IdDwBVhFdACePdBrMqD3jC9V 53DbmgWkIR5oHVAAn1HPsfaMXQsIyim9d2wpwQunGDcXuQINBEmjdrMQCACDziZLszCCtC0i 195vC7UlKnKEE7rLKP+tzpJuPb6EW27xBtJ2cr6RXZQ84rrHvgczmhaht7kUPyyAFVUG2pbK 9vOBPcurdimtz4cc5FJ6v2wi9NoNaxag8MY2WYYzH7Fs4Bh7ZK7B6pR/lYVNltu8vxT7MO4p k+jjDaKkYU4VlN9dWrwTapmBbYafdOHhxnvxYrr3TsLdpYbGiucDwLtWGgd7+jx9LUT9tStg RgSYpwULZbQWHjSGRAXHtOzsk01TcTUP+rzbqteQ+3n867848rnJxoOWdOF73TR32dif0osf DAr4EuHHSkRI8a7me8zcVVZGhjQsp6JGsnhKO0AfAAMFB/9Cym72Z7nNw4ewqhVAVPal+tQG zkyh1S8vTEo6GdOK7eapc1OaSK7YCAS6UmFVTgoAjRBUPA5L7aLorSUXwzjZ7X26Pn2ywlnI c8+7AlbeGnggEg1h95QQTly+xU3ZEiBF0LhhyAwpISqGiz7zq44w2pqAxnAiKNX2xZxjHdZ+ yDMxT86Yj/U7K6ITv4/GwygS7bMt9+wXYRzvr9gHr5jKMEsTeIJHi5UNWLYfpfmhyF6sZ3KT qHFVAZ6yu2xDuAEhnIWaOUC2+Z9XHLMvgSrxIleqkKJiWZbAc9C1F/iV+DeQ7rNPNg9pN2Kr imkVfjdMTCwORUeeGprBurp3wCy/iEkEGBECAAkFAkmjdrMCGwwACgkQV5o4IdDwBVgd9gCf YD8t+Q9rphTC4HpOX9lHYEIIko8An2V2hchJax+LOGzSQOXOj8OgK3g3 Organization: Concordia University, Montreal Message-ID: <86736d02-d1b6-ebfb-a894-92c9ca4b1e96@concordia.ca> Date: Mon, 29 Jun 2020 08:45:38 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <16876f80-5504-a622-f13c-686ce69b4733@sandelman.ca> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.58 on oldperseverance.encs.concordia.ca at 2020-06-29 08:45:39 EDT Archived-At: Subject: Re: [Anima] "virtual out-of-band" ... or some minor non-ACP-number comments on Action: draft-ietf-anima-autonomic-control-plane-25.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2020 12:45:44 -0000 Is "overlay" the right word? I agree that it is physically in-band, and virtually out-of-band. Isn't that the definition of "overlay"? Bill On 2020-06-28 11:02 p.m., Michael Richardson wrote: > Attention This email originates from outside the concordia.ca domain. // > Ce courriel provient de l'exterieur du domaine de concordia.ca > On 2020-06-23 10:31 p.m., internet-drafts@ietf.org wrote: >> A diff from the previous version is available at: >> > https://www.ietf.org/rfcdiff?url2=draft-ietf-anima-autonomic-control-plane-25 > > > yes, I read the diffs :-) > > -   This document describes a modular design for a self-forming, self- > -   managing and self-protecting ACP, which is a virtual in-band network > -   designed to be as independent as possible of configuration, > > +   This document describes a modular design for a self-forming, self- > +   managing and self-protecting ACP, which is a virtual out-of-band > +   network designed to be as independent as possible of configuration, > > This change from being a virtual in-band network to a virtual > out-of-band network must have been in response to some comments... It > seems a big change in some ways.  I guess it makes this text consistent > with the abstract which has said virtual out-of-band for awhile now. > > But, I do have to wonder if we are creating confusion by claiming that > this is an out-of-band mechanism, even though it's really an in-band > mechanism.  It's just virtually-out. > > I actually do want to start a bike-shed issue here? > Are we describing ourself wrong?  Maybe there is some portmanteau that > would be more accurate?  I think that the above sentence is essentially > the elevator pitch for all of ANIMA. > > > There is also a bunch of other text that has been added to the > Introduction, which I think confuses more than it enlightens. > Or at least needs a better copy-edit. > > A number of other new sections (9.4..) need a copy-edit to fix some > missing words.  I will try to help Toerless with that via github. > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima > -- Dr. J.W. Atwood, Eng. tel: +1 (514) 848-2424 x3046 Distinguished Professor Emeritus fax: +1 (514) 848-2830 Department of Computer Science and Software Engineering Concordia University EV 3.185 email:william.atwood@concordia.ca 1455 de Maisonneuve Blvd. West http://users.encs.concordia.ca/~bill Montreal, Quebec Canada H3G 1M8 From nobody Mon Jun 29 06:49:41 2020 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AF2F3A0EF6 for ; Mon, 29 Jun 2020 06:49:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 9h9EVtu6XRRz for ; Mon, 29 Jun 2020 06:49:38 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B3E83A0EF3 for ; Mon, 29 Jun 2020 06:49:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 6EB76300B83 for ; Mon, 29 Jun 2020 09:49:35 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 920eDk_RpjJW for ; Mon, 29 Jun 2020 09:49:33 -0400 (EDT) Received: from a860b60074bd.fios-router.home (pool-72-66-113-56.washdc.fios.verizon.net [72.66.113.56]) by mail.smeinc.net (Postfix) with ESMTPSA id E42F8300AE4; Mon, 29 Jun 2020 09:49:32 -0400 (EDT) From: Russ Housley Message-Id: <72D84BE3-1928-4153-A5BF-9B4FC53E0245@vigilsec.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_E5DB1C35-D331-4521-A473-71A8BEF3C25D" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.14\)) Date: Mon, 29 Jun 2020 09:49:34 -0400 In-Reply-To: <20200628161149.GA16571@faui48f.informatik.uni-erlangen.de> Cc: Eric Vyncke , Eric Rescorla , Michael Richardson , Anima WG , Ben Kaduk , Barry Leiba To: Toerless Eckert References: <9584c5cd-c68d-ddc3-0704-da672842e359@gmail.com> <9406.1592756905@localhost> <3A92516D-B980-4231-9059-EF7234BA8610@vigilsec.com> <20200627054056.GA35664@faui48f.informatik.uni-erlangen.de> <20200627224640.GA41058@faui48f.informatik.uni-erlangen.de> <3A5D70B2-B3F9-42A6-9219-F25D657A7A7F@vigilsec.com> <20200628161149.GA16571@faui48f.informatik.uni-erlangen.de> X-Mailer: Apple Mail (2.3445.104.14) Archived-At: Subject: Re: [Anima] Russ: Re: rfc822Name use in Autonomic Control Plane document X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2020 13:49:40 -0000 --Apple-Mail=_E5DB1C35-D331-4521-A473-71A8BEF3C25D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Toerless: >> I think that everyone understands that at this point. >=20 > I do not understand how a recommendation like yours can raise to > a blocking DISCUSS in an IESG review. I was asked to go a review, and I did so. As I said, I am quite sure = that you and everyone else that is reading this thread understands the = concern at this point. In my opinion, and the opinion of a few others that have spoken on this = list, the use of rfc822name is harmful. Russ --Apple-Mail=_E5DB1C35-D331-4521-A473-71A8BEF3C25D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Toerless:

I think that everyone understands = that at this point.

I do not understand how a recommendation like yours can raise = to
a blocking = DISCUSS in an IESG review.

I was asked to go a review, and I did = so.  As I said, I am quite sure that you and everyone else that is = reading this thread understands the concern at this point.

In my opinion, and the = opinion of a few others that have spoken on this list, the use of = rfc822name is harmful.

Russ

= --Apple-Mail=_E5DB1C35-D331-4521-A473-71A8BEF3C25D-- From nobody Mon Jun 29 06:59:17 2020 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD45A3A0F0B for ; Mon, 29 Jun 2020 06:59:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=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 a_7dTVRfiFEx for ; Mon, 29 Jun 2020 06:59:13 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41EA33A0F0A for ; Mon, 29 Jun 2020 06:59:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id C834E300B12 for ; Mon, 29 Jun 2020 09:59:10 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id jOuX3EqL7IPY for ; Mon, 29 Jun 2020 09:59:07 -0400 (EDT) Received: from a860b60074bd.fios-router.home (pool-72-66-113-56.washdc.fios.verizon.net [72.66.113.56]) by mail.smeinc.net (Postfix) with ESMTPSA id B8134300AE4; Mon, 29 Jun 2020 09:59:07 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.14\)) From: Russ Housley In-Reply-To: <20200628170128.GB16571@faui48f.informatik.uni-erlangen.de> Date: Mon, 29 Jun 2020 09:59:09 -0400 Cc: Brian Carpenter , Michael Richardson , Ben Kaduk , anima@ietf.org, barryleiba@computer.com Content-Transfer-Encoding: quoted-printable Message-Id: <0E9FB38C-B615-4A4D-876C-D27F3C8DA288@vigilsec.com> References: <9584c5cd-c68d-ddc3-0704-da672842e359@gmail.com> <9406.1592756905@localhost> <3A92516D-B980-4231-9059-EF7234BA8610@vigilsec.com> <20200627054056.GA35664@faui48f.informatik.uni-erlangen.de> <0bec7478-2661-71fe-2263-d0f5d3e75ba9@gmail.com> <020EE6AB-26B3-419B-8D5D-F573891E7293@vigilsec.com> <20200628000654.GD41058@faui48f.informatik.uni-erlangen.de> <7A22A1E0-D5E6-408F-8D15-31E09BCCF849@vigilsec.com> <20200628170128.GB16571@faui48f.informatik.uni-erlangen.de> To: Toerless Eckert X-Mailer: Apple Mail (2.3445.104.14) Archived-At: Subject: Re: [Anima] No certs for noreply (was: Re: Russ: Re: rfc822Name use in Autonomic Control Plane) document X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2020 13:59:15 -0000 > On Jun 28, 2020, at 1:01 PM, Toerless Eckert wrote: >=20 > On Sun, Jun 28, 2020 at 10:36:34AM -0400, Russ Housley wrote: >>> You also did not repy to my expamples about other systems where >>> email addresses are primarily used for non-mailbox purposes >>> but still encoded in rfc822Name. I have seen no outlawing of >>> this practice through IETF documents. >>=20 >> It is clear that noreply@example.com has the syntax of an email = address, but there is not corresponding mailbox. For that reason, it = should not appear in a certificate. It is the the email address of the = subject of the certificate. >=20 > Ok, i think this simple example allows me maybe to understand the = process better. >=20 > So, if i was to write a target normative RFC explaining for example=20 > certificates for "customer communications" departments of example.com = that would > result in creation of certs with rfc822Name noreply@example.com. >=20 > This draft passes 5 years through WG and all IETF/IESG review except = SEC review. >=20 > What now are the criteria by which your opinion should be vetted as a = blocker > for IESG approval of the document ? >=20 > I for once received numerous email in private that it is impossible to = argue > opinions of security people in IETF technically, just because of the = weight that their > names carry with IESG, so i shouldn't even try technical arguments. = And i fear this is > true, and some of the other emails here (not from you) also indicate = this to me. >=20 > If not, then i would like to hear what you think the process should = be. >=20 > If this is the process, then i should obviously stop making technical > arguments, accept defeat and move on. Hopefully we will at least be = allowed > to document in the RFC how easier implementable and deployable = solutions > where unacceptable due to ... understanding of the required semantic = of > rfc822Name content. Otherwise we would loose the whole discussion = here. >=20 > I already feel that the process is injust because i seem to > have to prove that what we are doing is not in violation of = RFC/semantics, > which to me sounds like i have to prove our draft is "innocent", = whereas > i was under the assumption that the burden of proof was opposite. >=20 > Wrt to the technical argument: >=20 > noreply@example.com is an interesting example, because i hate = receiving these > emails, so i would LOVE to see a normative RFC saying that these type = of > email addresses MUST NOT get certificates. However, technically i = think that > is not defensible, because obviously (to me) its perfect valid for a > mailbox to not receive or not to send emails. Its to me just a = controlled subject > with a name/address. >=20 > And customer harrasment departments are of course also > interested to be protected from phishing and the like, so they will > of course also use certificates for mails from noreply@example.com as = soon > as enough customers would understand security (*sigh*). And i am = willing > to take any bet with you, that there will be nothing from the IETF = that > normatively says this should not be done.=20 No. I go not agree. The noreply@example.com mailbox is not ever used = to communicate with the party that holds the private key. So, it should = not be bound to the subject public key in a certificate. Russ From nobody Mon Jun 29 06:59:52 2020 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2D4B3A0F0C for ; Mon, 29 Jun 2020 06:59:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.65 X-Spam-Level: X-Spam-Status: No, score=-1.65 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 UlyP2kOLaqfT for ; Mon, 29 Jun 2020 06:59:49 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6EC1E3A0EEA for ; Mon, 29 Jun 2020 06:59:49 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [131.188.34.52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id EB83D548441; Mon, 29 Jun 2020 15:59:43 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id E6875440043; Mon, 29 Jun 2020 15:59:43 +0200 (CEST) Date: Mon, 29 Jun 2020 15:59:43 +0200 From: Toerless Eckert To: Michael Richardson Cc: anima@ietf.org Message-ID: <20200629135943.GD16571@faui48f.informatik.uni-erlangen.de> References: <159296586835.337.577109779817720457@ietfa.amsl.com> <16876f80-5504-a622-f13c-686ce69b4733@sandelman.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <16876f80-5504-a622-f13c-686ce69b4733@sandelman.ca> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [Anima] "virtual out-of-band" ... or some minor non-ACP-number comments on Action: draft-ietf-anima-autonomic-control-plane-25.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2020 13:59:52 -0000 Thanks, Michael, inline On Sun, Jun 28, 2020 at 11:02:13PM -0400, Michael Richardson wrote: > On 2020-06-23 10:31 p.m., internet-drafts@ietf.org wrote: > > A diff from the previous version is available at: > > > https://www.ietf.org/rfcdiff?url2=draft-ietf-anima-autonomic-control-plane-25 > > yes, I read the diffs :-) > > - This document describes a modular design for a self-forming, self- > - managing and self-protecting ACP, which is a virtual in-band network > - designed to be as independent as possible of configuration, > > + This document describes a modular design for a self-forming, self- > + managing and self-protecting ACP, which is a virtual out-of-band > + network designed to be as independent as possible of configuration, > > This change from being a virtual in-band network to a virtual out-of-band > network must have been in response to some comments... It seems a big change > in some ways. I guess it makes this text consistent with the abstract which > has said virtual out-of-band for awhile now. > > But, I do have to wonder if we are creating confusion by claiming that this > is an out-of-band mechanism, even though it's really an in-band mechanism. Its in-band with the physcial component, it is out-of-band with the configuration of the Data-Plane. Go figure how you compress that into a single term that most logically captures this. I have been using virtual out-of-band network forever for this, and Joels review pointed out that it was not done consistently in the text. > It's just virtually-out. > > I actually do want to start a bike-shed issue here? With a question mark. Does that mean you do or you do not ? > Are we describing ourself wrong? Maybe there is some portmanteau that would > be more accurate? I think that the above sentence is essentially the > elevator pitch for all of ANIMA. I am not sure if i would elevate it to "all of ANIMA", but i agree that it is an elevator term for ACP. It is mostly focussed on operators that would at least heart of actual out-of-band network or have one themselves. > There is also a bunch of other text that has been added to the Introduction, > which I think confuses more than it enlightens. > Or at least needs a better copy-edit. Sure, please propose better text. > A number of other new sections (9.4..) need a copy-edit to fix some missing > words. I will try to help Toerless with that via github. Thanks Cheers Toerless From nobody Mon Jun 29 07:21:33 2020 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 784FC3A0F34 for ; Mon, 29 Jun 2020 07:21:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.641 X-Spam-Level: X-Spam-Status: No, score=-1.641 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01] 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 tbcqZ2InUJzb for ; Mon, 29 Jun 2020 07:21:29 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 886763A0F3E for ; Mon, 29 Jun 2020 07:21:29 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id BA4AD548441; Mon, 29 Jun 2020 16:21:24 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id B38D6440043; Mon, 29 Jun 2020 16:21:24 +0200 (CEST) Date: Mon, 29 Jun 2020 16:21:24 +0200 From: Toerless Eckert To: Russ Housley Cc: Brian Carpenter , Michael Richardson , Ben Kaduk , anima@ietf.org, barryleiba@computer.com Message-ID: <20200629142124.GE16571@faui48f.informatik.uni-erlangen.de> References: <9406.1592756905@localhost> <3A92516D-B980-4231-9059-EF7234BA8610@vigilsec.com> <20200627054056.GA35664@faui48f.informatik.uni-erlangen.de> <0bec7478-2661-71fe-2263-d0f5d3e75ba9@gmail.com> <020EE6AB-26B3-419B-8D5D-F573891E7293@vigilsec.com> <20200628000654.GD41058@faui48f.informatik.uni-erlangen.de> <7A22A1E0-D5E6-408F-8D15-31E09BCCF849@vigilsec.com> <20200628170128.GB16571@faui48f.informatik.uni-erlangen.de> <0E9FB38C-B615-4A4D-876C-D27F3C8DA288@vigilsec.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0E9FB38C-B615-4A4D-876C-D27F3C8DA288@vigilsec.com> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [Anima] No certs for noreply (was: Re: Russ: Re: rfc822Name use in Autonomic Control Plane) document X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2020 14:21:32 -0000 On Mon, Jun 29, 2020 at 09:59:09AM -0400, Russ Housley wrote: > > Wrt to the technical argument: > > > > noreply@example.com is an interesting example, because i hate receiving these > > emails, so i would LOVE to see a normative RFC saying that these type of > > email addresses MUST NOT get certificates. However, technically i think that > > is not defensible, because obviously (to me) its perfect valid for a > > mailbox to not receive or not to send emails. Its to me just a controlled subject > > with a name/address. > > > > And customer harrasment departments are of course also > > interested to be protected from phishing and the like, so they will > > of course also use certificates for mails from noreply@example.com as soon > > as enough customers would understand security (*sigh*). And i am willing > > to take any bet with you, that there will be nothing from the IETF that > > normatively says this should not be done. > > No. I go not agree. The noreply@example.com mailbox is not ever used to communicate with the party that holds the private key. So, it should not be bound to the subject public key in a certificate. Why can noreply@example.com not have the private key for the certificate which has noreply@example.com in its rfc822Name ? Are you excluding the option for any validation procedure that does not include an actual ?challenge? email to the email address ? Remember that in a private PKI environment ALL names in a certificate could be assigned to the entity based on a validation that by itself may not show up in the certificate at all. E.g.: When i become employee of a company, someone might see my drivers license, but the company PKI generated cert for me in that enrollment process would not have any info from that drivers license, but just my name in the SNand company email address in the rfc822Name SAN. On a USB TPM stick. To sign my email, or whatever else. Oh, and i was hired to be responsible to send harrassment emails to customers, so i get a second USB TPM stick to use specifically for this job role and it has only rfc822Name email address with noreply@example.com. Cheers Toerless > Russ From nobody Mon Jun 29 15:07:00 2020 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3ECD23A0D99 for ; Mon, 29 Jun 2020 15:06:58 -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, FREEMAIL_FROM=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 9TZXBWJDZVpt for ; Mon, 29 Jun 2020 15:06:56 -0700 (PDT) Received: from mail-pg1-x52d.google.com (mail-pg1-x52d.google.com [IPv6:2607:f8b0:4864:20::52d]) (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 B21403A0D96 for ; Mon, 29 Jun 2020 15:06:56 -0700 (PDT) Received: by mail-pg1-x52d.google.com with SMTP id e8so8957338pgc.5 for ; Mon, 29 Jun 2020 15:06:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=/04OLW6GY+hUwjZy+vpOBhEv+3MR88XenAuhA1OlAnA=; b=rFFlSu7Z38FkAFyxquwIazvYwEP3UYTCvcTOgWPx8b37iX34GsFiJh8ChH9bcZxTZH tadojT9hkBKzyRyOTUNPTQc6AcAXQfGIgia+W7b61RhsnT2eb88gNOoHVP11oSuZPDkt 1L3EacxWpUehdVKN361l7AZvw6QeS7qF1gLIksMTCSbVrOh89/wgSM7u2xGM50bfWz0d 9pFfX636Zp691Dd/E4M4Q2f+l7gG87VEIxNAn6HNZdvDafvWakMpGw7C1qO6pcKFnEjM LkvhPOzJGHhjLTGRWJ6NXsErPMpuTpPZHNWZYMXikVx+N13eMyVJ4Fe5y6RcszumG9QL purA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=/04OLW6GY+hUwjZy+vpOBhEv+3MR88XenAuhA1OlAnA=; b=CJ8E/bS2DBI9NLg7OtfE0EwA2Lwcx9wYS2p81kCIoBEywb7c/PoMXBns5RHT4Gjq1w 8ndcgbfQ18Lf3uJZpKpWh7SmECst5yzAZUMb8KPb9NQl49CMbA/vLtps7nAL3+04mX2P E4OHRz8/HLCRuKrH8a+NJhSDuTrMj4eZdb7rijou9lUf5Zd+1ENwjplE+i87RIbaT8UY ob10nhyH6BbUUvK1L/sCyGutYZFi4IQfyB2zO3Sw6yKT4rbnp1jSlbI++DwO1FpDl0VY 8T8xD0G0VMtDAwbyytiFz1K63iiEbCAVh26KulHijpXZnidNBxOSLCu35yyTcg3fpTBX DUIg== X-Gm-Message-State: AOAM530EP92WnixnxkMy07bgdrHO1V15VwrM8JauV7oPNzHpw8+LYEa4 spb282OIRThqKi6apI9AQhX0Vc0wGXo= X-Google-Smtp-Source: ABdhPJxaWU/a0V+5HDQDnhCopwvPqmnO1TE7tq7GCdBPhYrwmNV4A4NyrnPEKaXP8O/2p9bc6FLk9g== X-Received: by 2002:a05:6a00:1507:: with SMTP id q7mr15365218pfu.131.1593468415659; Mon, 29 Jun 2020 15:06:55 -0700 (PDT) Received: from [192.168.178.20] (203.90.69.111.dynamic.snap.net.nz. [111.69.90.203]) by smtp.gmail.com with ESMTPSA id s23sm575509pfs.157.2020.06.29.15.06.53 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 29 Jun 2020 15:06:55 -0700 (PDT) To: William Atwood , anima@ietf.org References: <159296586835.337.577109779817720457@ietfa.amsl.com> <16876f80-5504-a622-f13c-686ce69b4733@sandelman.ca> <86736d02-d1b6-ebfb-a894-92c9ca4b1e96@concordia.ca> From: Brian E Carpenter Message-ID: <1d463beb-ba42-9495-0c53-58116b6f3a57@gmail.com> Date: Tue, 30 Jun 2020 10:06:51 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <86736d02-d1b6-ebfb-a894-92c9ca4b1e96@concordia.ca> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Anima] "virtual out-of-band" ... or some minor non-ACP-number comments on Action: draft-ietf-anima-autonomic-control-plane-25.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2020 22:06:58 -0000 Say "secure overlay" to emphasise the point, but yes. The draft I submitted yesterday "describes a simple method of forming an = ACP immediately above the transport layer" which is indeed precisely a se= cure overlay. Regards Brian On 30-Jun-20 00:45, William Atwood wrote: > Is "overlay" the right word? >=20 > I agree that it is physically in-band, and virtually out-of-band. Isn'= t > that the definition of "overlay"? >=20 > Bill >=20 > On 2020-06-28 11:02 p.m., Michael Richardson wrote: >> Attention This email originates from outside the concordia.ca domain. = // >> Ce courriel provient de l'exterieur du domaine de concordia.ca >> On 2020-06-23 10:31 p.m., internet-drafts@ietf.org wrote: >>> A diff from the previous version is available at: >>> >> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-anima-autonomic-control= -plane-25 >> >> >> yes, I read the diffs :-) >> >> -=C2=A0=C2=A0 This document describes a modular design for a self-form= ing, self- >> -=C2=A0=C2=A0 managing and self-protecting ACP, which is a virtual in-= band network >> -=C2=A0=C2=A0 designed to be as independent as possible of configurati= on, >> >> +=C2=A0=C2=A0 This document describes a modular design for a self-form= ing, self- >> +=C2=A0=C2=A0 managing and self-protecting ACP, which is a virtual out= -of-band >> +=C2=A0=C2=A0 network designed to be as independent as possible of con= figuration, >> >> This change from being a virtual in-band network to a virtual >> out-of-band network must have been in response to some comments... It >> seems a big change in some ways.=C2=A0 I guess it makes this text cons= istent >> with the abstract which has said virtual out-of-band for awhile now. >> >> But, I do have to wonder if we are creating confusion by claiming that= >> this is an out-of-band mechanism, even though it's really an in-band >> mechanism.=C2=A0 It's just virtually-out. >> >> I actually do want to start a bike-shed issue here? >> Are we describing ourself wrong?=C2=A0 Maybe there is some portmanteau= that >> would be more accurate?=C2=A0 I think that the above sentence is essen= tially >> the elevator pitch for all of ANIMA. >> >> >> There is also a bunch of other text that has been added to the >> Introduction, which I think confuses more than it enlightens. >> Or at least needs a better copy-edit. >> >> A number of other new sections (9.4..) need a copy-edit to fix some >> missing words.=C2=A0 I will try to help Toerless with that via github.= >> >> _______________________________________________ >> Anima mailing list >> Anima@ietf.org >> https://www.ietf.org/mailman/listinfo/anima >> >=20 From nobody Mon Jun 29 23:27:21 2020 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51CF13A0B5F for ; Mon, 29 Jun 2020 23:27:19 -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, FREEMAIL_FROM=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 jwqddxojbPRD for ; Mon, 29 Jun 2020 23:27:17 -0700 (PDT) Received: from mail-wr1-x42d.google.com (mail-wr1-x42d.google.com [IPv6:2a00:1450:4864:20::42d]) (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 A5BBB3A0B5D for ; Mon, 29 Jun 2020 23:27:17 -0700 (PDT) Received: by mail-wr1-x42d.google.com with SMTP id f18so10817498wrs.0 for ; Mon, 29 Jun 2020 23:27:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:to:references:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=3X86dhrLylX3ESAizyyzWIjPdFs15DKUBKNYzybp1g4=; b=bfYxeHK39J/ZuMx+mA50Jz0olLtUEoqw/9hQY57GH6zg7eRszLC6B1ExgqtN8OmI++ SuAnkeHeQKFax4d+W8stZ0IzAqJmM1QdE5BBt/KWxIOwowPnTTymFisCZC655VtM+siD LfKZpSVNfjF0w26Msu3xKXPp7D0N/4iiaRzlO6K7aGR3ygt1UJEbvfWN1CS+fbL45x/e 40CXcHt6UMPRSADqI7inBkcHcXxtwcF6TurfO6oSkVgLehRas+R3RFe3qGO//EhBfZfh Ygtz463tko/wc9KmFCLVmNCqo6d/Zkoxz9XuyTz2+Dim/Fgl+eihr1t3RXXB0SA2yoL/ SGMQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:references:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=3X86dhrLylX3ESAizyyzWIjPdFs15DKUBKNYzybp1g4=; b=O2GTXA5dcNrzq68OSZkCWa2/kuW2KeJjvzpyvt60WVHu6/kaXF81sEsqBBVeq+aYqq sG+zNcwSEU92cllKOfvOquGcfobz9uuve/HluQSIOhcpg6J84vpxWNKpfjrqja4jnSMV 1Pp7pfFOO3jCl/KGFHZVLWLsmrVymYUp2sBCsu+c4VP5ARNFZmbX7cRTDQwzI8Jj48q9 q8pWXWLMcUx+50Dqlnc5pRiDFxtwxbpN4eyePObMECPahCxTMG9HdbFKUFbnW6qSArCN +Lr9VuJUva0j5NWhiz5x4kugRonjyfYNEUAXWSFDm60M6RMk/3tJERfdpXSbNzmeXZ2p hNyQ== X-Gm-Message-State: AOAM532fdMm0orbcF9UdNP6Z6XXYBVyrv7WxdPrYjQxTBFgldEJs6gyw agL72BSSj9dv5ehx92mE7m57Wxh/ X-Google-Smtp-Source: ABdhPJzqMl8eJF7s0RC/8WuyAz+huQApH6AYHqqePIyo46kGj5wnbiBW5G+cPlA0S6mnfFuRlBBrZA== X-Received: by 2002:adf:e948:: with SMTP id m8mr20834313wrn.398.1593498435602; Mon, 29 Jun 2020 23:27:15 -0700 (PDT) Received: from ?IPv6:2a01:cb1d:111:eb00:1435:bf0f:6f62:1e20? ([2a01:cb1d:111:eb00:1435:bf0f:6f62:1e20]) by smtp.gmail.com with ESMTPSA id l14sm2413462wrn.18.2020.06.29.23.27.14 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 29 Jun 2020 23:27:14 -0700 (PDT) From: "Michael H. Behringer" X-Google-Original-From: "Michael H. Behringer" To: anima@ietf.org References: <159296586835.337.577109779817720457@ietfa.amsl.com> <16876f80-5504-a622-f13c-686ce69b4733@sandelman.ca> <86736d02-d1b6-ebfb-a894-92c9ca4b1e96@concordia.ca> <1d463beb-ba42-9495-0c53-58116b6f3a57@gmail.com> Message-ID: <3528e4d5-4eb8-0e9f-6fe1-49494e9fcd54@gmail.com> Date: Tue, 30 Jun 2020 08:27:14 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <1d463beb-ba42-9495-0c53-58116b6f3a57@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-GB Archived-At: Subject: Re: [Anima] "virtual out-of-band" ... or some minor non-ACP-number comments on Action: draft-ietf-anima-autonomic-control-plane-25.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2020 06:27:19 -0000 I still prefer the definition "virtual out of band". An "overlay" (secure or not) depends on correct configuration of the underlay. The ACP does NOT depend on configuration in the underlay, that is what makes it special. I haven't seen the definition "virtual out of band" anywhere else, and it is the most precise way to describe it. Michael On 30/06/2020 00:06, Brian E Carpenter wrote: > Say "secure overlay" to emphasise the point, but yes. > > The draft I submitted yesterday "describes a simple method of forming an ACP immediately above the transport layer" which is indeed precisely a secure overlay. > > Regards > Brian > > On 30-Jun-20 00:45, William Atwood wrote: >> Is "overlay" the right word? >> >> I agree that it is physically in-band, and virtually out-of-band. Isn't >> that the definition of "overlay"? >> >> Bill >> >> On 2020-06-28 11:02 p.m., Michael Richardson wrote: >>> Attention This email originates from outside the concordia.ca domain. // >>> Ce courriel provient de l'exterieur du domaine de concordia.ca >>> On 2020-06-23 10:31 p.m., internet-drafts@ietf.org wrote: >>>> A diff from the previous version is available at: >>>> >>> https://www.ietf.org/rfcdiff?url2=draft-ietf-anima-autonomic-control-plane-25 >>> >>> >>> yes, I read the diffs :-) >>> >>> -   This document describes a modular design for a self-forming, self- >>> -   managing and self-protecting ACP, which is a virtual in-band network >>> -   designed to be as independent as possible of configuration, >>> >>> +   This document describes a modular design for a self-forming, self- >>> +   managing and self-protecting ACP, which is a virtual out-of-band >>> +   network designed to be as independent as possible of configuration, >>> >>> This change from being a virtual in-band network to a virtual >>> out-of-band network must have been in response to some comments... It >>> seems a big change in some ways.  I guess it makes this text consistent >>> with the abstract which has said virtual out-of-band for awhile now. >>> >>> But, I do have to wonder if we are creating confusion by claiming that >>> this is an out-of-band mechanism, even though it's really an in-band >>> mechanism.  It's just virtually-out. >>> >>> I actually do want to start a bike-shed issue here? >>> Are we describing ourself wrong?  Maybe there is some portmanteau that >>> would be more accurate?  I think that the above sentence is essentially >>> the elevator pitch for all of ANIMA. >>> >>> >>> There is also a bunch of other text that has been added to the >>> Introduction, which I think confuses more than it enlightens. >>> Or at least needs a better copy-edit. >>> >>> A number of other new sections (9.4..) need a copy-edit to fix some >>> missing words.  I will try to help Toerless with that via github. >>> >>> _______________________________________________ >>> Anima mailing list >>> Anima@ietf.org >>> https://www.ietf.org/mailman/listinfo/anima >>> > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima From nobody Tue Jun 30 00:13:46 2020 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8D0F3A10D7 for ; Tue, 30 Jun 2020 00:13:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-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 CnaGtEBtAgLL for ; Tue, 30 Jun 2020 00:13:43 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 A0F643A10D6 for ; Tue, 30 Jun 2020 00:13:43 -0700 (PDT) Received: from lhreml712-chm.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 35F4F98C7441B1500EF9; Tue, 30 Jun 2020 08:13:42 +0100 (IST) Received: from fraeml745-chm.china.huawei.com (10.206.15.226) by lhreml712-chm.china.huawei.com (10.201.108.63) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Tue, 30 Jun 2020 08:13:42 +0100 Received: from fraeml735-chm.china.huawei.com (10.206.15.216) by fraeml745-chm.china.huawei.com (10.206.15.226) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Tue, 30 Jun 2020 09:13:41 +0200 Received: from fraeml735-chm.china.huawei.com ([10.206.15.216]) by fraeml735-chm.china.huawei.com ([10.206.15.216]) with mapi id 15.01.1913.007; Tue, 30 Jun 2020 09:13:41 +0200 From: Artur Hecker To: "anima@ietf.org" CC: "Michael H. Behringer" Thread-Topic: [Anima] "virtual out-of-band" ... or some minor non-ACP-number comments on Action: draft-ietf-anima-autonomic-control-plane-25.txt Thread-Index: AQHWTcK7qwOSY00hqUizYkzLoGHsyqjvaVQAgACczYCAAIvPAIAALOcg Date: Tue, 30 Jun 2020 07:13:41 +0000 Message-ID: <563764486139436e82b048917c95a92b@huawei.com> References: <159296586835.337.577109779817720457@ietfa.amsl.com> <16876f80-5504-a622-f13c-686ce69b4733@sandelman.ca> <86736d02-d1b6-ebfb-a894-92c9ca4b1e96@concordia.ca> <1d463beb-ba42-9495-0c53-58116b6f3a57@gmail.com> <3528e4d5-4eb8-0e9f-6fe1-49494e9fcd54@gmail.com> In-Reply-To: <3528e4d5-4eb8-0e9f-6fe1-49494e9fcd54@gmail.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.221.98.57] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Anima] "virtual out-of-band" ... or some minor non-ACP-number comments on Action: draft-ietf-anima-autonomic-control-plane-25.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2020 07:13:46 -0000 SGkNCg0KDQpJIHN1cHBvcnQgTWljaGFlbCdzIHZpZXcgYmVsb3cuICJWaXJ0dWFsbHkgb3V0IG9m IGJhbmQiIGlzIG5vdCAoYW55bW9yZSkgdGhlIHNhbWUgYXMgIm92ZXJsYXkiLiBPdmVybGF5cyBh cmUgdXN1YWxseSAiYmxpbmQiIHdpdGggcmVnYXJkIHRvIHRoZSBpbmZyYXN0cnVjdHVyZSBhbmQg ZXhoaWJpdCBjb25zaWRlcmFibGUgc3RyZXRjaC4NCg0KV2l0aCBTRE4gYW5kIHByb2dyYW1tYWJs ZSBpbmZyYXN0cnVjdHVyZXMgKGFuZCBpZGVtIHdpdGggQVNBcyBvbiBldmVyeSBub2RlKSwgaXQn cyBwb3NzaWJsZSB0byBkZXBsb3kgQUNQIHZpcnR1YWxseSBvdXQgb2YgYmFuZCAoc2VjdXJlIG9y IG5vdCkgaW4gcGFyYWxsZWwgdG8gYW55IG90aGVyIHRyYWZmaWMgYW5kIHlldCB3aXRoIGRpc3Rp bmN0bHkgZGlmZmVyZW50IHN0cnVjdHVyZSwgZm9yd2FyZGluZyBydWxlcywgcXVldWVzLCBldGMu IFRoaXMgaXMgYSBwb3dlcmZ1bCBjb25jZXB0IHRvIHJlc29sdmUgcHJvYmxlbXMgd2l0aCByYWRp Y2FsbHkgZGlmZmVyZW50IGRlbnNpdGllcyB0aGF0IHdlIGZhY2Ugd2hlbiBtaXhpbmcgdmlydHVh bCBhbmQgcGh5c2ljYWwgbm9kZXMuDQoNCg0KUmVnYXJkcw0KQXJ0dXINCg0KDQo+IC0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IEFuaW1hIDxhbmltYS1ib3VuY2VzQGlldGYub3Jn PiBPbiBCZWhhbGYgT2YgTWljaGFlbCBILiBCZWhyaW5nZXINCj4gU2VudDogVHVlc2RheSwgSnVu ZSAzMCwgMjAyMCA4OjI3IEFNDQo+IFRvOiBhbmltYUBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTog W0FuaW1hXSAidmlydHVhbCBvdXQtb2YtYmFuZCIgLi4uIG9yIHNvbWUgbWlub3Igbm9uLUFDUC0N Cj4gbnVtYmVyIGNvbW1lbnRzIG9uIEFjdGlvbjogZHJhZnQtaWV0Zi1hbmltYS1hdXRvbm9taWMt Y29udHJvbC1wbGFuZS0NCj4gMjUudHh0DQo+IA0KPiBJIHN0aWxsIHByZWZlciB0aGUgZGVmaW5p dGlvbiAidmlydHVhbCBvdXQgb2YgYmFuZCIuDQo+IA0KPiBBbiAib3ZlcmxheSIgKHNlY3VyZSBv ciBub3QpIGRlcGVuZHMgb24gY29ycmVjdCBjb25maWd1cmF0aW9uIG9mIHRoZQ0KPiB1bmRlcmxh eS4gVGhlIEFDUCBkb2VzIE5PVCBkZXBlbmQgb24gY29uZmlndXJhdGlvbiBpbiB0aGUgdW5kZXJs YXksIHRoYXQgaXMNCj4gd2hhdCBtYWtlcyBpdCBzcGVjaWFsLg0KPiANCj4gSSBoYXZlbid0IHNl ZW4gdGhlIGRlZmluaXRpb24gInZpcnR1YWwgb3V0IG9mIGJhbmQiIGFueXdoZXJlIGVsc2UsIGFu ZCBpdCBpcyB0aGUNCj4gbW9zdCBwcmVjaXNlIHdheSB0byBkZXNjcmliZSBpdC4NCj4gDQo+IE1p Y2hhZWwNCj4gDQo+IE9uIDMwLzA2LzIwMjAgMDA6MDYsIEJyaWFuIEUgQ2FycGVudGVyIHdyb3Rl Og0KPiA+IFNheSAic2VjdXJlIG92ZXJsYXkiIHRvIGVtcGhhc2lzZSB0aGUgcG9pbnQsIGJ1dCB5 ZXMuDQo+ID4NCj4gPiBUaGUgZHJhZnQgSSBzdWJtaXR0ZWQgeWVzdGVyZGF5ICJkZXNjcmliZXMg YSBzaW1wbGUgbWV0aG9kIG9mIGZvcm1pbmcgYW4NCj4gQUNQIGltbWVkaWF0ZWx5IGFib3ZlIHRo ZSB0cmFuc3BvcnQgbGF5ZXIiIHdoaWNoIGlzIGluZGVlZCBwcmVjaXNlbHkgYQ0KPiBzZWN1cmUg b3ZlcmxheS4NCj4gPg0KPiA+IFJlZ2FyZHMNCj4gPiAgICAgQnJpYW4NCj4gPg0KPiA+IE9uIDMw LUp1bi0yMCAwMDo0NSwgV2lsbGlhbSBBdHdvb2Qgd3JvdGU6DQo+ID4+IElzICJvdmVybGF5IiB0 aGUgcmlnaHQgd29yZD8NCj4gPj4NCj4gPj4gSSBhZ3JlZSB0aGF0IGl0IGlzIHBoeXNpY2FsbHkg aW4tYmFuZCwgYW5kIHZpcnR1YWxseSBvdXQtb2YtYmFuZC4NCj4gPj4gSXNuJ3QgdGhhdCB0aGUg ZGVmaW5pdGlvbiBvZiAib3ZlcmxheSI/DQo+ID4+DQo+ID4+ICAgIEJpbGwNCj4gPj4NCj4gPj4g T24gMjAyMC0wNi0yOCAxMTowMiBwLm0uLCBNaWNoYWVsIFJpY2hhcmRzb24gd3JvdGU6DQo+ID4+ PiBBdHRlbnRpb24gVGhpcyBlbWFpbCBvcmlnaW5hdGVzIGZyb20gb3V0c2lkZSB0aGUgY29uY29y ZGlhLmNhDQo+ID4+PiBkb21haW4uIC8vIENlIGNvdXJyaWVsIHByb3ZpZW50IGRlIGwnZXh0ZXJp ZXVyIGR1IGRvbWFpbmUgZGUNCj4gPj4+IGNvbmNvcmRpYS5jYSBPbiAyMDIwLTA2LTIzIDEwOjMx IHAubS4sIGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyB3cm90ZToNCj4gPj4+PiBBIGRpZmYgZnJv bSB0aGUgcHJldmlvdXMgdmVyc2lvbiBpcyBhdmFpbGFibGUgYXQ6DQo+ID4+Pj4NCj4gPj4+IGh0 dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLWFuaW1hLWF1dG9ub21p Yy1jb250cm9sDQo+ID4+PiAtcGxhbmUtMjUNCj4gPj4+DQo+ID4+Pg0KPiA+Pj4geWVzLCBJIHJl YWQgdGhlIGRpZmZzIDotKQ0KPiA+Pj4NCj4gPj4+IC3CoMKgIFRoaXMgZG9jdW1lbnQgZGVzY3Jp YmVzIGEgbW9kdWxhciBkZXNpZ24gZm9yIGEgc2VsZi1mb3JtaW5nLA0KPiA+Pj4gc2VsZi0NCj4g Pj4+IC3CoMKgIG1hbmFnaW5nIGFuZCBzZWxmLXByb3RlY3RpbmcgQUNQLCB3aGljaCBpcyBhIHZp cnR1YWwgaW4tYmFuZA0KPiA+Pj4gbmV0d29yaw0KPiA+Pj4gLcKgwqAgZGVzaWduZWQgdG8gYmUg YXMgaW5kZXBlbmRlbnQgYXMgcG9zc2libGUgb2YgY29uZmlndXJhdGlvbiwNCj4gPj4+DQo+ID4+ PiArwqDCoCBUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyBhIG1vZHVsYXIgZGVzaWduIGZvciBhIHNl bGYtZm9ybWluZywNCj4gPj4+ICtzZWxmLQ0KPiA+Pj4gK8KgwqAgbWFuYWdpbmcgYW5kIHNlbGYt cHJvdGVjdGluZyBBQ1AsIHdoaWNoIGlzIGEgdmlydHVhbCBvdXQtb2YtYmFuZA0KPiA+Pj4gK8Kg wqAgbmV0d29yayBkZXNpZ25lZCB0byBiZSBhcyBpbmRlcGVuZGVudCBhcyBwb3NzaWJsZSBvZg0K PiA+Pj4gK2NvbmZpZ3VyYXRpb24sDQo+ID4+Pg0KPiA+Pj4gVGhpcyBjaGFuZ2UgZnJvbSBiZWlu ZyBhIHZpcnR1YWwgaW4tYmFuZCBuZXR3b3JrIHRvIGEgdmlydHVhbA0KPiA+Pj4gb3V0LW9mLWJh bmQgbmV0d29yayBtdXN0IGhhdmUgYmVlbiBpbiByZXNwb25zZSB0byBzb21lIGNvbW1lbnRzLi4u DQo+ID4+PiBJdCBzZWVtcyBhIGJpZyBjaGFuZ2UgaW4gc29tZSB3YXlzLsKgIEkgZ3Vlc3MgaXQg bWFrZXMgdGhpcyB0ZXh0DQo+ID4+PiBjb25zaXN0ZW50IHdpdGggdGhlIGFic3RyYWN0IHdoaWNo IGhhcyBzYWlkIHZpcnR1YWwgb3V0LW9mLWJhbmQgZm9yIGF3aGlsZQ0KPiBub3cuDQo+ID4+Pg0K PiA+Pj4gQnV0LCBJIGRvIGhhdmUgdG8gd29uZGVyIGlmIHdlIGFyZSBjcmVhdGluZyBjb25mdXNp b24gYnkgY2xhaW1pbmcNCj4gPj4+IHRoYXQgdGhpcyBpcyBhbiBvdXQtb2YtYmFuZCBtZWNoYW5p c20sIGV2ZW4gdGhvdWdoIGl0J3MgcmVhbGx5IGFuDQo+ID4+PiBpbi1iYW5kIG1lY2hhbmlzbS7C oCBJdCdzIGp1c3QgdmlydHVhbGx5LW91dC4NCj4gPj4+DQo+ID4+PiBJIGFjdHVhbGx5IGRvIHdh bnQgdG8gc3RhcnQgYSBiaWtlLXNoZWQgaXNzdWUgaGVyZT8NCj4gPj4+IEFyZSB3ZSBkZXNjcmli aW5nIG91cnNlbGYgd3Jvbmc/wqAgTWF5YmUgdGhlcmUgaXMgc29tZSBwb3J0bWFudGVhdQ0KPiA+ Pj4gdGhhdCB3b3VsZCBiZSBtb3JlIGFjY3VyYXRlP8KgIEkgdGhpbmsgdGhhdCB0aGUgYWJvdmUg c2VudGVuY2UgaXMNCj4gPj4+IGVzc2VudGlhbGx5IHRoZSBlbGV2YXRvciBwaXRjaCBmb3IgYWxs IG9mIEFOSU1BLg0KPiA+Pj4NCj4gPj4+DQo+ID4+PiBUaGVyZSBpcyBhbHNvIGEgYnVuY2ggb2Yg b3RoZXIgdGV4dCB0aGF0IGhhcyBiZWVuIGFkZGVkIHRvIHRoZQ0KPiA+Pj4gSW50cm9kdWN0aW9u LCB3aGljaCBJIHRoaW5rIGNvbmZ1c2VzIG1vcmUgdGhhbiBpdCBlbmxpZ2h0ZW5zLg0KPiA+Pj4g T3IgYXQgbGVhc3QgbmVlZHMgYSBiZXR0ZXIgY29weS1lZGl0Lg0KPiA+Pj4NCj4gPj4+IEEgbnVt YmVyIG9mIG90aGVyIG5ldyBzZWN0aW9ucyAoOS40Li4pIG5lZWQgYSBjb3B5LWVkaXQgdG8gZml4 IHNvbWUNCj4gPj4+IG1pc3Npbmcgd29yZHMuwqAgSSB3aWxsIHRyeSB0byBoZWxwIFRvZXJsZXNz IHdpdGggdGhhdCB2aWEgZ2l0aHViLg0KPiA+Pj4NCj4gPj4+IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4+PiBBbmltYSBtYWlsaW5nIGxpc3QNCj4g Pj4+IEFuaW1hQGlldGYub3JnDQo+ID4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2FuaW1hDQo+ID4+Pg0KPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQo+ID4gQW5pbWEgbWFpbGluZyBsaXN0DQo+ID4gQW5pbWFAaWV0Zi5v cmcNCj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2FuaW1hDQo+IA0K PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBBbmlt YSBtYWlsaW5nIGxpc3QNCj4gQW5pbWFAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9hbmltYQ0K From nobody Tue Jun 30 01:33:43 2020 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DA783A0EC8 for ; Tue, 30 Jun 2020 01:33:42 -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 i9qjBCXi5WT4 for ; Tue, 30 Jun 2020 01:33:40 -0700 (PDT) Received: from iramx2.ira.uni-karlsruhe.de (iramx2.ira.uni-karlsruhe.de [IPv6:2a00:1398:2::10:81]) (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 5A94D3A1101 for ; Tue, 30 Jun 2020 01:33:37 -0700 (PDT) Received: from i72vorta.tm.uni-karlsruhe.de ([141.3.71.26] helo=i72vorta.tm.kit.edu) by iramx2.ira.uni-karlsruhe.de with esmtpsa port 25 iface 141.3.10.8 id 1jqBhu-0007Fp-QP; Tue, 30 Jun 2020 10:33:34 +0200 Received: from [IPv6:::1] (ip6-localhost [IPv6:::1]) by i72vorta.tm.kit.edu (Postfix) with ESMTPS id AEB6042046C; Tue, 30 Jun 2020 10:33:34 +0200 (CEST) To: "Michael H. Behringer" , anima@ietf.org References: <159296586835.337.577109779817720457@ietfa.amsl.com> <16876f80-5504-a622-f13c-686ce69b4733@sandelman.ca> <86736d02-d1b6-ebfb-a894-92c9ca4b1e96@concordia.ca> <1d463beb-ba42-9495-0c53-58116b6f3a57@gmail.com> <3528e4d5-4eb8-0e9f-6fe1-49494e9fcd54@gmail.com> From: "Bless, Roland (TM)" Autocrypt: addr=roland.bless@kit.edu; prefer-encrypt=mutual; keydata= LS0tLS1CRUdJTiBQR1AgUFVCTElDIEtFWSBCTE9DSy0tLS0tCgptUUlOQkZpME94QUJFQUN5 MlZvaEo3VmhTdS94UEN0NC82cUNydzRQdzJuU2tsV1BmQVlFazFRZ3JiaXdndkxBClA5V0Vo QUlVdzQ1Y29qQmFEeHl0SUdnOGVhWWVJS1Ntc1hqSEdiVi9aVGZvOHIxMUxYOHlQWVIwV0hp TVdacGwKMFNIVWQvQ1pJa3YycENoTzg4dkYvMkZLTjk1SERjcDI0cHdPTkY0Vmh4Sm9TRms2 YzBtRE5mOEVtL0dsdDlCYwpXWDJBQXZpelRtcFFEc2hhUGplMThXSDM0KytLd1BaRGQvc0ov aEhTWGlQZzFHZGhzL09HL0MwQ0pndU9BbHFiCmdTVkFlM3FLT3IxTTRLNU0rd1Zwc2szNzNw WFJmeGQ3WkFtWjA1aUJUbitMZmdWY3orQWZhS0tjc1dyaTVDZFQKVCs3SkRMNlFOUXBveCti NUZYWkZTSG5FSVNUKy9xemZHN0cyTHFxWW1tbDZUWVk4WGJhTnlYWlAwUUtuY2ZTcApSeDh1 VFJXUmVIVWExWWJTdU94WFloNmJYcGN1Z0QyNW1sQy9MdTBnN3R6NGlqaUtpSXdxOStQMkgx S2ZBQWZZCnlZWmg2bk9vRTZFVDBUak9qVVNhK21BOGNxalBXWDk5a0VFZ2YxWG8rUDlmeDlR TENMV0lZN3pjbVNNK3ZqUUsKZ2RVRnBNU0NLY1lFS091d2xQdU96OGJWRUNhZnhhRXRKSkhq Q09LOHpvd2UyZUM5T00rRytibXRBTzNxWWNZWgpoUS9QVjNzenR0L1BqZ2R0bkZBWVBGTGM5 MTg5ckhSeEtzV1NPYjR4UGtSdy9ZUUFJOWwxNU9sVUVwc3lPZWh4Cm1BbVRzZXNudFNWaUN6 KytQQ2RlWHJRYzFCQ2dsOG5EeXRyeFcrbjV3MWFhRThhTDNobjhNMHRvblFBUkFRQUIKdENG U2IyeGhibVFnUW14bGMzTWdLRlJOS1NBOFlteGxjM05BYTJsMExtVmtkVDZKQWowRUV3RUlB Q2NGQWxpMQpmTHdDR3dNRkNSTE1Bd0FGQ3drSUJ3SUdGUWdKQ2dzQ0JCWUNBd0VDSGdFQ0Y0 QUFDZ2tRbzQzYTJXUTRsZTRsCkp3Ly9SNlgvSVY3Zmllem1ZRFZtNHpzM05Fb1hHdGdPdDBP bnk0MFNaS0xZVW9vc3pBSWFBZHNQU2lDenhTSHgKTmEwZnpGZWtYd0YxNWtjWC82cXdEUnJq d1Y0R2F2YWFSeUt3cUdOeTlvOU4ySHh6aXU1dUo1UWthaC9qS2prSwovTzlXclY2NnFuRmVX cWFzRVVSakNDMlR6WCtJSllFT0F4U0xmSnY5STFocHdrV2dZUzdWdVZjQkg2VDBPb2RkCmM3 YnovK1YzMmQ2VjdiNXFLRldJSzJaeXluMXJsRHlHSXh0bTZiTi9Ed2RtYzNCelRVN2hlNlV3 VW10NlAxTlcKc0V3K2RVK0F4TE1VcTJJTTV2eVB3NDJPMytmZkFkZ0xpNkhTV0NwV3NxNDlN bFZsSzZIUThOenI3eGtkek1lLwpwV0pLa2JMKzZZTWpZRjVESENTT3l4ZTNDZWNKODRDZFFR Y3o2TERySWhHSnI0VGR3eU54K2J6WUhJTUg1Zkp0Cmk5eDVWY0hHV1NaZnZDcXJVTDg5U3VG RHBEa0p3QlVkVm9ITUZlWXEwbGZtcUVYZ0tzdld1U3JHREIxYlhhTi8KZUdFTW9EbWd3NXpz b0ZJN1dERksvQ0doMnl1bUhmclBnTXVGNUwzNVhsZC83MFlIenRuR2lpS2pqSW40RHBjagpO WnhiZUlXcUJZVklIOEErRXFZVy91MmlrK1loT0U2d0JhQy92Z3krYkhkcVZCcE96VVp6THpu L1BRZ2xKUkpNCmRkRlV0SXRnWThESFRQbFVMKzQ4ckluZFRrek5zaEg1ZUdSWnJISDRMenFX aDdqY0p5U1Y3M3NyWG1nYzNZZVEKMnlzT3RFMVVIQ04vREF4aklpTFU0RUh2b0pkdE51dCsw SzA0R0tyc2liQ3FrdiswSGxKdmJHRnVaQ0JDYkdWegpjeUE4Y205c1lXNWtRR0pzWlhOekxt UmxQb2tDUFFRVEFRZ0FKd1VDV0xRN0VBSWJBd1VKRXN3REFBVUxDUWdICkFnWVZDQWtLQ3dJ RUZnSURBUUllQVFJWGdBQUtDUkNqamRyWlpEaVY3anY1RC93TlZnOFFKV3BkeXFPMThoZjcK TjVUSUFyZ1EzWWtCUXloVXZYKzh6Y1RsZjJ0UzM0TDV5dkN3eTU2YUV3a3lDbHU1bTBlZmhz bmh0Tkg4K3hNbgo0czlEMnZycS9XZzhQemNBdE5ld2dZeklrVENsdStHSjgrQkNlaEhVSHJ6 K1IvazRrSVo2QTR5WVhtWXVydGJJClRnQndOUVJKSFBzY2NqZnYzbkJoRDQ0UldsNkt4ZGF4 NUloaEwydS9IeitERHo1bzh2b3I0TU9ZNmFsS3RnSW0KTUJZc0p1aGc1bGg4c2FqRlBrM2pn NCsvUEVjdGtsNmJXTnV0R3lHWE1EZGJyQXlZNzgxMjk3V1ZKK0ZkekFkVAo5QzU3bHBYMk5t UUZURTQ1aWZFaUM3Tlh2aFB3SDJQeFh6TGJqeE1pSnJtT1pUcVllQzAyZXkyRE9SclFMTjlm ClNKSTRmNXRwVm5mK2cwTXB5K0xWQm5tcVoxSnNocmtRaUJkNlZxUi9YbVR0Q3o5NElBTGg5 YXFGakxabFM0QjkKR0JnT2dYNEVkcHFLVGU0cHVSaFFMU21pSVA0bHBsS3p4U1dod2piYjI0 V2xJcFRHQlhVUmFlMXh6UGJNN05HagpFZUhFVjF5UEkwU3NERkNGQXZ0UHNnRW5wT1VWQjNk b2pDeE80dStxZjR5bGFScXZ6dkFzbis2ZklPZkpVY3pnCjNqUGNRWWpvMnFFNzJvUnAzaS81 NWp6L2hlLzlsOFNpQmRRdk15NThuQW1WYjV1ZXBlZTRMaklvRXlwTWRmdmIKa203bENTdHJG WWdlcVFTYjZYZ2hnNEUwU1hMK2pCa2tWTk1WOU9lQVE4anJ5SEFjWTYwcndFcjFmaWhPaW9s WgpaWmM1eXdHcmVvK1g1cXUyL242VU1CYXFFclFvVW05c1lXNWtJRUpzWlhOeklDaFVUU2tn UEhKdmJHRnVaQzVpCmJHVnpjMEJyYVhRdVpXUjFQb2tDUUFRVEFRZ0FLZ0liQXdVSkVzd0RB QVVMQ1FnSEFnWVZDQWtLQ3dJRUZnSUQKQVFJZUFRSVhnQVVDV0xXSFJ3SVpBUUFLQ1JDampk clpaRGlWN3MxcEQvc0g0MUp3emMwWnVLOStHZ0RGbnFYRQpNNGs0S24rQ05YSzNDK2xRK09P K3V4NGNoYkkzQ2g5OVJPUnVZRXc4VzZiRE9LWnBJSVNuaTY2VDZOOUdDdDZtCit4UFlueUpL U1U3ekx0RXJVbEpuRjZ0TXo4aDJmaDhSM2pGcEtMSll4dDRQK0dIcEFxb0ZzS3dldGsrelRH S3QKQUUwSHRUQmdtVXdEOEVqeGdsR1U5NHFLdWRQTk5CVENQS0pKQmsxMHQ0ZGxQZHRucHU1 UEs3K3hOK1Bic25iOQpmV0JIRXU3U08vS1lJREhXcVFFcUQ5MEZnZE43Y3p5c0k2a0trbnI4 dXVMaWd4R3RGSUx3RE56MFd5Y1RtR1pWCjlYTjZ2d25Wc0tjSUZJZ0lUTFQxcjJyMWxrM01P aXBKT250SU1PS0JaUTBQb1dhS0M3K2E1V0VkM29IVmVBejIKZGJvQytkYnRNRUFrQnZhaWlE RjdKUUhaaW0wUTVCSEZoam90bTFnSFdNaUI0WVVCZVMwcm1tc1F0ajlyem1FUgo1eE9jcitT azFkMWU2WWhZRHhZeWcxdm9JZ2tYZTFSbjZIZWcyTm05c3M4SW5RakwzdFVMSnZQalJLeCts UG9UCktUQzNnaVF6THRUanIxMkd4WjA1S28zb09iQ29xVktFbllGN0NLT0pKZnFBSzJaYVNx Z3FKa2t6NFlvKzZ6TW4KcnY5WWpzR3pRbzdZcW9HK2VXUk94SkhmT0pxL2JHNnVDWnYrRUJw MVNOOUt1Rk5yM1JrbmpXMVk2SGRaNm8zOQoxRGN6OW1RdmgvY1k3QWhiaW1Hd2wrbU11RWty aEhMbTdYWm5RYXB0ZDZjYm11R2FqMGlOQTBFazlnaHd1NThTCjlRR2tSa1dHSWVjNk5yMFlO NHFaQkxrQ0RRUll0RHNRQVJBQXRnaVRhZFB5TDVMK0Nqb2w4WXJiREYyWGl2WHkKTkRWTmlW TmExdE9IVEN4ZXR5UmZBQllpZXFua2k5cGp4NkRJaS9ueHVZNWNjdE9kTVRIYVRDc1o0UTFY VE1jRAo3VEloc1d3Y243NjE3dGZQekFlNGZoTlF4MkZVWFJSVDJpOW80c1BnYjUrc0UwOTlU SXJodlZvZEZnSWFGdkkyClBDRjhTa0sxSiswRkRpckZvY3paYjFhVHFFb3pJbHVGbDVMRkFO QkVGVzVwYkpFdnpKeFRvQXEvS3Z4YXNBdk4KU2o4dmxTeHp3ZlN2d2V1YmtIYVdzTy9INHdJ RUZVS3FjUis0RkJkUkdLWFdWc3FJemZsZkI3U3ljZnZjbGdHWQowaFR1ZmR6aGQvNjlKd3h4 TW5Mam80WG53cTZxOUF3NEUyRkRiWVRuVkNqdGdzMCt6TGNIa2JRSDlKOXU4MjhLCkdMNUU3 NGlHMGZ0WlZkYnpaTVdsTFdlbnRhN1RzYjZKMFROVHQzWFJTTTBhZjBMbjdoM3ozdEdLb1JM S3dTQmwKdFdoUDZXVnZKSVRVSlFlcXJkdExKeS9YQlE2NXdldnZKQXh0M3Yvem95dFNBa0kv V1A4c3F5VldseW56MjNSNApTNmJJSWZFekF6NkIvbDEwSlF5Wll6QTlQdnY2TzNKRHQwbjJ2 R2JNb2RWbW04aWtBMkZ3NWc0SXZaUXFHa095CjM3aTFLYURMeVZmaEZxTkl4T0VWdjhBUmtH eXlhZWJyTXVZdEg0UVNyZzhMQ25TeHQ2amduK0hYcVNIRGJvMnUKbVptUjBVL3QwUlJZNzJm M1FJYXdscVVVOFdRRFpWcFMyYytvYlU2Q2JwUUdVQ1ErcFhLVmEreEZZQTEvOHVIRApjQ2hl L1hvRmx6d3p6cjBBRVFFQUFZa0NKUVFZQVFnQUR3VUNXTFE3RUFJYkRBVUpFc3dEQUFBS0NS Q2pqZHJaClpEaVY3cERLRC80elhvb0pZL0gzcHg5bG51MGlic2dhZlB1Uzk1L0hqY0g4R09R dVJ2bnJROUJPdjVaTGZ5WS8KVkhYVTJzOFhnZGVlSzFSVjBjNW5EZC9vUmdqbVlCZ01sZFRl M2ZNVE9uUWFrYlI1a1REN3VYMU1YMHFxelBhWgpxZ01Ob0pzd0h0SHM3VmIyalBzZWNlY1NB OWxtVG9qcXZIY2ZTamlxNldhSzNwSTdOeGhBTjFkY0pXZXpaTE1mCjZQQ21kT0lTM2luRWRh OU9zeEF5emY4Z1BoYy9DRDJ0Q3FxYm9heTlOZEcwQTRBSVh2YU9Vd05QM0RDYWNhUzYKaDRW OWdMUHVYRUFJU2d3N0ZpYnQ2QWMyVVpEZXg0ZngwNlZycTVrMEVVWjRpeGtub2k5TTNiWXBW MzZNTXNSbAp4K2tGb3R6R1dKcVRxdm5yYSs2T0JCaG01dG9wOGFWV3pQaldKbWliUGpBSXY4 K1c3RHY2d0FjSFRPY3JKdkljCkd3aHJmdGFCRERrY2pIRkpQN2tZM0pZRTJUTlRZUnFGNXRW Sit1L2tYb2J0T0l1d3dPbS9IWGRSL0FCWUdVanQKaCtDQ292dWNnQzNacVBuN1FpVXZOelgr bG91b1NaeWh2V2xrSXlpL3FwbWFnUkhMZnc5cmtTUmxnQkVWT2ZnOQpFY0RWZjR2WlVCUW1E WXh2VjAzc05BVDJHSndiUnhaYy9heVU2aG9RN3VMbTdwVXBHOFFDdDB5SlBGOHluVEwzCm45 N1ZmKzVpUXBuR2xXeWRtS0RWTFpIU2lZS0Rvb0NVekFWekVidUNHOHF0Ukl2bmZkSmNZYUl5 aXBYL2NvTHMKNmNaT1NtQlJsSXM2ZEhiYjNUYmwwUWJXSzhNOHBFdXJ3YzA1UzZoMmRLYnhv elgwMHI3cmpRPT0KPTVuZDYKLS0tLS1FTkQgUEdQIFBVQkxJQyBLRVkgQkxPQ0stLS0tLQo= Organization: Institute of Telematics, Karlsruhe Institute of Technology Message-ID: <9198c86b-4900-ebad-cbdd-33d96468b4f1@kit.edu> Date: Tue, 30 Jun 2020 10:33:34 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <3528e4d5-4eb8-0e9f-6fe1-49494e9fcd54@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 8bit X-ATIS-AV: ClamAV (iramx2.ira.uni-karlsruhe.de) X-ATIS-Checksum: v3zoCAcc32ckk X-ATIS-Timestamp: iramx2.ira.uni-karlsruhe.de esmtpsa 1593506014.866458507 Archived-At: Subject: Re: [Anima] "virtual out-of-band" ... or some minor non-ACP-number comments on Action: draft-ietf-anima-autonomic-control-plane-25.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2020 08:33:42 -0000 Hi, Am 30.06.20 um 08:27 schrieb Michael H. Behringer: > I still prefer the definition "virtual out of band". Me, too. Especially, if one reads RFC8368 it clearly makes the point that the DCN/OAM networks are normally out-of-band, whereas the GACP is realized as _in-band_ solution. So GACP and ACP are "virtually out-of-band". I think that the editorial change Michael Richardson referred to just fixed that, because "virtually in-band" would not be correct. An overlay is a very generic concept (e.g., IP is an overlay on top of layer 2 networks) and you can stack them on top of each other nearly infinitely. So overlays are nearly everywhere and I think it's also clear that ACP is a establishing a control overlay. > An "overlay" (secure or not) depends on correct configuration of the > underlay. The ACP does NOT depend on configuration in the underlay, that > is what makes it special. > > I haven't seen the definition "virtual out of band" anywhere else, and > it is the most precise way to describe it. Regards Roland > Michael > > On 30/06/2020 00:06, Brian E Carpenter wrote: >> Say "secure overlay" to emphasise the point, but yes. >> >> The draft I submitted yesterday "describes a simple method of forming >> an ACP immediately above the transport layer" which is indeed >> precisely a secure overlay. >> >> Regards >>     Brian >> >> On 30-Jun-20 00:45, William Atwood wrote: >>> Is "overlay" the right word? >>> >>> I agree that it is physically in-band, and virtually out-of-band.  Isn't >>> that the definition of "overlay"? >>> >>>    Bill >>> >>> On 2020-06-28 11:02 p.m., Michael Richardson wrote: >>>> Attention This email originates from outside the concordia.ca >>>> domain. // >>>> Ce courriel provient de l'exterieur du domaine de concordia.ca >>>> On 2020-06-23 10:31 p.m., internet-drafts@ietf.org wrote: >>>>> A diff from the previous version is available at: >>>>> >>>> https://www.ietf.org/rfcdiff?url2=draft-ietf-anima-autonomic-control-plane-25 >>>> >>>> >>>> >>>> yes, I read the diffs :-) >>>> >>>> -   This document describes a modular design for a self-forming, self- >>>> -   managing and self-protecting ACP, which is a virtual in-band >>>> network >>>> -   designed to be as independent as possible of configuration, >>>> >>>> +   This document describes a modular design for a self-forming, self- >>>> +   managing and self-protecting ACP, which is a virtual out-of-band >>>> +   network designed to be as independent as possible of configuration, >>>> >>>> This change from being a virtual in-band network to a virtual >>>> out-of-band network must have been in response to some comments... It >>>> seems a big change in some ways.  I guess it makes this text consistent >>>> with the abstract which has said virtual out-of-band for awhile now. >>>> >>>> But, I do have to wonder if we are creating confusion by claiming that >>>> this is an out-of-band mechanism, even though it's really an in-band >>>> mechanism.  It's just virtually-out. >>>> >>>> I actually do want to start a bike-shed issue here? >>>> Are we describing ourself wrong?  Maybe there is some portmanteau that >>>> would be more accurate?  I think that the above sentence is essentially >>>> the elevator pitch for all of ANIMA. >>>> >>>> >>>> There is also a bunch of other text that has been added to the >>>> Introduction, which I think confuses more than it enlightens. >>>> Or at least needs a better copy-edit. >>>> >>>> A number of other new sections (9.4..) need a copy-edit to fix some >>>> missing words.  I will try to help Toerless with that via github. From nobody Tue Jun 30 02:27:48 2020 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D191A3A1139 for ; Tue, 30 Jun 2020 02:27:45 -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 rcbnAZCo9KpQ for ; Tue, 30 Jun 2020 02:27:43 -0700 (PDT) Received: from mail-ed1-x531.google.com (mail-ed1-x531.google.com [IPv6:2a00:1450:4864:20::531]) (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 92D2D3A1135 for ; Tue, 30 Jun 2020 02:27:43 -0700 (PDT) Received: by mail-ed1-x531.google.com with SMTP id dm19so9244245edb.13 for ; Tue, 30 Jun 2020 02:27:43 -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=HVPR+HNwqusI1MKchpET6SD5dNPNFDkNKmvSGaRNfwI=; b=oQSaZLQx4lHyGIJFLSy8mJOfILkQJEBSrXXh2g8OU4NXKzGDkm8Sun33FfhcQzQ7OU FRKXY7vOP5YR+yqoqC+iPHiSOwvS6btrxokU0LRJeaaZir+HmQoK6D8NhYRQ+H6cRRzl S3I3LkT2GFEGCO2E45T3nrN/22HB3iDR5IlvwWeWABGSt3pTiTUobtee7wQ1KbtCJNV8 l5L7nfI9N8LwAx/NE9c/fdFoEP0W1o8blCSzIW+U+lq+2eXxkXxc4iZZWnf/chHxHcI/ +Y8JtDxxCQxG6KA+MdjmqomwoxR2a3iiyzqciQ9e3oydHEjAPWfXq4LITNxBxRZMTrcc kgNg== 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=HVPR+HNwqusI1MKchpET6SD5dNPNFDkNKmvSGaRNfwI=; b=YJFNBIfXJ7Jrl/tMHGW/+3PztzMRVnOIO0wM6JoLjUldLNZB8lF1hWr1hnUQxCN7kD 6e0Gd0l57HhEDmeqr8sKSfgSIm4D0WktL+hPVa7Owx1ToDOZ4OPWpCMK/jb6T6YEZqrI raJz2ZHB2T1L0IevnmcB+t4VG/pw1sJxRQ9yES//8YKMtN8UgauuOt6riWa961sqgCpf M562b9v0BuhM9M67llkOVqN5c7jfhdb3VAAjQzoR6+G87TswYkEW0Lh2NEsQgSmTDWnO ir9+YzEW4B8TkzSezuI2tyhyhRxxDbulgqzQSPJI7YPDrfQ5IzWC8QteYTFtwPFZAV/y rFig== X-Gm-Message-State: AOAM530k5mBANGBYcq4Eog3n+JxSpFkAfkHBQGlYO1EkW4ffcI4mkylV o/8a6BH5dTiKYYSrfrb324g9M+8c2u9DJj7kv1o= X-Google-Smtp-Source: ABdhPJxbI2qY2P967QFDJWa+xLNvXSyXW5uyn5xzxcfYfJX9ccN9Zo9DZJoki8ZynhmJknBULxut1dXWnzoAR9DfCZQ= X-Received: by 2002:a05:6402:947:: with SMTP id h7mr22104581edz.213.1593509262060; Tue, 30 Jun 2020 02:27:42 -0700 (PDT) MIME-Version: 1.0 References: <159296586835.337.577109779817720457@ietfa.amsl.com> <16876f80-5504-a622-f13c-686ce69b4733@sandelman.ca> <86736d02-d1b6-ebfb-a894-92c9ca4b1e96@concordia.ca> <1d463beb-ba42-9495-0c53-58116b6f3a57@gmail.com> <3528e4d5-4eb8-0e9f-6fe1-49494e9fcd54@gmail.com> In-Reply-To: <3528e4d5-4eb8-0e9f-6fe1-49494e9fcd54@gmail.com> From: Brian Carpenter Date: Tue, 30 Jun 2020 21:27:30 +1200 Message-ID: To: "Michael H. Behringer" Cc: Anima WG Content-Type: multipart/alternative; boundary="00000000000082ee4d05a949c9bf" Archived-At: Subject: Re: [Anima] "virtual out-of-band" ... or some minor non-ACP-number comments on Action: draft-ietf-anima-autonomic-control-plane-25.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2020 09:27:46 -0000 --00000000000082ee4d05a949c9bf Content-Type: text/plain; charset="UTF-8" Hi Michael, To be clear, I don't feel at all strongly about this. If people accept 'virtual out of band', I certainly don't object. Regards Brian (via tiny screen & keyboard) On Tue, 30 Jun 2020, 18:27 Michael H. Behringer, < michael.h.behringer@gmail.com> wrote: > I still prefer the definition "virtual out of band". > > An "overlay" (secure or not) depends on correct configuration of the > underlay. The ACP does NOT depend on configuration in the underlay, that > is what makes it special. > > I haven't seen the definition "virtual out of band" anywhere else, and > it is the most precise way to describe it. > > Michael > > On 30/06/2020 00:06, Brian E Carpenter wrote: > > Say "secure overlay" to emphasise the point, but yes. > > > > The draft I submitted yesterday "describes a simple method of forming an > ACP immediately above the transport layer" which is indeed precisely a > secure overlay. > > > > Regards > > Brian > > > > On 30-Jun-20 00:45, William Atwood wrote: > >> Is "overlay" the right word? > >> > >> I agree that it is physically in-band, and virtually out-of-band. Isn't > >> that the definition of "overlay"? > >> > >> Bill > >> > >> On 2020-06-28 11:02 p.m., Michael Richardson wrote: > >>> Attention This email originates from outside the concordia.ca domain. > // > >>> Ce courriel provient de l'exterieur du domaine de concordia.ca > >>> On 2020-06-23 10:31 p.m., internet-drafts@ietf.org wrote: > >>>> A diff from the previous version is available at: > >>>> > >>> > https://www.ietf.org/rfcdiff?url2=draft-ietf-anima-autonomic-control-plane-25 > >>> > >>> > >>> yes, I read the diffs :-) > >>> > >>> - This document describes a modular design for a self-forming, self- > >>> - managing and self-protecting ACP, which is a virtual in-band > network > >>> - designed to be as independent as possible of configuration, > >>> > >>> + This document describes a modular design for a self-forming, self- > >>> + managing and self-protecting ACP, which is a virtual out-of-band > >>> + network designed to be as independent as possible of configuration, > >>> > >>> This change from being a virtual in-band network to a virtual > >>> out-of-band network must have been in response to some comments... It > >>> seems a big change in some ways. I guess it makes this text consistent > >>> with the abstract which has said virtual out-of-band for awhile now. > >>> > >>> But, I do have to wonder if we are creating confusion by claiming that > >>> this is an out-of-band mechanism, even though it's really an in-band > >>> mechanism. It's just virtually-out. > >>> > >>> I actually do want to start a bike-shed issue here? > >>> Are we describing ourself wrong? Maybe there is some portmanteau that > >>> would be more accurate? I think that the above sentence is essentially > >>> the elevator pitch for all of ANIMA. > >>> > >>> > >>> There is also a bunch of other text that has been added to the > >>> Introduction, which I think confuses more than it enlightens. > >>> Or at least needs a better copy-edit. > >>> > >>> A number of other new sections (9.4..) need a copy-edit to fix some > >>> missing words. I will try to help Toerless with that via github. > >>> > >>> _______________________________________________ > >>> Anima mailing list > >>> Anima@ietf.org > >>> https://www.ietf.org/mailman/listinfo/anima > >>> > > _______________________________________________ > > Anima mailing list > > Anima@ietf.org > > https://www.ietf.org/mailman/listinfo/anima > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima > --00000000000082ee4d05a949c9bf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Michael,
To be clear, I do= n't feel at all strongly about this. If people accept 'virtual out = of band', I certainly don't object.

Regards
=C2=A0=C2=A0=C2=A0 Brian
=C2=A0= =C2=A0=C2=A0 (via tiny screen & keyboard)

On Tue, 30 Jun 20= 20, 18:27 Michael H. Behringer, <michael.h.behringer@gmail.com> wrote:
I still prefer the definition "virtual out of band= ".

An "overlay" (secure or not) depends on correct configuration of = the
underlay. The ACP does NOT depend on configuration in the underlay, that is what makes it special.

I haven't seen the definition "virtual out of band" anywhere = else, and
it is the most precise way to describe it.

Michael

On 30/06/2020 00:06, Brian E Carpenter wrote:
> Say "secure overlay" to emphasise the point, but yes.
>
> The draft I submitted yesterday "describes a simple method of for= ming an ACP immediately above the transport layer" which is indeed pre= cisely a secure overlay.
>
> Regards
>=C2=A0 =C2=A0 =C2=A0Brian
>
> On 30-Jun-20 00:45, William Atwood wrote:
>> Is "overlay" the right word?
>>
>> I agree that it is physically in-band, and virtually out-of-band.= =C2=A0 Isn't
>> that the definition of "overlay"?
>>
>>=C2=A0 =C2=A0 Bill
>>
>> On 2020-06-28 11:02 p.m., Michael Richardson wrote:
>>> Attention This email originates from outside the concordi= a.ca domain. //
>>> Ce courriel provient de l'exterieur du domaine de co= ncordia.ca
>>> On 2020-06-23 10:31 p.m., internet-drafts@ietf.org w= rote:
>>>> A diff from the previous version is available at:
>>>>
>>> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-anima-autonomic-control-p= lane-25
>>>
>>>
>>> yes, I read the diffs :-)
>>>
>>> -=C2=A0=C2=A0 This document describes a modular design for a s= elf-forming, self-
>>> -=C2=A0=C2=A0 managing and self-protecting ACP, which is a vir= tual in-band network
>>> -=C2=A0=C2=A0 designed to be as independent as possible of con= figuration,
>>>
>>> +=C2=A0=C2=A0 This document describes a modular design for a s= elf-forming, self-
>>> +=C2=A0=C2=A0 managing and self-protecting ACP, which is a vir= tual out-of-band
>>> +=C2=A0=C2=A0 network designed to be as independent as possibl= e of configuration,
>>>
>>> This change from being a virtual in-band network to a virtual<= br> >>> out-of-band network must have been in response to some comment= s... It
>>> seems a big change in some ways.=C2=A0 I guess it makes this t= ext consistent
>>> with the abstract which has said virtual out-of-band for awhil= e now.
>>>
>>> But, I do have to wonder if we are creating confusion by claim= ing that
>>> this is an out-of-band mechanism, even though it's really = an in-band
>>> mechanism.=C2=A0 It's just virtually-out.
>>>
>>> I actually do want to start a bike-shed issue here?
>>> Are we describing ourself wrong?=C2=A0 Maybe there is some por= tmanteau that
>>> would be more accurate?=C2=A0 I think that the above sentence = is essentially
>>> the elevator pitch for all of ANIMA.
>>>
>>>
>>> There is also a bunch of other text that has been added to the=
>>> Introduction, which I think confuses more than it enlightens.<= br> >>> Or at least needs a better copy-edit.
>>>
>>> A number of other new sections (9.4..) need a copy-edit to fix= some
>>> missing words.=C2=A0 I will try to help Toerless with that via= github.
>>>
>>> _______________________________________________
>>> Anima mailing list
>>> Anima@ietf.org
>>> https://www.ietf.org/mailman/list= info/anima
>>>
> _______________________________________________
> Anima mailing list
> Anima@ietf.org
> https://www.ietf.org/mailman/listinfo/ani= ma

_______________________________________________
Anima mailing list
Anim= a@ietf.org
https://www.ietf.org/mailman/listinfo/anima
--00000000000082ee4d05a949c9bf-- From nobody Tue Jun 30 05:03:22 2020 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBB963A07AA for ; Tue, 30 Jun 2020 05:03:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-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 M7t5-0vjVcZv for ; Tue, 30 Jun 2020 05:03:20 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 105DC3A07A5 for ; Tue, 30 Jun 2020 05:03:20 -0700 (PDT) Received: from lhreml724-chm.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id EEB60B1CD166CCCD5959; Tue, 30 Jun 2020 13:03:16 +0100 (IST) Received: from nkgeml706-chm.china.huawei.com (10.98.57.153) by lhreml724-chm.china.huawei.com (10.201.108.75) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Tue, 30 Jun 2020 13:03:15 +0100 Received: from nkgeml704-chm.china.huawei.com (10.98.57.158) by nkgeml706-chm.china.huawei.com (10.98.57.153) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Tue, 30 Jun 2020 20:03:13 +0800 Received: from nkgeml704-chm.china.huawei.com ([10.98.57.158]) by nkgeml704-chm.china.huawei.com ([10.98.57.158]) with mapi id 15.01.1913.007; Tue, 30 Jun 2020 20:03:13 +0800 From: "Yangjie (Jay, IP Standard)" To: Michael Richardson CC: "anima@ietf.org" Thread-Topic: My comments about : draft-richardson-anima-voucher-delegation-01 Thread-Index: AdZOw4Y4FeGqxEZ1SS6icxY5jL+EVw== Date: Tue, 30 Jun 2020 12:03:13 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.164.123.242] Content-Type: multipart/alternative; boundary="_000_c0b9640b000646698804adc2a45efc41huaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [Anima] My comments about : draft-richardson-anima-voucher-delegation-01 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2020 12:03:22 -0000 --_000_c0b9640b000646698804adc2a45efc41huaweicom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Michael, Resale scenario for IoT device are very common in market. So the delegated = voucher solution is very practical. And here, I have a question to ask for you: If the pledge may have several intermediates, then whether need to list the= ir identities in this pledge's voucher at the same time? If yes, how to process the multiple CA reference? For example as the follow= ing: One customer bought two batch of pledges from two different intermediates, = so for the same operator, they are no difference. But if for some reason, one pledge fail to get its voucher, maybe one inter= mediate forget set the right voucher, then how the operator confirm which i= ntermediate fail? I don't know whether there are available solution. Thanks. Certainly, if WG give some feedback for this, it will better. Best Regards, Jay. --_000_c0b9640b000646698804adc2a45efc41huaweicom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

&n= bsp;

Hi, Mic= hael,

&n= bsp;

&n= bsp;

Resale = scenario for IoT device are very common in market. So the delegated voucher= solution is very practical.

&n= bsp;

&n= bsp;

And her= e, I have a question to ask for you:

&n= bsp;

If the = pledge may have several intermediates, then whether need to list their iden= tities in this pledge’s voucher at the same time?

If yes,= how to process the multiple CA reference? For example as the following:

One cus= tomer bought two batch of pledges from two different intermediates, so for = the same operator, they are no difference.

But if = for some reason, one pledge fail to get its voucher, maybe one intermediate= forget set the right voucher, then how the operator confirm which intermed= iate fail?

I don&#= 8217;t know whether there are available solution.  Thanks.<= /span>

&n= bsp;

&n= bsp;

Cert= ainly, if WG give some feedback for this, it will better.=

&n= bsp;

&n= bsp;

&n= bsp;

Best Regards,<= /o:p>

Jay.

 

--_000_c0b9640b000646698804adc2a45efc41huaweicom_-- From nobody Tue Jun 30 05:45:14 2020 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C43ED3A07B7 for ; Tue, 30 Jun 2020 05:45:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-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 8rtC_0rJMm9c for ; Tue, 30 Jun 2020 05:45:09 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 C02313A07AF for ; Tue, 30 Jun 2020 05:45:09 -0700 (PDT) Received: from lhreml728-chm.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 17BDCE2A341BF7E7C173; Tue, 30 Jun 2020 13:45:08 +0100 (IST) Received: from nkgeml709-chm.china.huawei.com (10.98.57.40) by lhreml728-chm.china.huawei.com (10.201.108.79) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Tue, 30 Jun 2020 13:45:00 +0100 Received: from nkgeml704-chm.china.huawei.com (10.98.57.158) by nkgeml709-chm.china.huawei.com (10.98.57.40) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Tue, 30 Jun 2020 20:44:58 +0800 Received: from nkgeml704-chm.china.huawei.com ([10.98.57.158]) by nkgeml704-chm.china.huawei.com ([10.98.57.158]) with mapi id 15.01.1913.007; Tue, 30 Jun 2020 20:44:58 +0800 From: "Yangjie (Jay, IP Standard)" To: Michael Richardson CC: "anima@ietf.org" Thread-Topic: My comments about : draft-richardson-anima-registrar-considerations-00 Thread-Index: AdZO1zA5Op1A5ze8Sa67eaw7blOjAA== Date: Tue, 30 Jun 2020 12:44:57 +0000 Message-ID: <38e60e8da2004fbe8754dc1a8112abb6@huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.164.123.242] Content-Type: multipart/alternative; boundary="_000_38e60e8da2004fbe8754dc1a8112abb6huaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [Anima] My comments about : draft-richardson-anima-registrar-considerations-00 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2020 12:45:12 -0000 --_000_38e60e8da2004fbe8754dc1a8112abb6huaweicom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Michael, I know, there are two parts interaction process in BRSKI registrar, one is = with the pledge, another is with MASA. But current BRSKI Infrastructure hav= e no suggestion for voucher calling mechanism. Your draft for BRSKI registrar deployment give some considerations, which a= ll are concerned by the operator. To one customer, he may have many types of pledge. For scalability, not onl= y the number of the current pledges, but also the type of other pledges. So voucher calling mechanism on registrar, asynchronous mode is the best fo= r practical deployment. Is that so? Thanks, Certainly, if WG give some feedback for this, it will better. Best Regards, Jay. --_000_38e60e8da2004fbe8754dc1a8112abb6huaweicom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

&n= bsp;

Hi, Mic= hael,

&n= bsp;

&n= bsp;

I know,= there are two parts interaction process in BRSKI registrar, one is with th= e pledge, another is with MASA. But current BRSKI Infrastructure have no su= ggestion for voucher calling mechanism.

&n= bsp;

Your dr= aft for BRSKI registrar deployment give some considerations, which all are = concerned by the operator.

To one = customer, he may have many types of pledge. For scalability, not only the n= umber of the current pledges, but also the type of other pledges.

So vouc= her calling mechanism on registrar, asynchronous mode is the best for pract= ical deployment.

Is that= so?

Thanks,=

&n= bsp;

&n= bsp;

Cert= ainly, if WG give some feedback for this, it will better.=

&n= bsp;

&n= bsp;

Best Regards,<= /o:p>

Jay.

 

--_000_38e60e8da2004fbe8754dc1a8112abb6huaweicom_-- From nobody Tue Jun 30 09:10:19 2020 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 389923A0AD7 for ; Tue, 30 Jun 2020 09:10:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.65 X-Spam-Level: X-Spam-Status: No, score=-1.65 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 zBCf16YH-GfT for ; Tue, 30 Jun 2020 09:10:11 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B776E3A060A for ; Tue, 30 Jun 2020 09:10:10 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [131.188.34.52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 5CA16548011; Tue, 30 Jun 2020 18:10:04 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 5349F440043; Tue, 30 Jun 2020 18:10:04 +0200 (CEST) Date: Tue, 30 Jun 2020 18:10:04 +0200 From: Toerless Eckert To: Russ Housley Cc: Eric Rescorla , Michael Richardson , Ben Kaduk , Eric Vyncke , barryleiba@computer.org, Anima WG Message-ID: <20200630161004.GA48194@faui48f.informatik.uni-erlangen.de> References: <9406.1592756905@localhost> <3A92516D-B980-4231-9059-EF7234BA8610@vigilsec.com> <20200627054056.GA35664@faui48f.informatik.uni-erlangen.de> <20200627224640.GA41058@faui48f.informatik.uni-erlangen.de> <3A5D70B2-B3F9-42A6-9219-F25D657A7A7F@vigilsec.com> <20200628161149.GA16571@faui48f.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200628161149.GA16571@faui48f.informatik.uni-erlangen.de> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [Anima] Russ: Re: rfc822Name use in Autonomic Control Plane document X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2020 16:10:17 -0000 Just had a call with Russ and Barry (thanks Russ, Barry), and here is what transpired, and it comes with a Q to the ANIMA WG wrt. to solution options (see below). Hopefully Russ/Barry will correct me if i misrepresent anything. Russ and Barry agreed that a solutions where email addresses are not primarily intended to be used for actual emails (e.g.: using SMTP/RFC5321) may be something found in the wild, but in their opinion, it would create harm (to i guess the Internet email system), significant enough to warrant an IESG DISCUSS if such use was to be defined into an Internet Standard. If i understood it correctly, the choice of otherName by previous solutions similar might have also been influenced by the same rejection to use rfc822Name It sounded to me from the call as if email address/rfc822Name might have been desired to be used first by e.g.: XMPP but then they had to move to an otherName (RFC3920 i think) because of resistance to get that standardized. That at least would be a detail i was missing from the prior explanations on this thread. I continue to disagree, but i think the resolution of this basic argument would create an inacceptable timeline to progress ANIMA, so i do not want to afford this discussion any longer for the ACP draft. [ Hopefully i can get back to after ACP is done because i still think it is quite fundamental. ] a) Russ promised me a text stub or pointers thereto necessary/sufficient to define a new use (and i guess IANA registration). Probably something similar to what is e.g.: found in rfc8398. I think IANA registration is here: https://www.iana.org/assignments/smi-numbers/smi-numbers.xml See e.g.: id-on-SmtpUTF8Mailbox, registration procedure: spec required, expert: Russ Housley b) I brought up the point that using uniformResourceIdentifier instead of a new otherName would avoid that any part of the ecosystem including diagnostic tools would have to be software updated with new ASN.1 en/decode work and create unique names useable outside certificates as well. If we used "acp:@", this would require review process for the new "acp:" scheme, which according to my reading of process would take maybe up to one month. Barry suggested to simply register an IETF URN parameter (RFC3553), e.g.: urn:ietf:params:acp:@ IANA registry: https://www.iana.org/assignments/params/params.xhtml Registration procedure: IETF review (which i guess is the ACP draft IETF review). So, would love to hear opinions of a) vs. b). Am i overselling the URI option vs. the otherName option ? I have no experience on this backend side, i am just trying find the most pragmatic, easy to adopt option for operators, and i have seen a of backend systems (inventory management or the like) where names are shuffled around, and we started using email addresses because those are always supported identifier types in backend systems. No idea if URI are that common, but at least they could be there because they are an existing defined name/address type. For otherName, those uses outside certificates would need to come up with their own field type i think. Given how this is not an email address anymore, it would be prudent to introduce one degree of extensibility easier to manage: otherName: node:local@acp-domain-name URN: urn:ietf:params:acp:node:@ Where "node" is the value we define in ACP, and other values here are the extension points. Final note: of course we loose the ability to use public CA that an sign rfc822Name, e.g.: via ietf-acme-email-smime, which we would have if we whee permitted to use email addresses as ACP names, and i was getting fond of that option, but given how we did not perceive this nice option when we started ACP, its at least no set-back from the original ACP goals. Cheers Toerless On Sun, Jun 28, 2020 at 06:11:49PM +0200, Toerless Eckert wrote: > > On Sun, Jun 28, 2020 at 10:47:51AM -0400, Russ Housley wrote: > > Brian: > > > > The point of a certificate is to bind the public key to the identity of the private key holder. The certificate supports many different forms of names to support many different protocols. The rfc822name is used to bind to an email address. > > How do you think IETF should decide on what is a semantic correct > email address ? RFC5280 simply inherited the non-crypto definitions > of email address/mailbox. > > Do you think it is appropriate for you to recommend blocking progress > of a document through IESG review based on your interpretation what > does and what does not constitute a semantic correct email address ? > > Do you think that there are rfc2821 email addresses that are > semantically correct if not used in a certificate, but that are > not semantically correct for use in rfc5280 certificates ? If so, > can you please explain how such a differentiation would be justified > by existing RFC text ? > > If you do not think that there is a semantic correct email addresses > outside and inside of certificate/rfc822Name use, how then would > it be appropriate for you, Ben or LAMPS to decide on what is and > what is not a semantic correct email address. > > > And, something else is going on here. > > Are you saying the addresses are (1) semantic correct email addresses AND > something else is going on, or are you saying (2) they are NOT > semantic correct email addresses AND something else is going on. > > If you are saying (1), we are back to the above discussion of > the standing of how to decide what does and what does not > consitute a semantic correct email address. > > If you are saying (2), i fully agree, but i would need an explanation > of how such "something else" would invalidate the use of such > email addresses in rfc822Name, because i see no further requirements > against email addresses in rfc822Name other than what you showed > in a prior mair on this thread. > > If a terminal is assigned an email address of > "room17.terminal5@example.com", and the software says to the > user "you are sitting in Room17 on Terminal5", because the > software expected a particular formed local part of its > email address and parsed it, that is something else going on. > > If the same email address is then use together as an > identifier together with a password for the terminal to > access some resources, oh, like a library database, that is > also something else going on. > > This is pretty much what ACP does. What is IMHO is NOT going > on here is that these additional aspects render > room17.terminal5@example.com into a non semantic correct > email address. They just do more with it. > > > That is why I recommend otherName instead of rfc822name. > > No, if you would just recommend an alternative that would be great, > but you are blocking progress of a document that has a lot of > in our opinion crucial explanations how that alternative would > create more use-case harm than the solution choosen in the document. > > > I think that everyone understands that at this point. > > I do not understand how a recommendation like yours can raise to > a blocking DISCUSS in an IESG review. > > > Eric: > > > > Please change the write-up for this document. It currently says: > > > > (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? > > If so, please summarise the areas of conflict in separate email messages to the > > Responsible Area Director. (It should be in a separate email because this > > questionnaire is publicly available.) > > > > No. There was unanimous support for this work and nobody raised any objections. > > This is no longer the case. > > So, it is not a recommendation you are voicing, it is instead > "extreme discontent". > > I wonder what rules of IETF are for betting how such "extreme miscontent" > has to be technically founded or just needs to be taken into account > without suficient technical argument. I think you have provided > no clear technical reasoning for: > > - How does the documents choice cause more harm than the alternative > proposed for the use-cases or any other possible victims ? > - How is the choice in violation of any relevant RFC ? > - How are the email addresses not syntactic and semantic correct addresses according to rfc2821 ? > - How are otherwise statements like "i do not think this is the right thing" and > "there is something else going on here" sufficient arguments for blocking > IESG progressing the document. > > Cheers > Toerless > > > > > Russ > > > > > > > On Jun 27, 2020, at 11:09 PM, Brian E Carpenter wrote: > > > > > > Hi Eric, > > > > > > On 28-Jun-20 10:58, Eric Rescorla wrote: > > >> I'm not Russ, but I don't take his point to be about ACME one way or the other. > > >> > > >> Rather, I take his point to be (as he just said in his response to Brian) that while this is *formatted* as an e-mail address, it does not in fact correspond to something to which e-mail can be delivered > > > > > > It might do, simply because it is so formatted. > > > > > >> and therefore does not match the semantics of RFC 5280. > > > > > > RFC5280 does not require such a mailbox to exist. Is there another normative document, e.g. a BCP, that does require one? It's entirely possible that the authors of RFC5280 assumed that such a mailbox would exist, but this is not written anywhere that I can see. So IMNSHO, this objection to the ACP draft is attempting to hold it to a standard that isn't documented. > > > > > >> Taking a step back from the substantive issue, it seems to me that to the extent to which their is debate about the meaning of 5280, this is a discussion which cannot be resolved entirely on this list, but instead needs to involve the LAMPS WG. > > > > > > That may be true, but it's not ANIMA's fault and the discussion first arose last year, so why hasn't LAMPS already considered it, if it's important enough to continue obstructing ANIMA's progress? > > > > > > Brian > > > > > >> > > >> -Ekr > > >> > > >> > > >> > > >> > > >> On Sat, Jun 27, 2020 at 3:46 PM Toerless Eckert > wrote: > > >> > > >> On Sat, Jun 27, 2020 at 11:52:20AM -0400, Russ Housley wrote: > > >>> Toerless: > > >>> > > >>> I think Brian actually made my point. While the filed contains an email address, using it as such would result in a delivery failure. The private key holder cannot be reached by this address. > > >> > > >> Russ, i said: > > >> > > >>> First of all, you can if you want to, > > >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > >> > > >> Aka: Yes, if an ACP admin thinks ACME style challenge/reply > > >> email authentication mechanism is useful, then he can of course > > >> set up those email addresses accordingly. I did reply to that > > >> point exhaustively in my reply about the ACME email mechanism. > > >> > > >> Why do you ignore that answer ? > > >> > > >>> and secondly, i contest that it is a requirement to be able > > >>> to do that if the recipient doesn't need to support it. > > >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > >> > > >>> Think about noreply@bad-corporation.com . > > >>> You do want to make sure though that you are in control of > > >>> the electronic mail address though, and that is given for ACP > > >>> addresses. > > >> > > >> Where in rfc5280 or any other generic RFC about certificates does > > >> it say you MUST have a mailbox that is reachable ? Where does it > > >> say that all certificiates with rfc822Name must be email boxes > > >> that support ACME email style challenge-reply about the email address ? > > >> I think this is a non-existing requirement against email addresses. > > >> > > >> Of course, noreply@bad-corporation.com can have a certificate with > > >> that rfc822Name. It just can't use the ACME mechanism to be > > >> generated. But the signed mails sent from that address can be > > >> authenticated. > > >> > > >> Or there are never emails, because the email address just serves > > >> as identifier of an entity such as in wifi roaming identification > > >> and authentication. In that case you are not authenticating > > >> e.g.: password ownership for the email address via actual emails > > >> but via AAA protocols against a DNS domain known AAA server > > >> for the domain part of the email address. > > >> > > >> If you want to write a standards track RFC that all email addresses > > >> used in any X.509v3 certificate MUST support an ACME style > > >> challenge/reply email, then please do that, and seee if you get > > >> thast through. If would invalidate a lot of solutions like > > >> those wifi roaming ones. It WOULD NOT invalidate the ACP > > >> solution, because as said (no several times) the ACP solution > > >> can perfectly be set up to support this. It just does not > > >> need to. > > >> > > >> Cheers > > >> Toerless > > >> > > >>> Russ > > >>> > > >>> > > >>>> On Jun 27, 2020, at 1:40 AM, Toerless Eckert > wrote: > > >>>> > > >>>> Russ, > > >>>> > > >>>> Top posting re. your ACP vs. ACME question. > > >>>> > > >>>> ACP rfc822name are meant to be under control of the ACP network operations. > > >>>> aka: the ACP registrars could be controlling rfcSELF*@example.com mailboxes using > > >>>> ACME S/MIME to get rfcSELF*@example.com certificates or IMHO easier control > > >>>> the acp.example.com MTA. Just no need/benefit to do this now IMHO: > > >>>> > > >>>> An ACP is a private network which is ideally isolated from other > > >>>> ACP networks by use of private TA. Using the ACME rfc822name scheme would > > >>>> IMHO create a lot of attack components (all the MTA in the mail path > > >>>> and domain names) if used acros the Internet - without benefits for > > >>>> ACP. Of course, if it was all a private ACME setup within an enterprise, > > >>>> and using mailboxes and ACME is a popular choice - sure, why not. > > >>>> But for private CA setups there are existing IMO easier options > > >>>> (private CA VMs using EST or the like). > > >>>> > > >>>> IMHO public ACME CAwith S/MIME authenitcation could make sense > > >>>> in the future to enable authentication across different ACP domains. > > >>>> > > >>>> Any network has links into other domains and today they are usually > > >>>> unauthenticated, that could be solved IMHO fairly easily. > > >>>> > > >>>> "private" CA of ACP domain , lets call it acpCA signs all ACP certs. > > >>>> Its own cert is not self-signed, but signed by ACME CA via S/MIME, > > >>>> maybe email is rfcSELF@example.com (no ACP IPv6 address in it) > > >>>> > > >>>> Now the ACP nodes actually use acpCA PLUS ACMA CA's as TA. > > >>>> After IKEv2 authenticates neigbor the followup ACP domain membership > > >>>> step checks if the TA of the peer is acpCA. If yes, then peer > > >>>> becomes ACP member, otherwise we have an authenticated signalling > > >>>> channel to an interdomain / different CA peer. And that of course > > >>>> would enable better/secure auto-configuration of such interdomain > > >>>> links. > > >>>> > > >>>> This gives me good mix of security: Its still only relying on > > >>>> well controlled private TA to get into ACP, but also doubles > > >>>> at less secure but best available "Internet/Interdomain" > > >>>> authentication. > > >>>> > > >>>> Cheers > > >>>> Toerless > > >>>> > > >>>> On Sun, Jun 21, 2020 at 12:36:06PM -0400, Russ Housley wrote: > > >>>>>> On Jun 21, 2020, at 12:28 PM, Michael Richardson > wrote: > > >>>>>> > > >>>>>> > > >>>>>> Russ Housley > wrote: > > >>>>>>> One cannot send email to the character string in this specification, so > > >>>>>>> it should not be carried in the rfc822name. > > >>>>>> > > >>>>>> You can send email to that character string if you configure the MX. > > >>>>>> It was designed specifically to accomodate that. > > >>>>>> > > >>>>>> I objected at the time: I thought it was a stupid feature, that no sensible IKEv2 daemon > > >>>>>> was going to have to send/receive email. > > >>>>>> > > >>>>>> But, Toerless was paranoid that if we did anything at all out of the > > >>>>>> ordinary, that the corporate CA people, in order to protect their fiefdom, > > >>>>>> would freak out and throw some huge roadblock in the way of deploying the ACP. > > >>>>>> > > >>>>>> And, now have an ACME method past WGLC that does certificate validation by > > >>>>>> SMTP. > > >>>>> > > >>>>> Looking at the email certificate enrollment work in the ACME WG (draft-ietf-acme-email-smime-08), I have a hard time seeing how the device that knows the private key could participate in such a protocol. How do you see it working? > > >>>>> > > >>>>> Russ > > >>>>> > > >>>> > > >>>> > > >>>> > > >>>>> _______________________________________________ > > >>>>> Anima mailing list > > >>>>> Anima@ietf.org > > >>>>> https://www.ietf.org/mailman/listinfo/anima > > >>>> > > >>>> > > >>>> -- > > >>>> --- > > >>>> tte@cs.fau.de > > >> > > >> -- > > >> --- > > >> tte@cs.fau.de > > >> > > >> _______________________________________________ > > >> Anima mailing list > > >> Anima@ietf.org > > >> https://www.ietf.org/mailman/listinfo/anima > > >> > > >> > > >> _______________________________________________ > > >> Anima mailing list > > >> Anima@ietf.org > > >> https://www.ietf.org/mailman/listinfo/anima > > >> > > > > > -- > --- > tte@cs.fau.de > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima -- --- tte@cs.fau.de From nobody Tue Jun 30 09:12:42 2020 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8356C3A0B95 for ; Tue, 30 Jun 2020 09:12:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.65 X-Spam-Level: X-Spam-Status: No, score=-1.65 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 TUkevKwEwhvf for ; Tue, 30 Jun 2020 09:12:38 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E7553A0B72 for ; Tue, 30 Jun 2020 09:12:37 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 5FC2654843F; Tue, 30 Jun 2020 18:12:32 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 5934E440043; Tue, 30 Jun 2020 18:12:32 +0200 (CEST) Date: Tue, 30 Jun 2020 18:12:32 +0200 From: Toerless Eckert To: Brian Carpenter Cc: "Michael H. Behringer" , Anima WG Message-ID: <20200630161232.GB48194@faui48f.informatik.uni-erlangen.de> References: <159296586835.337.577109779817720457@ietfa.amsl.com> <16876f80-5504-a622-f13c-686ce69b4733@sandelman.ca> <86736d02-d1b6-ebfb-a894-92c9ca4b1e96@concordia.ca> <1d463beb-ba42-9495-0c53-58116b6f3a57@gmail.com> <3528e4d5-4eb8-0e9f-6fe1-49494e9fcd54@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [Anima] "virtual out-of-band" ... or some minor non-ACP-number comments on Action: draft-ietf-anima-autonomic-control-plane-25.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2020 16:12:41 -0000 Thanks to everbody chiming in for "virtual out of band" ;-) I would have hated anything with "overlay", i think Arthur correctly described it with "blind" On Tue, Jun 30, 2020 at 09:27:30PM +1200, Brian Carpenter wrote: > Hi Michael, > To be clear, I don't feel at all strongly about this. If people accept > 'virtual out of band', I certainly don't object. > > Regards > Brian > (via tiny screen & keyboard) > > On Tue, 30 Jun 2020, 18:27 Michael H. Behringer, < > michael.h.behringer@gmail.com> wrote: > > > I still prefer the definition "virtual out of band". > > > > An "overlay" (secure or not) depends on correct configuration of the > > underlay. The ACP does NOT depend on configuration in the underlay, that > > is what makes it special. > > > > I haven't seen the definition "virtual out of band" anywhere else, and > > it is the most precise way to describe it. > > > > Michael > > > > On 30/06/2020 00:06, Brian E Carpenter wrote: > > > Say "secure overlay" to emphasise the point, but yes. > > > > > > The draft I submitted yesterday "describes a simple method of forming an > > ACP immediately above the transport layer" which is indeed precisely a > > secure overlay. > > > > > > Regards > > > Brian > > > > > > On 30-Jun-20 00:45, William Atwood wrote: > > >> Is "overlay" the right word? > > >> > > >> I agree that it is physically in-band, and virtually out-of-band. Isn't > > >> that the definition of "overlay"? > > >> > > >> Bill > > >> > > >> On 2020-06-28 11:02 p.m., Michael Richardson wrote: > > >>> Attention This email originates from outside the concordia.ca domain. > > // > > >>> Ce courriel provient de l'exterieur du domaine de concordia.ca > > >>> On 2020-06-23 10:31 p.m., internet-drafts@ietf.org wrote: > > >>>> A diff from the previous version is available at: > > >>>> > > >>> > > https://www.ietf.org/rfcdiff?url2=draft-ietf-anima-autonomic-control-plane-25 > > >>> > > >>> > > >>> yes, I read the diffs :-) > > >>> > > >>> - This document describes a modular design for a self-forming, self- > > >>> - managing and self-protecting ACP, which is a virtual in-band > > network > > >>> - designed to be as independent as possible of configuration, > > >>> > > >>> + This document describes a modular design for a self-forming, self- > > >>> + managing and self-protecting ACP, which is a virtual out-of-band > > >>> + network designed to be as independent as possible of configuration, > > >>> > > >>> This change from being a virtual in-band network to a virtual > > >>> out-of-band network must have been in response to some comments... It > > >>> seems a big change in some ways. I guess it makes this text consistent > > >>> with the abstract which has said virtual out-of-band for awhile now. > > >>> > > >>> But, I do have to wonder if we are creating confusion by claiming that > > >>> this is an out-of-band mechanism, even though it's really an in-band > > >>> mechanism. It's just virtually-out. > > >>> > > >>> I actually do want to start a bike-shed issue here? > > >>> Are we describing ourself wrong? Maybe there is some portmanteau that > > >>> would be more accurate? I think that the above sentence is essentially > > >>> the elevator pitch for all of ANIMA. > > >>> > > >>> > > >>> There is also a bunch of other text that has been added to the > > >>> Introduction, which I think confuses more than it enlightens. > > >>> Or at least needs a better copy-edit. > > >>> > > >>> A number of other new sections (9.4..) need a copy-edit to fix some > > >>> missing words. I will try to help Toerless with that via github. > > >>> > > >>> _______________________________________________ > > >>> Anima mailing list > > >>> Anima@ietf.org > > >>> https://www.ietf.org/mailman/listinfo/anima > > >>> > > > _______________________________________________ > > > Anima mailing list > > > Anima@ietf.org > > > https://www.ietf.org/mailman/listinfo/anima > > > > _______________________________________________ > > Anima mailing list > > Anima@ietf.org > > https://www.ietf.org/mailman/listinfo/anima > > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima -- --- tte@cs.fau.de From nobody Tue Jun 30 10:26:03 2020 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD2503A086C for ; Tue, 30 Jun 2020 10:26:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=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 6CI3uWLdDgum for ; Tue, 30 Jun 2020 10:25:57 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFFF73A082B for ; Tue, 30 Jun 2020 10:25:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 0E3D4300B72 for ; Tue, 30 Jun 2020 13:25:51 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id KNtAq2D7Y1R6 for ; Tue, 30 Jun 2020 13:25:42 -0400 (EDT) Received: from a860b60074bd.fios-router.home (pool-72-66-113-56.washdc.fios.verizon.net [72.66.113.56]) by mail.smeinc.net (Postfix) with ESMTPSA id 857D13004AF; Tue, 30 Jun 2020 13:25:41 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.14\)) From: Russ Housley In-Reply-To: <20200630161004.GA48194@faui48f.informatik.uni-erlangen.de> Date: Tue, 30 Jun 2020 13:25:42 -0400 Cc: Eric Rescorla , Michael Richardson , Ben Kaduk , Eric Vyncke , Barry Leiba , Anima WG Content-Transfer-Encoding: quoted-printable Message-Id: References: <9406.1592756905@localhost> <3A92516D-B980-4231-9059-EF7234BA8610@vigilsec.com> <20200627054056.GA35664@faui48f.informatik.uni-erlangen.de> <20200627224640.GA41058@faui48f.informatik.uni-erlangen.de> <3A5D70B2-B3F9-42A6-9219-F25D657A7A7F@vigilsec.com> <20200628161149.GA16571@faui48f.informatik.uni-erlangen.de> <20200630161004.GA48194@faui48f.informatik.uni-erlangen.de> To: Toerless Eckert X-Mailer: Apple Mail (2.3445.104.14) Archived-At: Subject: Re: [Anima] Russ: Re: rfc822Name use in Autonomic Control Plane document X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2020 17:26:01 -0000 One minor additional point, otherName would allow binary encoding, which = might be helpful for the IoT environment. The URN approach does require = ASCII string. Russ > On Jun 30, 2020, at 12:10 PM, Toerless Eckert wrote: >=20 > Just had a call with Russ and Barry (thanks Russ, Barry), and here is > what transpired, and it comes with a Q to the ANIMA WG wrt. to > solution options (see below). Hopefully Russ/Barry will correct me if = i > misrepresent anything. >=20 > Russ and Barry agreed that a solutions where email addresses are not > primarily intended to be used for actual emails (e.g.: using = SMTP/RFC5321) > may be something found in the wild, but in their opinion, it would = create > harm (to i guess the Internet email system), significant enough to = warrant > an IESG DISCUSS if such use was to be defined into an Internet = Standard. >=20 > If i understood it correctly, the choice of otherName by previous = solutions > similar might have also been influenced by the same rejection to use = rfc822Name > It sounded to me from the call as if email address/rfc822Name might = have > been desired to be used first by e.g.: XMPP but then they had to move = to > an otherName (RFC3920 i think) because of resistance to get that = standardized. > That at least would be a detail i was missing from the prior = explanations on > this thread. >=20 > I continue to disagree, but i think the resolution of this basic > argument would create an inacceptable timeline to progress ANIMA, > so i do not want to afford this discussion any longer for the ACP = draft. > [ Hopefully i can get back to after ACP is done because i still think = it > is quite fundamental. ] >=20 > a) Russ promised me a text stub or pointers thereto = necessary/sufficient to define a new > use (and i guess IANA registration). Probably something similar to > what is e.g.: found in rfc8398. >=20 > I think IANA registration is here: = https://www.iana.org/assignments/smi-numbers/smi-numbers.xml > See e.g.: id-on-SmtpUTF8Mailbox,=20 > registration procedure: spec required, expert: Russ Housley >=20 > b) I brought up the point that using uniformResourceIdentifier instead > of a new otherName would avoid that any part of the ecosystem = including=20 > diagnostic tools would have to be software updated with new ASN.1 > en/decode work and create unique names useable outside certificates = as well. >=20 > If we used "acp:@", this would require > review process for the new "acp:" scheme, which according to my = reading of > process would take maybe up to one month. Barry suggested to simply > register an IETF URN parameter (RFC3553), e.g.: >=20 > urn:ietf:params:acp:@ >=20 > IANA registry: https://www.iana.org/assignments/params/params.xhtml > Registration procedure: IETF review (which i guess is the ACP = draft IETF review). >=20 > So, would love to hear opinions of a) vs. b). Am i overselling the URI = option > vs. the otherName option ? I have no experience on this backend side, = i am > just trying find the most pragmatic, easy to adopt option for = operators, > and i have seen a of backend systems (inventory management or the = like) > where names are shuffled around, and we started using email addresses = because > those are always supported identifier types in backend systems. No = idea if URI are that common, > but at least they could be there because they are an existing defined = name/address type. > For otherName, those uses outside certificates would need to come up = with their own > field type i think. >=20 > Given how this is not an email address anymore, it > would be prudent to introduce one degree of extensibility easier to = manage: >=20 > otherName: node:local@acp-domain-name > URN: urn:ietf:params:acp:node:@ >=20 > Where "node" is the value we define in ACP, and other values here > are the extension points. >=20 > Final note: of course we loose the ability to use public CA that an > sign rfc822Name, e.g.: via ietf-acme-email-smime, which we would have > if we whee permitted to use email addresses as ACP names, and i was = getting > fond of that option, but given how we did not perceive this nice = option > when we started ACP, its at least no set-back from the original ACP = goals. >=20 > Cheers > Toerless >=20 > On Sun, Jun 28, 2020 at 06:11:49PM +0200, Toerless Eckert wrote: >>=20 >> On Sun, Jun 28, 2020 at 10:47:51AM -0400, Russ Housley wrote: >>> Brian: >>>=20 >>> The point of a certificate is to bind the public key to the identity = of the private key holder. The certificate supports many different = forms of names to support many different protocols. The rfc822name is = used to bind to an email address. >>=20 >> How do you think IETF should decide on what is a semantic correct >> email address ? RFC5280 simply inherited the non-crypto definitions >> of email address/mailbox. >>=20 >> Do you think it is appropriate for you to recommend blocking progress >> of a document through IESG review based on your interpretation what >> does and what does not constitute a semantic correct email address ? >>=20 >> Do you think that there are rfc2821 email addresses that are >> semantically correct if not used in a certificate, but that are >> not semantically correct for use in rfc5280 certificates ? If so, >> can you please explain how such a differentiation would be justified >> by existing RFC text ? >>=20 >> If you do not think that there is a semantic correct email addresses >> outside and inside of certificate/rfc822Name use, how then would >> it be appropriate for you, Ben or LAMPS to decide on what is and >> what is not a semantic correct email address. >>=20 >>> And, something else is going on here. >>=20 >> Are you saying the addresses are (1) semantic correct email addresses = AND >> something else is going on, or are you saying (2) they are NOT >> semantic correct email addresses AND something else is going on. >>=20 >> If you are saying (1), we are back to the above discussion of >> the standing of how to decide what does and what does not >> consitute a semantic correct email address. >>=20 >> If you are saying (2), i fully agree, but i would need an explanation >> of how such "something else" would invalidate the use of such >> email addresses in rfc822Name, because i see no further requirements >> against email addresses in rfc822Name other than what you showed >> in a prior mair on this thread.=20 >>=20 >> If a terminal is assigned an email address of >> "room17.terminal5@example.com", and the software says to the >> user "you are sitting in Room17 on Terminal5", because the >> software expected a particular formed local part of its >> email address and parsed it, that is something else going on. >>=20 >> If the same email address is then use together as an >> identifier together with a password for the terminal to >> access some resources, oh, like a library database, that is=20 >> also something else going on.=20 >>=20 >> This is pretty much what ACP does. What is IMHO is NOT going >> on here is that these additional aspects render >> room17.terminal5@example.com into a non semantic correct >> email address. They just do more with it. >>=20 >>> That is why I recommend otherName instead of rfc822name. >>=20 >> No, if you would just recommend an alternative that would be great, >> but you are blocking progress of a document that has a lot of >> in our opinion crucial explanations how that alternative would >> create more use-case harm than the solution choosen in the document. >>=20 >>> I think that everyone understands that at this point. >>=20 >> I do not understand how a recommendation like yours can raise to >> a blocking DISCUSS in an IESG review. >>=20 >>> Eric: >>>=20 >>> Please change the write-up for this document. It currently says: >>>=20 >>> (10) Has anyone threatened an appeal or otherwise indicated extreme = discontent? >>> If so, please summarise the areas of conflict in separate email = messages to the >>> Responsible Area Director. (It should be in a separate email because = this >>> questionnaire is publicly available.) >>>=20 >>> No. There was unanimous support for this work and nobody raised any = objections. >>> This is no longer the case. >>=20 >> So, it is not a recommendation you are voicing, it is instead >> "extreme discontent".=20 >>=20 >> I wonder what rules of IETF are for betting how such "extreme = miscontent" >> has to be technically founded or just needs to be taken into account >> without suficient technical argument. I think you have provided >> no clear technical reasoning for: >>=20 >> - How does the documents choice cause more harm than the alternative >> proposed for the use-cases or any other possible victims ? >> - How is the choice in violation of any relevant RFC ? >> - How are the email addresses not syntactic and semantic correct = addresses according to rfc2821 ? >> - How are otherwise statements like "i do not think this is the right = thing" and >> "there is something else going on here" sufficient arguments for = blocking >> IESG progressing the document. >>=20 >> Cheers >> Toerless >>=20 >>>=20 >>> Russ >>>=20 >>>=20 >>>> On Jun 27, 2020, at 11:09 PM, Brian E Carpenter = wrote: >>>>=20 >>>> Hi Eric, >>>>=20 >>>> On 28-Jun-20 10:58, Eric Rescorla wrote: >>>>> I'm not Russ, but I don't take his point to be about ACME one way = or the other. >>>>>=20 >>>>> Rather, I take his point to be (as he just said in his response to = Brian) that while this is *formatted* as an e-mail address, it does not = in fact correspond to something to which e-mail can be delivered=20 >>>>=20 >>>> It might do, simply because it is so formatted. >>>>=20 >>>>> and therefore does not match the semantics of RFC 5280. >>>>=20 >>>> RFC5280 does not require such a mailbox to exist. Is there another = normative document, e.g. a BCP, that does require one? It's entirely = possible that the authors of RFC5280 assumed that such a mailbox would = exist, but this is not written anywhere that I can see. So IMNSHO, this = objection to the ACP draft is attempting to hold it to a standard that = isn't documented. >>>>=20 >>>>> Taking a step back from the substantive issue, it seems to me that = to the extent to which their is debate about the meaning of 5280, this = is a discussion which cannot be resolved entirely on this list, but = instead needs to involve the LAMPS WG. >>>>=20 >>>> That may be true, but it's not ANIMA's fault and the discussion = first arose last year, so why hasn't LAMPS already considered it, if = it's important enough to continue obstructing ANIMA's progress? >>>>=20 >>>> Brian >>>>=20 >>>>>=20 >>>>> -Ekr >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> On Sat, Jun 27, 2020 at 3:46 PM Toerless Eckert > wrote: >>>>>=20 >>>>> On Sat, Jun 27, 2020 at 11:52:20AM -0400, Russ Housley wrote: >>>>>> Toerless: >>>>>>=20 >>>>>> I think Brian actually made my point. While the filed contains = an email address, using it as such would result in a delivery failure. = The private key holder cannot be reached by this address. >>>>>=20 >>>>> Russ, i said: >>>>>=20 >>>>>> First of all, you can if you want to, >>>>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >>>>>=20 >>>>> Aka: Yes, if an ACP admin thinks ACME style challenge/reply >>>>> email authentication mechanism is useful, then he can of course >>>>> set up those email addresses accordingly. I did reply to that >>>>> point exhaustively in my reply about the ACME email mechanism. >>>>>=20 >>>>> Why do you ignore that answer ? >>>>>=20 >>>>>> and secondly, i contest that it is a requirement to be able >>>>>> to do that if the recipient doesn't need to support it. >>>>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >>>>>=20 >>>>>> Think about noreply@bad-corporation.com = . >>>>>> You do want to make sure though that you are in control of >>>>>> the electronic mail address though, and that is given for ACP >>>>>> addresses. >>>>>=20 >>>>> Where in rfc5280 or any other generic RFC about certificates = does >>>>> it say you MUST have a mailbox that is reachable ? Where does it >>>>> say that all certificiates with rfc822Name must be email boxes >>>>> that support ACME email style challenge-reply about the email = address ? >>>>> I think this is a non-existing requirement against email = addresses. >>>>>=20 >>>>> Of course, noreply@bad-corporation.com = can have a certificate with >>>>> that rfc822Name. It just can't use the ACME mechanism to be >>>>> generated. But the signed mails sent from that address can be >>>>> authenticated. >>>>>=20 >>>>> Or there are never emails, because the email address just serves >>>>> as identifier of an entity such as in wifi roaming = identification >>>>> and authentication. In that case you are not authenticating >>>>> e.g.: password ownership for the email address via actual emails >>>>> but via AAA protocols against a DNS domain known AAA server >>>>> for the domain part of the email address. >>>>>=20 >>>>> If you want to write a standards track RFC that all email = addresses >>>>> used in any X.509v3 certificate MUST support an ACME style >>>>> challenge/reply email, then please do that, and seee if you get >>>>> thast through. If would invalidate a lot of solutions like >>>>> those wifi roaming ones. It WOULD NOT invalidate the ACP >>>>> solution, because as said (no several times) the ACP solution >>>>> can perfectly be set up to support this. It just does not >>>>> need to. >>>>>=20 >>>>> Cheers >>>>> Toerless >>>>>=20 >>>>>> Russ >>>>>>=20 >>>>>>=20 >>>>>>> On Jun 27, 2020, at 1:40 AM, Toerless Eckert > wrote: >>>>>>>=20 >>>>>>> Russ, >>>>>>>=20 >>>>>>> Top posting re. your ACP vs. ACME question. >>>>>>>=20 >>>>>>> ACP rfc822name are meant to be under control of the ACP network = operations. >>>>>>> aka: the ACP registrars could be controlling = rfcSELF*@example.com mailboxes using >>>>>>> ACME S/MIME to get rfcSELF*@example.com = certificates or IMHO easier control >>>>>>> the acp.example.com MTA. Just no = need/benefit to do this now IMHO: >>>>>>>=20 >>>>>>> An ACP is a private network which is ideally isolated from other >>>>>>> ACP networks by use of private TA. Using the ACME rfc822name = scheme would >>>>>>> IMHO create a lot of attack components (all the MTA in the mail = path >>>>>>> and domain names) if used acros the Internet - without benefits = for >>>>>>> ACP. Of course, if it was all a private ACME setup within an = enterprise, >>>>>>> and using mailboxes and ACME is a popular choice - sure, why = not. >>>>>>> But for private CA setups there are existing IMO easier options >>>>>>> (private CA VMs using EST or the like). >>>>>>>=20 >>>>>>> IMHO public ACME CAwith S/MIME authenitcation could make sense >>>>>>> in the future to enable authentication across different ACP = domains. >>>>>>>=20 >>>>>>> Any network has links into other domains and today they are = usually >>>>>>> unauthenticated, that could be solved IMHO fairly easily. >>>>>>>=20 >>>>>>> "private" CA of ACP domain , lets call it acpCA signs all ACP = certs. >>>>>>> Its own cert is not self-signed, but signed by ACME CA via = S/MIME, >>>>>>> maybe email is rfcSELF@example.com = (no ACP IPv6 address in it) >>>>>>>=20 >>>>>>> Now the ACP nodes actually use acpCA PLUS ACMA CA's as TA. >>>>>>> After IKEv2 authenticates neigbor the followup ACP domain = membership >>>>>>> step checks if the TA of the peer is acpCA. If yes, then peer >>>>>>> becomes ACP member, otherwise we have an authenticated = signalling >>>>>>> channel to an interdomain / different CA peer. And that of = course >>>>>>> would enable better/secure auto-configuration of such = interdomain >>>>>>> links. >>>>>>>=20 >>>>>>> This gives me good mix of security: Its still only relying on >>>>>>> well controlled private TA to get into ACP, but also doubles >>>>>>> at less secure but best available "Internet/Interdomain" >>>>>>> authentication. >>>>>>>=20 >>>>>>> Cheers >>>>>>> Toerless >>>>>>>=20 >>>>>>> On Sun, Jun 21, 2020 at 12:36:06PM -0400, Russ Housley wrote: >>>>>>>>> On Jun 21, 2020, at 12:28 PM, Michael Richardson = > wrote: >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Russ Housley > wrote: >>>>>>>>>> One cannot send email to the character string in this = specification, so >>>>>>>>>> it should not be carried in the rfc822name. >>>>>>>>>=20 >>>>>>>>> You can send email to that character string if you configure = the MX. >>>>>>>>> It was designed specifically to accomodate that. >>>>>>>>>=20 >>>>>>>>> I objected at the time: I thought it was a stupid feature, = that no sensible IKEv2 daemon >>>>>>>>> was going to have to send/receive email. >>>>>>>>>=20 >>>>>>>>> But, Toerless was paranoid that if we did anything at all out = of the >>>>>>>>> ordinary, that the corporate CA people, in order to protect = their fiefdom, >>>>>>>>> would freak out and throw some huge roadblock in the way of = deploying the ACP. >>>>>>>>>=20 >>>>>>>>> And, now have an ACME method past WGLC that does certificate = validation by >>>>>>>>> SMTP. >>>>>>>>=20 >>>>>>>> Looking at the email certificate enrollment work in the ACME WG = (draft-ietf-acme-email-smime-08), I have a hard time seeing how the = device that knows the private key could participate in such a protocol. = How do you see it working? >>>>>>>>=20 >>>>>>>> Russ >>>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> Anima mailing list >>>>>>>> Anima@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/anima >>>>>>>=20 >>>>>>>=20 >>>>>>> -- >>>>>>> --- >>>>>>> tte@cs.fau.de >>>>>=20 >>>>> --=20 >>>>> --- >>>>> tte@cs.fau.de >>>>>=20 >>>>> _______________________________________________ >>>>> Anima mailing list >>>>> Anima@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/anima >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> Anima mailing list >>>>> Anima@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/anima >>>>>=20 >>>>=20 >>=20 >> --=20 >> --- >> tte@cs.fau.de >>=20 >> _______________________________________________ >> Anima mailing list >> Anima@ietf.org >> https://www.ietf.org/mailman/listinfo/anima >=20 > --=20 > --- > tte@cs.fau.de From nobody Tue Jun 30 11:59:33 2020 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0A0B3A003B for ; Tue, 30 Jun 2020 11:59:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.601 X-Spam-Level: X-Spam-Status: No, score=-9.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 ge3CqOY5A-U5 for ; Tue, 30 Jun 2020 11:59:29 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B963C3A0039 for ; Tue, 30 Jun 2020 11:59:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=19570; q=dns/txt; s=iport; t=1593543568; x=1594753168; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=qNHv85BiLaxgDPsQcGiwQQcLTXgJmVij1dsYLRR/Ta0=; b=PuNodAoVukc5jpL4GGw8u472/tceRPMqvZ5uvoXgyiRtnkIKeHivJz7b NvoJdsi3vHdfCxha4EeaEAzz+y4s/7x9Grm9suRRARy3WV2latdi22qoE CvkhuEFZPZFKKCqMJbZlzjlM9n0qdKIjNhcCGjXGtv01Yl3hT4p9BXmI/ Y=; X-IronPort-AV: E=Sophos;i="5.75,298,1589241600"; d="scan'208";a="25121036" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 30 Jun 2020 18:59:27 +0000 Received: from ams3-vpn-dhcp398.cisco.com (ams3-vpn-dhcp398.cisco.com [10.61.65.142]) by aer-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id 05UIxP1x026297 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 30 Jun 2020 18:59:26 GMT Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Eliot Lear In-Reply-To: <20200630161004.GA48194@faui48f.informatik.uni-erlangen.de> Date: Tue, 30 Jun 2020 20:59:24 +0200 Cc: Russ Housley , Eric Rescorla , Michael Richardson , Ben Kaduk , Eric Vyncke , barryleiba@computer.org, Anima WG Content-Transfer-Encoding: quoted-printable Message-Id: <69B9B7B6-4B75-4336-9F3F-45CD4FA51291@cisco.com> References: <9406.1592756905@localhost> <3A92516D-B980-4231-9059-EF7234BA8610@vigilsec.com> <20200627054056.GA35664@faui48f.informatik.uni-erlangen.de> <20200627224640.GA41058@faui48f.informatik.uni-erlangen.de> <3A5D70B2-B3F9-42A6-9219-F25D657A7A7F@vigilsec.com> <20200628161149.GA16571@faui48f.informatik.uni-erlangen.de> <20200630161004.GA48194@faui48f.informatik.uni-erlangen.de> To: Toerless Eckert X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Outbound-SMTP-Client: 10.61.65.142, ams3-vpn-dhcp398.cisco.com X-Outbound-Node: aer-core-2.cisco.com Archived-At: Subject: Re: [Anima] Russ: Re: rfc822Name use in Autonomic Control Plane document X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2020 18:59:32 -0000 Hi Toerless, I think either a URI or otherName are pretty much functionally = equivalent. I might go with URI for one particular reason, which is = that the tooling =E2=80=93 in particular OpenSSL =E2=80=93 will handle = it better. Eliot > On 30 Jun 2020, at 18:10, Toerless Eckert wrote: >=20 > Just had a call with Russ and Barry (thanks Russ, Barry), and here is > what transpired, and it comes with a Q to the ANIMA WG wrt. to > solution options (see below). Hopefully Russ/Barry will correct me if = i > misrepresent anything. >=20 > Russ and Barry agreed that a solutions where email addresses are not > primarily intended to be used for actual emails (e.g.: using = SMTP/RFC5321) > may be something found in the wild, but in their opinion, it would = create > harm (to i guess the Internet email system), significant enough to = warrant > an IESG DISCUSS if such use was to be defined into an Internet = Standard. >=20 > If i understood it correctly, the choice of otherName by previous = solutions > similar might have also been influenced by the same rejection to use = rfc822Name > It sounded to me from the call as if email address/rfc822Name might = have > been desired to be used first by e.g.: XMPP but then they had to move = to > an otherName (RFC3920 i think) because of resistance to get that = standardized. > That at least would be a detail i was missing from the prior = explanations on > this thread. >=20 > I continue to disagree, but i think the resolution of this basic > argument would create an inacceptable timeline to progress ANIMA, > so i do not want to afford this discussion any longer for the ACP = draft. > [ Hopefully i can get back to after ACP is done because i still think = it > is quite fundamental. ] >=20 > a) Russ promised me a text stub or pointers thereto = necessary/sufficient to define a new > use (and i guess IANA registration). Probably something similar to > what is e.g.: found in rfc8398. >=20 > I think IANA registration is here: = https://www.iana.org/assignments/smi-numbers/smi-numbers.xml > See e.g.: id-on-SmtpUTF8Mailbox,=20 > registration procedure: spec required, expert: Russ Housley >=20 > b) I brought up the point that using uniformResourceIdentifier instead > of a new otherName would avoid that any part of the ecosystem = including=20 > diagnostic tools would have to be software updated with new ASN.1 > en/decode work and create unique names useable outside certificates = as well. >=20 > If we used "acp:@", this would require > review process for the new "acp:" scheme, which according to my = reading of > process would take maybe up to one month. Barry suggested to simply > register an IETF URN parameter (RFC3553), e.g.: >=20 > urn:ietf:params:acp:@ >=20 > IANA registry: https://www.iana.org/assignments/params/params.xhtml > Registration procedure: IETF review (which i guess is the ACP = draft IETF review). >=20 > So, would love to hear opinions of a) vs. b). Am i overselling the URI = option > vs. the otherName option ? I have no experience on this backend side, = i am > just trying find the most pragmatic, easy to adopt option for = operators, > and i have seen a of backend systems (inventory management or the = like) > where names are shuffled around, and we started using email addresses = because > those are always supported identifier types in backend systems. No = idea if URI are that common, > but at least they could be there because they are an existing defined = name/address type. > For otherName, those uses outside certificates would need to come up = with their own > field type i think. >=20 > Given how this is not an email address anymore, it > would be prudent to introduce one degree of extensibility easier to = manage: >=20 > otherName: node:local@acp-domain-name > URN: urn:ietf:params:acp:node:@ >=20 > Where "node" is the value we define in ACP, and other values here > are the extension points. >=20 > Final note: of course we loose the ability to use public CA that an > sign rfc822Name, e.g.: via ietf-acme-email-smime, which we would have > if we whee permitted to use email addresses as ACP names, and i was = getting > fond of that option, but given how we did not perceive this nice = option > when we started ACP, its at least no set-back from the original ACP = goals. >=20 > Cheers > Toerless >=20 > On Sun, Jun 28, 2020 at 06:11:49PM +0200, Toerless Eckert wrote: >>=20 >> On Sun, Jun 28, 2020 at 10:47:51AM -0400, Russ Housley wrote: >>> Brian: >>>=20 >>> The point of a certificate is to bind the public key to the identity = of the private key holder. The certificate supports many different = forms of names to support many different protocols. The rfc822name is = used to bind to an email address. >>=20 >> How do you think IETF should decide on what is a semantic correct >> email address ? RFC5280 simply inherited the non-crypto definitions >> of email address/mailbox. >>=20 >> Do you think it is appropriate for you to recommend blocking progress >> of a document through IESG review based on your interpretation what >> does and what does not constitute a semantic correct email address ? >>=20 >> Do you think that there are rfc2821 email addresses that are >> semantically correct if not used in a certificate, but that are >> not semantically correct for use in rfc5280 certificates ? If so, >> can you please explain how such a differentiation would be justified >> by existing RFC text ? >>=20 >> If you do not think that there is a semantic correct email addresses >> outside and inside of certificate/rfc822Name use, how then would >> it be appropriate for you, Ben or LAMPS to decide on what is and >> what is not a semantic correct email address. >>=20 >>> And, something else is going on here. >>=20 >> Are you saying the addresses are (1) semantic correct email addresses = AND >> something else is going on, or are you saying (2) they are NOT >> semantic correct email addresses AND something else is going on. >>=20 >> If you are saying (1), we are back to the above discussion of >> the standing of how to decide what does and what does not >> consitute a semantic correct email address. >>=20 >> If you are saying (2), i fully agree, but i would need an explanation >> of how such "something else" would invalidate the use of such >> email addresses in rfc822Name, because i see no further requirements >> against email addresses in rfc822Name other than what you showed >> in a prior mair on this thread.=20 >>=20 >> If a terminal is assigned an email address of >> "room17.terminal5@example.com", and the software says to the >> user "you are sitting in Room17 on Terminal5", because the >> software expected a particular formed local part of its >> email address and parsed it, that is something else going on. >>=20 >> If the same email address is then use together as an >> identifier together with a password for the terminal to >> access some resources, oh, like a library database, that is=20 >> also something else going on.=20 >>=20 >> This is pretty much what ACP does. What is IMHO is NOT going >> on here is that these additional aspects render >> room17.terminal5@example.com into a non semantic correct >> email address. They just do more with it. >>=20 >>> That is why I recommend otherName instead of rfc822name. >>=20 >> No, if you would just recommend an alternative that would be great, >> but you are blocking progress of a document that has a lot of >> in our opinion crucial explanations how that alternative would >> create more use-case harm than the solution choosen in the document. >>=20 >>> I think that everyone understands that at this point. >>=20 >> I do not understand how a recommendation like yours can raise to >> a blocking DISCUSS in an IESG review. >>=20 >>> Eric: >>>=20 >>> Please change the write-up for this document. It currently says: >>>=20 >>> (10) Has anyone threatened an appeal or otherwise indicated extreme = discontent? >>> If so, please summarise the areas of conflict in separate email = messages to the >>> Responsible Area Director. (It should be in a separate email because = this >>> questionnaire is publicly available.) >>>=20 >>> No. There was unanimous support for this work and nobody raised any = objections. >>> This is no longer the case. >>=20 >> So, it is not a recommendation you are voicing, it is instead >> "extreme discontent".=20 >>=20 >> I wonder what rules of IETF are for betting how such "extreme = miscontent" >> has to be technically founded or just needs to be taken into account >> without suficient technical argument. I think you have provided >> no clear technical reasoning for: >>=20 >> - How does the documents choice cause more harm than the alternative >> proposed for the use-cases or any other possible victims ? >> - How is the choice in violation of any relevant RFC ? >> - How are the email addresses not syntactic and semantic correct = addresses according to rfc2821 ? >> - How are otherwise statements like "i do not think this is the right = thing" and >> "there is something else going on here" sufficient arguments for = blocking >> IESG progressing the document. >>=20 >> Cheers >> Toerless >>=20 >>>=20 >>> Russ >>>=20 >>>=20 >>>> On Jun 27, 2020, at 11:09 PM, Brian E Carpenter = wrote: >>>>=20 >>>> Hi Eric, >>>>=20 >>>> On 28-Jun-20 10:58, Eric Rescorla wrote: >>>>> I'm not Russ, but I don't take his point to be about ACME one way = or the other. >>>>>=20 >>>>> Rather, I take his point to be (as he just said in his response to = Brian) that while this is *formatted* as an e-mail address, it does not = in fact correspond to something to which e-mail can be delivered=20 >>>>=20 >>>> It might do, simply because it is so formatted. >>>>=20 >>>>> and therefore does not match the semantics of RFC 5280. >>>>=20 >>>> RFC5280 does not require such a mailbox to exist. Is there another = normative document, e.g. a BCP, that does require one? It's entirely = possible that the authors of RFC5280 assumed that such a mailbox would = exist, but this is not written anywhere that I can see. So IMNSHO, this = objection to the ACP draft is attempting to hold it to a standard that = isn't documented. >>>>=20 >>>>> Taking a step back from the substantive issue, it seems to me that = to the extent to which their is debate about the meaning of 5280, this = is a discussion which cannot be resolved entirely on this list, but = instead needs to involve the LAMPS WG. >>>>=20 >>>> That may be true, but it's not ANIMA's fault and the discussion = first arose last year, so why hasn't LAMPS already considered it, if = it's important enough to continue obstructing ANIMA's progress? >>>>=20 >>>> Brian >>>>=20 >>>>>=20 >>>>> -Ekr >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> On Sat, Jun 27, 2020 at 3:46 PM Toerless Eckert > wrote: >>>>>=20 >>>>> On Sat, Jun 27, 2020 at 11:52:20AM -0400, Russ Housley wrote: >>>>>> Toerless: >>>>>>=20 >>>>>> I think Brian actually made my point. While the filed contains = an email address, using it as such would result in a delivery failure. = The private key holder cannot be reached by this address. >>>>>=20 >>>>> Russ, i said: >>>>>=20 >>>>>> First of all, you can if you want to, >>>>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >>>>>=20 >>>>> Aka: Yes, if an ACP admin thinks ACME style challenge/reply >>>>> email authentication mechanism is useful, then he can of course >>>>> set up those email addresses accordingly. I did reply to that >>>>> point exhaustively in my reply about the ACME email mechanism. >>>>>=20 >>>>> Why do you ignore that answer ? >>>>>=20 >>>>>> and secondly, i contest that it is a requirement to be able >>>>>> to do that if the recipient doesn't need to support it. >>>>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >>>>>=20 >>>>>> Think about noreply@bad-corporation.com = . >>>>>> You do want to make sure though that you are in control of >>>>>> the electronic mail address though, and that is given for ACP >>>>>> addresses. >>>>>=20 >>>>> Where in rfc5280 or any other generic RFC about certificates = does >>>>> it say you MUST have a mailbox that is reachable ? Where does it >>>>> say that all certificiates with rfc822Name must be email boxes >>>>> that support ACME email style challenge-reply about the email = address ? >>>>> I think this is a non-existing requirement against email = addresses. >>>>>=20 >>>>> Of course, noreply@bad-corporation.com = can have a certificate with >>>>> that rfc822Name. It just can't use the ACME mechanism to be >>>>> generated. But the signed mails sent from that address can be >>>>> authenticated. >>>>>=20 >>>>> Or there are never emails, because the email address just serves >>>>> as identifier of an entity such as in wifi roaming = identification >>>>> and authentication. In that case you are not authenticating >>>>> e.g.: password ownership for the email address via actual emails >>>>> but via AAA protocols against a DNS domain known AAA server >>>>> for the domain part of the email address. >>>>>=20 >>>>> If you want to write a standards track RFC that all email = addresses >>>>> used in any X.509v3 certificate MUST support an ACME style >>>>> challenge/reply email, then please do that, and seee if you get >>>>> thast through. If would invalidate a lot of solutions like >>>>> those wifi roaming ones. It WOULD NOT invalidate the ACP >>>>> solution, because as said (no several times) the ACP solution >>>>> can perfectly be set up to support this. It just does not >>>>> need to. >>>>>=20 >>>>> Cheers >>>>> Toerless >>>>>=20 >>>>>> Russ >>>>>>=20 >>>>>>=20 >>>>>>> On Jun 27, 2020, at 1:40 AM, Toerless Eckert > wrote: >>>>>>>=20 >>>>>>> Russ, >>>>>>>=20 >>>>>>> Top posting re. your ACP vs. ACME question. >>>>>>>=20 >>>>>>> ACP rfc822name are meant to be under control of the ACP network = operations. >>>>>>> aka: the ACP registrars could be controlling = rfcSELF*@example.com mailboxes using >>>>>>> ACME S/MIME to get rfcSELF*@example.com = certificates or IMHO easier control >>>>>>> the acp.example.com MTA. Just no = need/benefit to do this now IMHO: >>>>>>>=20 >>>>>>> An ACP is a private network which is ideally isolated from other >>>>>>> ACP networks by use of private TA. Using the ACME rfc822name = scheme would >>>>>>> IMHO create a lot of attack components (all the MTA in the mail = path >>>>>>> and domain names) if used acros the Internet - without benefits = for >>>>>>> ACP. Of course, if it was all a private ACME setup within an = enterprise, >>>>>>> and using mailboxes and ACME is a popular choice - sure, why = not. >>>>>>> But for private CA setups there are existing IMO easier options >>>>>>> (private CA VMs using EST or the like). >>>>>>>=20 >>>>>>> IMHO public ACME CAwith S/MIME authenitcation could make sense >>>>>>> in the future to enable authentication across different ACP = domains. >>>>>>>=20 >>>>>>> Any network has links into other domains and today they are = usually >>>>>>> unauthenticated, that could be solved IMHO fairly easily. >>>>>>>=20 >>>>>>> "private" CA of ACP domain , lets call it acpCA signs all ACP = certs. >>>>>>> Its own cert is not self-signed, but signed by ACME CA via = S/MIME, >>>>>>> maybe email is rfcSELF@example.com = (no ACP IPv6 address in it) >>>>>>>=20 >>>>>>> Now the ACP nodes actually use acpCA PLUS ACMA CA's as TA. >>>>>>> After IKEv2 authenticates neigbor the followup ACP domain = membership >>>>>>> step checks if the TA of the peer is acpCA. If yes, then peer >>>>>>> becomes ACP member, otherwise we have an authenticated = signalling >>>>>>> channel to an interdomain / different CA peer. And that of = course >>>>>>> would enable better/secure auto-configuration of such = interdomain >>>>>>> links. >>>>>>>=20 >>>>>>> This gives me good mix of security: Its still only relying on >>>>>>> well controlled private TA to get into ACP, but also doubles >>>>>>> at less secure but best available "Internet/Interdomain" >>>>>>> authentication. >>>>>>>=20 >>>>>>> Cheers >>>>>>> Toerless >>>>>>>=20 >>>>>>> On Sun, Jun 21, 2020 at 12:36:06PM -0400, Russ Housley wrote: >>>>>>>>> On Jun 21, 2020, at 12:28 PM, Michael Richardson = > wrote: >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Russ Housley > wrote: >>>>>>>>>> One cannot send email to the character string in this = specification, so >>>>>>>>>> it should not be carried in the rfc822name. >>>>>>>>>=20 >>>>>>>>> You can send email to that character string if you configure = the MX. >>>>>>>>> It was designed specifically to accomodate that. >>>>>>>>>=20 >>>>>>>>> I objected at the time: I thought it was a stupid feature, = that no sensible IKEv2 daemon >>>>>>>>> was going to have to send/receive email. >>>>>>>>>=20 >>>>>>>>> But, Toerless was paranoid that if we did anything at all out = of the >>>>>>>>> ordinary, that the corporate CA people, in order to protect = their fiefdom, >>>>>>>>> would freak out and throw some huge roadblock in the way of = deploying the ACP. >>>>>>>>>=20 >>>>>>>>> And, now have an ACME method past WGLC that does certificate = validation by >>>>>>>>> SMTP. >>>>>>>>=20 >>>>>>>> Looking at the email certificate enrollment work in the ACME WG = (draft-ietf-acme-email-smime-08), I have a hard time seeing how the = device that knows the private key could participate in such a protocol. = How do you see it working? >>>>>>>>=20 >>>>>>>> Russ >>>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> Anima mailing list >>>>>>>> Anima@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/anima >>>>>>>=20 >>>>>>>=20 >>>>>>> -- >>>>>>> --- >>>>>>> tte@cs.fau.de >>>>>=20 >>>>> --=20 >>>>> --- >>>>> tte@cs.fau.de >>>>>=20 >>>>> _______________________________________________ >>>>> Anima mailing list >>>>> Anima@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/anima >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> Anima mailing list >>>>> Anima@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/anima >>>>>=20 >>>>=20 >>=20 >> --=20 >> --- >> tte@cs.fau.de >>=20 >> _______________________________________________ >> Anima mailing list >> Anima@ietf.org >> https://www.ietf.org/mailman/listinfo/anima >=20 > --=20 > --- > tte@cs.fau.de >=20 > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima From nobody Tue Jun 30 13:31:40 2020 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 629773A082C for ; Tue, 30 Jun 2020 13:31:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.87 X-Spam-Level: X-Spam-Status: No, score=-0.87 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=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 sg3vCn14Hnfp for ; Tue, 30 Jun 2020 13:31:33 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68F443A0837 for ; Tue, 30 Jun 2020 13:30:24 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [131.188.34.52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 7A32F548011; Tue, 30 Jun 2020 22:30:18 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 742CB440043; Tue, 30 Jun 2020 22:30:18 +0200 (CEST) Date: Tue, 30 Jun 2020 22:30:18 +0200 From: Toerless Eckert To: Eliot Lear Cc: Russ Housley , Eric Rescorla , Michael Richardson , Ben Kaduk , Eric Vyncke , barryleiba@computer.org, Anima WG Message-ID: <20200630203018.GC48194@faui48f.informatik.uni-erlangen.de> References: <3A92516D-B980-4231-9059-EF7234BA8610@vigilsec.com> <20200627054056.GA35664@faui48f.informatik.uni-erlangen.de> <20200627224640.GA41058@faui48f.informatik.uni-erlangen.de> <3A5D70B2-B3F9-42A6-9219-F25D657A7A7F@vigilsec.com> <20200628161149.GA16571@faui48f.informatik.uni-erlangen.de> <20200630161004.GA48194@faui48f.informatik.uni-erlangen.de> <69B9B7B6-4B75-4336-9F3F-45CD4FA51291@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <69B9B7B6-4B75-4336-9F3F-45CD4FA51291@cisco.com> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [Anima] Russ: Re: rfc822Name use in Autonomic Control Plane document X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2020 20:31:38 -0000 On Tue, Jun 30, 2020 at 08:59:24PM +0200, Eliot Lear wrote: > Hi Toerless, > > I think either a URI or otherName are pretty much functionally equivalent. I might go with URI for one particular reason, which is that the tooling ??? in particular OpenSSL ??? will handle it better. Thanks, Eliot. This was/is my initial thinking. let me see what i can put into the ntext rev. quickly. Just learned of one benefit of otherName in that it should also be possible to signal it in IKEv2 for IDi/IDr via ID_DER_ASN1_GN... I think ultimately we can define them to be interchangeably, but not quite sure how yet. Cheers toerless > > Eliot > > > On 30 Jun 2020, at 18:10, Toerless Eckert wrote: > > > > Just had a call with Russ and Barry (thanks Russ, Barry), and here is > > what transpired, and it comes with a Q to the ANIMA WG wrt. to > > solution options (see below). Hopefully Russ/Barry will correct me if i > > misrepresent anything. > > > > Russ and Barry agreed that a solutions where email addresses are not > > primarily intended to be used for actual emails (e.g.: using SMTP/RFC5321) > > may be something found in the wild, but in their opinion, it would create > > harm (to i guess the Internet email system), significant enough to warrant > > an IESG DISCUSS if such use was to be defined into an Internet Standard. > > > > If i understood it correctly, the choice of otherName by previous solutions > > similar might have also been influenced by the same rejection to use rfc822Name > > It sounded to me from the call as if email address/rfc822Name might have > > been desired to be used first by e.g.: XMPP but then they had to move to > > an otherName (RFC3920 i think) because of resistance to get that standardized. > > That at least would be a detail i was missing from the prior explanations on > > this thread. > > > > I continue to disagree, but i think the resolution of this basic > > argument would create an inacceptable timeline to progress ANIMA, > > so i do not want to afford this discussion any longer for the ACP draft. > > [ Hopefully i can get back to after ACP is done because i still think it > > is quite fundamental. ] > > > > a) Russ promised me a text stub or pointers thereto necessary/sufficient to define a new > > use (and i guess IANA registration). Probably something similar to > > what is e.g.: found in rfc8398. > > > > I think IANA registration is here: https://www.iana.org/assignments/smi-numbers/smi-numbers.xml > > See e.g.: id-on-SmtpUTF8Mailbox, > > registration procedure: spec required, expert: Russ Housley > > > > b) I brought up the point that using uniformResourceIdentifier instead > > of a new otherName would avoid that any part of the ecosystem including > > diagnostic tools would have to be software updated with new ASN.1 > > en/decode work and create unique names useable outside certificates as well. > > > > If we used "acp:@", this would require > > review process for the new "acp:" scheme, which according to my reading of > > process would take maybe up to one month. Barry suggested to simply > > register an IETF URN parameter (RFC3553), e.g.: > > > > urn:ietf:params:acp:@ > > > > IANA registry: https://www.iana.org/assignments/params/params.xhtml > > Registration procedure: IETF review (which i guess is the ACP draft IETF review). > > > > So, would love to hear opinions of a) vs. b). Am i overselling the URI option > > vs. the otherName option ? I have no experience on this backend side, i am > > just trying find the most pragmatic, easy to adopt option for operators, > > and i have seen a of backend systems (inventory management or the like) > > where names are shuffled around, and we started using email addresses because > > those are always supported identifier types in backend systems. No idea if URI are that common, > > but at least they could be there because they are an existing defined name/address type. > > For otherName, those uses outside certificates would need to come up with their own > > field type i think. > > > > Given how this is not an email address anymore, it > > would be prudent to introduce one degree of extensibility easier to manage: > > > > otherName: node:local@acp-domain-name > > URN: urn:ietf:params:acp:node:@ > > > > Where "node" is the value we define in ACP, and other values here > > are the extension points. > > > > Final note: of course we loose the ability to use public CA that an > > sign rfc822Name, e.g.: via ietf-acme-email-smime, which we would have > > if we whee permitted to use email addresses as ACP names, and i was getting > > fond of that option, but given how we did not perceive this nice option > > when we started ACP, its at least no set-back from the original ACP goals. > > > > Cheers > > Toerless > > > > On Sun, Jun 28, 2020 at 06:11:49PM +0200, Toerless Eckert wrote: > >> > >> On Sun, Jun 28, 2020 at 10:47:51AM -0400, Russ Housley wrote: > >>> Brian: > >>> > >>> The point of a certificate is to bind the public key to the identity of the private key holder. The certificate supports many different forms of names to support many different protocols. The rfc822name is used to bind to an email address. > >> > >> How do you think IETF should decide on what is a semantic correct > >> email address ? RFC5280 simply inherited the non-crypto definitions > >> of email address/mailbox. > >> > >> Do you think it is appropriate for you to recommend blocking progress > >> of a document through IESG review based on your interpretation what > >> does and what does not constitute a semantic correct email address ? > >> > >> Do you think that there are rfc2821 email addresses that are > >> semantically correct if not used in a certificate, but that are > >> not semantically correct for use in rfc5280 certificates ? If so, > >> can you please explain how such a differentiation would be justified > >> by existing RFC text ? > >> > >> If you do not think that there is a semantic correct email addresses > >> outside and inside of certificate/rfc822Name use, how then would > >> it be appropriate for you, Ben or LAMPS to decide on what is and > >> what is not a semantic correct email address. > >> > >>> And, something else is going on here. > >> > >> Are you saying the addresses are (1) semantic correct email addresses AND > >> something else is going on, or are you saying (2) they are NOT > >> semantic correct email addresses AND something else is going on. > >> > >> If you are saying (1), we are back to the above discussion of > >> the standing of how to decide what does and what does not > >> consitute a semantic correct email address. > >> > >> If you are saying (2), i fully agree, but i would need an explanation > >> of how such "something else" would invalidate the use of such > >> email addresses in rfc822Name, because i see no further requirements > >> against email addresses in rfc822Name other than what you showed > >> in a prior mair on this thread. > >> > >> If a terminal is assigned an email address of > >> "room17.terminal5@example.com", and the software says to the > >> user "you are sitting in Room17 on Terminal5", because the > >> software expected a particular formed local part of its > >> email address and parsed it, that is something else going on. > >> > >> If the same email address is then use together as an > >> identifier together with a password for the terminal to > >> access some resources, oh, like a library database, that is > >> also something else going on. > >> > >> This is pretty much what ACP does. What is IMHO is NOT going > >> on here is that these additional aspects render > >> room17.terminal5@example.com into a non semantic correct > >> email address. They just do more with it. > >> > >>> That is why I recommend otherName instead of rfc822name. > >> > >> No, if you would just recommend an alternative that would be great, > >> but you are blocking progress of a document that has a lot of > >> in our opinion crucial explanations how that alternative would > >> create more use-case harm than the solution choosen in the document. > >> > >>> I think that everyone understands that at this point. > >> > >> I do not understand how a recommendation like yours can raise to > >> a blocking DISCUSS in an IESG review. > >> > >>> Eric: > >>> > >>> Please change the write-up for this document. It currently says: > >>> > >>> (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? > >>> If so, please summarise the areas of conflict in separate email messages to the > >>> Responsible Area Director. (It should be in a separate email because this > >>> questionnaire is publicly available.) > >>> > >>> No. There was unanimous support for this work and nobody raised any objections. > >>> This is no longer the case. > >> > >> So, it is not a recommendation you are voicing, it is instead > >> "extreme discontent". > >> > >> I wonder what rules of IETF are for betting how such "extreme miscontent" > >> has to be technically founded or just needs to be taken into account > >> without suficient technical argument. I think you have provided > >> no clear technical reasoning for: > >> > >> - How does the documents choice cause more harm than the alternative > >> proposed for the use-cases or any other possible victims ? > >> - How is the choice in violation of any relevant RFC ? > >> - How are the email addresses not syntactic and semantic correct addresses according to rfc2821 ? > >> - How are otherwise statements like "i do not think this is the right thing" and > >> "there is something else going on here" sufficient arguments for blocking > >> IESG progressing the document. > >> > >> Cheers > >> Toerless > >> > >>> > >>> Russ > >>> > >>> > >>>> On Jun 27, 2020, at 11:09 PM, Brian E Carpenter wrote: > >>>> > >>>> Hi Eric, > >>>> > >>>> On 28-Jun-20 10:58, Eric Rescorla wrote: > >>>>> I'm not Russ, but I don't take his point to be about ACME one way or the other. > >>>>> > >>>>> Rather, I take his point to be (as he just said in his response to Brian) that while this is *formatted* as an e-mail address, it does not in fact correspond to something to which e-mail can be delivered > >>>> > >>>> It might do, simply because it is so formatted. > >>>> > >>>>> and therefore does not match the semantics of RFC 5280. > >>>> > >>>> RFC5280 does not require such a mailbox to exist. Is there another normative document, e.g. a BCP, that does require one? It's entirely possible that the authors of RFC5280 assumed that such a mailbox would exist, but this is not written anywhere that I can see. So IMNSHO, this objection to the ACP draft is attempting to hold it to a standard that isn't documented. > >>>> > >>>>> Taking a step back from the substantive issue, it seems to me that to the extent to which their is debate about the meaning of 5280, this is a discussion which cannot be resolved entirely on this list, but instead needs to involve the LAMPS WG. > >>>> > >>>> That may be true, but it's not ANIMA's fault and the discussion first arose last year, so why hasn't LAMPS already considered it, if it's important enough to continue obstructing ANIMA's progress? > >>>> > >>>> Brian > >>>> > >>>>> > >>>>> -Ekr > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> On Sat, Jun 27, 2020 at 3:46 PM Toerless Eckert > wrote: > >>>>> > >>>>> On Sat, Jun 27, 2020 at 11:52:20AM -0400, Russ Housley wrote: > >>>>>> Toerless: > >>>>>> > >>>>>> I think Brian actually made my point. While the filed contains an email address, using it as such would result in a delivery failure. The private key holder cannot be reached by this address. > >>>>> > >>>>> Russ, i said: > >>>>> > >>>>>> First of all, you can if you want to, > >>>>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > >>>>> > >>>>> Aka: Yes, if an ACP admin thinks ACME style challenge/reply > >>>>> email authentication mechanism is useful, then he can of course > >>>>> set up those email addresses accordingly. I did reply to that > >>>>> point exhaustively in my reply about the ACME email mechanism. > >>>>> > >>>>> Why do you ignore that answer ? > >>>>> > >>>>>> and secondly, i contest that it is a requirement to be able > >>>>>> to do that if the recipient doesn't need to support it. > >>>>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > >>>>> > >>>>>> Think about noreply@bad-corporation.com . > >>>>>> You do want to make sure though that you are in control of > >>>>>> the electronic mail address though, and that is given for ACP > >>>>>> addresses. > >>>>> > >>>>> Where in rfc5280 or any other generic RFC about certificates does > >>>>> it say you MUST have a mailbox that is reachable ? Where does it > >>>>> say that all certificiates with rfc822Name must be email boxes > >>>>> that support ACME email style challenge-reply about the email address ? > >>>>> I think this is a non-existing requirement against email addresses. > >>>>> > >>>>> Of course, noreply@bad-corporation.com can have a certificate with > >>>>> that rfc822Name. It just can't use the ACME mechanism to be > >>>>> generated. But the signed mails sent from that address can be > >>>>> authenticated. > >>>>> > >>>>> Or there are never emails, because the email address just serves > >>>>> as identifier of an entity such as in wifi roaming identification > >>>>> and authentication. In that case you are not authenticating > >>>>> e.g.: password ownership for the email address via actual emails > >>>>> but via AAA protocols against a DNS domain known AAA server > >>>>> for the domain part of the email address. > >>>>> > >>>>> If you want to write a standards track RFC that all email addresses > >>>>> used in any X.509v3 certificate MUST support an ACME style > >>>>> challenge/reply email, then please do that, and seee if you get > >>>>> thast through. If would invalidate a lot of solutions like > >>>>> those wifi roaming ones. It WOULD NOT invalidate the ACP > >>>>> solution, because as said (no several times) the ACP solution > >>>>> can perfectly be set up to support this. It just does not > >>>>> need to. > >>>>> > >>>>> Cheers > >>>>> Toerless > >>>>> > >>>>>> Russ > >>>>>> > >>>>>> > >>>>>>> On Jun 27, 2020, at 1:40 AM, Toerless Eckert > wrote: > >>>>>>> > >>>>>>> Russ, > >>>>>>> > >>>>>>> Top posting re. your ACP vs. ACME question. > >>>>>>> > >>>>>>> ACP rfc822name are meant to be under control of the ACP network operations. > >>>>>>> aka: the ACP registrars could be controlling rfcSELF*@example.com mailboxes using > >>>>>>> ACME S/MIME to get rfcSELF*@example.com certificates or IMHO easier control > >>>>>>> the acp.example.com MTA. Just no need/benefit to do this now IMHO: > >>>>>>> > >>>>>>> An ACP is a private network which is ideally isolated from other > >>>>>>> ACP networks by use of private TA. Using the ACME rfc822name scheme would > >>>>>>> IMHO create a lot of attack components (all the MTA in the mail path > >>>>>>> and domain names) if used acros the Internet - without benefits for > >>>>>>> ACP. Of course, if it was all a private ACME setup within an enterprise, > >>>>>>> and using mailboxes and ACME is a popular choice - sure, why not. > >>>>>>> But for private CA setups there are existing IMO easier options > >>>>>>> (private CA VMs using EST or the like). > >>>>>>> > >>>>>>> IMHO public ACME CAwith S/MIME authenitcation could make sense > >>>>>>> in the future to enable authentication across different ACP domains. > >>>>>>> > >>>>>>> Any network has links into other domains and today they are usually > >>>>>>> unauthenticated, that could be solved IMHO fairly easily. > >>>>>>> > >>>>>>> "private" CA of ACP domain , lets call it acpCA signs all ACP certs. > >>>>>>> Its own cert is not self-signed, but signed by ACME CA via S/MIME, > >>>>>>> maybe email is rfcSELF@example.com (no ACP IPv6 address in it) > >>>>>>> > >>>>>>> Now the ACP nodes actually use acpCA PLUS ACMA CA's as TA. > >>>>>>> After IKEv2 authenticates neigbor the followup ACP domain membership > >>>>>>> step checks if the TA of the peer is acpCA. If yes, then peer > >>>>>>> becomes ACP member, otherwise we have an authenticated signalling > >>>>>>> channel to an interdomain / different CA peer. And that of course > >>>>>>> would enable better/secure auto-configuration of such interdomain > >>>>>>> links. > >>>>>>> > >>>>>>> This gives me good mix of security: Its still only relying on > >>>>>>> well controlled private TA to get into ACP, but also doubles > >>>>>>> at less secure but best available "Internet/Interdomain" > >>>>>>> authentication. > >>>>>>> > >>>>>>> Cheers > >>>>>>> Toerless > >>>>>>> > >>>>>>> On Sun, Jun 21, 2020 at 12:36:06PM -0400, Russ Housley wrote: > >>>>>>>>> On Jun 21, 2020, at 12:28 PM, Michael Richardson > wrote: > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> Russ Housley > wrote: > >>>>>>>>>> One cannot send email to the character string in this specification, so > >>>>>>>>>> it should not be carried in the rfc822name. > >>>>>>>>> > >>>>>>>>> You can send email to that character string if you configure the MX. > >>>>>>>>> It was designed specifically to accomodate that. > >>>>>>>>> > >>>>>>>>> I objected at the time: I thought it was a stupid feature, that no sensible IKEv2 daemon > >>>>>>>>> was going to have to send/receive email. > >>>>>>>>> > >>>>>>>>> But, Toerless was paranoid that if we did anything at all out of the > >>>>>>>>> ordinary, that the corporate CA people, in order to protect their fiefdom, > >>>>>>>>> would freak out and throw some huge roadblock in the way of deploying the ACP. > >>>>>>>>> > >>>>>>>>> And, now have an ACME method past WGLC that does certificate validation by > >>>>>>>>> SMTP. > >>>>>>>> > >>>>>>>> Looking at the email certificate enrollment work in the ACME WG (draft-ietf-acme-email-smime-08), I have a hard time seeing how the device that knows the private key could participate in such a protocol. How do you see it working? > >>>>>>>> > >>>>>>>> Russ > >>>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>>> _______________________________________________ > >>>>>>>> Anima mailing list > >>>>>>>> Anima@ietf.org > >>>>>>>> https://www.ietf.org/mailman/listinfo/anima > >>>>>>> > >>>>>>> > >>>>>>> -- > >>>>>>> --- > >>>>>>> tte@cs.fau.de > >>>>> > >>>>> -- > >>>>> --- > >>>>> tte@cs.fau.de > >>>>> > >>>>> _______________________________________________ > >>>>> Anima mailing list > >>>>> Anima@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/anima > >>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> Anima mailing list > >>>>> Anima@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/anima > >>>>> > >>>> > >> > >> -- > >> --- > >> tte@cs.fau.de > >> > >> _______________________________________________ > >> Anima mailing list > >> Anima@ietf.org > >> https://www.ietf.org/mailman/listinfo/anima > > > > -- > > --- > > tte@cs.fau.de > > > > _______________________________________________ > > Anima mailing list > > Anima@ietf.org > > https://www.ietf.org/mailman/listinfo/anima -- --- tte@cs.fau.de From nobody Tue Jun 30 18:34:17 2020 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CAB73A08AA for ; Tue, 30 Jun 2020 18:34: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, 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 DCZRKdxQVI51 for ; Tue, 30 Jun 2020 18:34:14 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E800F3A08A5 for ; Tue, 30 Jun 2020 18:34:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 33BDF389BC for ; Tue, 30 Jun 2020 21:31:25 -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 80-_f4OzKOrP for ; Tue, 30 Jun 2020 21:31:24 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 70E8B389BB for ; Tue, 30 Jun 2020 21:31:24 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 8E146476 for ; Tue, 30 Jun 2020 21:34:11 -0400 (EDT) From: Michael Richardson To: Anima WG In-Reply-To: <69B9B7B6-4B75-4336-9F3F-45CD4FA51291@cisco.com> References: <9406.1592756905@localhost> <3A92516D-B980-4231-9059-EF7234BA8610@vigilsec.com> <20200627054056.GA35664@faui48f.informatik.uni-erlangen.de> <20200627224640.GA41058@faui48f.informatik.uni-erlangen.de> <3A5D70B2-B3F9-42A6-9219-F25D657A7A7F@vigilsec.com> <20200628161149.GA16571@faui48f.informatik.uni-erlangen.de> <20200630161004.GA48194@faui48f.informatik.uni-erlangen.de> <69B9B7B6-4B75-4336-9F3F-45CD4FA51291@cisco.com> 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: [Anima] Russ: Re: rfc822Name use in Autonomic Control Plane document X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2020 01:34:15 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Eliot Lear wrote: > I think either a URI or otherName are pretty much functionally > equivalent. I might go with URI for one particular reason, which is > that the tooling =E2=80=93 in particular OpenSSL =E2=80=93 will handl= e it better. Maybe the command line stuff, but for the API, it's an identical amount of effort. (I have running code). I don't think an ASN.1 encoded otherName will be better for IoT (or BFRS) because it force the ACP application developers to learn something about ASN.1, and history says they will get it wrong. (Because, as Nico says, lack of access to ASN1 code generators). I would prefer CBOR encoding, if there is consensus that it should not be a= string. This also anticipates more modern certificate-like artifacts (CoID). =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl776BMACgkQgItw+93Q 3WWGFAf/UD5DGy1GRpcL+NdpG3gannPtvQUXs/IzbDIAnmzIO+RyH0GfzTKGhBuR jEc+QEkXqiVgLwpt+h4rq4Brw7vc0vzBUZ/5qgfGXbEAzeJnKiyRY0AdsPmrLmZd gSG70JONp9eH643q6K56SeSnX4r9Hpmrm+xsB05nVxPzmTylo75irijekEhzRw8y xHzyhEKhgu0VR3AV0k9+QAO5SB63mDc6Z+zzVPkgCuKcGXVczkrE35jg4kK4pTLL LFjqJHsnbUa17VwABHs9CcEMNQDsJ0NJS4BFWFjsitaKquuGnWIM1JcbNN3YW7l1 p3oKjhkLVTKHgbkJmQKYezh7cV4KRw== =otUM -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Jun 30 18:59:48 2020 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21CC23A08E9 for ; Tue, 30 Jun 2020 18:59:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.65 X-Spam-Level: X-Spam-Status: No, score=-1.65 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 rb1_eX8fCe8X for ; Tue, 30 Jun 2020 18:59:44 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D7BC23A08E7 for ; Tue, 30 Jun 2020 18:59:43 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 84C7454843F; Wed, 1 Jul 2020 03:59:38 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 792E3440043; Wed, 1 Jul 2020 03:59:38 +0200 (CEST) Date: Wed, 1 Jul 2020 03:59:38 +0200 From: Toerless Eckert To: Michael Richardson Cc: Anima WG Message-ID: <20200701015938.GA34680@faui48f.informatik.uni-erlangen.de> References: <20200627054056.GA35664@faui48f.informatik.uni-erlangen.de> <20200627224640.GA41058@faui48f.informatik.uni-erlangen.de> <3A5D70B2-B3F9-42A6-9219-F25D657A7A7F@vigilsec.com> <20200628161149.GA16571@faui48f.informatik.uni-erlangen.de> <20200630161004.GA48194@faui48f.informatik.uni-erlangen.de> <69B9B7B6-4B75-4336-9F3F-45CD4FA51291@cisco.com> <23063.1593567251@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <23063.1593567251@localhost> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [Anima] Russ: Re: rfc822Name use in Autonomic Control Plane document X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2020 01:59:46 -0000 Well, i definitely want to strick to string because otherwise i would still have to write a standard human consumption representation, i had enough problem with real world code across different systems representing the same infor differently to the poor troubleshooter. Application layer code is mostly strings too, and if one wants to map a name from otherName into e.g.: URN (urn:ietf:params:acp:), then there would just be a 1:1 same on both sides. And just that consideration may be good enough right now not to have to bother with URN now in this doc but define this later when needed - if nodoby feels there is sufficient interop benefit to go to URI GeneralName instead of otherName (but me). Cheers Toerless On Tue, Jun 30, 2020 at 09:34:11PM -0400, Michael Richardson wrote: > > Eliot Lear wrote: > > I think either a URI or otherName are pretty much functionally > > equivalent. I might go with URI for one particular reason, which is > > that the tooling ??? in particular OpenSSL ??? will handle it better. > > Maybe the command line stuff, but for the API, it's an identical amount of > effort. (I have running code). > > I don't think an ASN.1 encoded otherName will be better for IoT (or BFRS) > because it force the ACP application developers to learn something about > ASN.1, and history says they will get it wrong. (Because, as Nico says, lack > of access to ASN1 code generators). > > I would prefer CBOR encoding, if there is consensus that it should not be a string. > This also anticipates more modern certificate-like artifacts (CoID). > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima -- --- tte@cs.fau.de From nobody Tue Jun 30 19:25:51 2020 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A1B33A091E for ; Tue, 30 Jun 2020 19:25:49 -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 B4rrmtcg808U for ; Tue, 30 Jun 2020 19:25:47 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B58B63A091C for ; Tue, 30 Jun 2020 19:25:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 7F174389B9; Tue, 30 Jun 2020 22:22:59 -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 qPFQMnap_tyL; Tue, 30 Jun 2020 22:22:59 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id E36303899F; Tue, 30 Jun 2020 22:22:58 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 17F07476; Tue, 30 Jun 2020 22:25:46 -0400 (EDT) From: Michael Richardson To: Toerless Eckert cc: Anima WG In-Reply-To: <20200701015938.GA34680@faui48f.informatik.uni-erlangen.de> References: <20200627054056.GA35664@faui48f.informatik.uni-erlangen.de> <20200627224640.GA41058@faui48f.informatik.uni-erlangen.de> <3A5D70B2-B3F9-42A6-9219-F25D657A7A7F@vigilsec.com> <20200628161149.GA16571@faui48f.informatik.uni-erlangen.de> <20200630161004.GA48194@faui48f.informatik.uni-erlangen.de> <69B9B7B6-4B75-4336-9F3F-45CD4FA51291@cisco.com> <23063.1593567251@localhost> <20200701015938.GA34680@faui48f.informatik.uni-erlangen.de> 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: [Anima] Russ: Re: rfc822Name use in Autonomic Control Plane document X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2020 02:25:49 -0000 --=-=-= Content-Type: text/plain Toerless Eckert wrote: > Well, i definitely want to strick to string because otherwise i would > still have to write a standard human consumption representation, i I prefer a string. mcr> I would prefer CBOR encoding, if there is consensus that it should not be a string. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl779CkACgkQgItw+93Q 3WWAEwgAp7o/qkbEmxsgLWcQGXHArdFrBXQqJAi2MLw/o7OMOfSBiK8VcDfJ2CNQ iyrekxHZgOBkQAKpDZf9CDCslMe7i7UlD2JyYTgpqbeNKzU1gpNqGwVU7qoTVepF BU6/xq0VcFTAE7t9zHGbY5M9tIkHCV5sJNfxSj/zN+BxMwUAIIYpHS16ITa9oOob DWjxNKsUExhZBzBkpIaZ9o6yr3TQzik/8sT8ENSUzZTDEPo9TyQv7MXsTLFm1yFh Gx0UjXcXIhc8wv84V+dqy9JBigznjntXVpTpCg/LcEL1KSmFYFZWBo829dDFp+jh R7b1uD33q+5b2snTCQAE6ovFOjkMVg== =8Rjm -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Jun 30 19:43:24 2020 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CF7E3A0996 for ; Tue, 30 Jun 2020 19:43:22 -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, FREEMAIL_FROM=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 NPjg4qBLkJxf for ; Tue, 30 Jun 2020 19:43:20 -0700 (PDT) Received: from mail-pg1-x530.google.com (mail-pg1-x530.google.com [IPv6:2607:f8b0:4864:20::530]) (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 C8EF53A0992 for ; Tue, 30 Jun 2020 19:43:20 -0700 (PDT) Received: by mail-pg1-x530.google.com with SMTP id p3so10941027pgh.3 for ; Tue, 30 Jun 2020 19:43:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=JEaQCuddAw3u4qC5rFj4cy+xayvA/nLwa+30mE5Za6k=; b=tsht08HLrTzKwpnXRKTmX+E0ShCY98fvURGJRVLVYCJh6A6IMGGqLw3WqpnjalIXYE PC/0RLsGLlnhxwdbX9TIfGgrf+mxQ+U1gnAPsI13E4agtLjDs8xv6Kno8HH1ZXc+cSM2 kp2+tXDu2H8RrviKyZXuxwF6Blv7Py3nrdj84MqCWc+Viaf2vV1KjTComnOPbjgoq0pz JYE7mOUlq+a2pgkqBrrgSgn0u/sC4a9rbjlmlkvaXnbY0PvvYaxg+uvOte/r1n4V6g3C XJ6O+AuTe5Qd4N4s926AGJ3SQati0wxAWd9sLCnVZ+uWiUefTptOXUDdIKRDUdSAAMmz sTvQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=JEaQCuddAw3u4qC5rFj4cy+xayvA/nLwa+30mE5Za6k=; b=SS2e1pfi/rZuKPc0Ky9qr3cW+9E4XCG6IJnb01ylY2hoEBTv3l7TI0bFRf2EHAffni QN4Uiaz1ap3DYwZLX1mNb7ZbSEWer7edFeTGwenKGfU0FDfBpO/UccqeU3OPXLghVzgJ KP2THKVCBRa31bIBPqQqdFGWy8CjrKJBs5TWQZuh/ZeD3LIppznUqXtjb976uBwFp6E9 tBYPwYihQXT3u4mVDrWc7GNu2OFXM6vBY2JilEiWbw3n2j4piE3rurSY7swZ9rOMuaWg jMs3c/t5encTswuxUGepTqW+QnsrXKAfodxrzCtX0/gadQqfJ3y0Gaxlpl0oPUjY/BUq xu/A== X-Gm-Message-State: AOAM5336oZ1hiopg2xQNMYtxdpSg5pWunyOHc3aSv4hZyHlguuXwJJc0 Ha78kz96tYfLrKgXTqZhd5NSCb7c X-Google-Smtp-Source: ABdhPJz0iPYRDz9NIRGH/yAHpp4b6LN3L5T8pIQ9MKGlXQdrYT7DIKCajnnsoVfz430duGs0JUL93Q== X-Received: by 2002:a62:a218:: with SMTP id m24mr23081810pff.156.1593571399943; Tue, 30 Jun 2020 19:43:19 -0700 (PDT) Received: from [192.168.178.20] (102.124.69.111.dynamic.snap.net.nz. [111.69.124.102]) by smtp.gmail.com with ESMTPSA id w9sm4051416pfq.178.2020.06.30.19.43.17 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 30 Jun 2020 19:43:19 -0700 (PDT) To: Michael Richardson , Anima WG References: <9406.1592756905@localhost> <3A92516D-B980-4231-9059-EF7234BA8610@vigilsec.com> <20200627054056.GA35664@faui48f.informatik.uni-erlangen.de> <20200627224640.GA41058@faui48f.informatik.uni-erlangen.de> <3A5D70B2-B3F9-42A6-9219-F25D657A7A7F@vigilsec.com> <20200628161149.GA16571@faui48f.informatik.uni-erlangen.de> <20200630161004.GA48194@faui48f.informatik.uni-erlangen.de> <69B9B7B6-4B75-4336-9F3F-45CD4FA51291@cisco.com> <23063.1593567251@localhost> From: Brian E Carpenter Message-ID: <108b7d1b-26b7-557a-f203-05f596550b13@gmail.com> Date: Wed, 1 Jul 2020 14:43:16 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <23063.1593567251@localhost> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Anima] Russ: Re: rfc822Name use in Autonomic Control Plane document X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2020 02:43:22 -0000 I do agree that avoiding ASN.1 is a very desirable goal, for exactly that reason: high probability of human error. So my gut feeling is to go for a URI. Regards Brian On 01-Jul-20 13:34, Michael Richardson wrote: >=20 > Eliot Lear wrote: > > I think either a URI or otherName are pretty much functionally > > equivalent. I might go with URI for one particular reason, which= is > > that the tooling =E2=80=93 in particular OpenSSL =E2=80=93 will h= andle it better. >=20 > Maybe the command line stuff, but for the API, it's an identical amount= of > effort. (I have running code). >=20 > I don't think an ASN.1 encoded otherName will be better for IoT (or BFR= S) > because it force the ACP application developers to learn something abou= t > ASN.1, and history says they will get it wrong. (Because, as Nico says,= lack > of access to ASN1 code generators). >=20 > I would prefer CBOR encoding, if there is consensus that it should not = be a string. > This also anticipates more modern certificate-like artifacts (CoID). >=20 > -- > Michael Richardson , Sandelman Software Works > -=3D IPv6 IoT consulting =3D- >=20 >=20 >=20 >=20 > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima >=20 From nobody Tue Jun 30 21:02:34 2020 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D497E3A0B37 for ; Tue, 30 Jun 2020 21:02: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 nqe_2QlMD8qs for ; Tue, 30 Jun 2020 21:02:32 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E02D3A0B33 for ; Tue, 30 Jun 2020 21:02:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 06D50389BA; Tue, 30 Jun 2020 23:59:44 -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 I9gD6Lnwatis; Tue, 30 Jun 2020 23:59:43 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 842E9389B4; Tue, 30 Jun 2020 23:59:43 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id BE96F1F9; Wed, 1 Jul 2020 00:02:30 -0400 (EDT) From: Michael Richardson To: Brian E Carpenter cc: Anima WG In-Reply-To: <108b7d1b-26b7-557a-f203-05f596550b13@gmail.com> References: <9406.1592756905@localhost> <3A92516D-B980-4231-9059-EF7234BA8610@vigilsec.com> <20200627054056.GA35664@faui48f.informatik.uni-erlangen.de> <20200627224640.GA41058@faui48f.informatik.uni-erlangen.de> <3A5D70B2-B3F9-42A6-9219-F25D657A7A7F@vigilsec.com> <20200628161149.GA16571@faui48f.informatik.uni-erlangen.de> <20200630161004.GA48194@faui48f.informatik.uni-erlangen.de> <69B9B7B6-4B75-4336-9F3F-45CD4FA51291@cisco.com> <23063.1593567251@localhost> <108b7d1b-26b7-557a-f203-05f596550b13@gmail.com> 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: [Anima] Russ: Re: rfc822Name use in Autonomic Control Plane document X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2020 04:02:34 -0000 --=-=-= Content-Type: text/plain Brian E Carpenter wrote: > I do agree that avoiding ASN.1 is a very desirable goal, for exactly > that reason: high probability of human error. So my gut feeling > is to go for a URI. otherName can trivially contain a UTF8 string. yes, there is an OID that goes in first, but it is already implemented. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl78CtYACgkQgItw+93Q 3WV4Cgf+MOSTFTmZuufLzP4l1SdqRQEy935TGJyZoyPgEEr3xuQgOmA01tgj0jCz zeXITYsQodyImgSJ31pGdEviVOrh7kFV/Sj/Cm56+1J0NIDnGksyd3ZBnFyZTvJ5 UMf7x8A5lhKAFAGDrqDTgfrpqEjSzJyvkc33CUQ2hi0lrz8qYdKFNjLnlY1suDxx NevscZuYhla4G2Si8NqpPY9n8J3S8yi8nHjz+4EOILmd032niEmiHfah01qP/F3c PBio779Be8+Y3pUKLNNIDFH7HsAkYP/Vjl+IAEG7MMtsXv75W/G3OfhXxCyhGEcN VvpwgKGxjl+cT5zQctHnB+HVN9AdBQ== =WORn -----END PGP SIGNATURE----- --=-=-=--