Re: [dtn] [EXT] Re: Important side issues from ACME Node ID Validation draft
Roman Danyliw <rdd@cert.org> Fri, 03 September 2021 14:13 UTC
Return-Path: <rdd@cert.org>
X-Original-To: dtn@ietfa.amsl.com
Delivered-To: dtn@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68A613A1FEA for <dtn@ietfa.amsl.com>; Fri, 3 Sep 2021 07:13:18 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=seicmu.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Da9KAEOg82OZ for <dtn@ietfa.amsl.com>; Fri, 3 Sep 2021 07:13:13 -0700 (PDT)
Received: from USG02-BN3-obe.outbound.protection.office365.us (mail-bn3usg02on0139.outbound.protection.office365.us [23.103.208.139]) (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 51DBE3A1FE7 for <dtn@ietf.org>; Fri, 3 Sep 2021 07:13:12 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector5401; d=microsoft.com; cv=none; b=cEwBmJx260RpfMMQ/0HAPyGeoWEySi+k0/4N8VMGLaeskIeNhGZ5A1iPENwR/cT4lvb+Cb0inXifwC4/9IPeZ3+Im9EEPP07xYMnic9PpIat8OuNHH1tftQ0hB0COYkRTRUGWBLgXhjMXwLLIRp6CgRuJzuZBd4qgkEGzFhMWYX+l4hBGZxzsV6ItKdXbRSiYSD4ad7Pb1TgebvkwGjkzzMG5UfEi3pdEGlig4+Od6cRXV0sOygp6gURDAdnMvmo0WjwfmQuX81HHBFtfMzSIP3wsCpUFd0NIZPns8nH+YVip/MRG40sto8hBxO7/6p528278Z3EReagGmGzwQeYfQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector5401; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Co5ANO2OOr4Vy2fLBYPa5xuarJW4x8JWxhRkLz6AbwM=; b=vcttWloPBnB5yNnavn+oZB0YrHnI8uRLEuAx8q3W3nn4szDWKsAFgI7zzza7Rcaan8VcWsRZ1SZg+9eZFZ8iJ2l4u4w1b249rnaIPGHF7FRA8fDGmCXqQway4DUw+Mc6n2/WLgeCYSHcGZcNInU4xY0Cbr6YgJumYEOBtE5CuRXxEH9KIATEXHNEUTWXvQ6feVgWK3p18QlYH8P/hOII2QHnwA59g7fw2qQwmPcFn/eVUcT+Zr5Nv7x6bLh/RCkmip/mSlFFirW7aHKhpb792EkOol/fzuUx4PCJyT24pM8FA54tPWueG3U3Jgm0w1dBvgs0MMOY2CAA+gK7EWMhoQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cert.org; dmarc=pass action=none header.from=cert.org; dkim=pass header.d=cert.org; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=seicmu.onmicrosoft.com; s=selector1-seicmu-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Co5ANO2OOr4Vy2fLBYPa5xuarJW4x8JWxhRkLz6AbwM=; b=NgPioTXLgyUpfOyGGs92KtdTh9BmUo0n0jnC4zAald6cjfnLwgDvNQWzQx3gassxMzeEu7hIwHuBLIb2RjZzoUCajhChuDZ25wdwdnYTpmbwB3TmMZvRlLcBl5Y4geIj+eALmq9mhLRvP1JlD+tH+0pElyq7ADq9u+rzI6cKIEo=
Received: from BN1P110MB0939.NAMP110.PROD.OUTLOOK.COM (2001:489a:200:134::12) by BN1P110MB0577.NAMP110.PROD.OUTLOOK.COM (2001:489a:200:135::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4478.21; Fri, 3 Sep 2021 14:13:09 +0000
Received: from BN1P110MB0939.NAMP110.PROD.OUTLOOK.COM ([fe80::93b:40b5:d4b6:9650]) by BN1P110MB0939.NAMP110.PROD.OUTLOOK.COM ([fe80::93b:40b5:d4b6:9650%5]) with mapi id 15.20.4478.022; Fri, 3 Sep 2021 14:13:09 +0000
From: Roman Danyliw <rdd@cert.org>
To: "dtn@ietf.org" <dtn@ietf.org>
Thread-Topic: Re: [dtn] [EXT] Re: Important side issues from ACME Node ID Validation draft
Thread-Index: Adegxqku/cncZNW+RCm6mw0bRz/vhg==
Date: Fri, 03 Sep 2021 14:13:09 +0000
Message-ID: <BN1P110MB093974F5B749DB68A304FBD2DCCF9@BN1P110MB0939.NAMP110.PROD.OUTLOOK.COM>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=cert.org;
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: bbaaa2c9-def3-418d-42b9-08d96ee4f548
x-ms-traffictypediagnostic: BN1P110MB0577:
x-microsoft-antispam-prvs: <BN1P110MB05770B25C94F012907641BF3DCCF9@BN1P110MB0577.NAMP110.PROD.OUTLOOK.COM>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: n50uxuH1xeNf2aL+pGjMDpY/Rn9ABvMHGO5TNumbHga2ZAzqsq2QHWjuvS6Qb5LVsolDMxdFX5LKrFmAP5rCruwTre7C1uiM8IDswu/sr6sPzP2iWtX2enkojSaidV3b/iAWBlhqxi2l6ZWtpbpltiSLxeBz07jVMlUp3jKSZPp4fanETGihk6kFQ7QkaPdIVXDWP8SIi7lSj4E7V5JQmT12ezY56fKfvvwEBsKPLcMnK09pIKCmmDQnikOQgHOevawn37KIRQBjDGF8DgG6BSTT/XE3TgJYbWCrY8tYZQOsLAC7VLK5+Yb5rDt8/dts34/n5t+3P0vMUUfFboi/evcy7AFXDN/R7RUvILnUJh5kfRDJnsGmuE0krvWJz4ZLy+pID4Y3h0JUy71mU1/jjNfGsVa6+/IZgNr6GGEoo5/uzDsD4RZJlvCI2yMcF2yUY18EfhQLr6bjBSIvNVzyBFjlkGhk+34wnu3RqES7WI3Iiaj6JfxCluG/Yh1pBJ/LNtZoR/3gmZIB330ihFgztHCgJDo1K/GHQy6W72v54DvYgwNYk9ra91YPguFIWg8y2WHm/EQRkXs8KfubBQBXJvhDKA//z17jeufQGajPfozTswGaK/UI9KxyiPiLX4th/FmL6BYh8zJXhR8U6uwvuuXMuj/SteXGFEafqZd7hGGujGMUd0shy9xosGX/1RIvquE00MCFmOq5kiaYXE52qw==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BN1P110MB0939.NAMP110.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(366004)(966005)(122000001)(66574015)(7696005)(9686003)(83380400001)(52536014)(30864003)(38100700002)(498600001)(55016002)(33656002)(86362001)(66946007)(66446008)(64756008)(38070700005)(66476007)(53546011)(6506007)(186003)(5660300002)(26005)(8676002)(76116006)(6916009)(2906002)(8936002)(66556008)(71200400001); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: cFs21xOfFV6XFMO9iIDFje6hAF2tubDZIAvzuaEetWkB9RkA3WFc3cyVAVg3nbIveLx0h20qO4lL19Uk9JtLoDOZAEon3dkjm9P1Gl0sOcoLQOr7mIsXJYUiXlmPTVoukHOA6AUULM5w/axyVZO/475PMLIBvc30NedD1U+y2fuNTSJqMEHUsR363FuDQ9kusrn3AfbZLQ8y1lwQPgV4tQwHOHw60AZoxrvIh2VxCw7wGhAJdz200FUL2x8pDyfRN8bNrZHNDSMQTHpLCA7pRR00VkDntRMdJM1oWAm658qJyMwCo8AvAGTz1jvhxGRbp42LObTUXM9uR7ju7E4ZHrf7W8gskNNNEAtHjT+9D5DvG8Rtxhw4e/GPupY+zbjlTXWAkngg6stv8qrIUBheTA8QCEHD3/eMrCYtrGh9mypHoiCHE5L586/B7wPqJ21tN74RwyRbp0xnoaliK3TP+hZ6r1AOEQ56nYC+yIx3J1j7lK2RmOZUsI7l3E1a/mLYZzc2BQdf8iuPKdI9jiyainAeDjgW3XbQI1ufckfPocup8nO90bTnShuz0SV+LnzI2w2yGuDYI/G4y4tXcbmFbKTWwo6CIUS+O6wu0Vm+jQNxzgWRl0kayWDNA1MYo79L5+zorgFSRcS1ixzWP+AZizSYtSsQmi1SpBDctM4htTi6O+BVpdOuv9v6gcsSCgXmkFlIT8Y5SmGcXUlDiGLBBA==
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: cert.org
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BN1P110MB0939.NAMP110.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-Network-Message-Id: bbaaa2c9-def3-418d-42b9-08d96ee4f548
X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Sep 2021 14:13:09.4699 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 95a9dce2-04f2-4043-995d-1ec3861911c6
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1P110MB0577
Archived-At: <https://mailarchive.ietf.org/arch/msg/dtn/C-f5NstIb5vzLg12RhBV6rwVFXw>
Subject: Re: [dtn] [EXT] Re: Important side issues from ACME Node ID Validation draft
X-BeenThere: dtn@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." <dtn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dtn>, <mailto:dtn-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dtn/>
List-Post: <mailto:dtn@ietf.org>
List-Help: <mailto:dtn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dtn>, <mailto:dtn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 03 Sep 2021 14:13:19 -0000
Hi Brian! On Wed, 01 September 2021 14:08 Brian Sipos <brian.sipos+ietf@gmail.com> wrote: > All, > I have a drafted (but not submitted to the datatracker) redline [1] to > TCPCLv4 for the NODE-ID encoding changes discussed earlier. It adds one new > IANA Considerations subsection for the otherName type and updates the one > paragraph that uses that new type. This can be wordsmithed if anything > seems vague or under-specified; specifically, there's no text explaining > the nuance of "it can encode any Endpoint ID but for this PKIX profile it > must contain only a Node ID". Something similar could be added if helpful. Thanks for staging this diff. The explicit mapping of NODE-ID to otherName seems like a good alternative, and it can be cascaded in the related ACME draft. At the risk of re-opening some of the unrelated text, but in the spirit of being extremely explicit on how NODE-ID (Node ID), DNS-ID (DNS Name) and IPADDR-ID (Network Address) are expected to map into certificates in DTN, I noticed that the text in Section 4.4.1 only provide guidance on NODE-ID and IPADDR-ID. The obvious is never said about DNS-ID. Specifically: NEW TEXT (to be symmetric with IPDADDR-ID) This specification defines a DNS-ID of a certificate as being the subjectAltName entry of type dNSName whose value is encoded according to [RFC5280]. Regards, Roman > [1] https://tools.ietf.org/rfcdiff?url1=https://www.ietf.org/archive/id/draft-ietf-dtn-tcpclv4-26.txt&url2=https://briansipos.github.io/dtn-bpbis-tcpcl/draft-ietf-dtn-tcpclv4.txt > > > > On Fri, Aug 27, 2021 at 5:55 PM Birrane, Edward J. < > Edward.Birrane@jhuapl.edu> wrote: > > Rick, > > > > Upon review, I agree with your (and Brian's) statement that NODE ID > should be preserved but not as a URL. > > > > DTNWG, > > > > This document ( > https://datatracker.ietf.org/doc/html/draft-ietf-dtn-tcpclv4) is > currently in the RFC editor "EDIT" state. There will be an update to the > document as part of responding to editor comments to produce a final > version of the RFC. This update as part of the editor process can be used > to correct errors in the document as they are identified. > > > > The question, of course, is whether the proposed correction to TCPCLv4 > (for NODE ID use an otherName with a new OID for Endpoint ID) is a > sufficient technical change to warrant restarting DTNWG technical review or > whether this is a correction that can take place as part of the existing > editing process. > > > > To that end, if you have a concern that this change requires more DTNWG > technical review, please say so on this list. > > > > Alternatively, if you believe that this change should proceed with other > corrections in the edit process, please post that as well. > > > > -Ed > > > > --- > Edward J. Birrane, III, Ph.D. (he/him/his) > > Embedded Applications Group Supervisor > > Space Exploration Sector > > Johns Hopkins Applied Physics Laboratory > (W) 443-778-7423 / (F) 443-228-3839 > > > > > *From:* Rick Taylor <rick@tropicalstormsoftware.com> > *Sent:* Wednesday, August 25, 2021 4:07 AM > *To:* Brian Sipos <brian.sipos+ietf@gmail.com> > *Cc:* Birrane, Edward J. <Edward.Birrane@jhuapl.edu>du>; R. Atkinson < > rja.lists@gmail.com>gt;; Brian Sipos <BSipos@rkf-eng.com>om>; dtn@ietf.org > *Subject:* RE: [dtn] [EXT] Re: Important side issues from ACME Node ID > Validation draft > > > > *APL external email warning: *Verify sender rick@tropicalstormsoftware.com > before clicking links or attachments > > > > Hi Brian, > > > > From my reading of BPv7, a Node-ID is just an Endpoint ID with a special > meaning (it's the EID of the node itself, rather than another service on > the node, or a multicast endpoint), so I suggest having the "otherName" OID > registered as "DTN Endpoint ID" type. > > > > There may be advantage to that flexibility beyond TCPCL, I can imagine > use-cases where services may need to assert an identity just as a node does > for TCPCL, and the generic "otherName" is the right tool for that job as > well. > > > > Cheers, > > > > Rick > > > > > > *From:* Brian Sipos [mailto:brian.sipos+ietf@gmail.com > <brian.sipos+ietf@gmail.com>] > *Sent:* 24 August 2021 21:35 > *To:* Rick Taylor > *Cc:* Birrane, Edward J.; R. Atkinson; Brian Sipos; dtn@ietf.org > *Subject:* Re: [dtn] [EXT] Re: Important side issues from ACME Node ID > Validation draft > > > > One remaining technical decision about this is: does the SAN otherName > allow only Node ID values or any Endpoint ID values. This certificate > profile will only have a use for Node ID, but this restriction is related > to the SAN otherName type definition and not how that type is used by the > profile. From the tool perspective, it seems a little easier to allow the > type to contain any EID. A non-Node-ID value won't match any CL peer Node > ID so there's no harm in the otherName value being an EID. > > > > On Tue, Aug 24, 2021 at 4:20 PM Brian Sipos <brian.sipos@gmail.com> wrote: > > Ed and Rick, > > The fundamental issue is that tools can and do make assumptions beyond the > already incompatible requirement from RFC 5280 that a SAN URI have an > internet name (DNS FQDN or IP address), and there are some pre-existing > issues anyway with tools using SAN URI and PKIX certificate constraints. > The SAN extension is the right place to put it, but the " > uniformResourceIdentifier" type . Like some other aspects of IETF > protocols, where PKIX uses generic "URI" or similar terms what they really > mean (and what tools/libraries can assume) "internet name URI." > > > > The change is to redefine what is a NODE-ID (it changes from a SAN URI to > a SAN otherName with a newly allocated type OID to specifically contain a > DTN EID value). This will require no change or conflict with RFC 5280 or > existing PKIX tooling or libraries. It will decouple the NODE-ID definition > from any earlier/other use of SAN URI. I can draft a modified TCPCL > document for these changes. > > > > Rick, you are correct that the current definitions can be used in some > circumstances (the proof-of-concept implementation works fine with Node IDs > such as "dtn://node-A/") can run into problems when node names fall outside > of allowed DNS names (e.g. "dtn://_node_A/" or other disallowed DNS name > characters "dtn://_&@/") tools can rightfully refuse to either issue or > accept certificates with these SAN URIs. > > > > On Mon, Aug 23, 2021 at 3:38 PM Rick Taylor < > rick@tropicalstormsoftware.com> wrote: > > Hi Brian, Ed, > > I personally agree with the ACME Sec review... I think subjectAltName is > the wrong field to be using for Node-ID in the certificate, and using it > definitely ties our hands with Naming and Addressing to only use Node-IDs > (and by extension Endpoint IDs) that map to RFC3986 valid formats. > > @Brian, Can you suggest some replacement text for the 3rd paragraph of > 4.4.1 that meet the ACME suggestion? > > Everyone else, do you consider the change to use a different field/type in > the certificate to be a change that requires returning TCPCLv4 to the WG. > Note that doing this will delay BPv7 and BPSec as they are all bound > together. > > With my chair hat on, I would suggest that the current text specifies the > wrong field to use, rather than specifying something functionally incorrect. > > Cheers, > > Rick > > > From: dtn [mailto:dtn-bounces@ietf.org] On Behalf Of Birrane, Edward J. > Sent: 23 August 2021 17:12 > To: Brian Sipos; R. Atkinson > Cc: Brian Sipos; dtn@ietf.org > Subject: Re: [dtn] [EXT] Re: Important side issues from ACME Node ID > Validation draft > > Brian, > > If I am reading the TCPCLv4 document correctly ( > https://datatracker.ietf.org/doc/html/draft-ietf-dtn-tcpclv4-26) then the > NODE-ID is optional, and instead a DNS-ID/IPADDR-ID may be used. > > If the bundle EID scheme (there may be more than dtn://) does not map > cleanly to a fully qualified domain name or IP address, my intuition is > that the DNS-ID/IPADDR-ID construct would need to be used instead. > > Since this is a TCP convergence layer, we already need to map a domain > name or an IP Address anyway. > > If that is the correct interpretation, it may be useful to strengthen > the wording in the draft, but I don't think we need a technical change. > > Am I missing something here? > > -Ed > > --- > Edward J. Birrane, III, Ph.D. (he/him/his) Embedded Applications Group > Supervisor Space Exploration Sector Johns Hopkins Applied Physics Laboratory > (W) 443-778-7423 / (F) 443-228-3839 > > > From: dtn <dtn-bounces@ietf.org> On Behalf Of Brian Sipos > Sent: Friday, August 20, 2021 3:36 PM > To: R. Atkinson <rja.lists@gmail.com> > Cc: Brian Sipos <BSipos@rkf-eng.com>om>; dtn@ietf.org > Subject: [EXT] Re: [dtn] Important side issues from ACME Node ID > Validation draft > > APL external email warning: Verify sender dtn-bounces@ietf.org before > clicking links or attachments > > All, > After further discussion in the ACME WG (security area), based on a need > to avoid the requirements on DNS-name/IP-address and to avoid both valid > and invalid assumptions made by tools/libraries about SAN URI contents, the > strong recommendation is to avoid the SAN uniformResourceIdentifier > entirely in favor of a new SAN otherName type-id OID which is used just for > DTN EID (and thus Node ID) claims. > > Unfortunately, this would require editing of a portion of the TCPCLv4 > draft now in the RFC editors queue, and a new IANA registration for the OID > under the "SMI Security for PKIX Other Name Forms" IANA sub-registry [6]. > Is this late edit an acceptable path for the document? > It would avoid many potential interoperability issues that were brought up > in the ACME discussion and require only slight change to a DTN > implementation to use a different SAN type (but identically encoded value). > > [6] > https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#smi-numbers-1.3.6.1.5.5.7.8 > > On Wed, Aug 11, 2021 at 11:20 AM R. Atkinson <rja.lists@gmail.com> wrote: > > > > On Jul 26, 2021, at 21:04, Brian Sipos <BSipos@rkf-eng.com> wrote: > > > > The second issue is unfortunately more technical; the "dtn" URI scheme > has been set in stone and is already in use, but the PKIX profile in [4] > specifically requires that when any SAN URI which includes an authority > part (the "dtn" scheme does, it is the node name) that authority is either > a DNS name or IP address. And we know that a Node ID is _not_ going to > contain a network-level name but some other name. This technically breaks > the profile in [5] as well as [2], which both use SAN URI as Node ID > authentication. Because neither RFC5280 nor RFC6125 require to dereference > the SAN URI and the DTN PKIX profiles explicitly avoid the URI-ID > definition of RFC6125, the only risk is really that some application may > inadvertently try to DNS probe the node name (or something like that). I > don't yet know how much of a blocking issue this will be, and it's > unfortunate that it wasn't noticed earlier. > > Brian, > > DNS Operations folks consider "noise" DNS queries (such as an application > trying to use DNS to resolve the node name or something similar) to be a > significant operational challenge - because the volume of "noise" DNS > queries already is high. > > I imagine the DNS Operations folks would be greatly unhappy at the > prospect of the DTN URI scheme being the cause of additional "noise" DNS > queries. > > A prospective change would be to update the PKIX profile in [4] to make > clear that a dtn URI is neither a DNS name nor an IP address - ever. > > In short, this looks like a real-world operational problem that will need > _some_ form of solution, even if different from the prospective change I > outlined just above. > > Yours, > > Ran > > _______________________________________________ > dtn mailing list > dtn@ietf.org > https://www.ietf.org/mailman/listinfo/dtn > >
- [dtn] Important side issues from ACME Node ID Val… Brian Sipos
- Re: [dtn] Important side issues from ACME Node ID… R. Atkinson
- Re: [dtn] Important side issues from ACME Node ID… Brian Sipos
- Re: [dtn] [EXT] Re: Important side issues from AC… Birrane, Edward J.
- Re: [dtn] [EXT] Re: Important side issues from AC… Rick Taylor
- Re: [dtn] [EXT] Re: Important side issues from AC… Brian Sipos
- Re: [dtn] [EXT] Re: Important side issues from AC… Brian Sipos
- Re: [dtn] [EXT] Re: Important side issues from AC… Rick Taylor
- Re: [dtn] [EXT] Re: Important side issues from AC… Birrane, Edward J.
- Re: [dtn] [EXT] Re: Important side issues from AC… sburleig.sb
- Re: [dtn] [EXT] Re: Important side issues from AC… Brian Sipos
- Re: [dtn] [EXT] Re: Important side issues from AC… Roman Danyliw
- Re: [dtn] [EXT] Re: Important side issues from AC… Brian Sipos
- Re: [dtn] [EXT] Re: Important side issues from AC… Brian Sipos
- Re: [dtn] [EXT] Re: Important side issues from AC… Birrane, Edward J.
- Re: [dtn] [EXT] Re: Important side issues from AC… Birrane, Edward J.