Re: [Sidrops] 6486bis: Failed Fetches

George Michaelson <> Tue, 18 August 2020 19:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 86DC03A0B13 for <>; Tue, 18 Aug 2020 12:51:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id QWg3cQ_rt16j for <>; Tue, 18 Aug 2020 12:51:03 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::d33]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3E6EB3A0A3B for <>; Tue, 18 Aug 2020 12:51:03 -0700 (PDT)
Received: by with SMTP id a5so22313777ioa.13 for <>; Tue, 18 Aug 2020 12:51:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=2TPlGs3G1rTGR7Ecm330qElrB5dxonfKYm/FbPQQcgo=; b=VqlsSTyhaf94brW74leooEJ0ZY0+mQd4wMGOwvJp5cx4GH3ojiRqQ7haZdYiT5kOYJ 2JcH2b1aZaFPeXEi/1wXe5mAfM6QGNzDWXVgbLOg1UYKBedycYus5Zaug2ehxeLYe9dL 4oMOaqZHS28U1J9aLy6fJgMgEheSxEEBcBJreVTtW4xnVrfACFzmoH6gyFgeYXJ5JF7I FyHUaIv9z7cARB/i3xT0Tg5DJb+UKMpOXENQewrHq0e/2nRvN1Vy6ULkz2CNa4X2huu8 YSSb8JqW4+ruIpNIDsSpk5GuL+P9DWaUCsqAbbcy3fuqoWB8nCtY4TSsG6mwQjWZRUVd tdFw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=2TPlGs3G1rTGR7Ecm330qElrB5dxonfKYm/FbPQQcgo=; b=RqnPOOsxlWL3JeMCTSvcviOH/R00eme/EYjzKtNzMf0zZaHHUxvtvh7fbnet4XgRlJ F1sSV78F3ExFNRiV6ioSkkt3Ngb03YoevD73XUJoub06NyG5wjWFAFP8G56ZCVqAnwnG k/prE7WS6lzNd3bkWiC6KYrbGjwVuaYzlmQcerVong4/4oys1SnBb8XX1CHPaakJtsXu vV4xlD4eWyM1qXpUbBIirOViGzxZiKDTZ2VprA9QWpaUWybFoZeuWEYR4SQybz8nmoSP LsI0a6uSn2e0C5Ny3PwyXKVrZbhsbWeUhiZZF8l6nnK1U7xFPaPRtFOWM5kBTxRev9hC wsSA==
X-Gm-Message-State: AOAM5317ojYOobs6//mBOqsTm4YV+hrjesIiNCo8TGxpno4SqwsOW7zv THthcFhI/XMK927zXC4MJhzphaWUafS5IgfCdnt1oA==
X-Google-Smtp-Source: ABdhPJyET0cVdpoNfirtXx/yEOoA2gScbUz5nDC2tJ40j+XralemiaC3Udlw9t5fCBh1cAlVfj4uLtNCzsPiYrq6v4E=
X-Received: by 2002:a02:a905:: with SMTP id n5mr21161959jam.64.1597780262036; Tue, 18 Aug 2020 12:51:02 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
From: George Michaelson <>
Date: Wed, 19 Aug 2020 05:50:51 +1000
Message-ID: <>
To: Martin Hoffmann <>
Cc: Stephen Kent <>, SIDR Operations WG <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [Sidrops] 6486bis: Failed Fetches
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 18 Aug 2020 19:51:08 -0000

FYI we fully intend resubmitting RTA, we were waiting for the second
implementation (the work Martin is doing) to have input of merit to
spin the new version. It would be plausible to resubmit for the
November IETF. Two running code!

We designed RTA to be complete outside of a repo, so it can be used
privately between B2B partners. Not that its things cannot "be" on the
manifest, but that there is no dependency on the repo framework beyond
the TA, because the passed data is the chain for validation. This
matters to people who want to conduct activity outside of the BGP
validation problem, which is an 'all data needed' problem. B2B uses of
RTA are not directly about all data. Its different. (provisioning is
typically the use case here and the intent is to show the request to
route, originate, provision is valid, because control of the resource
can be demonstrated. its inherently a one-to-one conversation)

