From nobody Thu Jan 10 14:26:53 2019 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DF7813128F for ; Thu, 10 Jan 2019 14:26:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 8GshbcFxoUrh for ; Thu, 10 Jan 2019 14:26:50 -0800 (PST) Received: from mail-wm1-x342.google.com (mail-wm1-x342.google.com [IPv6:2a00:1450:4864:20::342]) (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 DC8D8131287 for ; Thu, 10 Jan 2019 14:26:49 -0800 (PST) Received: by mail-wm1-x342.google.com with SMTP id f188so552447wmf.5 for ; Thu, 10 Jan 2019 14:26:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=xLhHLjcgRPWq5jGY2sPA6NPUVvc65ZkrlTMS0pAB7oA=; b=MmLTOteLWlLXUyumOfeVdGeDuLPdn4F/gjG7YMwhhCUMQlK/sSaznWhRq9j99kiPSC yRqyG4R4VFgHrl7ipdeFxNpgHNlJ4J6PImDE8iL6Ngd60fj1a+GxHX1MiMwyVPccNsXZ 4IX+0kXwYEqPYiB13Ao+zVjZ8C3ZnM+1PqSF3odP7L28vp3vLY+vVl6jz/1eM2Zdk1tF P0PFwO1Hv27pJNajcd7TitbZHwroTkjntRaQWK8Qs0VZMnuOgAZvOXDlzjU2bvNWgCNC Sfr+785ScBrOP27xZ40hOy0UBaajQDdMjS1yjcV+avTv5DKB0MJd1/oel2w2/j/uOtvj +0Fw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=xLhHLjcgRPWq5jGY2sPA6NPUVvc65ZkrlTMS0pAB7oA=; b=m9MTBZ5blPvCHNfMcJI8bxr9nOpr5KsUMhUXqJE9OrWMVZuBnf/Pbijhwe5zUbZshf dCbaASPei8n4n3embRPX/d2isjlew9E3eKnxob9SUT+2LFMGI0Ed9fYMqQcDl2K+pjon DLwtkdNyZxrNjakODB/XVVZOWbC+oZQAXu4+PUlBv577GxCM1FnvoilVRTLVv5T3WRJA 26pLLZtwozKEL58N8XHvb1dTqOUuJkYS8t4a1Bg0XXViAGsO6nxVcJcVlinTQoSNTQjT t+eZPZiU418SsX7uUhkFBNnmlNeuKiUpqDO4S6QMNCnY63Gtcl6U3AKJoZ/ecxyjl6Ae sruA== X-Gm-Message-State: AJcUukeY3DnVfRb2r7kVTNuUz8lwfzsBpmRPxRyV8GN+g5i/7QZaSo46 5EEVG/H9+G+mUXLOeI7mn+AC+DQsyTgrU1RvHzcQ+KT+ X-Google-Smtp-Source: ALg8bN6HfVQ/mfXXQmLedeQKlqpFmBPYSwDqlXPyieIHn0KcI+BzcdgvRuYTXCvc3Mm6J+a3iJRVNmAYVHufGvZoMPo= X-Received: by 2002:a1c:1f83:: with SMTP id f125mr504576wmf.56.1547159208275; Thu, 10 Jan 2019 14:26:48 -0800 (PST) MIME-Version: 1.0 From: Alberto Leiva Date: Thu, 10 Jan 2019 16:26:37 -0600 Message-ID: To: sidr@ietf.org, mlepinski@bbn.com, achi@bbn.com, kent@bbn.com, skent@bbn.com, dkong@bbn.com Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [sidr] RPKI: Are relying parties really supposed to validate DER encoding? X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jan 2019 22:26:52 -0000 Hello. I have a question: RFC 6488 section 3.1.l (https://tools.ietf.org/html/rfc6488#section-3) wants relying parties (RPs) to validate that all RPKI signed objects are DER-encoded, which (I think) means that they must be BER-encoded with minimal and unique representations. But I have found at least one other requirement that seems to contradict this: RFC 6482 section 3.3, fourth paragraph, second half, claims that a ROA (which is a signed object) is allowed to contain redundant ROAIPAddress elements. Furthermore, RFC 3779 (which is meaningfully referenced by the ROA and RPKI certificate (6487) RFCs) states the following: relying parties do not need to sort the information, or to implement extra code in the subset checking algorithms to handle several boundary cases (adjacent, overlapping, or subsumed ranges). Which seems to be paraphraseable as "RPs can parse signed objects as if they were BER-encoded, without worrying about DER." In fact, my reading of it is that the entirety of RFC 3779 seems to be of the mind that IP and AS extension writers are intended to strictly adhere to DER specifically for the sake of simplifying the task of RPs. RFC 6488, on the other hand, wants both to be strict. So what's the consensus? From nobody Thu Jan 10 14:39:08 2019 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 851241312B8 for ; Thu, 10 Jan 2019 14:39:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 l6cCzaLZjG8r for ; Thu, 10 Jan 2019 14:39:03 -0800 (PST) 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 297D91312B1 for ; Thu, 10 Jan 2019 14:39:03 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 83DD9300546 for ; Thu, 10 Jan 2019 17:20:45 -0500 (EST) 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 TcMc8oEO59D7 for ; Thu, 10 Jan 2019 17:20:44 -0500 (EST) Received: from a860b60074bd.fios-router.home (pool-108-45-137-105.washdc.fios.verizon.net [108.45.137.105]) by mail.smeinc.net (Postfix) with ESMTPSA id 2368A300064; Thu, 10 Jan 2019 17:20:44 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: Russ Housley In-Reply-To: Date: Thu, 10 Jan 2019 17:39:00 -0500 Cc: IETF SIDR Content-Transfer-Encoding: 7bit Message-Id: References: To: Alberto Leiva X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [sidr] RPKI: Are relying parties really supposed to validate DER encoding? X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jan 2019 22:39:06 -0000 See the Section on DER encoding at https://en.wikipedia.org/wiki/X.690. > On Jan 10, 2019, at 5:26 PM, Alberto Leiva wrote: > > Hello. > > I have a question: > > RFC 6488 section 3.1.l (https://tools.ietf.org/html/rfc6488#section-3) > wants relying parties (RPs) to validate that all RPKI signed objects > are DER-encoded, which (I think) means that they must be BER-encoded > with minimal and unique representations. > > But I have found at least one other requirement that seems to > contradict this: RFC 6482 section 3.3, fourth paragraph, second half, > claims that a ROA (which is a signed object) is allowed to contain > redundant ROAIPAddress elements. > > Furthermore, RFC 3779 (which is meaningfully referenced by the ROA and > RPKI certificate (6487) RFCs) states the following: > > relying parties do > not need to sort the information, or to implement extra code in the > subset checking algorithms to handle several boundary cases > (adjacent, overlapping, or subsumed ranges). > > Which seems to be paraphraseable as "RPs can parse signed objects as > if they were BER-encoded, without worrying about DER." > > In fact, my reading of it is that the entirety of RFC 3779 seems to be > of the mind that IP and AS extension writers are intended to strictly > adhere to DER specifically for the sake of simplifying the task of > RPs. RFC 6488, on the other hand, wants both to be strict. > > So what's the consensus? > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From nobody Thu Jan 10 15:00:21 2019 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDACF1312B8 for ; Thu, 10 Jan 2019 15:00:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 mZk0wzDm-RYd for ; Thu, 10 Jan 2019 15:00:17 -0800 (PST) Received: from mail-wr1-x429.google.com (mail-wr1-x429.google.com [IPv6:2a00:1450:4864:20::429]) (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 4962B130EFC for ; Thu, 10 Jan 2019 15:00:17 -0800 (PST) Received: by mail-wr1-x429.google.com with SMTP id x10so13205167wrs.8 for ; Thu, 10 Jan 2019 15:00:17 -0800 (PST) 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=Riy1pX2WnxyqQCU7cIIJ4k8ybnPk/isI/OmZiVJeHt8=; b=kQ1n/2eGzzGJGGxahGoCas8jSodOIvf7+9lYPCReXg5kVk1pq6Uyq+jrX6yQCFhwzq jud3vfMoZp1iWBvQJnKyzbrDZ3D9pZi/jO1uJLJ7vZ6+FLnV9TU3+PgP1AEZRFWA5wvb KUU/i8/t03bWMg3c+Z8YOn6s/ihewTnFzL/TMP0GVjGVZweJmIesy3cH0jGIUJtA3tyx mDQLqJcAG/VDrAW1MsDioZnt1wmfPnUd0zEZJ/9T02OT0DALr2N8GVoIMybfkBlUGMYW U7/1OHmt8zIXsyqa6YNBLdIFBADdQq6VG2XocWIQ3XAN60sH6rBTSjipaf3Aj9BHfS3a fOJg== 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=Riy1pX2WnxyqQCU7cIIJ4k8ybnPk/isI/OmZiVJeHt8=; b=nz1o7GWVSjb5Lb1P4dz6AcKNCrTsWGAoF1RoWBdaM7lU0+TCNK1rW8DOLZSJ8IZ7Mu X27FGExu+m2XoE0lzDai225x+pfmPAnaUJ3eBlRMGXfF76FeTq2LCkAsA5r025oho/yU BwBvHuOaATd1HTcfgI1wvoa/4Hu10h8YWN1baKVdagrHyg+tAgzG7KZm5UKrouMMAlkC U0Ss6LC0kU8yRS1PTr0YoAie5TmQEMUYsWtueJVjuWLNIhL6wpv98ZGNmBmPl+GFSjx1 paE55RFhLiNn4dusnLilAyxlqdFyYhvjeUWNY7m/UA57o5jbmWNaZin0nUsjMRGgtLia ewZQ== X-Gm-Message-State: AJcUukcBMar7pqMONQRMlFwiAYvbbtmX7JCDp7gqYCWl1UssmPnWJkfp zdzuTd5H8KXqpplNmgAsGnfBKPNO5ziDbjjPwWdZnQ== X-Google-Smtp-Source: ALg8bN7dWyL2e0kHuDpVChdRmwHJxGvJ7ZYgSLUIK+OxEv+MqVC0BvylCstYBWpEX6C0AdGIVfyx4eWmQMnWRv7R9B8= X-Received: by 2002:adf:b307:: with SMTP id j7mr11811913wrd.46.1547161215718; Thu, 10 Jan 2019 15:00:15 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Alberto Leiva Date: Thu, 10 Jan 2019 17:00:04 -0600 Message-ID: To: Russ Housley Cc: IETF SIDR Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [sidr] RPKI: Are relying parties really supposed to validate DER encoding? X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jan 2019 23:00:20 -0000 Ok, thanks. On Thu, Jan 10, 2019 at 4:39 PM Russ Housley wrote: > > See the Section on DER encoding at https://en.wikipedia.org/wiki/X.690. > > > On Jan 10, 2019, at 5:26 PM, Alberto Leiva wrote: > > > > Hello. > > > > I have a question: > > > > RFC 6488 section 3.1.l (https://tools.ietf.org/html/rfc6488#section-3) > > wants relying parties (RPs) to validate that all RPKI signed objects > > are DER-encoded, which (I think) means that they must be BER-encoded > > with minimal and unique representations. > > > > But I have found at least one other requirement that seems to > > contradict this: RFC 6482 section 3.3, fourth paragraph, second half, > > claims that a ROA (which is a signed object) is allowed to contain > > redundant ROAIPAddress elements. > > > > Furthermore, RFC 3779 (which is meaningfully referenced by the ROA and > > RPKI certificate (6487) RFCs) states the following: > > > > relying parties do > > not need to sort the information, or to implement extra code in the > > subset checking algorithms to handle several boundary cases > > (adjacent, overlapping, or subsumed ranges). > > > > Which seems to be paraphraseable as "RPs can parse signed objects as > > if they were BER-encoded, without worrying about DER." > > > > In fact, my reading of it is that the entirety of RFC 3779 seems to be > > of the mind that IP and AS extension writers are intended to strictly > > adhere to DER specifically for the sake of simplifying the task of > > RPs. RFC 6488, on the other hand, wants both to be strict. > > > > So what's the consensus? > > > > _______________________________________________ > > sidr mailing list > > sidr@ietf.org > > https://www.ietf.org/mailman/listinfo/sidr > From nobody Fri Jan 11 02:24:23 2019 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3745412DF71 for ; Fri, 11 Jan 2019 02:24:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] 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 mnekk9j26UCS for ; Fri, 11 Jan 2019 02:24:19 -0800 (PST) Received: from dicht.nlnetlabs.nl (dicht.nlnetlabs.nl [185.49.140.10]) (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 CC83F12D7EA for ; Fri, 11 Jan 2019 02:24:18 -0800 (PST) Received: from glaurung.nlnetlabs.nl (unknown [IPv6:2a04:b900:0:1:a2c5:89ff:feb5:e311]) by dicht.nlnetlabs.nl (Postfix) with ESMTPSA id 77DB523210; Fri, 11 Jan 2019 11:24:14 +0100 (CET) Authentication-Results: dicht.nlnetlabs.nl; dmarc=none (p=none dis=none) header.from=opennetlabs.com Date: Fri, 11 Jan 2019 11:24:13 +0100 From: Martin Hoffmann To: Alberto Leiva Cc: sidr@ietf.org Message-ID: <20190111112413.47060ed7@glaurung.nlnetlabs.nl> In-Reply-To: References: Organization: Open Netlabs X-Mailer: Claws Mail 3.17.2 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [sidr] RPKI: Are relying parties really supposed to validate DER encoding? X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2019 10:24:21 -0000 Alberto Leiva wrote: > Hello. > > I have a question: > > RFC 6488 section 3.1.l (https://tools.ietf.org/html/rfc6488#section-3) > wants relying parties (RPs) to validate that all RPKI signed objects > are DER-encoded, which (I think) means that they must be BER-encoded > with minimal and unique representations. > > But I have found at least one other requirement that seems to > contradict this: RFC 6482 section 3.3, fourth paragraph, second half, > claims that a ROA (which is a signed object) is allowed to contain > redundant ROAIPAddress elements. DER is only concerned with encoding, not with the content. Mostly, it forbids indefinite length constructed values and enforces string types to be primitively encoded. Unlike X.680, X.690 is actually quite readable. All of them are now available for free from the ITU. That all said, be warned that at least two RIRs currently produce RPKI signed objects that are not validly DER encoded, but rather seem to be using CER. So in practice, you will need to be able to parse the more generic BER at least at this time or loose a significant part of the RPKI repository. For Routinator, we decided to have a relaxed validation mode and documented all it does[0]. Currently, be default we run in relaxed mode and have a command line option for strict mode. Not sure if the working group needs to address this issue or how. Kind regards, Martin [0] https://github.com/NLnetLabs/rpki-rs/blob/master/doc/relaxed-validation.md From nobody Tue Jan 15 20:57:17 2019 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 149E01310EA for ; Tue, 15 Jan 2019 20:56:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 nDbFe68s_5H7 for ; Tue, 15 Jan 2019 20:56:06 -0800 (PST) Received: from mail-ed1-x534.google.com (mail-ed1-x534.google.com [IPv6:2a00:1450:4864:20::534]) (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 D71661310DA for ; Tue, 15 Jan 2019 20:56:02 -0800 (PST) Received: by mail-ed1-x534.google.com with SMTP id g22so4368715edr.7 for ; Tue, 15 Jan 2019 20:56:02 -0800 (PST) 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=OM8K5ltrNqyCLXOQs/z7H2b/ogWyaHFUZI5GsnTwJzs=; b=gx9cTe6e1YMq53VIL+13LCaLMAQCBWms131TiqgNfgxIY4+H/dG/G56SCr8DBSbLiR ORcIr7gJwf2HGwHUal1DPIHfd4dHoNA5KHgdaC9wGDX4uK3EHeKvjFVejXygz74eOv9m mibXSTN4TWR3UKKrYVjktUYo5zZhdk/+8Kqs4= 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=OM8K5ltrNqyCLXOQs/z7H2b/ogWyaHFUZI5GsnTwJzs=; b=a2HL2WDyRLtnxtO8RNkipIhB1Ugc45uqgY4NBwPNO0WJZs61ZVxSLw32sXknd3JhK0 iSx1YrucFpqqK+hEFlLbC6BIQFjnhVSHcrjKfMhepKjwTFG6+JcC1GgqbFM3n2JGCvlV VV2WBXvUZqE8nymOiV+B0pWJ06RJ2G9UZVpmoTItoTO3get2qCkUXLnd/PPghrpixdPR ZNumr/wEc5AhP2n4pOibH4uVGAtZ2Vkftrf3fzoN53LRZXy8cWSVgxaFfCYCtldaffDw 9pQPDUnBFiaY7p+V6ExFbRAAHBuV33ZQTcN4W0sNI2vFa7pY/3xWF1+tb+HJSxMlff5H H6mA== X-Gm-Message-State: AJcUukePXdxLUUnkbpxtST6w85W+j7I5JnGOEIBPp2mlJdgIQP2MvPmc HbbBFZJZj2JcIXppnnfyZqzARA== X-Google-Smtp-Source: ALg8bN7Cx75KVm+gGsMruCyBitUDVzEHzjNm9+Sap9PeF6X1MQQKGERJ25lQA+gBiTQTVXz2PUFVow== X-Received: by 2002:aa7:d684:: with SMTP id d4mr5685349edr.59.1547614561152; Tue, 15 Jan 2019 20:56:01 -0800 (PST) Received: from [5.5.33.23] (vpn.snozzages.com. [204.42.252.17]) by smtp.gmail.com with ESMTPSA id k26-v6sm3011536ejv.59.2019.01.15.20.55.57 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 15 Jan 2019 20:56:00 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: Sean Turner In-Reply-To: Date: Tue, 15 Jan 2019 20:55:57 -0800 Cc: SIDROps Chairs , ops-dir , IETF Discuss , SIDR Operations WG , sidr@ietf.org, draft-ietf-sidrops-rtr-keying.all@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <0D959FE6-928D-48E0-B748-A372F67F8B96@sn3rd.com> References: <154582975877.9431.8940530526143232465@ietfa.amsl.com> To: Christopher Morrow , Warren Kumari , Scott Bradner X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [sidr] Opsdir last call review of draft-ietf-sidrops-rtr-keying-02 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jan 2019 04:56:10 -0000 Apologies for just finding this now =E2=80=A6 I seem to remember a WG discussion about whether this draft should be = BCP or ST. We discussed BCP addressing both what the IETF wanted to be = the best practice as well as what is the actual current practice. Since = BGPsec was/is new it was/is hard to say it fell in the latter bucket and = there was at least one person who felt that the router and operator = driven methods weren=E2=80=99t the way to go in the future (hence why = there is s8 the "advanced deployment scenarios=E2=80=9D section). So = the WG said go ST and because this draft has exhausted me we just = changed it to ST. I will note that the SECDIR and RTGDIR both had this = same comment it seems like we=E2=80=99re back to BCP. I think there was = another message somewhere about changing this to BCP so I will do that = in -03 unless I hear otherwise. spt > On Dec 26, 2018, at 08:29, Christopher Morrow = wrote: >=20 > BCP seems like a fine answer here, I'm not remembering why we would = have swapped to ST from BCP. >=20 > On Wed, Dec 26, 2018 at 11:12 AM Warren Kumari = wrote: > [ + Sandy, Alvaro ] >=20 > On Wed, Dec 26, 2018 at 9:51 AM Scott Bradner wrote: > that use of a MUST is commendable but its not exactly an = interoperability issue=20 >=20 > to me =E2=80=9Cmust=E2=80=9D works in this case (and the other cases = in this document) >=20 > but, that said, 2119 has been misused for kinda a long time so its not = a new sin >=20 >=20 > This document has a long history -- it was originally a product of the = SIDR Working Group (as draft-ietf-sidr-rtr-keying), and only moved over = to SIDROPS recently, when SIDR closed down = (https://datatracker.ietf.org/wg/sidr/about/). >=20 > The document was originally a BCP = (https://datatracker.ietf.org/doc/draft-ietf-sidr-rtr-keying/09/), but = was changed to Standards Track in -10 = (https://www.ietf.org/archive/id/draft-ietf-sidr-rtr-keying-10.txt). >=20 >=20 > I have gone back through the agenda and minutes for IETF 92 = (https://datatracker.ietf.org/doc/agenda-92-sidr/), IETF 93 = (https://datatracker.ietf.org/doc/agenda-93-sidr/) and IETF 94 = (https://datatracker.ietf.org/doc/agenda-94-sidr/).=20 > I also went back and watched the video recordings from IETF 94: = https://youtu.be/fElkBi4UMEA?t=3D2397 and wasn't able to find any = discussion of why the change was made, but I *was* able to find some = changes made between -09 and -10 which seem to be the outcome of those = discussions.=20 >=20 > Authors / SIDROPS [0] & SIDR / chairs - can y'all remember why the = track change was made?=20 >=20 > Whatever the case, the IETF LC was done as Standards Track (a higher = level), and so it could always be "downgraded" to BCP / informational = during IESG Eval. > I personally think it "feels" like BCP, but I don't have full history = / inherited the document and don't want to be arbitrarily making = changes. >=20 >=20 > W > [0]: SIDROPS and SIDR participant overlap is almost 100%. >=20 >=20 > =20 > Scott >=20 > > On Dec 26, 2018, at 9:25 AM, Randy Bush wrote: > >=20 > > mornin=E2=80=99 scott, > >=20 > >> it is hard to see why it should be standards track or why it should=20= > >> be using RFC 2119 type terminology. > >=20 > > these are two separate issues. =20 > >=20 > > alvaro and the chairs can adjudicate what flavor of ice cream it = should > > be. it my memory says it was a wg decision. i really do not care. > >=20 > > as to 2119 language, i kinda feel it should remain. it is used > > sparingly. but is crucial when used. e.g. > >=20 > > all private keys MUST be protected when at rest in a secure > > fashion. > >=20 > > i suspect we would want to keep that strongly prescriptive; but it = is > > not a hill on which i am interested in dying. > >=20 > > randy >=20 >=20 >=20 > --=20 > I don't think the execution is relevant when it was obviously a bad = idea in the first place. > This is like putting rabid weasels in your pants, and later expressing = regret at having chosen those particular rabid weasels and that pair of = pants. > ---maf > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From nobody Wed Jan 16 12:15:14 2019 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60A38131131 for ; Wed, 16 Jan 2019 12:15:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.041 X-Spam-Level: X-Spam-Status: No, score=-2.041 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=kumari-net.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 wDSsgJ5rBH_t for ; Wed, 16 Jan 2019 12:15:09 -0800 (PST) Received: from mail-wr1-x434.google.com (mail-wr1-x434.google.com [IPv6:2a00:1450:4864:20::434]) (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 818B1130ED0 for ; Wed, 16 Jan 2019 12:15:08 -0800 (PST) Received: by mail-wr1-x434.google.com with SMTP id v13so8464898wrw.5 for ; Wed, 16 Jan 2019 12:15:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=HFNZ89Ckctn1lBaFaEEAVaWdtcVXA36whUt0I2UCWGg=; b=irUvobGH9rOn+AXxosD0ppx775WHBWv3GKvd/S+nyGTHuuKrt6tf2i4Y03gxhZYAPp 2Tp3ktkHkqZnbxeiEhqTnvwrltJ2oQP5IgZvDwLPdGC+pMbeP7zqVF5Mh6inWJNgdOXu RAyBRiXnU5+kS59KLhLr4zFL4NwaoJ4gUKlvKHS7qbfrjwqhHwHe9d6Cfur8fKhh0Vxe jAeSjTzH1aMuC/1G3PPi2eoR25zR8f3dkhvZHmGzBi2BGLN/O65ikAJcQFno31J0XIr6 e7WYenmGWcml5NwxByxS4W5Er5OXSr/rcHfQ1+4o+Bs5kDaUhO++dFa7xBg4pw7WtAIH Xi5A== 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=HFNZ89Ckctn1lBaFaEEAVaWdtcVXA36whUt0I2UCWGg=; b=a7xB2SBdy3yT+j1VXZX0phu2XfOQpE5FWHjmVgWmWxGQHjdpjaURistRT5IfCBU5bn 176O2ubiWN7Y+WFMQDyOCaU/mpjqg0mYVn3U9FxdmOCiJbZyCpT1DRLf4kivYvvUIvFE APkbBEqK3skdaL86NzgdQ4hjMPqtr0b9KKCekSMb94ZGgM9GoTeXN5HxsHaUOuqfYwS7 jokbh+FtmTMR7H3DhATU2/hnI0aqLA6CsD1y/sAMhoyBxulhioeLF5y6eguq/OkF4z8W VGP7iDDN5xmchOBCl8sdg1j5Q+tNwbnlxEoGnxSX+vQ0U/tFU8R5mIJtXM9tYckx3g/u JwVg== X-Gm-Message-State: AJcUukfgdED7V3IXCz7SqXMW6uPNYXv1WVbL62yUObNVEjcy+3hcI9Sj yqNKcbp6QdJvgIK17uG/CqaVH0C8dSc3WpNrlVv/PA== X-Google-Smtp-Source: ALg8bN54OJsrsgCj4s5bNJ5BXNTozwjr7DY7dipfscK5jXZYw6aQx6W99sKm4qTQG3QRsyd4hmO1Klll8nBpGm7wGTk= X-Received: by 2002:adf:f0c5:: with SMTP id x5mr8649261wro.77.1547669706604; Wed, 16 Jan 2019 12:15:06 -0800 (PST) MIME-Version: 1.0 References: <154582975877.9431.8940530526143232465@ietfa.amsl.com> <0D959FE6-928D-48E0-B748-A372F67F8B96@sn3rd.com> In-Reply-To: <0D959FE6-928D-48E0-B748-A372F67F8B96@sn3rd.com> From: Warren Kumari Date: Wed, 16 Jan 2019 15:14:30 -0500 Message-ID: To: Sean Turner Cc: Christopher Morrow , Scott Bradner , SIDROps Chairs , ops-dir , IETF Discuss , SIDR Operations WG , sidr@ietf.org, draft-ietf-sidrops-rtr-keying.all@ietf.org Content-Type: multipart/alternative; boundary="0000000000001799f9057f98efd2" Archived-At: Subject: Re: [sidr] Opsdir last call review of draft-ietf-sidrops-rtr-keying-02 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jan 2019 20:15:13 -0000 --0000000000001799f9057f98efd2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Jan 15, 2019 at 11:56 PM Sean Turner wrote: > Apologies for just finding this now =E2=80=A6 > > I seem to remember a WG discussion about whether this draft should be BCP > or ST. We discussed BCP addressing both what the IETF wanted to be the > best practice as well as what is the actual current practice. Since BGPs= ec > was/is new it was/is hard to say it fell in the latter bucket and there w= as > at least one person who felt that the router and operator driven methods > weren=E2=80=99t the way to go in the future (hence why there is s8 the "a= dvanced > deployment scenarios=E2=80=9D section). So the WG said go ST and because= this > draft has exhausted me we just changed it to ST. Ah, awesome, I'm glad someone remembers the original reason. > I will note that the SECDIR and RTGDIR both had this same comment it seem= s > like we=E2=80=99re back to BCP. I think there was another message somewh= ere about > changing this to BCP so I will do that in -03 unless I hear otherwise. > Yes please, and thank you for solving the mystery. W > > spt > > > On Dec 26, 2018, at 08:29, Christopher Morrow > wrote: > > > > BCP seems like a fine answer here, I'm not remembering why we would hav= e > swapped to ST from BCP. > > > > On Wed, Dec 26, 2018 at 11:12 AM Warren Kumari > wrote: > > [ + Sandy, Alvaro ] > > > > On Wed, Dec 26, 2018 at 9:51 AM Scott Bradner wrote: > > that use of a MUST is commendable but its not exactly an > interoperability issue > > > > to me =E2=80=9Cmust=E2=80=9D works in this case (and the other cases in= this document) > > > > but, that said, 2119 has been misused for kinda a long time so its not = a > new sin > > > > > > This document has a long history -- it was originally a product of the > SIDR Working Group (as draft-ietf-sidr-rtr-keying), and only moved over t= o > SIDROPS recently, when SIDR closed down ( > https://datatracker.ietf.org/wg/sidr/about/). > > > > The document was originally a BCP ( > https://datatracker.ietf.org/doc/draft-ietf-sidr-rtr-keying/09/), but was > changed to Standards Track in -10 ( > https://www.ietf.org/archive/id/draft-ietf-sidr-rtr-keying-10.txt). > > > > > > I have gone back through the agenda and minutes for IETF 92 ( > https://datatracker.ietf.org/doc/agenda-92-sidr/), IETF 93 ( > https://datatracker.ietf.org/doc/agenda-93-sidr/) and IETF 94 ( > https://datatracker.ietf.org/doc/agenda-94-sidr/). > > I also went back and watched the video recordings from IETF 94: > https://youtu.be/fElkBi4UMEA?t=3D2397 and wasn't able to find any > discussion of why the change was made, but I *was* able to find some > changes made between -09 and -10 which seem to be the outcome of those > discussions. > > > > Authors / SIDROPS [0] & SIDR / chairs - can y'all remember why the > track change was made? > > > > Whatever the case, the IETF LC was done as Standards Track (a higher > level), and so it could always be "downgraded" to BCP / informational > during IESG Eval. > > I personally think it "feels" like BCP, but I don't have full history / > inherited the document and don't want to be arbitrarily making changes. > > > > > > W > > [0]: SIDROPS and SIDR participant overlap is almost 100%. > > > > > > > > Scott > > > > > On Dec 26, 2018, at 9:25 AM, Randy Bush wrote: > > > > > > mornin=E2=80=99 scott, > > > > > >> it is hard to see why it should be standards track or why it should > > >> be using RFC 2119 type terminology. > > > > > > these are two separate issues. > > > > > > alvaro and the chairs can adjudicate what flavor of ice cream it shou= ld > > > be. it my memory says it was a wg decision. i really do not care. > > > > > > as to 2119 language, i kinda feel it should remain. it is used > > > sparingly. but is crucial when used. e.g. > > > > > > all private keys MUST be protected when at rest in a secure > > > fashion. > > > > > > i suspect we would want to keep that strongly prescriptive; but it is > > > not a hill on which i am interested in dying. > > > > > > randy > > > > > > > > -- > > I don't think the execution is relevant when it was obviously a bad ide= a > in the first place. > > This is like putting rabid weasels in your pants, and later expressing > regret at having chosen those particular rabid weasels and that pair of > pants. > > ---maf > > _______________________________________________ > > sidr mailing list > > sidr@ietf.org > > https://www.ietf.org/mailman/listinfo/sidr > > --=20 I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf --0000000000001799f9057f98efd2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Jan 15, 2019 at 11:56 PM Sean Turner <sean@sn3rd.com> wrote:
Apologies for just finding this no= w =E2=80=A6

I seem to remember a WG discussion about whether this draft should be BCP o= r ST.=C2=A0 We discussed BCP addressing both what the IETF wanted to be the= best practice as well as what is the actual current practice.=C2=A0 Since = BGPsec was/is new it was/is hard to say it fell in the latter bucket and th= ere was at least one person who felt that the router and operator driven me= thods weren=E2=80=99t the way to go in the future (hence why there is s8 th= e "advanced deployment scenarios=E2=80=9D section).=C2=A0 So the WG sa= id go ST and because this draft has exhausted me we just changed it to ST.= =C2=A0

Ah, awesome, I'm glad someone remem= bers the original reason.

=C2=A0
I will note that the SECDIR and RTGDIR bot= h had this same comment it seems like we=E2=80=99re back to BCP.=C2=A0 I th= ink there was another message somewhere about changing this to BCP so I wil= l do that in -03 unless I hear otherwise.

Ye= s please, and thank you for solving the mystery.
W

=C2= =A0

spt

> On Dec 26, 2018, at 08:29, Christopher Morrow <morrowc.lists@gmail.com> wr= ote:
>
> BCP seems like a fine answer here, I'm not remembering why we woul= d have swapped to ST from BCP.
>
> On Wed, Dec 26, 2018 at 11:12 AM Warren Kumari <warren@kumari.net> wrote:
> [ + Sandy, Alvaro ]
>
> On Wed, Dec 26, 2018 at 9:51 AM Scott Bradner <sob@sobco.com> wrote:
> that use of a MUST is commendable but its not exactly an interoperabil= ity issue
>
> to me =E2=80=9Cmust=E2=80=9D works in this case (and the other cases i= n this document)
>
> but, that said, 2119 has been misused for kinda a long time so its not= a new sin
>
>
> This document has a long history -- it was originally a product of the= SIDR Working Group (as draft-ietf-sidr-rtr-keying), and only moved over to= SIDROPS recently, when SIDR closed down (https://datatra= cker.ietf.org/wg/sidr/about/).
>
> The document was originally a BCP (https://datatracker.ietf.org/doc/draft-ietf-sidr-rtr-keying/09/), bu= t was changed to Standards Track in -10 (https://www.ietf.org/archive/id/draft-ietf-sidr-rtr-keying-10.txt= ).
>
>
> I have gone back through the agenda and minutes for IETF 92 (https://datatracker.ietf.org/doc/agenda-92-sidr/), IETF= 93 (https://datatracker.ietf.org/doc/agenda-93-sidr= /) and IETF 94 (https://datatracker.ietf.org/doc= /agenda-94-sidr/).
> I also went back and watched the video recordings from IETF 94: https://youtu.be/fElkBi4UMEA?t=3D2397 and wasn't able to find= any discussion of why the change was made, but I *was* able to find some c= hanges made between -09 and -10 which seem to be the outcome of those discu= ssions.
>
> Authors / SIDROPS [0] & SIDR / chairs -=C2=A0 can y'all rememb= er why the track change was made?
>
> Whatever the case, the IETF LC was done as Standards Track (a higher l= evel), and so it could always be "downgraded" to BCP / informatio= nal during IESG Eval.
> I personally think it "feels" like BCP, but I don't have= full history / inherited the document and don't want to be arbitrarily= making changes.
>
>
> W
> [0]: SIDROPS and SIDR participant overlap is almost 100%.
>
>
>=C2=A0
> Scott
>
> > On Dec 26, 2018, at 9:25 AM, Randy Bush <randy@psg.com> wrote:
> >
> > mornin=E2=80=99 scott,
> >
> >> it is hard to see why it should be standards track or why it = should
> >> be using RFC 2119 type terminology.
> >
> > these are two separate issues.=C2=A0
> >
> > alvaro and the chairs can adjudicate what flavor of ice cream it = should
> > be.=C2=A0 it my memory says it was a wg decision.=C2=A0 i really = do not care.
> >
> > as to 2119 language, i kinda feel it should remain.=C2=A0 it is u= sed
> > sparingly. but is crucial when used.=C2=A0 e.g.
> >
> >=C2=A0 =C2=A0 =C2=A0 all private keys MUST be protected when at re= st in a secure
> >=C2=A0 =C2=A0 =C2=A0 fashion.
> >
> > i suspect we would want to keep that strongly prescriptive; but i= t is
> > not a hill on which i am interested in dying.
> >
> > randy
>
>
>
> --
> I don't think the execution is relevant when it was obviously a ba= d idea in the first place.
> This is like putting rabid weasels in your pants, and later expressing= regret at having chosen those particular rabid weasels and that pair of pa= nts.
>=C2=A0 =C2=A0 ---maf
> _______________________________________________
> sidr mailing list
> sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr



--
I don't think the execution is relevant when= it was obviously a bad idea in the first place.
This is like putting ra= bid weasels in your pants, and later expressing regret at having chosen tho= se particular rabid weasels and that pair of pants.
=C2=A0 =C2=A0---maf<= /div>
--0000000000001799f9057f98efd2-- From nobody Sun Jan 20 13:17:36 2019 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE997130E5A for ; Sun, 20 Jan 2019 13:17:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_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 buOZFcfV44sK for ; Sun, 20 Jan 2019 13:17:29 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1802130E66 for ; Sun, 20 Jan 2019 13:17:29 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 45073B80E2F; Sun, 20 Jan 2019 13:17:25 -0800 (PST) To: mlepinski@bbn.com, skent@bbn.com, dkong@bbn.com, db3546@att.com, aretana.ietf@gmail.com, martin.vigoureux@nokia.com, morrowc@ops-netman.net, sandy@tislabs.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: jtk@depaul.edu, sidr@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20190120211725.45073B80E2F@rfc-editor.org> Date: Sun, 20 Jan 2019 13:17:25 -0800 (PST) Archived-At: Subject: [sidr] [Editorial Errata Reported] RFC6482 (5609) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jan 2019 21:17:35 -0000 The following errata report has been submitted for RFC6482, "A Profile for Route Origin Authorizations (ROAs)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata/eid5609 -------------------------------------- Type: Editorial Reported by: John Kristoff Section: GLOBAL Original Text ------------- 5. Security Considerations .........................................5 6. Acknowledgments .................................................6 7. References ......................................................6 7.1. Normative References .......................................6 7.2. Informative References .....................................6 Corrected Text -------------- 5. Security Considerations .........................................5 6. IANA Considerations .............................................6 7. Acknowledgments .................................................6 8. References ......................................................6 8.1. Normative References .......................................6 8.2. Informative References .....................................6 Notes ----- The Table of Contents omits the "IANA Considerations" section, which should be section 6, which consequently causes the numbered sections to be follow be labeled incorrectly. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6482 (draft-ietf-sidr-roa-format-12) -------------------------------------- Title : A Profile for Route Origin Authorizations (ROAs) Publication Date : February 2012 Author(s) : M. Lepinski, S. Kent, D. Kong Category : PROPOSED STANDARD Source : Secure Inter-Domain Routing Area : Routing Stream : IETF Verifying Party : IESG From nobody Tue Jan 22 09:33:35 2019 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF8F8130F70; Tue, 22 Jan 2019 09:33:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_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 wdhNLZwr2FJc; Tue, 22 Jan 2019 09:33:32 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D77C130F3C; Tue, 22 Jan 2019 09:33:32 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 02C74B804E0; Tue, 22 Jan 2019 09:33:26 -0800 (PST) To: jtk@depaul.edu, mlepinski@bbn.com, skent@bbn.com, dkong@bbn.com X-PHP-Originating-Script: 1005:errata_mail_lib.php From: RFC Errata System Cc: rfc-editor@rfc-editor.org, iesg@ietf.org, sidr@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20190122173327.02C74B804E0@rfc-editor.org> Date: Tue, 22 Jan 2019 09:33:26 -0800 (PST) Archived-At: Subject: [sidr] [Errata Verified] RFC6482 (5609) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jan 2019 17:33:34 -0000 The following errata report has been verified for RFC6482, "A Profile for Route Origin Authorizations (ROAs)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata/eid5609 -------------------------------------- Status: Verified Type: Editorial Reported by: John Kristoff Date Reported: 2019-01-20 Verified by: RFC Editor Section: Table of Contents Original Text ------------- 5. Security Considerations .........................................5 6. Acknowledgments .................................................6 7. References ......................................................6 7.1. Normative References .......................................6 7.2. Informative References .....................................6 Corrected Text -------------- 5. Security Considerations .........................................5 6. IANA Considerations .............................................6 7. Acknowledgments .................................................6 8. References ......................................................6 8.1. Normative References .......................................6 8.2. Informative References .....................................6 Notes ----- The Table of Contents omits the "IANA Considerations" section, which should be section 6, which consequently causes the numbered sections to be follow be labeled incorrectly. -------------------------------------- RFC6482 (draft-ietf-sidr-roa-format-12) -------------------------------------- Title : A Profile for Route Origin Authorizations (ROAs) Publication Date : February 2012 Author(s) : M. Lepinski, S. Kent, D. Kong Category : PROPOSED STANDARD Source : Secure Inter-Domain Routing Area : Routing Stream : IETF From nobody Mon Jan 28 10:46:38 2019 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF245131141 for ; Mon, 28 Jan 2019 10:46:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 WVtHF8QeRyVe for ; Mon, 28 Jan 2019 10:46:34 -0800 (PST) Received: from mail-wm1-x334.google.com (mail-wm1-x334.google.com [IPv6:2a00:1450:4864:20::334]) (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 C9DE8130E93 for ; Mon, 28 Jan 2019 10:46:33 -0800 (PST) Received: by mail-wm1-x334.google.com with SMTP id p6so15050231wmc.1 for ; Mon, 28 Jan 2019 10:46:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=b0STGBO6UGz58oRvDj2IIYedjuRNqrnOS9UgSkZ6GaM=; b=QzKnOwtKMMy03dJVyX8A9yz98Ic7ntQt2ZlI29pdVmogdTuAUXw0yKlfiJVbDChPvh PkQC4FLicVAbyaHfG5zP3u0H1l1wpI8W3n4TPj8NqcutOh8ZTdYqeviiQ0PqFkAUuLS6 PVx0zr8a4MZBvjBoIVLvlIqC4v4dPcv6JL74C9n+GjPJdqaTXf9y/1IP3ti/kUAuHv4u 6ePUmd3zVRUSlS+qygHUUG7txUQnjhGoVGpLE6gRiomEVv2vvSpS/QYM/B0oGiivRjWE HdumAk3qViwzq3np3psJ9rPiWFSBgksdMQGeeVB7k5yxz4oIhS10IqNA7BAmn7RfQ3Y2 BOKQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=b0STGBO6UGz58oRvDj2IIYedjuRNqrnOS9UgSkZ6GaM=; b=Mw/1Snm/RCmcoDuew52nS2c7o6rJs6eG64Fp5vs58nGKAa5DHmnwzR8JHwAPgfmXJP 33ikaJlr0APRFZOe/Qmld20L0WSjcptqhnkaASPPjIngf4Zowe0B6wzfqak0QOIBeQpX 6bGQ4jUyXfVwSObhL6w0oE6CmonWHz/0KsQ1T/OjYevJwiB2Rf94C6FCafHqityGoBiL JyoYDbbj0uF5pdRzg1vbd3N/lKgs1OuOTOFJ3lZOwtpksRpUi7L+jh2pXWe82QOg+qrD TI8A5vhcVVBN2vJTDHKIi/QZXyTpxPXuwuAQDFfTlwYTgyY8gczoIFyc1bRR7RY9X689 BhNA== X-Gm-Message-State: AJcUukf/1pUeiwsvtNJ+PPyLtALTfwyfLxLIKZmMNxO04se2AilI7zuk 6cTv5S+F7mKxvmhWHmkK2ji6qWAaDg9y6Z7eeOUmYIqTKic= X-Google-Smtp-Source: ALg8bN7isUzahtazaBrbpZXsdZAWu8V1+FIKK28HAgdQHih6icZ8pPexYoaLeINues+EOb5oyHqmkC7zWVsJBJIM3Vw= X-Received: by 2002:a1c:bc82:: with SMTP id m124mr17737538wmf.77.1548701192022; Mon, 28 Jan 2019 10:46:32 -0800 (PST) MIME-Version: 1.0 From: Alberto Leiva Date: Mon, 28 Jan 2019 12:46:21 -0600 Message-ID: To: sidr@ietf.org, mlepinski@bbn.com, achi@bbn.com, kent@bbn.com, skent@bbn.com, dkong@bbn.com Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [sidr] RPKI: Three questions regarding RFC 6487 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jan 2019 18:46:36 -0000 I have three questions: ==== 1 ==== Section 4.8.8.1 has the following paragraph: This extension MUST have an instance of an accessMethod of id-ad- caRepository, with an accessLocation form of a URI that MUST specify an rsync URI [RFC5781]. (...) Other accessDescription elements with an accessMethod of id-ad-caRepository MAY be present. In such cases, the accessLocation values describe alternate supported URI access mechanisms for the same directory. The ordering of URIs in this accessDescription sequence reflect the CA's relative preferences for access methods to be used by RPs, with the first element of the sequence being the most preferred by the CA. Those MUSTs confuse me. What is the intent behind them? 1. Exactly one of the caRepositories MUST be URI, and MUST be RSYNC: caRepository URI RSYNC caRepository other whatever caRepository other whatever caRepository other whatever 2. Exactly one of the URI caRepositories MUST be RSYNC: caRepository URI RSYNC caRepository URI other caRepository URI other caRepository other whatever 3. There MUST be at least one RSYNC URI caRepository: caRepository URI RSYNC caRepository URI RSYNC caRepository URI whatever caRepository other whatever 4. (Unlikely, I realize) All of the caRepositories which are URIs MUST be RSYNC: caRepository URI RSYNC caRepository URI RSYNC caRepository URI RSYNC caRepository other whatever ==== 2 ==== Is the above verdict supposed to be consistent with the other Access Descriptions in the RFC? They generally use somewhat different wording: AIA: The preferred URI access mechanisms is "rsync", and an rsync URI [RFC5781] MUST be specified with an accessMethod value of id-ad-caIssuers. (...) Other accessMethod URIs referencing the same object MAY also be included in the value sequence of this extension. CA SIA.rpkiManifest: This extension MUST have an instance of an AccessDescription with an accessMethod of id-ad-rpkiManifest, (...) with an rsync URI [RFC5781] form of accessLocation. (...) Other accessDescription elements MAY exist for the id-ad-rpkiManifest accessMethod, where the accessLocation value indicates alternate access mechanisms for the same manifest object. EE SIA: This extension MUST have an instance of an accessMethod of id-ad- signedObject, (...) with an accessLocation form of a URI that MUST include an rsync URI [RFC5781]. (...) Other accessDescription elements may exist for the id-ad-signedObject accessMethod, where the accessLocation value indicates alternate URI access mechanisms for the same object, ordered in terms of the EE's relative preference for supported access mechanisms. Other AccessMethods MUST NOT be used for an EE certificates's SIA. ==== 3 ==== Section 4.8.8.2: Other AccessMethods MUST NOT be used for an EE certificates's SIA. It seems that this requirement has been superseded by RFC 8182: Certificate Authorities that use RRDP MUST include an instance of an SIA AccessDescription extension in resource certificates they produce, in addition to the ones defined in [RFC6487]: (...) This extension MUST use an accessMethod of id-ad-rpkiNotify (...) Has it been superseded? Or does the second quote only apply to CA certificates? (which would make the word "produce" seemingly out of place.) (Aside: 8182 does not appear in the 6487 Updated By list.) From nobody Tue Jan 29 01:38:27 2019 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9ECFE1274D0 for ; Tue, 29 Jan 2019 01:38:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.001 X-Spam-Level: X-Spam-Status: No, score=-7.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nlnetlabs.nl Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E-yo-F549Zk2 for ; Tue, 29 Jan 2019 01:38:23 -0800 (PST) Received: from dicht.nlnetlabs.nl (dicht.nlnetlabs.nl [185.49.140.10]) (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 D3AE5130F3C for ; Tue, 29 Jan 2019 01:38:22 -0800 (PST) Received: from [192.168.192.27] (dhcp-089-098-091-015.chello.nl [89.98.91.15]) by dicht.nlnetlabs.nl (Postfix) with ESMTPSA id CAFCD1F209; Tue, 29 Jan 2019 10:38:19 +0100 (CET) Authentication-Results: dicht.nlnetlabs.nl; dmarc=fail (p=none dis=none) header.from=nlnetlabs.nl Authentication-Results: dicht.nlnetlabs.nl; spf=fail smtp.mailfrom=tim@nlnetlabs.nl DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1548754699; bh=7afa/ywSvyJSXRestlGxrpZWDH0WEXu99unUC+Ov5qQ=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=doYvfT7btKx7XbEgivuC6C2QJJwal/sXDoS9+x4kL/a0l+cDhyA7hJ5/s5ixGGcG1 zUbc3G3b9W+nt4xlcb/pMrcBPf37W636j547QSxUP0db3N0uO0aicFNBMeF/4TCG2K FArFXVx6rJJhHurStJqfDQ/2lTe0/j/lvKAz69ho= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: Tim Bruijnzeels In-Reply-To: Date: Tue, 29 Jan 2019 10:38:19 +0100 Cc: IETF SIDR , Matt Lepinski Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Alberto Leiva X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [sidr] RPKI: Three questions regarding RFC 6487 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jan 2019 09:38:26 -0000 Hi Alberto, [removing the email addresses which I think are no longer valid] I am not an author of this RFC, but I wanted to share my interpretation = as an implementer of CA and RP software. > On 28 Jan 2019, at 19:46, Alberto Leiva wrote: >=20 > I have three questions: >=20 > =3D=3D=3D=3D 1 =3D=3D=3D=3D >=20 > Section 4.8.8.1 has the following paragraph: >=20 > This extension MUST have an instance of an accessMethod of id-ad- > caRepository, with an accessLocation form of a URI that MUST specify > an rsync URI [RFC5781]. (...) Other accessDescription elements with > an accessMethod of id-ad-caRepository MAY be present. In such = cases, > the accessLocation values describe alternate supported URI access > mechanisms for the same directory. The ordering of URIs in this > accessDescription sequence reflect the CA's relative preferences for > access methods to be used by RPs, with the first element of the > sequence being the most preferred by the CA. >=20 > Those MUSTs confuse me. What is the intent behind them? I agree that this is somewhat confusing. My interpretation of this is = that the text tries to leave the option for future transport protocols, = other than rsync, open. However, there are no accepted other transport = protocols defined at this time. > 1. Exactly one of the caRepositories MUST be URI, and MUST be RSYNC: >=20 > caRepository URI RSYNC > caRepository other whatever > caRepository other whatever > caRepository other whatever >=20 > 2. Exactly one of the URI caRepositories MUST be RSYNC: >=20 > caRepository URI RSYNC > caRepository URI other > caRepository URI other > caRepository other whatever >=20 > 3. There MUST be at least one RSYNC URI caRepository: >=20 > caRepository URI RSYNC > caRepository URI RSYNC > caRepository URI whatever > caRepository other whatever >=20 > 4. (Unlikely, I realize) All of the caRepositories which are URIs MUST > be RSYNC: >=20 > caRepository URI RSYNC > caRepository URI RSYNC > caRepository URI RSYNC > caRepository other whatever caRepository MUST be a URI, not other. There MUST be one and only one = rsync. There MAY, in future, other URIs for 'alternate URI access = mechanisms' - one for each. However, no other such mechanisms are = defined. So, for all intents and purposes you can expect 1 and only 1 SIA of the = type caRepository and it MUST use rsync. > =3D=3D=3D=3D 2 =3D=3D=3D=3D >=20 > Is the above verdict supposed to be consistent with the other Access > Descriptions in the RFC? They generally use somewhat different = wording: >=20 > AIA: >=20 > The preferred > URI access mechanisms is "rsync", and an rsync URI [RFC5781] MUST be > specified with an accessMethod value of id-ad-caIssuers. (...) > Other accessMethod URIs referencing the same object MAY also be > included in the value sequence of this extension. One, rsync. And the value of the AIA is rather limited. It provides a = hint to where the parent certificate may be found, but this may be = incorrect without invalidating the object. Typically the certificate is = found through top-down validation so the parent CA certificate is = already known. > CA SIA.rpkiManifest: >=20 > This extension MUST have an instance of an AccessDescription with an > accessMethod of id-ad-rpkiManifest, (...) > with an rsync URI [RFC5781] form of accessLocation. (...) > Other accessDescription elements MAY exist for the = id-ad-rpkiManifest > accessMethod, where the accessLocation value indicates alternate > access mechanisms for the same manifest object. Again my interpretation is that there can be only one SIA of this type = in practice, and it MUST be rsync. >=20 > EE SIA: >=20 > This extension MUST have an instance of an accessMethod of id-ad- > signedObject, (...) > with an accessLocation form of a URI that MUST include an rsync URI > [RFC5781]. (...) Other accessDescription > elements may exist for the id-ad-signedObject accessMethod, where = the > accessLocation value indicates alternate URI access mechanisms for > the same object, ordered in terms of the EE's relative preference = for > supported access mechanisms. >=20 > Other AccessMethods MUST NOT be used for an EE certificates's SIA. Same.. Except that in this case I really feel that this is a formality. This = SIA points to the object itself. I assume that you won't need this = information once you have found the object. > =3D=3D=3D=3D 3 =3D=3D=3D=3D >=20 > Section 4.8.8.2: >=20 > Other AccessMethods MUST NOT be used for an EE certificates's SIA. >=20 > It seems that this requirement has been superseded by RFC 8182: >=20 > Certificate Authorities that use RRDP MUST include an instance of an > SIA AccessDescription extension in resource certificates they > produce, in addition to the ones defined in [RFC6487]: > (...) > This extension MUST use an accessMethod of id-ad-rpkiNotify (...) >=20 > Has it been superseded? Or does the second quote only apply to CA > certificates? (which would make the word "produce" seemingly out of > place.) >=20 > (Aside: 8182 does not appear in the 6487 Updated By list.) Good point, and I see another omission upon re-reading RFC8182 (RRDP) - = of which I am a co-author.. The SIA defined in section 3.2 of RFC8182 is intended as an addition to = the existing SIAs defined in RFC6487. Furthermore it is only expected to = be present in CA certificates, since these are the only currently = defined RPKI objects for which signed products may be found. Including = the id-ad-rpkiNotify in an SIA of en EE certificate of e.g. a manifest = does not hurt, but it's also pointless. This intent is phrased in the = last paragraph of 3.2: The accessLocation MUST be an HTTPS URI as defined in [RFC7230] that will point to the Update Notification File for the Repository Server = that publishes the products of this Certificate Authority certificate. ^^^^^^^^^^^^^^^^^^^^ But this is not phrased as clearly as it could have been. >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From nobody Wed Jan 30 07:55:46 2019 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9416B124C04 for ; Wed, 30 Jan 2019 07:55:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 Tz0hUWLrEv4Q for ; Wed, 30 Jan 2019 07:55:42 -0800 (PST) Received: from mail-wm1-x334.google.com (mail-wm1-x334.google.com [IPv6:2a00:1450:4864:20::334]) (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 2D59B12426E for ; Wed, 30 Jan 2019 07:55:42 -0800 (PST) Received: by mail-wm1-x334.google.com with SMTP id d15so26284wmb.3 for ; Wed, 30 Jan 2019 07:55:42 -0800 (PST) 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:content-transfer-encoding; bh=BcHCetauLtzcZoWSgKMR2KY/T+4keJ6Bvb4ajnTtr5Y=; b=IzS+4gHX7rXoSv0U3ao/sBXy8+/B3EEixd8sXnq0kZiZSJSeksOg5jv+MTLSkk0wwf lhoOy7mqmiqsmUl4pnBeuZ6H5DetmT1js0mT5dWFCnFeGWsBpiS7mnMrJNq4fmryQdX1 lGE75eiieMDBdXTB5JWZaPctVXfdngNLudL36vjRdVnGmyvNqDYpFmgp5j85MRV5L9bO iCQNrTkb7CxWh8ZRvgnHleGRLg6V8k6lExOAgET0vXk/dee0ZemDvyu9/M3gHtfS8CVv VV6ZDcCdHDPwZ72zZwFUkuLHn1ceKzsrZHvhKqOI/7iRmx20A/nCvnt+jzMeAEvE43D0 o8Jg== 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:content-transfer-encoding; bh=BcHCetauLtzcZoWSgKMR2KY/T+4keJ6Bvb4ajnTtr5Y=; b=fH8P/nKDadoRUFU3fQHlUXzyrXmostP9Hj6o+LxPHrjv1aEfAUN6mWR023ZSJ59wUa LaiWnBj4DM0rvD297g07qTNiXATMzSUyTds8s1hFbnb/m8CzDl//8HzrUyktVzjy10VA 4t8aIqJGL2kfVghAHIurg8D4B5lH1KvY3ERISCKdi1QFYtDc/ZVVqyPY/l5h3DZOwqq7 Qb29PZQmRrsx+btIHjnASFQ2thQ70S7zjss5sfrvRXXYh3R9/RKGD4V4xljHvbmdsGE3 iJQg8/Y0gO6N4qU0wmH8/Z+UL7BmiJ3X6e6NrY1IvfkcXektV5E6NKhBQ5r9CzSO25hF Wtpg== X-Gm-Message-State: AJcUukeH/caoVKl7lzPkCUYIWZuSnW4EL2KAhkTwArmKW/rbo5AQ/9sA so0PM5iERzS/dDEYnRRv81LF1bZdcpPEdN+ZhUw= X-Google-Smtp-Source: ALg8bN6khvRk118D0J0ELVKihzqh0iXkv+OodMK425n8g1MfepEl4Az3uyXDUj6qdHWvEK4cvkqpAfZIXPo5kVt1RXE= X-Received: by 2002:a1c:7dd7:: with SMTP id y206mr25792147wmc.50.1548863740478; Wed, 30 Jan 2019 07:55:40 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Alberto Leiva Date: Wed, 30 Jan 2019 09:55:29 -0600 Message-ID: To: Tim Bruijnzeels Cc: IETF SIDR , Matt Lepinski Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [sidr] RPKI: Three questions regarding RFC 6487 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jan 2019 15:55:45 -0000 Thank you! On Tue, Jan 29, 2019 at 3:38 AM Tim Bruijnzeels wrote: > > Hi Alberto, > > [removing the email addresses which I think are no longer valid] > > I am not an author of this RFC, but I wanted to share my interpretation a= s an implementer of CA and RP software. > > > On 28 Jan 2019, at 19:46, Alberto Leiva wrote: > > > > I have three questions: > > > > =3D=3D=3D=3D 1 =3D=3D=3D=3D > > > > Section 4.8.8.1 has the following paragraph: > > > > This extension MUST have an instance of an accessMethod of id-ad- > > caRepository, with an accessLocation form of a URI that MUST specify > > an rsync URI [RFC5781]. (...) Other accessDescription elements with > > an accessMethod of id-ad-caRepository MAY be present. In such cases, > > the accessLocation values describe alternate supported URI access > > mechanisms for the same directory. The ordering of URIs in this > > accessDescription sequence reflect the CA's relative preferences for > > access methods to be used by RPs, with the first element of the > > sequence being the most preferred by the CA. > > > > Those MUSTs confuse me. What is the intent behind them? > > I agree that this is somewhat confusing. My interpretation of this is tha= t the text tries to leave the option for future transport protocols, other = than rsync, open. However, there are no accepted other transport protocols = defined at this time. > > > 1. Exactly one of the caRepositories MUST be URI, and MUST be RSYNC: > > > > caRepository URI RSYNC > > caRepository other whatever > > caRepository other whatever > > caRepository other whatever > > > > 2. Exactly one of the URI caRepositories MUST be RSYNC: > > > > caRepository URI RSYNC > > caRepository URI other > > caRepository URI other > > caRepository other whatever > > > > 3. There MUST be at least one RSYNC URI caRepository: > > > > caRepository URI RSYNC > > caRepository URI RSYNC > > caRepository URI whatever > > caRepository other whatever > > > > 4. (Unlikely, I realize) All of the caRepositories which are URIs MUST > > be RSYNC: > > > > caRepository URI RSYNC > > caRepository URI RSYNC > > caRepository URI RSYNC > > caRepository other whatever > > caRepository MUST be a URI, not other. There MUST be one and only one rsy= nc. There MAY, in future, other URIs for 'alternate URI access mechanisms' = - one for each. However, no other such mechanisms are defined. > > So, for all intents and purposes you can expect 1 and only 1 SIA of the t= ype caRepository and it MUST use rsync. > > > > > =3D=3D=3D=3D 2 =3D=3D=3D=3D > > > > Is the above verdict supposed to be consistent with the other Access > > Descriptions in the RFC? They generally use somewhat different wording: > > > > AIA: > > > > The preferred > > URI access mechanisms is "rsync", and an rsync URI [RFC5781] MUST be > > specified with an accessMethod value of id-ad-caIssuers. (...) > > Other accessMethod URIs referencing the same object MAY also be > > included in the value sequence of this extension. > > One, rsync. And the value of the AIA is rather limited. It provides a hin= t to where the parent certificate may be found, but this may be incorrect w= ithout invalidating the object. Typically the certificate is found through = top-down validation so the parent CA certificate is already known. > > > > CA SIA.rpkiManifest: > > > > This extension MUST have an instance of an AccessDescription with an > > accessMethod of id-ad-rpkiManifest, (...) > > with an rsync URI [RFC5781] form of accessLocation. (...) > > Other accessDescription elements MAY exist for the id-ad-rpkiManifest > > accessMethod, where the accessLocation value indicates alternate > > access mechanisms for the same manifest object. > > Again my interpretation is that there can be only one SIA of this type in= practice, and it MUST be rsync. > > > > > EE SIA: > > > > This extension MUST have an instance of an accessMethod of id-ad- > > signedObject, (...) > > with an accessLocation form of a URI that MUST include an rsync URI > > [RFC5781]. (...) Other accessDescription > > elements may exist for the id-ad-signedObject accessMethod, where the > > accessLocation value indicates alternate URI access mechanisms for > > the same object, ordered in terms of the EE's relative preference for > > supported access mechanisms. > > > > Other AccessMethods MUST NOT be used for an EE certificates's SIA. > > Same.. > > Except that in this case I really feel that this is a formality. This SIA= points to the object itself. I assume that you won't need this information= once you have found the object. > > > =3D=3D=3D=3D 3 =3D=3D=3D=3D > > > > Section 4.8.8.2: > > > > Other AccessMethods MUST NOT be used for an EE certificates's SIA. > > > > It seems that this requirement has been superseded by RFC 8182: > > > > Certificate Authorities that use RRDP MUST include an instance of an > > SIA AccessDescription extension in resource certificates they > > produce, in addition to the ones defined in [RFC6487]: > > (...) > > This extension MUST use an accessMethod of id-ad-rpkiNotify (...) > > > > Has it been superseded? Or does the second quote only apply to CA > > certificates? (which would make the word "produce" seemingly out of > > place.) > > > > (Aside: 8182 does not appear in the 6487 Updated By list.) > > Good point, and I see another omission upon re-reading RFC8182 (RRDP) - o= f which I am a co-author.. > > The SIA defined in section 3.2 of RFC8182 is intended as an addition to t= he existing SIAs defined in RFC6487. Furthermore it is only expected to be = present in CA certificates, since these are the only currently defined RPKI= objects for which signed products may be found. Including the id-ad-rpkiNo= tify in an SIA of en EE certificate of e.g. a manifest does not hurt, but i= t's also pointless. This intent is phrased in the last paragraph of 3.2: > > The accessLocation MUST be an HTTPS URI as defined in [RFC7230] that > will point to the Update Notification File for the Repository Server t= hat publishes > the products of this Certificate Authority certificate. > ^^^^^^^^^^^^^^^^^^^^ > > But this is not phrased as clearly as it could have been. > > > > > > > _______________________________________________ > > sidr mailing list > > sidr@ietf.org > > https://www.ietf.org/mailman/listinfo/sidr >