Re: [sidr] RPKI: Three questions regarding RFC 6487

Alberto Leiva <ydahhrk@gmail.com> Wed, 30 January 2019 15:55 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 9416B124C04 for <sidr@ietfa.amsl.com>; 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 <sidr@ietfa.amsl.com>; 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 <sidr@ietf.org>; Wed, 30 Jan 2019 07:55:42 -0800 (PST)
Received: by mail-wm1-x334.google.com with SMTP id d15so26284wmb.3 for <sidr@ietf.org>; 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: <CAA0dE=WecNKYx7Pyk+LpqcWEsL7qbVef7=-uCfUQhBjXFaQhYA@mail.gmail.com> <A1925027-2A2E-45C0-8AD3-CCE411692F8A@nlnetlabs.nl>
In-Reply-To: <A1925027-2A2E-45C0-8AD3-CCE411692F8A@nlnetlabs.nl>
From: Alberto Leiva <ydahhrk@gmail.com>
Date: Wed, 30 Jan 2019 09:55:29 -0600
Message-ID: <CAA0dE=VJagRC4wSHv-HhneO_VQtsybVUTzo2ChTPAt8D5LOYrw@mail.gmail.com>
To: Tim Bruijnzeels <tim@nlnetlabs.nl>
Cc: IETF SIDR <sidr@ietf.org>, Matt Lepinski <mlepinski@bbn.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidr/xBHgX7ft92Jg555ZS7EVOUQFoCE>
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 <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: Wed, 30 Jan 2019 15:55:45 -0000

Thank you!

On Tue, Jan 29, 2019 at 3:38 AM Tim Bruijnzeels <tim@nlnetlabs.nl>; 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 as an implementer of CA and RP software.
>
> > On 28 Jan 2019, at 19:46, Alberto Leiva <ydahhrk@gmail.com>; wrote:
> >
> > 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?
>
> 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:
> >
> >    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 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.
>
>
>
> > ==== 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.
>
> 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:
> >
> >   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.
>
> > ==== 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.)
>
> 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.
>
>
>
> >
> > _______________________________________________
> > sidr mailing list
> > sidr@ietf.org
> > https://www.ietf.org/mailman/listinfo/sidr
>