[sidr] RPKI: Three questions regarding RFC 6487
Alberto Leiva <ydahhrk@gmail.com> Mon, 28 January 2019 18:46 UTC
Return-Path: <ydahhrk@gmail.com>
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 <sidr@ietfa.amsl.com>; 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 <sidr@ietfa.amsl.com>; 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 <sidr@ietf.org>; Mon, 28 Jan 2019 10:46:33 -0800 (PST)
Received: by mail-wm1-x334.google.com with SMTP id p6so15050231wmc.1 for <sidr@ietf.org>; 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 <ydahhrk@gmail.com>
Date: Mon, 28 Jan 2019 12:46:21 -0600
Message-ID: <CAA0dE=WecNKYx7Pyk+LpqcWEsL7qbVef7=-uCfUQhBjXFaQhYA@mail.gmail.com>
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: <https://mailarchive.ietf.org/arch/msg/sidr/1C5ef6LR_MdiEsET1ODKCIK1J7g>
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 <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidr/>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=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.)
- [sidr] RPKI: Three questions regarding RFC 6487 Alberto Leiva
- Re: [sidr] RPKI: Three questions regarding RFC 64… Tim Bruijnzeels
- Re: [sidr] RPKI: Three questions regarding RFC 64… Alberto Leiva