RTA objects have an OID, are in the registry of types. So there is a
meta-question implicit here, that the set of OID which can be
referenced from a Manifest is NOT bound, and CAN increase, so
validators have to be written in a way which expect to deal with
unknown signed things: The system is not closed, and there will be
others in future. I think the validation of a manifest MUST NOT fail
simply because unknown objects exist on the Manifest, especially if
the OID lies in the arc of RPKI definitions.

Martin's question is also on the other side of the deal: If a manifest
is showing a repository is incomplete, does it cause formal
invalidation of all things in the manifest, which has potential to
make validation of the 'complete' chain we send in RTA not work
because now, an object on the RTA validation path is questioned for
other reasons.

I tend to the view that only things which invalidate the certificates
matter, ROA or other elements are not contributing to the validity of
the RTA.  This is because they are not material to the validity of the
object. If it was a 'whole repo' problem I could argue otherwise. It
is not. It is inherently constrained.

Specifically Missing CRL.. I have more concerns about. That would mean
we cannot authentically deny the objects being validated.


On Tue, Aug 18, 2020 at 4:37 PM Martin Hoffmann <> wrote:
> Stephen Kent wrote:
> >
> > Are you positing the case where the cache contains an expired ROA for
> > a CA instance, and a fetch that would have replaced the expired ROA
> > fails?
> No, I am talking about a case where the ROA can be fetched successfully
> and matches the manifest hash, but its EE certificate is expired.
> Section 6.4 says that "if [files] fail the validity tests specified in
> [RFC6488]", the fetch has failed. Thus, the expired EE certificate in
> the ROA fails the complete fetch of all objects associated with the CA.
> So, not replacing an expired ROA in a publication point makes the
> entire CA not update anymore. I.e., any other objects that now expire
> cannot be replaced until that ROA is also replaced.
> You could argue “Don’t do that, then” but this approach doesn’t make
> the RPKI more robust but rather makes it break more easily on simple
> oversights.
> > > This rule also blocks skipping objects of types I don’t know or care
> > > about. I will have to at least do signed object validation on them,
> > > which means reading and parsing them and then do signature
> > > validation. If that is intended, I think this should be called out
> > > explicitly in the document.
> > If a manifest points to objects that are not CRLs, certs, ROAs, etc.,
> > then it is in error.
> How do you introduce new object types in this case? There will always
> be relying parties that run old software that doesn’t know of them. You
> rather have to assume that objects of unknown types are signed objects
> with unknown content. If you do that, the current draft stipulates that
> you have to read, parse, and validate them -- and then throw away the
> content.
> This still means that all object types added to the RPKI must be signed
> objects. Whether that is okay or not, I don’t quite know.
> > But, your question seems to be what processing
> > has to be performed on the files contained in an apparently valid
> > manifest, right? Section 6.4 and RFC 6488 defines the tests to be
> > performed, and 6.4 explicitly cites 6488. What additional info do you
> > feel is needed here?
> I would like the document to explicitly state how to deal with object
> types appearing on a manifest that a replying party does not know. If
> nothing else then to make the document more helpful for implementers.
> > > But I’m not even sure it provides any benefit. I, say, I am
> > > validating a resource tagged association (RTA, [0]), I don’t care
> > > about the ROAs at all. Does the RTA become invalid because a CA
> > > somewhere in the validation chain had an expired ROA?
> >
> > I have not examined the RTA ID, and it's an expired draft, so ...
> RTA validates signed objects distributed via alternative means using
> the PKI published as part of the RPKI. I.e., one of the CA
> certificates published via the RPKI has issued the EE certificate used
> in that signed object.
> In order to validate that object, I do not need to look at any ROAs or
> GBRs, only certificates, CRLs, and manifests.
> Should validation of that object fail if there is an expired ROA
> published by one of the CAs along the validation chain?
> Kind regards,
> Martin
> _______________________________________________
> Sidrops mailing list